One way to match the way bitcoin do things, you could have the "list of
extra conditions" encoded explicitly in the transaction via the annex,
and then check the extra conditions when the script is executed.
The conditions are already basically what's in transactions. I think the only thing missing is the assertion about one's own id, which could be added in by, in addition to passing the scriptpubkey the transaction it's part of, also passing in the index of inputs which it itself is.
> If you're doing everything from scratch it's cleaner to go with the coin
> set model, but retrofitting onto existing Bitcoin it may be best to leave
> the UTXO model intact and compensate by adding a bunch more opcodes which
> are special to parsing Bitcoin transactions. The transaction format itself
> can be mostly left alone but to enable some of the extra tricks (mostly
> implementing capabilities) it's probably a good idea to make new
> conventions for how a transaction can have advisory information which
> specifies which of the inputs to a transaction is the parent of a specific
> output and also info which is used for communication between the UTXOs in a
> transaction.
I think the parent/child coin relationship is only interesting when
"unrelated" spends can assert that the child coin is being created -- ie
things along the lines of the "transaction sponsorship" proposal. My
feeling is that complicates the mempool a bit much, so is best left for
later, if done at all.
The parent/child relationship is mostly about implementing capabilities. There's this fundamental trick, sort of the ollie of UTXO programming, where to make a coin have a capability you have a wrapper around an inner puzzle for it where the wrapper asserts 'my parent must either be the unique originator of this capability or also have this same wrapper' and it enforces that by being given a reveal of its parent and told/asserting its own id which it can derive from that parent. The main benefit of the coin set approach over UTXO is that it reduces the amount of stuff to be revealed and string mangling involved in the parentage check.
(I think the hard part of managing the extra conditions is mostly
in keeping it efficient to manage the mempool and construct the most
profitable blocks/bundles, rather than where the data goes)
Not sure what you mean by this. Conditions map fairly closely with what's in Bitcoin transactions and are designed so to be monotonic and so the costs and fees are known up front. The only way two transactions can conflict with each other is if they both try to spend the same coin.
> 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.
The above prevents combining puzzles/solutions from multiple coin spends,
but I don't think that's very attractive in bitcoin's context, the way
it is for chia. I don't think it loses much else?
Making something lisp-based be a completely alternative script type would also be my preferred approach.
> A nice side benefit of sticking with the UTXO model is that the soft fork
> hook can be that all unknown opcodes make the entire thing automatically
> pass.
I don't think that works well if you want to allow the spender (the
puzzle solution) to be able to use opcodes introduced in a soft-fork
(eg, for graftroot-like behaviour)?
This is already the approach to soft forking in Bitcoin script and I don't see anything wrong with it. You shouldn't write scripts using previously unrecognized opcodes until after they've been soft forked into having real functionality, and if you do that and accidentally write an anyonecanspend that's your own fault.
Having third parties be able to link their spends to yours complicates
mempool behaviour a fair bit (see the discussions on pinning wrt
lightning txs -- and that's only with direct participants being able to
link transactions).
Bitcoin already has that with spending of transaction outputs, and Chia's mempool doesn't currently let transactions depend on other transactions in the mempool. If you do have that sort of dependency, you should have to smush both transactions together to make a single larger transaction and make it have enough of a fee to replace the smaller one.
I'm pretty skeptical about having a database of large script snippets
that will hopefully be reused in the future.
That database is just the list of old blocks which can be dredged up to have code pulled out of them.
In chia the "scriptPubKey" is the hash of a lisp program, and when you
create a new coin, the "scriptPubKey" of the newly generated coin is
also the output of a lisp program. So writing a quine gets you general
recursive covenants in a pretty straight forward way, as I understand it.
Usually you don't quite write a quine because you can be passed in your own code and assert your own id derived from it, but that's the basic idea. You need to validate your own id anyway when you have a capability.
Rather than a "transaction" containing "inputs/outputs", chia has spend
bundles that spend and create coins; and spend bundles can be merged
together, so that a block only has a single spend bundle. That spend
bundle joins all the puzzles (the programs that, when hashed match
the scriptPubKey) and solutions (scriptSigs) for the coins being spent
together.
I often refer to spend bundles as 'transactions'. Hope that isn't too confusing. They serve the same function in the mempool.
I /think/ the compression hook would be to allow you to have the puzzles
be (re)generated via another lisp program if that was more efficient
than just listing them out.
It literally has a lisp program called the generator which returns the list of puzzle reveals and transactions. The simplest version of that program is to return a quoted list.