Quote from: nearmint on February 25, 2014, 09:37:13 PM

Unfortunately, I don't quite understand this last part of your reply yet. Is defining inputs = ALL previously received outputs to a certain wallet?) From what I understand, if we have to calculate the sum of all inputs (=all btc ownership values that were transferred to the wallet?) minus the sum of all outputs (=all btc ownership values that were transferred away from the wallet), then the transaction fee can only be calculated after the transaction has taken place.

A wallet contains only the private keys that are necessary to sign transactions. There are no "Bitcoins" in a wallet. The wallet uses the private keys to calculate the associated bitcoin addresses (each private key has one and only one bitcoin address that it is mathematically linked to). The wallet then uses the addresses to search through the entire blockchain for every transaction that pays an output to that address. Some of those outputs will already have been spent in other transactions. The wallet sums up all the unspent outputs and displays this as a total for you. The outputs remain in the blockchain, still unspent until you actually spend them.

When you create a transaction, your wallet chooses one or more of the unspent outputs in the blockchain that are associated with an address that the wallet has the private key for. The wallet chooses enough inputs to make sure that the total value being provided to the transaction is at least as much as the total value of the outputs that you told the wallet you wanted to create.

Listing an input in a transaction involves providing reference information about where in the blockchain to find that unspent output as well as an ECDSA digital signature using the private key proving that the spender is authorized to spend that output. There is some additional overhead for each input as well. All together this requires approximately 180 bytes.

Listing an output in a transaction involves providing the RIPEMD-160 hash that is associated with the bitcoin address, and a total value being sent to that address. There is some additional overhead for each output as well. All together this requires approximately 40 bytes.

There transaction itself has some overhead indicating the quantity of inputs, quantity of outputs, and a few other useful pieces of information.

So, the wallet first determines how much value the sum of the outputs is. Then it finds enough unspent inputs to gather together to provide the necessary value to the transaction. It is rare for the exact amount needed to be available from a combination of inputs, so this will generally result in providing too much value to the transaction. The wallet then creates one additional output to send the "change" back to an address in the wallet. At this point the wallet knows exactly how big the inputs and outputs are. It can calculate the appropriate fee, and adjust the value of the "change" to make sure there is enough value left over unaccounted for to provide an appropriate fee. Then the transaction inputs are all signed and the transaction is broadcast.

Quote from: nearmint on February 25, 2014, 09:37:13 PM

By the way,.. starting to read Satoshi's whitepaper..the first question that pops to my mind is in regards to the Timestamp Server.

As has been pointed out, since Bitcoin is decentralized, there is no single "timestamp server" instead Bitcoin needs a decentralized way to indicate the order that transactions occur. The blockchain provides this functionality. By packaging transactions into blocks and making it possible to discern the order of those blocks, it is now possible to state that a particular transaction "occurs" either before or after another transaction.

Quote from: nearmint on February 25, 2014, 09:37:13 PM

Won't the transaction size increase, depending on how many Timestamps have been added to the chain?

Not transaction size. Each transaction provides a reference into the blockchain to indicate which previous unspent transaction output is being spent. This reference is the same size regardless of the size of the blockchain. The size of the blockchain on the other hand does increase forever. It grows in size by one block approximately every 10 minutes.

Quote from: nearmint on February 25, 2014, 09:37:13 PM

Wouldn't this mean at one point, every transaction will be subject to higher and higher transaction fees, simply because the timestamp chain is getting larger and larger?

See above. Transaction doesn't get bigger. The reference used doesn't change in size as the blockchain gets bigger.

Quote from: nearmint on February 25, 2014, 09:37:13 PM

Is the following true?
1. Miners' nodes are needed to confirm transactions

Yes this is the purpose of mining. In exchange the miner that solves the block is rewarded with the sum of all the transaction fees of all the transactions they include in the block (giving them an incentive to actually include the transactions) as well as the current block subsidy (newly created bitcoins). The current subsidy is 25 BTC. The subsidy is cut in half every 210,000 blocks (approximately every 4 years).

Quote from: nearmint on February 25, 2014, 09:37:13 PM

2. At one point, all Bitcoins are mined

Yes. Since the subsidy is an integer, and is cut in half every 210,000 blocks, eventually the subsidy will be 0 BTC.

Quote from: nearmint on February 25, 2014, 09:37:13 PM

3. So at some point, miners need to make money just by confirming transactions, because they can't mine Bitcoins anymore.

Correct. As the subsidy shrinks and bitcoin gains popularity, eventually the total transaction fees in a block will exceed the block subsidy. The subsidy will continue to shrink and eventually the entire mining revenue will be from transaction fees.

Quote from: nearmint on February 25, 2014, 09:37:13 PM

4. The process of confirming transactions increases in difficulty depending on amount of transaction (not self-regulated!) // The difficulty to mine Bitcoin increases in difficulty depending on how many nodes are trying to mine the Coins (self-regulated! less miners>easier mining)

The target hash that a miner must find to satisfy the proof-of-work is self-regulated by the protocol. It is adjusted to attempt to keep the rate of solved blocks as close to 2016 blocks every 705,600 seconds. The adjustment occurs every 2016 blocks.

If the 2,016 blocks were solved faster than 705,600 seconds, then the protocol requires a new difficulty target that is proportionally more difficult to achieve. This results in the average time between blocks increasing.

If the 2,016 blocks were solved slower than 705,600 seconds, then the protocol requires a new difficulty target that is proportionally less difficult to achieve. This results in the average time between blocks decreasing.

The difficulty is not related to the amount of transctions at all. It is entirely based on the speed at which blocks are being solved.

Additional hashing power from miners decreases the amount of time that it takes to find a low enough hash to satisfy the difficulty (it is faster/easier to roll a 1 if you roll 15 dice all at once than it is if you are only rolling 2 dice at a time). This speeds up block solving and triggers a difficulty adjustment when the next 2,016 block trigger is encountered.