Author: ZmnSCPxj 2022-03-07 22:56:38
Published on: 2022-03-07T22:56:38+00:00
The discussion starts with a query regarding the coin set model, where each scriptpubkey gets run and returns a list of extra conditions. The question is whether this means it gets recursive covenants or if there's a condition in the list that is written in a more restrictive language which cannot return a list of conditions. There's also a mention of serialization being verbose and suggestions for optimizing it for small lists and literal numbers. The conversation moves on to compression at the consensus layer, which isn't being used aggressively yet. There's a hook for doing compression, but it has the downside of adding up very nonlinearly when combined with the cost of transactions. Even with that form of compression maxed out, gzip could still do some compression, but it's better done in the database and wire protocol formats rather than changing the format hashed at the consensus layer. There's a discussion about the opcodes used in the first section being directly from Chia Lisp, while the rest are to complete the "bitcoin" functionality. The last two are extensions that are more food for thought than a real proposal. It's hard to see how they mix because everything in Lisp is completely sandboxed, and that functionality is important to a lot of things. AJ proposes a completely alternative format to OG Bitcoin SCRIPT, as nothing in the design of Tapscript versions prevents them from completely changing the interpretation of Tapscript bytes and using a completely different language.
Updated on: 2023-06-15T17:32:52.683475+00:00