"Recursive covenant" with CTV and CSFS

"Recursive covenant" with CTV and CSFS
2025-03-05  6:14 ` Olaoluwa Osuntokun
                   ` (2 more replies)
  
From: Anthony Towns @ 2025-03-05  0:01 UTC (permalink / raw)
  To: bitcoindev

Hello world,

Some people on twitter are apparently proposing the near-term activation of
CTV and CSFS (BIP 119 and BIP 348 respectively), eg:

 https://x.com/JeremyRubin/status/1895676912401252588
 https://x.com/lopp/status/1895837290209161358
 https://x.com/stevenroose3/status/1895881757288996914
 https://x.com/reardencode/status/1871343039123452340
 https://x.com/sethforprivacy/status/1895814836535378055

Since BIP 119's motivation is entirely concerned with its concept of
covenants and avoiding what it calls recursive covenants, I think it
is interesting to note that the combination of CSFS and CTV trivially
enables the construction of a "recursive covenant" as BIP 119 uses those
terms. One approach is as follows:

 * Make a throwaway BIP340 private key X with 32-bit public key P.
 * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
   its corresponding scriptPubKey K when combined with P as the internal public
   key.
 * Calculate the CTV hash corresponding to a payment of some specific value V
   to K; call this hash H
 * Calculate the BIP 340 signature for message H with private key X, call it S.
 * Discard the private key X
 * Funds sent to K can only be spent by the witness data "<H> <S>" that forwards
   an amount V straight back to K.

Here's a demonstration on mutinynet:

 https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58

I'd encourage people to try implementing that themselves with their
preferred tooling; personally, I found it pretty inconvenient, which I
don't think is a good indication of ecosystem readiness wrt deployment.
(For me, the two components that are annoying is doing complicated
taproot script path spends, and calculating CTV hashes)

I don't believe the existence of a construction like this poses any
problems in practice, however if there is going to be a push to activate
BIP 119 in parallel with features that directly undermine its claimed
motivation, then it would presumably be sensible to at least update
the BIP text to describe a motivation that would actually be achieved by
deployment.

Personally, I think BIP 119's motivation remains very misguided:

 - the things it describes are, in general, not "covenants" [0]
 - the thing it avoids is not "recursion" but unbounded recursion
 - avoiding unbounded recursion is not very interesting when arbitrarily
   large recursion is still possible [1]
 - despite claiming that "covenants have historically been widely
   considering to be unfit for Bitcoin", no evidence for this claim has
   been able to be provided [2,3]
 - the opposition to unbounded recursion seems to me to either mostly
   or entirely be misplaced fear of things that are already possible in
   bitcoin and easily avoided by people who want to avoid it, eg [4]

so, at least personally, I think almost any update to BIP 119's motivation
section would be an improvement...

[0] https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
[1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/
[2] https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/
[3] https://x.com/Ethan_Heilman/status/1194624166093369345
[4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/

Beyond being a toy example of a conflict with BIP 119's motivation
section, I think the above script could be useful in the context of the
"blind-merged-mining" component of spacechains [5]. For example, if
the commitment was to two outputs, one the recursive step and the other
being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
would allow for both providing fees conveniently and for encoding the
spacechain block's commitment; competing spacechain miners would then
just be rbf'ing that spend with the parent spacechain update remaining
unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
need to be used to ensure the "one spacechain update per bitcoin block"
rule. (I believe mutinynet doesn't support ephemeral anchors however, so
I don't think there's anywhere this can be tested)

[5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg

(For a spacechain, miners would want to be confident that the private key
has been discarded. This confidence could be enhanced by creating X as a
musig2 key by a federation, in which case provided any of the private keys
used in generating X were correctly discarded, then everything is fine,
but that's still a trust assumption. Simple introspection opcodes would
work far better for this use case, both removing the trust assumption
and reducing the onchain data required)

If you're providing CTV and CSFS anyway, I don't see why you wouldn't
provide the same or similar functionality via a SIGHASH flag so that you
can avoid specifying the hash directly when you're signing it anyway,
giving an ANYPREVOUT/NOINPUT-like feature directly.

(Likewise, I don't see why you'd want to activate CAT on mainnet without
also at least re-enabling SUBSTR, and potentially also the redundant
LEFT and RIGHT operations)

For comparison, bllsh [6,7] takes the approach of providing
"bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
equivalent would then either involve simplying writing:

   (= (bip342_txmsg 3) 0x.....)

meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,
then evaluate whether the result is exactly equal to this constant"
providing one of the standard sighashes worked for your use case, or
replacing the bip342_txmsg opcode with a custom calculation of the tx
hash, along the lines of the example reimplementation of bip342_txmsg
for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
someone wants to write up the BIP 119 hashing formula in bllsh, I'd
be happy to include that as an example; I think it should be a pretty
straightforward conversion from the test-tx example.

If bllsh were live today (eg on either signet or mainnet), and it were
desired to softfork in a more optimised implementation of either CTV or
ANYPREVOUT to replace people coding their own implementation in bllsh
directly, both would simply involve replacing calls to "bip342_txmsg"
with calls to a new hash calculation opcode. For CTV behaviour, usage
would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
is, the underlying "I want to hash a message in such-and-such a way"
looks the same, and how it's used is the wallet author's decision,
not a matter of how the consensus code is written.

I believe simplicity/simfony can be thought of in much the same way;
with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
[9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
behaviour [10].

[6] https://github.com/ajtowns/bllsh/
[7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
[8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
[9] https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
[10] https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf

For me, the bllsh/simplicity approach makes more sense as a design
approach for the long term, and the ongoing lack of examples of killer
apps demonstrating big wins from limited slices of new functionality
leaves me completely unexcited about rushing something in the short term.
Having a flood of use cases that don't work out when looked into isn't
a good replacement for a single compelling use case that does.

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/Z8eUQCfCWjdivIzn%40erisian.com.au.


 permalink raw reply	[|nested]
2025-03-05  6:14 ` 
                   ` 
  
From: Anthony Towns @ 2025-03-05  0:01 UTC (permalink / raw)
  To: bitcoindev

Hello world,

Some people on twitter are apparently proposing the near-term activation of
CTV and CSFS (BIP 119 and BIP 348 respectively), eg:

 https://x.com/JeremyRubin/status/1895676912401252588
 https://x.com/lopp/status/1895837290209161358
 https://x.com/stevenroose3/status/1895881757288996914
 https://x.com/reardencode/status/1871343039123452340
 https://x.com/sethforprivacy/status/1895814836535378055

Since BIP 119's motivation is entirely concerned with its concept of
covenants and avoiding what it calls recursive covenants, I think it
is interesting to note that the combination of CSFS and CTV trivially
enables the construction of a "recursive covenant" as BIP 119 uses those
terms. One approach is as follows:

 * Make a throwaway BIP340 private key X with 32-bit public key P.
 * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
   its corresponding scriptPubKey K when combined with P as the internal public
   key.
 * Calculate the CTV hash corresponding to a payment of some specific value V
   to K; call this hash H
 * Calculate the BIP 340 signature for message H with private key X, call it S.
 * Discard the private key X
 * Funds sent to K can only be spent by the witness data "<H> <S>" that forwards
   an amount V straight back to K.

Here's a demonstration on mutinynet:

 https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58

I'd encourage people to try implementing that themselves with their
preferred tooling; personally, I found it pretty inconvenient, which I
don't think is a good indication of ecosystem readiness wrt deployment.
(For me, the two components that are annoying is doing complicated
taproot script path spends, and calculating CTV hashes)

I don't believe the existence of a construction like this poses any
problems in practice, however if there is going to be a push to activate
BIP 119 in parallel with features that directly undermine its claimed
motivation, then it would presumably be sensible to at least update
the BIP text to describe a motivation that would actually be achieved by
deployment.

Personally, I think BIP 119's motivation remains very misguided:

 - the things it describes are, in general, not "covenants" [0]
 - the thing it avoids is not "recursion" but unbounded recursion
 - avoiding unbounded recursion is not very interesting when arbitrarily
   large recursion is still possible [1]
 - despite claiming that "covenants have historically been widely
   considering to be unfit for Bitcoin", no evidence for this claim has
   been able to be provided [2,3]
 - the opposition to unbounded recursion seems to me to either mostly
   or entirely be misplaced fear of things that are already possible in
   bitcoin and easily avoided by people who want to avoid it, eg [4]

so, at least personally, I think almost any update to BIP 119's motivation
section would be an improvement...

[0] https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
[1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/
[2] https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/
[3] https://x.com/Ethan_Heilman/status/1194624166093369345
[4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/

Beyond being a toy example of a conflict with BIP 119's motivation
section, I think the above script could be useful in the context of the
"blind-merged-mining" component of spacechains [5]. For example, if
the commitment was to two outputs, one the recursive step and the other
being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
would allow for both providing fees conveniently and for encoding the
spacechain block's commitment; competing spacechain miners would then
just be rbf'ing that spend with the parent spacechain update remaining
unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
need to be used to ensure the "one spacechain update per bitcoin block"
rule. (I believe mutinynet doesn't support ephemeral anchors however, so
I don't think there's anywhere this can be tested)

[5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg

(For a spacechain, miners would want to be confident that the private key
has been discarded. This confidence could be enhanced by creating X as a
musig2 key by a federation, in which case provided any of the private keys
used in generating X were correctly discarded, then everything is fine,
but that's still a trust assumption. Simple introspection opcodes would
work far better for this use case, both removing the trust assumption
and reducing the onchain data required)

If you're providing CTV and CSFS anyway, I don't see why you wouldn't
provide the same or similar functionality via a SIGHASH flag so that you
can avoid specifying the hash directly when you're signing it anyway,
giving an ANYPREVOUT/NOINPUT-like feature directly.

(Likewise, I don't see why you'd want to activate CAT on mainnet without
also at least re-enabling SUBSTR, and potentially also the redundant
LEFT and RIGHT operations)

For comparison, bllsh [6,7] takes the approach of providing
"bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
equivalent would then either involve simplying writing:

   (= (bip342_txmsg 3) 0x.....)

meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,
then evaluate whether the result is exactly equal to this constant"
providing one of the standard sighashes worked for your use case, or
replacing the bip342_txmsg opcode with a custom calculation of the tx
hash, along the lines of the example reimplementation of bip342_txmsg
for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
someone wants to write up the BIP 119 hashing formula in bllsh, I'd
be happy to include that as an example; I think it should be a pretty
straightforward conversion from the test-tx example.

If bllsh were live today (eg on either signet or mainnet), and it were
desired to softfork in a more optimised implementation of either CTV or
ANYPREVOUT to replace people coding their own implementation in bllsh
directly, both would simply involve replacing calls to "bip342_txmsg"
with calls to a new hash calculation opcode. For CTV behaviour, usage
would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
is, the underlying "I want to hash a message in such-and-such a way"
looks the same, and how it's used is the wallet author's decision,
not a matter of how the consensus code is written.

I believe simplicity/simfony can be thought of in much the same way;
with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
[9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
behaviour [10].

[6] https://github.com/ajtowns/bllsh/
[7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
[8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
[9] https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
[10] https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf

For me, the bllsh/simplicity approach makes more sense as a design
approach for the long term, and the ongoing lack of examples of killer
apps demonstrating big wins from limited slices of new functionality
leaves me completely unexcited about rushing something in the short term.
Having a flood of use cases that don't work out when looked into isn't
a good replacement for a single compelling use case that does.

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/Z8eUQCfCWjdivIzn%40erisian.com.au.


 permalink raw reply	[|nested]
2025-03-05  6:14 ` Olaoluwa Osuntokun

  2025-03-06 17:17     ` Greg Sanders
  2025-03-07 21:01   ` Anthony Towns
  
From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2025-03-05 16:14 UTC (permalink / raw)
  To: Olaoluwa Osuntokun;  Anthony Towns, bitcoindev

[-- Attachment #1: Type: text/plain, Size: 13368 bytes --]

Hi,

Just picking on one thing Laolu said:

> The current Overton Window appears to be focused on a small (LoC wise) package to enable a greater degree of permissionless innovation on Bitcoin

For what it's worth i'm not sure this is the correct focus. Bitcoin Script is so notoriously unpredictable and hard to reason about that most of what matters is outside of the lines of code changed. Of course it depends on the specifics, but rewriting a clean interpreter that we can actually reason about does not strike me as a necessarily riskier approach than "just changing a few lines of code" in an interpreter that hardly anyone knows how it really behaves in all cases.

Antoine

On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <laolu32@gmail•com> wrote:

> Hi AJ,
>
> First a standard disclaimer: the contents of this email shouldn't be
> interpreted as an endorsement of one covenants proposal over another.
>
>> Since BIP 119's motivation is entirely concerned with its concept of
>> covenants and avoiding what it calls recursive covenants
>
> If we look at the motivation section of BIP 119, we find this sentence:
>
>> This BIP introduces a simple covenant called a *template* which enables a
>> limited set of highly valuable use cases without significant risk. BIP-119
>> templates allow for non-recursive fully-enumerated covenants with no
>> dynamic state.
>
> You appear to have latched onto the "non-recursive" aspect, ignoring the
> subsequent qualifiers of "fully-enumerated" and "with no dynamic state".
>
> The example that you've come up with to "directly undermine" the claimed
> motivations of BIP 119 is still fully enumerated (the sole state is declared
> up front), and doesn't contain dynamic state (I can't spend the contract on
> chain and do something like swap in another hash H, or signature S).
>
>> I found it pretty inconvenient, which I don't think is a good indication
>> of ecosystem readiness wrt deployment. (For me, the two components that
>> are annoying is doing complicated taproot script path spends, and
>> calculating CTV hashes)
>
> What language/libraries did you use to produce the spend? In my own
> development tooling of choice, producing complicated taproot script path
> spends is pretty straight forward, so perhaps the inconvenience you ran into
> says more about your dev tooling than the ecosystem readiness.
>
> It's also worth pointing out that your example relies on private key
> deletion, which if deemed acceptable, can be used to emulate CTV as is today
> (though you can't create a self-referential loop that way afaict).
>
>> For me, the bllsh/simplicity approach makes more sense as a design
>> approach for the long term
>
> Simplicity certainly has some brilliant devs working on it, but after all
> these years it still seems to be struggling to exit research mode with some
> "killer apps" on Liquid.
>
> bllsh on the other hand is a very new (and cool!) project that has no
> development uptake beyond its creator. Given its nascent state, it seems
> rather premature to promote it as a long term solution.
>
> Both of them are effectively a complete rewrite of Script, so compared to
> some of the existing covenant proposals on the table (many of which have a
> small core code footprint in the interpreter), they represent a radically
> expanded scope (ecosystem changes, wallets, consensus code) and therefore
> additional risks. The current Overton Window appears to be focused on a
> small (LoC wise) package to enable a greater degree of permissionless
> innovation on Bitcoin, while leaving the research landscape open for more
> dramatic overhauls (bllsh/Simplicity) in the future.
>
> -- Laolu
>
> On Tue, Mar 4, 2025 at 5:06 PM Anthony Towns <aj@erisian•com.au> wrote:
>
>> Hello world,
>>
>> Some people on twitter are apparently proposing the near-term activation of
>> CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
>>
>> https://x.com/JeremyRubin/status/1895676912401252588
>> https://x.com/lopp/status/1895837290209161358
>> https://x.com/stevenroose3/status/1895881757288996914
>> https://x.com/reardencode/status/1871343039123452340
>> https://x.com/sethforprivacy/status/1895814836535378055
>>
>> Since BIP 119's motivation is entirely concerned with its concept of
>> covenants and avoiding what it calls recursive covenants, I think it
>> is interesting to note that the combination of CSFS and CTV trivially
>> enables the construction of a "recursive covenant" as BIP 119 uses those
>> terms. One approach is as follows:
>>
>> * Make a throwaway BIP340 private key X with 32-bit public key P.
>> * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
>> its corresponding scriptPubKey K when combined with P as the internal public
>> key.
>> * Calculate the CTV hash corresponding to a payment of some specific value V
>> to K; call this hash H
>> * Calculate the BIP 340 signature for message H with private key X, call it S.
>> * Discard the private key X
>> * Funds sent to K can only be spent by the witness data "<H> <S>" that forwards
>> an amount V straight back to K.
>>
>> Here's a demonstration on mutinynet:
>>
>> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
>>
>> I'd encourage people to try implementing that themselves with their
>> preferred tooling; personally, I found it pretty inconvenient, which I
>> don't think is a good indication of ecosystem readiness wrt deployment.
>> (For me, the two components that are annoying is doing complicated
>> taproot script path spends, and calculating CTV hashes)
>>
>> I don't believe the existence of a construction like this poses any
>> problems in practice, however if there is going to be a push to activate
>> BIP 119 in parallel with features that directly undermine its claimed
>> motivation, then it would presumably be sensible to at least update
>> the BIP text to describe a motivation that would actually be achieved by
>> deployment.
>>
>> Personally, I think BIP 119's motivation remains very misguided:
>>
>> - the things it describes are, in general, not "covenants" [0]
>> - the thing it avoids is not "recursion" but unbounded recursion
>> - avoiding unbounded recursion is not very interesting when arbitrarily
>> large recursion is still possible [1]
>> - despite claiming that "covenants have historically been widely
>> considering to be unfit for Bitcoin", no evidence for this claim has
>> been able to be provided [2,3]
>> - the opposition to unbounded recursion seems to me to either mostly
>> or entirely be misplaced fear of things that are already possible in
>> bitcoin and easily avoided by people who want to avoid it, eg [4]
>>
>> so, at least personally, I think almost any update to BIP 119's motivation
>> section would be an improvement...
>>
>> [0] https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
>> [1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/
>> [2] https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/
>> [3] https://x.com/Ethan_Heilman/status/1194624166093369345
>> [4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/
>>
>> Beyond being a toy example of a conflict with BIP 119's motivation
>> section, I think the above script could be useful in the context of the
>> "blind-merged-mining" component of spacechains [5]. For example, if
>> the commitment was to two outputs, one the recursive step and the other
>> being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
>> would allow for both providing fees conveniently and for encoding the
>> spacechain block's commitment; competing spacechain miners would then
>> just be rbf'ing that spend with the parent spacechain update remaining
>> unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
>> need to be used to ensure the "one spacechain update per bitcoin block"
>> rule. (I believe mutinynet doesn't support ephemeral anchors however, so
>> I don't think there's anywhere this can be tested)
>>
>> [5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
>>
>> (For a spacechain, miners would want to be confident that the private key
>> has been discarded. This confidence could be enhanced by creating X as a
>> musig2 key by a federation, in which case provided any of the private keys
>> used in generating X were correctly discarded, then everything is fine,
>> but that's still a trust assumption. Simple introspection opcodes would
>> work far better for this use case, both removing the trust assumption
>> and reducing the onchain data required)
>>
>> If you're providing CTV and CSFS anyway, I don't see why you wouldn't
>> provide the same or similar functionality via a SIGHASH flag so that you
>> can avoid specifying the hash directly when you're signing it anyway,
>> giving an ANYPREVOUT/NOINPUT-like feature directly.
>>
>> (Likewise, I don't see why you'd want to activate CAT on mainnet without
>> also at least re-enabling SUBSTR, and potentially also the redundant
>> LEFT and RIGHT operations)
>>
>> For comparison, bllsh [6,7] takes the approach of providing
>> "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
>> for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
>> equivalent would then either involve simplying writing:
>>
>> (= (bip342_txmsg 3) 0x.....)
>>
>> meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,
>> then evaluate whether the result is exactly equal to this constant"
>> providing one of the standard sighashes worked for your use case, or
>> replacing the bip342_txmsg opcode with a custom calculation of the tx
>> hash, along the lines of the example reimplementation of bip342_txmsg
>> for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
>> someone wants to write up the BIP 119 hashing formula in bllsh, I'd
>> be happy to include that as an example; I think it should be a pretty
>> straightforward conversion from the test-tx example.
>>
>> If bllsh were live today (eg on either signet or mainnet), and it were
>> desired to softfork in a more optimised implementation of either CTV or
>> ANYPREVOUT to replace people coding their own implementation in bllsh
>> directly, both would simply involve replacing calls to "bip342_txmsg"
>> with calls to a new hash calculation opcode. For CTV behaviour, usage
>> would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
>> usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
>> is, the underlying "I want to hash a message in such-and-such a way"
>> looks the same, and how it's used is the wallet author's decision,
>> not a matter of how the consensus code is written.
>>
>> I believe simplicity/simfony can be thought of in much the same way;
>> with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
>> [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
>> behaviour [10].
>>
>> [6] https://github.com/ajtowns/bllsh/
>> [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
>> [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
>> [9] https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
>> [10] https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
>>
>> For me, the bllsh/simplicity approach makes more sense as a design
>> approach for the long term, and the ongoing lack of examples of killer
>> apps demonstrating big wins from limited slices of new functionality
>> leaves me completely unexcited about rushing something in the short term.
>> Having a flood of use cases that don't work out when looked into isn't
>> a good replacement for a single compelling use case that does.
>>
>> 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](mailto:bitcoindev%2Bunsubscribe@googlegroups•com).
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au.
>
> --
> 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/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com.

-- 
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/1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo%3D%40protonmail.com.

[-- Attachment #2: Type: text/html, Size: 18275 bytes --]

 permalink raw reply	[|nested]
2025-03-05  0:01 [bitcoindev] "Recursive covenant" with CTV and CSFS Anthony Towns
  2025-03-05  6:14 ` Olaoluwa Osuntokun

  2025-03-05 22:46   ` Antoine Riard
  2025-03-10  5:14 ` Nadav Ivgi
  
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-03-05 17:53 UTC (permalink / raw)
  To: Anthony Towns;  bitcoindev

Hi AJ,

I don't even think about this "recursion" as an issue in itself anymore. The way CSFS enables "recursion" with deleted key covenants basically is useful for some things not so much for others. Useful for vaults, possibly somewhat useful for spacechains, pretty useless for tokens.

It's not even a really a meaningful distinction as you noted in general.

What's more interesting is "do these set of changes allow for 'native' fungible tokens you can _identify_ and interact with in script in a way that is enforced by consensus"? Can you build AMMs for them? For a lot of proposals currently discussed we actually know how to do that. Anything fully generic will trivially unlock this capability.

The two primitives involved are state carrying (amounts) and quining (aka recursion). These are the truly significant thresholds for changes that can possibly alter the nature of bitcoin and how people use it. Only one of them is not enough. Beyond these there remains the issue of novel trust minimized two way pegs to other chains like Ethereum which would also be in high demand, in fact probably prioritized in funding over all other things we are discussing in relation to covenants.

After all these years I'm confident that for LNhance (CTV+CSFS+IKEY+PC) the answer is NO.

BR,
moonsettler

On Wednesday, March 5th, 2025 at 1:01 AM, Anthony Towns <aj@erisian•com.au> wrote:

> Hello world,
> 
> Some people on twitter are apparently proposing the near-term activation of
> CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
> 
> https://x.com/JeremyRubin/status/1895676912401252588
> https://x.com/lopp/status/1895837290209161358
> https://x.com/stevenroose3/status/1895881757288996914
> https://x.com/reardencode/status/1871343039123452340
> https://x.com/sethforprivacy/status/1895814836535378055
> 
> Since BIP 119's motivation is entirely concerned with its concept of
> covenants and avoiding what it calls recursive covenants, I think it
> is interesting to note that the combination of CSFS and CTV trivially
> enables the construction of a "recursive covenant" as BIP 119 uses those
> terms. One approach is as follows:
> 
> * Make a throwaway BIP340 private key X with 32-bit public key P.
> * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
> 
> its corresponding scriptPubKey K when combined with P as the internal public
> key.
> * Calculate the CTV hash corresponding to a payment of some specific value V
> to K; call this hash H
> * Calculate the BIP 340 signature for message H with private key X, call it S.
> * Discard the private key X
> * Funds sent to K can only be spent by the witness data "<H> <S>" that forwards
> 
> an amount V straight back to K.
> 
> Here's a demonstration on mutinynet:
> 
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
> 
> I'd encourage people to try implementing that themselves with their
> preferred tooling; personally, I found it pretty inconvenient, which I
> don't think is a good indication of ecosystem readiness wrt deployment.
> (For me, the two components that are annoying is doing complicated
> taproot script path spends, and calculating CTV hashes)
> 
> I don't believe the existence of a construction like this poses any
> problems in practice, however if there is going to be a push to activate
> BIP 119 in parallel with features that directly undermine its claimed
> motivation, then it would presumably be sensible to at least update
> the BIP text to describe a motivation that would actually be achieved by
> deployment.
> 
> Personally, I think BIP 119's motivation remains very misguided:
> 
> - the things it describes are, in general, not "covenants" [0]
> - the thing it avoids is not "recursion" but unbounded recursion
> - avoiding unbounded recursion is not very interesting when arbitrarily
> large recursion is still possible [1]
> - despite claiming that "covenants have historically been widely
> considering to be unfit for Bitcoin", no evidence for this claim has
> been able to be provided [2,3]
> - the opposition to unbounded recursion seems to me to either mostly
> or entirely be misplaced fear of things that are already possible in
> bitcoin and easily avoided by people who want to avoid it, eg [4]
> 
> so, at least personally, I think almost any update to BIP 119's motivation
> section would be an improvement...
> 
> [0] https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
> [1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/
> [2] https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/
> [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> [4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/
> 
> Beyond being a toy example of a conflict with BIP 119's motivation
> section, I think the above script could be useful in the context of the
> "blind-merged-mining" component of spacechains [5]. For example, if
> the commitment was to two outputs, one the recursive step and the other
> being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
> would allow for both providing fees conveniently and for encoding the
> spacechain block's commitment; competing spacechain miners would then
> just be rbf'ing that spend with the parent spacechain update remaining
> unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
> need to be used to ensure the "one spacechain update per bitcoin block"
> rule. (I believe mutinynet doesn't support ephemeral anchors however, so
> I don't think there's anywhere this can be tested)
> 
> [5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
> 
> (For a spacechain, miners would want to be confident that the private key
> has been discarded. This confidence could be enhanced by creating X as a
> musig2 key by a federation, in which case provided any of the private keys
> used in generating X were correctly discarded, then everything is fine,
> but that's still a trust assumption. Simple introspection opcodes would
> work far better for this use case, both removing the trust assumption
> and reducing the onchain data required)
> 
> If you're providing CTV and CSFS anyway, I don't see why you wouldn't
> provide the same or similar functionality via a SIGHASH flag so that you
> can avoid specifying the hash directly when you're signing it anyway,
> giving an ANYPREVOUT/NOINPUT-like feature directly.
> 
> (Likewise, I don't see why you'd want to activate CAT on mainnet without
> also at least re-enabling SUBSTR, and potentially also the redundant
> LEFT and RIGHT operations)
> 
> For comparison, bllsh [6,7] takes the approach of providing
> "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
> for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
> equivalent would then either involve simplying writing:
> 
> (= (bip342_txmsg 3) 0x.....)
> 
> meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,
> then evaluate whether the result is exactly equal to this constant"
> providing one of the standard sighashes worked for your use case, or
> replacing the bip342_txmsg opcode with a custom calculation of the tx
> hash, along the lines of the example reimplementation of bip342_txmsg
> for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
> someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> be happy to include that as an example; I think it should be a pretty
> straightforward conversion from the test-tx example.
> 
> If bllsh were live today (eg on either signet or mainnet), and it were
> desired to softfork in a more optimised implementation of either CTV or
> ANYPREVOUT to replace people coding their own implementation in bllsh
> directly, both would simply involve replacing calls to "bip342_txmsg"
> with calls to a new hash calculation opcode. For CTV behaviour, usage
> would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
> usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
> is, the underlying "I want to hash a message in such-and-such a way"
> looks the same, and how it's used is the wallet author's decision,
> not a matter of how the consensus code is written.
> 
> I believe simplicity/simfony can be thought of in much the same way;
> with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
> [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
> behaviour [10].
> 
> [6] https://github.com/ajtowns/bllsh/
> [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> [9] https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
> [10] https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
> 
> For me, the bllsh/simplicity approach makes more sense as a design
> approach for the long term, and the ongoing lack of examples of killer
> apps demonstrating big wins from limited slices of new functionality
> leaves me completely unexcited about rushing something in the short term.
> Having a flood of use cases that don't work out when looked into isn't
> a good replacement for a single compelling use case that does.
> 
> 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/Z8eUQCfCWjdivIzn%40erisian.com.au.

-- 
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/A1uNlgzWNUB3L_ITCAGDB85UhNdcF4GX6zZhkaEFHPmLmQivzXnY7stFGtG8iR_8cmVCxiWklqO9VEN6SqDyO6fMEuN3gJDnDEOIN-60sDE%3D%40protonmail.com.


 permalink raw reply	[|nested]
2025-03-05 17:53 ` 'moonsettler' via Bitcoin Development Mailing List

  2025-03-07 21:16     ` Anthony Towns
  
From: Antoine Riard @ 2025-03-05 22:46 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 13955 bytes --]

Hi AJ,

> I don't believe the existence of a construction like this poses any 
> problems in practice, however if there is going to be a push to activate 
> BIP 119 in parallel with features that directly undermine its claimed 
> motivation, then it would presumably be sensible to at least update 
> the BIP text to describe a motivation that would actually be achieved by 
> deployment. 

I do...

https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark/
https://blog.bitmex.com/txwithhold-smart-contracts/

Terminology in the article is the following, as a reminder:
- target transaction: a tx to be withheld
- target tx: a fee, which a victim pays for the target tx inclusion
- attacker: an actor willing to withhold the target tx
- victim: a spender of the target tx
- reward transaction: a tx paying out a reward to the miner which withheld 
a target tx

With OP_CHECKSIGFROMSTACK, which is iirc <signature> <pubkey> <message>
as an input stack, one can have the <message> being an already spent 
transaction.

From then, one can build a TxWithhold for a LN commitment transaction, where
the <message> is the latest valid commitment transaction to spend a chan 
funding
output (each counterparty re-build the remote commitment tx for 
counter-signature
of the 2-of-2 P2WSH).

After that, one can build a script: 
<proof-of-target-UTXO-mining=commitment_tx"
OP_CSFS> OR <<bounty_timelock> <OP_CHECKLOCKTIMEVERIFY> 
<recursive_bounty_sig |
SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold attacker 
can
make the funding UTXO amount available as a "anyone-can-spend" and force a 
re-
commitment to the same tx-withholding script.

There is no hash dependency, as the "proof-of-target-UTXO-mining" is a hash 
given
as part of the input stack, be it for legacy spends or segwit spends.

One can have multiple script branches for all the versions of the commitment
transaction, at least the latest 2 no-penalty one.

The TxWithhold attacker can publish the script in an unrelated inscription
in the chain itself, to make the "bribing" TxWithhold contract available to
any miner anonymously wishing to engage in a TxWithhold to maximize its 
income
for given hashrate capabilities.

Bonus point: if you the reader can come with a construction to do a 
TxWithold on
the spend of any coinbase output, at least more than the delay of 
COINBASE_MATURITY=
100 blocks to get the `blockReward`.

Bonus Bonus point: if you the reader can come with a detailed protocol for 
all
the miners in a N retarget period to get a reward % share of a TxWithhold 
instance
weighted by their respective hashrate capabilities, by only using on-chain
inscriptions.

Best,
Antoine
OTS hash: 28d42f8caeedb4760f3a4ddb39adf5443edaf63741560e3cee264237c0c126b5

Le mercredi 5 mars 2025 à 18:16:02 UTC, moonsettler a écrit :

> Hi AJ,
>
> I don't even think about this "recursion" as an issue in itself anymore. 
> The way CSFS enables "recursion" with deleted key covenants basically is 
> useful for some things not so much for others. Useful for vaults, possibly 
> somewhat useful for spacechains, pretty useless for tokens.
>
> It's not even a really a meaningful distinction as you noted in general.
>
> What's more interesting is "do these set of changes allow for 'native' 
> fungible tokens you can _identify_ and interact with in script in a way 
> that is enforced by consensus"? Can you build AMMs for them? For a lot of 
> proposals currently discussed we actually know how to do that. Anything 
> fully generic will trivially unlock this capability.
>
> The two primitives involved are state carrying (amounts) and quining (aka 
> recursion). These are the truly significant thresholds for changes that can 
> possibly alter the nature of bitcoin and how people use it. Only one of 
> them is not enough. Beyond these there remains the issue of novel trust 
> minimized two way pegs to other chains like Ethereum which would also be in 
> high demand, in fact probably prioritized in funding over all other things 
> we are discussing in relation to covenants.
>
> After all these years I'm confident that for LNhance (CTV+CSFS+IKEY+PC) 
> the answer is NO.
>
> BR,
> moonsettler
>
> On Wednesday, March 5th, 2025 at 1:01 AM, Anthony Towns <
> a...@erisian•com.au> wrote:
>
> > Hello world,
> > 
> > Some people on twitter are apparently proposing the near-term activation 
> of
> > CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
> > 
> > https://x.com/JeremyRubin/status/1895676912401252588
> > https://x.com/lopp/status/1895837290209161358
> > https://x.com/stevenroose3/status/1895881757288996914
> > https://x.com/reardencode/status/1871343039123452340
> > https://x.com/sethforprivacy/status/1895814836535378055
> > 
> > Since BIP 119's motivation is entirely concerned with its concept of
> > covenants and avoiding what it calls recursive covenants, I think it
> > is interesting to note that the combination of CSFS and CTV trivially
> > enables the construction of a "recursive covenant" as BIP 119 uses those
> > terms. One approach is as follows:
> > 
> > * Make a throwaway BIP340 private key X with 32-bit public key P.
> > * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
> > 
> > its corresponding scriptPubKey K when combined with P as the internal 
> public
> > key.
> > * Calculate the CTV hash corresponding to a payment of some specific 
> value V
> > to K; call this hash H
> > * Calculate the BIP 340 signature for message H with private key X, call 
> it S.
> > * Discard the private key X
> > * Funds sent to K can only be spent by the witness data "<H> <S>" that 
> forwards
> > 
> > an amount V straight back to K.
> > 
> > Here's a demonstration on mutinynet:
> > 
> > 
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
> > 
> > I'd encourage people to try implementing that themselves with their
> > preferred tooling; personally, I found it pretty inconvenient, which I
> > don't think is a good indication of ecosystem readiness wrt deployment.
> > (For me, the two components that are annoying is doing complicated
> > taproot script path spends, and calculating CTV hashes)
> > 
> > I don't believe the existence of a construction like this poses any
> > problems in practice, however if there is going to be a push to activate
> > BIP 119 in parallel with features that directly undermine its claimed
> > motivation, then it would presumably be sensible to at least update
> > the BIP text to describe a motivation that would actually be achieved by
> > deployment.
> > 
> > Personally, I think BIP 119's motivation remains very misguided:
> > 
> > - the things it describes are, in general, not "covenants" [0]
> > - the thing it avoids is not "recursion" but unbounded recursion
> > - avoiding unbounded recursion is not very interesting when arbitrarily
> > large recursion is still possible [1]
> > - despite claiming that "covenants have historically been widely
> > considering to be unfit for Bitcoin", no evidence for this claim has
> > been able to be provided [2,3]
> > - the opposition to unbounded recursion seems to me to either mostly
> > or entirely be misplaced fear of things that are already possible in
> > bitcoin and easily avoided by people who want to avoid it, eg [4]
> > 
> > so, at least personally, I think almost any update to BIP 119's 
> motivation
> > section would be an improvement...
> > 
> > [0] https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/ 
> <https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/>
> > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/ 
> <https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/>
> > [2] 
> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.amazonses.com/ 
> <https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/>
> > [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> > [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/ 
> <https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/>
> > 
> > Beyond being a toy example of a conflict with BIP 119's motivation
> > section, I think the above script could be useful in the context of the
> > "blind-merged-mining" component of spacechains [5]. For example, if
> > the commitment was to two outputs, one the recursive step and the other
> > being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
> > would allow for both providing fees conveniently and for encoding the
> > spacechain block's commitment; competing spacechain miners would then
> > just be rbf'ing that spend with the parent spacechain update remaining
> > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
> > need to be used to ensure the "one spacechain update per bitcoin block"
> > rule. (I believe mutinynet doesn't support ephemeral anchors however, so
> > I don't think there's anywhere this can be tested)
> > 
> > [5] 
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
> > 
> > (For a spacechain, miners would want to be confident that the private key
> > has been discarded. This confidence could be enhanced by creating X as a
> > musig2 key by a federation, in which case provided any of the private 
> keys
> > used in generating X were correctly discarded, then everything is fine,
> > but that's still a trust assumption. Simple introspection opcodes would
> > work far better for this use case, both removing the trust assumption
> > and reducing the onchain data required)
> > 
> > If you're providing CTV and CSFS anyway, I don't see why you wouldn't
> > provide the same or similar functionality via a SIGHASH flag so that you
> > can avoid specifying the hash directly when you're signing it anyway,
> > giving an ANYPREVOUT/NOINPUT-like feature directly.
> > 
> > (Likewise, I don't see why you'd want to activate CAT on mainnet without
> > also at least re-enabling SUBSTR, and potentially also the redundant
> > LEFT and RIGHT operations)
> > 
> > For comparison, bllsh [6,7] takes the approach of providing
> > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
> > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
> > equivalent would then either involve simplying writing:
> > 
> > (= (bip342_txmsg 3) 0x.....)
> > 
> > meaining "calculate the message hash of the current tx for 
> SIGHASH_SINGLE,
> > then evaluate whether the result is exactly equal to this constant"
> > providing one of the standard sighashes worked for your use case, or
> > replacing the bip342_txmsg opcode with a custom calculation of the tx
> > hash, along the lines of the example reimplementation of bip342_txmsg
> > for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
> > someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> > be happy to include that as an example; I think it should be a pretty
> > straightforward conversion from the test-tx example.
> > 
> > If bllsh were live today (eg on either signet or mainnet), and it were
> > desired to softfork in a more optimised implementation of either CTV or
> > ANYPREVOUT to replace people coding their own implementation in bllsh
> > directly, both would simply involve replacing calls to "bip342_txmsg"
> > with calls to a new hash calculation opcode. For CTV behaviour, usage
> > would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
> > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
> > is, the underlying "I want to hash a message in such-and-such a way"
> > looks the same, and how it's used is the wallet author's decision,
> > not a matter of how the consensus code is written.
> > 
> > I believe simplicity/simfony can be thought of in much the same way;
> > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
> > [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
> > behaviour [10].
> > 
> > [6] https://github.com/ajtowns/bllsh/
> > [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> > [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> > [9] 
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
> > [10] 
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
> > 
> > For me, the bllsh/simplicity approach makes more sense as a design
> > approach for the long term, and the ongoing lack of examples of killer
> > apps demonstrating big wins from limited slices of new functionality
> > leaves me completely unexcited about rushing something in the short term.
> > Having a flood of use cases that don't work out when looked into isn't
> > a good replacement for a single compelling use case that does.
> > 
> > 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+...@googlegroups•com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au
> .
>

-- 
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/6a9d4eea-51bd-45d8-b839-4ac3cefdbb7en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 21291 bytes --]

 permalink raw reply	[|nested]
2025-03-05 16:14   ` 'Antoine Poinsot' via Bitcoin Development Mailing List

  2025-03-06 18:36       ` 'moonsettler' via Bitcoin Development Mailing List
  2025-03-07 21:36       ` Anthony Towns
  
From: Greg Sanders @ 2025-03-06 17:17 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 14528 bytes --]

> Of course it depends on the specifics, but rewriting a clean interpreter 
that we can actually reason about does not strike me as a necessarily 
riskier approach than "just changing a few lines of code" in an interpreter 
that hardly anyone knows how it really behaves in all cases.

It's certainly something to consider when weighing further off Bitcoin 
Script updates: From here is something like "Great Script Restoration" ever 
the right choice vs a from scratch overhaul? I am less persuaded that 
consensus risk is particularly high for very narrowly scoped changes, 
ignoring the "fixed" costs of changing consensus, maintenance burden, MEVil 
risks, etc. The risk-reward ratio may be suboptimal of course.

Greg
On Wednesday, March 5, 2025 at 11:39:27 AM UTC-5 Antoine Poinsot wrote:

> Hi,
>
> Just picking on one thing Laolu said:
>
> The current Overton Window appears to be focused on a small (LoC wise) 
> package to enable a greater degree of permissionless innovation on Bitcoin
>
>
> For what it's worth i'm not sure this is the correct focus. Bitcoin Script 
> is so notoriously unpredictable and hard to reason about that most of what 
> matters is outside of the lines of code changed. Of course it depends on 
> the specifics, but rewriting a clean interpreter that we can actually 
> reason about does not strike me as a necessarily riskier approach than 
> "just changing a few lines of code" in an interpreter that hardly anyone 
> knows how it really behaves in all cases.
>
> Antoine
> On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <
> lao...@gmail•com> wrote:
>
> Hi AJ,
>
> First a standard disclaimer: the contents of this email shouldn't be
> interpreted as an endorsement of one covenants proposal over another.
>
> > Since BIP 119's motivation is entirely concerned with its concept of
> > covenants and avoiding what it calls recursive covenants
>
> If we look at the motivation section of BIP 119, we find this sentence: 
>
> > This BIP introduces a simple covenant called a *template* which enables a
> > limited set of highly valuable use cases without significant risk. 
> BIP-119
> > templates allow for non-recursive fully-enumerated covenants with no
> > dynamic state. 
>
> You appear to have latched onto the "non-recursive" aspect, ignoring the
> subsequent qualifiers of "fully-enumerated" and "with no dynamic state".
>
> The example that you've come up with to "directly undermine" the claimed
> motivations of BIP 119 is still fully enumerated (the sole state is 
> declared
> up front), and doesn't contain dynamic state (I can't spend the contract on
> chain and do something like swap in another hash H, or signature S).
>
> > I found it pretty inconvenient, which I don't think is a good indication
> > of ecosystem readiness wrt deployment. (For me, the two components that
> > are annoying is doing complicated taproot script path spends, and
> > calculating CTV hashes)
>
> What language/libraries did you use to produce the spend? In my own
> development tooling of choice, producing complicated taproot script path
> spends is pretty straight forward, so perhaps the inconvenience you ran 
> into
> says more about your dev tooling than the ecosystem readiness.
>
> It's also worth pointing out that your example relies on private key
> deletion, which if deemed acceptable, can be used to emulate CTV as is 
> today
> (though you can't create a self-referential loop that way afaict).
>
> > For me, the bllsh/simplicity approach makes more sense as a design
> > approach for the long term
>
> Simplicity certainly has some brilliant devs working on it, but after all
> these years it still seems to be struggling to exit research mode with some
> "killer apps" on Liquid.
>
> bllsh on the other hand is a very new (and cool!) project that has no
> development uptake beyond its creator. Given its nascent state, it seems
> rather premature to promote it as a long term solution.
>
> Both of them are effectively a complete rewrite of Script, so compared to
> some of the existing covenant proposals on the table (many of which have a
> small core code footprint in the interpreter), they represent a radically
> expanded scope (ecosystem changes, wallets, consensus code) and therefore
> additional risks. The current Overton Window appears to be focused on a
> small (LoC wise) package to enable a greater degree of permissionless
> innovation on Bitcoin, while leaving the research landscape open for more
> dramatic overhauls (bllsh/Simplicity) in the future.
>
> -- Laolu
>
>
> On Tue, Mar 4, 2025 at 5:06 PM Anthony Towns <a...@erisian•com.au> wrote:
>
>> Hello world,
>>
>> Some people on twitter are apparently proposing the near-term activation 
>> of
>> CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
>>
>> https://x.com/JeremyRubin/status/1895676912401252588
>> https://x.com/lopp/status/1895837290209161358
>> https://x.com/stevenroose3/status/1895881757288996914
>> https://x.com/reardencode/status/1871343039123452340
>> https://x.com/sethforprivacy/status/1895814836535378055
>>
>> Since BIP 119's motivation is entirely concerned with its concept of
>> covenants and avoiding what it calls recursive covenants, I think it
>> is interesting to note that the combination of CSFS and CTV trivially
>> enables the construction of a "recursive covenant" as BIP 119 uses those
>> terms. One approach is as follows:
>>
>> * Make a throwaway BIP340 private key X with 32-bit public key P.
>> * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
>> its corresponding scriptPubKey K when combined with P as the internal 
>> public
>> key.
>> * Calculate the CTV hash corresponding to a payment of some specific 
>> value V
>> to K; call this hash H
>> * Calculate the BIP 340 signature for message H with private key X, call 
>> it S.
>> * Discard the private key X
>> * Funds sent to K can only be spent by the witness data "<H> <S>" that 
>> forwards
>> an amount V straight back to K.
>>
>> Here's a demonstration on mutinynet:
>>
>>
>> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
>>
>> I'd encourage people to try implementing that themselves with their
>> preferred tooling; personally, I found it pretty inconvenient, which I
>> don't think is a good indication of ecosystem readiness wrt deployment.
>> (For me, the two components that are annoying is doing complicated
>> taproot script path spends, and calculating CTV hashes)
>>
>> I don't believe the existence of a construction like this poses any
>> problems in practice, however if there is going to be a push to activate
>> BIP 119 in parallel with features that directly undermine its claimed
>> motivation, then it would presumably be sensible to at least update
>> the BIP text to describe a motivation that would actually be achieved by
>> deployment.
>>
>> Personally, I think BIP 119's motivation remains very misguided:
>>
>> - the things it describes are, in general, not "covenants" [0]
>> - the thing it avoids is not "recursion" but unbounded recursion
>> - avoiding unbounded recursion is not very interesting when arbitrarily
>> large recursion is still possible [1]
>> - despite claiming that "covenants have historically been widely
>> considering to be unfit for Bitcoin", no evidence for this claim has
>> been able to be provided [2,3]
>> - the opposition to unbounded recursion seems to me to either mostly
>> or entirely be misplaced fear of things that are already possible in
>> bitcoin and easily avoided by people who want to avoid it, eg [4]
>>
>> so, at least personally, I think almost any update to BIP 119's motivation
>> section would be an improvement...
>>
>> [0] https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/ 
>> <https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/>
>> [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/ 
>> <https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/>
>> [2] 
>> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.amazonses.com/ 
>> <https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/>
>> [3] https://x.com/Ethan_Heilman/status/1194624166093369345
>> [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/ 
>> <https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/>
>>
>> Beyond being a toy example of a conflict with BIP 119's motivation
>> section, I think the above script could be useful in the context of the
>> "blind-merged-mining" component of spacechains [5]. For example, if
>> the commitment was to two outputs, one the recursive step and the other
>> being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
>> would allow for both providing fees conveniently and for encoding the
>> spacechain block's commitment; competing spacechain miners would then
>> just be rbf'ing that spend with the parent spacechain update remaining
>> unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
>> need to be used to ensure the "one spacechain update per bitcoin block"
>> rule. (I believe mutinynet doesn't support ephemeral anchors however, so
>> I don't think there's anywhere this can be tested)
>>
>> [5] 
>> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
>>
>> (For a spacechain, miners would want to be confident that the private key
>> has been discarded. This confidence could be enhanced by creating X as a
>> musig2 key by a federation, in which case provided any of the private keys
>> used in generating X were correctly discarded, then everything is fine,
>> but that's still a trust assumption. Simple introspection opcodes would
>> work far better for this use case, both removing the trust assumption
>> and reducing the onchain data required)
>>
>> If you're providing CTV and CSFS anyway, I don't see why you wouldn't
>> provide the same or similar functionality via a SIGHASH flag so that you
>> can avoid specifying the hash directly when you're signing it anyway,
>> giving an ANYPREVOUT/NOINPUT-like feature directly.
>>
>> (Likewise, I don't see why you'd want to activate CAT on mainnet without
>> also at least re-enabling SUBSTR, and potentially also the redundant
>> LEFT and RIGHT operations)
>>
>> For comparison, bllsh [6,7] takes the approach of providing
>> "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
>> for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
>> equivalent would then either involve simplying writing:
>>
>> (= (bip342_txmsg 3) 0x.....)
>>
>> meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,
>> then evaluate whether the result is exactly equal to this constant"
>> providing one of the standard sighashes worked for your use case, or
>> replacing the bip342_txmsg opcode with a custom calculation of the tx
>> hash, along the lines of the example reimplementation of bip342_txmsg
>> for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
>> someone wants to write up the BIP 119 hashing formula in bllsh, I'd
>> be happy to include that as an example; I think it should be a pretty
>> straightforward conversion from the test-tx example.
>>
>> If bllsh were live today (eg on either signet or mainnet), and it were
>> desired to softfork in a more optimised implementation of either CTV or
>> ANYPREVOUT to replace people coding their own implementation in bllsh
>> directly, both would simply involve replacing calls to "bip342_txmsg"
>> with calls to a new hash calculation opcode. For CTV behaviour, usage
>> would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
>> usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
>> is, the underlying "I want to hash a message in such-and-such a way"
>> looks the same, and how it's used is the wallet author's decision,
>> not a matter of how the consensus code is written.
>>
>> I believe simplicity/simfony can be thought of in much the same way;
>> with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
>> [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
>> behaviour [10].
>>
>> [6] https://github.com/ajtowns/bllsh/
>> [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
>> [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
>> [9] 
>> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
>> [10] 
>> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
>>
>> For me, the bllsh/simplicity approach makes more sense as a design
>> approach for the long term, and the ongoing lack of examples of killer
>> apps demonstrating big wins from limited slices of new functionality
>> leaves me completely unexcited about rushing something in the short term.
>> Having a flood of use cases that don't work out when looked into isn't
>> a good replacement for a single compelling use case that does.
>>
>> 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+...@googlegroups•com.
>> To view this discussion visit 
>> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au
>> .
>>
> -- 
> 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+...@googlegroups•com.
>
> To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com
> .
>
>
>

-- 
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/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 23546 bytes --]

 permalink raw reply	[|nested]
2025-03-06 17:17     ` Greg Sanders

  2025-03-06 21:26         ` Antoine Riard
  2025-03-07 21:36       ` Anthony Towns
  
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-03-06 18:36 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Development Mailing List

Hi All,

> I am less persuaded that consensus risk is particularly high for very narrowly scoped changes
Agreed.

Some people out there seem to conflate execution risks with crypto-economic incentives risks.
Better designed script systems obviously reduce execution risks and unintended consensus failure risks and make maintenance easier.
They also quiet easily blow the lid off other types of risks by nature of being better and more capable.

Paradoxically the more expressive bitcoin script becomes over time, the less likely that a script system overhaul comes with a nasty surprise.

BR,
moonsettler


On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders <gsanders87@gmail•com> wrote:

> > Of course it depends on the specifics, but rewriting a clean interpreter that we can actually reason about does not strike me as a necessarily riskier approach than "just changing a few lines of code" in an interpreter that hardly anyone knows how it really behaves in all cases.
> 
> It's certainly something to consider when weighing further off Bitcoin Script updates: From here is something like "Great Script Restoration" ever the right choice vs a from scratch overhaul? I am less persuaded that consensus risk is particularly high for very narrowly scoped changes, ignoring the "fixed" costs of changing consensus, maintenance burden, MEVil risks, etc. The risk-reward ratio may be suboptimal of course.
> Greg
> On Wednesday, March 5, 2025 at 11:39:27 AM UTC-5 Antoine Poinsot wrote:
> 
> > Hi,
> > 
> > 
> > Just picking on one thing Laolu said:
> > 
> > > The current Overton Window appears to be focused on a small (LoC wise) package to enable a greater degree of permissionless innovation on Bitcoin
> > 
> > 
> > For what it's worth i'm not sure this is the correct focus. Bitcoin Script is so notoriously unpredictable and hard to reason about that most of what matters is outside of the lines of code changed. Of course it depends on the specifics, but rewriting a clean interpreter that we can actually reason about does not strike me as a necessarily riskier approach than "just changing a few lines of code" in an interpreter that hardly anyone knows how it really behaves in all cases.
> > 
> > Antoine
> > 
> > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <lao...@gmail•com> wrote:
> > 
> > > Hi AJ,
> > > 
> > > First a standard disclaimer: the contents of this email shouldn't be
> > > interpreted as an endorsement of one covenants proposal over another.
> > > 
> > > > Since BIP 119's motivation is entirely concerned with its concept of
> > > > covenants and avoiding what it calls recursive covenants
> > > 
> > > If we look at the motivation section of BIP 119, we find this sentence:
> > > 
> > > > This BIP introduces a simple covenant called a *template* which enables a
> > > > limited set of highly valuable use cases without significant risk. BIP-119
> > > > templates allow for non-recursive fully-enumerated covenants with no
> > > > dynamic state.
> > > 
> > > You appear to have latched onto the "non-recursive" aspect, ignoring the
> > > subsequent qualifiers of "fully-enumerated" and "with no dynamic state".
> > > 
> > > The example that you've come up with to "directly undermine" the claimed
> > > motivations of BIP 119 is still fully enumerated (the sole state is declared
> > > up front), and doesn't contain dynamic state (I can't spend the contract on
> > > chain and do something like swap in another hash H, or signature S).
> > > 
> > > > I found it pretty inconvenient, which I don't think is a good indication
> > > > of ecosystem readiness wrt deployment. (For me, the two components that
> > > > are annoying is doing complicated taproot script path spends, and
> > > > calculating CTV hashes)
> > > 
> > > What language/libraries did you use to produce the spend? In my own
> > > development tooling of choice, producing complicated taproot script path
> > > spends is pretty straight forward, so perhaps the inconvenience you ran into
> > > says more about your dev tooling than the ecosystem readiness.
> > > 
> > > It's also worth pointing out that your example relies on private key
> > > deletion, which if deemed acceptable, can be used to emulate CTV as is today
> > > (though you can't create a self-referential loop that way afaict).
> > > 
> > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > approach for the long term
> > > 
> > > Simplicity certainly has some brilliant devs working on it, but after all
> > > these years it still seems to be struggling to exit research mode with some
> > > "killer apps" on Liquid.
> > > 
> > > bllsh on the other hand is a very new (and cool!) project that has no
> > > development uptake beyond its creator. Given its nascent state, it seems
> > > rather premature to promote it as a long term solution.
> > > 
> > > Both of them are effectively a complete rewrite of Script, so compared to
> > > some of the existing covenant proposals on the table (many of which have a
> > > small core code footprint in the interpreter), they represent a radically
> > > expanded scope (ecosystem changes, wallets, consensus code) and therefore
> > > additional risks. The current Overton Window appears to be focused on a
> > > small (LoC wise) package to enable a greater degree of permissionless
> > > innovation on Bitcoin, while leaving the research landscape open for more
> > > dramatic overhauls (bllsh/Simplicity) in the future.
> > > 
> > > -- Laolu
> > > 
> > > 
> > > On Tue, Mar 4, 2025 at 5:06 PM Anthony Towns <a...@erisian•com.au> wrote:
> > > 
> > > > Hello world,
> > > > 
> > > > Some people on twitter are apparently proposing the near-term activation of
> > > > CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
> > > > 
> > > > https://x.com/JeremyRubin/status/1895676912401252588
> > > > https://x.com/lopp/status/1895837290209161358
> > > > https://x.com/stevenroose3/status/1895881757288996914
> > > > https://x.com/reardencode/status/1871343039123452340
> > > > https://x.com/sethforprivacy/status/1895814836535378055
> > > > 
> > > > Since BIP 119's motivation is entirely concerned with its concept of
> > > > covenants and avoiding what it calls recursive covenants, I think it
> > > > is interesting to note that the combination of CSFS and CTV trivially
> > > > enables the construction of a "recursive covenant" as BIP 119 uses those
> > > > terms. One approach is as follows:
> > > > 
> > > > * Make a throwaway BIP340 private key X with 32-bit public key P.
> > > > * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
> > > > its corresponding scriptPubKey K when combined with P as the internal public
> > > > key.
> > > > * Calculate the CTV hash corresponding to a payment of some specific value V
> > > > to K; call this hash H
> > > > * Calculate the BIP 340 signature for message H with private key X, call it S.
> > > > * Discard the private key X
> > > > * Funds sent to K can only be spent by the witness data "<H> <S>" that forwards
> > > > an amount V straight back to K.
> > > > 
> > > > Here's a demonstration on mutinynet:
> > > > 
> > > > https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
> > > > 
> > > > I'd encourage people to try implementing that themselves with their
> > > > preferred tooling; personally, I found it pretty inconvenient, which I
> > > > don't think is a good indication of ecosystem readiness wrt deployment.
> > > > (For me, the two components that are annoying is doing complicated
> > > > taproot script path spends, and calculating CTV hashes)
> > > > 
> > > > I don't believe the existence of a construction like this poses any
> > > > problems in practice, however if there is going to be a push to activate
> > > > BIP 119 in parallel with features that directly undermine its claimed
> > > > motivation, then it would presumably be sensible to at least update
> > > > the BIP text to describe a motivation that would actually be achieved by
> > > > deployment.
> > > > 
> > > > Personally, I think BIP 119's motivation remains very misguided:
> > > > 
> > > > - the things it describes are, in general, not "covenants" [0]
> > > > - the thing it avoids is not "recursion" but unbounded recursion
> > > > - avoiding unbounded recursion is not very interesting when arbitrarily
> > > > large recursion is still possible [1]
> > > > - despite claiming that "covenants have historically been widely
> > > > considering to be unfit for Bitcoin", no evidence for this claim has
> > > > been able to be provided [2,3]
> > > > - the opposition to unbounded recursion seems to me to either mostly
> > > > or entirely be misplaced fear of things that are already possible in
> > > > bitcoin and easily avoided by people who want to avoid it, eg [4]
> > > > 
> > > > so, at least personally, I think almost any update to BIP 119's motivation
> > > > section would be an improvement...
> > > > 
> > > > [0] https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/
> > > > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/
> > > > [2] https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.amazonses.com/
> > > > [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> > > > [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/
> > > > 
> > > > Beyond being a toy example of a conflict with BIP 119's motivation
> > > > section, I think the above script could be useful in the context of the
> > > > "blind-merged-mining" component of spacechains [5]. For example, if
> > > > the commitment was to two outputs, one the recursive step and the other
> > > > being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
> > > > would allow for both providing fees conveniently and for encoding the
> > > > spacechain block's commitment; competing spacechain miners would then
> > > > just be rbf'ing that spend with the parent spacechain update remaining
> > > > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
> > > > need to be used to ensure the "one spacechain update per bitcoin block"
> > > > rule. (I believe mutinynet doesn't support ephemeral anchors however, so
> > > > I don't think there's anywhere this can be tested)
> > > > 
> > > > [5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
> > > > 
> > > > (For a spacechain, miners would want to be confident that the private key
> > > > has been discarded. This confidence could be enhanced by creating X as a
> > > > musig2 key by a federation, in which case provided any of the private keys
> > > > used in generating X were correctly discarded, then everything is fine,
> > > > but that's still a trust assumption. Simple introspection opcodes would
> > > > work far better for this use case, both removing the trust assumption
> > > > and reducing the onchain data required)
> > > > 
> > > > If you're providing CTV and CSFS anyway, I don't see why you wouldn't
> > > > provide the same or similar functionality via a SIGHASH flag so that you
> > > > can avoid specifying the hash directly when you're signing it anyway,
> > > > giving an ANYPREVOUT/NOINPUT-like feature directly.
> > > > 
> > > > (Likewise, I don't see why you'd want to activate CAT on mainnet without
> > > > also at least re-enabling SUBSTR, and potentially also the redundant
> > > > LEFT and RIGHT operations)
> > > > 
> > > > For comparison, bllsh [6,7] takes the approach of providing
> > > > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
> > > > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
> > > > equivalent would then either involve simplying writing:
> > > > 
> > > > (= (bip342_txmsg 3) 0x.....)
> > > > 
> > > > meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,
> > > > then evaluate whether the result is exactly equal to this constant"
> > > > providing one of the standard sighashes worked for your use case, or
> > > > replacing the bip342_txmsg opcode with a custom calculation of the tx
> > > > hash, along the lines of the example reimplementation of bip342_txmsg
> > > > for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
> > > > someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> > > > be happy to include that as an example; I think it should be a pretty
> > > > straightforward conversion from the test-tx example.
> > > > 
> > > > If bllsh were live today (eg on either signet or mainnet), and it were
> > > > desired to softfork in a more optimised implementation of either CTV or
> > > > ANYPREVOUT to replace people coding their own implementation in bllsh
> > > > directly, both would simply involve replacing calls to "bip342_txmsg"
> > > > with calls to a new hash calculation opcode. For CTV behaviour, usage
> > > > would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
> > > > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
> > > > is, the underlying "I want to hash a message in such-and-such a way"
> > > > looks the same, and how it's used is the wallet author's decision,
> > > > not a matter of how the consensus code is written.
> > > > 
> > > > I believe simplicity/simfony can be thought of in much the same way;
> > > > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
> > > > [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
> > > > behaviour [10].
> > > > 
> > > > [6] https://github.com/ajtowns/bllsh/
> > > > [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> > > > [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> > > > [9] https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
> > > > [10] https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
> > > > 
> > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > approach for the long term, and the ongoing lack of examples of killer
> > > > apps demonstrating big wins from limited slices of new functionality
> > > > leaves me completely unexcited about rushing something in the short term.
> > > > Having a flood of use cases that don't work out when looked into isn't
> > > > a good replacement for a single compelling use case that does.
> > > > 
> > > > 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+...@googlegroups•com.
> > > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au.
> > > 
> > > --
> > > 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+...@googlegroups•com.
> > 
> > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com.
> 
> --
> 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/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.com.

-- 
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/Gfgs0GeY513WBZ1FueJBVhdl2D-8QD2NqlBaP0RFGErYbHLE-dnFBN_rbxnTwzlolzpjlx0vo9YSgZpC013Lj4SI_WZR0N1iwbUiNze00tA%3D%40protonmail.com.


 permalink raw reply	[|nested]
2025-03-06 18:36       ` 'moonsettler' via Bitcoin Development Mailing List

  
From: Antoine Riard @ 2025-03-06 21:26 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 20953 bytes --]

Hi all,

> After that, one can build a script: 
<proof-of-target-UTXO-mining=commitment_tx"
> OP_CSFS> OR <<bounty_timelock> <OP_CHECKLOCKTIMEVERIFY> 
<recursive_bounty_sig |
> SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold attacker 
can
> make the funding UTXO amount available as a "anyone-can-spend" and force 
a re-
> commitment to the same tx-withholding script.

Correcting myself, after more thinking I believe to get a non-forgeable 
"proof-of
-target-UTXO-mining" there should be a merkle branch proof of the txid back 
to
the mined block. Otherwise, any participant in the target UTXO / 
transaction (e.g
a LN channel) can confirm the target transaction to execute the contracting 
protocol
according to its semantics _and_ generate the "proof-of-target-UTXO-mining" 
to
claim the "anyone-can-spend" bribing output.

So to do a merkle branch proof, script would have to be of the rough form 
e.g:
< <leaf_node_ab> <OP_SHA256> <OP_CAT> <leaf_node_cd> <OP_SHA256> <OP_CAT>, 
or
any equivalent opcode primitive allowing to get concatenation in the script.

For the design of a TxWithhold, all that you wish is a proof-of-existence 
of a
block B + transaction T (in the mathematical sense). That way if a timelock 
is
reached after X blocks, and no proof-of-existence as been brought until 
then,
this logically implies that B + T do not exist. Or at least have not been 
published,
which for the purpose of the chain being the publication space and 
anti-double-spend
oracle of UTXO spends is the same.

I don't believe with OP_CHECKSIGFROMSTACK alone you can build such 
proof-of-target-UTXO
-mining, though I'm not sure of such statement. All cov primitives 
proposals are coming
without formal analysis of the limits of the expressivity extensions, there 
has been
progress since OP_EVAL, though it's always tooling on a subset of current 
Bitcoin
Script not extension.

At the very least, and in reference to what is described in naumenkogs's 
original
TxWithhold article, the introduction of OP_CSFS let you have m-of-n oracles 
doing
attestations in the script that a block has been confirmed, eventually with 
a tx.
This is already a powerful building block for TxWithhold. At first thought, 
I don't
see how you can have the equivalent with OP_CHECKTEMPLATEVERIFY, by design 
the scope
is reduced.

On the distinction between execution risks with crypto-economic incentives 
risks
brought by some on this thread, this is unclear what is meant exactly. Of 
course
with execution risks, it might more think affecting full-node security (e.g 
a DoS
vector, reason a lot of opcodes were disabled back in ~2010), though it 
could be
just a risk of misuage of the primitive by use-cases toolchain (e.g 
generating 
a consensus-invalid tx due to misuse of the timelock flags) or an attack 
driven
by crypto-ecnomic incentives (e.g selfish-mining or block-withholding 
attack at
the miner-level). Though even for a simple DoS, one can evaluate the CPU / 
bandwidth
cost in quantitative terms to gauge if it's a serious risk, there is an 
area of
uncertainty, or it's not a risk.

When we we talk about security risks, one has to see things that it's more 
a continuum,
where an attacker vector can be used as a building block for more 
sophisticated
attacks. In the original bitcoin paper, crypto-incentives themselves are 
weighted
to evaluate the soundness of the system in section 6. and in section 11.

Best,
Antoine
OTS hash: 2c3e2e41ed67484f5d58138413cfca7f0aba5d7b4d448f2895a1b70b2886e9d8

Le jeudi 6 mars 2025 à 19:03:48 UTC, moonsettler a écrit :

> Hi All,
>
> > I am less persuaded that consensus risk is particularly high for very 
> narrowly scoped changes
> Agreed.
>
> Some people out there seem to conflate execution risks with 
> crypto-economic incentives risks.
> Better designed script systems obviously reduce execution risks and 
> unintended consensus failure risks and make maintenance easier.
> They also quiet easily blow the lid off other types of risks by nature of 
> being better and more capable.
>
> Paradoxically the more expressive bitcoin script becomes over time, the 
> less likely that a script system overhaul comes with a nasty surprise.
>
> BR,
> moonsettler
>
>
> On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders <gsand...@gmail•com> 
> wrote:
>
> > > Of course it depends on the specifics, but rewriting a clean 
> interpreter that we can actually reason about does not strike me as a 
> necessarily riskier approach than "just changing a few lines of code" in an 
> interpreter that hardly anyone knows how it really behaves in all cases.
> > 
> > It's certainly something to consider when weighing further off Bitcoin 
> Script updates: From here is something like "Great Script Restoration" ever 
> the right choice vs a from scratch overhaul? I am less persuaded that 
> consensus risk is particularly high for very narrowly scoped changes, 
> ignoring the "fixed" costs of changing consensus, maintenance burden, MEVil 
> risks, etc. The risk-reward ratio may be suboptimal of course.
> > Greg
> > On Wednesday, March 5, 2025 at 11:39:27 AM UTC-5 Antoine Poinsot wrote:
> > 
> > > Hi,
> > > 
> > > 
> > > Just picking on one thing Laolu said:
> > > 
> > > > The current Overton Window appears to be focused on a small (LoC 
> wise) package to enable a greater degree of permissionless innovation on 
> Bitcoin
> > > 
> > > 
> > > For what it's worth i'm not sure this is the correct focus. Bitcoin 
> Script is so notoriously unpredictable and hard to reason about that most 
> of what matters is outside of the lines of code changed. Of course it 
> depends on the specifics, but rewriting a clean interpreter that we can 
> actually reason about does not strike me as a necessarily riskier approach 
> than "just changing a few lines of code" in an interpreter that hardly 
> anyone knows how it really behaves in all cases.
> > > 
> > > Antoine
> > > 
> > > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <
> lao...@gmail•com> wrote:
> > > 
> > > > Hi AJ,
> > > > 
> > > > First a standard disclaimer: the contents of this email shouldn't be
> > > > interpreted as an endorsement of one covenants proposal over another.
> > > > 
> > > > > Since BIP 119's motivation is entirely concerned with its concept 
> of
> > > > > covenants and avoiding what it calls recursive covenants
> > > > 
> > > > If we look at the motivation section of BIP 119, we find this 
> sentence:
> > > > 
> > > > > This BIP introduces a simple covenant called a *template* which 
> enables a
> > > > > limited set of highly valuable use cases without significant risk. 
> BIP-119
> > > > > templates allow for non-recursive fully-enumerated covenants with 
> no
> > > > > dynamic state.
> > > > 
> > > > You appear to have latched onto the "non-recursive" aspect, ignoring 
> the
> > > > subsequent qualifiers of "fully-enumerated" and "with no dynamic 
> state".
> > > > 
> > > > The example that you've come up with to "directly undermine" the 
> claimed
> > > > motivations of BIP 119 is still fully enumerated (the sole state is 
> declared
> > > > up front), and doesn't contain dynamic state (I can't spend the 
> contract on
> > > > chain and do something like swap in another hash H, or signature S).
> > > > 
> > > > > I found it pretty inconvenient, which I don't think is a good 
> indication
> > > > > of ecosystem readiness wrt deployment. (For me, the two components 
> that
> > > > > are annoying is doing complicated taproot script path spends, and
> > > > > calculating CTV hashes)
> > > > 
> > > > What language/libraries did you use to produce the spend? In my own
> > > > development tooling of choice, producing complicated taproot script 
> path
> > > > spends is pretty straight forward, so perhaps the inconvenience you 
> ran into
> > > > says more about your dev tooling than the ecosystem readiness.
> > > > 
> > > > It's also worth pointing out that your example relies on private key
> > > > deletion, which if deemed acceptable, can be used to emulate CTV as 
> is today
> > > > (though you can't create a self-referential loop that way afaict).
> > > > 
> > > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > > approach for the long term
> > > > 
> > > > Simplicity certainly has some brilliant devs working on it, but 
> after all
> > > > these years it still seems to be struggling to exit research mode 
> with some
> > > > "killer apps" on Liquid.
> > > > 
> > > > bllsh on the other hand is a very new (and cool!) project that has no
> > > > development uptake beyond its creator. Given its nascent state, it 
> seems
> > > > rather premature to promote it as a long term solution.
> > > > 
> > > > Both of them are effectively a complete rewrite of Script, so 
> compared to
> > > > some of the existing covenant proposals on the table (many of which 
> have a
> > > > small core code footprint in the interpreter), they represent a 
> radically
> > > > expanded scope (ecosystem changes, wallets, consensus code) and 
> therefore
> > > > additional risks. The current Overton Window appears to be focused 
> on a
> > > > small (LoC wise) package to enable a greater degree of permissionless
> > > > innovation on Bitcoin, while leaving the research landscape open for 
> more
> > > > dramatic overhauls (bllsh/Simplicity) in the future.
> > > > 
> > > > -- Laolu
> > > > 
> > > > 
> > > > On Tue, Mar 4, 2025 at 5:06 PM Anthony Towns <a...@erisian•com.au> 
> wrote:
> > > > 
> > > > > Hello world,
> > > > > 
> > > > > Some people on twitter are apparently proposing the near-term 
> activation of
> > > > > CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
> > > > > 
> > > > > https://x.com/JeremyRubin/status/1895676912401252588
> > > > > https://x.com/lopp/status/1895837290209161358
> > > > > https://x.com/stevenroose3/status/1895881757288996914
> > > > > https://x.com/reardencode/status/1871343039123452340
> > > > > https://x.com/sethforprivacy/status/1895814836535378055
> > > > > 
> > > > > Since BIP 119's motivation is entirely concerned with its concept 
> of
> > > > > covenants and avoiding what it calls recursive covenants, I think 
> it
> > > > > is interesting to note that the combination of CSFS and CTV 
> trivially
> > > > > enables the construction of a "recursive covenant" as BIP 119 uses 
> those
> > > > > terms. One approach is as follows:
> > > > > 
> > > > > * Make a throwaway BIP340 private key X with 32-bit public key P.
> > > > > * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", 
> and
> > > > > its corresponding scriptPubKey K when combined with P as the 
> internal public
> > > > > key.
> > > > > * Calculate the CTV hash corresponding to a payment of some 
> specific value V
> > > > > to K; call this hash H
> > > > > * Calculate the BIP 340 signature for message H with private key 
> X, call it S.
> > > > > * Discard the private key X
> > > > > * Funds sent to K can only be spent by the witness data "<H> <S>" 
> that forwards
> > > > > an amount V straight back to K.
> > > > > 
> > > > > Here's a demonstration on mutinynet:
> > > > > 
> > > > > 
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
> > > > > 
> > > > > I'd encourage people to try implementing that themselves with their
> > > > > preferred tooling; personally, I found it pretty inconvenient, 
> which I
> > > > > don't think is a good indication of ecosystem readiness wrt 
> deployment.
> > > > > (For me, the two components that are annoying is doing complicated
> > > > > taproot script path spends, and calculating CTV hashes)
> > > > > 
> > > > > I don't believe the existence of a construction like this poses any
> > > > > problems in practice, however if there is going to be a push to 
> activate
> > > > > BIP 119 in parallel with features that directly undermine its 
> claimed
> > > > > motivation, then it would presumably be sensible to at least update
> > > > > the BIP text to describe a motivation that would actually be 
> achieved by
> > > > > deployment.
> > > > > 
> > > > > Personally, I think BIP 119's motivation remains very misguided:
> > > > > 
> > > > > - the things it describes are, in general, not "covenants" [0]
> > > > > - the thing it avoids is not "recursion" but unbounded recursion
> > > > > - avoiding unbounded recursion is not very interesting when 
> arbitrarily
> > > > > large recursion is still possible [1]
> > > > > - despite claiming that "covenants have historically been widely
> > > > > considering to be unfit for Bitcoin", no evidence for this claim 
> has
> > > > > been able to be provided [2,3]
> > > > > - the opposition to unbounded recursion seems to me to either 
> mostly
> > > > > or entirely be misplaced fear of things that are already possible 
> in
> > > > > bitcoin and easily avoided by people who want to avoid it, eg [4]
> > > > > 
> > > > > so, at least personally, I think almost any update to BIP 119's 
> motivation
> > > > > section would be an improvement...
> > > > > 
> > > > > [0] 
> https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/
> > > > > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/
> > > > > [2] 
> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email.amazonses.com/
> > > > > [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> > > > > [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/
> > > > > 
> > > > > Beyond being a toy example of a conflict with BIP 119's motivation
> > > > > section, I think the above script could be useful in the context 
> of the
> > > > > "blind-merged-mining" component of spacechains [5]. For example, if
> > > > > the commitment was to two outputs, one the recursive step and the 
> other
> > > > > being a 0sat ephemeral anchor, then the spend of the ephemeral 
> anchor
> > > > > would allow for both providing fees conveniently and for encoding 
> the
> > > > > spacechain block's commitment; competing spacechain miners would 
> then
> > > > > just be rbf'ing that spend with the parent spacechain update 
> remaining
> > > > > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV 
> would
> > > > > need to be used to ensure the "one spacechain update per bitcoin 
> block"
> > > > > rule. (I believe mutinynet doesn't support ephemeral anchors 
> however, so
> > > > > I don't think there's anywhere this can be tested)
> > > > > 
> > > > > [5] 
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
> > > > > 
> > > > > (For a spacechain, miners would want to be confident that the 
> private key
> > > > > has been discarded. This confidence could be enhanced by creating 
> X as a
> > > > > musig2 key by a federation, in which case provided any of the 
> private keys
> > > > > used in generating X were correctly discarded, then everything is 
> fine,
> > > > > but that's still a trust assumption. Simple introspection opcodes 
> would
> > > > > work far better for this use case, both removing the trust 
> assumption
> > > > > and reducing the onchain data required)
> > > > > 
> > > > > If you're providing CTV and CSFS anyway, I don't see why you 
> wouldn't
> > > > > provide the same or similar functionality via a SIGHASH flag so 
> that you
> > > > > can avoid specifying the hash directly when you're signing it 
> anyway,
> > > > > giving an ANYPREVOUT/NOINPUT-like feature directly.
> > > > > 
> > > > > (Likewise, I don't see why you'd want to activate CAT on mainnet 
> without
> > > > > also at least re-enabling SUBSTR, and potentially also the 
> redundant
> > > > > LEFT and RIGHT operations)
> > > > > 
> > > > > For comparison, bllsh [6,7] takes the approach of providing
> > > > > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" 
> (same but
> > > > > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A 
> CTV
> > > > > equivalent would then either involve simplying writing:
> > > > > 
> > > > > (= (bip342_txmsg 3) 0x.....)
> > > > > 
> > > > > meaining "calculate the message hash of the current tx for 
> SIGHASH_SINGLE,
> > > > > then evaluate whether the result is exactly equal to this constant"
> > > > > providing one of the standard sighashes worked for your use case, 
> or
> > > > > replacing the bip342_txmsg opcode with a custom calculation of the 
> tx
> > > > > hash, along the lines of the example reimplementation of 
> bip342_txmsg
> > > > > for SIGHASH_ALL [8] in the probably more likely case that it 
> didn't. If
> > > > > someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> > > > > be happy to include that as an example; I think it should be a 
> pretty
> > > > > straightforward conversion from the test-tx example.
> > > > > 
> > > > > If bllsh were live today (eg on either signet or mainnet), and it 
> were
> > > > > desired to softfork in a more optimised implementation of either 
> CTV or
> > > > > ANYPREVOUT to replace people coding their own implementation in 
> bllsh
> > > > > directly, both would simply involve replacing calls to 
> "bip342_txmsg"
> > > > > with calls to a new hash calculation opcode. For CTV behaviour, 
> usage
> > > > > would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO 
> behaviour,
> > > > > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". 
> That
> > > > > is, the underlying "I want to hash a message in such-and-such a 
> way"
> > > > > looks the same, and how it's used is the wallet author's decision,
> > > > > not a matter of how the consensus code is written.
> > > > > 
> > > > > I believe simplicity/simfony can be thought of in much the same 
> way;
> > > > > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like 
> behaviour
> > > > > [9], or "jet::eq_256" comparing a tx hash and a constant for 
> CTV-like
> > > > > behaviour [10].
> > > > > 
> > > > > [6] https://github.com/ajtowns/bllsh/
> > > > > [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> > > > > [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> > > > > [9] 
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
> > > > > [10] 
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
> > > > > 
> > > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > > approach for the long term, and the ongoing lack of examples of 
> killer
> > > > > apps demonstrating big wins from limited slices of new 
> functionality
> > > > > leaves me completely unexcited about rushing something in the 
> short term.
> > > > > Having a flood of use cases that don't work out when looked into 
> isn't
> > > > > a good replacement for a single compelling use case that does.
> > > > > 
> > > > > 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+...@googlegroups•com.
> > > > > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au
> .
> > > > 
> > > > --
> > > > 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+...@googlegroups•com.
> > > 
> > > > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com
> .
> > 
> > --
> > 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+...@googlegroups•com.
> > To view this discussion visit 
> https://groups.google.com/d/msgid/bitcoindev/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.com
> .
>

-- 
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/7535451a-d92a-44fb-9ce1-bc0c8ea4e73bn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 31528 bytes --]

 permalink raw reply	[|nested]
2025-03-05  6:14 ` Olaoluwa Osuntokun
  2025-03-05 16:14   ` 'Antoine Poinsot' via Bitcoin Development Mailing List

  2025-03-08 15:55     ` James O'Beirne
  
From: Anthony Towns @ 2025-03-07 21:01 UTC (permalink / raw)
  To: Olaoluwa Osuntokun;  bitcoindev

On Tue, Mar 04, 2025 at 10:14:59PM -0800, Olaoluwa Osuntokun wrote:
> > Since BIP 119's motivation is entirely concerned with its concept of
> > covenants and avoiding what it calls recursive covenants
> If we look at the motivation section of BIP 119, we find this sentence:
> > This BIP introduces a simple covenant called a *template* which enables a
> > limited set of highly valuable use cases without significant risk. BIP-119
> > templates allow for non-recursive fully-enumerated covenants with no
> > dynamic state.
> You appear to have latched onto the "non-recursive" aspect, ignoring the
> subsequent qualifiers of "fully-enumerated" and "with no dynamic state".
>
> The example that you've come up with to "directly undermine" the claimed
> motivations of BIP 119 is still fully enumerated (the sole state is declared
> up front), and doesn't contain dynamic state (I can't spend the contract on
> chain and do something like swap in another hash H, or signature S).

The reason "fully-enumerated" provides any "safety" is that it occurs
when the scriptPubKey is chosen -- without the availability of CSFS,
you either include the CTV hash in the scriptPubKey or the use of CTV
provides no protection at all.

My example does not include the CTV hash in the scriptPubKey, which is
what allows the CTV hash to then commit to the scriptPubKey, which in turn
allows for the unbounded recursion.

If you instead did not delete the CSFS private key would allow you to
swap in another hash H or signature S in future. That would perhaps
allow designing an unbounded state machine where a master key can add
new states in future. It's not immediately obvious to me if there's
anything interesting that can be done with that.

In any event, if there is some weird subset of use cases that are somehow
both scary and still prevented even by the combination of CTV and CSFS
the BIP should be updated to document that.

> > For me, the bllsh/simplicity approach makes more sense as a design
> > approach for the long term
> Simplicity certainly has some brilliant devs working on it, but after all
> these years it still seems to be struggling to exit research mode with some
> "killer apps" on Liquid.

https://github.com/ElementsProject/elements/pull/1427 suggests
Simplicity's potentially going live on Liquid any day now.

> The current Overton Window appears to be focused on a
> small (LoC wise) package to enable a greater degree of permissionless
> innovation on Bitcoin, while leaving the research landscape open for more
> dramatic overhauls (bllsh/Simplicity) in the future.

The concept of an "Overton window" is a political one, used for when
there has been successful political pressure to exclude some subjects
from discussion for reasons other than their underlying merits. That's
not a good idea if you want to maintain high quality, and it's probably
not compatible at all with a project that aims to be decentralised in
any meaningful way.

Certainly a small change (though LoC is a bad measure of that -- how
many LoC does it take to drop the 21M limit, or to drop the subsidy from
3.125 BTC to 0 BTC?) is better than a large change all else being equal;
but all else isn't equal: different changes enable different feature
sets. The question you should be asking is whether we're getting useful
feature sets from the small changes being proposed.

If you want "permissionless innovation", then many small incremental
consensus changes are not a good way of doing it -- as that involves
asking the global network of Bitcoin users for permission for each
individual change.

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/Z8tes4tXo53_DRpU%40erisian.com.au.


 permalink raw reply	[|nested]
2025-03-05 22:46   ` Antoine Riard

  2025-03-10 22:36       ` Antoine Riard
  
From: Anthony Towns @ 2025-03-07 21:16 UTC (permalink / raw)
  To: Antoine Riard;  Bitcoin Development Mailing List

On Wed, Mar 05, 2025 at 02:46:08PM -0800, Antoine Riard wrote:
> > I don't believe the existence of a construction like this poses any 
> > problems in practice, however if there is going to be a push to activate 
> > BIP 119 in parallel with features that directly undermine its claimed 
> > motivation, then it would presumably be sensible to at least update 
> > the BIP text to describe a motivation that would actually be achieved by 
> > deployment. 
> I do...
> https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark/
> https://blog.bitmex.com/txwithhold-smart-contracts/

I don't believe being able to pay for censorship on-chain is any more
threatening than being able to pay for censorship off-chain.

The bitmex blog post there relies on having a trusted oracle to release
DLC payments if the target tx wasn't mined. If you have that level of
trust anyway, then just putting funds in escrow, having miners register
bolt12 invoices with the oracle, and having the oracle make the payments
when it's satisfied blocks are sufficiently confirmed has a pretty
similar risk profile.

> With OP_CHECKSIGFROMSTACK, which is iirc <signature> <pubkey> <message>

It's <signature> <message> <pubkey> with pubkey at the top of the stack.
https://github.com/bitcoin/bips/blob/master/bip-0348.md

The same is also true of both Elements' CSFS and Bitcoin-Cash's CHECKDATASIG.

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/Z8tiNcjdsRKvekp4%40erisian.com.au.


 permalink raw reply	[|nested]
2025-03-06 17:17     ` Greg Sanders
  2025-03-06 18:36       ` 'moonsettler' via Bitcoin Development Mailing List

  
From: Anthony Towns @ 2025-03-07 21:36 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Development Mailing List

On Thu, Mar 06, 2025 at 09:17:41AM -0800, Greg Sanders wrote:
> > Of course it depends on the specifics, but rewriting a clean interpreter
> > that we can actually reason about does not strike me as a necessarily
> > riskier approach than "just changing a few lines of code" in an interpreter
> > that hardly anyone knows how it really behaves in all cases.
> It's certainly something to consider when weighing further off Bitcoin
> Script updates: From here is something like "Great Script Restoration" ever
> the right choice vs a from scratch overhaul? I am less persuaded that
> consensus risk is particularly high for very narrowly scoped changes,
> ignoring the "fixed" costs of changing consensus, maintenance burden, MEVil
> risks, etc. The risk-reward ratio may be suboptimal of course.

I think "narrowly scoped changes" is doing a lot of work there. Was
tapscript a narrowly scoped change? I would have said so. However,
one thing it did was remove the limit on sript size/opcodes, which
necessitated a change to how OP_IF/OP_ELSE were implemented to avoid
potential quadratic execution time in the length of the script.

https://github.com/bitcoin/bitcoin/pull/16902

On the other hand, treating the current interpreter code as an artifact
of wise ancients, whose knowledge of how to safely modify it has been
lost to time doesn't really seem like a great approach to me, either.

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/Z8tm6VmhtQxmc2gO%40erisian.com.au.


 permalink raw reply	[|nested]
2025-03-07 21:01   ` Anthony Towns

  2025-03-11  1:06       ` Antoine Riard
  
From: James O'Beirne @ 2025-03-08 15:55 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3407 bytes --]

On Friday, March 7, 2025 at 4:26:36 PM UTC-5 Anthony Towns wrote:

If you instead did not delete the CSFS private key would allow you to 
swap in another hash H or signature S in future. That would perhaps 
allow designing an unbounded state machine where a master key can add 
new states in future.


I'm not sure what your point here is - that we can do stupid things with 
CTV + CSFS? That's universally true in bitcoin; I can have an "unbounded 
state machine" by sending myself the same UTXO back and forth indefinitely 
with CHECKSIG.

As with everything in bitcoin, the chain is insulated from stupidity like 
that by fees, the UTXO model, and block cadence, so what's the problem?
 

https://github.com/ElementsProject/elements/pull/1427 suggests 
Simplicity's potentially going live on Liquid any day now.


Probably worth noting that CSFS and many advanced introspection opcodes 
(which allow synthesizing CTV) have been live for almost *four years now* 
on Liquid 
(https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-functionality).
 

The concept of an "Overton window" is a political one, used for when 
there has been successful political pressure to exclude some subjects 
from discussion for reasons other than their underlying merits. That's 
not a good idea if you want to maintain high quality, and it's probably 
not compatible at all with a project that aims to be decentralised in 
any meaningful way.


Sorry to tell you, but given that changing consensus requires soliciting 
buy-in from a wide variety of people across the Bitcoin ecosystem with 
varying levels of technical ability, it is inherently a political process.

Beyond that, "Overton window" is an appropriate device in the sense that 
roasbeef is using it because the more substantial a proposed change is, the 
more time is needed by the technical ecosystem to digest it, both in terms 
of tooling and safety analysis. Introducing an entirely new script 
interpreter on the basis of a Lisp (or combinator calculus, or whatever 
Simplicity's claim is) is indeed far outside of that "Overton" window - 
much farther than tacking on what is essentially just a new SIGHASH mode to 
the existing interpreter.
 

Certainly a small change (though LoC is a bad measure of that -- how 
many LoC does it take to drop the 21M limit, or to drop the subsidy from 
3.125 BTC to 0 BTC?) is better than a large change all else being equal; 
but all else isn't equal: different changes enable different feature 
sets. The question you should be asking is whether we're getting useful 
feature sets from the small changes being proposed.


Let's not be petty here - it's clear he's talking about LoC within the 
script interpreter, which is a different context than the codebase as a 
whole. Within the context of the interpreter, LoC is indeed a decent 
heuristic for marginal risk. Of course, nobody's saying it's perfect.

James

-- 
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/45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4497 bytes --]

 permalink raw reply	[|nested]
2025-03-05  0:01 [bitcoindev] "Recursive covenant" with CTV and CSFS Anthony Towns
  2025-03-05  6:14 ` Olaoluwa Osuntokun
  2025-03-05 17:53 ` 'moonsettler' via Bitcoin Development Mailing List

  2025-03-12  3:48   ` Anthony Towns
  
From: Nadav Ivgi @ 2025-03-10  5:14 UTC (permalink / raw)
  To: Anthony Towns;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 11339 bytes --]

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.

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.

>  I'd encourage people to try implementing that themselves with their
preferred tooling; personally, I found it pretty inconvenient

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

Example transaction:
https://mutinynet.com/tx/9c941dc9c0068eb817b2d18416b174468203c6ad090d8d5735cc9b3732959e39

Note however that what you described is creating 0-fee transactions, with
no way to attach additional fees. So this would also need either an anchor
output or a CTV template that allows the inclusion of an additional input,
which I did not implement in the gist.

> For me, the two components that are annoying is doing complicated taproot
script path spends, and calculating CTV hashes

I've been working on improving Minsc to make these kinds of things easier.
It supports Taproot, CTV, PSBT, Descriptors, Miniscript, raw Script, BIP32,
and more. Much of it is still undocumented (the min.sc website is very much
outdated), but I have some examples demonstrating different uses that might
be of interest:

- A simple one that involves calculating CTV hashes and a multi-script
Taproot tree: https://min.sc/v0.3/#github=examples/ctv-simple.minsc

- More advanced example implementing a CTV vault:
https://min.sc/v0.3/#github=examples/ctv-vault.minsc

- Another vault, with key delegation using CTV+CSFS+PAIRCOMMIT+INTERNALKEY:
https://min.sc/v0.3/#gist=82d92568c2fcba62203157f8df11354e

- Decaying multisig using PSBT/Miniscript:
https://min.sc/v0.3/#github=examples/3of3-into-2of3.minsc

More examples are available on the README: https://github.com/shesek/minsc

Cheers,
shesek


On Wed, Mar 5, 2025 at 3:06 AM Anthony Towns <aj@erisian•com.au> wrote:

> Hello world,
>
> Some people on twitter are apparently proposing the near-term activation of
> CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
>
>  https://x.com/JeremyRubin/status/1895676912401252588
>  https://x.com/lopp/status/1895837290209161358
>  https://x.com/stevenroose3/status/1895881757288996914
>  https://x.com/reardencode/status/1871343039123452340
>  https://x.com/sethforprivacy/status/1895814836535378055
>
> Since BIP 119's motivation is entirely concerned with its concept of
> covenants and avoiding what it calls recursive covenants, I think it
> is interesting to note that the combination of CSFS and CTV trivially
> enables the construction of a "recursive covenant" as BIP 119 uses those
> terms. One approach is as follows:
>
>  * Make a throwaway BIP340 private key X with 32-bit public key P.
>  * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
>    its corresponding scriptPubKey K when combined with P as the internal
> public
>    key.
>  * Calculate the CTV hash corresponding to a payment of some specific
> value V
>    to K; call this hash H
>  * Calculate the BIP 340 signature for message H with private key X, call
> it S.
>  * Discard the private key X
>  * Funds sent to K can only be spent by the witness data "<H> <S>" that
> forwards
>    an amount V straight back to K.
>
> Here's a demonstration on mutinynet:
>
>
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58
>
> I'd encourage people to try implementing that themselves with their
> preferred tooling; personally, I found it pretty inconvenient, which I
> don't think is a good indication of ecosystem readiness wrt deployment.
> (For me, the two components that are annoying is doing complicated
> taproot script path spends, and calculating CTV hashes)
>
> I don't believe the existence of a construction like this poses any
> problems in practice, however if there is going to be a push to activate
> BIP 119 in parallel with features that directly undermine its claimed
> motivation, then it would presumably be sensible to at least update
> the BIP text to describe a motivation that would actually be achieved by
> deployment.
>
> Personally, I think BIP 119's motivation remains very misguided:
>
>  - the things it describes are, in general, not "covenants" [0]
>  - the thing it avoids is not "recursion" but unbounded recursion
>  - avoiding unbounded recursion is not very interesting when arbitrarily
>    large recursion is still possible [1]
>  - despite claiming that "covenants have historically been widely
>    considering to be unfit for Bitcoin", no evidence for this claim has
>    been able to be provided [2,3]
>  - the opposition to unbounded recursion seems to me to either mostly
>    or entirely be misplaced fear of things that are already possible in
>    bitcoin and easily avoided by people who want to avoid it, eg [4]
>
> so, at least personally, I think almost any update to BIP 119's motivation
> section would be an improvement...
>
> [0]
> https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
> [1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/
> [2]
> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/
> [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> [4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/
>
> Beyond being a toy example of a conflict with BIP 119's motivation
> section, I think the above script could be useful in the context of the
> "blind-merged-mining" component of spacechains [5]. For example, if
> the commitment was to two outputs, one the recursive step and the other
> being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
> would allow for both providing fees conveniently and for encoding the
> spacechain block's commitment; competing spacechain miners would then
> just be rbf'ing that spend with the parent spacechain update remaining
> unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
> need to be used to ensure the "one spacechain update per bitcoin block"
> rule. (I believe mutinynet doesn't support ephemeral anchors however, so
> I don't think there's anywhere this can be tested)
>
> [5]
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg
>
> (For a spacechain, miners would want to be confident that the private key
> has been discarded. This confidence could be enhanced by creating X as a
> musig2 key by a federation, in which case provided any of the private keys
> used in generating X were correctly discarded, then everything is fine,
> but that's still a trust assumption. Simple introspection opcodes would
> work far better for this use case, both removing the trust assumption
> and reducing the onchain data required)
>
> If you're providing CTV and CSFS anyway, I don't see why you wouldn't
> provide the same or similar functionality via a SIGHASH flag so that you
> can avoid specifying the hash directly when you're signing it anyway,
> giving an ANYPREVOUT/NOINPUT-like feature directly.
>
> (Likewise, I don't see why you'd want to activate CAT on mainnet without
> also at least re-enabling SUBSTR, and potentially also the redundant
> LEFT and RIGHT operations)
>
> For comparison, bllsh [6,7] takes the approach of providing
> "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
> for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
> equivalent would then either involve simplying writing:
>
>    (= (bip342_txmsg 3) 0x.....)
>
> meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,
> then evaluate whether the result is exactly equal to this constant"
> providing one of the standard sighashes worked for your use case, or
> replacing the bip342_txmsg opcode with a custom calculation of the tx
> hash, along the lines of the example reimplementation of bip342_txmsg
> for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
> someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> be happy to include that as an example; I think it should be a pretty
> straightforward conversion from the test-tx example.
>
> If bllsh were live today (eg on either signet or mainnet), and it were
> desired to softfork in a more optimised implementation of either CTV or
> ANYPREVOUT to replace people coding their own implementation in bllsh
> directly, both would simply involve replacing calls to "bip342_txmsg"
> with calls to a new hash calculation opcode. For CTV behaviour, usage
> would look like "(= (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
> usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
> is, the underlying "I want to hash a message in such-and-such a way"
> looks the same, and how it's used is the wallet author's decision,
> not a matter of how the consensus code is written.
>
> I believe simplicity/simfony can be thought of in much the same way;
> with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
> [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
> behaviour [10].
>
> [6] https://github.com/ajtowns/bllsh/
> [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> [9]
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf
> [10]
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf
>
> For me, the bllsh/simplicity approach makes more sense as a design
> approach for the long term, and the ongoing lack of examples of killer
> apps demonstrating big wins from limited slices of new functionality
> leaves me completely unexcited about rushing something in the short term.
> Having a flood of use cases that don't work out when looked into isn't
> a good replacement for a single compelling use case that does.
>
> 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/Z8eUQCfCWjdivIzn%40erisian.com.au
> .
>

-- 
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/CAGXD5f3EGyUVBc%3DbDoNi_nXcKmW7M_-mUZ7LOeyCCab5Nqt69Q%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 15790 bytes --]

 permalink raw reply	[|nested]
2025-03-07 21:16     ` Anthony Towns

  
From: Antoine Riard @ 2025-03-10 22:36 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 5597 bytes --]

Hi AJ,

> I don't believe being able to pay for censorship on-chain is any more
> threatening than being able to pay for censorship off-chain.
> 
> The bitmex blog post there relies on having a trusted oracle to release
> DLC payments if the target tx wasn't mined. If you have that level of
> trust anyway, then just putting funds in escrow, having miners register
> bolt12 invoices with the oracle, and having the oracle make the payments
> when it's satisfied blocks are sufficiently confirmed has a pretty
> similar risk profile.

I think your reasoning point out exactly what is the "unknown" part of such
tx-withholding risk in bitcoin, and what Gleb never formalized further in 
the
bitmex blog or his email on costless bribes to miner, as far as I know. 
Namely
"If you have that level of trust anyway", which I'm understanding that we're
putting here in the shoes of the attacker to evaluate a tx-withhold attacks 
_cost_.

Generally, when we evaluate a threat model (e.g for internet DDoS) we'll 
have
few notions like a goal (e.g DoS a Minecraft server), knowledge (e.g 
know-how
on do to the most efficient DDoS) and capabilities (e.g number of botnet 
available
to reach a DoS threshold), all 3 elements combined in an attack scenario.

Here, if we reason by analogy to mount a tx-withholding attack as an 
attacker,
we'll have a goal, i.e censor a LN commitment-tx, a knowledge, i.e txid of 
the
commitment transaction to be withheld and inner know-how of the LN protocol 
and
about capabilities i.e DLC oracles available and what can be paid as bribing
on-chain fees (to simplify, let's say on-chain fees == off-chain fees).

Now, in this tx-withholding attack, we can consider that the attacker 
capabilities
are constituted, among others, of the number of trusted oracles available 
to release
DLC payment signing the equivalent of a "proof-of-target-UTXO-mining" for a
tx-withholding "bribing" contract.

And that's where your remark on "If you have that level of trust anyway" is
pertinent, I think as this underscores the _accumulation cost_ for an 
attacker
to build _trust_ in the given DLC oracles that will be used for a 
tx-withhold
attack. Accumulation or acquisition cost of a Sybil node is a metric 
considered
in the litterature about Sybil attacks.

Now, and this where is the crux of my interrogation, by extending the 
expressivity
of bitcoin script and removing the necessity to use an off-chain twist, are 
we
slashing the _accumulation_ cost for a tx-withholding attack ? An attacker 
could
from now on just rely on the "blockchain-as-a-judge" paradigm, which is the 
one
explained in the LN paper iirc and attacks become far more practical.

If you have another methodology to evaluate such tx-censorship risk, I'm of
course curious...The bitmex blog post have also a recension of the 
literature
in Ethereum analyzing HTLC-attacks, among fews.

> It's <signature> <message> <pubkey> with pubkey at the top of the stack.
https://github.com/bitcoin/bips/blob/master/bip-0348.md

> The same is also true of both Elements' CSFS and Bitcoin-Cash's 
CHECKDATASIG.

Okay, so this is the latest CSFS draft. I still had in mind the O'Connor's 
FS'17
paper where it was <signature> <message> <pubkey> with sig-first as a stack 
order,
as example. Fwiw, what matters is that you can freely sign a <message>, 
which is
not iself the implicit signature digest, though exact code matters to 
analyze 
opcode composability, of course.

Best,
Antoine
OTS hash: 2e731833f7408e21832605e904e5db0cb21d29a453fbb1cd232eb6c766441f2a

Le vendredi 7 mars 2025 à 21:27:01 UTC, Anthony Towns a écrit :

> On Wed, Mar 05, 2025 at 02:46:08PM -0800, Antoine Riard wrote:
> > > I don't believe the existence of a construction like this poses any 
> > > problems in practice, however if there is going to be a push to 
> activate 
> > > BIP 119 in parallel with features that directly undermine its claimed 
> > > motivation, then it would presumably be sensible to at least update 
> > > the BIP text to describe a motivation that would actually be achieved 
> by 
> > > deployment. 
> > I do...
> > 
> https://gnusha.org/pi/bitcoindev/f594c2f8-d712-48e4-a010-778dd4d0cadb@Spark/
> > https://blog.bitmex.com/txwithhold-smart-contracts/
>
> I don't believe being able to pay for censorship on-chain is any more
> threatening than being able to pay for censorship off-chain.
>
> The bitmex blog post there relies on having a trusted oracle to release
> DLC payments if the target tx wasn't mined. If you have that level of
> trust anyway, then just putting funds in escrow, having miners register
> bolt12 invoices with the oracle, and having the oracle make the payments
> when it's satisfied blocks are sufficiently confirmed has a pretty
> similar risk profile.
>
> > With OP_CHECKSIGFROMSTACK, which is iirc <signature> <pubkey> <message>
>
> It's <signature> <message> <pubkey> with pubkey at the top of the stack.
> https://github.com/bitcoin/bips/blob/master/bip-0348.md
>
> The same is also true of both Elements' CSFS and Bitcoin-Cash's 
> CHECKDATASIG.
>
> 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/b9a11745-4e5e-45f7-8036-f27b8d401ff5n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 7440 bytes --]

 permalink raw reply	[|nested]
2025-03-08 15:55     ` James O'Beirne

  
From: Antoine Riard @ 2025-03-11  1:06 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 9706 bytes --]

Hi James,

> As with everything in bitcoin, the chain is insulated from stupidity like 
that
> by fees, the UTXO model, and block cadence, so what's the problem?

See my novel answer to AJ that by extending bitcoin script, I think you 
might *actually*
diluting the UTXO model as you can now on cross-inspect the status of an 
outpoint.
This might amplify tx-withhold style risk for bitcoin contracting 
protocols, e.g vaults.

> Probably worth noting that CSFS and many advanced introspection opcodes 
(which allow synthesizing
> CTV) have been live for almost *four years now* on Liquid 
(https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-functionality).

Live != Deployed use-cases built on top of those advanced introspection 
opcodes.

I've not verified this by myself, though from what is available from public 
data
L-BTC is <= to LN today in terms of locked coins. In terms of 
decentralization,
a federated side-chain is not even like a network of payment channels, where
everyone can join by confirming a 2-of-2 in the chain. So have skilled dev 
really
try do "wrong things" with L-BTC and all those shiny introspection opcodes 
? I'm
not sure, and please accept my skepticism here.

> Sorry to tell you, but given that changing consensus requires soliciting 
buy-in from a
> wide variety of people across the Bitcoin ecosystem with varying levels 
of technical
> ability, it is inherently a political process.

No -- Apologies to tell you that science / engineering != politics.

Somehow, if one has taste and familiarity with all postmodernism sociology,
there is well one domain where it completely failed to demonstrate that 
things
are following a "political process", this is indeed the domain of science. 
In
science, mathematical or physical truth always prevails, no matter what.

Don't get me wrong -- This doesn't mean I cannot share the opinion that 
current
consensus changes process is a complete conoundrum. Sadly it might have 
devolved
in the view of numerous segments of the Bitcoin ecosystem that what matters 
w.r.t
consensus build-up is who is sitting on a bunch of surreanous github 
repository
permissions, and not necessarily if the consensus change is benefitful in an
objective fashion for bitcoin, not even if such _consensus change_ might be
required for the long-term flourishing of bitcoin (at least fixing the 
technical
debt).

There is difference in saying what makes you socially popular to be vetted 
with
empty github permissions and let you vegetate on them by a weak social 
consensus
and there is a difference in saying unpopular truth to nurture real changes 
on
the long-term. I won't open the conversation more on that subject.

Now, back to the more technical analysis of covenant, personally my position
is still the same than it was discussed on Bitcoin Core #28550. The 
communication
tone was rude, for sure, though I still share the same belief we shouldn't 
be
careful in designing contracting primitives and be completely $YOLO if said
primitives works well for a second-layer.

On concerning CheckTemplateVerify itself, which is itself simpler than any
other proposed soft-forks due to the non-malleable templating, as I said 18
months ago I'm still open in my free time to review/test a CTV-based vault
(https://github.com/jamesob/simple-ctv-vault), the same way I did for 
Eltoo-based
LN channels in the past. This is one thing to come with a proof-of-concept
working on a single workstation, this is another thing to have tested it
under real operational guidelines, where dynamic fees and keys ceremonies
have to be deal with.

I don't think CTV is altering the UTXO model significantly, though pleasure
to be proven wrong here. On the other hand CTV is bringing this idea of
immutability in a chain of transactions, that we cannot do currently with
sigs-based covenant. That immutability in theory has consequential value
for anyone building cold wallet or vault, that is clear as once the funding
utxo is confirmed, the UTXO signing keys leaks are void.

Now, I might be the last guy in the ecosystem to think that CTV is not
the promised silver-bullet by its author all over the world to design
and deploy vaults. Fine.

> Beyond that, "Overton window" is an appropriate device in the sense that 
roasbeef
> is using it because the more substantial a proposed change is, the more 
time is
> needed by the technical ecosystem to digest it, both in terms of tooling 
and safety
> analysis. Introducing an entirely new script interpreter on the basis of 
a Lisp (or
> combinator calculus, or whatever Simplicity's claim is) is indeed far 
outside of
> that "Overton" window - much farther than tacking on what is essentially 
just a
> new SIGHASH mode to the existing interpreter.

I do not wish to be overly pessimitic, though I think whatever 
"just-drop-a-new
script-interpreter" approach is just the wrong design approach, if we do 
not go
to fix first all the dynamic fees issues grieving all the contracting 
protocols
and bitcoin second-layers.

Side-note: if you're used with playing with your compiler to target exotic
ISAs, one could build the equivalent for any Lisp interpreter where there is
an IR and in function of the target you compile to current supported bitcoin
opcodes, disabling interpreter syntax that are not (currently) supported or
that cannot be translated. I think this would be already a formal 
verification
gain for any smart-contract toolchain using it, even if it's a subset.

> Let's not be petty here - it's clear he's talking about LoC within the 
script
>interpreter, which is a different context than the codebase as a whole. 
Within
> the context of the interpreter, LoC is indeed a decent heuristic for 
marginal risk. Of course, nobody's saying it's perfect.

I agree that LoC is a decent heuristic for marginal risk.

Best,
Antoine
OTS hash: 7f00760799b4defd9fe551673a7926c01704274e522d44f3dc8e701b320243de
Le samedi 8 mars 2025 à 16:39:34 UTC, James O'Beirne a écrit :

> On Friday, March 7, 2025 at 4:26:36 PM UTC-5 Anthony Towns wrote:
>
> If you instead did not delete the CSFS private key would allow you to 
> swap in another hash H or signature S in future. That would perhaps 
> allow designing an unbounded state machine where a master key can add 
> new states in future.
>
>
> I'm not sure what your point here is - that we can do stupid things with 
> CTV + CSFS? That's universally true in bitcoin; I can have an "unbounded 
> state machine" by sending myself the same UTXO back and forth indefinitely 
> with CHECKSIG.
>
> As with everything in bitcoin, the chain is insulated from stupidity like 
> that by fees, the UTXO model, and block cadence, so what's the problem?
>  
>
> https://github.com/ElementsProject/elements/pull/1427 suggests 
> Simplicity's potentially going live on Liquid any day now.
>
>
> Probably worth noting that CSFS and many advanced introspection opcodes 
> (which allow synthesizing CTV) have been live for almost *four years now* 
> on Liquid (
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-functionality
> ).
>  
>
> The concept of an "Overton window" is a political one, used for when 
> there has been successful political pressure to exclude some subjects 
> from discussion for reasons other than their underlying merits. That's 
> not a good idea if you want to maintain high quality, and it's probably 
> not compatible at all with a project that aims to be decentralised in 
> any meaningful way.
>
>
> Sorry to tell you, but given that changing consensus requires soliciting 
> buy-in from a wide variety of people across the Bitcoin ecosystem with 
> varying levels of technical ability, it is inherently a political process.
>
> Beyond that, "Overton window" is an appropriate device in the sense that 
> roasbeef is using it because the more substantial a proposed change is, the 
> more time is needed by the technical ecosystem to digest it, both in terms 
> of tooling and safety analysis. Introducing an entirely new script 
> interpreter on the basis of a Lisp (or combinator calculus, or whatever 
> Simplicity's claim is) is indeed far outside of that "Overton" window - 
> much farther than tacking on what is essentially just a new SIGHASH mode to 
> the existing interpreter.
>  
>
> Certainly a small change (though LoC is a bad measure of that -- how 
> many LoC does it take to drop the 21M limit, or to drop the subsidy from 
> 3.125 BTC to 0 BTC?) is better than a large change all else being equal; 
> but all else isn't equal: different changes enable different feature 
> sets. The question you should be asking is whether we're getting useful 
> feature sets from the small changes being proposed.
>
>
> Let's not be petty here - it's clear he's talking about LoC within the 
> script interpreter, which is a different context than the codebase as a 
> whole. Within the context of the interpreter, LoC is indeed a decent 
> heuristic for marginal risk. Of course, nobody's saying it's perfect.
>
> James
>

-- 
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/5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 11996 bytes --]

 permalink raw reply	[|nested]
2025-03-10  5:14 ` Nadav Ivgi

  2025-03-12 10:02     ` Nadav Ivgi
  2025-03-18 20:29     ` 'moonsettler' via Bitcoin Development Mailing List
  
From: Anthony Towns @ 2025-03-12  3:48 UTC (permalink / raw)
  To: Nadav Ivgi;  bitcoindev

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.


 permalink raw reply	[|nested]
2025-03-12  3:48   ` Anthony Towns

  2025-03-12 16:15       ` Nadav Ivgi
  2025-03-14  3:20       ` Anthony Towns
  2025-03-18 20:29     ` 'moonsettler' via Bitcoin Development Mailing List
  
From: Nadav Ivgi @ 2025-03-12 10:02 UTC (permalink / raw)
  To: Anthony Towns;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 3626 bytes --]

On Wed, Mar 12, 2025 at 5:48 AM Anthony Towns <aj@erisian•com.au> wrote:

> 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


Yes you are of course correct. My memory failed me, should've looked up the
BIP :)

With either APO or CTV alone you can do an arbitrarily long chain of
> commitments,

adding CSFS and discarding the CSFS private key allows
> you to have a single commitment that can be reused indefinitely.


With APO alone, you can use one of two constructs:

1. Trustless, Finite - using a chain of pre-computed transactions where the
signature for the next transaction is committed to in the scriptPubKey.
This has similar properties to what you can get with CTV alone.

2. Trusted, Infinite - using a simple non-committed signature spending back
to the same address. This has similar properties to your CTV+CSFS construct.

Does adding CSFS enable any additional designs?

I think it's impossible to get Trustless, Infinite short of having full
introspection abilities (CAT/TXHASH/Elements-like), right?

With Elements it's pretty straightforward, something like
`OP_PUSHCURRENTINPUTINDEX OP_INSPECTINPUTSCRIPTPUBKEY <0>
OP_INSPECTOUTPUTSCRIPTPUBKEY OP_ROT OP_EQUALVERIFY OP_EQUAL`

You could have CTV commit to two inputs, with the second input's entire
> value being burnt to fees, but that's fairly annoying


Yes, preparing an exact-sized utxo for fees is indeed annoying. However
it's not much different from CPFP - an extra tx with the same overall
number of inputs/outputs, only around 46vB less efficient[0] (assuming you
need change[1]). So at least for some use-cases it's not terrible either.

One important difference is that for a BMM-like bidding system, losing bids
would still pay tx fees (and take up chain space) for creating the fee
utxo, unlike with CPFP where only the winning bid pays fees. But for other
cases, the difference would be negligible.

Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) that
you mentioned, where no extra transaction is needed at all.

[0] Assuming you need to use N coins for fees and that change is needed,
with an exact-sized fee utxo you have a N-in, 2-out tx to prepare the fee
utxo, then a 2-in, 1-out for the main tx - for a total of N+2 inputs and 3
outputs. With CPFP, its 1-in, 2-out for the main tx, then a N+1-in, 1-out
tx for the CPFP fee bump - also for a total of N+2 inputs and 3 outputs.
However, with CPFP you could use Pay-to-Anchor (while the fee utxo has to
be key-encumbered), saving 65WU for one input plus 30vB/120WU for one
output, making it more efficient by a total of 185WU/46vB (assuming the fee
utxo uses key-path P2TR).

[1] If you happen to have an existing utxo to pay fees with, the 2-input
CTV template would be as efficient as it gets, on par with APO|SINGLE. This
can be extended to combos of multiple utxos, by adding more CTV tapleaves
for different numbers of inputs (at a slight cost of larger control
blocks). With large wallets it could be plausible to find such combos.

Cheers,
shesek

-- 
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/CAGXD5f3zHuwGq%2BM1jwBJjpEc3Wd8biwjwnrXu6VhrysQeyivLQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5093 bytes --]

 permalink raw reply	[|nested]
2025-03-12 10:02     ` Nadav Ivgi

  2025-03-14  3:20       ` Anthony Towns
  
From: Nadav Ivgi @ 2025-03-12 16:15 UTC (permalink / raw)
  To: Anthony Towns;  bitcoindev

[-- Attachment #1: Type: text/plain, Size: 4421 bytes --]

> One important difference is that for a BMM-like bidding system [..]. But
for other cases, the difference would be negligible.

Actually, thinking about this some more, this could be an issue even
without multiple bidders - the tx preparing the fee utxo might pay
sufficient fees to get itself confirmed, yet not provide enough fees for
the main transaction to confirm too. In this case you'll basically also
have 'losing bids' that waste fees/space and will have to make another tx
to prepare a larger fee utxo.

So yes, pretty annoying. :< More than I initially thought.

shesek


On Wed, Mar 12, 2025 at 12:02 PM Nadav Ivgi <nadav@shesek•info> wrote:

> On Wed, Mar 12, 2025 at 5:48 AM Anthony Towns <aj@erisian•com.au> wrote:
>
>> 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
>
>
> Yes you are of course correct. My memory failed me, should've looked up
> the BIP :)
>
> With either APO or CTV alone you can do an arbitrarily long chain of
>> commitments,
>
> adding CSFS and discarding the CSFS private key allows
>> you to have a single commitment that can be reused indefinitely.
>
>
> With APO alone, you can use one of two constructs:
>
> 1. Trustless, Finite - using a chain of pre-computed transactions where
> the signature for the next transaction is committed to in the scriptPubKey.
> This has similar properties to what you can get with CTV alone.
>
> 2. Trusted, Infinite - using a simple non-committed signature spending
> back to the same address. This has similar properties to your CTV+CSFS
> construct.
>
> Does adding CSFS enable any additional designs?
>
> I think it's impossible to get Trustless, Infinite short of having full
> introspection abilities (CAT/TXHASH/Elements-like), right?
>
> With Elements it's pretty straightforward, something like
> `OP_PUSHCURRENTINPUTINDEX OP_INSPECTINPUTSCRIPTPUBKEY <0>
> OP_INSPECTOUTPUTSCRIPTPUBKEY OP_ROT OP_EQUALVERIFY OP_EQUAL`
>
> You could have CTV commit to two inputs, with the second input's entire
>> value being burnt to fees, but that's fairly annoying
>
>
> Yes, preparing an exact-sized utxo for fees is indeed annoying. However
> it's not much different from CPFP - an extra tx with the same overall
> number of inputs/outputs, only around 46vB less efficient[0] (assuming you
> need change[1]). So at least for some use-cases it's not terrible either.
>
> One important difference is that for a BMM-like bidding system, losing
> bids would still pay tx fees (and take up chain space) for creating the fee
> utxo, unlike with CPFP where only the winning bid pays fees. But for other
> cases, the difference would be negligible.
>
> Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) that
> you mentioned, where no extra transaction is needed at all.
>
> [0] Assuming you need to use N coins for fees and that change is needed,
> with an exact-sized fee utxo you have a N-in, 2-out tx to prepare the fee
> utxo, then a 2-in, 1-out for the main tx - for a total of N+2 inputs and 3
> outputs. With CPFP, its 1-in, 2-out for the main tx, then a N+1-in, 1-out
> tx for the CPFP fee bump - also for a total of N+2 inputs and 3 outputs.
> However, with CPFP you could use Pay-to-Anchor (while the fee utxo has to
> be key-encumbered), saving 65WU for one input plus 30vB/120WU for one
> output, making it more efficient by a total of 185WU/46vB (assuming the fee
> utxo uses key-path P2TR).
>
> [1] If you happen to have an existing utxo to pay fees with, the 2-input
> CTV template would be as efficient as it gets, on par with APO|SINGLE. This
> can be extended to combos of multiple utxos, by adding more CTV tapleaves
> for different numbers of inputs (at a slight cost of larger control
> blocks). With large wallets it could be plausible to find such combos.
>
> Cheers,
> shesek
>

-- 
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/CAGXD5f3XScYjj-eFu76vNWyRZG1T_wzeTNfgWCAC3qWKL6_n5w%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 6133 bytes --]

 permalink raw reply	[|nested]
2025-03-12 10:02     ` Nadav Ivgi
  2025-03-12 16:15       ` Nadav Ivgi

  
From: Anthony Towns @ 2025-03-14  3:20 UTC (permalink / raw)
  To: Nadav Ivgi;  bitcoindev

On Wed, Mar 12, 2025 at 12:02:27PM +0200, Nadav Ivgi wrote:
> > adding CSFS and discarding the CSFS private key allows
> > you to have a single commitment that can be reused indefinitely.
> With APO alone, you can use one of two constructs:
> 2. Trusted, Infinite - using a simple non-committed signature spending back
> to the same address. This has similar properties to your CTV+CSFS construct.

Right, that's

   <01 P> OP_CHECKSIG

as the scriptPubKey, "<sig ANYPREVOUT|ALL>" as the witness, committing to
that scriptPubKey (and an anchor output probably), and after generating
that signature, the private key is discarded.

> Does adding CSFS enable any additional designs?
> I think it's impossible to get Trustless, Infinite short of having full
> introspection abilities (CAT/TXHASH/Elements-like), right?

Direct introspection certainly seems like the easiest approach.
TLUV/OP_VAULT should also get you there I think, despite not providing
full introspection.

> > You could have CTV commit to two inputs, with the second input's entire
> > value being burnt to fees, but that's fairly annoying
> Yes, preparing an exact-sized utxo for fees is indeed annoying. However
> it's not much different from CPFP - an extra tx with the same overall
> number of inputs/outputs, only around 46vB less efficient[0] (assuming you
> need change[1]). So at least for some use-cases it's not terrible either.

CPFP is easier to RBF, so still superior, I think.

> Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) that
> you mentioned, where no extra transaction is needed at all.

A big problem with that is that a griefer can potentially attach large
inputs or outputs to your tx and get their package relayed before yours,
making RBF attempts expensive in high-feerate scenarios, potentially
resulting in nothing being confirmed for an extended period. Could
potentially be solved by TRUC or similar rules (or pure replace-by-feerate
rules), though.

Also, for better or worse, an even more WU-optimal construction is simply
paying miners directly, out of band.

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/Z9OgbC3Zvg1vfrlc%40erisian.com.au.


 permalink raw reply	[|nested]
2025-03-12  3:48   ` Anthony Towns
  2025-03-12 10:02     ` Nadav Ivgi

  
From: 'moonsettler' via Bitcoin Development Mailing List @ 2025-03-18 20:29 UTC (permalink / raw)
  To: Anthony Towns;  Nadav Ivgi, bitcoindev

Hi All,

> You could have CTV commit to two inputs, with the second input's entire
> value being burnt to fees, but that's fairly annoying

Sometimes it's annoying, other times it enables new applications, because
it can force the submitter of the transaction to contribute to the output(s).

This could serve different uses like griefing deterrent (immortal statechains)
or collect yield from blind merged mining (surfchains).

BR,
moonsettler

On Wednesday, March 12th, 2025 at 4:48 AM, Anthony Towns <aj@erisian•com.au> wrote:

> 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.

-- 
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/NYpEviMeuCzkq09xeaXnKDBNDLjREe-7gJEKCHw5RiOo-fFntC4Ts6ainINIYpEh8CZdcVn9nNLApxbBTIl3jxkXs2zwtwPpPuOJHlbfKpQ%3D%40protonmail.com.


 permalink raw reply	[|nested]