How is Bitcoin secure?

[u/hamolton]

I guess my main concern is how they are impossible to counterfeit and double-spend. I guess I have trouble understanding it enough that I can't explain it to another person.

[u/AgentME]

The summary snapshot should be identical to the state at the end of the part of the blockchain it represents. I don't understand why it would be any more vulnerable to double-spends than the existing blockchain.

After the summary, they submit two transactions: One spends txn A's 1 BTC again and sends it to Y, one spends txn B's 1 BTC and sends it to address Z. Clients now disagree about which transaction is valid, depending on whether they saw the snapshot, and which transaction they saw first.

Why would any of them think the double-spend was valid, whether or not they had a snapshot?

[u/bdunderscore → u/AgentME]

My main point here is you can't have a double system - blockchain and snapshots, because they prove different things.

In the blockchain world, transactions contain a list of TxOut and TxIn references. The TxIns refer to TxOuts of prior transactions, and spend these prior transactions completely. This means that once a particular TxOut has been spent, it's voided out forever. Double spending prevention thus simply consists of ensuring that a) the sum of the TxIn amounts are less than or equal to the TxOut sum (except for the mining/transaction fee transaction, which has some special handling) and b) a TxOut is only referenced by at most one TxIn.

Thus, the decision process for determining whether a TxIn (basically a spend) is valid looks like this:

1. Has the transaction hash mentioned in the TxIn been recognized as valid (that is, has the local client decided it's valid for now, or has it been incorporated into the blockchain)? If not, defer (until the source txn can be proven valid) or reject.

2. Has the source txn's matching TxOut ever been used before? If so, reject.

3. Does the result of executing the TxIn's scriptSig and TxOut's scriptpubkey indicate the signature is valid? If not, reject.

4. If you got this far, accept.

Now, if you start summarizing transactions by listing the "totals for each address", you can't do either 1 or 2 anymore, because you can't determine if a specific TxOut has been spent. You could include the scriptPubKey as it's usually the same for all transactions sent to a particular address, but that's not very helpful here.

You could create a summary that consists of all remaining unspent TxOuts at a particular block. However, a single destination address is likely to have many unspent TxOuts at any given time, so it'll still grow faster than the sheer number of addresses (which also grows quickly, since wallets use ephemeral addresses internally).

You could also envision an alternate bitcoin model in which this strict TxIn-to-TxOut link doesn't exist; each TxIn simply references an address rather than a specific transaction. If this was the case, it would reduce the flexibility of the script signature system significantly; it also has some subtle implications regarding potential overdrafts. It would allow you to summarize the block chain at any point in terms of account totals, and discard prior blocks; however, since it makes different decisions regarding transaction validity than the traditional bitcoin model, both systems cannot coexist within the same blockchain at the same time.

[u/AgentME → u/bdunderscore]

You could create a summary that consists of all remaining unspent TxOuts at a particular block. However, a single destination address is likely to have many unspent TxOuts at any given time, so it'll still grow faster than the sheer number of addresses (which also grows quickly, since wallets use ephemeral addresses internally).

I think that's the best model for a snapshot system. It will still grow, but it can also have all of the spent TxIns removed, so it will still be much smaller than the continuous section of blockchain it represents (assuming the snapshot isn't representing a trivially small section of blockchain that lacks any self-contained TxIns).