Published on: 2022-03-22T23:37:23+00:00
The bitcoin-dev mailing list discussion covered various topics related to improving efficiency in Bitcoin transactions. One suggestion was to discuss cross-input compression of puzzles/solutions, similar to the Chia network, which could save bytes and require less heavy crypto math. The conversation also explored the block packing problem and optimizing block templates to fit more transactions. BLS signatures and PTLC signatures were discussed, along with their benefits and drawbacks. The potential use of a domain-specific language (DSL) and concerns about code comments impacting the blockchain's size were briefly mentioned.In the discussion on cross-input compression, ZmnSCPxj noted that it could save bytes and require less heavy crypto math. BLS signatures were mentioned as a simpler alternative with efficient verification and aggregation. The costs involved in Chia transactions were compared, while in Bitcoin, the costs are implicitly tied together. The use of lisp-generating-lisp compression was discussed, along with its potential impact on CPU load.PTLC signatures were found to be incompatible with Chia due to the absence of secp256k1 operations and the loss of information when aggregated via BLS. However, the CLVM supports BLS12-381 operations, potentially enabling PTLCs in the future. The risks associated with implementing complex covenants directly in C++ were mentioned, and the advantages of using a DSL for covenants were highlighted.Another email thread focused on saving bytes in Bitcoin transactions by reusing single signatures or scriptPubKey templates. Key reuse was seen as undesirable, and instead, encouraging reuse of how pubkeys are used while rotating them was suggested. The potential savings in witness data for HTLCs were discussed, but PTLCs were considered more space-efficient. The implementation of covenant features using CLVM was noted as an advantage over soft fork deployment.The bitcoin-dev mailing list discussion covered various topics. Cross-input signature aggregation was compared to cross-input puzzle/solution compression, with the latter deemed less complicated. The idea of lisp-generating-lisp compression was discussed, along with potential CPU load implications. The compatibility of PTLCs with Chia was questioned due to the absence of secp256k1 operations and the loss of information when using BLS aggregation. The security implications of BLS signatures and concerns about implementing complex covenants directly in C++ were raised. The possibility of using a DSL for covenants was mentioned, though concerns about complexity and auditing were noted.In an exchange between Anthony Towns and an unknown party, the challenges of saving bytes in Bitcoin transactions through single signature reuse or scriptPubKey template reuse were discussed. Key reuse incentivization was identified as an issue, and the benefits and limitations of HTLCs and PTLCs were explored. The complexities and risks associated with implementing covenant features directly in C++ were highlighted.ZmnSCPxj explained the differences between Lisp and Chia in handling puzzles/solutions and cross-input signature aggregation. The importance of cross-transaction relationships in Bitcoin's context was emphasized. The discussion also touched on cost differences in jets and the lack of special treatment for generating Lisp code with Lisp code. Concerns about bugs in covenant complexity and the advantages of implementing covenant capabilities with a language implementation were mentioned.Bram Cohen and Anthony Towns discussed the possibility of redoing the singleton pattern in Bitcoin's context. They proposed passing both the full transaction being spent and the full transaction of its parent to retrieve the parent's scriptPubKey. The need for soft fork opcodes to allow spender flexibility and the use of lisp-like code fragments were suggested. The complications of implementing soft forks and the desirability of rejecting fakeopcodes were discussed.The benefits of cross-input signature aggregation were discussed, noting that BLS signatures could simplify the process. The suggestion of reusing single signatures or scriptPubKey templates for multiple inputs was made. The potential savings in witness data for HTLCs and PTLCs were explored, with PTLCs considered more space-efficient. Concerns about the complexity and risks of implementing covenant features were raised.The email thread delved into the details of cross-input signature aggregation and its complexities. The use of BLS signatures was highlighted as a way to simplify the process. The potential savings in bytes by reusing single signatures or scriptPubKey templates were mentioned. The discussion also touched on the complexities of covenant implementation and the risks associated with it.Overall, the discussions revolved around improving efficiency, reducing transaction size, and exploring different signature types and techniques in Bitcoin transactions.In a discussion about Bitcoin's scripting language, it is explained that in the coin set model, each puzzle (scriptpubkey) either fails an assert or returns a list of extra conditions. The language allows for recursive covenants through specifying output scriptpubkeys/puzzles. However, Bitcoin's script's ability to generate and parse transactions falls short. There is a hook for compression at the consensus layer, but it isn't aggressively used yet.
Updated on: 2023-08-02T05:48:04.512962+00:00