Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Hi Peter and Zac, > I like the maxim of Peter Todd: any change of Bitcoin must benefit all > users. This means that every change must have well-defined and transparent > benefits. Personally I believe that the only additions to the protocol that > would still be acceptable are those that clearly benefit layer 2 solutions > such as LN and do not carry the dangerous potential of getting abused by > freeloaders selling commercial services on top of “free” eternal storage on > the blockchain. > > To strengthen your point: benefiting "all users" can only be done by > benefiting layer 2 solutions in some way, because it's inevitable that the > vast majority of users will use layer 2 because that's the only known way > that Bitcoin can scale. - CTV does not allow bitcoin blockchain to be used as storage - CTV will benefit layer 2 solutions: lightning, sidechains, spacechain etc. - Every L2 is dependent on L1 and soft forks could improve things that benefit both There are a few emails with information that could be interpreted in a wrong way on this mailing list related to CTV or creating contentious environment. I had expected better things from bitcoin developers. This is not just the opinion of someone who supports CTV but even people who are trying to read things and form an opinion: https://nitter.net/NicolasDorier/status/1518407535480705024 I am sure there are lot of positives if we look at things differently and will end the email on a good note: You might like Jeremy or hate him, however he took some real efforts in working on CTV, Sapio etc. and even if BIP 119 never gets activated his contribution in bitcoin covenants will always be appreciated. /dev/fd0 Sent with [ProtonMail](https://protonmail.com/) secure email.___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj wrote CTV *can* benefit layer 2 users, which is why I switched from vaguely > apathetic to CTV, to vaguely supportive of it. Other proposals exist that also benefit L2 solutions. What makes you support CTV specifically? Centrally documenting the implications of each side by side and point by point might be a useful next step. This would enable a larger part of the community to understand each proposal and may reduce repetition and misunderstandings on this list. Once a common understanding of the implications of each proposal is in place, their tradeoffs can be considered, facilitating creating consensus on which proposal benefits a maximum of users. Zac ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Good morning Zac, > On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj wrote > > > CTV *can* benefit layer 2 users, which is why I switched from vaguely > > apathetic to CTV, to vaguely supportive of it. > > > Other proposals exist that also benefit L2 solutions. What makes you support > CTV specifically? It is simple to implement, and a pure `OP_CTV` SCRIPT on a P2WSH / P2SH is only 32 bytes + change on the output and 32 bytes + change on the input/witness, compared to signature-based schemes which require at least 32 bytes + change on the output and 64 bytes + change on the witness ***IF*** they use the Taproot format (and since we currently gate the Taproot format behind actual Taproot usages, any special SCRIPT that uses Taproot-format signatures would need at least the 33-byte internal pubkey revelation; if we settle with the old signature format, then that is 73 bytes for the signature). To my knowledge as well, hashes (like `OP_CTV` uses) are CPU-cheaper (and memory-cheaper?) than even highly-optimized `libsecp256k1` signature validation, and (to my knowledge) you cannot use batch validation for SCRIPT-based signature checks. It definitely does not enable recursive covenants, which I think deserve more general research and thinking before we enable recursive covenants. Conceptually, I see `OP_CTV` as the "AND" to the "OR" of MAST. In both cases, you have a hash-based tree, but in `OP_CTV` you want *all* these pre-agreed cases, while in MAST you want *one* of these pre-agreed cases. Which is not to say that other proposals do not benefit L2 solutions *more* (`SIGHASH_ANYPREVOUT` when please?), but other proposals are signature-based and would be larger in this niche. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Good morning Peter, > > On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > I like the maxim of Peter Todd: any change of Bitcoin must benefit all > > users. This means that every change must have well-defined and transparent > > benefits. Personally I believe that the only additions to the protocol that > > would still be acceptable are those that clearly benefit layer 2 solutions > > such as LN and do not carry the dangerous potential of getting abused by > > freeloaders selling commercial services on top of “free” eternal storage on > > the blockchain. > > > To strengthen your point: benefiting "all users" can only be done by > benefiting layer 2 solutions in some way, because it's inevitable that the > vast majority of users will use layer 2 because that's the only known way > that Bitcoin can scale. I would like to point out that CTV is usable in LN. In particular, instead of hosting all outputs (remote, local, and all the HTLCs) directly on the commitment transaction, the commitment transaction instead outputs to a CTV-guarded SCRIPT that defers the "real" outputs. This is beneficial since a common cause of unilateral closes is that one of the HTLCs on the channel has timed out. However, only *that* particular HTLC has to be exposed onchain *right now*, and the use of CTV allows only that failing HTLC, plus O(log N) other txes, to be published. The CTV-tree can even be rearranged so that HTLCs with closer timeouts are nearer to the root of the CTV-tree. This allows the rest of the unilateral close to be resolved later, if right now there is block space congestion (we only really need to deal with the sole HTLC that is timing out right now, the rest can be done later when block space is less tight). This is arguably minimal (unilateral closes are rare, though they *do* have massive effects on the network, since a single timed-out channel can, during short-term block congestion, cause other channels to also time out, which worsen the block congestion and leading to cascades of channel closures). So this objection seems, to me, at least mitigated: CTV *can* benefit layer 2 users, which is why I switched from vaguely apathetic to CTV, to vaguely supportive of it. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson < michaelfolk...@protonmail.com> wrote: > Hi Jorge > > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > > Personally I'd rather stick to one challenge at a time :) Currently we are > facing a contentious soft fork activation attempt of CTV using an > alternative client which we expect [1] to be a Speedy Trial deployment. > Once this is resolved we can discuss the lessons and observations that come > out of this. > That sounds reasonable to me. Fair enough. > > Is there any PR to actively resist the proposal on bitcoin core? > > Not currently. Unless this becomes really, really messy and starts to pose > a true existential threat to Bitcoin itself I think it best that attempts > to actively resist the proposal are done outside of Bitcoin Core in an > alternative client(s). Contrary to what some CTV proponents say getting > anything consensus related into Bitcoin Core is extremely difficult > (especially at short notice). There is no BDFL or Linus Torvalds like > figure, there are a large number of contributors (and maintainers) who all > have differing personal views. Hence directing people to have this > discussion on a particular PR in the Bitcoin Core repo seems to me to be > counterproductive and a massive distraction to other work that is going on > on Bitcoin Core. We've already started to see online attacks on Bitcoin > Core by CTV proponents [2] claiming an "old guard trying to assert > dictatorship over the Bitcoin protocol". It is nonsense of course but > directing that nonsense to the Bitcoin Core repo is surely not the right > way to go. > > As I've said in previous emails there is a Libera (and Freenode now) IRC > channel ##ursf that has been set up to discuss an alternative client. We'll > get a conversation log up too. And of course we wait for confirmation on > what the Speedy Trial deployment parameters for this attempted CTV soft > fork are going to be. > > [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/ > [2]: > https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20=_jgRh3kkYP3kn1qLuzGXrQ > > I disagree that it shouldn't be on bitcoin core, but I guess such a proposal would get many nacks. But if there are no speedy trial parameters yet, I guess we need to wait for that; whether the code for resisting it ends up in bitcoin core or not. Thanks for the clarifications. -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > > --- Original Message --- > On Saturday, April 23rd, 2022 at 21:40, Jorge Timón > wrote: > > I've been calling them "controversial softforks" for long. > I hate to be right some times, but I guess I'm happy that I'm not the only > one who distrusts jeremy rubin anymore. > > Can we agree now that resisting a bip8 proposal is simpler and cleaner > than resisting a speedy trial proposal? > I guess now we don't need to discuss it in hypothetical terms anymore, do > we? > > Is there any PR to actively resist the proposal on bitcoin core? > > > > > > > On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a >> CTV soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one >> would be skeptical.) >> >> Understandably this has angered and surprised a few people including some >> of those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release >> candidate (and older versions) does not include any CTV code or CTV >> activation code. If a miner runs Bitcoin Core 23.0 out the box it will not >> signal for CTV. If by some chance CTV was to activate through some other >> software release Bitcoin Core releases would not apply CTV rules but they >> also wouldn't reject blocks that apply CTV rules. Hence it is prudent to >> prepare for an eventuality where the miner signaling threshold might be >> reached but the community wants to prevent the attempted soft fork from >> activating. (I personally don't think a 90 percent miner signaling >> threshold will be reached but I wouldn't want to bet Bitcoin's future on >> it.) >> >> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) >> but I'm open to better names. I certainly don't want to discourage those >> who dislike or oppose UASFs from contributing to this effort and >> potentially ultimately running a URSF release. If you don't want this >> rushed CTV soft fork to activate we are all on the same side whatever we >> call it. >> >> For now I've set up a ##ursf channel on
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Sun, Apr 24, 2022 at 2:56 PM Ryan Grant wrote: > Michael and Jorge, > > It is ethically inappropriate to make personal attacks on the > trustworthiness of participants on this list, on such vague grounds as > disliking an activation proposal! > > https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith > I don't think the same principle is being applied to me and other people, sadly. Some people disregard dissent on the grounds that it comes from "people who just loo for dissent". I don't think it is unethical to say the truth. In fact, I think it is fair that I clarify my bias against jeremy. I realize it can be held against me. What I think is hypocritical and unethical is having rules that are only expected to be followed by some. Is everyone assuming good intentions from me? Is everyone assuming good intentions from luke? Is everyone assuming good intentions from michael? I don't think so. It is against the spirit of the project to base your judgements of a > technical solution on who presents them! You should not be so > technically adrift that you only have reputation left to speak about. > I disagree, I think it is against the spirit of the project to trust ideas based on who they come from. In that sense, I apologize for not being able to distrust every other developer as much as I can distrust jeremy. > If you disagree with ideas, then shoot them down on the technical merits. > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html > I've tried regarding bip8 and speedy trial. I may be wrong, but I think those ideas have been discarded not on their technical merits, but based on who were promoting them. I feel there has been a biased against people like Luke-jr or me. That's subjective. Perhaps I'm just being paranoid. But I truly think Jeremy distrusts me and luke as much as I distrusts him, he just won't say it. Anyway, I had said it once before, so I guess there's no need to further disclaim my bias against jeremy. > If you disagree with people, then take it to smuttier sections of the > Internet. > > Yeah, to twitter, right? lol, sorry, I couldn't resist the joke. Sorry. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Hi Jorge > Can we agree now that resisting a bip8 proposal is simpler and cleaner than > resisting a speedy trial proposal? Personally I'd rather stick to one challenge at a time :) Currently we are facing a contentious soft fork activation attempt of CTV using an alternative client which we expect [1] to be a Speedy Trial deployment. Once this is resolved we can discuss the lessons and observations that come out of this. > Is there any PR to actively resist the proposal on bitcoin core? Not currently. Unless this becomes really, really messy and starts to pose a true existential threat to Bitcoin itself I think it best that attempts to actively resist the proposal are done outside of Bitcoin Core in an alternative client(s). Contrary to what some CTV proponents say getting anything consensus related into Bitcoin Core is extremely difficult (especially at short notice). There is no BDFL or Linus Torvalds like figure, there are a large number of contributors (and maintainers) who all have differing personal views. Hence directing people to have this discussion on a particular PR in the Bitcoin Core repo seems to me to be counterproductive and a massive distraction to other work that is going on on Bitcoin Core. We've already started to see online attacks on Bitcoin Core by CTV proponents [2] claiming an "old guard trying to assert dictatorship over the Bitcoin protocol". It is nonsense of course but directing that nonsense to the Bitcoin Core repo is surely not the right way to go. As I've said in previous emails there is a Libera (and Freenode now) IRC channel ##ursf that has been set up to discuss an alternative client. We'll get a conversation log up too. And of course we wait for confirmation on what the Speedy Trial deployment parameters for this attempted CTV soft fork are going to be. [1]: https://blog.bitmex.com/op_ctv-summer-softfork-shenanigans/ [2]: https://twitter.com/ProofOfKeags/status/1517574210691887105?s=20=_jgRh3kkYP3kn1qLuzGXrQ -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Saturday, April 23rd, 2022 at 21:40, Jorge Timón wrote: > I've been calling them "controversial softforks" for long. > I hate to be right some times, but I guess I'm happy that I'm not the only > one who distrusts jeremy rubin anymore. > > Can we agree now that resisting a bip8 proposal is simpler and cleaner than > resisting a speedy trial proposal? > I guess now we don't need to discuss it in hypothetical terms anymore, do we? > > Is there any PR to actively resist the proposal on bitcoin core? > > On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev > wrote: > >> Ok so we've had to scramble a bit as I don't think anyone except perhaps >> Jeremy thought that there would be a Speedy Trial signaling period for a CTV >> soft fork planned to start on May 5th [1]. That is two weeks away. >> >> (I have to take what he says at face value. I can understand why one would >> be skeptical.) >> >> Understandably this has angered and surprised a few people including some of >> those who have voiced opposition to a CTV soft fork activation being >> attempted in the first place [2]. >> >> As I've said in a previous post [3] the Bitcoin Core 23.0 release candidate >> (and older versions) does not include any CTV code or CTV activation code. >> If a miner runs Bitcoin Core 23.0 out the box it will not signal for CTV. If >> by some chance CTV was to activate through some other software release >> Bitcoin Core releases would not apply CTV rules but they also wouldn't >> reject blocks that apply CTV rules. Hence it is prudent to prepare for an >> eventuality where the miner signaling threshold might be reached but the >> community wants to prevent the attempted soft fork from activating. (I >> personally don't think a 90 percent miner signaling threshold will be >> reached but I wouldn't want to bet Bitcoin's future on it.) >> >> I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but >> I'm open to better names. I certainly don't want to discourage those who >> dislike or oppose UASFs from contributing to this effort and potentially >> ultimately running a URSF release. If you don't want this rushed CTV soft >> fork to activate we are all on the same side whatever we call it. >> >> For now I've set up a ##ursf channel on Libera IRC to monitor developments >> and discuss working on an additional release that if run may ultimately >> reject blocks that signal for CTV. >> >> The intention of this would be to provide additional direction and incentive >> to miners that the community does not want this soft fork to be activated. >> To repeat running a Bitcoin Core release will not signal for a CTV soft fork >> out the box. If a miner runs a Bitcoin Core release it will not signal for >> CTV. >> >>
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev wrote: >I like the maxim of Peter Todd: any change of Bitcoin must benefit *all* >users. This means that every change must have well-defined and transparent >benefits. Personally I believe that the only additions to the protocol that >would still be acceptable are those that clearly benefit layer 2 solutions >such as LN *and* do not carry the dangerous potential of getting abused by >freeloaders selling commercial services on top of “free” eternal storage on >the blockchain. To strengthen your point: benefiting "all users" can only be done by benefiting layer 2 solutions in some way, because it's inevitable that the vast majority of users will use layer 2 because that's the only known way that Bitcoin can scale. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Sun, Apr 24, 2022 at 1:12 PM Jorge Timón wrote: > [...all context chopped, mid-sentence...] > I think it is against the spirit of the project to trust ideas based on who > they come from. On this we agree! ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Michael and Jorge, It is ethically inappropriate to make personal attacks on the trustworthiness of participants on this list, on such vague grounds as disliking an activation proposal! https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith It is against the spirit of the project to base your judgements of a technical solution on who presents them! You should not be so technically adrift that you only have reputation left to speak about. If you disagree with ideas, then shoot them down on the technical merits. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011457.html If you disagree with people, then take it to smuttier sections of the Internet. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
I've been calling them "controversial softforks" for long. I hate to be right some times, but I guess I'm happy that I'm not the only one who distrusts jeremy rubin anymore. Can we agree now that resisting a bip8 proposal is simpler and cleaner than resisting a speedy trial proposal? I guess now we don't need to discuss it in hypothetical terms anymore, do we? Is there any PR to actively resist the proposal on bitcoin core? On Thu, Apr 21, 2022 at 8:16 PM Michael Folkson via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Ok so we've had to scramble a bit as I don't think anyone except perhaps > Jeremy thought that there would be a Speedy Trial signaling period for a > CTV soft fork planned to start on May 5th [1]. That is two weeks away. > > (I have to take what he says at face value. I can understand why one would > be skeptical.) > > Understandably this has angered and surprised a few people including some > of those who have voiced opposition to a CTV soft fork activation being > attempted in the first place [2]. > > As I've said in a previous post [3] the Bitcoin Core 23.0 release > candidate (and older versions) does not include any CTV code or CTV > activation code. If a miner runs Bitcoin Core 23.0 out the box it will not > signal for CTV. If by some chance CTV was to activate through some other > software release Bitcoin Core releases would not apply CTV rules but they > also wouldn't reject blocks that apply CTV rules. Hence it is prudent to > prepare for an eventuality where the miner signaling threshold might be > reached but the community wants to prevent the attempted soft fork from > activating. (I personally don't think a 90 percent miner signaling > threshold will be reached but I wouldn't want to bet Bitcoin's future on > it.) > > I've tentatively labelled this effort a User Resisted Soft Fork (URSF) but > I'm open to better names. I certainly don't want to discourage those who > dislike or oppose UASFs from contributing to this effort and potentially > ultimately running a URSF release. If you don't want this rushed CTV soft > fork to activate we are all on the same side whatever we call it. > > For now I've set up a ##ursf channel on Libera IRC to monitor developments > and discuss working on an additional release that if run may ultimately > reject blocks that signal for CTV. > > The intention of this would be to provide additional direction and > incentive to miners that the community does not want this soft fork to be > activated. To repeat running a Bitcoin Core release will not signal for a > CTV soft fork out the box. If a miner runs a Bitcoin Core release it will > not signal for CTV. > > Apologies that this is rushed. But as always with Jeremy caution and > conservatism seems to be thrown out the window and we have to react to > that. It goes without saying that this is not how Bitcoin consensus changes > should be attempted. > > [1]: https://rubin.io/bitcoin/2022/04/17/next-steps-bip119/ > [2]: > https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 > [3]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020235.html > > -- > Michael Folkson > Email: michaelfolkson at protonmail.com > Keybase: michaelfolkson > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Sat, Apr 23, 2022, 5:05 AM Billy Tetrud via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > @Zac > > More use cases means more blockchain usage which increases the price of > a transaction for *everyone*. > > This is IMO a ridiculous opposition. Anything that increases the utility > of the bitcoin network will increase usage of the blockchain and increase > the price of a transaction on average. It is absurd to say such a thing is > bad for bitcoin. Its like the old saying: "nobody goes there any more - > its too crowded". > > > I like the maxim of Peter Todd: any change of Bitcoin must benefit *all* > users. > > This is a fair opinion to take on the face of it. However, I completely > disagree with it. Why must any change benefit *all* users? Did segwit > benefit all users? Did taproot? What if an upgrade benefits 90% of users > a LOT and at the same time doesn't negatively affect the other 10%? Is that > a bad change? I think you'd find it very difficult to argue it is. > > Regardless of the above, I think CTV *does *in fact likely provide > substantial benefit to all users in the following ways: > > 1. CTV allows much easier/cheaper ways of improving their security via > wallet vaults, > Maybe. But there are enough security caveats that it probably needs other opcodes too to be useful. DLCs, channels > APO (BIP118) handles these with a smaller footprint and many other use cases. > Someone want to volunteer to make a table of use cases, proposed opcodes (CTV, APO) and a maturity and efficiency rating at each intersection? Hard to juggle all this. I'm not a fan of the squeaky wheel method of consensus. I do think most people believe some form of restricted, well-tested covenants that don't allow for recursion should make it into Bitcoin at some point. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
@Zac > More use cases means more blockchain usage which increases the price of a transaction for *everyone*. This is IMO a ridiculous opposition. Anything that increases the utility of the bitcoin network will increase usage of the blockchain and increase the price of a transaction on average. It is absurd to say such a thing is bad for bitcoin. Its like the old saying: "nobody goes there any more - its too crowded". > I like the maxim of Peter Todd: any change of Bitcoin must benefit *all* users. This is a fair opinion to take on the face of it. However, I completely disagree with it. Why must any change benefit *all* users? Did segwit benefit all users? Did taproot? What if an upgrade benefits 90% of users a LOT and at the same time doesn't negatively affect the other 10%? Is that a bad change? I think you'd find it very difficult to argue it is. Regardless of the above, I think CTV *does *in fact likely provide substantial benefit to all users in the following ways: 1. CTV allows much easier/cheaper ways of improving their security via wallet vaults, DLCs, channels, and many other use cases. This means both societal benefit that grows the value of the bitcoin network and on-chain benefit that reduces the fees people have to pay for certain utility, which leads to lower fees for everyone. 2. Wallet vaults specifically, that CTV would unlock, would make it substantially easier and cheaper to hold funds in a multi key vault (akin to but better than a classic multisig wallet). This could substantially increase the fraction of users that self-custody their bitcoin. This increased self-custodiation would substantially improve the decentralization of bitcoin in terms of holdership which is an important part of bitcoin's resilience, which would be a huge benefit to anyone that holds bitcoin or relies on the bitcoin network in any way. Even if a minority (eg 20%) of bitcoin users use CTV, it would have a substantial positive effect for everyone because of these things. On Fri, Apr 22, 2022 at 10:40 AM Corey Haddad via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > >*A change that increases the number of use cases of Bitcoin affects all > users and is *not* non-invasive. More use cases means more blockchain usage > which increases the price of a transaction for *everyone*.* > > This manages to be both incorrect and philosophically opposed to what > defines success of the project . Neither the number of ways that people > figure out how to innovatively harness Bitcoin's existing capabilities, nor > the number or complexity of any optional transaction types that the Bitcoin > protocol supports have any bearing on transaction fees. Demand for > blockspace from transactions, which is just plain *use* - and not *use > cases* - is what could drive up transaction fees. > > On the philosophical level, as designers of the system, we all hope and > work to make Bitcoin so useful, appealing, and secure that there is massive > demand for blockspace, even in the face of high transaction fees. As an > individual thinking only of their next on-chain transaction, it is > understandable that one might hope for low fees and partially-filled > blocks. Longer term, the health of the system can both be measured by and > itself depends on high transaction demand and fee pressure. > > If you were trying to argue that CTV is invasive because it may increase > transaction demand and therefore cost users more fees, that is 1) an > endorsement of CTV's desirability and 2) reveals that you consider any > increased free-market competition (i.e. more demand) to be "invasive". > > > *>I like the maxim of Peter Todd: any change of Bitcoin must benefit *all* > users. * > > As for Peter Todd's "any change of Bitcoin must benefit *all* users", that > is absolutely a reasonable thing to consider. However, in order to make > practical use of that maxim, we must adopt in our minds a *generic*, or > "model user", and then replicate them so that we may meaningfully > understand a least a proxy for "all users". In reality, there will always > be someone (and at this point, probably a "user" too) who wouldn't benefit > from a change, or at least think they won't. Some users of Bitcoin may even > want Bitcoin to fail, so we cannot afford assume that people have alignment > of goals or vision just by virtue of being a 'user'. > > Corey > > >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
>*A change that increases the number of use cases of Bitcoin affects all users and is *not* non-invasive. More use cases means more blockchain usage which increases the price of a transaction for *everyone*.* This manages to be both incorrect and philosophically opposed to what defines success of the project . Neither the number of ways that people figure out how to innovatively harness Bitcoin's existing capabilities, nor the number or complexity of any optional transaction types that the Bitcoin protocol supports have any bearing on transaction fees. Demand for blockspace from transactions, which is just plain *use* - and not *use cases* - is what could drive up transaction fees. On the philosophical level, as designers of the system, we all hope and work to make Bitcoin so useful, appealing, and secure that there is massive demand for blockspace, even in the face of high transaction fees. As an individual thinking only of their next on-chain transaction, it is understandable that one might hope for low fees and partially-filled blocks. Longer term, the health of the system can both be measured by and itself depends on high transaction demand and fee pressure. If you were trying to argue that CTV is invasive because it may increase transaction demand and therefore cost users more fees, that is 1) an endorsement of CTV's desirability and 2) reveals that you consider any increased free-market competition (i.e. more demand) to be "invasive". *>I like the maxim of Peter Todd: any change of Bitcoin must benefit *all* users. * As for Peter Todd's "any change of Bitcoin must benefit *all* users", that is absolutely a reasonable thing to consider. However, in order to make practical use of that maxim, we must adopt in our minds a *generic*, or "model user", and then replicate them so that we may meaningfully understand a least a proxy for "all users". In reality, there will always be someone (and at this point, probably a "user" too) who wouldn't benefit from a change, or at least think they won't. Some users of Bitcoin may even want Bitcoin to fail, so we cannot afford assume that people have alignment of goals or vision just by virtue of being a 'user'. Corey > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
I'm going to keep this short as I'm sure you are not interested in discussion on supposedly "unhinged" takes. Plus I know you support this soft fork activation attempt, you have heard the arguments from various people against attempting it and if you don't believe by now that soft forks should have community consensus before they are attempted nothing will convince you. > Resisting changes that don't affect you The consensus rules are essentially what define Bitcoin. Bitcoin is nothing without well defined and rarely changing consensus rules. If they can be changed by a subset of the community against the wishes of another subset of the community then we may as well accept that all soft fork proposals will eventually get activated because all soft fork proposals will be able to get a subset of the community to support them. (There are a lot of proposals out there.) Decentralized decision making requires that we collectively set high bars when considering making changes to the most important and dangerous part of Bitcoin. Once consensus rules are changed they generally need a hard fork to revert. This is Bitcoin 101. I really shouldn't need to explain this to you. There was a lot of work done by a large number of people to slowly build community consensus around Taproot. You seem to be arguing that that work was pointless because ultimately Taproot doesn't affect the community. If you don't like it don't use it right? Just keep quiet? Nothing to do with you? Gosh > You've gone from saying you won't NACK the proposal on its own to > intentionally cause consensus forks to block its enforcement. Can you provide a link? If there was community consensus a single NACK from me would be pointless. I'm assuming that's the context in which it was said. I've been consistent on wanting community consensus before any soft fork is attempted. If there is community consensus it doesn't matter what I think. This is not a proposal that currently has community consensus and you are seeking to attempt to activate it anyway. Look at some of the individuals on this list. Only yesterday Matt Corallo, Adam Back, Murch, Bob McElrath etc were arguing online this should not be attempted. Perhaps you want to call their takes "unhinged" too? https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718 I'm happy to discuss anything with those who are on the fence or who are genuinely trying to come to a view on this. But I won't be responding again to people like Jeremy, Keagan etc who I know perfectly well understand these arguments, ignore them and proceed regardless. -- Michael Folkson Email: michaelfolkson at [protonmail.com](http://protonmail.com/) Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 --- Original Message --- On Friday, April 22nd, 2022 at 12:36 AM, Keagan McClelland wrote: > Good day Michael, >> and discuss working on an additional release that if run may ultimately >> reject blocks that signal for CTV. > This seems silly to me. > > The structure of CTV is imbuing an OP_NOP with script semantics. Resisting > changes that don't affect you is not consistent with the ideals of people > being able to structure their own private agreements as they see fit...aka > freedom. It seems needlessly coercive to try and resist CTV in this way. CTV > is ultimately an opt-in proposal. If you don't like the risk/benefit ratio, > you can simply not generate scripts that contain CTV checks. Conservatism and > apathy are something I can understand, but resisting CTV via an escalating > soft fork is not conservatism or apathy, it's fundamental opposition. What is > it that you hope to accomplish by blocking others from using a new opcode? > According to your formal statement, you haven't really opposed CTV on > fundamental grounds so much as vaguely questioning whether or not it is the > "best tool for the job"...as if anyone really has the capacity to judge that > for a diverse group with varying interests and use cases that may differ > substantially from their own. > > There are really two ways to effectively resist this change: 1. reject all > blocks during the lockin period, 2. reject all blocks that include OP_CTV in > the script. > > Regardless of which method you choose, it is ultimately going to be a far > more forceful/invasive consensus change than CTV was in the first place. So > have fun trying to explain yourself out of that one. You've gone from saying > you won't NACK the proposal on its own to intentionally cause consensus forks > to block its enforcement. Did you change your mind or something? >> Hence it is prudent to prepare for an eventuality where the miner signaling >> threshold might be reached but the community wants to prevent the attempted >> soft fork from activating. (I personally don't think a 90 percent miner >> signaling threshold will be reached but I wouldn't want to bet Bitcoin's >> future
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
On Fri, 22 Apr 2022 at 09:56, Keagan McClelland via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I think that trying to find ways to activate non-invasive changes should > be everyone's goal, *even if* they personally may not have an immediate use > case > A change that increases the number of use cases of Bitcoin affects all users and is *not* non-invasive. More use cases means more blockchain usage which increases the price of a transaction for *everyone*. I like the maxim of Peter Todd: any change of Bitcoin must benefit *all* users. This means that every change must have well-defined and transparent benefits. Personally I believe that the only additions to the protocol that would still be acceptable are those that clearly benefit layer 2 solutions such as LN *and* do not carry the dangerous potential of getting abused by freeloaders selling commercial services on top of “free” eternal storage on the blockchain. Zac > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] User Resisted Soft Fork for CTV
Good day Michael, > and discuss working on an additional release that if run may ultimately reject blocks that signal for CTV. This seems silly to me. The structure of CTV is imbuing an OP_NOP with script semantics. Resisting changes that don't affect you is not consistent with the ideals of people being able to structure their own private agreements as they see fit...aka freedom. It seems needlessly coercive to try and resist CTV in this way. CTV is ultimately an opt-in proposal. If you don't like the risk/benefit ratio, you can simply not generate scripts that contain CTV checks. Conservatism and apathy are something I can understand, but resisting CTV via an escalating soft fork is not conservatism or apathy, it's fundamental opposition. What is it that you hope to accomplish by blocking others from using a new opcode? According to your formal statement, you haven't really opposed CTV on fundamental grounds so much as vaguely questioning whether or not it is the "best tool for the job"...as if anyone really has the capacity to judge that for a diverse group with varying interests and use cases that may differ substantially from their own. There are really two ways to effectively resist this change: 1. reject all blocks during the lockin period, 2. reject all blocks that include OP_CTV in the script. Regardless of which method you choose, it is ultimately going to be a far more forceful/invasive consensus change than CTV was in the first place. So have fun trying to explain yourself out of that one. You've gone from saying you won't NACK the proposal on its own to intentionally cause consensus forks to block its enforcement. Did you change your mind or something? > Hence it is prudent to prepare for an eventuality where the miner signaling threshold might be reached but the community wants to prevent the attempted soft fork from activating. (I personally don't think a 90 percent miner signaling threshold will be reached but I wouldn't want to bet Bitcoin's future on it.) Making the statement that "the community doesn't want this to activate" as if it's some kind of foregone conclusion is a pretty bold claim. I think you'll be surprised at how broad support actually is. To contrast your second citation, here's the set of people who have endorsed the proposal, along with a handful of people opposed (such as yourself): https://utxos.org/signals/. If you are aware of others who are opposed, it would be worth your time to solicit a statement from them that can be put on the signals page. Absent that, it seems appropriate to assume that the overwhelming majority of people who have opined on the subject are for it. > But as always with Jeremy caution and conservatism seems to be thrown out the window and we have to react to that. It goes without saying that this is not how Bitcoin consensus changes should be attempted. What an unhinged take. The level of effort put into gathering consensus for CTV has set the bar higher than Taproot. Taproot didn't have the level of outreach effort that CTV does, and the complexity in taproot is significantly larger than for CTV. You didn't seem to have a problem organizing that activation process. That proposal was opened for public discussion in Jan'20, merged in Oct'20, and you were organizing activation discussions as early as Jan'21. The design of CTV has been *final* since Feb'20, a month after Taproot was opened for public discussion. There's a ton of Proof-of-Concept code that has been written to test out use cases for CTV, but for Taproot it still doesn't look like we'll have MuSig for a while longer (I heard a year, but someone can correct me on that if I'm wrong), and wallet support for Taproot wasn't fleshed out until after activation. Characterizing Jeremy's efforts as throwing caution and conservatism out the window is hypocritical at best and malicious at worst. Finally, I think it is worth stating that if Bitcoin adopts a culture where a willfully ignorant set of people can block changes that have no impact on them, despite a large constituency wanting those changes, then Bitcoin kind of deserves the slow deterioration that will result from that. I don't really find that future appealing and so I think that trying to find ways to activate non-invasive changes should be everyone's goal, *even if* they personally may not have an immediate use case, or have a slight preference for alternate solutions. The exception to this is any introduction of systemic risk. Not all soft-forks are equal, and therefore the meta-consensus requirements for getting them activated should vary based on how broadly consequential the change is. Feel free to resist this if you want. In some sense that's what the Speedy Trial procedure is for. However, I think your case would be more compelling if you actually had some sort of affirmative argument for why CTV induces systemic risk to non-users of the opcode. Expressing uncertainty over whether it is the globally optimal
