Wouldn't it save lots of block space and reduce transaction fees? It seems to me the current method wastes lots of space. I wasn't able to find a technical reason for the current method

  • Bitcoin transactions basically are just "from, to, amount" - "from" are the inputs, "to, amount" are the outputs. What specific difference are you suggesting? – MeshCollider Nov 27 '17 at 4:56

On some blockchains, they are. They just don't work that way on the bitcoin blockchain. There are advantages to the way bitcoin does it. What if you want to send bitcoins to more than one destination or from more than one source?

Also, bitcoin's scheme is much simpler. Either a particular transaction output exists and is unspent or it isn't. A balance is the end result of a very large number of transactions and much more complex to verify.

  • Not only that, an accounts based system is vulnerable to transaction replay. Suppose you were to send me money in a transaction. What prevents me from waiting until your balance is high enough and rebroadcasting that transaction? – Andrew Chow Nov 27 '17 at 2:39
  • @AndrewChow That's not particularly difficult to solve. Ripple does it by requiring that transactions include a sequence number that must match the account's sequence number. During the transaction execution, the account's sequence number is incremented, forever invalidating the transaction. (Ripple also supports binding the transaction to a "ticket" that can only exist once and which is destroyed when the transaction succeeds.) If an account can have a balance, it can just as easily have a sequence number. – David Schwartz Nov 27 '17 at 2:40
  • You have to store the sequence numbers forever though. – Anonymous Nov 27 '17 at 6:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.