[bitcoin-dev] User Resisted Soft Fork for CTV

[bitcoin-dev] User Resisted Soft Fork for CTV

[Michael Folkson]

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

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](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Keagan McClelland]

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

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 solution (to a problem that cannot be
globally defined due to diverse interests) is not persuasive to me and many
others in the community.

Keagan

On Thu, Apr 21, 2022 at 12: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
>

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Zac Greenwood]

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

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

>

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Corey Haddad]

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

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

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Billy Tetrud]

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

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

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Erik Aronesty]

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

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.

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Peter Todd]

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.

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[ZmnSCPxj]

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Zac Greenwood]

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

On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj <ZmnSCPxj@protonmail.com> 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

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[ZmnSCPxj]

Good morning Zac,

> On Mon, 25 Apr 2022 at 07:36, ZmnSCPxj <zmnscpxj@protonmail.com> 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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Michael Folkson]

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

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 <keagan.mcclelland@gmail.com> 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 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 solution (to a problem that cannot be globally defined due to diverse interests) is not persuasive to me and many others in the community.
> Keagan
>
> On Thu, Apr 21, 2022 at 12: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](http://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

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Jorge Timón]

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

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
>

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Michael Folkson]

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

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&t=_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 <jtimon@jtimon.cc> 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 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](http://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

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Jorge Timón]

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

On Sun, Apr 24, 2022 at 2:17 PM Michael Folkson <
michaelfolkson@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&t=_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 <jtimon@jtimon.cc>
> 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 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
>>
>
>

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Ryan Grant]

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.

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Jorge Timón]

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

On Sun, Apr 24, 2022 at 2:56 PM Ryan Grant <bitcoin-dev@rgrant.org> 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.

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

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[Ryan Grant]

On Sun, Apr 24, 2022 at 1:12 PM Jorge Timón <jtimon@jtimon.cc> 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!

Re: [bitcoin-dev] User Resisted Soft Fork for CTV

[alicexbt]

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

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.

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