Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 306EFC000B for ; Wed, 9 Mar 2022 02:55:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 17B9660615 for ; Wed, 9 Mar 2022 02:55:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=chia.net Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czG2ulGscd8F for ; Wed, 9 Mar 2022 02:55:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by smtp3.osuosl.org (Postfix) with ESMTPS id 7F381606FF for ; Wed, 9 Mar 2022 02:55:10 +0000 (UTC) Received: by mail-lf1-x134.google.com with SMTP id w12so1339157lfr.9 for ; Tue, 08 Mar 2022 18:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZwvfbYp5/bXw/IKWx/2OJrgZJiyp7BV8pFEP1BHX1Es=; b=IsUJiyDBb9HoJkQ3Fb91Q5uBrSk5dq35PJrvKyY8tN/z6FWuWyW/wrvRsRMXnVumAU b6Ymya2ojGIsY/CscH0DU16EgjqT/FfyaP2WFUBA/NyqfDmjWO2R3j0QZTrQprbBAEOH Em0F9SDYellnisYVXn1TDsGAAI/9oiXwk+4A/911HDMUE35HqDCPn3WsIJ46dgEvM2lE /1MHnX9K9GR5bUUwWHEmsUuG7afDS3tgB5Au7d6K/B9pVideKWMwcfEBP1UzV/vCh/fF 6yI1cb7HfoxR+rdXIOGUtjtCL3XrilrENmxh2HqSRUHxG5Knq/xvgJIXMoNbb0t7Bwdj aPZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZwvfbYp5/bXw/IKWx/2OJrgZJiyp7BV8pFEP1BHX1Es=; b=gWXQObk2H607CqfpGYaklXfJXqyXIsznSEtT7pypOhPLpRV2mz1uvY0imU+g8VJD4+ Sr0hpl20Pd0NLqA73hFD0Zm3I9HiUlk1FhjY9XH0EpmJXVQhY5yeCzranxviYyNve5ik qQlsWObvSYn3+G7ja5xa5obiuQKFbqyH7vuTyEibIog0iPqGjQGfDpMCpglVRYguVGNe kptylSZkZc8g5altqkGObiz4kyt9JsFK1EbnoeyNdXoFtZqmu8sS0t1I8TRsn+naP72n Gw9dWuX+WOg+TwPI11y0Xj2cpWG1egu7j14JXlWs59m4HhRWlS/9VQL8bcUAbNtErOcM Fusg== X-Gm-Message-State: AOAM533XT763sxve1xWS8chlzy/cYwjTFi4X+CjAWVwTNQnjgz7HMWiv tOIS5d0IH+KWjOPdsZX2TmIwOa2EBmjp1t3nJffhjw== X-Google-Smtp-Source: ABdhPJy476MjKFCC7FUHb+STUqyrXtqjTX2nXSrNYgoHdvTIjtzfNBJzROzx7iC7ZyrwGsn2ezXF5E9Fc2IKpnSRLLM= X-Received: by 2002:ac2:410d:0:b0:443:7f40:47a8 with SMTP id b13-20020ac2410d000000b004437f4047a8mr12459309lfi.228.1646794508006; Tue, 08 Mar 2022 18:55:08 -0800 (PST) MIME-Version: 1.0 References: <20220308012719.GA6992@erisian.com.au> In-Reply-To: <20220308012719.GA6992@erisian.com.au> From: Bram Cohen Date: Tue, 8 Mar 2022 18:54:56 -0800 Message-ID: To: Anthony Towns Content-Type: multipart/alternative; boundary="000000000000ab0a3b05d9c0398b" X-Mailman-Approved-At: Wed, 09 Mar 2022 13:10:51 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] bitcoin scripting and lisp X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2022 02:55:12 -0000 --000000000000ab0a3b05d9c0398b Content-Type: text/plain; charset="UTF-8" On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns wrote: > 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. --000000000000ab0a3b05d9c0398b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Mar 7, 2022 at 5:27 PM Anthony To= wns <aj@erisian.com.au> wrot= e:
One way to match the way bitcoin do things, you could have th= e "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 i= n transactions. I think the only thing missing is the assertion about one&#= 39;s own id, which could be added in by, in addition to passing the scriptp= ubkey the transaction it's part of, also passing in the index of inputs= which it itself is.
=C2=A0

> If you're doing everything from scratch it's cleaner to go wit= h the coin
> set model, but retrofitting onto existing Bitcoin it may be best to le= ave
> the UTXO model intact and compensate by adding a bunch more opcodes wh= ich
> are special to parsing Bitcoin transactions. The transaction format it= self
> can be mostly left alone but to enable some of the extra tricks (mostl= y
> implementing capabilities) it's probably a good idea to make new > conventions for how a transaction can have advisory information which<= br> > specifies which of the inputs to a transaction is the parent of a spec= ific
> 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 create= d -- 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 f= undamental trick, sort of the ollie of UTXO programming, where to make a co= in 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 b= y 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 ove= r UTXO is that it reduces the amount of stuff to be revealed and string man= gling involved in the parentage check.
=C2=A0

(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 m= onotonic and so the costs and fees are known up front. The only way two tra= nsactions can conflict with each other is if they both try to spend the sam= e coin.
=C2=A0
> They're radically different approaches and
> it's hard to see how they mix. Everything in lisp is completely sa= ndboxed,
> and that functionality is important to a lot of things, and it's r= eally
> normal to be given a reveal of a scriptpubkey and be able to rely on y= our
> 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 scri= pt type would also be my preferred approach.
=C2=A0
> A nice side benefit of stick= ing with the UTXO model is that the soft fork
> hook can be that all unknown opcodes make the entire thing automatical= ly
> 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)?

Thi= s 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 previous= ly unrecognized opcodes until after they've been soft forked into havin= g real functionality, and if you do that and accidentally write an anyoneca= nspend that's your own fault.
=C2=A0
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 tha= t 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 transact= ions together to make a single larger transaction and make it have enough o= f a fee to replace the smaller one.

I'm pretty skeptical about having a da= tabase 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.
=C2=A0
In chia the "scriptPubKey" is the h= ash 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 quin= e 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 a= nyway when you have a capability.
=C2=A0
Rather than a "transaction" cont= aining "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 bundle= s as 'transactions'. Hope that isn't too confusing. They serve = the same function in the mempool.
=C2=A0

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 ha= s a lisp program called the generator which returns the list of puzzle reve= als and transactions. The simplest version of that program is to return a q= uoted list.
--000000000000ab0a3b05d9c0398b--