Published on: 2011-12-18T19:50:13+00:00
The speaker in the given context expresses gratitude for gaining an understanding of a concept related to saving space through shorter scripts in transactions. The concept is possibly related to programming or coding. The benefits of writing shorter scripts in transactions are now clear to the speaker, although it is not specified how they came to this understanding.In a discussion about Bitcoin's transaction format, Jorge Timón questions the idea of including the whole public key in each output instead of just the address hash. This would save space compared to the current method. Various improvements, such as using compressed public keys, compact signatures, and pubkey recovery, were suggested to achieve space savings. Gregory Maxwell provides a table comparing these options, showing that all proposed options are better than the current method. However, the advantages of these new methods may be smaller if pruning is implemented in the future.The conversation on December 18, 2011, confirms that putting the whole pub key in each output was being proposed as a more efficient solution for the blockchain. However, sipa's key extraction was considered a better alternative if it could be achieved without a blockchain fork.In a conversation thread from 2011, Jorge Timón and Luke-Jr discuss the use of "Green addresses" in POS payments. Luke-Jr supports their use, but Jorge Timón argues that they are a "broken-by-design feature" and should not be encouraged. The flaw Luke-Jr refers to is not specified. The conversation then shifts to discussing whether it would be practical to put the entire public key in each output.Jorge Timón expresses his opinion about the usefulness of "green addresses" in a specific case in a conversation on December 18, 2011. However, it is stated that "green addresses" are considered broken-by-design and should not be encouraged. No further information is provided about what exactly a "green address" is or why it is considered flawed.In a forum post from 2011, Jordan Mack shares his thoughts on the firstbits proposal compared to current alias proposals. He finds the idea of firstbits interesting but agrees with Matt that it produces a less desirable solution. However, he sees the usefulness of firstbits for the "green address" case, where people would not have to write or memorize the firstbit address but could use a shorter string for QR codes. Mack believes aliases are a better solution for the "memorizing use case." He also questions how putting the entire public key instead of just the address hash would save space.In December 2011, Luke-Jr and Gregory Maxwell discuss enabling new opcodes in the Bitcoin protocol. Gregory expresses irritation that recovery discussion in OP_EVAL was dropped due to the belief that input script size does not matter because of pruning. Luke-Jr is willing to defer full OP_EVAL support on Eligius to enable key recovery. They agree to revisit the possibilities enabled by enabling new opcodes.In another conversation on December 17, 2011, Gregory Maxwell expresses annoyance that discussion on recovery in OP_EVAL was dropped. He is concerned about adding another address type, which would create bloated transactions when there is pruning. Luke-Jr is willing to defer full OP_EVAL support on Eligius for key recovery.Luke-Jr proposes in a Bitcoin development discussion that full public key addresses be required to be "compact" and use version 21. This would introduce another address type, which may require modifications to existing software. Pay-to-pubkey schemes are discussed, and it is concluded that pay-to-address plus key recovery is smaller than pay-to-compressed pubkey. The advantages and disadvantages of different options are considered, with the conclusion that pay-to-address should be preferred if pruning becomes common on many nodes.A proposal is made to require full public key addresses to be "compact" and use version 21. The purpose of this proposal is not clear, but feedback is sought on its workability. No further information is provided about potential benefits or drawbacks.The use of firstbits in Bitcoin addresses is deemed unscalable and potentially harmful by developers. While it may seem like a clever solution to shorten addresses, it could lead to errors and exploitation. Matt Corallo warns against supporting firstbits due to incentives for chain spamming. As Bitcoin moves towards SPV clients, the use of firstbits is not considered viable.In a discussion about QR codes, Jorge Timón expresses confusion about why Jav would want to use firstbits. Matt strongly opposes the use of firstbits due to scalability issues and potential incentives for chain spamming. He believes it should never be supported, especially as SPV clients become more prevalent.In an email conversation, Wladimir and Luke-Jr discuss the idea of standardizing and supporting public key addresses. They acknowledge that these addresses may not be ideal for humans but suggest they would be better for large QR codes.
Updated on: 2023-08-01T02:44:40.898309+00:00