Good morning Bram, > while in the coin set model each puzzle (scriptpubkey) gets run and either > assert fails or returns a list of extra conditions it has, possibly including > timelocks and creating new coins, paying fees, and other things.
Does this mean it basically gets recursive covenants? Or is a condition in this list of conditions written a more restrictive language which itself cannot return a list of conditions? > > - serialization seems to be a bit verbose -- 100kB of serialized clvm > > code from a random block gzips to 60kB; optimising the serialization > > for small lists, and perhaps also for small literal numbers might be > > a feasible improvement; though it's not clear to me how frequently > > serialization size would be the limiting factor for cost versus > > execution time or memory usage. > > A lot of this is because there's a hook for doing compression at the > consensus layer which isn't being used aggressively yet. That one has the > downside that the combined cost of transactions can add up very nonlinearly, > but when you have constantly repeated bits of large boilerplate it gets close > and there isn't much of an alternative. That said even with that form of > compression maxxed out it's likely that gzip could still do some compression > but that would be better done in the database and in wire protocol formats > rather than changing the format which is hashed at the consensus layer. How different is this from "jets" as proposed in Simplicity? > > Pretty much all the opcodes in the first section are directly from chia > > lisp, while all the rest are to complete the "bitcoin" functionality. > > The last two are extensions that are more food for thought than a real > > proposal. > > Are you thinking of this as a completely alternative script format or an > extension to bitcoin script? They're radically different approaches and it's > hard to see how they mix. Everything in lisp is completely sandboxed, and > that functionality is important to a lot of things, and it's really normal to > be given a reveal of a scriptpubkey and be able to rely on your parsing of it. I believe AJ is proposing a completely alternative format to OG Bitcoin SCRIPT. Basically, as I understand it, nothing in the design of Tapscript versions prevents us from completely changing the interpretation of Tapscript bytes, and use a completely different language. That is, we could designate a new Tapscript version as completely different from OG Bitcoin SCRIPT. Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
