[bitcoin-dev] CTV BIP review

[bitcoin-dev] CTV BIP review

[Luke Dashjr]

tl;dr: I don't think CTV is ready yet (but probably close), and in any case 
definitely not worth reviving BIP 9 with its known flaws and vulnerability.

My review here is based solely on the BIP, with no outside context (aside from 
current consensus rules, of course). In particular, I have _not_ looked at 
the CTV code proposed for Bitcoin Core yet.

>Covenants are restrictions on how a coin may be spent beyond key ownership. 

nit: Poorly phrased. Even simple scripts can do that already.

>A few examples are described below, which should be the subject of future 
non-consensus standardization efforts.

I would ideally like to see fully implemented BIPs for at least one of these 
(preferably the claimed CoinJoin improvements) before we move toward 
activation.

>Congestion Controlled Transactions

I think this use case hasn't been fully thought through yet. It seems like it 
would be desirable for this purpose, to allow any of the recipients to claim 
their portion of the payment without footing the fee for every other payment 
included in the batch. This is still a covenant-type solution, but one that 
BIP 119 cannot support as-is.

(I realise this may be a known and accepted limitation, but I think it should 
be addressed in the BIP)

>Payment Channels

Why batch mere channel creation? Seems like the spending transaction should 
really be the channel closing.

>CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than 
previously because participants agree on a single output which pays all 
participants, which will be lower fee than before.

I don't see how. They still have to agree in advance on the outputs, and the 
total fees will logically be higher than not using CTV...?

>Further Each participant doesn't need to know the totality of the outputs 
committed to by that output, they only have to verify their own sub-tree will 
pay them.

I don't see any way to do this with the provided implementation.

>Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.

Hard NACK on this. BIP 9 at this point represents developers attempting to 
disregard and impose their will over community consensus, as well as an 
attempt to force a miner veto backdoor/vulnerability on deployment. It should 
never be used again.

Speedy Trial implemented with BIP 8 made sense* as a possible neutral 
compromise between LOT=True and LOT=False (which could be deployed prior to 
or in parallel), but using BIP 9 would destroy this.

As with Taproot, any future deployments should use BIP 8 again, until a better 
solution is developed. Reverting back to a known flawed and vulnerable 
activation method should not be done, and it would be better not to deploy 
CTV at all at such an expense.

The fact that certain developers attempted to deploy a BIP 9 alternative 
activation for Taproot against community consensus, and that even managed to 
get released as "Bitcoin Core", makes it all the more important that the 
community firmly rejects any further action to force this regression.

* it is my opinion a BIP 8 ST would be an okay compromise under those 
circumstances; others do disagree that ST is acceptable at all

> This ensures that for a given known input, the TXIDs can also be known ahead 
of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched 
Channel Creation constructions as the redemption TXID could be malleated and 
pre-signed transactions invalidated, unless the channels are built using an 
Eltoo-like protocol.

Why is it a problem for them to use an Eltoo-like protocol?

Why not just commit to the txid itself if that's the goal?

>P2SH is incompatible with CHECKTEMPLATEVERIFY 

Maybe the CTV opcode should only be defined/enforced within witness scripts?

>nLockTime should generally be fixed to 0 (in the case of a payment tree, only 
the *first* lock time is needed to prevent fee-sniping the root)

Your "Congestion Controlled Transactions" example would only make sense with 
the spending transaction much later than the "root", and so could benefit 
from fee sniping malleability. (In fact, in that example, it would be better 
not to commit to locktime at all.)

>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to 
simple templates. The structure of CHECKTEMPLATEVERIFY template is such that 
the outputs must be known exactly at the time of construction. Based on a 
destructuring argument, it is only possible to create templates which expand 
in a finite number of steps.

It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get added.

>For example, a exchange's hot wallet might use an address which can 
automatically be moved to a cold storage address after a relative timeout.

Wouldn't it make more sense to just have a UTXO both cold+hot can spend, then 
throw away the hot key?

>In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make scripts 
valid for policy until the new rule is active.

Policy isn't validity, and cannot be dictated by BIPs (or anyone/anything, for 
that matter).

Luke

Re: [bitcoin-dev] CTV BIP review

[eric]

I won't comment on CTV at this point, but these comments on BIP9 and BIP8
deserve a response, given the intense obfuscation below.

The only material distinction between BIP9 and BIP8 is that the latter may
activate without signaled support of hash power enforcement.

As unenforced soft forks are not "backward compatible" they produce a chain
split. It was for this reason alone that BIP8 never gained sufficient
support.

Taproot activation was in no way a compromise between enforced and
unenforced activation. Unenforced activation was wholly rejected.

> BIP 9 at this point represents developers attempting to disregard and
impose their will over community consensus, as well as an attempt to force a
miner veto backdoor/vulnerability on deployment. It should never be used
again."

This appears to be the start of another marketing campaign, an attempt to
reclaim Taproot activation as some sort of "win" over the "miner backdoor".
The same sort of misleading campaign was waged in the wake of segwit, and
led directly to the conflict around Taproot activation.

The differences between ST and BIP9 are inconsequential in this regard. The
criticism you are making of BIP9 above applies equally to ST.

> As with Taproot, any future deployments should use BIP 8 again

This is one of the most misleading statements I've seen here. It's not
technically a lie, because it states what "should" happen. But it is clearly
intended to lead people to believe that BIP8 was actually used ("again") -
it was not. ST was some technical tweaks to BIP9.

I am making no statement whatsoever on what "should" happen. My interest is
in providing accurate information so that people can make informed
decisions.

The outright deception around this one topic has led to significant
unnecessary conflict in the community. Make your argument, but make it
honestly.

e

> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> On
Behalf
> Of Luke Dashjr via bitcoin-dev
> Sent: Tuesday, January 18, 2022 1:19 PM
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] CTV BIP review
> 
> tl;dr: I don't think CTV is ready yet (but probably close), and in any
case
> definitely not worth reviving BIP 9 with its known flaws and
vulnerability.
...
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
> 
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should never be used again.
> 
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed
> prior to or in parallel), but using BIP 9 would destroy this.
> 
> As with Taproot, any future deployments should use BIP 8 again, until a
better
> solution is developed. Reverting back to a known flawed and vulnerable
> activation method should not be done, and it would be better not to deploy
> CTV at all at such an expense.
> 
> The fact that certain developers attempted to deploy a BIP 9 alternative
> activation for Taproot against community consensus, and that even managed
> to get released as "Bitcoin Core", makes it all the more important that
the
> community firmly rejects any further action to force this regression.
> 
> * it is my opinion a BIP 8 ST would be an okay compromise under those
> circumstances; others do disagree that ST is acceptable at all

Re: [bitcoin-dev] CTV BIP review

[Luke Dashjr]

On Tuesday 18 January 2022 22:02:24 eric@voskuil.org wrote:
> The only material distinction between BIP9 and BIP8 is that the latter may
> activate without signaled support of hash power enforcement.
>
> As unenforced soft forks are not "backward compatible" they produce a chain
> split.

Enforcement of the Bitcoin consensus protocol is by users, not miners.

Softforks never produce a chain split. Miners can, and might try to do it to 
cause disruption in retaliation, but the softfork itself does not.

> It was for this reason alone that BIP8 never gained sufficient 
> support.

BIP 8 in fact achieved consensus for Taproot activation.

> This is one of the most misleading statements I've seen here. It's not
> technically a lie, because it states what "should" happen. But it is
> clearly intended to lead people to believe that BIP8 was actually used
> ("again") - it was not. ST was some technical tweaks to BIP9.

BIP 8 was used to activate Taproot.

> The outright deception around this one topic has led to significant
> unnecessary conflict in the community. Make your argument, but make it
> honestly.

You are the one attempting to deceive here.

Luke

Re: [bitcoin-dev] CTV BIP review

[eric]

> -----Original Message-----
> From: Luke Dashjr <luke@dashjr.org>
> Sent: Tuesday, January 18, 2022 2:10 PM
> To: eric@voskuil.org
> Cc: 'Bitcoin Protocol Discussion' <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] CTV BIP review
> 
> On Tuesday 18 January 2022 22:02:24 eric@voskuil.org wrote:
> > The only material distinction between BIP9 and BIP8 is that the latter
> > may activate without signaled support of hash power enforcement.
> >
> > As unenforced soft forks are not "backward compatible" they produce a
> > chain split.
> 
> Enforcement of the Bitcoin consensus protocol is by users, not miners.

Given that I stated "hash power enforcement" it is quite clear that this is
in fact only produced by mining. You are misrepresenting my statement to
make an emotional appeal. Without "hash power enforcement", a soft fork is
NOT backward compatible.

"[enforcement of] consensus protocol" is of course by merchants, but that is
not the question at hand. The question is explicitly compatibility. Anyone
can activate a soft fork at any time, but without "hash power enforcement"
soft forks are NOT backward compatible.

> Softforks never produce a chain split. Miners can, and might try to do it
to cause disruption in retaliation, but the softfork itself does not.

Maybe you are trying to split hairs given the fact that blocks are produced
only by miners, so only miners can "cause" a split.

But through not intention ("disruption in retaliation") whatsoever by
mining, a soft fork will result in those activating the rule being split off
the original chain unless majority hash power enforces the rule. The fact
that doing nothing apart from deploying the rule will result in a split is
the very definition of NOT compatible.

I assume you will argue that the original chain is not "valid" and therefore
irrelevant (as if no chain split occurred). But again the point is about
compatibility. The appearance of multiple chains, which appear valid
according to either the previous or new rules, is obviously the
incompatibility.

I shouldn't have to point this out, but observed chain splits have occurred
in more the one large scale soft fork deployment. These splits have only
been resolved through hash power enforcement. In 2010 it took 51 blocks
before the current chain took the lead. In 2012 minority chains persisted
for months. The deployment of soft forks caused these splits, NOT the
actions of miners. And unless majority hash power eventually enforces it,
the soft fork branch necessarily dies.

> > It was for this reason alone that BIP8 never gained sufficient
> > support.
> 
> BIP 8 in fact achieved consensus for Taproot activation.

Please define "achieved consensus", because by any definition I can imagine,
this is simply untrue.

> > This is one of the most misleading statements I've seen here. It's not
> > technically a lie, because it states what "should" happen. But it is
> > clearly intended to lead people to believe that BIP8 was actually used
> > ("again") - it was not. ST was some technical tweaks to BIP9.
> 
> BIP 8 was used to activate Taproot.

No, it wasn't. I find it hard to imaging how you rationalize such grossly
misleading statements.

> > The outright deception around this one topic has led to significant
> > unnecessary conflict in the community. Make your argument, but make it
> > honestly.
> 
> You are the one attempting to deceive here.

That is for others to decide. I appreciate your responses above, since they
certainly help clarify what is happening here.

e

Re: [bitcoin-dev] CTV BIP review

[Michael Folkson]

Eric, Luke

Can I request that you don't discuss activation methods for future soft forks on a thread for CTV BIP review? I (and a number of others [0]) do not support an upcoming activation attempt of standalone OP_CTV. If you want to discuss activation methods for soft forks generally it would be much better if you set up a separate thread. OP_CTV is not the only current soft fork proposal and there will likely be more.

The activation discussion for Taproot was deliberately kept separate from the review of the Taproot BIPs and implementation. It only commenced once there was overwhelming community consensus for the soft fork to be activated (months after in fact). Though you are free to discuss whatever topics you wish (obviously) discussing soft fork activation methods on a OP_CTV thread might give the mistaken impression that OP_CTV is the next soft fork to be activated which is mere speculation at this point. In an ideal world the promoters of OP_CTV would follow the strong precedent set by the authors and contributors to the Taproot BIPs but regrettably that seems to have gone out the window at this point.

Thanks
Michael

[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
--
Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> -----Original Message-----
>
> From: Luke Dashjr luke@dashjr.org
>
> Sent: Tuesday, January 18, 2022 2:10 PM
>
> To: eric@voskuil.org
>
> Cc: 'Bitcoin Protocol Discussion' bitcoin-dev@lists.linuxfoundation.org
>
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 eric@voskuil.org wrote:
>
> > The only material distinction between BIP9 and BIP8 is that the latter
> >
> > may activate without signaled support of hash power enforcement.
> >
> > As unenforced soft forks are not "backward compatible" they produce a
> >
> > chain split.
>
> Enforcement of the Bitcoin consensus protocol is by users, not miners.

Given that I stated "hash power enforcement" it is quite clear that this is

in fact only produced by mining. You are misrepresenting my statement to

make an emotional appeal. Without "hash power enforcement", a soft fork is

NOT backward compatible.

"[enforcement of] consensus protocol" is of course by merchants, but that is

not the question at hand. The question is explicitly compatibility. Anyone

can activate a soft fork at any time, but without "hash power enforcement"

soft forks are NOT backward compatible.

> Softforks never produce a chain split. Miners can, and might try to do it

to cause disruption in retaliation, but the softfork itself does not.

Maybe you are trying to split hairs given the fact that blocks are produced

only by miners, so only miners can "cause" a split.

But through not intention ("disruption in retaliation") whatsoever by

mining, a soft fork will result in those activating the rule being split off

the original chain unless majority hash power enforces the rule. The fact

that doing nothing apart from deploying the rule will result in a split is

the very definition of NOT compatible.

I assume you will argue that the original chain is not "valid" and therefore

irrelevant (as if no chain split occurred). But again the point is about

compatibility. The appearance of multiple chains, which appear valid

according to either the previous or new rules, is obviously the

incompatibility.

I shouldn't have to point this out, but observed chain splits have occurred

in more the one large scale soft fork deployment. These splits have only

been resolved through hash power enforcement. In 2010 it took 51 blocks

before the current chain took the lead. In 2012 minority chains persisted

for months. The deployment of soft forks caused these splits, NOT the

actions of miners. And unless majority hash power eventually enforces it,

the soft fork branch necessarily dies.

> > It was for this reason alone that BIP8 never gained sufficient
> >
> > support.
>
> BIP 8 in fact achieved consensus for Taproot activation.

Please define "achieved consensus", because by any definition I can imagine,

this is simply untrue.

> > This is one of the most misleading statements I've seen here. It's not
> >
> > technically a lie, because it states what "should" happen. But it is
> >
> > clearly intended to lead people to believe that BIP8 was actually used
> >
> > ("again") - it was not. ST was some technical tweaks to BIP9.
>
> BIP 8 was used to activate Taproot.

No, it wasn't. I find it hard to imaging how you rationalize such grossly

misleading statements.

> > The outright deception around this one topic has led to significant
> >
> > unnecessary conflict in the community. Make your argument, but make it
> >
> > honestly.
>
> You are the one attempting to deceive here.

That is for others to decide. I appreciate your responses above, since they

certainly help clarify what is happening here.

e

bitcoin-dev mailing list

bitcoin-dev@lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] CTV BIP review

[Billy Tetrud]

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

I'm curious to hear clarification on most of Luke's non-activation related
comments.

> I would ideally like to see fully implemented BIPs for at least one of
these

While that would be interesting, I think that's a heavy burden to be placed
on this BIP. More in depth exploration would be helpful, but a fully
implemented BIP I think is more than necessary.

> Why is it a problem for them to use an Eltoo-like protocol?

I think he was saying it is a problem *unless* its an eltoo-like protocol.
Why I'm not sure. Maybe you can clarify Jeremy?

> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get
added.

Even were these opcodes to be implemented in bitcoin, a script writer could
choose to not use them, making it still possible to use CTV to create
covenant chains with a finite number of steps.

>  w.r.t. the language cleanups... the legal definition of covenant ... I
do think things like CLTV/CSV are covenants

Maybe it would be useful to specify that these are "child covenants" or
"inherited covenants" or something like that, since unlike things like
CLTV, CTV and similar proposed opcodes place restrictions on the child
output of the output containing the opcode call, which is the interesting
unique behavior. Tho I don't think we need to be bound to the legal or
dictionary definition in usage of the word covenant in the realm of bitcoin
- its gonna have its own definition in this context anyway.

Thank you Eric for pointing out the factual errors in LukeJr's mention and
implications around BIP8. The fact is that the ST pull request was
described as "BIP9-based" <https://github.com/bitcoin/bitcoin/pull/21377>.
TBH BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8
nor BIP9, so characterization one way or another is moot IMO. In any case,
I also agree with Michael that this isn't the place to have a long
discussion about activation method. That discussion should be kept
separate. I'd go so far to say that BIPs should not advocate for any
particular activation method, but should only go so far as to mention what
types of activation methods are possible (if some types aren't possible for
some reason). Separation of concerns would be very useful on that front
to reduce noise in conversations.

Thanks,
BT


On Wed, Jan 19, 2022 at 6:37 AM Michael Folkson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Eric, Luke
>
> Can I request that you don't discuss activation methods for future soft
> forks on a thread for CTV BIP review? I (and a number of others [0]) do not
> support an upcoming activation attempt of standalone OP_CTV. If you want to
> discuss activation methods for soft forks generally it would be much better
> if you set up a separate thread. OP_CTV is not the only current soft fork
> proposal and there will likely be more.
>
> The activation discussion for Taproot was deliberately kept separate from
> the review of the Taproot BIPs and implementation. It only commenced once
> there was overwhelming community consensus for the soft fork to be
> activated (months after in fact). Though you are free to discuss whatever
> topics you wish (obviously) discussing soft fork activation methods on a
> OP_CTV thread might give the mistaken impression that OP_CTV is the next
> soft fork to be activated which is mere speculation at this point. In an
> ideal world the promoters of OP_CTV would follow the strong precedent set
> by the authors and contributors to the Taproot BIPs but regrettably that
> seems to have gone out the window at this point.
>
> Thanks
> Michael
>
> [0]:
> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Tuesday, January 18th, 2022 at 11:00 PM, Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > -----Original Message-----
> >
> > From: Luke Dashjr luke@dashjr.org
> >
> > Sent: Tuesday, January 18, 2022 2:10 PM
> >
> > To: eric@voskuil.org
> >
> > Cc: 'Bitcoin Protocol Discussion' bitcoin-dev@lists.linuxfoundation.org
> >
> > Subject: Re: [bitcoin-dev] CTV BIP review
> >
> > On Tuesday 18 January 2022 22:02:24 eric@voskuil.org wrote:
> >
> > > The only material distinction between BIP9 and BIP8 is that the latter
> > >
> > > may activate without signaled support of hash power enforcement.
> > >
> > > As unenforced soft forks are not "backward compatible" they produce a
> > >
> > > chain split.
> >
> > Enforcement of the Bitcoin consensus protocol is by users, not miners.
>
> Given that I stated "hash power enforcement" it is quite clear that this is
>
> in fact only produced by mining. You are misrepresenting my statement to
>
> make an emotional appeal. Without "hash power enforcement", a soft fork is
>
> NOT backward compatible.
>
> "[enforcement of] consensus protocol" is of course by merchants, but that
> is
>
> not the question at hand. The question is explicitly compatibility. Anyone
>
> can activate a soft fork at any time, but without "hash power enforcement"
>
> soft forks are NOT backward compatible.
>
> > Softforks never produce a chain split. Miners can, and might try to do it
>
> to cause disruption in retaliation, but the softfork itself does not.
>
> Maybe you are trying to split hairs given the fact that blocks are produced
>
> only by miners, so only miners can "cause" a split.
>
> But through not intention ("disruption in retaliation") whatsoever by
>
> mining, a soft fork will result in those activating the rule being split
> off
>
> the original chain unless majority hash power enforces the rule. The fact
>
> that doing nothing apart from deploying the rule will result in a split is
>
> the very definition of NOT compatible.
>
> I assume you will argue that the original chain is not "valid" and
> therefore
>
> irrelevant (as if no chain split occurred). But again the point is about
>
> compatibility. The appearance of multiple chains, which appear valid
>
> according to either the previous or new rules, is obviously the
>
> incompatibility.
>
> I shouldn't have to point this out, but observed chain splits have occurred
>
> in more the one large scale soft fork deployment. These splits have only
>
> been resolved through hash power enforcement. In 2010 it took 51 blocks
>
> before the current chain took the lead. In 2012 minority chains persisted
>
> for months. The deployment of soft forks caused these splits, NOT the
>
> actions of miners. And unless majority hash power eventually enforces it,
>
> the soft fork branch necessarily dies.
>
> > > It was for this reason alone that BIP8 never gained sufficient
> > >
> > > support.
> >
> > BIP 8 in fact achieved consensus for Taproot activation.
>
> Please define "achieved consensus", because by any definition I can
> imagine,
>
> this is simply untrue.
>
> > > This is one of the most misleading statements I've seen here. It's not
> > >
> > > technically a lie, because it states what "should" happen. But it is
> > >
> > > clearly intended to lead people to believe that BIP8 was actually used
> > >
> > > ("again") - it was not. ST was some technical tweaks to BIP9.
> >
> > BIP 8 was used to activate Taproot.
>
> No, it wasn't. I find it hard to imaging how you rationalize such grossly
>
> misleading statements.
>
> > > The outright deception around this one topic has led to significant
> > >
> > > unnecessary conflict in the community. Make your argument, but make it
> > >
> > > honestly.
> >
> > You are the one attempting to deceive here.
>
> That is for others to decide. I appreciate your responses above, since they
>
> certainly help clarify what is happening here.
>
> e
>
> 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
>

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

Re: [bitcoin-dev] CTV BIP review

[eric]

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

> BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor BIP9, so characterization one way or another is moot IMO.

 

For a selective definition of “based” you can draw any conclusion you desire. However I was very clear, as was Luke, and the history on this issue is equally clear, that the *only* material distinction (and the one that we are discussing) is activation with or without majority hash power support. BIP9/ST requires this support, BIP8 does not. The characterization is not moot. It is the central issue and always has been. There was no compromise on this question made in Taproot.

 

e

 

From: Billy Tetrud <billy.tetrud@gmail.com> 
Sent: Thursday, January 20, 2022 7:23 AM



Thank you Eric for pointing out the factual errors in LukeJr's mention and implications around BIP8. The fact is that the ST pull request was described as  <https://github.com/bitcoin/bitcoin/pull/21377> "BIP9-based". TBH BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor BIP9, so characterization one way or another is moot IMO. In any case, I also agree with Michael that this isn't the place to have a long discussion about activation method. That discussion should be kept separate. I'd go so far to say that BIPs should not advocate for any particular activation method, but should only go so far as to mention what types of activation methods are possible (if some types aren't possible for some reason). Separation of concerns would be very useful on that front to reduce noise in conversations.

 

Thanks,

BT

 


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

Re: [bitcoin-dev] CTV BIP review

[Billy Tetrud]

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

>  the **only** material distinction (and the one that we are discussing)
is activation with or without majority hash power support

I agree that characterization specifically is not moot. But its also
orthogonal to the topic of the CTV opcode itself.

On Thu, Jan 20, 2022 at 4:03 PM <eric@voskuil.org> wrote:

> > BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8
> nor BIP9, so characterization one way or another is moot IMO.
>
>
>
> For a selective definition of “based” you can draw any conclusion you
> desire. However I was very clear, as was Luke, and the history on this
> issue is equally clear, that the **only** material distinction (and the
> one that we are discussing) is activation with or without majority hash
> power support. BIP9/ST requires this support, BIP8 does not. The
> characterization is not moot. It is the central issue and always has been.
> There was no compromise on this question made in Taproot.
>
>
>
> e
>
>
>
> *From:* Billy Tetrud <billy.tetrud@gmail.com>
> *Sent:* Thursday, January 20, 2022 7:23 AM
>
> Thank you Eric for pointing out the factual errors in LukeJr's mention and
> implications around BIP8. The fact is that the ST pull request was
> described as "BIP9-based" <https://github.com/bitcoin/bitcoin/pull/21377>.
> TBH BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8
> nor BIP9, so characterization one way or another is moot IMO. In any case,
> I also agree with Michael that this isn't the place to have a long
> discussion about activation method. That discussion should be kept
> separate. I'd go so far to say that BIPs should not advocate for any
> particular activation method, but should only go so far as to mention what
> types of activation methods are possible (if some types aren't possible for
> some reason). Separation of concerns would be very useful on that front
> to reduce noise in conversations.
>
>
>
> Thanks,
>
> BT
>
>
>

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

Re: [bitcoin-dev] CTV BIP review

[Jeremy]

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

Thanks for the detailed review.

I'll withhold comment around activation logic and leave that for others to
discuss.

w.r.t. the language cleanups I'll make a PR that (I hope) clears up the
small nits later today or tomorrow. Some of it's kind of annoying because
the legal definition of covenant is "A formal agreement or promise, usually
included in a contract or deed, to do or not do a particular act; a compact
or stipulation made in writing or by parol." so I do think things like
CLTV/CSV are covenants since it's a binding promise to not spend before a
certain time... it might be out of scope for the BIP to fully define these
terms because it doesn't really matter what a covenant could be as much as
it matters what CTV is specifically.

On the topic of drafting BIPs for specific use cases, I agree that would be
valuable and can consider it.

However, I'm a bit skeptical of that approach overall as I don't
necessarily think that the applications *must be* standard, and I view BIPs
as primarily for standardization whereas part of the flexibility of
CTV/Sapio allows users to figure out how they want to use it.

E.g., we do not yet have a BIP for MuSig or even Multisig in Taproot,
although there are some papers and example implementations but nothing
formal yet
https://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multisig-descriptors).
Perhaps this is an opportunity for CTV to lead on the amount of formal
application designs available before 'release'.

As a starting point, maybe you could review some of the application focused
posts in rubin.io/advent21 and let me know where they seem deficient?

Also a BIP describing how to build something like Sapio (and less so Sapio
itself, since it's still early days for that) might help for folks to be
able to think through how to compile to CTV contracts? But again, I'm
skeptical of the value of a BIP v.s. the documentation and examples
available in the code and https://learn.sapio-lang.org.

I think it's an interesting discussion too because as we've just seen the
LN ecosystem start the BLIP standards, would an example of non-interactive
channels be best written up as a BIP, a BLIP, or a descriptive blog/mailing
list post?

--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> tl;dr: I don't think CTV is ready yet (but probably close), and in any
> case
> definitely not worth reviving BIP 9 with its known flaws and vulnerability.
>
> My review here is based solely on the BIP, with no outside context (aside
> from
> current consensus rules, of course). In particular, I have _not_ looked at
> the CTV code proposed for Bitcoin Core yet.
>
> >Covenants are restrictions on how a coin may be spent beyond key
> ownership.
>
> nit: Poorly phrased. Even simple scripts can do that already.
>
> >A few examples are described below, which should be the subject of future
> non-consensus standardization efforts.
>
> I would ideally like to see fully implemented BIPs for at least one of
> these
> (preferably the claimed CoinJoin improvements) before we move toward
> activation.
>
> >Congestion Controlled Transactions
>
> I think this use case hasn't been fully thought through yet. It seems like
> it
> would be desirable for this purpose, to allow any of the recipients to
> claim
> their portion of the payment without footing the fee for every other
> payment
> included in the batch. This is still a covenant-type solution, but one
> that
> BIP 119 cannot support as-is.
>
> (I realise this may be a known and accepted limitation, but I think it
> should
> be addressed in the BIP)
>
> >Payment Channels
>
> Why batch mere channel creation? Seems like the spending transaction
> should
> really be the channel closing.
>
> >CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins
> than
> previously because participants agree on a single output which pays all
> participants, which will be lower fee than before.
>
> I don't see how. They still have to agree in advance on the outputs, and
> the
> total fees will logically be higher than not using CTV...?
>
> >Further Each participant doesn't need to know the totality of the outputs
> committed to by that output, they only have to verify their own sub-tree
> will
> pay them.
>
> I don't see any way to do this with the provided implementation.
>
> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
> Trial.
>
> Hard NACK on this. BIP 9 at this point represents developers attempting to
> disregard and impose their will over community consensus, as well as an
> attempt to force a miner veto backdoor/vulnerability on deployment. It
> should
> never be used again.
>
> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
> compromise between LOT=True and LOT=False (which could be deployed prior
> to
> or in parallel), but using BIP 9 would destroy this.
>
> As with Taproot, any future deployments should use BIP 8 again, until a
> better
> solution is developed. Reverting back to a known flawed and vulnerable
> activation method should not be done, and it would be better not to deploy
> CTV at all at such an expense.
>
> The fact that certain developers attempted to deploy a BIP 9 alternative
> activation for Taproot against community consensus, and that even managed
> to
> get released as "Bitcoin Core", makes it all the more important that the
> community firmly rejects any further action to force this regression.
>
> * it is my opinion a BIP 8 ST would be an okay compromise under those
> circumstances; others do disagree that ST is acceptable at all
>
> > This ensures that for a given known input, the TXIDs can also be known
> ahead
> of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched
> Channel Creation constructions as the redemption TXID could be malleated
> and
> pre-signed transactions invalidated, unless the channels are built using
> an
> Eltoo-like protocol.
>
> Why is it a problem for them to use an Eltoo-like protocol?
>
> Why not just commit to the txid itself if that's the goal?
>
> >P2SH is incompatible with CHECKTEMPLATEVERIFY
>
> Maybe the CTV opcode should only be defined/enforced within witness
> scripts?
>
> >nLockTime should generally be fixed to 0 (in the case of a payment tree,
> only
> the *first* lock time is needed to prevent fee-sniping the root)
>
> Your "Congestion Controlled Transactions" example would only make sense
> with
> the spending transaction much later than the "root", and so could benefit
> from fee sniping malleability. (In fact, in that example, it would be
> better
> not to commit to locktime at all.)
>
> >In the CHECKTEMPLATEVERIFY approach, the covenants are severely
> restricted to
> simple templates. The structure of CHECKTEMPLATEVERIFY template is such
> that
> the outputs must be known exactly at the time of construction. Based on a
> destructuring argument, it is only possible to create templates which
> expand
> in a finite number of steps.
>
> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get
> added.
>
> >For example, a exchange's hot wallet might use an address which can
> automatically be moved to a cold storage address after a relative timeout.
>
> Wouldn't it make more sense to just have a UTXO both cold+hot can spend,
> then
> throw away the hot key?
>
> >In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make
> scripts
> valid for policy until the new rule is active.
>
> Policy isn't validity, and cannot be dictated by BIPs (or anyone/anything,
> for
> that matter).
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] CTV BIP review

[Alex Schoof]

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

Hey Jeremy,

> On the topic of drafting BIPs for specific use cases, I agree that would
be valuable and can consider it.
> However, I'm a bit skeptical of that approach overall as I don't
necessarily think that the applications *must be* standard, and I view BIPs
as primarily for standardization whereas part of the flexibility of
CTV/Sapio allows users to figure out how they want to use it.

Electronic components (think an integrated circuit or a capacitor) usually
have both a "data sheet" and a set of "application notes". The data sheet
is like a spec or the formal documentation: how the thing works (or is
intended to work), precise dimensions and tolerances, etc. On the other
hand, the Application Notes are either a separate document or an appendix
to the data sheet with specific details about using that component in a
specific application: things like schematics for an example implementation,
things to watch out for (edge cases or unexpected application-specific
behavior, etc.). I appreciate the balance you're trying to strike between
having the BIP for CTV have enough details about how you think it might be
used and having it exclusively be a spec to help drive standardization.
Maybe the solution here is to have some explicit application notes that
have enough details to give people a sense of how these uses could be built
out, but still have it be clear that they are a use of, not a part of CTV
itself by having it either in a linked document or an appendix or
something.

Just a suggestion.

Cheers,

Alex

On Tue, Jan 18, 2022 at 6:54 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks for the detailed review.
>
> I'll withhold comment around activation logic and leave that for others to
> discuss.
>
> w.r.t. the language cleanups I'll make a PR that (I hope) clears up the
> small nits later today or tomorrow. Some of it's kind of annoying because
> the legal definition of covenant is "A formal agreement or promise,
> usually included in a contract or deed, to do or not do a particular act; a
> compact or stipulation made in writing or by parol." so I do think things
> like CLTV/CSV are covenants since it's a binding promise to not spend
> before a certain time... it might be out of scope for the BIP to fully
> define these terms because it doesn't really matter what a covenant could
> be as much as it matters what CTV is specifically.
>
> On the topic of drafting BIPs for specific use cases, I agree that would
> be valuable and can consider it.
>
> However, I'm a bit skeptical of that approach overall as I don't
> necessarily think that the applications *must be* standard, and I view BIPs
> as primarily for standardization whereas part of the flexibility of
> CTV/Sapio allows users to figure out how they want to use it.
>
> E.g., we do not yet have a BIP for MuSig or even Multisig in Taproot,
> although there are some papers and example implementations but nothing
> formal yet
> https://bitcoin.stackexchange.com/questions/111666/support-for-taproot-multisig-descriptors).
> Perhaps this is an opportunity for CTV to lead on the amount of formal
> application designs available before 'release'.
>
> As a starting point, maybe you could review some of the application
> focused posts in rubin.io/advent21 and let me know where they seem
> deficient?
>
> Also a BIP describing how to build something like Sapio (and less so Sapio
> itself, since it's still early days for that) might help for folks to be
> able to think through how to compile to CTV contracts? But again, I'm
> skeptical of the value of a BIP v.s. the documentation and examples
> available in the code and https://learn.sapio-lang.org.
>
> I think it's an interesting discussion too because as we've just seen the
> LN ecosystem start the BLIP standards, would an example of non-interactive
> channels be best written up as a BIP, a BLIP, or a descriptive blog/mailing
> list post?
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Tue, Jan 18, 2022 at 1:19 PM Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> tl;dr: I don't think CTV is ready yet (but probably close), and in any
>> case
>> definitely not worth reviving BIP 9 with its known flaws and
>> vulnerability.
>>
>> My review here is based solely on the BIP, with no outside context (aside
>> from
>> current consensus rules, of course). In particular, I have _not_ looked
>> at
>> the CTV code proposed for Bitcoin Core yet.
>>
>> >Covenants are restrictions on how a coin may be spent beyond key
>> ownership.
>>
>> nit: Poorly phrased. Even simple scripts can do that already.
>>
>> >A few examples are described below, which should be the subject of
>> future
>> non-consensus standardization efforts.
>>
>> I would ideally like to see fully implemented BIPs for at least one of
>> these
>> (preferably the claimed CoinJoin improvements) before we move toward
>> activation.
>>
>> >Congestion Controlled Transactions
>>
>> I think this use case hasn't been fully thought through yet. It seems
>> like it
>> would be desirable for this purpose, to allow any of the recipients to
>> claim
>> their portion of the payment without footing the fee for every other
>> payment
>> included in the batch. This is still a covenant-type solution, but one
>> that
>> BIP 119 cannot support as-is.
>>
>> (I realise this may be a known and accepted limitation, but I think it
>> should
>> be addressed in the BIP)
>>
>> >Payment Channels
>>
>> Why batch mere channel creation? Seems like the spending transaction
>> should
>> really be the channel closing.
>>
>> >CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins
>> than
>> previously because participants agree on a single output which pays all
>> participants, which will be lower fee than before.
>>
>> I don't see how. They still have to agree in advance on the outputs, and
>> the
>> total fees will logically be higher than not using CTV...?
>>
>> >Further Each participant doesn't need to know the totality of the
>> outputs
>> committed to by that output, they only have to verify their own sub-tree
>> will
>> pay them.
>>
>> I don't see any way to do this with the provided implementation.
>>
>> >Deployment could be done via BIP 9 VersionBits deployed through Speedy
>> Trial.
>>
>> Hard NACK on this. BIP 9 at this point represents developers attempting
>> to
>> disregard and impose their will over community consensus, as well as an
>> attempt to force a miner veto backdoor/vulnerability on deployment. It
>> should
>> never be used again.
>>
>> Speedy Trial implemented with BIP 8 made sense* as a possible neutral
>> compromise between LOT=True and LOT=False (which could be deployed prior
>> to
>> or in parallel), but using BIP 9 would destroy this.
>>
>> As with Taproot, any future deployments should use BIP 8 again, until a
>> better
>> solution is developed. Reverting back to a known flawed and vulnerable
>> activation method should not be done, and it would be better not to
>> deploy
>> CTV at all at such an expense.
>>
>> The fact that certain developers attempted to deploy a BIP 9 alternative
>> activation for Taproot against community consensus, and that even managed
>> to
>> get released as "Bitcoin Core", makes it all the more important that the
>> community firmly rejects any further action to force this regression.
>>
>> * it is my opinion a BIP 8 ST would be an okay compromise under those
>> circumstances; others do disagree that ST is acceptable at all
>>
>> > This ensures that for a given known input, the TXIDs can also be known
>> ahead
>> of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched
>> Channel Creation constructions as the redemption TXID could be malleated
>> and
>> pre-signed transactions invalidated, unless the channels are built using
>> an
>> Eltoo-like protocol.
>>
>> Why is it a problem for them to use an Eltoo-like protocol?
>>
>> Why not just commit to the txid itself if that's the goal?
>>
>> >P2SH is incompatible with CHECKTEMPLATEVERIFY
>>
>> Maybe the CTV opcode should only be defined/enforced within witness
>> scripts?
>>
>> >nLockTime should generally be fixed to 0 (in the case of a payment tree,
>> only
>> the *first* lock time is needed to prevent fee-sniping the root)
>>
>> Your "Congestion Controlled Transactions" example would only make sense
>> with
>> the spending transaction much later than the "root", and so could benefit
>> from fee sniping malleability. (In fact, in that example, it would be
>> better
>> not to commit to locktime at all.)
>>
>> >In the CHECKTEMPLATEVERIFY approach, the covenants are severely
>> restricted to
>> simple templates. The structure of CHECKTEMPLATEVERIFY template is such
>> that
>> the outputs must be known exactly at the time of construction. Based on a
>> destructuring argument, it is only possible to create templates which
>> expand
>> in a finite number of steps.
>>
>> It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get
>> added.
>>
>> >For example, a exchange's hot wallet might use an address which can
>> automatically be moved to a cold storage address after a relative timeout.
>>
>> Wouldn't it make more sense to just have a UTXO both cold+hot can spend,
>> then
>> throw away the hot key?
>>
>> >In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make
>> scripts
>> valid for policy until the new rule is active.
>>
>> Policy isn't validity, and cannot be dictated by BIPs (or
>> anyone/anything, for
>> that matter).
>>
>> Luke
>> _______________________________________________
>> 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
>


-- 


Alex Schoof

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

Re: [bitcoin-dev] CTV BIP review

[Anthony Towns]

On Tue, Jan 18, 2022 at 03:54:21PM -0800, Jeremy via bitcoin-dev wrote:
> Some of it's kind of annoying because
> the legal definition of covenant is [...]
> so I do think things like CLTV/CSV are covenants

I think that in the context of Bitcoin, the most useful definition of
covenant is that it's when the scriptPubKey of a utxo restricts the
scriptPubKey in the output(s) of a tx spending that utxo.

CTV, TLUV, etc do that; CSV, CLTV don't. ("checksig" per se doesn't
either, though of course the signature that checksig uses does -- if that
signature is in the scriptPubKey rather than the scriptSig or witness,
that potentially becomes a covenant too)

Cheers,
aj

Re: [bitcoin-dev] CTV BIP review

[Prayank]

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

Hi Luke,

This is the first competent review for CTV based on my understanding. I would not mention controversial things in this email but nobody cares about scammers and we will review everything irrespective of personal or legal attacks on developers because some people are prepared for it and capable, competent and healthy.

> nit: Poorly phrased. Even simple scripts can do that already.

Agree

> I would ideally like to see fully implemented BIPs for at least one of these (preferably the claimed CoinJoin improvements) before we move toward activation.

Agree

> Hard NACK on this. BIP 9 at this point represents developers attempting to disregard and impose their will over community consensus, as well as an attempt to force a miner veto backdoor/vulnerability on deployment. It should never be used again.

Agree

Other technical comments on BIP are appreciated however they would be better answered by Jeremy at this point or other as I am still researching and not confident to comment.

-- 
Prayank

A3B1 E430 2298 178F

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