Delivery-date: Tue, 11 Mar 2025 22:59:48 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193;
Date: Wed, 12 Mar 2025 13:48:13 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Nadav Ivgi <nadav@shesek.info>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Message-ID: <Z9ED_dez7_UHxjK0@erisian.com.au>
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
 <CAGXD5f3EGyUVBc=bDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <CAGXD5f3EGyUVBc=bDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q@mail.gmail.com>
X-Spam_score: 0.1
X-Spam_bar: /
X-Original-Sender: aj@erisian.com.au
X-Original-Authentication-Results: gmr-mx.google.com;       spf=pass
 (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as
 permitted sender) smtp.mailfrom=aj@erisian.com.au
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)

On Mon, Mar 10, 2025 at 07:14:30AM +0200, Nadav Ivgi wrote:
> For some historical context, it's interesting to note that CTV originally
> had the constexpr requirement which prevented your CSFS+CTV construct by
> requiring the CTV hash to come from a literal push preceding the opcode
> (i.e. not dynamically computed/pre-verified and not from the witness). This
> was eventually removed because it was deemed an unnecessary safeguard and
> to simplify the implementation.

I think the original COSHV implementation had the hash appear a push *after*
the CTV opcode.
https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki

> Also, it seems that APO alone also enables the same kind of construct as
> what you're describing. For example, a 'recursive' APO signature spending
> back to the same address could similarly be used as the basis for a BMM
> Spacechain.

With either APO or CTV alone you can do an arbitrarily long chain of commitments
(with APO|SINGLE allowing you to add an input/output for fees and change when
using those commitments), adding CSFS and discarding the CSFS private key allows
you to have a single commitment that can be reused indefinitely.

> Here's my go at it using Minsc:
> https://min.sc/v0.3/#gist=3aa538b384d3aaf4282d1acaf943f608

Nice!

> Note however that what you described is creating 0-fee transactions, with
> no way to attach additional fees.

Yes; I don't think you can do a good job of that on mutinynet with just
CTV/CSFS, since I don't think 0-value anchor outputs are supported. (You
could have CTV commit to two inputs, with the second input's entire
value being burnt to fees, but that's fairly annoying)

Cheers,
aj

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z9ED_dez7_UHxjK0%40erisian.com.au.