BIP: Short Term Use Addresses for Scalability [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-07-23T06:05:12+00:00


Summary:

A proposed change in Bitcoin's transaction format could result in significant memory savings for the UTXO pool. Currently, a standard transaction occupies 225 bytes, but this change could potentially save up to 8.6% of space, with even greater savings for larger transactions. It is important to note that this change specifically impacts the UTXO pool's memory usage and not the overall storage size of the blockchain.However, implementing this change would require most clients to update their code, which could be a time-consuming process. Moreover, considering the modest space savings of just 10 bytes, some may question whether it is worth the effort. An alternative solution suggested by Gavin Andresen involves introducing shorter ECDSA keys, which would save more space for public keys and signatures. This approach would likely be included in the OP_MAST and require a new address type.Gavin Andresen further expressed his concerns regarding introducing a new address type, as it would necessitate widespread code changes. He argued that the potential space savings of around 5% are not significant enough to justify the extreme decrease in security, going from 2^160 to 2^80 against brute-force attacks. Instead, he proposed the use of shorter ECDSA keys, which would remain secure as long as the output value is much lower than the cost of attack.The discussion also delves into the topic of Short Term Use Addresses (STUAs) and their potential benefits. STUAs provide an incentive for reducing transaction fees, aligning with the concept that miners are paid for maintaining network security. However, there is debate about the actual savings benefit, as they may only be marginal unless margins are tight. Large players could prefer this option, while individual users may desire it. Security concerns surrounding STUAs can be mitigated by selecting LEN_PARAM during transactions to increase security. Additionally, given that these addresses are meant for short-term use only, the threat is not significant. Furthermore, STUAs offer advantages in reducing memory bloat associated with the UTXO pool.Regarding the proposal to introduce a new Bitcoin address type, Gavin Andresen and Tier Nolan both raised concerns about the challenges it poses. Nolan highlighted the need for client updates, citing the difficulties experienced during the introduction of P2SH addresses. He concluded that introducing a new address system for a modest space saving of 10 bytes, especially considering the extreme decrease in security, would not be worthwhile. Andresen echoed these sentiments, expressing his belief that introducing another Bitcoin address type is unnecessary.Jeremy Rubin contributed to the discussion by proposing a soft fork solution to increase the number of transactions per block. His proposal involves repurposing a NOP instruction with a new opcode called OP_LEFTEQUALVERIFY. This opcode would check if the leftmost L bytes of two arrays match, failing immediately if they do not, or if either array is less than L bytes, or if there are fewer than three values on the stack. Rubin acknowledges that implementing this change would require a new BIP and client updates, but it would only provide a one-time improvement in efficiency. Therefore, he suggests that this solution may not be worth the effort. Another option mentioned is using a different script engine, similar to the approach taken with P2SH.In summary, the discussions revolve around potential changes to Bitcoin's transaction format and address types. While the proposed changes could lead to memory savings in the UTXO pool, there are concerns about the effort required for widespread code updates and the trade-off between space savings and security. The debate also touches upon the benefits and considerations of Short Term Use Addresses and alternative solutions to increase the number of transactions per block.


Updated on: 2023-08-01T14:29:04.113809+00:00