-
Notifications
You must be signed in to change notification settings - Fork 787
Rejected features
It would be possible to put a send and receive action in to a single block but this would require a connection and agreement between the sender and receiver as to where the transaction should go in their respective block chains. Connecting in order generate a transaction would add complexity and breach much of the pseudonymity of the ledger. Interlocked transactions could also temporarily freeze either account for fork resolution if either of them generated a fork.
It's possible to express each account balance as a fraction of the total coin supply. This would require peers to be able to operate on large rational numbers and there would need to be consensus guarding against fractions with large numerators and denominators that represents a disproportionately small balance. Using a fraction would also make block size variable which can hurt some block storage optimizations. The only necessary form of fractional balance would be n/2^m where m can be increased to generate smaller balances. This complexity seems unnecessary if we operate on integral coins from a sufficiently large pool.
It would be possible to construct blocks that could take multiple inputs and multiple outputs but this adds complexity to the receiving part of a transaction because we not only have to name the source send block but which entry in the send block we're receiving. This would also make blocks variable size which requires framing and hurts some block store optimizations. The same block would also be in multiple chains and the entire block would need to be rolled back if any the entries created a fork. Multiple inputs and outputs greatly increases complexity of the ledger algorithms.