Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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

Hi Michael,

> If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.

It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.


> It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.

I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.


> It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].

He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.


> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].

Because its not ready?


> Similar work has not been done for any of the speculated use cases of OP_CTV.

There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.

If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.


> Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.

We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.


> This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.

If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.


> I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.

I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.


> I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.

I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.


> Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.

Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.


-- 
Prayank

A3B1 E430 2298 178F

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Michael Folkson]

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

> It should be ready to go in a few months IMO

What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.

You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.

I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.

> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.

Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true.

>> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].

> Because its not ready?

As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves.

I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious.

As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.

[0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html

--

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 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Michael,
>
>> If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.
>
> It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.
>
>> It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.
>
> I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.
>
>> It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].
>
> He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.
>
>> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>
> Because its not ready?
>
>> Similar work has not been done for any of the speculated use cases of OP_CTV.
>
> There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.
>
> If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.
>
>> Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.
>
> We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.
>
>> This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.
>
> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>
>> I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.
>
> I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.
>
>> I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.
>
> I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.
>
>> Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.
>
> Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.
>
> --
> Prayank
>
> A3B1 E430 2298 178F

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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

What I have done related to OP_CTV?

https://twitter.com/prayankgahlot/status/1456643891885592579

What am I currently working on that is not shared publicly and will do in next few weeks?

Review pull request 21702 and write contracts using Sapio based on few ideas that I already have.

What is this assessment based on?

A few months are enough for the recent bounty to find bugs if possible and other things pending to be completed.

> you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones)

I have read enough about alternative proposals and some of them don't even compete with OP_CTV, they can all be implemented and complement each other. Vaults is not the only thing that I care about and it would be better if we don't assume about research done by others.

> A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.

TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.

I don't understand what work are you expecting me to do in this case to share my opinion about a soft fork.

> It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.

I have dedicated enough time reading everything related to OP_CTV and discuss things that were posted earlier here by Jeremy Rubin. Not sure how many skeptics did the same or even tried to discuss anything until recent bounty was announced.

> You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.

I would NACK and write the reasons in this pull request as well if I find any issues and PR author is not addressing them. I had lots of questions at conceptual level which have been answered on different platforms and I cannot document each conversation. Its a Concept ACK from me and none of the contributors could find any issues with PR right now so I don't want to stop people from improving Bitcoin.

> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.

I would be attending the workshops and had even requested Jeremy to use Twitch because it would help more people understand things with audio, screen sharing etc. I would love to see skeptics participate and discuss technical things.

> I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point.

If you don't participate in the workshops you might miss few things. However, either Jeremy or one of the participants will ensure they share the summary here or even logs would be available.

-- 
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 19:45 by michaelfolkson@protonmail.com:

> > > It should be ready to go in a few months IMO
>
> What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>
> You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>
> I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>
> > If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>
> Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true.
>
> >> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>
> > Because its not ready?
>
> As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves.
>
> I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious.
>
> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>
> [0]: > https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
> [1]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
>
> --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>  On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>  
>
>> Hi Michael,
>>
>> > If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.
>>
>> It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.
>>
>>
>> > It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.
>>
>> I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.
>>
>>
>> > It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].
>>
>> He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.
>>
>>
>> > To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>
>> Because its not ready?
>>
>>
>> > Similar work has not been done for any of the speculated use cases of OP_CTV.
>>
>> There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.
>>
>> If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.
>>
>>
>> > Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.
>>
>> We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.
>>
>>
>> > This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.
>>
>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>
>>
>> > I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.
>>
>> I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.
>>
>>
>> > I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.
>>
>> I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.
>>
>>
>> > Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.
>>
>> Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.
>>
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>


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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Michael Folkson]

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

You are working on a use case of OP_CTV now? Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements. Regardless stick with it and build out more than a rudimentary proof of concept. That is one of the things that is severely lacking at this point for OP_CTV.

> TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.

I would hope you weren't against Miniscript because Sapio is built on top of it :) But whatever have fun, I can't do this all day.

--

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 4th, 2022 at 3:06 PM, Prayank <prayank@tutanota.de> wrote:

> What I have done related to OP_CTV?
>
> https://twitter.com/prayankgahlot/status/1456643891885592579
>
> What am I currently working on that is not shared publicly and will do in next few weeks?
>
> Review pull request 21702 and write contracts using Sapio based on few ideas that I already have.
>
> What is this assessment based on?
>
> A few months are enough for the recent bounty to find bugs if possible and other things pending to be completed.
>
>> you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones)
>
> I have read enough about alternative proposals and some of them don't even compete with OP_CTV, they can all be implemented and complement each other. Vaults is not the only thing that I care about and it would be better if we don't assume about research done by others.
>
>> A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>
> TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.
>
> I don't understand what work are you expecting me to do in this case to share my opinion about a soft fork.
>
>> It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>
> I have dedicated enough time reading everything related to OP_CTV and discuss things that were posted earlier here by Jeremy Rubin. Not sure how many skeptics did the same or even tried to discuss anything until recent bounty was announced.
>
>> You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>
> I would NACK and write the reasons in this pull request as well if I find any issues and PR author is not addressing them. I had lots of questions at conceptual level which have been answered on different platforms and I cannot document each conversation. Its a Concept ACK from me and none of the contributors could find any issues with PR right now so I don't want to stop people from improving Bitcoin.
>
>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>
> I would be attending the workshops and had even requested Jeremy to use Twitch because it would help more people understand things with audio, screen sharing etc. I would love to see skeptics participate and discuss technical things.
>
>> I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point.
>
> If you don't participate in the workshops you might miss few things. However, either Jeremy or one of the participants will ensure they share the summary here or even logs would be available.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
> Jan 4, 2022, 19:45 by michaelfolkson@protonmail.com:
>
>>> It should be ready to go in a few months IMO
>>
>> What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>>
>> You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>>
>> I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>>
>>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>
>> Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true.
>>
>>>> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>
>>> Because its not ready?
>>
>> As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves.
>>
>> I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious.
>>
>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>>
>> [0]: https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>> [1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
>>
>> --
>>
>> 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 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Michael,
>>>
>>>> If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.
>>>
>>> It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.
>>>
>>>> It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.
>>>
>>> I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.
>>>
>>>> It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].
>>>
>>> He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.
>>>
>>>> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>>
>>> Because its not ready?
>>>
>>>> Similar work has not been done for any of the speculated use cases of OP_CTV.
>>>
>>> There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.
>>>
>>> If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.
>>>
>>>> Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.
>>>
>>> We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.
>>>
>>>> This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.
>>>
>>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>>
>>>> I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.
>>>
>>> I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.
>>>
>>>> I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.
>>>
>>> I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.
>>>
>>>> Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.
>>>
>>> Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.
>>>
>>> --
>>> Prayank
>>>
>>> A3B1 E430 2298 178F

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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

> You are working on a use case of OP_CTV now?

I think I mentioned clearly what I would be doing: 1. Review pull request 2. Create contracts with Sapio. This would help me review OP_CTV and learn new things.

> Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements.

You can read more about my involvement in Bitcoin Knots here: https://github.com/bitcoinknots/bitcoin/discussions/39

I started working for zkSNACKs Wasabi 2 months back which can be confirmed with the team.

There are no announcements and humans can work on multiple things. You might want to check my next project which involves discreet log contracts as I have learnt a few things in bitcoin-s slack as well: https://gok.one/

For my involvement in other projects you can email me privately and I can share my resume.

-- 
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 22:18 by michaelfolkson@protonmail.com:

> You are working on a use case of OP_CTV now? Cool, you only recently announced you were working on Bitcoin Knots (and I think Wasabi before that) so I'm losing track of all the announcements. Regardless stick with it and build out more than a rudimentary proof of concept. That is one of the things that is severely lacking at this point for OP_CTV.
>
> > TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.
>
> I would hope you weren't against Miniscript because Sapio is built on top of it :) But whatever have fun, I can't do this all day.
>
>
> --> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>  On Tuesday, January 4th, 2022 at 3:06 PM, Prayank <prayank@tutanota.de> wrote:
>  
>
>> What I have done related to OP_CTV?
>>
>> https://twitter.com/prayankgahlot/status/1456643891885592579
>>
>> What am I currently working on that is not shared publicly and will do in next few weeks?
>>
>> Review pull request 21702 and write contracts using Sapio based on few ideas that I already have.
>>
>> What is this assessment based on?
>>
>> A few months are enough for the recent bounty to find bugs if possible and other things pending to be completed.
>>
>> > you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones)
>>
>> I have read enough about alternative proposals and some of them don't even compete with OP_CTV, they can all be implemented and complement each other. Vaults is not the only thing that I care about and it would be better if we don't assume about research done by others.
>>
>> > A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>>
>> TBH I am not against Miniscript and still waiting for its support in Core which might take another few years. I would love to have multiple programming languages so that application developers can decide what works best for them.
>>
>> I don't understand what work are you expecting me to do in this case to share my opinion about a soft fork.
>>
>> > It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>>
>> I have dedicated enough time reading everything related to OP_CTV and discuss things that were posted earlier here by Jeremy Rubin. Not sure how many skeptics did the same or even tried to discuss anything until recent bounty was announced.
>>
>> > You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>>
>> I would NACK and write the reasons in this pull request as well if I find any issues and PR author is not addressing them. I had lots of questions at conceptual level which have been answered on different platforms and I cannot document each conversation. Its a Concept ACK from me and none of the contributors could find any issues with PR right now so I don't want to stop people from improving Bitcoin.
>>
>> > As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>>
>> I would be attending the workshops and had even requested Jeremy to use Twitch because it would help more people understand things with audio, screen sharing etc. I would love to see skeptics participate and discuss technical things.
>>
>> > I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point.
>>
>> If you don't participate in the workshops you might miss few things. However, either Jeremy or one of the participants will ensure they share the summary here or even logs would be available.
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Jan 4, 2022, 19:45 by michaelfolkson@protonmail.com:
>>
>>> > >>> It should be ready to go in a few months IMO
>>>
>>> What is this assessment based on? I am assuming you haven't done a code review of the opcode, you haven't coded up a real world use case of OP_CTV (or even a primitive proof of concept), you haven't thought about alternative proposals for any particular use case (vaults for example have multiple current alternative proposals and most likely many future ones). A new programming language (Sapio) sounds great but do you you need it for your use case rather than an alternative high level language like Minsc? Sapio makes use of Miniscript which hasn't been finalized yet or updated for Taproot. Surely that needs to be done first otherwise Sapio is built on top of something that isn't ready? When you make the claims such as a consensus change is ready to go the burden is on you to convince me and other skeptics why. The status quo is the default. "I think it is ready or will be ready" doesn't mean much unless you have done the work.
>>>
>>> You are well aware of the review process in Core for non-consensus changes. For consensus changes you really should be digging even deeper, the bar should be higher and all questions you and others have should be explored in depth. It is not enough for one individual to say it is ready to be activated, anyone who is expressing that view should understand why the opcode has been designed in the way it has and why it is so important that we should dedicate months of community time to getting a single opcode activated this year.
>>>
>>> I have more sympathy for those who don't follow Bitcoin Core development and Bitcoin Core review on an ongoing basis (note as I said that the bar for consensus changes should be significantly higher than a non-consensus PR). The use cases sound cool and the work is genuinely interesting. But honestly for someone who has followed Bitcoin Core development, review for a while now you really should know better than bandy around statements like "it should be ready to go in a few months" when you currently haven't scratched the surface on the utility and safety of this opcode. You regularly NACK Core PRs yet you seem willing to wave a consensus change through with no outstanding questions and zero skepticism.
>>>
>>> > If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>>
>>> Multiple proven built out use cases, sure. Multiple is better than single when you have done the work to ensure they are actually the right tool for those multiple use cases. This work hasn't been done on any of these use cases. The curing cancer analogy was used to elucidate the point that claims should be deeply explored rather than just accepted as true.
>>>
>>> >> To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>>
>>> > Because its not ready?
>>>
>>> As I said it is not ready because the ANYPREVOUT contributors are building out and testing a use case. The high bar on readiness should be applied to all proposals not merely the ones where the authors/contributors decide to impose a high bar themselves.
>>>
>>> I don't really want to spend my year imploring people to dig deeper on this before indicating they support an imminent activation attempt. Some people don't have the understanding to dig deeper, some people don't have the time and some don't have either. However, if an activation of OP_CTV is attempted this year I am sure it will be contentious [0]. Anyone who cares about Bitcoin development and the ongoing technical work in a multitude of areas should be strongly against a contentious soft fork activation attempt wasting the time of developers and the entire ecosystem even if they don't have the understanding or time to appreciate the reasons why it is contentious.
>>>
>>> As I understand there are IRC workshops next week on BIP 119 [1] that I'd encourage you to join so you can start getting into a position where you can engage with the skeptics on technical concerns. Regrettably (as I said I find this work interesting) I don't feel like I can participate because deployment and activation is being included and I think it is irresponsible to be discussing those at this point. In my view activation should not even be speculated upon until it is clear there is overwhelming community support for a soft fork being activated.
>>>
>>> [0]: >>> https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
>>> [1]: >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019719.html
>>>
>>> -->>> Michael FolksonEmail: michaelfolkson at protonmail.comKeybase: michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Tuesday, January 4th, 2022 at 11:53 AM, Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>
>>>> Hi Michael,
>>>>
>>>> > If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.
>>>>
>>>> It should be ready to go in a few months IMO and makes no sense to bundle everything with Taproot soft fork. Things can remain separate and still considered good enough based on the changes proposed.
>>>>
>>>>
>>>> > It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem.
>>>>
>>>> I don't see any damage with a soft fork that is being discussed since years, documented properly, includes code for implementation and examples, recently got crowdfunding to incentivize review process and improve security.
>>>>
>>>>
>>>> > It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2].
>>>>
>>>> He is doing nothing unexpected and got reasons to support OP_CTV being implemented soon.
>>>>
>>>>
>>>> > To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4].
>>>>
>>>> Because its not ready?
>>>>
>>>>
>>>> > Similar work has not been done for any of the speculated use cases of OP_CTV.
>>>>
>>>> There is no comparison between the two. If someone has worked on one of the speculated uses cases, it makes no difference.
>>>>
>>>> If we still compare something because of our bias, maybe Sapio is something that would be more helpful for Bitcoin developers.
>>>>
>>>>
>>>> > Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.
>>>>
>>>> We had soft signals from mining pools for Taproot as well and still waiting for projects to use Taproot. Even miners signaling with speedy trial was not a guarantee they would follow new consensus rules later. I don't see anything wrong in looking for people who support a proposal and documenting it.
>>>>
>>>>
>>>> > This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible.
>>>>
>>>> If I had to select between a soft fork without any use cases and one with use cases, I would go with the one that has some use cases with code, documentation etc. You should propose a new opcode but OP_CTV is not claiming to cure cancer.
>>>>
>>>>
>>>> > I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day.
>>>>
>>>> I am confident this proposal will be used by lot of Bitcoin projects and improve privacy, security, decentralization, demand for block space etc.
>>>>
>>>>
>>>> > I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.
>>>>
>>>> I feel the danger is a few people able to stop soft forks that improve Bitcoin because of their bias and opinions which are mostly non-technical.
>>>>
>>>>
>>>> > Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted.
>>>>
>>>> Nobody has stopped anyone from doing research. There is no backdoor and everything is public. So soon? I am not sure if there are any issues with a soft fork in next few months if its ready.
>>>>
>>>>
>>>> -- 
>>>> Prayank
>>>>
>>>> A3B1 E430 2298 178F
>>>>
>>
>>


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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Christian Decker]

Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
>> To contrast with his approach, the authors and contributors of
>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>> aren’t promoting an imminent soft fork activation attempt and instead
>> are building out and testing one of the speculated use cases, eltoo
>> payment channels [4].
>
> Because its not ready?

Could you elaborate on this point? I keep seeing people mentioning this,
but I, as BIP co-author, have not seen any real pushback. For context
BIP118 was initially called `sighash_noinput` and it was mentioned at
least as far back as 2015 when Joseph and Tadje wrote about its
applications in the LN protocol. While writing eltoo we stumbled over an
alternative use, and decided to draft the formal proposal.

Once we saw that Taproot is likely to activate next, AJ started adapting
it to integrate nicely with Taproot, and renamed it to anyprevout.

I'd like to point out that the original noinput could be implemented
with as little as 3-5 lines of code in Bitcoin Core, and there are
experimental branches implementing APO, which isn't significantly more
complex than the original proposal.

In addition Richard Myers has implemented a PoC of eltoo on top of one
of these experimental branches. So with all this I don't see how APO
could be considered "not ready".

The reason that neither noinput nor APO have a section on activation is
that we want to allow bundling with other soft-forks, and we want to
minimize the surface for potential conflicts. Also as the Taproot
activation has shown activation is a whole another discussion, that is
mostly unrelated to the soft-fork being activated.

Why aren't we yelling about the advantages of APO over other soft-forks
or asking for immediate activation? Because we want to be respectful of
everyone's time. We know review capacity is very limited, and developer
time expensive. By now most devs will be aware of the many improvements
(on LN, eltoo, MPC, channel factories, statechains, spacechains, etc)
anyprevout would enable, so there is little point in annoying everyone
by constantly talking about it. The people interested in exploring this
venue are already working on it, and we just need to wait for an
opportune moment to start the activation discussion with other
soft-forks.

I also see people comparing OP_CTV with APO, which may or may not work
out in the end. It seems possible to emulate APO using OP_CTV, but at
what cost? APO does not have any overhead in the transaction size, which
is not the case for OP_CTV, and I therefore consider the two proposals
complementary, and not competing (APO does best what APO does best,
while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO
for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV
if only one gets activated (But then why would we? We've done much more
obscure things to save bytes in a TX).

Finally I see people mentioning that APO is insufficient to get
eltoo. That's also not true, since in fact we can implement a poor-man's
version of eltoo right now:

 - When updating:
   - Iterate through all prior update TXs
   - Bind the new update TX to each of the prior ones
   - Sign using `sighash_all`
   - Collect all sinatures and send to peer (message size O(n), but
     semantics are preserved, while APO enable O(1) making it actually
     reasonable to implement).

There may be some extensions, such as layered commitments that may be
added at a later stage, but they are not required to get the first
versions off the ground. Pretending that they're required would be like
saying that the protocol in the LN paper hasn't changed since it was
first written (definitely not the case).

Overall I agree with Michael's sentiment that soft-fork activations have
to be carefully planned, and kept at a reasonable pace. This is in order
to ensure that the activated features will work as expected (building
PoCs is important here) and that review time is kept efficient (bundling
may help here). For these reasons we omitted the activation discussion
in BIP118 and have trimmed the proposal to the bare minimum.

Sorry for the longish rant, but I felt I needed to clarify this
situation a bit.

Cheers,
Christian

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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

Hi Christian,

A few things are mentioned in these threads including unsolved research issues in which you were tagged and Richard Myers had even replied so I am assuming this is known:

https://twitter.com/JeremyRubin/status/1460349481518465025

https://twitter.com/ajtowns/status/1477586002252238850

> I also see people comparing OP_CTV with APO, which may or may not work
out in the end.

Michael Folkson did in the first email for this thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html

> I therefore consider the two proposals complementary

Agree

> I'm also happy to go wih OP_CTV if only one gets activated (But then why would we? We've done much more obscure things to save bytes in a TX).

Maybe we can activate one that does more than just eltoo and see how things work. If APO is still required for eltoo, there would be clear consensus for APO.


-- 
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 20:12 by decker.christian@gmail.com:

> Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
>
>>> To contrast with his approach, the authors and contributors of
>>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>>> aren’t promoting an imminent soft fork activation attempt and instead
>>> are building out and testing one of the speculated use cases, eltoo
>>> payment channels [4].
>>>
>>
>> Because its not ready?
>>
>
> Could you elaborate on this point? I keep seeing people mentioning this,
> but I, as BIP co-author, have not seen any real pushback. For context
> BIP118 was initially called `sighash_noinput` and it was mentioned at
> least as far back as 2015 when Joseph and Tadje wrote about its
> applications in the LN protocol. While writing eltoo we stumbled over an
> alternative use, and decided to draft the formal proposal.
>
> Once we saw that Taproot is likely to activate next, AJ started adapting
> it to integrate nicely with Taproot, and renamed it to anyprevout.
>
> I'd like to point out that the original noinput could be implemented
> with as little as 3-5 lines of code in Bitcoin Core, and there are
> experimental branches implementing APO, which isn't significantly more
> complex than the original proposal.
>
> In addition Richard Myers has implemented a PoC of eltoo on top of one
> of these experimental branches. So with all this I don't see how APO
> could be considered "not ready".
>
> The reason that neither noinput nor APO have a section on activation is
> that we want to allow bundling with other soft-forks, and we want to
> minimize the surface for potential conflicts. Also as the Taproot
> activation has shown activation is a whole another discussion, that is
> mostly unrelated to the soft-fork being activated.
>
> Why aren't we yelling about the advantages of APO over other soft-forks
> or asking for immediate activation? Because we want to be respectful of
> everyone's time. We know review capacity is very limited, and developer
> time expensive. By now most devs will be aware of the many improvements
> (on LN, eltoo, MPC, channel factories, statechains, spacechains, etc)
> anyprevout would enable, so there is little point in annoying everyone
> by constantly talking about it. The people interested in exploring this
> venue are already working on it, and we just need to wait for an
> opportune moment to start the activation discussion with other
> soft-forks.
>
> I also see people comparing OP_CTV with APO, which may or may not work
> out in the end. It seems possible to emulate APO using OP_CTV, but at
> what cost? APO does not have any overhead in the transaction size, which
> is not the case for OP_CTV, and I therefore consider the two proposals
> complementary, and not competing (APO does best what APO does best,
> while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO
> for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV
> if only one gets activated (But then why would we? We've done much more
> obscure things to save bytes in a TX).
>
> Finally I see people mentioning that APO is insufficient to get
> eltoo. That's also not true, since in fact we can implement a poor-man's
> version of eltoo right now:
>
>  - When updating:
>  - Iterate through all prior update TXs
>  - Bind the new update TX to each of the prior ones
>  - Sign using `sighash_all`
>  - Collect all sinatures and send to peer (message size O(n), but
>  semantics are preserved, while APO enable O(1) making it actually
>  reasonable to implement).
>
> There may be some extensions, such as layered commitments that may be
> added at a later stage, but they are not required to get the first
> versions off the ground. Pretending that they're required would be like
> saying that the protocol in the LN paper hasn't changed since it was
> first written (definitely not the case).
>
> Overall I agree with Michael's sentiment that soft-fork activations have
> to be carefully planned, and kept at a reasonable pace. This is in order
> to ensure that the activated features will work as expected (building
> PoCs is important here) and that review time is kept efficient (bundling
> may help here). For these reasons we omitted the activation discussion
> in BIP118 and have trimmed the proposal to the bare minimum.
>
> Sorry for the longish rant, but I felt I needed to clarify this
> situation a bit.
>
> Cheers,
> Christian
>


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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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

Hi Peter,

> that current lacks compelling use-cases clearly beneficial to all users

All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:

 https://utxos.org/uses/

https://rubin.io/archive/

> I don't think CTV in its current form makes that case sufficiently, and the technical details are lacking.
CTV cannot be compared to segwit or taproot. We are expecting different things in that case. CTV is trying to do add basic covenants in Bitcoin that would help all Bitcoin users. Most important thing missing in lot of conversations is the low demand for block space which affects everyone who understands importance of fees in long term. Right now fee rates only spike during peak bull markets which indicate the only use case is speculation and this can be improved if developers could do better things with Bitcoin smart contracts.

This would also ensure that we don't end up with something really contentious in future that changes supply.

> DoS Attacks

I think this was already answered by Jeremy and pull request to add related information is also merged:

https://github.com/bitcoin/bips/pull/1272


-- 
Prayank

A3B1 E430 2298 178F

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Peter Todd]

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

On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> Hi Peter,
> 
> > that current lacks compelling use-cases clearly beneficial to all users
> 
> All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:
> 
>  https://utxos.org/uses/
> 
> https://rubin.io/archive/

Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
users", not just a small subset. I neither think the use-cases in those links
are clearly compelling in the current form, and they of course, don't benefit
all users. Indeed, the Drivechains use-case arguably *harms* all users, as
Drivechains is arguably harmful to the security of Bitcoin as a whole.
Similarly, the various new uses for on-chain transactions mentioned as a
use-case arguably harms all existing users by competing for scarce blockchain
space - note how ETH has quite high on chain fees for basic transactions,
because there are so many use-cases where the per-tx value can afford much
higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
a whole by providing more fuel for a future contentious blocksize debate.

Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
the benefits of making core consensus changes to that system against the risks.
Both for each proposal in isolation, as well as the precedent making that
change sets.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Erik Aronesty]

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

> note how ETH has quite high on chain fees for basic transactions,
> because there are so many use-cases where the per-tx value can afford much
> higher fees. That kind of expansion of use-case also arguably harms
Bitcoin as
> a whole by providing more fuel for a future contentious blocksize debate.

i second this argument

ideally, all extensions should be explicit use cases, not generic/implicit
layers that can be exploited for unknown and possibly harmful use cases

also timing is critical for all bitcoin innovation.   look at how lightning
ate up fees

to keep bitcoin stable, we can't "scale" too quickly either

i'm a fan of, eventually (timing is critical), a lightning-compatible
mimblewible+dandelion on-chain soft fork can reduce tx size, move us from
l2 to l3, vastly improve privacy, and get more small transactions off-chain.

but it probably shouldn't be released for another 2 years


On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> > Hi Peter,
> >
> > > that current lacks compelling use-cases clearly beneficial to all users
> >
> > All the use cases shared in below links look compelling enough to me and
> we can do anything that a programmer could think of using such restrictions:
> >
> >  https://utxos.org/uses/
> >
> > https://rubin.io/archive/
>
> Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
> users", not just a small subset. I neither think the use-cases in those
> links
> are clearly compelling in the current form, and they of course, don't
> benefit
> all users. Indeed, the Drivechains use-case arguably *harms* all users, as
> Drivechains is arguably harmful to the security of Bitcoin as a whole.
> Similarly, the various new uses for on-chain transactions mentioned as a
> use-case arguably harms all existing users by competing for scarce
> blockchain
> space - note how ETH has quite high on chain fees for basic transactions,
> because there are so many use-cases where the per-tx value can afford much
> higher fees. That kind of expansion of use-case also arguably harms
> Bitcoin as
> a whole by providing more fuel for a future contentious blocksize debate.
>
> Bitcoin is an almost $1 trillion dollar system. We have to very carefully
> weigh
> the benefits of making core consensus changes to that system against the
> risks.
> Both for each proposal in isolation, as well as the precedent making that
> change sets.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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

> note how ETH has quite high on chain fees for basic transactions,> because there are so many use-cases where the per-tx value can afford much> higher fees. That kind of expansion of use-case also arguably harms Bitcoin as> a whole by providing more fuel for a future contentious blocksize debate.
>i second this argument

I disagree with this argument, Satoshi won't agree with it either if still active and it make no sense. Fees will be the incentives for miners as subsidy decreases after every 210,000 blocks and it will depend on demand for block space.

There is nothing harmful in it just because something similar is happening in an altcoin which has several other issues. Example: if a user has to pay fees with 100 sat/vbyte fee rate to open and close channels it will be good for Bitcoin in long term.

If this is the reason to stop/delay improvements in bitcoin, maybe it applies for Taproot as well although I don't remember reading such things in your posts or maybe missed it.

-- 
Prayank

A3B1 E430 2298 178F



Feb 21, 2022, 00:05 by erik@q32.com:

> > note how ETH has quite high on chain fees for basic transactions,
> > because there are so many use-cases where the per-tx value can afford much
> > higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
> > a whole by providing more fuel for a future contentious blocksize debate.
>
> i second this argument
>
> ideally, all extensions should be explicit use cases, not generic/implicit layers that can be exploited for unknown and possibly harmful use cases
>
> also timing is critical for all bitcoin innovation.   look at how lightning ate up fees
>
> to keep bitcoin stable, we can't "scale" too quickly either
>
> i'm a fan of, eventually (timing is critical), a lightning-compatible mimblewible+dandelion on-chain soft fork can reduce tx size, move us from l2 to l3, vastly improve privacy, and get more small transactions off-chain.
>
> but it probably shouldn't be released for another 2 years
>
>
> On Fri, Feb 18, 2022 at 6:41 PM Peter Todd via bitcoin-dev <> bitcoin-dev@lists.linuxfoundation.org> > wrote:
>
>> On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
>>  > Hi Peter,
>>  > 
>>  > > that current lacks compelling use-cases clearly beneficial to all users
>>  > 
>>  > All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:
>>  > 
>>  >  >> https://utxos.org/uses/
>>  > 
>>  > >> https://rubin.io/archive/
>>  
>>  Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
>>  users", not just a small subset. I neither think the use-cases in those links
>>  are clearly compelling in the current form, and they of course, don't benefit
>>  all users. Indeed, the Drivechains use-case arguably *harms* all users, as
>>  Drivechains is arguably harmful to the security of Bitcoin as a whole.
>>  Similarly, the various new uses for on-chain transactions mentioned as a
>>  use-case arguably harms all existing users by competing for scarce blockchain
>>  space - note how ETH has quite high on chain fees for basic transactions,
>>  because there are so many use-cases where the per-tx value can afford much
>>  higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
>>  a whole by providing more fuel for a future contentious blocksize debate.
>>  
>>  Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
>>  the benefits of making core consensus changes to that system against the risks.
>>  Both for each proposal in isolation, as well as the precedent making that
>>  change sets.
>>  
>>  -- 
>>  >> https://petertodd.org>>  'peter'[:-1]@>> petertodd.org <http://petertodd.org>
>>  _______________________________________________
>>  bitcoin-dev mailing list
>>  >> bitcoin-dev@lists.linuxfoundation.org
>>  >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[ZmnSCPxj]

Good morning Prayank,

(offlist)

>  Satoshi

I object to the invocation of Satoshi here, and in general.
If Satoshi wants to participate in Bitcoin development today, he can speak for himself.
If Satoshi refuses to participate in Bitcoin development today, who cares what his opinion is?
Satoshi is dead, long live Bitcoin.


Aside from that, I am otherwise thinking about the various arguments being presented.


Regards,
ZmnSCPxj

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[ZmnSCPxj]

> Good morning Prayank,
>
> (offlist)

<facepalm>

My apologies.
I pushed the wrong button, I should have pressed "Reply" and not "Reply All".

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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

Goog morning ZmnSCPxj,

Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329

Maybe I should have rephrased it and quote Satoshi. I agree I should not speak for others and it was not my intention in the email.

> If Satoshi refuses to participate in Bitcoin development today, who cares what his opinion is?

I care about the opinions especially if consensus rules are not changed and remain same as far as subsidy is concerned.

> Satoshi is dead, long live Bitcoin.

I object to such assumptions about the founder of Bitcoin. Satoshi is more than a pseudonym and will stay alive forever.

-- 
Prayank

A3B1 E430 2298 178F



Feb 21, 2022, 14:32 by ZmnSCPxj@protonmail.com:

> Good morning Prayank,
>
> (offlist)
>
>> Satoshi
>>
>
> I object to the invocation of Satoshi here, and in general.
> If Satoshi wants to participate in Bitcoin development today, he can speak for himself.
> If Satoshi refuses to participate in Bitcoin development today, who cares what his opinion is?
> Satoshi is dead, long live Bitcoin.
>
>
> Aside from that, I am otherwise thinking about the various arguments being presented.
>
>
> Regards,
> ZmnSCPxj
>


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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Billy Tetrud]

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

> look at how lightning ate up fees to keep bitcoin stable, we can't
"scale" too quickly either

I strongly disagree with this. We should be scaling Bitcoin as fast as we
can. There is no reason to delay scaling for the purposes of keeping fees
high. If we need fees to be higher, we can lower the block size or increase
the default minimum relay fee rate.

Also, the idea that use of the LN is there primary cause of recent low fees
is highly dubious.

> the various new uses for on-chain transactions mentioned as a use-case
arguably harms all existing users by competing for scarce blockchain space

Reminds me of that old saying, "nobody goes there anymore, it's too
crowded". ; )


On Mon, Feb 21, 2022, 03:54 Prayank via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Goog morning ZmnSCPxj,
>
> Context: https://bitcointalk.org/index.php?topic=48.msg329#msg329
>
> Maybe I should have rephrased it and quote Satoshi. I agree I should not
> speak for others and it was not my intention in the email.
>
> > If Satoshi refuses to participate in Bitcoin development today, who
> cares what his opinion is?
>
> I care about the opinions especially if consensus rules are not changed
> and remain same as far as subsidy is concerned.
>
> > Satoshi is dead, long live Bitcoin.
>
> I object to such assumptions about the founder of Bitcoin. Satoshi is more
> than a pseudonym and will stay alive forever.
>
> --
> Prayank
>
> A3B1 E430 2298 178F
>
>
>
> Feb 21, 2022, 14:32 by ZmnSCPxj@protonmail.com:
>
> Good morning Prayank,
>
> (offlist)
>
> Satoshi
>
>
> I object to the invocation of Satoshi here, and in general.
> If Satoshi wants to participate in Bitcoin development today, he can speak
> for himself.
> If Satoshi refuses to participate in Bitcoin development today, who cares
> what his opinion is?
> Satoshi is dead, long live Bitcoin.
>
>
> Aside from that, I am otherwise thinking about the various arguments being
> presented.
>
>
> Regards,
> ZmnSCPxj
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[ZmnSCPxj]

Good morning,


> If this is the reason to stop/delay improvements in bitcoin, maybe it applies for Taproot as well although I don't remember reading such things in your posts or maybe missed it.

Perhaps a thing to note, is that if it allows us to move some activity off-chain, and reduce activity on the blockchain, then the increase in functionality does *not* translate to a requirement of block size increase.

So for example:

* Taproot, by allowing the below improvements, is good:
  * Schnorr multisignatures that allow multiple users to publish a single signature, reducing block size usage for large participant sets.
  * MAST, which allows eliding branches of complicated SCRIPTs that are not executed, reducing block size usage for complex contracts.
* `SIGHASH_ANYPREVOUT`, by enabling an offchain updateable multiparty (N > 2) cryptocurrency system (Decker-Russell-Osuntokun), is also good, as it allows us to make channel factories without having to suffer the bad tradeoffs of Decker-Wattenhofer.
* `OP_CTV`, by enabling commit-to-unpublished-promised-outputs, is also good, as it allows opportunities for transactional cut-through without having to publish promised outputs *right now*.

So I do not think the argument should really object to any of the above, either --- all these improvements increase the functionality of Bitcoin, but also allow opportunities to use the blockchain as judge+jury+executioner instead of noisy marketplace.

Regards,
ZmnSCPxj

[bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Michael Folkson]

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

I have already expressed my arguments on the regularity of soft forks [0]. Having spent months of my time on Taproot activation last year attempting to get at least rough community consensus on the activation method it seems crazy to me that some want to do that again so soon after Taproot activation and somehow this time it will be plain sailing. (Spoiler: it won’t. Although Taproot safely activated there remain outstanding views ranging on whether BIP 8 or 9 variants of Speedy Trial should be used in future to Speedy Trial only being a short term stopgap that should not be repeated.) If OP_CTV is ready to go now and has overwhelming community support (I don’t think either is true) it should surely have been included in the Taproot soft fork (perhaps delayed) rather than going through the months of activation wrangling and community outreach twice.

I stated in that post:

“A contentious or disputed soft fork can be merged into a Bitcoin implementation at any time but doing this is opening the door to the schism, disruption and waste of developer hours that we saw in 2017. Personally I think we’ll see an attempt to activate a contentious soft fork at some point in the long term future (Murphy’s Law) but any attempt to do so should be strongly discouraged. It should be made clear to any individual(s) that attempt this of the knock on impacts and potential short term damage they are inflicting on the entire ecosystem. Longer term I have confidence in Bitcoin’s ability to survive whatever happens but allocating significant community resources to resist an unnecessary contentious soft fork (or even regular contentious soft forks) is not an optimal use of those resources.”

I am getting increasingly concerned that we are stumbling into this scenario three months after I wrote that post. One of many future soft fork proposals (as many will know) is BIP 119 [1] which is the enabling of a new opcode OP_CHECKTEMPLATEVERIFY (OP_CTV). It seems to me like the author and primary promoter of this proposal (Jeremy Rubin) is pushing for an imminent attempted activation of a soft fork containing exclusively OP_CTV [2]. To contrast with his approach, the authors and contributors of another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT) aren’t promoting an imminent soft fork activation attempt and instead are building out and testing one of the speculated use cases, eltoo payment channels [4]. Similar work has not been done for any of the speculated use cases of OP_CTV. Instead Jeremy is encouraging people to “soft signal” for soft fork activation of OP_CTV presumably in the hope that the building out and testing of use cases can be completed post activation.

This is totally irresponsible in my view. A long list of speculated use cases means nothing on its own. I can propose a new opcode OP_MAGIC and claim it will cure cancer with no potential downsides and hence we should have a soft fork activating it as soon as possible. I would hope there would be sufficient skepticism that this proposal wouldn’t see the light of day. It is true that Jeremy has some rudimentary proofs of concept built but as any software engineer will tell you the vast majority of the challenges are encountered once you attempt to build out that proof of concept. Once you do you may realize that the tool (or opcode) you are using isn’t the right one for the job. Unlike adjusting a feature on a social media app adjusting a consensus change once it has been activated is trickier to put it mildly.

There are a number of other more interesting technical discussions to be had later (what kind of covenants we want and are able to enable safely on Bitcoin etc, how CTV compares to other covenant enabling proposals, to what extent activating CTV would impact future proposals) but I feel the top priority is to bring some attention to the danger of us stumbling into an attempted contentious soft fork activation attempt.

Jeremy has put up this site (https://utxos.org/signals/) which is collecting so-called “soft signals”. I very much doubt anyone has a problem with Jeremy engaging with the community on his proposal and receiving feedback. However, the site currently states:

“The following organizations, individuals, or pools have communicated preference for and intent to support a BIP-119 activation attempt using reasonable parameters. These “soft signals” are non-binding until an actual concrete proposal has been formed, but are useful for measuring community consensus.”

There have been a number of “soft signals”, many expressing enthusiasm for the speculated use cases of OP_CTV. Personally I share that enthusiasm like I do with the prospect of curing cancer. But these soft signals seem as if they are going to be used to attempt to justify an imminent contentious soft fork attempt. The devil is in the details both with regards to wording like “reasonable parameters” and the utility and safety of a new opcode. Indeed if you share my concerns that there has not been sufficient scrutiny and research on the long implications of this proposal I encourage you to register a soft signal of “No” on the site like I have. You can always change it to “Yes” if and when you support an imminent soft fork activation attempt containing exclusively OP_CTV. Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted. To look at the ~200 lines of code for the opcode exclusively (of course this should be done too) in a vacuum without considering the broader implications is also incredibly shortsighted. The only thing stopping a descent into Ethereum style seat of our pants consensus changes is community vigilance. If we ever lose that we lose the foundation of this industry.

[0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-October/019535.html

[1]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

[2]: https://rubin.io/bitcoin/2021/12/24/advent-27/

[3]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

[4]: https://yakshaver.org/bitcoin/#anyprevout

--

Michael Folkson
Email: michaelfolkson at protonmail.com
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Peter Todd]

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

On Mon, Jan 03, 2022 at 02:05:20AM +0000, Michael Folkson via bitcoin-dev wrote:
> There have been a number of “soft signals”, many expressing enthusiasm for the speculated use cases of OP_CTV. Personally I share that enthusiasm like I do with the prospect of curing cancer. But these soft signals seem as if they are going to be used to attempt to justify an imminent contentious soft fork attempt. The devil is in the details both with regards to wording like “reasonable parameters” and the utility and safety of a new opcode. Indeed if you share my concerns that there has not been sufficient scrutiny and research on the long implications of this proposal I encourage you to register a soft signal of “No” on the site like I have. You can always change it to “Yes” if and when you support an imminent soft fork activation attempt containing exclusively OP_CTV. Enabling covenants on Bitcoin is a big step change with barely any existing research on the topic and attempting to rush it through by the back door so soon after Taproot activation should be resisted. To look at the ~200 lines of code for the opcode exclusively (of course this should be done too) in a vacuum without considering the broader implications is also incredibly shortsighted. The only thing stopping a descent into Ethereum style seat of our pants consensus changes is community vigilance. If we ever lose that we lose the foundation of this industry.

I have to second your objections.

I spent a bit of time over the past week looking at the current state of
OP_CTV/BIP-0119, and I too think it's a premature idea with an insufficient BIP
and reference implementation, that current lacks compelling use-cases clearly
beneficial to all users.

Remember that Bitcoin is a nearly $1 trillion network with tens of millions of
users that has gotten to that point with careful, conservative engineering.
Every change to the protocol poses risks to those users. Previous feature
upgrades to the Bitcoin protocol have always been done with the intent of
improving the protocol for everyone: CSV/segwit benefit all users via
Lightning, because we can reasonably all users to directly take advantage of
those features. We expect _everyone_ to benefit from Taproot via improved
privacy. I don't think CTV in its current form makes that case sufficiently,
and the technical details are lacking.



As for some more detailed thoughts, for clarify, I'm referring to:

https://github.com/bitcoin/bips/blob/3693cdfd192dacdac89cd742f68cd1bb96bf7f7e/bip-0119.mediawiki
https://github.com/JeremyRubin/bitcoin/tree/8f313d292e426a74d9ce28e5130bbf0cd48f867e

By no means is this a complete list of issues:

# DoS Attacks

Note how above I cited the git hashes to make it clear what exactly I'm
referring too: the fact that the reference implementation is listed as
https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify in the BIP is
an immediate problem, as it's not clear what exactly is the specification.

This in turn matters quite a lot, because the BIP itself glosses over the quite
serious DoS attack issues involved in adding more ways that opcodes can hash
txs. Strong resistance to DoS attacks is a _mandatory_ aspect of all Bitcoin
script proposals, so leaving those details to a mostly uncommented reference
implementation without a clear discussion of those trade-offs is insufficient.


# Use Cases

As Folkson notes, these are barely fleshed out:

## Congestion Controlled Transactions

While this section appears somewhat fleshed out, with even a simulation, it
completely ignores the numerous practical issues like the need for
communication channels between wallets to inform them of the existence of these
batches. It also raises an important question: who needs this? On-chain
transactions are clearly not the future of Bitcoin and this use-case will
likely impact a small % of users.


## Wallet Vaults

This use-case can be easily tested, even in production, right now with
additional "oracle" signers that simply verify the CTV rules have been
followed.


## Payment Channels

These use-cases sound promising. But they all need to be clearly fleshed out as
actually taking advantage of them is quite complex.


## CoinJoin

> because participants agree on a single output which pays all participants,
> which will be lower fee than before

It is not clear how the fee will be lower, given that taking advantage of CTV
means there are more transactions, not less.


# Covenant Design Trade-Offs and Risks

> Covenants have historically been controversial given their potential for
> fungibility risks -- coins could be minted which have a permanent restriction
> on how they may or may not be spent or required to propagate metadata.

Indeed, this is a significant risk with the potential to harm all Bitcoin
users.

> 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. Thus templated transactions are in theory as
> safe as transactions which create all the inputs directly in this regard.

The "finite" number of steps could be millions of transactions - "infinitely
long" for any practical purpose.


# Test Vectors

Currently the testing is poorly documented, without clear goals as to what edge
cases are actually being tested:
https://github.com/JeremyRubin/bitcoin/commit/e026bae28a774d91effc32862d0246286c114c24

Also, we really need test _vectors_ rather than a Python test: for consenus,
you want to write down explicitly the *data* in the form of serialized
transactions that is being fed into the consensus engine, to avoid mistakes in
test coverage due to broken test harnesses.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Jeremy]

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

Hi Peter,

Thank you for your review and feedback.

Apologies for the difficulties in reviewing. The branch linked from the BIP
is not the latest, the branch in the PR is what should be considered
https://github.com/bitcoin/bitcoin/pull/21702 for review and has more
thorough well documented tests and test vectors. The version you reviewed
should still be compatible with the current branch as there have not been
any spec changes, though.

I'm not sure what best practice is w.r.t. linking to BIPs and
implementations given need to rebase and respond to feedback with changes.
Appreciate any pointers on how to better solve this. For the time being, I
will suggest an edit to point it to the PR, although I recognize this is
not ideal. I understand your preference for a commit hash and can do one if
it helps. For what it's worth, the taproot BIPs do not link to a reference
implementation of Taproot so I'm not sure what best practice is considered
these days.

One note that is unfortunate in your review is that there is a
discrepancy between the BIP and the implementation (the original reference
or the current PR either) in that caching and DoS is not addressed. This
was an explicit design goal of CTV and for it not to be mentioned in the
BIP (and just the reference) is an oversight on my part to not aid
reviewers more explicitly. Compounding this, I accepted a third-party PR to
make the BIP more clear as to what is required to implement it that does
not have caching (functional correctness), that exposes the issue if
implemented by the BIP directly and not by the reference implementation. I
have explained this in a review last year to pyskell
<https://github.com/bitcoin/bitcoin/pull/21702#discussion_r616853690> on
the PR that caching is required for non-DoS. I will add a note to the BIP
about the importance of caching to avoid DoS as that should make third
party implementers aware of the issue.

That said, this is not a mis-considered part of CTV. The reference
implementation is specifically designed to not have quadratic hashing and
CTV is designed to be friendly to caching to avoid denial of service. It's
just a part of the BIP that can be more clear. I will make a PR to more
clearly describe how that should happen.

------
use cases
------

One thing that's not clear to me is the amount of work a BIP needs to do
within itself to fully describe all applications and use cases. I don't
think it's appropriate for most BIPs to do so, but in some cases it is a
good idea. However, for CTV the applications actually are relatively
fleshed out, just outside the BIP. Further, the availability of generic
tooling through Sapio and it's examples has demonstrated how one might
build a variety of applications. See rubin.io/advent21 for numerous worked
examples.


## Congestion Controlled Transactions

Generally, the existence of these transactions can be tracked using
existing wallets if the transaction is seen in the mempool, it will be
marked as "mine" and can even be marked as "trusted". See
https://utxos.org/analysis/taxes/ which covers the legal obligations of
senders with respect to payees under congestion control. Generally, a
legally identifiable party such as an exchange sending a congestion control
payment must retain and serve it to the user to prove that they made
payment to the user. Users of said exchanges can either download a list of
their transactions at the time of withdrawal or they can wait to see it
e.g. in the mempool. This was also discussed at
https://diyhpl.us/wiki/transcripts/ctv-bip-review-workshop/ where you can
see notes/videos of what was discussed if the notes are hard to parse.

Lightning specific wallets such as Muun and LND particularly plan to use
CTV to batch-open a multitude of channels for users, using both congestion
control and non-interactive batching. Channels have to be opened on-chain
and if channels are to be the future so will on-chain opening of them.
These wallets can be built out to track and receive these opening proofs.

## Wallet Vaults

There exists at least 3 implementations of Vaults using CTV (one by me in
C++, one by me in Sapio, another by Bryan Bishop in python), and there
exist oracles as you mention for emulating it.

## Payment Channels

Actually taking advantage of them is quite simple and has been discussed
and reviewed with a number of independent lightning developers.

You can see here a rudimentary implementation and description of how it can
work https://rubin.io/bitcoin/2021/12/11/advent-14/.

This is composable with any `impl Revokable` channel update specification
so generalizes to Lightning.

Of course, making it production grade requires a lot of work, but the
concept is sound.


## CoinJoin


CTV trees may mean more transactions, not less, but if feerates are not
monotonic and CTV allows you to defer the utilization of chainspace.

CTV CoinJoins also open the opportunity to cooperation through payment
pools (which can be opened via a coinjoin), which saves further space.

The opportunity to use embedded non-interactive channels (technically, this
is a part of payment pools) also further decreases the urgency of getting a
UTXO out.

Lastly, while it is a slight privacy leak, CTV also allows coin-joiners of
different fee-priority levels to batch together where previously they would
not have incentive to (see https://utxos.org/analysis/batching_sim/). This
does use overall less chainspace total than if it is not incentive
compatible to batch together. While this is a slight privacy leak, it is
not that large since the batches would otherwise be unable to join together
(worse) and priority is still unlinked from the inputs. Further, priority
already leaks through the observability of coins being spent anyways.


# Covenant Design Trade-Offs and Risks

The important part is the the covenant -- regardless of its length -- must
be entirely known in advance. CTV is a fully enumerated non-recursive
validation-only non-dynamic state covenant. This limits the types of issues
that can arise.

Useful links:
https://medium.com/block-digest-mempool/my-worries-about-too-generalized-covenants-5eff33affbb6
https://rubin.io/bitcoin/2021/12/04/advent-7/

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


On Mon, Jan 10, 2022 at 10:31 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Jan 03, 2022 at 02:05:20AM +0000, Michael Folkson via bitcoin-dev
> wrote:
> > There have been a number of “soft signals”, many expressing enthusiasm
> for the speculated use cases of OP_CTV. Personally I share that enthusiasm
> like I do with the prospect of curing cancer. But these soft signals seem
> as if they are going to be used to attempt to justify an imminent
> contentious soft fork attempt. The devil is in the details both with
> regards to wording like “reasonable parameters” and the utility and safety
> of a new opcode. Indeed if you share my concerns that there has not been
> sufficient scrutiny and research on the long implications of this proposal
> I encourage you to register a soft signal of “No” on the site like I have.
> You can always change it to “Yes” if and when you support an imminent soft
> fork activation attempt containing exclusively OP_CTV. Enabling covenants
> on Bitcoin is a big step change with barely any existing research on the
> topic and attempting to rush it through by the back door so soon after
> Taproot activation should be resisted. To look at the ~200 lines of code
> for the opcode exclusively (of course this should be done too) in a vacuum
> without considering the broader implications is also incredibly
> shortsighted. The only thing stopping a descent into Ethereum style seat of
> our pants consensus changes is community vigilance. If we ever lose that we
> lose the foundation of this industry.
>
> I have to second your objections.
>
> I spent a bit of time over the past week looking at the current state of
> OP_CTV/BIP-0119, and I too think it's a premature idea with an
> insufficient BIP
> and reference implementation, that current lacks compelling use-cases
> clearly
> beneficial to all users.
>
> Remember that Bitcoin is a nearly $1 trillion network with tens of
> millions of
> users that has gotten to that point with careful, conservative engineering.
> Every change to the protocol poses risks to those users. Previous feature
> upgrades to the Bitcoin protocol have always been done with the intent of
> improving the protocol for everyone: CSV/segwit benefit all users via
> Lightning, because we can reasonably all users to directly take advantage
> of
> those features. We expect _everyone_ to benefit from Taproot via improved
> privacy. I don't think CTV in its current form makes that case
> sufficiently,
> and the technical details are lacking.
>
>
>
> As for some more detailed thoughts, for clarify, I'm referring to:
>
>
> https://github.com/bitcoin/bips/blob/3693cdfd192dacdac89cd742f68cd1bb96bf7f7e/bip-0119.mediawiki
>
> https://github.com/JeremyRubin/bitcoin/tree/8f313d292e426a74d9ce28e5130bbf0cd48f867e
>
> By no means is this a complete list of issues:
>
> # DoS Attacks
>
> Note how above I cited the git hashes to make it clear what exactly I'm
> referring too: the fact that the reference implementation is listed as
> https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify in the
> BIP is
> an immediate problem, as it's not clear what exactly is the specification.
>
> This in turn matters quite a lot, because the BIP itself glosses over the
> quite
> serious DoS attack issues involved in adding more ways that opcodes can
> hash
> txs. Strong resistance to DoS attacks is a _mandatory_ aspect of all
> Bitcoin
> script proposals, so leaving those details to a mostly uncommented
> reference
> implementation without a clear discussion of those trade-offs is
> insufficient.
>
>
> # Use Cases
>
> As Folkson notes, these are barely fleshed out:
>
> ## Congestion Controlled Transactions
>
> While this section appears somewhat fleshed out, with even a simulation, it
> completely ignores the numerous practical issues like the need for
> communication channels between wallets to inform them of the existence of
> these
> batches. It also raises an important question: who needs this? On-chain
> transactions are clearly not the future of Bitcoin and this use-case will
> likely impact a small % of users.
>
>
> ## Wallet Vaults
>
> This use-case can be easily tested, even in production, right now with
> additional "oracle" signers that simply verify the CTV rules have been
> followed.
>
>
> ## Payment Channels
>
> These use-cases sound promising. But they all need to be clearly fleshed
> out as
> actually taking advantage of them is quite complex.
>
>
> ## CoinJoin
>
> > because participants agree on a single output which pays all
> participants,
> > which will be lower fee than before
>
> It is not clear how the fee will be lower, given that taking advantage of
> CTV
> means there are more transactions, not less.
>
>
> # Covenant Design Trade-Offs and Risks
>
> > Covenants have historically been controversial given their potential for
> > fungibility risks -- coins could be minted which have a permanent
> restriction
> > on how they may or may not be spent or required to propagate metadata.
>
> Indeed, this is a significant risk with the potential to harm all Bitcoin
> users.
>
> > 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. Thus templated transactions are in theory as
> > safe as transactions which create all the inputs directly in this regard.
>
> The "finite" number of steps could be millions of transactions -
> "infinitely
> long" for any practical purpose.
>
>
> # Test Vectors
>
> Currently the testing is poorly documented, without clear goals as to what
> edge
> cases are actually being tested:
>
> https://github.com/JeremyRubin/bitcoin/commit/e026bae28a774d91effc32862d0246286c114c24
>
> Also, we really need test _vectors_ rather than a Python test: for
> consenus,
> you want to write down explicitly the *data* in the form of serialized
> transactions that is being fed into the consensus engine, to avoid
> mistakes in
> test coverage due to broken test harnesses.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Jeremy]

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

Please see the following bips PRs which are follow ups to the concrete
actionables raised by Peter. Thanks for bringing these up, it certainly
improves the reviewability of the BIP.

https://github.com/bitcoin/bips/pull/1271
https://github.com/bitcoin/bips/pull/1272

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


On Mon, Jan 10, 2022 at 7:42 PM Jeremy <jlrubin@mit.edu> wrote:

> Hi Peter,
>
> Thank you for your review and feedback.
>
> Apologies for the difficulties in reviewing. The branch linked from the
> BIP is not the latest, the branch in the PR is what should be considered
> https://github.com/bitcoin/bitcoin/pull/21702 for review and has more
> thorough well documented tests and test vectors. The version you reviewed
> should still be compatible with the current branch as there have not been
> any spec changes, though.
>
> I'm not sure what best practice is w.r.t. linking to BIPs and
> implementations given need to rebase and respond to feedback with changes.
> Appreciate any pointers on how to better solve this. For the time being, I
> will suggest an edit to point it to the PR, although I recognize this is
> not ideal. I understand your preference for a commit hash and can do one
> if it helps. For what it's worth, the taproot BIPs do not link to a
> reference implementation of Taproot so I'm not sure what best practice is
> considered these days.
>
> One note that is unfortunate in your review is that there is a
> discrepancy between the BIP and the implementation (the original reference
> or the current PR either) in that caching and DoS is not addressed. This
> was an explicit design goal of CTV and for it not to be mentioned in the
> BIP (and just the reference) is an oversight on my part to not aid
> reviewers more explicitly. Compounding this, I accepted a third-party PR to
> make the BIP more clear as to what is required to implement it that does
> not have caching (functional correctness), that exposes the issue if
> implemented by the BIP directly and not by the reference implementation. I
> have explained this in a review last year to pyskell
> <https://github.com/bitcoin/bitcoin/pull/21702#discussion_r616853690> on
> the PR that caching is required for non-DoS. I will add a note to the BIP
> about the importance of caching to avoid DoS as that should make third
> party implementers aware of the issue.
>
> That said, this is not a mis-considered part of CTV. The reference
> implementation is specifically designed to not have quadratic hashing and
> CTV is designed to be friendly to caching to avoid denial of service. It's
> just a part of the BIP that can be more clear. I will make a PR to more
> clearly describe how that should happen.
>
>

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