Published on: 2020-06-09T14:16:27+00:00
In a recent email exchange on the Bitcoin-dev mailing list, Mostafa Sedaghat joo proposed the idea of stamping transactions to decouple them from blocks and keep the size of the blockchain as small as possible. He argued that blockchain size matters, even though data storage is cheap and easy, and suggested that if you need a data-center to keep a copy of a blockchain, then you are far from a decentralization system.However, ZmnSCPxj countered that the entire history of Bitcoin is needed when starting a new node to prove ownership of current coins, and that existing currency systems have not only the "official" minter but also many "unofficial" minters (counterfeiters) which dilute the value of the currency. ZmnSCPxj further argued that validating the stamp is still a cost on every node, and it is that cost that needs to be reflected in pricing every byte in the transaction. He pointed out that UTXOs are retained indefinitely and that outputs in SegWit are 4x more expensive than signatures because signatures are only validated once when the transaction is queued to be put in the mempool.Mostafa Sedaghat joo suggested that the proposed mechanism could be made into a softfork by using an unspendable `scriptPubKey` with 0 output value. ZmnSCPxj countered that soft fork is not possible here since the transaction will not be saved inside the block and only tx hashes will be saved. Mostafa Sedaghat joo suggested that nodes can turn on pruning if the operator doesn't desire to keep all the transactions from the genesis block. Likewise, light clients may not keep any transaction history. He also suggested that when a new node connects to the network, it doesn't need to validate all the blocks since genesis but can start validating from a checkpoint.ZmnSCPxj raised concerns about the incentives for stamped transactions, as users will prefer to run older versions and never upgrade to the new version that requires stamped transactions. He argued that if it is so good for the network, then it should be good for an individual user because the network is made up of individual users anyway. If individual users are not incentivized to use it, then that fact suggests it might not be as good for the network as one might think.In summary, Mostafa suggests decoupling transactions from the block to keep the blockchain size small. However, ZmnSCPxj argues that stamped transactions are not a solution to reduce the blockchain size. The reason why old history is retained is to prove to new nodes that one is the correct owner of the current coins. This is what separates Bitcoin from previous currency systems. Stamped transactions will require a hardfork, which is risky and unlikely to be accepted by everyone. Moreover, validation becomes more expensive as the blockchain grows. Stamped transactions are larger and more expensive than unstamped transactions, making them less incentivized. Users may prefer running older versions and never upgrading to the new version that requires stamped transactions. Furthermore, validating the stamp on every node is still a cost, and it is an incentive problem if individual users are not incentivized to use it. Stamping transactions does not help reduce mempool size as resending the transaction with a fresh stamp increases bandwidth usage. The article discusses the idea of stamping transactions to keep the size of the blockchain as small as possible. However, it is argued that stamping transaction is not how one can be able to keep blockchain size low since very old history is retained to prove that you are the correct owner of the current coins when starting a new node. The proposal would require a hardfork and validation is expected to become more expensive as the blockchain grows. Stamped transactions are more expensive than unstamped transactions due to their larger size. This creates an incentives problem because users will prefer to run older versions and never upgrade to the new version that requires stamped transactions. Finally, it is pointed out that the stamp does not reduce mempool size and re-sending the same transaction with a fresh stamp increases bandwidth use.The proposed mechanism can be made into a softfork by using an unspendable `scriptPubKey` with 0 output value. For instance, a stamp could be any 0-value output whose `scriptPubKey` is `OP_0`, which should be unspendable. Post-softfork nodes would reject blocks where some transaction is stamped and the stamped `` is not within the last N blocks. Block validation now needs to memorize the last N block hashes. The mempool design currently assumes that a transaction that enters the mempool is always valid unless any UTXOs it spends have been removed.If transactions are stamped with a block that has dropped from the stamp TTL, there is an additional need to drop transactions from the mempool.
Updated on: 2023-08-02T02:21:20.352012+00:00