Re: [bitcoin-dev] CTV dramatically improves DLCs

[Alex Schoof via bitcoin-dev]

> CTV DLCs are non-interactive asynchronously third-party unilaterally
creatable.

This is super interesting. I think that would make it easier to do
multi-party DLCs. With a "normal" DLC, you need to have N parties
exchanging and signing CETs and you end up with a combinatorial explosion
of signing operations to perform. It sounds like if you did it with CTV,
then each party could compute all the outcomes on their own in parallel (to
be able to generate commitments for each tapleaf) and then just exchange
and sign the single opening transaction for the DLC. Or for devices with
limited resources, you could have a coordinator compute the whole TR tree
and publish a ZKP to the other signers.

Cheers,

Alex


On Fri, Jan 28, 2022 at 12:21 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Lloyd,
>
> This is an excellent write up, the idea and benefits are clear.
>
> Is it correct that in the case of a 3/5th threshold it is a total 10x *
> 30x = 300x improvement? Quite impressive.
>
> I have a few notes of possible added benefits / features of DLCs with CTV:
>
> 1) CTV also enables a "trustless timeout" branch, whereby you can have a
> failover claim that returns funds to both sides.
>
> There are a few ways to do this:
>
> A) The simplest is just an oracle-free  CTV whereby the
> timeout transaction has an absolute/relative timelock after the creation of
> the DLC in question.
>
> B) An alternative approach I like is to have the base DLC have a branch
> ` CTV` which pays into a DLC that is the exact same
> except it removes the just-used branch and replaces it with ` tx)> CTV` which contains a relative timelock R for the desired amount of
> time to resolve. This has the advantage of always guaranteeing at least R
> amount of time since the Oracles have been claimed to be non-live to
> "return funds"  to parties participating
>
>
> 2) CTV DLCs are non-interactive asynchronously third-party unilaterally
> creatable.
>
> What I mean by this is that it is possible for a single party to create a
> DLC on behalf of another user since there is no required per-instance
> pre-signing or randomly generated state. E.g., if Alice wants to create a
> DLC with Bob, and knows the contract details, oracles, and a key for Bob,
> she can create the contract and pay to it unilaterally as a payment to Bob.
>
> This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
> also be constructed and then sent (along with a specific amount) to a third
> party service (such as an exchange or Lightning node) to create DLCs
> without requiring the third party service to do anything other than make
> the payment as requested.
>
>
> 3) CTV DLCs can be composed in interesting ways
>
> Options over DLCs open up many exciting types of instrument where Alice
> can do things like:
> A) Create a Option expiring in 1 week where Bob can add funds to pay a
> premium and "Open" a DLC on an outcome closing in 1 year
> B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
> premium (on-chain DEX?).
>
>  See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete
> stuff around this.
>
> There are also opportunities for perpetual-like contracts where you could
> combine into one logical DLC 12 DLCs closing 1 per month that can either be
> payed out all at once at the end of the year, or profit pulled out
> partially at any time earlier.
>
> 4) This satisfies (I think?) my request to make DLCs expressible as Sapio
> contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/
>
> 5) An additional performance improvement can be had for iterative DLCs in
> Lightning where you might trade over a fixed set of attestation points with
> variable payout curves (e.g., just modifying some set of the CTV points).
> Defer to you on performance, but this could help enable some more HFT-y
> experiences for DLCs in LN
>
> Best,
>
> Jeremy
> --
> @JeremyRubin 
> 
>
>
> On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi dlc-dev and bitcoin-dev,
>>
>> tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a 
>> lot*.
>>
>>
>> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


-- 


Alex Schoof
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV dramatically improves DLCs

[Jeremy Rubin via bitcoin-dev]

Apologies for the double post*, but I just had a follow up idea
that's pretty interesting to me.

You can make the close portion of a DLC be an "optimistic" execution with a
choice of justice scheme. This enables closing a DLC somewhat securely
without exposing the oracles on-chain at all.

Assuming honest oracles, the only cost of this mechanism over previous is
that you have to do a script path spend (but it can be a top-level branch,
since it's the "most likely" one).


For every DLC branch like:

* CHECKTEMPLATEVERIFY
 CHECKSIG
 CHECKSIGADD
 CHECKSIGADD
2 EQUAL*


add a 2 branches:


* CHECKTEMPLATEVERIFY
 CHECKSIG
*

* CHECKTEMPLATEVERIFY
 CHECKSIG*


This enables Alice or Bob to "lock in" a redemption of the contract
that becomes spendable by them after . CET-hash-* should
include a nLockTime/nSequence such that it is at the same time as the
attestation points should be known.


Where CET-hash-T sends funds to a DLC that has the following conditions:


(cooperate):

*pk_internal=musig(Alice, Bob)*

or (unilateral timeout)

* Checksig <2 weeks> CSV*

or (show oracles for this outcome)

* CHECKTEMPLATEVERIFY*

* CHECKSIG
 CHECKSIGADD
 CHECKSIGADD
2 EQUAL*

or (justice with no punishment), forall j !=i:

* CHECKTEMPLATEVERIFY*

* CHECKSIG
 CHECKSIGADD
 CHECKSIGADD
2 EQUAL*

or (justice with punishment), forall j!=i:

* CHECKTEMPLATEVERIFY*

* CHECKSIG
 CHECKSIGADD
 CHECKSIGADD
2 EQUAL*


Justice with punishment seems to me to be the better option since T is
actively choosing this resolution (the CTV transition is signed), but
justice with no punishment might be better if you think the oracles
might screw you over and collude to steal.

One interesting question is if the justice transactions can be
"compressed" to be fewer for a given outcome. I.e., if Bob has claimed
that the outcome is 35, and there are 100 total outcomes, do we need
99 justice paths or is there a way to make fewer of them? Intuitively,
it would seem so, because if we have a 8-10 threshold for picking a
path, a 3-10 proof would be sufficient to prove Bob claimed to know
the 8-10 falsely. However, that then means 3-10 could collude, v.s.
the fraud proof requiring a full 8-10 counter. Things to think about!


Best,


Jeremy


* this might actually be a triple or quadruple post depending on how
you count, I adjusted which email was the subscriber on my mailing
list account and resultantly sent from the old address... sincere
apologies if you are seeing this message >1 times to those who were on
the CC.

--
@JeremyRubin 



On Fri, Jan 28, 2022 at 9:21 AM Jeremy  wrote:

> Lloyd,
>
> This is an excellent write up, the idea and benefits are clear.
>
> Is it correct that in the case of a 3/5th threshold it is a total 10x *
> 30x = 300x improvement? Quite impressive.
>
> I have a few notes of possible added benefits / features of DLCs with CTV:
>
> 1) CTV also enables a "trustless timeout" branch, whereby you can have a
> failover claim that returns funds to both sides.
>
> There are a few ways to do this:
>
> A) The simplest is just an oracle-free  CTV whereby the
> timeout transaction has an absolute/relative timelock after the creation of
> the DLC in question.
>
> B) An alternative approach I like is to have the base DLC have a branch
> ` CTV` which pays into a DLC that is the exact same
> except it removes the just-used branch and replaces it with ` tx)> CTV` which contains a relative timelock R for the desired amount of
> time to resolve. This has the advantage of always guaranteeing at least R
> amount of time since the Oracles have been claimed to be non-live to
> "return funds"  to parties participating
>
>
> 2) CTV DLCs are non-interactive asynchronously third-party unilaterally
> creatable.
>
> What I mean by this is that it is possible for a single party to create a
> DLC on behalf of another user since there is no required per-instance
> pre-signing or randomly generated state. E.g., if Alice wants to create a
> DLC with Bob, and knows the contract details, oracles, and a key for Bob,
> she can create the contract and pay to it unilaterally as a payment to Bob.
>
> This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
> also be constructed and then sent (along with a specific amount) to a third
> party service (such as an exchange or Lightning node) to create DLCs
> without requiring the third party service to do anything other than make
> the payment as requested.
>
>
> 3) CTV DLCs can be composed in interesting ways
>
> Options over DLCs open up many exciting types of instrument where Alice
> can do things like:
> A) Create a Option expiring in 1 week where Bob can add funds to pay a
> premium and "Open" a DLC on an outcome closing in 1 year
> B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
> premium (on-chain DEX?).
>
>  See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete
> stuff around this.
>
> Th

Re: [bitcoin-dev] CTV dramatically improves DLCs

[Jeremy via bitcoin-dev]

Lloyd,

This is an excellent write up, the idea and benefits are clear.

Is it correct that in the case of a 3/5th threshold it is a total 10x * 30x
= 300x improvement? Quite impressive.

I have a few notes of possible added benefits / features of DLCs with CTV:

1) CTV also enables a "trustless timeout" branch, whereby you can have a
failover claim that returns funds to both sides.

There are a few ways to do this:

A) The simplest is just an oracle-free  CTV whereby the
timeout transaction has an absolute/relative timelock after the creation of
the DLC in question.

B) An alternative approach I like is to have the base DLC have a branch
` CTV` which pays into a DLC that is the exact same
except it removes the just-used branch and replaces it with ` CTV` which contains a relative timelock R for the desired amount of
time to resolve. This has the advantage of always guaranteeing at least R
amount of time since the Oracles have been claimed to be non-live to
"return funds"  to parties participating


2) CTV DLCs are non-interactive asynchronously third-party unilaterally
creatable.

What I mean by this is that it is possible for a single party to create a
DLC on behalf of another user since there is no required per-instance
pre-signing or randomly generated state. E.g., if Alice wants to create a
DLC with Bob, and knows the contract details, oracles, and a key for Bob,
she can create the contract and pay to it unilaterally as a payment to Bob.

This enables use cases like pay-to-DLC addresses. Pay-to-DLC addresses can
also be constructed and then sent (along with a specific amount) to a third
party service (such as an exchange or Lightning node) to create DLCs
without requiring the third party service to do anything other than make
the payment as requested.


3) CTV DLCs can be composed in interesting ways

Options over DLCs open up many exciting types of instrument where Alice can
do things like:
A) Create a Option expiring in 1 week where Bob can add funds to pay a
premium and "Open" a DLC on an outcome closing in 1 year
B) Create an Option expiring in 1 week where one-of-many Bobs can pay the
premium (on-chain DEX?).

 See https://rubin.io/bitcoin/2021/12/20/advent-23/ for more concrete stuff
around this.

There are also opportunities for perpetual-like contracts where you could
combine into one logical DLC 12 DLCs closing 1 per month that can either be
payed out all at once at the end of the year, or profit pulled out
partially at any time earlier.

4) This satisfies (I think?) my request to make DLCs expressible as Sapio
contracts in https://rubin.io/bitcoin/2021/12/20/advent-23/

5) An additional performance improvement can be had for iterative DLCs in
Lightning where you might trade over a fixed set of attestation points with
variable payout curves (e.g., just modifying some set of the CTV points).
Defer to you on performance, but this could help enable some more HFT-y
experiences for DLCs in LN

Best,

Jeremy
--
@JeremyRubin 



On Mon, Jan 24, 2022 at 3:04 AM Lloyd Fournier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi dlc-dev and bitcoin-dev,
>
> tl;dr OP_CTV simplifies and improves performance of DLCs by a factor of *a 
> lot*.
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [dlc-dev] CTV dramatically improves DLCs

[Jeremy via bitcoin-dev]

Thibaut,

CSFS might have independent benefits, but in this case CTV is not being
used in the Oracle part of the DLC, it's being used in the user generated
mapping of Oracle result to Transaction Outcome.

So it'd only be complimentary if you came up with something CSFS based for
the Oracles.

Best,

Jeremy


On Thu, Jan 27, 2022 at 12:59 AM Thibaut Le Guilly via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi,
>
> Lloyd, thanks for this excellent writeup. I must say that indeed using CTV
> seems like it would very much lower the complexity of the DLC protocol (and
> it seems like APO would also work, thanks Jonas for pointing that out).
> Though thinking about it, I can't help wondering if the ideal op code for
> DLC wouldn't actually be CHECKSIGFROMSTACK? It feels to me that this would
> give the most natural way of doing things. If I'm not mistaken, this would
> enable simply requiring an oracle signature over the outcome, without any
> special trick, and without even needing the oracle to release a nonce in
> advance (the oracle could sign `event_outcome + event_id` to avoid
> signature reuse). I must say that I haven't studied covenant opcodes in
> detail yet so is that line of thinking correct or am I missing something?
>
> Cheers,
>
> Thibaut
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Jeremy via bitcoin-dev]

I probably need to reset it -- I ran into some issues with the IBD latch
bug IIRC and had difficulty producing new blocks.

I sent funds as a manual faucet to at least one person... not aware of
anyone else finding use for the signet. In part this is due to the fact
that in order to run a signet, you also kind of need to run some kind of
faucet on it, which wasn't readily available when I launched it previously.
I think I can use https://github.com/jsarenik/bitcoin-faucet-shell now
though.

Usually people are using Regtest to play around with CTV less so Signet.
There is value in a signet, but I don't think that "there's not a signet
for it" is a blocking issue v.s. nice to have.
--
@JeremyRubin 



On Fri, Jan 28, 2022 at 6:18 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Jan 28, 2022 at 01:14:07PM +, Michael Folkson via bitcoin-dev
> wrote:
> > There is not even a custom signet with CTV (as far as I know)
>
> https://twitter.com/jeremyrubin/status/1339699281192656897
>
>
> signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
> addnode=50.18.75.225
>
> But I think there's only been a single coinbase consolidation tx, and no
> actual CTV transactions?
>
> Cheers,
> aj
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PathCoin

[Billy Tetrud via bitcoin-dev]

> what is the incentive for the honest party to punish?

Justice. Also, there's no incentive for the honest party to not punish -
presumably their software would automatically punish, and why go through
any effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a
$10 bribe might get someone somewhere to install hacked up software to be
able to fulfill such a bribe, but even then i think it would be a rare
person that would stoop to that. Were it to become a true negotiation, the
cheater has more to lose, and therefore the bribee has a lot of leverage.

> my strong intuition is that it will never be properly stable.

I'm curious what you mean by "stable". You had mentioned the game theory is
"fragile" and I'm wondering if there's more to this than just "what
incentive does the honest party have to burn?"

To be clear, I'm not advocating for Sabu and I haven't done any deep
thinking about burn based incentives.

One thing I thought of regarding path coin, if there's ever a situation
where there are multiple choices in path, whatever punishment there is
probably needs to be able to handle the multiple of the number of paths.
The only way around this i can imagine is to have some method of
coordination between payees, eg a place where a payee records their payment
such that a payee who has been double spent on to become aware they've been
double spent on and initiate the punishment. But once you have that
coordination mechanism it starts not looking more like an on chain
transaction.

On Tue, Jan 25, 2022, 06:50 AdamISZ  wrote:

> Hi Billy,
> I read through the description. I think systems like this *mostly* fail
> due to game theory.
>
> With punishment-by-burn you have various issues that make it to my mind
> pretty unstable, too unstable to use for any serious system. To be fair,
> this isn't cut-and-dried. So let me unpack:
>
> (I briefly touched on why I dismissed penalties via burn in my gist,
> section: "Not feeling the burn".)
>
> There is a distinction between penalty via burn to unspendable output and
> penalty via burn to miner fees. The latter has an obvious problem: if your
> counterparties collude with (or are) miners, they may not actually be
> penalized at all (now to be clear, that is a problematic attack ex nihilo:
> nobody usually can be sure who's mining the next block, but markets have a
> way of solving and coordinating such things: see e.g. the various MEV
> discussions and initiatives in Ethereum for an example of that).
>
> But the former (provable burn) is still imo extremely unstable: if the
> penalty tx destroys all the money, what is the incentive for the honest
> party to punish? In such a scenario even a one cent donation from the
> attacker to the victim might prevent the penalty from happening.
> You can combine 'destruction of most, or some, of the funds' with a
> smaller payout to the aggrieved party, but then again you have to factor in
> the possibility of bribes. The Sabu post you linked describes it as: "There
> are precise and delicate formulas for calculating the amount of loss of the
> issuer and the creditor, which ensures that just and true act in both
> parties are cost-effective in all situations." I agree it's delicate, but
> after having spent time looking into these things, my strong intuition is
> that it will never be properly stable.
>
> In the PathCoin description I am specifically looking for a trustless
> system, with this finesse: we still count it as trustless even though we
> are using penalties as disincentive, because the penalty *consists of a
> payment directly from the attacker to the attacked, and that payment is
> larger than the amount stolen*. I claim that that *is* stable.
>
> Notice that Lightning has the same model (in LN-Penalty), as long as
> 'claiming the whole channel capacity' is enough to be larger than what is
> stolen (see: channel reserves etc.).
>
> Sent with ProtonMail  Secure Email.
>
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, January 25th, 2022 at 11:53, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> There was a protocol someone mentioned a while back called Sabu that had
> the same goals. As i recall, it had some pretty promising constructs, but
> would have a critical vulnerability that could be exploited by miners. This
> is the write up:
>
>
> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transactions-per-second-and-privacy-1eef8568d180
>
> Perhaps some of the techniques there could be combined with your ideas to
> get closer to a solution.
>
> On Mon, Jan 24, 2022, 08:51 AdamISZ via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello list,
>>
>> I took the time to write up this rather out-there idea:
>>
>> Imagine you wanted to send a coin just like email, i.e. just transfer
>> data to the counterparty.
>>
>> Clearly this is in general entirely impossible; but with what
>> restrictions and assu

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[James O'Beirne via bitcoin-dev]

> Technical debt isn't a measure of weight of transactions.

Sorry, my original sentence was a little unclear. I meant to say that the
notion that CTV is just a subpar waypoint en route to a more general
covenant system may not be accurate if it is a more efficient way (in terms
of chainstate/weight) to express highly useful patterns like vaults. In
that case, characterizing CTV as technical debt wouldn't be right.

> Our only option here is to be mindful of the long term implications of
the design choices we are making today.

Your points are well taken - I don't think anyone is arguing against
thinking hard about consensus changes. But I have yet to see a proposal for
covenants that is as efficient on-chain and easy to reason about as CTV is.

I also think there's some value in "legging into" covenants by deploying a
simple, non-recursive construction like CTV that services some very
important uses, and then taking as much time as necessary to think about
how to solve more existential problems, like UTXO scalability, that likely
require a recursive covenant construction.

There doesn't have to be mutual exclusion in the approaches, especially
when the maintenance burden of CTV seems to be so low. If we end up
deploying something that requires a wider variety of in-script hashing, it
seems likely that CTV's hash will be able to "free ride" on whatever more
general sighash cache structure we come up with.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Anthony Towns via bitcoin-dev]

On Fri, Jan 28, 2022 at 01:14:07PM +, Michael Folkson via bitcoin-dev wrote:
> There is not even a custom signet with CTV (as far as I know) 

https://twitter.com/jeremyrubin/status/1339699281192656897

signetchallenge=512102946e8ba8eca597194e7ed90377d9bbebc5d17a9609ab3e35e706612ee882759351ae
addnode=50.18.75.225

But I think there's only been a single coinbase consolidation tx, and no
actual CTV transactions?

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne 
wrote:

> > I don't think implementing a CTV opcode that we expect to largely be
> obsoleted by a TXHASH at a later date is yielding good value from a soft
> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it).
> You're presenting a novel idea that, as far as I know, hasn't had much time
> to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
> of flags and the implications that has for testing. Caching for something
> like TXHASH looks to me like a whole different ballgame relative to CTV,
> which has a single kind of hash.
>

Let's not overstate the concern around the combinatorics of TXHASH.   It's
not like there is a vast amount of cross-flag interaction we are talking
about here.  There are also a combinatorial number of ways of assembling
opcodes in Bitcoin script, but we aren't required to exhaustively test
every single possible Script program.


> Even if we were to adopt something like TXHASH, how long is it going to
> take to develop, test, and release? My guess is "a while" - in the
> meantime, users of Bitcoin are without a vault strategy that doesn't
> require either presigning transactions with ephemeral keys (operationally
> difficult) or multisig configurations that would make Rube Goldberg blush
> (operationally difficult and precarious). The utility of vaulting seems
> underappreciated among consensus devs and it's something I'd like to write
> about soon in a separate post.
>
> > The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> Another argument for CTV (which I find especially persuasive) is its
> simplicity - it's relatively easy to reason about and, at this point,
> pretty well understood. It seems like a low-risk change relative to some of
> the other covenant proposals, nearly all of which elicit a good deal of
> headscratching (at least from me) and seem to require not only larger
> on-chain footprints but sizable code changes.
>


> > I am sensitive to technical debt and soft fork processes
>

> If OP_CTV ends up being the most practical approach for vaulting - among
> other things - in terms of weight (which it seems to be at the moment) I
> don't think "technical debt" is an applicable term.
>

Technical debt isn't a measure of weight of transactions.  It's a measure
of the code complexity needed to implement, in this case, a Bitcoin Script
interpreter.

By itself, adding a single new hash format for CTV isn't that complex, and
it is certainly simpler than this TXHASH proposal.  But then we need to add
another two slightly different hash formats for APO support.  And tomorrow
we will need yet another set of transaction hash formats for the next
thing, and so on, with each instance requiring going through its own
soft-fork process.  It is at that point we end up with something more
complicated and with more deployment risk than if we had just done
something like TXHASH at the very beginning.  But unlike other programming
environments, we cannot refactor our way out of such a situation.  We
cannot make a new script version while deprecating the old one.  Our only
option here is to be mindful of the long term implications of the design
choices we are making today.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Russell O'Connor via bitcoin-dev]

On Thu, Jan 27, 2022 at 8:34 PM Anthony Towns  wrote:

> > An Alternative Proposal::
> >  ...
>
> > For similar reasons, TXHASH is not amenable to extending the set of
> txflags
> > at a later date.
>
> > I believe the difficulties with upgrading TXHASH can be mitigated by
> > designing a robust set of TXHASH flags from the start.  For example
> having
> > bits to control whether [...]
>
> I don't think that's really feasible -- eg, what you propose don't cover
> SIGHASH_GROUP:
>
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019243.html
>

For more complex interactions, I was imagining combining this TXHASH
proposal with CAT and/or rolling SHA256 opcodes.  If TXHASH ended up
supporting relative or absolute input/output indexes then users could
assemble the hashes of the particular inputs and outputs they care about
into a single signed message.


> > That all said, even if other txhash flag modes are needed in the future,
> > adding TXHASH2 always remains an option.
>
> I think baking this in from day 0 might be better: make TXHASH be
> a multibyte opcode, so that when you decode "0xBB" on the stack,
> you also decode a serialize.h:VarInt as the version number.


I wouldn't be opposed to this.

> ' CHECKSIGVERIFY can be simulated by '
> TXHASH  CHECKSIGFROMSTACKVERIFY'.
>
> I don't think that's quite right. BIP 118 anyprevout is done by taking
> the pubkey "P", marking it as "APO-capable" (by prefixing it with 0x01),
> and then getting a sighash and sig from the witness. Doing the same
> with TXHASH/CSFSV would just be replacing " CHECKSIGVERIFY" with
> "TXHASH  CSFSV" with the witness providing both the signature and
> txhash flag, just as separate elements rather than concatenated. (The
> "APO-capable" part is implicit in the "TXHASH" opcode)
>

Indeed. The TXHASH variant does require splitting the signature and txhash
flag across two stack items.  So it wouldn't be an operationally identical
drop in replacement.


> > In addition to the CTV and ANYPREVOUT applications, with
> > CHECKSIGFROMSTACKVERIFY we can verify signatures on arbitrary messages
> > signed by oracles for oracle applications.  This is where we see the
> > benefit of decomposing operations into primitive pieces.  By giving users
> > the ability to program their own use cases from components, we get more
> > applications out of fewer op codes!
>
> While I see the appeal of this from a language design perspective;
> I'm not sure it's really the goal we want. When I look at bitcoin's
> existing script, I see a lot of basic opcodes to do simple arithmetic and
> manipulate the stack in various ways, but the opcodes that are actually
> useful are more "do everything at once" things like check(multi)sig or
> sha256. It seems like what's most useful on the blockchain is a higher
> level language, rather than more of blockchain assembly language made
> up of small generic pieces. I guess "program their own use cases from
> components" seems to be coming pretty close to "write your own crypto
> algorithms" here...
>

Which operations in Script are actually composable today?

CHECKSIG composes with nothing else (other than possibly other CHECKSIGs)
as there are no other operations that manipulate pubkey keys or signature
data.

CLTV and CSV in principle can be composed with addition and subtraction and
comparison operations.  But where are you going to get other values to add
and subtract from?  I suppose you could compare the relative and absolute
locktimes to each other.

What do the HASH functions compose with?  Without CAT you cannot construct
messages to hash.  You can hash the result of the arithmetic operations,
but you are limited to hashing 32-bit (or 33-bit if you are generous)
strings, which is too little entropy to have any security properties.  You
can hash a public key or a signature I suppose.

I don't think there is much in the way of lessons to be drawn from how we
see Bitcoin Script used today with regards to programs built out of
reusable components.  User's haven't been composing programs, not because
they don't find composition useful, but rather because the existing
primitives do not lend themselves to being composed at all.

There is one aspect of Bitcoin Script that is composable, which is
(monotone) boolean combinations of the few primitive transaction conditions
that do exist.  The miniscript language captures nearly the entirety of
what is composable in Bitcoin Script today: which amounts to conjunctions,
disjunctions (and thresholds) of signatures, locktimes, and revealing hash
preimages.

TXHASH + CSFSV won't be enough by itself to allow for very interesting
programs Bitcoin Script yet, we still need CAT and friends for that, but
CSFSV is at least a step in that direction.  CSFSV can take arbitrary
messages and these messages can be fixed strings, or they can be hashes of
strings (that need to be revealed), or they can be hashes returned from
TXHASH, or they can be locktime values, or they can b

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[Michael Folkson via bitcoin-dev]

> Even if we were to adopt something like TXHASH, how long is it going to take 
> to develop, test, and release? My guess is "a while" - in the meantime, users 
> of Bitcoin are without a vault strategy that doesn't require either 
> presigning transactions with ephemeral keys (operationally difficult) or 
> multisig configurations that would make Rube Goldberg blush (operationally 
> difficult and precarious).

To me this seems to be jumping ahead a number of steps from where we are at the 
current time. If the ecosystem was widely using all the tools available to them 
at the current time (MuSig(2), Taproot trees to embed complex scripts, 
Miniscript etc), was testing out upcoming available tools like threshold key 
aggregation schemes (e.g. FROST) on signets and the final missing piece was a 
covenant opcode to avoid the deleted key requirement then the argument for 
urgency would be stronger. I would still share the concerns I and many others 
have repeated over rushing soft forks and treating mainnet as a testbed for new 
use cases rather than the final destination for changes that will stand the 
test of time. But I would be a lot more sympathetic to that argument.

This isn't a criticism of the ecosystem or individual vault projects like 
Revault, it is clearly still very early. darosior (Revault) is working on 
getting a first version of Miniscript finalized and in Core [0] and I'm 
assuming will be part of the effort to get Taproot support in Miniscript 
assuming that initial effort succeeds. Murch is tracking basic send and receive 
to the P2TR addresses (not complex scripts, multisig, MuSig(2), merely single 
key spends) in the ecosystem [1] and there is still a long way to go there.

There are a bunch of covenant opcodes that have been enabled on Liquid [2] that 
I haven't heard yet of anyone building vault prototypes with. It would be good 
to get others (TLUV, TXHASH) in future. There is not even a custom signet with 
CTV (as far as I know) for those who subscribe to the view that we must rush to 
get CTV activated on mainnet as soon as possible with no thought to what 
opcodes might follow.

When this discussion focuses on the pros and cons of various proposals and how 
they are being tested and used in prototypes on signets, sidechains I think it 
is really productive. But when it gets onto urgency (or worse activation 
speculation) I am just perplexed. That viewpoint seems to completely ignore 
where we are currently with Taproot use and tooling (on which most vault 
designs will presumably build) and even more perplexingly where we are with 
vault prototypes on signets, sidechains.

I am sure at some point in the future we will have various vault prototypes on 
signets, sidechains making use of Taproot, Miniscript, MuSig(2), FROST etc and 
crying out for a covenant opcode or sighash flag to go into production on 
mainnet. But we seem miles away from that at the present time.

[0]: https://github.com/bitcoin/bitcoin/pull/24147
[1]: https://en.bitcoin.it/wiki/Bech32_adoption
[2]: 
https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

‐‐‐ Original Message ‐‐‐
On Friday, January 28th, 2022 at 12:18 AM, James O'Beirne via bitcoin-dev 
 wrote:

>> I don't think implementing a CTV opcode that we expect to largely be 
>> obsoleted by a TXHASH at a later date is yielding good value from a soft 
>> fork process.
>
> This presumes the eventual adoption of TXHASH (or something like it). You're 
> presenting a novel idea that, as far as I know, hasn't had much time to bake 
> in public. Like Jeremy, I'm concerned by the combinatorial growth of flags 
> and the implications that has for testing. Caching for something like TXHASH 
> looks to me like a whole different ballgame relative to CTV, which has a 
> single kind of hash.
>
> Even if we were to adopt something like TXHASH, how long is it going to take 
> to develop, test, and release? My guess is "a while" - in the meantime, users 
> of Bitcoin are without a vault strategy that doesn't require either 
> presigning transactions with ephemeral keys (operationally difficult) or 
> multisig configurations that would make Rube Goldberg blush (operationally 
> difficult and precarious). The utility of vaulting seems underappreciated 
> among consensus devs and it's something I'd like to write about soon in a 
> separate post.
>
>> The strongest argument I can make in favour of CTV would be something like: 
>> "We definitely want bare CTV and if we are going to add CTV to legacy script 
>> (since we cannot use TXHASH in legacy script), then it is actually easier 
>> not to exclude it from tapscript, even if we plan to add TXHASH to tapscript 
>> as well."
>
> Another argument for CTV (which I find especially persuasive) is its 
> simplicity - it's relativel

Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT

[James O'Beirne via bitcoin-dev]

> I don't think implementing a CTV opcode that we expect to largely be
obsoleted by a TXHASH at a later date is yielding good value from a soft
fork process.

This presumes the eventual adoption of TXHASH (or something like it).
You're presenting a novel idea that, as far as I know, hasn't had much time
to bake in public. Like Jeremy, I'm concerned by the combinatorial growth
of flags and the implications that has for testing. Caching for something
like TXHASH looks to me like a whole different ballgame relative to CTV,
which has a single kind of hash.

Even if we were to adopt something like TXHASH, how long is it going to
take to develop, test, and release? My guess is "a while" - in the
meantime, users of Bitcoin are without a vault strategy that doesn't
require either presigning transactions with ephemeral keys (operationally
difficult) or multisig configurations that would make Rube Goldberg blush
(operationally difficult and precarious). The utility of vaulting seems
underappreciated among consensus devs and it's something I'd like to write
about soon in a separate post.

> The strongest argument I can make in favour of CTV would be something
like: "We definitely want bare CTV and if we are going to add CTV to legacy
script (since we cannot use TXHASH in legacy script), then it is actually
easier not to exclude it from tapscript, even if we plan to add TXHASH to
tapscript as well."

Another argument for CTV (which I find especially persuasive) is its
simplicity - it's relatively easy to reason about and, at this point,
pretty well understood. It seems like a low-risk change relative to some of
the other covenant proposals, nearly all of which elicit a good deal of
headscratching (at least from me) and seem to require not only larger
on-chain footprints but sizable code changes.

> I am sensitive to technical debt and soft fork processes

If OP_CTV ends up being the most practical approach for vaulting - among
other things - in terms of weight (which it seems to be at the moment) I
don't think "technical debt" is an applicable term.

On Thu, Jan 27, 2022 at 5:20 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I am sensitive to technical debt and soft fork processes, and I don't
> believe I'm unordinary particular about these issues.  Once implemented,
> opcodes must be supported and maintained indefinitely.  Some opcodes are
> easier to maintain than others.  These particular opcodes involve caching
> of hash computations and, for that reason, I would judge them to be of
> moderate complexity.
>
> But more importantly, soft-forks are inherently a risky process, so we
> should be getting as much value out of them as we reasonably can. I don't
> think implementing a CTV opcode that we expect to largely be obsoleted by a
> TXHASH at a later date is yielding good value from a soft fork process.
>
> The strongest argument I can make in favour of CTV would be something
> like: "We definitely want bare CTV and if we are going to add CTV to legacy
> script (since we cannot use TXHASH in legacy script), then it is actually
> easier not to exclude it from tapscript, even if we plan to add TXHASH to
> tapscript as well."
>
> But that argument basically rests the entire value of CTV on the shoulders
> of bare CTV.  As I understand, the argument for why we want bare CTV,
> instead of just letting people use tapscript, involves the finer details of
> weight calculations, and I haven't really reviewed that aspect yet.  I
> think it would need to be pretty compelling to make it worthwhile to add
> CTV for that one use case.
>
>
> Regarding "OP_TXHASH+CSFSV doesn't seem to be the 'full' set of things
> needed", I totally agree we will want more things such as CAT, rolling
> SHA256 opcodes, wider arithmetic, pushing amounts onto the stack, some kind
> of tapleaf manipulation and/or TWEAKVERIFY.  For now, I only want to argue
> TXHASH+CSFSV is better than CTV+APO because it gives us more value, namely
> oracle signature verification.  In particular, I want to argue that
> TXHASH's push semantics is better that CTV's verify semantics because it
> composes better by not needing to carry an extra 32-bytes (per instance) in
> the witness data.  I expect that in a world of full recursive covenants,
> TXHASH would still be useful as a fast and cheap way to verify the
> "payload" of these covenants, i.e. that a transaction is paying a certain,
> possibly large, set of addresses certain specific amounts of money.  And
> even if not, TXHASH+CSFSV would still be the way that eltoo would be
> implemented under this proposal.
>
> On Wed, Jan 26, 2022 at 5:16 PM Jeremy  wrote:
>
>> Hi Russell,
>>
>> Thanks for this email, it's great to see this approach described.
>>
>> A few preliminary notes of feedback:
>>
>> 1) a Verify approach can be made to work for OP_TXHASH (even with CTV
>> as-is) E.g., suppose a semantic added for a single byte stack[-1] sighash
>> flag to read the hash at stack[-2],