[bitcoin-dev] Speedy Trial

[bitcoin-dev] Speedy Trial

[Russell O'Connor]

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

On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> You're right, we shouldn't get personal. We shouldn't ignore feedback from
> me, mark friedenbach or luke just because of who it comes from.
>

For goodness sake Jorge, enough with the persecution complex.

As the person who initially proposed the Speedy Trial deployment design, I
can say it was designed to take in account those concerns raised by luke-jr
and the "no-miner-veto" faction.  I also listened to the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction
and their concerns.

The "no-miner-veto" concerns are, to an extent, addressed by the short
timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
their feet.  If ST fails to active then we are back where we started with
at most a few weeks lost.  And those weeks aren't really lost if they would
have been wasted away anyways trying to find broad consensus on another
deployment mechanism.

I get that you don't like the design of Speedy Trial.  You may even object
that it fails to really address your concerns by leaving open how to follow
up a failed Speedy Trial deployment.  But regardless of how you feel, I
believe I did meaningfully address the those miner-veto concerns and other
people agree with me.

If you are so concerned about listening to legitimate criticism, maybe you
can design a new deployment mechanism that addresses the concerns of the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules"
faction.  Or do you feel that their concerns are illegitimate?  Maybe, by
sheer coincidence, all people you disagree with have illegitimate concerns
while only your concerns are legitimate.

A major contender to the Speedy Trial design at the time was to mandate
eventual forced signalling, championed by luke-jr.  It turns out that, at
the time of that proposal, a large amount of hash power simply did not have
the firmware required to support signalling.  That activation proposal
never got broad consensus, and rightly so, because in retrospect we see
that the design might have risked knocking a significant fraction of mining
power offline if it had been deployed.  Imagine if the firmware couldn't be
quickly updated or imagine if the problem had been hardware related.

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

Re: [bitcoin-dev] Speedy Trial

[Luke Dashjr]

On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> The "no-miner-veto" concerns are, to an extent, addressed by the short
> timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
> their feet.

It's still a miner veto. The only way this works is if the full deployment 
(with UASF fallback) is released in parallel.

> If you are so concerned about listening to legitimate criticism, maybe you
> can design a new deployment mechanism that addresses the concerns of the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> faction.

BIP8 already does that.

> A major contender to the Speedy Trial design at the time was to mandate
> eventual forced signalling, championed by luke-jr.  It turns out that, at
> the time of that proposal, a large amount of hash power simply did not have
> the firmware required to support signalling.  That activation proposal
> never got broad consensus,

BIP 8 did in fact have broad consensus before some devs decided to ignore the 
community and do their own thing. Why are you trying to rewrite history?

> and rightly so, because in retrospect we see 
> that the design might have risked knocking a significant fraction of mining
> power offline if it had been deployed.  Imagine if the firmware couldn't be
> quickly updated or imagine if the problem had been hardware related.

They had 18 months to fix their broken firmware. That's plenty of time.

Luke

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

>  BIP 8 did in fact have broad consensus

I hear you claim this often Luke, but claiming its so does not make it so.
Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some evidence
<https://www.youtube.com/watch?v=U7rXOgL4oFQ> and present it.

On Thu, Mar 10, 2022 at 6:38 PM Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote:
> > The "no-miner-veto" concerns are, to an extent, addressed by the short
> > timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
> > their feet.
>
> It's still a miner veto. The only way this works is if the full deployment
> (with UASF fallback) is released in parallel.
>
> > If you are so concerned about listening to legitimate criticism, maybe
> you
> > can design a new deployment mechanism that addresses the concerns of the
> > "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> > faction.
>
> BIP8 already does that.
>
> > A major contender to the Speedy Trial design at the time was to mandate
> > eventual forced signalling, championed by luke-jr.  It turns out that, at
> > the time of that proposal, a large amount of hash power simply did not
> have
> > the firmware required to support signalling.  That activation proposal
> > never got broad consensus,
>
> BIP 8 did in fact have broad consensus before some devs decided to ignore
> the
> community and do their own thing. Why are you trying to rewrite history?
>
> > and rightly so, because in retrospect we see
> > that the design might have risked knocking a significant fraction of
> mining
> > power offline if it had been deployed.  Imagine if the firmware couldn't
> be
> > quickly updated or imagine if the problem had been hardware related.
>
> They had 18 months to fix their broken firmware. That's plenty of time.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

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

On Fri, Mar 11, 2022, 00:12 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> You're right, we shouldn't get personal. We shouldn't ignore feedback
>> from me, mark friedenbach or luke just because of who it comes from.
>>
>
> For goodness sake Jorge, enough with the persecution complex.
>

Thanks for answering.

As the person who initially proposed the Speedy Trial deployment design, I
> can say it was designed to take in account those concerns raised by luke-jr
> and the "no-miner-veto" faction.  I also listened to the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction
> and their concerns.
>

That's great, but it still doesn't take into account my concerns. I'm not
part of any of those "factions". I guess I'm part of the "yes-user-veto"
faction. I know, I know, we don't matter because the "no-divergent-rules"
"faction" matters too much for us to be listened.



The "no-miner-veto" concerns are, to an extent, addressed by the short
> timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
> their feet.  If ST fails to active then we are back where we started with
> at most a few weeks lost.  And those weeks aren't really lost if they would
> have been wasted away anyways trying to find broad consensus on another
> deployment mechanism.
>
> I get that you don't like the design of Speedy Trial.  You may even object
> that it fails to really address your concerns by leaving open how to follow
> up a failed Speedy Trial deployment.  But regardless of how you feel, I
> believe I did meaningfully address the those miner-veto concerns and other
> people agree with me.
>
> If you are so concerned about listening to legitimate criticism, maybe you
> can design a new deployment mechanism that addresses the concerns of the
> "devs-do-not-decide" faction and the "no-divegent-consensus-rules"
> faction.  Or do you feel that their concerns are illegitimate?  Maybe, by
> sheer coincidence, all people you disagree with have illegitimate concerns
> while only your concerns are legitimate.
>

I talked about this. But the "no-divergent-rules" faction doesn't like it,
so we can pretend we have listened to this "faction" and addressed all its
concerns, I guess.
Or perhaps it's just "prosectution complex", but, hey, what do I know about
psychology?

A major contender to the Speedy Trial design at the time was to mandate
> eventual forced signalling, championed by luke-jr.  It turns out that, at
> the time of that proposal, a large amount of hash power simply did not have
> the firmware required to support signalling.  That activation proposal
> never got broad consensus, and rightly so, because in retrospect we see
> that the design might have risked knocking a significant fraction of mining
> power offline if it had been deployed.  Imagine if the firmware couldn't be
> quickly updated or imagine if the problem had been hardware related.
>

Yes, I like this solution too, with a little caveat: an easy mechanism for
users to actively oppose a proposal.
Luke alao talked about this.
If users oppose, they should use activation as a trigger to fork out of the
network by invalidating the block that produces activation.
The bad scenario here is that miners want to deploy something but users
don't want to.
"But that may lead to a fork". Yeah, I know.
I hope imagining a scenario in which developers propose something that most
miners accept but some users reject is not taboo.

Some of these discussions started at the time of segwit activation. Yes,
segwit, not taproot.

As for mark, he wasn't talking about activation, but quantum computing
concerns. Perhaps those have been "addressed"?
I just don't know where.

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

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

Re: [bitcoin-dev] Speedy Trial

[Russell O'Connor]

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

On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón <jtimon@jtimon.cc> wrote:

> I talked about this. But the "no-divergent-rules" faction doesn't like it,
> so we can pretend we have listened to this "faction" and addressed all its
> concerns, I guess.
> Or perhaps it's just "prosectution complex", but, hey, what do I know
> about psychology?
>

Your accusations of bad faith on the part of myself and pretty much
everyone else makes me disinclined to continue this discussion with you.
I'll reply, but if you want me to continue beyond this, then you need to
knock it off with the accusations.


> A major contender to the Speedy Trial design at the time was to mandate
>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>> the time of that proposal, a large amount of hash power simply did not have
>> the firmware required to support signalling.  That activation proposal
>> never got broad consensus, and rightly so, because in retrospect we see
>> that the design might have risked knocking a significant fraction of mining
>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>> quickly updated or imagine if the problem had been hardware related.
>>
>
> Yes, I like this solution too, with a little caveat: an easy mechanism for
> users to actively oppose a proposal.
> Luke alao talked about this.
> If users oppose, they should use activation as a trigger to fork out of
> the network by invalidating the block that produces activation.
> The bad scenario here is that miners want to deploy something but users
> don't want to.
> "But that may lead to a fork". Yeah, I know.
> I hope imagining a scenario in which developers propose something that
> most miners accept but some users reject is not taboo.
>

This topic is not taboo.

There are a couple of ways of opting out of taproot.  Firstly, users can
just not use taproot.  Secondly, users can choose to not enforce taproot
either by running an older version of Bitcoin Core or otherwise forking the
source code.  Thirdly, if some users insist on a chain where taproot is
"not activated", they can always softk-fork in their own rule that
disallows the version bits that complete the Speedy Trial activation
sequence, or alternatively soft-fork in a rule to make spending from (or
to) taproot addresses illegal.

As for mark, he wasn't talking about activation, but quantum computing
> concerns. Perhaps those have been "addressed"?
> I just don't know where.
>

Quantum concerns were discussed.  Working from memory, the arguments were
(1) If you are worried about your funds not being secured by taproot, then
don't use taproot addresses, and (2) If you are worried about everyone
else's funds not being quantum secure by other people choosing to use
taproot, well it is already too late because over 5M BTC is currently
quantum insecure due to pubkey reuse <
https://nitter.net/pwuille/status/1108091924404027392>.  I think it is
unlikely that a quantum breakthrough will sneak up on us without time to
address the issue and, at the very least, warn people to move their funds
off of taproot and other reused addresses, if not forking in some quantum
secure alternative.  A recent paper <
https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>
suggest that millions physical qubits will be needed to break EC in a day
with current error correction technology.  But even if taproot were to be
very suddenly banned, there is still a small possibility for recovery
because one can prove ownership of HD pubkeys by providing a zero-knowledge
proof of the chaincode used to derive them.

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

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

On Fri, Mar 11, 2022, 13:47 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón <jtimon@jtimon.cc> wrote:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this "faction" and addressed all
>> its concerns, I guess.
>> Or perhaps it's just "prosectution complex", but, hey, what do I know
>> about psychology?
>>
>
> Your accusations of bad faith on the part of myself and pretty much
> everyone else makes me disinclined to continue this discussion with you.
> I'll reply, but if you want me to continue beyond this, then you need to
> knock it off with the accusations.
>

What accusations of bad faith?
You're accusing me of having prosecution complex.
I'm accusing you of ignoring the "yes-users-veto" faction. But that doesn't
require bad faith, you may simply not understand the "faction".

A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling.  That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>> Yes, I like this solution too, with a little caveat: an easy mechanism
>> for users to actively oppose a proposal.
>> Luke alao talked about this.
>> If users oppose, they should use activation as a trigger to fork out of
>> the network by invalidating the block that produces activation.
>> The bad scenario here is that miners want to deploy something but users
>> don't want to.
>> "But that may lead to a fork". Yeah, I know.
>> I hope imagining a scenario in which developers propose something that
>> most miners accept but some users reject is not taboo.
>>
>
> This topic is not taboo.
>
> There are a couple of ways of opting out of taproot.  Firstly, users can
> just not use taproot.  Secondly, users can choose to not enforce taproot
> either by running an older version of Bitcoin Core or otherwise forking the
> source code.  Thirdly, if some users insist on a chain where taproot is
> "not activated", they can always softk-fork in their own rule that
> disallows the version bits that complete the Speedy Trial activation
> sequence, or alternatively soft-fork in a rule to make spending from (or
> to) taproot addresses illegal.
>

Since it's about activation in general and not about taproot specifically,
your third point is the one that applies.
Users could have coordinated to have "activation x" never activated in
their chains if they simply make a rule that activating a given proposal
(with bip8) is forbidden in their chain.
But coordination requires time.
Please, try to imagine an example for an activation that you wouldn't like
yourself. Imagine it gets proposed and you, as a user, want to resist it.


As for mark, he wasn't talking about activation, but quantum computing
>> concerns. Perhaps those have been "addressed"?
>> I just don't know where.
>>
>
> Quantum concerns were discussed.  Working from memory, the arguments were
> (1) If you are worried about your funds not being secured by taproot, then
> don't use taproot addresses, and (2) If you are worried about everyone
> else's funds not being quantum secure by other people choosing to use
> taproot, well it is already too late because over 5M BTC is currently
> quantum insecure due to pubkey reuse <
> https://nitter.net/pwuille/status/1108091924404027392>.  I think it is
> unlikely that a quantum breakthrough will sneak up on us without time to
> address the issue and, at the very least, warn people to move their funds
> off of taproot and other reused addresses, if not forking in some quantum
> secure alternative.  A recent paper <
> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>
> suggest that millions physical qubits will be needed to break EC in a day
> with current error correction technology.  But even if taproot were to be
> very suddenly banned, there is still a small possibility for recovery
> because one can prove ownership of HD pubkeys by providing a zero-knowledge
> proof of the chaincode used to derive them.
>

Thank you, perhaps I'm wrong about this and all his concerns were addressed
and all his suggestions heard. I guess I shouldn't have brought that up,
since I cannot talk for Mark.

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

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

Re: [bitcoin-dev] Speedy Trial

[Russell O'Connor]

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

On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon@jtimon.cc> wrote:

>
> A major contender to the Speedy Trial design at the time was to mandate
>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>> the time of that proposal, a large amount of hash power simply did not have
>> the firmware required to support signalling.  That activation proposal
>> never got broad consensus, and rightly so, because in retrospect we see
>> that the design might have risked knocking a significant fraction of mining
>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>> quickly updated or imagine if the problem had been hardware related.
>>
>
>>> Yes, I like this solution too, with a little caveat: an easy mechanism
>>> for users to actively oppose a proposal.
>>> Luke alao talked about this.
>>> If users oppose, they should use activation as a trigger to fork out of
>>> the network by invalidating the block that produces activation.
>>> The bad scenario here is that miners want to deploy something but users
>>> don't want to.
>>> "But that may lead to a fork". Yeah, I know.
>>> I hope imagining a scenario in which developers propose something that
>>> most miners accept but some users reject is not taboo.
>>>
>>
>> This topic is not taboo.
>>
>> There are a couple of ways of opting out of taproot.  Firstly, users can
>> just not use taproot.  Secondly, users can choose to not enforce taproot
>> either by running an older version of Bitcoin Core or otherwise forking the
>> source code.  Thirdly, if some users insist on a chain where taproot is
>> "not activated", they can always softk-fork in their own rule that
>> disallows the version bits that complete the Speedy Trial activation
>> sequence, or alternatively soft-fork in a rule to make spending from (or
>> to) taproot addresses illegal.
>>
>
> Since it's about activation in general and not about taproot specifically,
> your third point is the one that applies.
> Users could have coordinated to have "activation x" never activated in
> their chains if they simply make a rule that activating a given proposal
> (with bip8) is forbidden in their chain.
> But coordination requires time.
>

A mechanism of soft-forking against activation exists.  What more do you
want? Are we supposed to write the code on behalf of this hypothetical
group of users who may or may not exist for them just so that they can have
a node that remains stalled on Speedy Trial lockin?  That simply isn't
reasonable, but if you think it is, I invite you to create such a fork.


> Please, try to imagine an example for an activation that you wouldn't like
> yourself. Imagine it gets proposed and you, as a user, want to resist it.
>

If I believe I'm in the economic majority then I'll just refuse to upgrade
my node, which was option 2. I don't know why you dismissed it.

Not much can prevent a miner cartel from enforcing rules that users don't
want other than hard forking a replacement POW.  There is no effective
difference between some developers releasing a malicious soft-fork of
Bitcoin and the miners releasing a malicious version themselves.  And when
the miner cartel forms, they aren't necessarily going to be polite enough
to give a transparent signal of their new rules.  However, without the
economic majority enforcing their set of rules, the cartel continuously
risks falling apart from the temptation of transaction fees of the censored
transactions.

On the other hand, If I find out I'm in the economic minority then I have
little choice but to either accept the existence of the new rules or sell
my Bitcoin.  Look, you cannot have the perfect system of money all by your
lonesome self.  Money doesn't have economic value if no one else wants to
trade you for it.  Just ask that poor user who YOLO'd his own taproot
activation in advance all by themselves.  I'm sure they think they've got
just the perfect money system, with taproot early and everything.  But now
their node is stuck at block 692261
<https://b10c.me/blog/007-spending-p2tr-pre-activation/> and hasn't made
progress since.  No doubt they are hunkered down for the long term,
absolutely committed to their fork and just waiting for the rest of the
world to come around to how much better their version of Bitcoin is than
the rest of us.

Even though you've dismissed it, one of the considerations of taproot was
that it is opt-in for users to use the functionality.  Future soft-forks
ought to have the same considerations to the extent possible.

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

>  If I find out I'm in the economic minority then I have little choice but
to either accept the existence of the new rules or sell my Bitcoin

I do worry about what I have called a "dumb majority soft fork". This is
where, say, mainstream adoption has happened, some crisis of some magnitude
happens that convinces a lot of people something needs to change now. Let's
say it's another congestion period where fees spike for months. Getting
into and out of lighting is hard and maybe even the security of lightning's
security model is called into question because it would either take too
long to get a transaction on chain or be too expensive. Panicy people might
once again think something like "let's increase the block size to 1GB, then
we'll never have this problem again". This could happen in a segwit-like
soft fork.

In a future where Bitcoin is the dominant world currency, it might not be
unrealistic to imagine that an economic majority might not understand why
such a thing would be so dangerous, or think the risk is low enough to be
worth it. At that point, we in the economic minority would need a plan to
hard fork away. One wouldn't necessarily need to sell all their majority
fork Bitcoin, but they could.

That minority fork would of course need some mining power. How much? I
don't know, but we should think about how small of a minority chain we
could imagine might be worth saving. Is 5% enough? 1%? How long would the
chain stall if hash power dropped to 1%?

TBH I give the world a ~50% chance that something like this happens in the
next 100 years. Maybe Bitcoin will ossify and we'll lose all the people
that had deep knowledge on these kinds of things because almost no one's
actively working on it. Maybe the crisis will be too much for people to
remain rational and think long term. Who knows? But I think that at some
point it will become dangerous if there isn't a well discussed well vetted
plan for what to do in such a scenario. Maybe we can think about that 10
years from now, but we probably shouldn't wait much longer than that. And
maybe it's as simple as: tweak the difficulty recalculation and then just
release a soft fork aware Bitcoin version that rejects the new rules or
rejects a specific existing post-soft-fork block. Would it be that simple?

On Sat, Mar 12, 2022, 07:35 Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon@jtimon.cc> wrote:
>
>>
>> A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling.  That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>>>> Yes, I like this solution too, with a little caveat: an easy mechanism
>>>> for users to actively oppose a proposal.
>>>> Luke alao talked about this.
>>>> If users oppose, they should use activation as a trigger to fork out of
>>>> the network by invalidating the block that produces activation.
>>>> The bad scenario here is that miners want to deploy something but users
>>>> don't want to.
>>>> "But that may lead to a fork". Yeah, I know.
>>>> I hope imagining a scenario in which developers propose something that
>>>> most miners accept but some users reject is not taboo.
>>>>
>>>
>>> This topic is not taboo.
>>>
>>> There are a couple of ways of opting out of taproot.  Firstly, users can
>>> just not use taproot.  Secondly, users can choose to not enforce taproot
>>> either by running an older version of Bitcoin Core or otherwise forking the
>>> source code.  Thirdly, if some users insist on a chain where taproot is
>>> "not activated", they can always softk-fork in their own rule that
>>> disallows the version bits that complete the Speedy Trial activation
>>> sequence, or alternatively soft-fork in a rule to make spending from (or
>>> to) taproot addresses illegal.
>>>
>>
>> Since it's about activation in general and not about taproot
>> specifically, your third point is the one that applies.
>> Users could have coordinated to have "activation x" never activated in
>> their chains if they simply make a rule that activating a given proposal
>> (with bip8) is forbidden in their chain.
>> But coordination requires time.
>>
>
> A mechanism of soft-forking against activation exists.  What more do you
> want? Are we supposed to write the code on behalf of this hypothetical
> group of users who may or may not exist for them just so that they can have
> a node that remains stalled on Speedy Trial lockin?  That simply isn't
> reasonable, but if you think it is, I invite you to create such a fork.
>
>
>> Please, try to imagine an example for an activation that you wouldn't
>> like yourself. Imagine it gets proposed and you, as a user, want to resist
>> it.
>>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade
> my node, which was option 2. I don't know why you dismissed it.
>
> Not much can prevent a miner cartel from enforcing rules that users don't
> want other than hard forking a replacement POW.  There is no effective
> difference between some developers releasing a malicious soft-fork of
> Bitcoin and the miners releasing a malicious version themselves.  And when
> the miner cartel forms, they aren't necessarily going to be polite enough
> to give a transparent signal of their new rules.  However, without the
> economic majority enforcing their set of rules, the cartel continuously
> risks falling apart from the temptation of transaction fees of the censored
> transactions.
>
> On the other hand, If I find out I'm in the economic minority then I have
> little choice but to either accept the existence of the new rules or sell
> my Bitcoin.  Look, you cannot have the perfect system of money all by your
> lonesome self.  Money doesn't have economic value if no one else wants to
> trade you for it.  Just ask that poor user who YOLO'd his own taproot
> activation in advance all by themselves.  I'm sure they think they've got
> just the perfect money system, with taproot early and everything.  But now
> their node is stuck at block 692261
> <https://b10c.me/blog/007-spending-p2tr-pre-activation/> and hasn't made
> progress since.  No doubt they are hunkered down for the long term,
> absolutely committed to their fork and just waiting for the rest of the
> world to come around to how much better their version of Bitcoin is than
> the rest of us.
>
> Even though you've dismissed it, one of the considerations of taproot was
> that it is opt-in for users to use the functionality.  Future soft-forks
> ought to have the same considerations to the extent possible.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >  If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is where, say, mainstream adoption has happened, some crisis of some magnitude happens that convinces a lot of people something needs to change now. Let's say it's another congestion period where fees spike for months. Getting into and out of lighting is hard and maybe even the security of lightning's security model is called into question because it would either take too long to get a transaction on chain or be too expensive. Panicy people might once again think something like "let's increase the block size to 1GB, then we'll never have this problem again". This could happen in a segwit-like soft fork.

I guess this is a better explained example for a hypothetical "evil
fork" that may sound more concrete and plausible to some people than
my own, which isn't that different. Thanks.

> In a future where Bitcoin is the dominant world currency, it might not be unrealistic to imagine that an economic majority might not understand why such a thing would be so dangerous, or think the risk is low enough to be worth it. At that point, we in the economic minority would need a plan to hard fork away. One wouldn't necessarily need to sell all their majority fork Bitcoin, but they could.
>
> That minority fork would of course need some mining power. How much? I don't know, but we should think about how small of a minority chain we could imagine might be worth saving. Is 5% enough? 1%? How long would the chain stall if hash power dropped to 1%?

In perfect competition the mining power costs per chain tends to equal
the rewards offered by that chain, both in subsidy and transaction
fees.
For example, if chain A gets a reward 10 times as valuable as chain
B's reward, then one should expect it to get 10 times more hashrate
too.
Of course, perfect competition is just a theoretical concept though.

Re: [bitcoin-dev] Speedy Trial

[Kate Salazar]

Hey

On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >  If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is where, say, mainstream adoption has happened, some crisis of some magnitude happens that convinces a lot of people something needs to change now. Let's say it's another congestion period where fees spike for months. Getting into and out of lighting is hard and maybe even the security of lightning's security model is called into question because it would either take too long to get a transaction on chain or be too expensive. Panicy people might once again think something like "let's increase the block size to 1GB, then we'll never have this problem again". This could happen in a segwit-like soft fork.

Bitcoin has never been mainstream, and yet somehow you have known
where you needed to be, all the time. The same will apply then. This
is a non-issue.

>
> In a future where Bitcoin is the dominant world currency, it might not be unrealistic to imagine that an economic majority might not understand why such a thing would be so dangerous, or think the risk is low enough to be worth it. At that point, we in the economic minority would need a plan to hard fork away. One wouldn't necessarily need to sell all their majority fork Bitcoin, but they could.

Again, Bitcoin _is_ not an economic majority. Has never been. But
smart money always wins. This is a non-issue.

If one doesn't know where to be, there's the option to defer choices.
I was a big blocker myself, and yet I'm fairly OK even after being so
wrong. Even if forced to choose because of evil deadlines (which is
really unlikely), a divide strategy should be helpful enough to cut
losses in those cases.

>
> That minority fork would of course need some mining power. How much? I don't know, but we should think about how small of a minority chain we could imagine might be worth saving. Is 5% enough? 1%? How long would the chain stall if hash power dropped to 1%?
>
> TBH I give the world a ~50% chance that something like this happens in the next 100 years. Maybe Bitcoin will ossify and we'll lose all the people that had deep knowledge on these kinds of things because almost no one's actively working on it. Maybe the crisis will be too much for people to remain rational and think long term. Who knows? But I think that at some point it will become dangerous if there isn't a well discussed well vetted plan for what to do in such a scenario. Maybe we can think about that 10 years from now, but we probably shouldn't wait much longer than that. And maybe it's as simple as: tweak the difficulty recalculation and then just release a soft fork aware Bitcoin version that rejects the new rules or rejects a specific existing post-soft-fork block. Would it be that simple?

Maybe this is worth thinking about, but really, there'll always be
smart enough people around. However
dumb people sometimes are not as dangerous as we think, and
smart people sometimes are not as flawless as we desire to take for granted.

>
> On Sat, Mar 12, 2022, 07:35 Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon@jtimon.cc> wrote:
>>>
>>>
>>>> A major contender to the Speedy Trial design at the time was to mandate eventual forced signalling, championed by luke-jr.  It turns out that, at the time of that proposal, a large amount of hash power simply did not have the firmware required to support signalling.  That activation proposal never got broad consensus, and rightly so, because in retrospect we see that the design might have risked knocking a significant fraction of mining power offline if it had been deployed.  Imagine if the firmware couldn't be quickly updated or imagine if the problem had been hardware related.
>>>>>
>>>>>
>>>>> Yes, I like this solution too, with a little caveat: an easy mechanism for users to actively oppose a proposal.
>>>>> Luke alao talked about this.
>>>>> If users oppose, they should use activation as a trigger to fork out of the network by invalidating the block that produces activation.
>>>>> The bad scenario here is that miners want to deploy something but users don't want to.
>>>>> "But that may lead to a fork". Yeah, I know.
>>>>> I hope imagining a scenario in which developers propose something that most miners accept but some users reject is not taboo.
>>>>
>>>>
>>>> This topic is not taboo.
>>>>
>>>> There are a couple of ways of opting out of taproot.  Firstly, users can just not use taproot.  Secondly, users can choose to not enforce taproot either by running an older version of Bitcoin Core or otherwise forking the source code.  Thirdly, if some users insist on a chain where taproot is "not activated", they can always softk-fork in their own rule that disallows the version bits that complete the Speedy Trial activation sequence, or alternatively soft-fork in a rule to make spending from (or to) taproot addresses illegal.
>>>
>>>
>>> Since it's about activation in general and not about taproot specifically, your third point is the one that applies.
>>> Users could have coordinated to have "activation x" never activated in their chains if they simply make a rule that activating a given proposal (with bip8) is forbidden in their chain.
>>> But coordination requires time.
>>
>>
>> A mechanism of soft-forking against activation exists.  What more do you want? Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin?  That simply isn't reasonable, but if you think it is, I invite you to create such a fork.
>>
>>>
>>> Please, try to imagine an example for an activation that you wouldn't like yourself. Imagine it gets proposed and you, as a user, want to resist it.
>>
>>
>> If I believe I'm in the economic majority then I'll just refuse to upgrade my node, which was option 2. I don't know why you dismissed it.
>>
>> Not much can prevent a miner cartel from enforcing rules that users don't want other than hard forking a replacement POW.  There is no effective difference between some developers releasing a malicious soft-fork of Bitcoin and the miners releasing a malicious version themselves.  And when the miner cartel forms, they aren't necessarily going to be polite enough to give a transparent signal of their new rules.  However, without the economic majority enforcing their set of rules, the cartel continuously risks falling apart from the temptation of transaction fees of the censored transactions.
>>
>> On the other hand, If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin.  Look, you cannot have the perfect system of money all by your lonesome self.  Money doesn't have economic value if no one else wants to trade you for it.  Just ask that poor user who YOLO'd his own taproot activation in advance all by themselves.  I'm sure they think they've got just the perfect money system, with taproot early and everything.  But now their node is stuck at block 692261 and hasn't made progress since.  No doubt they are hunkered down for the long term, absolutely committed to their fork and just waiting for the rest of the world to come around to how much better their version of Bitcoin is than the rest of us.
>>
>> Even though you've dismissed it, one of the considerations of taproot was that it is opt-in for users to use the functionality.  Future soft-forks ought to have the same considerations to the extent possible.
>> _______________________________________________
>> 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] Speedy Trial

[Jeremy Rubin]

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

Boker tov bitcoin devs,

A mechanism of soft-forking against activation exists.  What more do you
> want?
>

Agreed -- that should be enough.



> Are we supposed to write the code on behalf of this hypothetical group of
> users who may or may not exist for them just so that they can have a node
> that remains stalled on Speedy Trial lockin?
>
That simply isn't reasonable, but if you think it is, I invite you to
> create such a fork.
>

Disagree.

It is a reasonable ask.

I've done it in about 40 lines of python:
https://github.com/jeremyrubin/forkd

Merry Christmas Jorge, please vet the code carefully before running.

Peace,

Jeremy

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

@Aj Your steps seem reasonable. I definitely agree step one (talking to
each other) is obviously the ideal solution, when it works.

Step 2 (futures market) is the option I would say I understand the least.
In any case, a futures market seems like it only incorporates the
opinions/predictions of the group of people willing to bet money on things
like this. This is likely to be a rather small group of particular types of
people. I find it a bit difficult to reconcile the theories that betting
rings like this are good at predicting against the inherent selection bias
of the group of betting individuals. Going just by number of individuals
(or probably even by amount of currency risked) this seems like a futures
market would inherently be a small and biased group. Potentially useful,
but I wouldn't assume that it could be taken stand-alone as a proxy for
consensus.

I'm curious what you think about a coin-weighted poll like I suggested here
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019022.html>
being
added to that list of steps? Surely this would be a broader group of people
than a futures market, tho still obviously a group subject to selection
bias.

@jeremy drops the bomb. I'm sure Jorge will be running this within the
year.



On Tue, Mar 15, 2022 at 12:25 PM Jeremy Rubin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Boker tov bitcoin devs,
>
> A mechanism of soft-forking against activation exists.  What more do you
>> want?
>>
>
> Agreed -- that should be enough.
>
>
>
>> Are we supposed to write the code on behalf of this hypothetical group of
>> users who may or may not exist for them just so that they can have a node
>> that remains stalled on Speedy Trial lockin?
>>
> That simply isn't reasonable, but if you think it is, I invite you to
>> create such a fork.
>>
>
> Disagree.
>
> It is a reasonable ask.
>
> I've done it in about 40 lines of python:
> https://github.com/jeremyrubin/forkd
>
> Merry Christmas Jorge, please vet the code carefully before running.
>
> Peace,
>
> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

On Tue, Mar 15, 2022 at 6:25 PM Jeremy Rubin via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Boker tov bitcoin devs,

I don't undesrtand what that means, sorry

>> A mechanism of soft-forking against activation exists.  What more do you want?
>
>
> Agreed -- that should be enough.

No, resistance should ideally be a priori, not a posteriori.

>
>>
>> Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin?
>>
>> That simply isn't reasonable, but if you think it is, I invite you to create such a fork.
>
>
> Disagree.
>
> It is a reasonable ask.
>
> I've done it in about 40 lines of python: https://github.com/jeremyrubin/forkd
>
> Merry Christmas Jorge, please vet the code carefully before running.

40 lines of python code should be easy to bet even if the author was
very bad at writing readable code and obfuscated his code on purpose.
I don't know if it's the case, because, sorry, I'm not reviewing your
code at the moment.
"Vet the code carefully before running" strikes me as arrogant and
condescending. as if you were implying my engineering capacity was
very limited. If you say these things to me publicly, I can only only
imagine what you have told other devs behind my back about my capacity
(or even my ideology) if they ever asked (or perhaps without them
asking). I really hope you haven't lied to anyone about my ideology,
J.
Perhaps I do have "prosectution complex" with you indeed. Not with
Russel, but with you.
After all, I've publicly say I don't trust you, haven't I?
But, again, what do I know about psychology?

Going back on topic, the reason I won't review your code is because
you have rushed a design before understanding the analysis.
No, I'm not asking for a stalled mechanism for speedy trial, I don't
want speedy trial.
We disagree on the analysis of the problem to solve, that's why we
disagree on the design for the solution.

https://en.wikipedia.org/wiki/Systems_development_life_cycle#Analysis

Anyway, perhaps I look at the code in the future if your proposal
consensus change seems to prosper.

Regarding "merry christmas"...what the f are you talking about? it's
not Christmas time and neither you or me are christians, are you?
If this is some sort of riddle or joke, we really must have very
different senses of humor, because I don't get it.
Come on, J, let's both try to stay on topic or people will start to
correctly point out that we both negatively discriminate each other
for offtopic reasons, be them reasonably justified or not.

> Peace,

Ama, y ensancha el alma.

> Jeremy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon@jtimon.cc> wrote:
> A mechanism of soft-forking against activation exists.  What more do you want? Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin?  That simply isn't reasonable, but if you think it is, I invite you to create such a fork.

I want BIP+LOT=true to be used. I want speedy trial not to be used.
Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
write it myself, yes.
If you think that's not reasonable code to ever run, I don't think
you're really getting the "softfork THAT YOU OPPOSE" part of the
hypothetical right. Let me try to help with an example, although I
hope we don't get derailed in the implementation details of the
hypothetical evil proposal.

Suppose someone proposes a weight size limit increase by a extension
block softfork.
Or instead of that, just imagine the final version of the covenants
proposal has a backdoor in it or something.


Would you rather that proposal be deployed with speedy trial
activation or with BIP8+LOT=true activation?

>>
>> Please, try to imagine an example for an activation that you wouldn't like yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade my node, which was option 2. I don't know why you dismissed it.

Not upgrading your node doesn't prevent the softfork from being
activated in your chain.
A softfork may affect you indirectly even if you don't use the new
features yourself directly.
You may chose to stay in the old chain even if you don't consider
you're "in the economic majority" at that moment.

> Not much can prevent a miner cartel from enforcing rules that users don't want other than hard forking a replacement POW.  There is no effective difference between some developers releasing a malicious soft-fork of Bitcoin and the miners releasing a malicious version themselves.  And when the miner cartel forms, they aren't necessarily going to be polite enough to give a transparent signal of their new rules.  However, without the economic majority enforcing their set of rules, the cartel continuously risks falling apart from the temptation of transaction fees of the censored transactions.

It is true that a mining cartel doesn't need to use speedy trial or
BIP8+LOT=true to apply rule changes they want just because we do.
But they would do if they wanted to maintain the appearance of benevolence.

> On the other hand, If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin.  Look, you cannot have the perfect system of money all by your lonesome self.  Money doesn't have economic value if no one else wants to trade you for it.  Just ask that poor user who YOLO'd his own taproot activation in advance all by themselves.  I'm sure they think they've got just the perfect money system, with taproot early and everything.  But now their node is stuck at block 692261 and hasn't made progress since.  No doubt they are hunkered down for the long term, absolutely committed to their fork and just waiting for the rest of the world to come around to how much better their version of Bitcoin is than the rest of us.

Well, you could also have the option to stay in the old chain with the
economic minority, it doesn't have to be you alone.
We agree that one person alone can't use a currency.

> Even though you've dismissed it, one of the considerations of taproot was that it is opt-in for users to use the functionality.  Future soft-forks ought to have the same considerations to the extent possible.

Well, the same could be said about segwit. And yet all the
consequences of the change are not opt in.
For example, segwit contained a block size limit increase.
Sure, you can just not validate the witnesses, but then you're no
longer a full node.

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.

Not the one I'll propose right here. What I propose specifically is
a coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
support:10%}> for each UTXO they want to respond to the poll with.
B. A signed message like that is valid only while that UTXO has not been
spent.
C. Poll results are considered only at each particular block height, where
the support and opposition responses are weighted by the UTXO amount (and
the support/oppose fraction in the message). This means you'd basically see
a rolling poll through the blockchain as new signed poll messages come in
and as their UTXOs are spent.

This is not vulnerable to sybil attacks because it requires access to UTXOs
and response-weight is directly tied to UTXO amount. If someone signs a
poll message with a key that can unlock (or is in some other designated way
associated with) a UTXO, and then spends that UTXO, their poll response
stops being counted for all block heights after the UTXO was spent.

Why put support and oppose fractions in the message? Who would want to both
support and oppose something? Any multiple participant UTXO would. Eg
lightning channels would, where each participant disagrees with the other.
They need to sign together, so they can have an agreement to sign for the
fractions that match their respective channel balances (using a force
channel close as a last resort against an uncooperative partner as usual).

This does have the potential issue of public key exposure prior to spending
for current addresses. But that could be fixed with a new address type that
has two public keys / spend paths: one for spending and one for signing.

> In perfect competition the mining power costs per chain tends to equal
the rewards offered by that chain, both in subsidy and transaction fees.

Agreed, but it takes time for an economic shock to reach its new
equilibrium. That period of time, which might be rather precarious, should
be considered in a plan to preserve a minority fork.

> Would you rather that proposal be deployed with speedy trial activation
or with BIP8+LOT=true activation?

For a proposal I don't want to succeed, I absolutely would prefer speedy
trial over BIP8+LOT=true. Speedy trial at 90% signaling threshold can
quickly determine that the proposal (hopefully) does not have enough
consensus among miners. By contrast, BIP8+LOT=true could polarize the
debate, worsening the community's ability to communicate and talk through
issues. It would also basically guarantee that a fork happens, which in the
best case (in my hypothetical point of view where I don't like the
proposal) would mean some small minority forks off the network, which
reduces the main chain's value somewhat (at least temporarily). Worst case
a small majority forces the issue at near 50% which would cause all sorts
of blockchain issues and would have a high probability of leading to a
hardfork by the minority.

All this sounds rather more tenable with speedy trial. Any proposal has
less chance of causing an actual fork (soft or otherwise) with speedy trial
vs LOT=true. LOT=true guarantees a fork if even a single person is running
it. LOT=true could certainly come in handy to initiate a UASF, but IMO
that's better left as a plan B or C.

> segwit... all the consequences of the change are not opt in.

I definitely agree there. The consequences of a soft fork are not always
opt in. That's basically what my example of a "dumb majority soft fork" is,
and sounds like what your "evil fork" basically is.

On Thu, Mar 17, 2022 at 7:19 AM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon@jtimon.cc> wrote:
> > A mechanism of soft-forking against activation exists.  What more do you
> want? Are we supposed to write the code on behalf of this hypothetical
> group of users who may or may not exist for them just so that they can have
> a node that remains stalled on Speedy Trial lockin?  That simply isn't
> reasonable, but if you think it is, I invite you to create such a fork.
>
> I want BIP+LOT=true to be used. I want speedy trial not to be used.
> Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
> write it myself, yes.
> If you think that's not reasonable code to ever run, I don't think
> you're really getting the "softfork THAT YOU OPPOSE" part of the
> hypothetical right. Let me try to help with an example, although I
> hope we don't get derailed in the implementation details of the
> hypothetical evil proposal.
>
> Suppose someone proposes a weight size limit increase by a extension
> block softfork.
> Or instead of that, just imagine the final version of the covenants
> proposal has a backdoor in it or something.
>
>
> Would you rather that proposal be deployed with speedy trial
> activation or with BIP8+LOT=true activation?
>
> >>
> >> Please, try to imagine an example for an activation that you wouldn't
> like yourself. Imagine it gets proposed and you, as a user, want to resist
> it.
> >
> >
> > If I believe I'm in the economic majority then I'll just refuse to
> upgrade my node, which was option 2. I don't know why you dismissed it.
>
> Not upgrading your node doesn't prevent the softfork from being
> activated in your chain.
> A softfork may affect you indirectly even if you don't use the new
> features yourself directly.
> You may chose to stay in the old chain even if you don't consider
> you're "in the economic majority" at that moment.
>
> > Not much can prevent a miner cartel from enforcing rules that users
> don't want other than hard forking a replacement POW.  There is no
> effective difference between some developers releasing a malicious
> soft-fork of Bitcoin and the miners releasing a malicious version
> themselves.  And when the miner cartel forms, they aren't necessarily going
> to be polite enough to give a transparent signal of their new rules.
> However, without the economic majority enforcing their set of rules, the
> cartel continuously risks falling apart from the temptation of transaction
> fees of the censored transactions.
>
> It is true that a mining cartel doesn't need to use speedy trial or
> BIP8+LOT=true to apply rule changes they want just because we do.
> But they would do if they wanted to maintain the appearance of benevolence.
>
> > On the other hand, If I find out I'm in the economic minority then I
> have little choice but to either accept the existence of the new rules or
> sell my Bitcoin.  Look, you cannot have the perfect system of money all by
> your lonesome self.  Money doesn't have economic value if no one else wants
> to trade you for it.  Just ask that poor user who YOLO'd his own taproot
> activation in advance all by themselves.  I'm sure they think they've got
> just the perfect money system, with taproot early and everything.  But now
> their node is stuck at block 692261 and hasn't made progress since.  No
> doubt they are hunkered down for the long term, absolutely committed to
> their fork and just waiting for the rest of the world to come around to how
> much better their version of Bitcoin is than the rest of us.
>
> Well, you could also have the option to stay in the old chain with the
> economic minority, it doesn't have to be you alone.
> We agree that one person alone can't use a currency.
>
> > Even though you've dismissed it, one of the considerations of taproot
> was that it is opt-in for users to use the functionality.  Future
> soft-forks ought to have the same considerations to the extent possible.
>
> Well, the same could be said about segwit. And yet all the
> consequences of the change are not opt in.
> For example, segwit contained a block size limit increase.
> Sure, you can just not validate the witnesses, but then you're no
> longer a full node.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[ZmnSCPxj]

Good morning Billy,

> @Jorge
> > Any user polling system is going to be vulnerable to sybil attacks.
>
> Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components:
> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.
> B. A signed message like that is valid only while that UTXO has not been spent.
> C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent. 
>
> This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent. 
>
> Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual). 

This does not quite work, as lightning channel balances can be changed at any time.
I might agree that you have 90% of the channel and I have 10% of the channel right now, but if you then send a request to forward your funds out, I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.
This begins to add complexity.

More pointedly, if the signaling is done onchain, then a forward on the LN requires that I put up invalidations of previous signals, also onchain, otherwise you could cheaty cheat your effective balance by moving your funds around.
But the point of LN is to avoid putting typical everyday forwards onchain.

> This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing. 

This issue is particularly relevant to vault constructions.
Typically a vault has a "cold" key that is the master owner of the fund, with "hot" keys having partial access.
Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.

So, we should consider a vote from the "cold" key only.
However, the point is that the "cold" key wants to be kept offline as much as possible for security.

I suppose the "cold" key could be put online just once to create the signal message, but vault owners might not want to vote because of the risk, and their weight might be enough to be important in your voting scheme (consider that the point of vaults is to protect large funds).


A sub-issue here with the spend/signal pubkey idea is that if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

Good Evening ZmnSCPxj,

>  I need to be able to invalidate the previous signal, one that is tied to
the fulfillment of the forwarding request.

You're right that there's some nuance there. You could add a block hash
into the poll message and define things so any subsequent poll message sent
with a newer block hash overrides the old poll message at the block with
that hash and later blocks. That way if a channel balance changes
significantly, a new poll message can be sent out.

Or you could remove the ability to specify fractional support/opposition
and exclude multiparty UTXOs from participation. I tend to like the idea of
the possibility of full participation tho, even in a world that mainly uses
lightning.

> if the signaling is done onchain

I don't think any of this signaling needs to be done on-chain. Anyone who
wants to keep a count of the poll can simply collect together all these
poll messages and count up the weighted preferences. Yes, it would be
possible for one person to send out many conflicting poll messages, but
this could be handled without any commitment to the blockchain. A simple
thing to do would be to simply invalidate poll messages that conflict (ie
include them both in your list of counted messages, but ignore them in your
weighted-sums of poll preferences). As long as these polls are simply used
to inform action rather than to trigger action, it should be ok that
someone can produce biased incomplete counts, since anyone can show a
provably more complete set (a superset) of poll messages. Also, since this
would generally be a time-bound thing, where this poll information would
for example be used to gauge support for a soft fork, there isn't much of a
need to keep the poll messages on an immutable ledger. Old poll data is
inherently not very practically useful compared to recent poll data. So we
can kind of side step things like history attacks by simply ignoring polls
that aren't recent.

> Semantically, we would consider the "cold" key to be the "true" owner of
the fund, with "hot" key being delegates who are semi-trusted, but not as
trusted as the "cold" key.

I'm not sure I agree with those semantics as a hard rule. I don't consider
a "key" to be an owner of anything. A person owns a key, which gives them
access to funds. A key is a tool, and the owner of a key or wallet vault
can define whatever semantics they want. If they want to designate a hot
key as their poll-signing key, that's their prerogative. If they want to
require a cold-key as their message-signing key or even require multisig
signing, that's up to them as well. You could even mirror wallet-vault
constructs by overriding a poll message signed with fewer key using one
signed with more keys. The trade offs you bring up are reasonable
considerations, and I think which trade offs to choose may vary by the
individual in question and their individual situation. However, I think the
time-bound and non-binding nature of a poll makes the risks here pretty
small for most situations you would want to use this in (eg in a soft-fork
poll). It should be reasonable to consider any signed poll message valid,
regardless of possibilities of theft or key renting shinanigans. Nacho keys
nacho coins would of course be important in this scenario.

>  if I need to be able to somehow indicate that a long-term-cold-storage
UTXO has a signaling pubkey, I imagine this mechanism of indioating might
itself require a softfork, so you have a chicken-and-egg problem...

If such a thing did need a soft fork, the chicken and egg question would be
easy to answer: the soft fork comes first. We've done soft forks before
having this mechanism, and if necessary we could do another one to enable
it.

However, I think taproot can enable this mechanism without a soft fork. It
should be possible to include a taproot leaf that has the data necessary to
validate a signaling signature. The tapleaf would contain an invalid script
that has an alternative interpretation, where your poll message can include
the merkle path to tapleaf (the invalid-script), and the data at that leaf
would be a public key you can then verify the signaling signature against.

@vjudeu

> It should not be expressed in percents, but in amounts

Agreed. You make a good case for that.

> it could be just some kind of transaction, where you have utxo_id just as
transaction input, amount of coins as some output, and then add your
message as "OP_RETURN <commitment>" in your input, in this way your
signature would be useless in a different context than voting.

I don't quite understand this part. I don't understand how this would make
your signature useless in a different context. Could you elaborate?

> it does not really matter if you store that commitments on-chain to
preserve signalling results in consensus rules or if there would be some
separate chain for storing commitments and nothing else

I don't think any kind of chain is necessary to store this data. I'm
primarily suggesting this as a method to help the debate about a soft fork
have better information about what broader users think about a particular
soft fork proposal, so such data would simply inform whether or not we
decide to continue work on an upgrade. I don't think you'd want to require
any validation of this data by all full nodes, because the data could be
hundreds of gigabytes in size (let's say 1 billion people respond). You'd
have to run some kind of random sampling (more like actual proof of stake)
to get this data down to a manageable size.

> It would be Proof of Stake, where users would put their coins at stake to
vote.

Sure, as long as by this you mean simply proof of coin ownership. Just as
any bitcoin transaction involves proof of coin ownership.

I was pretty careful to avoid the word "voting", since I'm not proposing
that this be used with definite thresholds that trigger action, but more of
an information gathering mechanism. Perhaps one day it could be used for
something akin to voting, but certainly if we were going to implement this
to help decide on the next soft fork, it would very likely be a quite
biased set of responders. We would want to take that into account when
deciding how to interpret the data. Even with biased data tho, it could be
a useful tool for resolving some contention.

But on that note, I was thinking that it might be interesting to have an
optional human readable message into these poll messages. Those messages
could be then read through to gain a better understanding of why people are
supporting and why people are rejecting a particular thing. It could inform
how we might change how we explain a technical change to make it easier for
less technical folks (who don't post on twitter) to understand. It could
potentially give insight into an otherwise quiet majority (or large
minority).

> it sounds similar to "Merged Signing"

Interesting. I'm not sure I fully grok his idea, but I think he was
suggesting that a proof of stake consensus protocol pay attention to
bitcoin transactions formatted in a particular way. I think I've hopefully
clarified above why the idea I'm suggesting is rather different from this
(eg in that no special commitments need to be made).

Cheers,
BT







On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning Billy,
>
> > @Jorge
> > > Any user polling system is going to be vulnerable to sybil attacks.
> >
> > Not the one I'll propose right here. What I propose specifically is
> a coin-weighted signature-based poll with the following components:
> > A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
> support:10%}> for each UTXO they want to respond to the poll with.
> > B. A signed message like that is valid only while that UTXO has not been
> spent.
> > C. Poll results are considered only at each particular block height,
> where the support and opposition responses are weighted by the UTXO amount
> (and the support/oppose fraction in the message). This means you'd
> basically see a rolling poll through the blockchain as new signed poll
> messages come in and as their UTXOs are spent.
> >
> > This is not vulnerable to sybil attacks because it requires access to
> UTXOs and response-weight is directly tied to UTXO amount. If someone signs
> a poll message with a key that can unlock (or is in some other designated
> way associated with) a UTXO, and then spends that UTXO, their poll response
> stops being counted for all block heights after the UTXO was spent.
> >
> > Why put support and oppose fractions in the message? Who would want to
> both support and oppose something? Any multiple participant UTXO would. Eg
> lightning channels would, where each participant disagrees with the other.
> They need to sign together, so they can have an agreement to sign for the
> fractions that match their respective channel balances (using a force
> channel close as a last resort against an uncooperative partner as usual).
>
> This does not quite work, as lightning channel balances can be changed at
> any time.
> I might agree that you have 90% of the channel and I have 10% of the
> channel right now, but if you then send a request to forward your funds
> out, I need to be able to invalidate the previous signal, one that is tied
> to the fulfillment of the forwarding request.
> This begins to add complexity.
>
> More pointedly, if the signaling is done onchain, then a forward on the LN
> requires that I put up invalidations of previous signals, also onchain,
> otherwise you could cheaty cheat your effective balance by moving your
> funds around.
> But the point of LN is to avoid putting typical everyday forwards onchain.
>
> > This does have the potential issue of public key exposure prior to
> spending for current addresses. But that could be fixed with a new address
> type that has two public keys / spend paths: one for spending and one for
> signing.
>
> This issue is particularly relevant to vault constructions.
> Typically a vault has a "cold" key that is the master owner of the fund,
> with "hot" keys having partial access.
> Semantically, we would consider the "cold" key to be the "true" owner of
> the fund, with "hot" key being delegates who are semi-trusted, but not as
> trusted as the "cold" key.
>
> So, we should consider a vote from the "cold" key only.
> However, the point is that the "cold" key wants to be kept offline as much
> as possible for security.
>
> I suppose the "cold" key could be put online just once to create the
> signal message, but vault owners might not want to vote because of the
> risk, and their weight might be enough to be important in your voting
> scheme (consider that the point of vaults is to protect large funds).
>
>
> A sub-issue here with the spend/signal pubkey idea is that if I need to be
> able to somehow indicate that a long-term-cold-storage UTXO has a signaling
> pubkey, I imagine this mechanism of indioating might itself require a
> softfork, so you have a chicken-and-egg problem...
>
> Regards,
> ZmnSCPxj
>

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

Re: [bitcoin-dev] Speedy Trial

[vjudeu]

> I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?

It is simple. If you vote by making transactions, then someone could capture that and broadcast to nodes. If your signature is "useless in a different context", then you can only send that to your network. If it will be sent anywhere else, it will be invalid, so also useless. Another reason to sign transactions and not just some custom data is to make it compatible with "signet way of making signatures", the same as used in signet challenge.

> I don't think any kind of chain is necessary to store this data.

Even if it is not needed, it is kind of "free" if you take transaction size into account. Because each person moving coins on-chain could attach "OP_RETURN <commitment>" in TapScript, just to save commitments. Then, even if someone is not in your network from the very beginning, that person could still collect commitments and find out how they are connected with on-chain transactions.

> Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders.

If it will be ever implemented, it should be done in a similar way as difficulty: if you want 90%, you should calculate, what amount in satoshis is needed to reach that 90%, and update it every two weeks, based on all votes. In this way, you reduce floating-point operations to a bare minimum, and have a system, where you can compare uint64 amounts to quickly get "yes/no" answer to the question, if something should be triggered (also, you can compress it to 32 bits in the same way as 256-bit target is compressed).

> But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages.

As I said, "OP_RETURN <commitment>" inside TapScript is enough to produce all commitments of arbitrary size for "free", so that on-chain transaction size is constant, no matter how large that commitment is. And about storage: you could create a separate chain for that, you could store that in the same way as LN nodes store data, you could use something else, it doesn't really matter, because on-chain commitments could be constructed in the same way (also, as long as the transaction creator keeps those commitments as a secret, there is no way to get them; that means you can add them later if needed and easily pretend that "it was always possible").


On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Good Evening ZmnSCPxj,


>  I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.


You're right that there's some nuance there. You could add a block hash into the poll message and define things so any subsequent poll message sent with a newer block hash overrides the old poll message at the block with that hash and later blocks. That way if a channel balance changes significantly, a new poll message can be sent out. 


Or you could remove the ability to specify fractional support/opposition and exclude multiparty UTXOs from participation. I tend to like the idea of the possibility of full participation tho, even in a world that mainly uses lightning.


> if the signaling is done onchain


I don't think any of this signaling needs to be done on-chain. Anyone who wants to keep a count of the poll can simply collect together all these poll messages and count up the weighted preferences. Yes, it would be possible for one person to send out many conflicting poll messages, but this could be handled without any commitment to the blockchain. A simple thing to do would be to simply invalidate poll messages that conflict (ie include them both in your list of counted messages, but ignore them in your weighted-sums of poll preferences). As long as these polls are simply used to inform action rather than to trigger action, it should be ok that someone can produce biased incomplete counts, since anyone can show a provably more complete set (a superset) of poll messages. Also, since this would generally be a time-bound thing, where this poll information would for example be used to gauge support for a soft fork, there isn't much of a need to keep the poll messages on an immutable ledger. Old poll data is inherently not very practically useful compared to recent poll data. So we can kind of side step things like history attacks by simply ignoring polls that aren't recent.


> Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.


I'm not sure I agree with those semantics as a hard rule. I don't consider a "key" to be an owner of anything. A person owns a key, which gives them access to funds. A key is a tool, and the owner of a key or wallet vault can define whatever semantics they want. If they want to designate a hot key as their poll-signing key, that's their prerogative. If they want to require a cold-key as their message-signing key or even require multisig signing, that's up to them as well. You could even mirror wallet-vault constructs by overriding a poll message signed with fewer key using one signed with more keys. The trade offs you bring up are reasonable considerations, and I think which trade offs to choose may vary by the individual in question and their individual situation. However, I think the time-bound and non-binding nature of a poll makes the risks here pretty small for most situations you would want to use this in (eg in a soft-fork poll). It should be reasonable to consider any signed poll message valid, regardless of possibilities of theft or key renting shinanigans. Nacho keys nacho coins would of course be important in this scenario. 


>  if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...


If such a thing did need a soft fork, the chicken and egg question would be easy to answer: the soft fork comes first. We've done soft forks before having this mechanism, and if necessary we could do another one to enable it.


However, I think taproot can enable this mechanism without a soft fork. It should be possible to include a taproot leaf that has the data necessary to validate a signaling signature. The tapleaf would contain an invalid script that has an alternative interpretation, where your poll message can include the merkle path to tapleaf (the invalid-script), and the data at that leaf would be a public key you can then verify the signaling signature against. 


@vjudeu

> It should not be expressed in percents, but in amounts


Agreed. You make a good case for that.


> it could be just some kind of transaction, where you have utxo_id just as transaction input, amount of coins as some output, and then add your message as "OP_RETURN <commitment>" in your input, in this way your signature would be useless in a different context than voting.
 
I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?
 
> it does not really matter if you store that commitments on-chain to preserve signalling results in consensus rules or if there would be some separate chain for storing commitments and nothing else
 
I don't think any kind of chain is necessary to store this data. I'm primarily suggesting this as a method to help the debate about a soft fork have better information about what broader users think about a particular soft fork proposal, so such data would simply inform whether or not we decide to continue work on an upgrade. I don't think you'd want to require any validation of this data by all full nodes, because the data could be hundreds of gigabytes in size (let's say 1 billion people respond). You'd have to run some kind of random sampling (more like actual proof of stake) to get this data down to a manageable size. 


> It would be Proof of Stake, where users would put their coins at stake to vote.


Sure, as long as by this you mean simply proof of coin ownership. Just as any bitcoin transaction involves proof of coin ownership.


I was pretty careful to avoid the word "voting", since I'm not proposing that this be used with definite thresholds that trigger action, but more of an information gathering mechanism. Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders. We would want to take that into account when deciding how to interpret the data. Even with biased data tho, it could be a useful tool for resolving some contention. 


But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages. Those messages could be then read through to gain a better understanding of why people are supporting and why people are rejecting a particular thing. It could inform how we might change how we explain a technical change to make it easier for less technical folks (who don't post on twitter) to understand. It could potentially give insight into an otherwise quiet majority (or large minority).


> it sounds similar to "Merged Signing" 


Interesting. I'm not sure I fully grok his idea, but I think he was suggesting that a proof of stake consensus protocol pay attention to bitcoin transactions formatted in a particular way. I think I've hopefully clarified above why the idea I'm suggesting is rather different from this (eg in that no special commitments need to be made).


Cheers,
BT














On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Billy,

> @Jorge
> > Any user polling system is going to be vulnerable to sybil attacks.
>
> Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components:
> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.
> B. A signed message like that is valid only while that UTXO has not been spent.
> C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent. 
>
> This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent. 
>
> Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual). 

This does not quite work, as lightning channel balances can be changed at any time.
I might agree that you have 90% of the channel and I have 10% of the channel right now, but if you then send a request to forward your funds out, I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.
This begins to add complexity.

More pointedly, if the signaling is done onchain, then a forward on the LN requires that I put up invalidations of previous signals, also onchain, otherwise you could cheaty cheat your effective balance by moving your funds around.
But the point of LN is to avoid putting typical everyday forwards onchain.

> This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing. 

This issue is particularly relevant to vault constructions.
Typically a vault has a "cold" key that is the master owner of the fund, with "hot" keys having partial access.
Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.

So, we should consider a vote from the "cold" key only.
However, the point is that the "cold" key wants to be kept offline as much as possible for security.

I suppose the "cold" key could be put online just once to create the signal message, but vault owners might not want to vote because of the risk, and their weight might be enough to be important in your voting scheme (consider that the point of vaults is to protect large funds).


A sub-issue here with the spend/signal pubkey idea is that if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

>  If you vote by making transactions, then someone could capture that and
broadcast to nodes
>  you can only send that to your network

What do you mean "capture that" and "your network"? I was imagining a
scenario where these poll messages are always broadcast globally. Are you
implying more of a private poll?

> If it will be sent anywhere else, it will be invalid

I still don't understand. Why would a signed transaction be invalid
anywhere? Wouldn't a signed transaction be valid everywhere?

> Another reason to sign transactions and not just some custom data is to
make it compatible with "signet way of making signatures", the same as used
in signet challenge.

Perhaps I don't understand how signet works well enough to understand this,
but I would think that signing an message would work with signet just as
well as mainnet. I get the feeling perhaps we're misunderstanding each
other in some fundamental way.

> Even if it is not needed, it is kind of "free" if you take transaction
size into account

But it would require an on-chain transaction. We don't want 6 billion
people to have to send an on-chain transaction all in the same week in
order to register their preference on something.

On Mon, Mar 21, 2022 at 10:56 AM <vjudeu@gazeta.pl> wrote:

> > I don't quite understand this part. I don't understand how this would
> make your signature useless in a different context. Could you elaborate?
>
> It is simple. If you vote by making transactions, then someone could
> capture that and broadcast to nodes. If your signature is "useless in a
> different context", then you can only send that to your network. If it will
> be sent anywhere else, it will be invalid, so also useless. Another reason
> to sign transactions and not just some custom data is to make it compatible
> with "signet way of making signatures", the same as used in signet
> challenge.
>
> > I don't think any kind of chain is necessary to store this data.
>
> Even if it is not needed, it is kind of "free" if you take transaction
> size into account. Because each person moving coins on-chain could attach
> "OP_RETURN <commitment>" in TapScript, just to save commitments. Then, even
> if someone is not in your network from the very beginning, that person
> could still collect commitments and find out how they are connected with
> on-chain transactions.
>
> > Perhaps one day it could be used for something akin to voting, but
> certainly if we were going to implement this to help decide on the next
> soft fork, it would very likely be a quite biased set of responders.
>
> If it will be ever implemented, it should be done in a similar way as
> difficulty: if you want 90%, you should calculate, what amount in satoshis
> is needed to reach that 90%, and update it every two weeks, based on all
> votes. In this way, you reduce floating-point operations to a bare minimum,
> and have a system, where you can compare uint64 amounts to quickly get
> "yes/no" answer to the question, if something should be triggered (also,
> you can compress it to 32 bits in the same way as 256-bit target is
> compressed).
>
> > But on that note, I was thinking that it might be interesting to have an
> optional human readable message into these poll messages.
>
> As I said, "OP_RETURN <commitment>" inside TapScript is enough to produce
> all commitments of arbitrary size for "free", so that on-chain transaction
> size is constant, no matter how large that commitment is. And about
> storage: you could create a separate chain for that, you could store that
> in the same way as LN nodes store data, you could use something else, it
> doesn't really matter, because on-chain commitments could be constructed in
> the same way (also, as long as the transaction creator keeps those
> commitments as a secret, there is no way to get them; that means you can
> add them later if needed and easily pretend that "it was always possible").
>
>
> On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> Good Evening ZmnSCPxj,
>
>
> >  I need to be able to invalidate the previous signal, one that is tied
> to the fulfillment of the forwarding request.
>
>
> You're right that there's some nuance there. You could add a block hash
> into the poll message and define things so any subsequent poll message sent
> with a newer block hash overrides the old poll message at the block with
> that hash and later blocks. That way if a channel balance changes
> significantly, a new poll message can be sent out.
>
>
> Or you could remove the ability to specify fractional support/opposition
> and exclude multiparty UTXOs from participation. I tend to like the idea of
> the possibility of full participation tho, even in a world that mainly uses
> lightning.
>
>
> > if the signaling is done onchain
>
>
> I don't think any of this signaling needs to be done on-chain. Anyone who
> wants to keep a count of the poll can simply collect together all these
> poll messages and count up the weighted preferences. Yes, it would be
> possible for one person to send out many conflicting poll messages, but
> this could be handled without any commitment to the blockchain. A simple
> thing to do would be to simply invalidate poll messages that conflict (ie
> include them both in your list of counted messages, but ignore them in your
> weighted-sums of poll preferences). As long as these polls are simply used
> to inform action rather than to trigger action, it should be ok that
> someone can produce biased incomplete counts, since anyone can show a
> provably more complete set (a superset) of poll messages. Also, since this
> would generally be a time-bound thing, where this poll information would
> for example be used to gauge support for a soft fork, there isn't much of a
> need to keep the poll messages on an immutable ledger. Old poll data is
> inherently not very practically useful compared to recent poll data. So we
> can kind of side step things like history attacks by simply ignoring polls
> that aren't recent.
>
>
> > Semantically, we would consider the "cold" key to be the "true" owner of
> the fund, with "hot" key being delegates who are semi-trusted, but not as
> trusted as the "cold" key.
>
>
> I'm not sure I agree with those semantics as a hard rule. I don't consider
> a "key" to be an owner of anything. A person owns a key, which gives them
> access to funds. A key is a tool, and the owner of a key or wallet vault
> can define whatever semantics they want. If they want to designate a hot
> key as their poll-signing key, that's their prerogative. If they want to
> require a cold-key as their message-signing key or even require multisig
> signing, that's up to them as well. You could even mirror wallet-vault
> constructs by overriding a poll message signed with fewer key using one
> signed with more keys. The trade offs you bring up are reasonable
> considerations, and I think which trade offs to choose may vary by the
> individual in question and their individual situation. However, I think the
> time-bound and non-binding nature of a poll makes the risks here pretty
> small for most situations you would want to use this in (eg in a soft-fork
> poll). It should be reasonable to consider any signed poll message valid,
> regardless of possibilities of theft or key renting shinanigans. Nacho keys
> nacho coins would of course be important in this scenario.
>
>
> >  if I need to be able to somehow indicate that a long-term-cold-storage
> UTXO has a signaling pubkey, I imagine this mechanism of indioating might
> itself require a softfork, so you have a chicken-and-egg problem...
>
>
> If such a thing did need a soft fork, the chicken and egg question would
> be easy to answer: the soft fork comes first. We've done soft forks before
> having this mechanism, and if necessary we could do another one to enable
> it.
>
>
> However, I think taproot can enable this mechanism without a soft fork. It
> should be possible to include a taproot leaf that has the data necessary to
> validate a signaling signature. The tapleaf would contain an invalid script
> that has an alternative interpretation, where your poll message can include
> the merkle path to tapleaf (the invalid-script), and the data at that leaf
> would be a public key you can then verify the signaling signature against.
>
>
> @vjudeu
>
> > It should not be expressed in percents, but in amounts
>
>
> Agreed. You make a good case for that.
>
>
> > it could be just some kind of transaction, where you have utxo_id just
> as transaction input, amount of coins as some output, and then add your
> message as "OP_RETURN <commitment>" in your input, in this way your
> signature would be useless in a different context than voting.
>
> I don't quite understand this part. I don't understand how this would make
> your signature useless in a different context. Could you elaborate?
>
> > it does not really matter if you store that commitments on-chain to
> preserve signalling results in consensus rules or if there would be some
> separate chain for storing commitments and nothing else
>
> I don't think any kind of chain is necessary to store this data. I'm
> primarily suggesting this as a method to help the debate about a soft fork
> have better information about what broader users think about a particular
> soft fork proposal, so such data would simply inform whether or not we
> decide to continue work on an upgrade. I don't think you'd want to require
> any validation of this data by all full nodes, because the data could be
> hundreds of gigabytes in size (let's say 1 billion people respond). You'd
> have to run some kind of random sampling (more like actual proof of stake)
> to get this data down to a manageable size.
>
>
> > It would be Proof of Stake, where users would put their coins at stake
> to vote.
>
>
> Sure, as long as by this you mean simply proof of coin ownership. Just as
> any bitcoin transaction involves proof of coin ownership.
>
>
> I was pretty careful to avoid the word "voting", since I'm not proposing
> that this be used with definite thresholds that trigger action, but more of
> an information gathering mechanism. Perhaps one day it could be used for
> something akin to voting, but certainly if we were going to implement this
> to help decide on the next soft fork, it would very likely be a quite
> biased set of responders. We would want to take that into account when
> deciding how to interpret the data. Even with biased data tho, it could be
> a useful tool for resolving some contention.
>
>
> But on that note, I was thinking that it might be interesting to have an
> optional human readable message into these poll messages. Those messages
> could be then read through to gain a better understanding of why people are
> supporting and why people are rejecting a particular thing. It could inform
> how we might change how we explain a technical change to make it easier for
> less technical folks (who don't post on twitter) to understand. It could
> potentially give insight into an otherwise quiet majority (or large
> minority).
>
>
> > it sounds similar to "Merged Signing"
>
>
> Interesting. I'm not sure I fully grok his idea, but I think he was
> suggesting that a proof of stake consensus protocol pay attention to
> bitcoin transactions formatted in a particular way. I think I've hopefully
> clarified above why the idea I'm suggesting is rather different from this
> (eg in that no special commitments need to be made).
>
>
> Cheers,
> BT
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning Billy,
>
> > @Jorge
> > > Any user polling system is going to be vulnerable to sybil attacks.
> >
> > Not the one I'll propose right here. What I propose specifically is
> a coin-weighted signature-based poll with the following components:
> > A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90%
> support:10%}> for each UTXO they want to respond to the poll with.
> > B. A signed message like that is valid only while that UTXO has not been
> spent.
> > C. Poll results are considered only at each particular block height,
> where the support and opposition responses are weighted by the UTXO amount
> (and the support/oppose fraction in the message). This means you'd
> basically see a rolling poll through the blockchain as new signed poll
> messages come in and as their UTXOs are spent.
> >
> > This is not vulnerable to sybil attacks because it requires access to
> UTXOs and response-weight is directly tied to UTXO amount. If someone signs
> a poll message with a key that can unlock (or is in some other designated
> way associated with) a UTXO, and then spends that UTXO, their poll response
> stops being counted for all block heights after the UTXO was spent.
> >
> > Why put support and oppose fractions in the message? Who would want to
> both support and oppose something? Any multiple participant UTXO would. Eg
> lightning channels would, where each participant disagrees with the other.
> They need to sign together, so they can have an agreement to sign for the
> fractions that match their respective channel balances (using a force
> channel close as a last resort against an uncooperative partner as usual).
>
> This does not quite work, as lightning channel balances can be changed at
> any time.
> I might agree that you have 90% of the channel and I have 10% of the
> channel right now, but if you then send a request to forward your funds
> out, I need to be able to invalidate the previous signal, one that is tied
> to the fulfillment of the forwarding request.
> This begins to add complexity.
>
> More pointedly, if the signaling is done onchain, then a forward on the LN
> requires that I put up invalidations of previous signals, also onchain,
> otherwise you could cheaty cheat your effective balance by moving your
> funds around.
> But the point of LN is to avoid putting typical everyday forwards onchain.
>
> > This does have the potential issue of public key exposure prior to
> spending for current addresses. But that could be fixed with a new address
> type that has two public keys / spend paths: one for spending and one for
> signing.
>
> This issue is particularly relevant to vault constructions.
> Typically a vault has a "cold" key that is the master owner of the fund,
> with "hot" keys having partial access.
> Semantically, we would consider the "cold" key to be the "true" owner of
> the fund, with "hot" key being delegates who are semi-trusted, but not as
> trusted as the "cold" key.
>
> So, we should consider a vote from the "cold" key only.
> However, the point is that the "cold" key wants to be kept offline as much
> as possible for security.
>
> I suppose the "cold" key could be put online just once to create the
> signal message, but vault owners might not want to vote because of the
> risk, and their weight might be enough to be important in your voting
> scheme (consider that the point of vaults is to protect large funds).
>
>
> A sub-issue here with the spend/signal pubkey idea is that if I need to be
> able to somehow indicate that a long-term-cold-storage UTXO has a signaling
> pubkey, I imagine this mechanism of indioating might itself require a
> softfork, so you have a chicken-and-egg problem...
>
> Regards,
> ZmnSCPxj
>

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

Re: [bitcoin-dev] Speedy Trial

[Eric Voskuil]

> > Even if it is not needed, it is kind of "free" if you take transaction size into account
> 
> But it would require an on-chain transaction. We don't want 6 billion people to have to send an on-chain transaction all in the same week in order to register their preference on something.

I haven’t followed this thread, so apologies if I’m missing some context, but confirmed tx signaling remains miner signaling.

Regardless, miners are the only actors who can create soft fork compatibility, so theirs is the only relevant signal. Otherwise people can just fork themselves at any time using any voting mechanism they want.

e

Re: [bitcoin-dev] Speedy Trial

[vjudeu]

> What do you mean "capture that" and "your network"? I was imagining a scenario where these poll messages are always broadcast globally. Are you implying more of a private poll?

If you vote by making a Bitcoin transaction, then someone could move real bitcoins, just by including your transaction into a block. I thought you only want to get some feedback, in this case you only need to sign things, not to move real coins. So, there will be one network for moving bitcoins and one network for signalling/voting/whatever. If you combine both of them to be the same network, then you end up in a situation, where moving coins is needed to signal anything (that may quickly fill mempools and increase on-chain fees).

Also, as you earlier proposed custom data format for signing, I thought you want to create a separate network.

> I still don't understand. Why would a signed transaction be invalid anywhere? Wouldn't a signed transaction be valid everywhere?

It depends what is signed and how it is signed. A transaction moving "1 BTC -> 1.5 BTC" with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY cannot be included directly into a block, but can be turned into a valid transaction, just by attaching more inputs. A signed "Bitcoin Message" can be used to prove ownership, but cannot be included into a block as a valid transaction. So, if you want to move coins and vote, you can just sign a transaction (or even just observe your mempool and receive new blocks, then you can use existing transactions and pretend they are all signalling for or against something). But if you want to only move coins or to only vote, then you need to carefully choose data for signing, just to do one thing and not the other.

> Perhaps I don't understand how signet works well enough to understand this, but I would think that signing an message would work with signet just as well as mainnet. I get the feeling perhaps we're misunderstanding each other in some fundamental way.

In signet, whole transactions are signed. There are separate BIP's that describe signing in a different way than famous "Bitcoin Message". Because if you sign just some message, extending such format is complicated. But if you sign a transaction, then you can sign P2SH address, P2WSH address, Taproot address, and potentially even not-yet-implemented-future-soft-fork-address.

> But it would require an on-chain transaction. We don't want 6 billion people to have to send an on-chain transaction all in the same week in order to register their preference on something.

It would require an on-chain transaction every sometimes, not every vote. If someone is going to do some on-chain transaction, then that person could attach some commitment for the whole network. So, instead of just doing regular transaction, people could attach commitments at the same cost, with the same on-chain transaction size. The only needed change is just tweaking their own keys and informing your network about pushed commitment.


On 2022-03-22 16:19:49 user Billy Tetrud <billy.tetrud@gmail.com> wrote:
>  If you vote by making transactions, then someone could capture that and broadcast to nodes
>  you can only send that to your network



What do you mean "capture that" and "your network"? I was imagining a scenario where these poll messages are always broadcast globally. Are you implying more of a private poll?


> If it will be sent anywhere else, it will be invalid


I still don't understand. Why would a signed transaction be invalid anywhere? Wouldn't a signed transaction be valid everywhere? 


> Another reason to sign transactions and not just some custom data is to make it compatible with "signet way of making signatures", the same as used in signet challenge.


Perhaps I don't understand how signet works well enough to understand this, but I would think that signing an message would work with signet just as well as mainnet. I get the feeling perhaps we're misunderstanding each other in some fundamental way.


> Even if it is not needed, it is kind of "free" if you take transaction size into account


But it would require an on-chain transaction. We don't want 6 billion people to have to send an on-chain transaction all in the same week in order to register their preference on something. 


On Mon, Mar 21, 2022 at 10:56 AM <vjudeu@gazeta.pl> wrote:

> I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?

It is simple. If you vote by making transactions, then someone could capture that and broadcast to nodes. If your signature is "useless in a different context", then you can only send that to your network. If it will be sent anywhere else, it will be invalid, so also useless. Another reason to sign transactions and not just some custom data is to make it compatible with "signet way of making signatures", the same as used in signet challenge.

> I don't think any kind of chain is necessary to store this data.

Even if it is not needed, it is kind of "free" if you take transaction size into account. Because each person moving coins on-chain could attach "OP_RETURN <commitment>" in TapScript, just to save commitments. Then, even if someone is not in your network from the very beginning, that person could still collect commitments and find out how they are connected with on-chain transactions.

> Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders.

If it will be ever implemented, it should be done in a similar way as difficulty: if you want 90%, you should calculate, what amount in satoshis is needed to reach that 90%, and update it every two weeks, based on all votes. In this way, you reduce floating-point operations to a bare minimum, and have a system, where you can compare uint64 amounts to quickly get "yes/no" answer to the question, if something should be triggered (also, you can compress it to 32 bits in the same way as 256-bit target is compressed).

> But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages.

As I said, "OP_RETURN <commitment>" inside TapScript is enough to produce all commitments of arbitrary size for "free", so that on-chain transaction size is constant, no matter how large that commitment is. And about storage: you could create a separate chain for that, you could store that in the same way as LN nodes store data, you could use something else, it doesn't really matter, because on-chain commitments could be constructed in the same way (also, as long as the transaction creator keeps those commitments as a secret, there is no way to get them; that means you can add them later if needed and easily pretend that "it was always possible").


On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Good Evening ZmnSCPxj,


>  I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.


You're right that there's some nuance there. You could add a block hash into the poll message and define things so any subsequent poll message sent with a newer block hash overrides the old poll message at the block with that hash and later blocks. That way if a channel balance changes significantly, a new poll message can be sent out. 


Or you could remove the ability to specify fractional support/opposition and exclude multiparty UTXOs from participation. I tend to like the idea of the possibility of full participation tho, even in a world that mainly uses lightning.


> if the signaling is done onchain


I don't think any of this signaling needs to be done on-chain. Anyone who wants to keep a count of the poll can simply collect together all these poll messages and count up the weighted preferences. Yes, it would be possible for one person to send out many conflicting poll messages, but this could be handled without any commitment to the blockchain. A simple thing to do would be to simply invalidate poll messages that conflict (ie include them both in your list of counted messages, but ignore them in your weighted-sums of poll preferences). As long as these polls are simply used to inform action rather than to trigger action, it should be ok that someone can produce biased incomplete counts, since anyone can show a provably more complete set (a superset) of poll messages. Also, since this would generally be a time-bound thing, where this poll information would for example be used to gauge support for a soft fork, there isn't much of a need to keep the poll messages on an immutable ledger. Old poll data is inherently not very practically useful compared to recent poll data. So we can kind of side step things like history attacks by simply ignoring polls that aren't recent.


> Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.


I'm not sure I agree with those semantics as a hard rule. I don't consider a "key" to be an owner of anything. A person owns a key, which gives them access to funds. A key is a tool, and the owner of a key or wallet vault can define whatever semantics they want. If they want to designate a hot key as their poll-signing key, that's their prerogative. If they want to require a cold-key as their message-signing key or even require multisig signing, that's up to them as well. You could even mirror wallet-vault constructs by overriding a poll message signed with fewer key using one signed with more keys. The trade offs you bring up are reasonable considerations, and I think which trade offs to choose may vary by the individual in question and their individual situation. However, I think the time-bound and non-binding nature of a poll makes the risks here pretty small for most situations you would want to use this in (eg in a soft-fork poll). It should be reasonable to consider any signed poll message valid, regardless of possibilities of theft or key renting shinanigans. Nacho keys nacho coins would of course be important in this scenario. 


>  if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...


If such a thing did need a soft fork, the chicken and egg question would be easy to answer: the soft fork comes first. We've done soft forks before having this mechanism, and if necessary we could do another one to enable it.


However, I think taproot can enable this mechanism without a soft fork. It should be possible to include a taproot leaf that has the data necessary to validate a signaling signature. The tapleaf would contain an invalid script that has an alternative interpretation, where your poll message can include the merkle path to tapleaf (the invalid-script), and the data at that leaf would be a public key you can then verify the signaling signature against. 


@vjudeu

> It should not be expressed in percents, but in amounts


Agreed. You make a good case for that.


> it could be just some kind of transaction, where you have utxo_id just as transaction input, amount of coins as some output, and then add your message as "OP_RETURN <commitment>" in your input, in this way your signature would be useless in a different context than voting.
 
I don't quite understand this part. I don't understand how this would make your signature useless in a different context. Could you elaborate?
 
> it does not really matter if you store that commitments on-chain to preserve signalling results in consensus rules or if there would be some separate chain for storing commitments and nothing else
 
I don't think any kind of chain is necessary to store this data. I'm primarily suggesting this as a method to help the debate about a soft fork have better information about what broader users think about a particular soft fork proposal, so such data would simply inform whether or not we decide to continue work on an upgrade. I don't think you'd want to require any validation of this data by all full nodes, because the data could be hundreds of gigabytes in size (let's say 1 billion people respond). You'd have to run some kind of random sampling (more like actual proof of stake) to get this data down to a manageable size. 


> It would be Proof of Stake, where users would put their coins at stake to vote.


Sure, as long as by this you mean simply proof of coin ownership. Just as any bitcoin transaction involves proof of coin ownership.


I was pretty careful to avoid the word "voting", since I'm not proposing that this be used with definite thresholds that trigger action, but more of an information gathering mechanism. Perhaps one day it could be used for something akin to voting, but certainly if we were going to implement this to help decide on the next soft fork, it would very likely be a quite biased set of responders. We would want to take that into account when deciding how to interpret the data. Even with biased data tho, it could be a useful tool for resolving some contention. 


But on that note, I was thinking that it might be interesting to have an optional human readable message into these poll messages. Those messages could be then read through to gain a better understanding of why people are supporting and why people are rejecting a particular thing. It could inform how we might change how we explain a technical change to make it easier for less technical folks (who don't post on twitter) to understand. It could potentially give insight into an otherwise quiet majority (or large minority).


> it sounds similar to "Merged Signing" 


Interesting. I'm not sure I fully grok his idea, but I think he was suggesting that a proof of stake consensus protocol pay attention to bitcoin transactions formatted in a particular way. I think I've hopefully clarified above why the idea I'm suggesting is rather different from this (eg in that no special commitments need to be made).


Cheers,
BT














On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Billy,

> @Jorge
> > Any user polling system is going to be vulnerable to sybil attacks.
>
> Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components:
> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.
> B. A signed message like that is valid only while that UTXO has not been spent.
> C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent. 
>
> This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent. 
>
> Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual). 

This does not quite work, as lightning channel balances can be changed at any time.
I might agree that you have 90% of the channel and I have 10% of the channel right now, but if you then send a request to forward your funds out, I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request.
This begins to add complexity.

More pointedly, if the signaling is done onchain, then a forward on the LN requires that I put up invalidations of previous signals, also onchain, otherwise you could cheaty cheat your effective balance by moving your funds around.
But the point of LN is to avoid putting typical everyday forwards onchain.

> This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing. 

This issue is particularly relevant to vault constructions.
Typically a vault has a "cold" key that is the master owner of the fund, with "hot" keys having partial access.
Semantically, we would consider the "cold" key to be the "true" owner of the fund, with "hot" key being delegates who are semi-trusted, but not as trusted as the "cold" key.

So, we should consider a vote from the "cold" key only.
However, the point is that the "cold" key wants to be kept offline as much as possible for security.

I suppose the "cold" key could be put online just once to create the signal message, but vault owners might not want to vote because of the risk, and their weight might be enough to be important in your voting scheme (consider that the point of vaults is to protect large funds).


A sub-issue here with the spend/signal pubkey idea is that if I need to be able to somehow indicate that a long-term-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of indioating might itself require a softfork, so you have a chicken-and-egg problem...

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Speedy Trial

[vjudeu]

> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.

It should not be expressed in percents, but in amounts. It would be easier and more compatible with votes where there is 100% oppose or 100% support (and also easier to handle if some LN user would move one satoshi, because rounding percents would be tricky). Anyway, you need to convert percents to amounts, so better use amounts from the very beginning. Also, it could be just some kind of transaction, where you have utxo_id just as transaction input, amount of coins as some output, and then add your message as "OP_RETURN <commitment>" in your input, in this way your signature would be useless in a different context than voting.

Also note that such voting would be some kind of Proof of Stake. And it does not really matter if you store that commitments on-chain to preserve signalling results in consensus rules or if there would be some separate chain for storing commitments and nothing else. It would be Proof of Stake, where users would put their coins at stake to vote. Also, you probably solved "nothing at stake" problem in a nice way, because it would be protected by Proof of Work chain to decide who can vote. So, voters could only freeze their coins for getting some voting power or move their coins and lose their votes.

For me, it sounds similar to "Merged Signing" proposed by stwenhao here: https://bitcointalk.org/index.php?topic=5390027.0. I think it is kind of dangerous and unstoppable (so nobody could stop you if you would ignore any criticism and implement that). Fortunately, it is also possible to add some Proof of Work if any staking-like system would be present in Bitcoin, just OP_SUBSTR would do the trick (if enabled; if not, we could still use OP_HASH256 and force the target by some kind of soft-fork on top of your voting system).


On 2022-03-17 20:58:35 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.


Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% support:10%}> for each UTXO they want to respond to the poll with.
B. A signed message like that is valid only while that UTXO has not been spent.
C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent. 


This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent. 


Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual). 


This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing. 



> In perfect competition the mining power costs per chain tends to equal the rewards offered by that chain, both in subsidy and transaction fees.


Agreed, but it takes time for an economic shock to reach its new equilibrium. That period of time, which might be rather precarious, should be considered in a plan to preserve a minority fork. 


> Would you rather that proposal be deployed with speedy trial activation or with BIP8+LOT=true activation?


For a proposal I don't want to succeed, I absolutely would prefer speedy trial over BIP8+LOT=true. Speedy trial at 90% signaling threshold can quickly determine that the proposal (hopefully) does not have enough consensus among miners. By contrast, BIP8+LOT=true could polarize the debate, worsening the community's ability to communicate and talk through issues. It would also basically guarantee that a fork happens, which in the best case (in my hypothetical point of view where I don't like the proposal) would mean some small minority forks off the network, which reduces the main chain's value somewhat (at least temporarily). Worst case a small majority forces the issue at near 50% which would cause all sorts of blockchain issues and would have a high probability of leading to a hardfork by the minority. 


All this sounds rather more tenable with speedy trial. Any proposal has less chance of causing an actual fork (soft or otherwise) with speedy trial vs LOT=true. LOT=true guarantees a fork if even a single person is running it. LOT=true could certainly come in handy to initiate a UASF, but IMO that's better left as a plan B or C. 


> segwit... all the consequences of the change are not opt in.


I definitely agree there. The consequences of a soft fork are not always opt in. That's basically what my example of a "dumb majority soft fork" is, and sounds like what your "evil fork" basically is. 


On Thu, Mar 17, 2022 at 7:19 AM Jorge Timón via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón <jtimon@jtimon.cc> wrote:
> A mechanism of soft-forking against activation exists.  What more do you want? Are we supposed to write the code on behalf of this hypothetical group of users who may or may not exist for them just so that they can have a node that remains stalled on Speedy Trial lockin?  That simply isn't reasonable, but if you think it is, I invite you to create such a fork.

I want BIP+LOT=true to be used. I want speedy trial not to be used.
Luke wrote the code to resist BIP8+LOT=true, and if he didn't, I could
write it myself, yes.
If you think that's not reasonable code to ever run, I don't think
you're really getting the "softfork THAT YOU OPPOSE" part of the
hypothetical right. Let me try to help with an example, although I
hope we don't get derailed in the implementation details of the
hypothetical evil proposal.

Suppose someone proposes a weight size limit increase by a extension
block softfork.
Or instead of that, just imagine the final version of the covenants
proposal has a backdoor in it or something.


Would you rather that proposal be deployed with speedy trial
activation or with BIP8+LOT=true activation?

>>
>> Please, try to imagine an example for an activation that you wouldn't like yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrade my node, which was option 2. I don't know why you dismissed it.

Not upgrading your node doesn't prevent the softfork from being
activated in your chain.
A softfork may affect you indirectly even if you don't use the new
features yourself directly.
You may chose to stay in the old chain even if you don't consider
you're "in the economic majority" at that moment.

> Not much can prevent a miner cartel from enforcing rules that users don't want other than hard forking a replacement POW.  There is no effective difference between some developers releasing a malicious soft-fork of Bitcoin and the miners releasing a malicious version themselves.  And when the miner cartel forms, they aren't necessarily going to be polite enough to give a transparent signal of their new rules.  However, without the economic majority enforcing their set of rules, the cartel continuously risks falling apart from the temptation of transaction fees of the censored transactions.

It is true that a mining cartel doesn't need to use speedy trial or
BIP8+LOT=true to apply rule changes they want just because we do.
But they would do if they wanted to maintain the appearance of benevolence.

> On the other hand, If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin.  Look, you cannot have the perfect system of money all by your lonesome self.  Money doesn't have economic value if no one else wants to trade you for it.  Just ask that poor user who YOLO'd his own taproot activation in advance all by themselves.  I'm sure they think they've got just the perfect money system, with taproot early and everything.  But now their node is stuck at block 692261 and hasn't made progress since.  No doubt they are hunkered down for the long term, absolutely committed to their fork and just waiting for the rest of the world to come around to how much better their version of Bitcoin is than the rest of us.

Well, you could also have the option to stay in the old chain with the
economic minority, it doesn't have to be you alone.
We agree that one person alone can't use a currency.

> Even though you've dismissed it, one of the considerations of taproot was that it is opt-in for users to use the functionality.  Future soft-forks ought to have the same considerations to the extent possible.

Well, the same could be said about segwit. And yet all the
consequences of the change are not opt in.
For example, segwit contained a block size limit increase.
Sure, you can just not validate the witnesses, but then you're no
longer a full node.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> >  Thirdly, if some users insist on a chain where taproot is
> > "not activated", they can always softk-fork in their own rule that
> > disallows the version bits that complete the Speedy Trial activation
> > sequence, or alternatively soft-fork in a rule to make spending from (or
> > to) taproot addresses illegal.
> Since it's about activation in general and not about taproot specifically,
> your third point is the one that applies.
> Users could have coordinated to have "activation x" never activated in
> their chains if they simply make a rule that activating a given proposal
> (with bip8) is forbidden in their chain.
> But coordination requires time.

People opposed to having taproot transactions in their chain had over
three years to do that coordination before an activation method was merged
[0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].

[0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
    trial activation parameters for mainnet and testnet were merged.
[1] 2021-11-14

For comparison, the UASF activation attempt for segwit took between 4
to 6 months to coordinate, assuming you start counting from either the
"user activated soft fork" concept being raised on bitcoin-dev or the
final params for BIP 148 being merged into the bips repo, and stop
counting when segwit locked in.

> Please, try to imagine an example for an activation that you wouldn't like
> yourself. Imagine it gets proposed and you, as a user, want to resist it.

Sure. There's more steps than just "fork off onto a minority chain"
though.

 1) The first and most important step is to explain why you want to
    resist it, either to convince the proposers that there really is
    a problem and they should stand down, or so someone can come up
    with a way of fixing the proposal so you don't need to resist it.
    Ideally, that's all that's needed to resolve the objections. (That's
    what didn't happen with opposition to segwit)

 2) If that somehow doesn't work, and people are pushing ahead with a
    consensus change despite significant reasonable opposition; the next
    thing to do would be to establish if either side is a paper tiger
    and setup a futures market. That has the extra benefit of giving
    miners some information about which (combination of) rules will be
    most profitable to mine for.

    Once that's setup and price discovery happens, one side or the other
    will probably throw in the towel -- there's not much point have a
    money that other people aren't interested in using. (And that more
    or less is what happened with 2X)

    If a futures market like that is going to be setup, I think it's
    best if it happens before signalling for the soft fork starts --
    the information miners will get from it is useful for figuring out
    how much resources to invest in signalling, eg. I think it might even
    be feasible to set something up even before activation parameters are
    finalised; you need something more than just one-on-one twitter bets
    to get meaningful price discovery, but I think you could probably
    build something based on a reasonably unbiassed oracle declaring an
    outcome, without precisely defined parameters fixed in a BIP.

    So if acting like reasonable people and talking it through doesn't
    work, this seems like the next step to me.

 3) But maybe you try both those and they fail and people start trying
    to activate the soft fork (or perhaps you just weren't paying
    attention until it was too late, and missed the opportunity).

    I think the speedy trial approach here is ideal for a last ditch
    "everyone stays on the same chain while avoiding this horrible change"
    attempt. The reason being that it allows everyone to agree to not
    adopt the new rules with only very little cost: all you need is for
    10% of hashpower to not signal over a three month period.

    That's cheaper than bip9 (5% over 12 months requires 2x the
    cumulative hashpower), and much cheaper than bip8 which requires
    users to update their software

 4) At this point, if you were able to prevent activation, hopefully
    that's enough of a power move that people will take your concerns
    seriously, and you get a second chance at step (1). If that still
    results in an impasse, I'd expect there to be a second, non-speedy
    activation of the soft fork, that either cannot be blocked at all, or
    cannot be blocked without having control of at least 60% of hashpower.

 5) If you weren't able to prevent activation (whether or not you
    prevented speedy trial from working), then you should have a lot
    of information:

      - you weren't able to convince people there was a problem

      - you either weren't in the economic majority and people don't
        think your concept of bitcoin is more valuable (perhaps they
	don't even think it's valuable enough to setup a futures market
	for you)

      - you can't get control of even 10% of hashpower for a few months

    and your only option is to accept defeat or create a new chain.

    Since your new chain won't have a hashpower majority, you'll likely
    have significant problems if you don't hard fork in a change to
    how proof-of-work works; my guess is you'd either want to switch
    to a different proof-of-work algorithm, or make your chain able
    to be merge-mined against bitcoin, though just following BCH/BSV's
    example and tweaking the difficulty adjustment to be more dynamic
    could work too.

    (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
    BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
    merge-mining, are apparently at 68%, 42% and 17% respectively)

    At the point that you're doing a hard fork, making a clean split is
    straightforward: schedule the hard fork for around the same time as
    the start of enforcement of the soft fork you oppose, work out how
    to make sure you're on your own p2p network, and figure out how
    exchanges and lightning channels and everything else are going to
    cope with the coin split.

 6) There's potentially also the case where a soft fork locks-in
    and later everyone realises the people who were opposing it were
    right all along and the fork is a really bad idea.

    If everyone agreed that some idea was irredeemably bad -- eg,
    OP_VERIF -- then we could soft fork them out and just forbid
    blocks/transactions that attempt to use them. Or conceivably we could
    do a hardfork and have more options about how to fix the problem.

    That's already true for various features that satoshi included and
    that are still available today -- eg the CHECKMULTISIG bug where
    it pops one too many things from the stack, or the timewarp bug,
    or CODESEP/FindAndDelete validation complexity.

    Those can be complicated to fix though; if people have lost their
    private keys and are sitting on (timelocked?) pre-signed transactions,
    even fixing the problem via a hard fork could cause loss of funds.

But those are really progressively worse options -- just talking to each
other and solving the problem before it's a problem is a better approach
than risking money on futures markets; and that's better than having to
buy hashpower to try to block something that other people want; and that's
better than forking the chain; and even that's better than doing things
that might cause irretrievable loss of funds from random other bitcoiners.

Cheers,
aj

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj@erisian.com.au> wrote:
>
> On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> People opposed to having taproot transactions in their chain had over
> three years to do that coordination before an activation method was merged
> [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
>
> [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
>     trial activation parameters for mainnet and testnet were merged.
> [1] 2021-11-14

People may be opposed only to the final version, but not the initial
one or the fundamental concept.
Please, try to think of worse case scenarios.
Perhaps there's no opposition until after activation code has been
released and miners are already starting to signal.
Perhaps at that moment a reviewer comes and points out a fatal flaw.

> For comparison, the UASF activation attempt for segwit took between 4
> to 6 months to coordinate, assuming you start counting from either the
> "user activated soft fork" concept being raised on bitcoin-dev or the
> final params for BIP 148 being merged into the bips repo, and stop
> counting when segwit locked in.

That was extremely risky and could have been a disaster. It went well,
but in my opinion a BIP8 approach from the beginning would have been
much less risky. Instead of improvising these things we should plan
ahead. But for "user forced" activations and for "user forced"
rejections.
Just remember you may reject your own code.

> > Please, try to imagine an example for an activation that you wouldn't like
> > yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
> Sure. There's more steps than just "fork off onto a minority chain"
> though.
>
>  1) The first and most important step is to explain why you want to
>     resist it, either to convince the proposers that there really is
>     a problem and they should stand down, or so someone can come up
>     with a way of fixing the proposal so you don't need to resist it.
>     Ideally, that's all that's needed to resolve the objections. (That's
>     what didn't happen with opposition to segwit)

Agreed, for any given proposal, the first approach should be rational
discussion.
Some times we consider other arguments irrational simply because we
don't understand them though.

>  2) If that somehow doesn't work, and people are pushing ahead with a
>     consensus change despite significant reasonable opposition; the next
>     thing to do would be to establish if either side is a paper tiger
>     and setup a futures market. That has the extra benefit of giving
>     miners some information about which (combination of) rules will be
>     most profitable to mine for.
>
>     Once that's setup and price discovery happens, one side or the other
>     will probably throw in the towel -- there's not much point have a
>     money that other people aren't interested in using. (And that more
>     or less is what happened with 2X)

Future markets can be manipulated.
Regarding 2x, that's not how I remember it. If I remember correctly,
"discovered" a price in btc for bcash that was
orders of magnitude higher than what it is today.

>     If a futures market like that is going to be setup, I think it's
>     best if it happens before signalling for the soft fork starts --
>     the information miners will get from it is useful for figuring out
>     how much resources to invest in signalling, eg. I think it might even
>     be feasible to set something up even before activation parameters are
>     finalised; you need something more than just one-on-one twitter bets
>     to get meaningful price discovery, but I think you could probably
>     build something based on a reasonably unbiassed oracle declaring an
>     outcome, without precisely defined parameters fixed in a BIP.

Whatever miners signal, until there are two chains and their real
rewards can be traded, it's hard to know what they will mine
afterwards.
They could signal a change with 100% and then after it is activated on
one chain and resisted on another, they 95% of them may switch to the
old chain simply because its rewards are 20 times more valuable. This
may happen 3 days after activation or 3 months, or more.
It could depend on how fast some relevant information about the new
change spreads.
Which is specially hard to estimate in a censored world like ours.

>     So if acting like reasonable people and talking it through doesn't
>     work, this seems like the next step to me.

Not to me, but you're free to create your future markets or trade in them.
I wouldn't do any of them, and I would advice against it.

>  3) But maybe you try both those and they fail and people start trying
>     to activate the soft fork (or perhaps you just weren't paying
>     attention until it was too late, and missed the opportunity).

Yes, some changes may be rejected late because some people weren't
paying attention or weren't paid attention, indeed.
Or perhaps it's your own proposal and you realize it is flawed
yourself. There are infinite hypothetical scenarios we could consider
for this to happen.

>     I think the speedy trial approach here is ideal for a last ditch
>     "everyone stays on the same chain while avoiding this horrible change"
>     attempt. The reason being that it allows everyone to agree to not
>     adopt the new rules with only very little cost: all you need is for
>     10% of hashpower to not signal over a three month period.

No, 10% of hashpower is not "very little cost", that's very expensive.

>     That's cheaper than bip9 (5% over 12 months requires 2x the
>     cumulative hashpower), and much cheaper than bip8 which requires
>     users to update their software

Updating software is not expensive. the code for bip8 could have been
merged long before taproot was even initially proposed.
It could be merged now before another proposal.
Updating software is certainly not more expensive than getting 10% of
the hashrate.

>  4) At this point, if you were able to prevent activation, hopefully
>     that's enough of a power move that people will take your concerns
>     seriously, and you get a second chance at step (1). If that still
>     results in an impasse, I'd expect there to be a second, non-speedy
>     activation of the soft fork, that either cannot be blocked at all, or
>     cannot be blocked without having control of at least 60% of hashpower.

And if you never got 10% hashpower, we move to the next step, I guess.

>  5) If you weren't able to prevent activation (whether or not you
>     prevented speedy trial from working), then you should have a lot
>     of information:
>
>       - you weren't able to convince people there was a problem
>
>       - you either weren't in the economic majority and people don't
>         think your concept of bitcoin is more valuable (perhaps they
>         don't even think it's valuable enough to setup a futures market
>         for you)
>
>       - you can't get control of even 10% of hashpower for a few months
>
>     and your only option is to accept defeat or create a new chain.

What if it's still the other people who are lacking information?
It wouldn't be a new chain, it would be the old chain without the new
evil change, until you manage to show the other people that the change
was indeed evil.
Remember, in this example, the new change being evil is not a
possibility, but an assumption.
What you're arguing is "if you haven't been able to stop the evil
change, then perhaps it wasn't evil all along and the people trying to
resist it were wrong and don't know it".
But that contradicts the premise: an evil change being deployed using
speedy trial.

>     Since your new chain won't have a hashpower majority, you'll likely
>     have significant problems if you don't hard fork in a change to
>     how proof-of-work works; my guess is you'd either want to switch
>     to a different proof-of-work algorithm, or make your chain able
>     to be merge-mined against bitcoin, though just following BCH/BSV's
>     example and tweaking the difficulty adjustment to be more dynamic
>     could work too.

No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.
A better difficulty update filter and merge mining could help you, I
guess. But that could be a threat on its own.
Also, as pointed out earlier, "mining majority" is dynamic and depends
on the rewards.

>     (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
>     BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
>     merge-mining, are apparently at 68%, 42% and 17% respectively)

Google tells me 0.0073BTC.
In perfect competition and leaving fees aside (in which probably
bitcoin wins too), BCH should have approximately 0.0073% the hashrate
bitcoin hash. This tells me someone who likes BCH is throwing money
away to subsidize its security.
Or perhaps it's something else I'm not taking into account or your
estimate is wrong.
But BCH having 0.8% of bitcoin's hashrate sounds like too much to me.
And yet, what did your future markers "discovered" pre hard fork?

>     At the point that you're doing a hard fork, making a clean split is
>     straightforward: schedule the hard fork for around the same time as
>     the start of enforcement of the soft fork you oppose, work out how
>     to make sure you're on your own p2p network, and figure out how
>     exchanges and lightning channels and everything else are going to
>     cope with the coin split.

You shouldn't need to do a hardfork to resist a consensus change you don't like.
"around the same time", with bip8 and the resistance mechanism
proposed by luke, it doesn't need to be "around the same time
according to some expert who will tell you what to put in your
software", but "exactly at the same time, and you only need to know
which pproposal version bit you're opposing".

>  6) There's potentially also the case where a soft fork locks-in
>     and later everyone realises the people who were opposing it were
>     right all along and the fork is a really bad idea.
>
>     If everyone agreed that some idea was irredeemably bad -- eg,
>     OP_VERIF -- then we could soft fork them out and just forbid
>     blocks/transactions that attempt to use them. Or conceivably we could
>     do a hardfork and have more options about how to fix the problem.

Yeah, great example. It doesn't have to be an "evil change" as such,
it can just be a "deeply wrong change" or something.
Or if we were using BIP8 and had the resistance mechanism proposed by
luke, all we would need to do is change one line and recompile:
I don't remember his enumeration constants but, something like...

- bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
+ bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;

Say we discover it 3 days before forced activation.
Well, that would still be much less rushed that the berkeleyDB thing,
wouldn't it?
As you point out, after activation it is much more painful to fix
things. In some cases a hardfork may be the best solution a
posteriori, but I guess that gets out of the scope for activation
mechanisms.
If there's only opposition after it is deployed, whatever the
activation mechanism, in that particular case, would be irrelevant.
Whatever evil change it was, we would have probably swallowed whatever
the activation mechanism, because we only thought it evil or wrong a
posteriori.

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj@erisian.com.au> wrote:
> > On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> > People opposed to having taproot transactions in their chain had over
> > three years to do that coordination before an activation method was merged
> > [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
> >
> > [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> >     trial activation parameters for mainnet and testnet were merged.
> > [1] 2021-11-14
> People may be opposed only to the final version, but not the initial
> one or the fundamental concept.
> Please, try to think of worse case scenarios.

I mean, I've already spent a lot of time thinking through these worst
cast scenarios, including the ones you bring up. Maybe I've come up with
wrong or suboptimal conclusions about it, and I'm happy to discuss that,
but it's a bit hard to avoid taking offense at the suggestion that I
haven't even thought about it.

In the case of taproot, the final substantive update to the BIP was PR#982
merged on 2020-08-27 -- so even if you'd only been opposed to the changes
in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to
raise those concerns before the code implementing taproot was merged,
and 6 months to raise those concerns before activation parameters were
set. If you'd been following the discussion outside of the code and BIP
text, in the case of 32B pubkeys, you'd have had an additional 15 months
from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you
only follow optech's summaries) until it was included in the BIP.

> Perhaps there's no opposition until after activation code has been
> released and miners are already starting to signal.
> Perhaps at that moment a reviewer comes and points out a fatal flaw.

Perhaps there's no opposition until the change has been deployed and in
wide use for 30 years. Aborting activation isn't the be-all and end-all
of addressing problems with a proposal, and it's not going to be able to
deal with every problem. For any problems that can be found before the
change is deployed and in use, you want to find them while the proposal
is being discussed.



More broadly, what I don't think you're getting is that *any* method you
can use to abort/veto/revert an activation that's occuring via BIP8 (with
or without mandatory activation), can also be used to abort/veto/revert
a speedy trial activation.

Speedy trial simply changes two things: it allows a minority (~10%)
of hashpower to abort the activation; and it guarantees a "yes" or "no"
answer within three months, while with BIP343 you initially don't know
when within a ~1 year period activation will occur.

If you're part of an (apparent) minority trying to abort/veto/reject
activation, this gives you an additional option: if you can get support
from ~10% of hashpower, you can force an initial "no" answer within
three months, at which point many of the people who were ignoring your
arguments up until then may be willing to reconsider them.

For example, I think Mark Friedenbach's concerns about unhashed pubkeys
and quantum resistance don't make sense, and (therefore) aren't widely
held; but if 10% of blocks during taproot's speedy trial had included a
tagline indicating otherwise and prevented activation, that would have
been pretty clear objective evidence that the concern was more widely
held than I thought, and might be worth reconsidering. Likewise, there
could have somehow been other problems that somehow were being ignored,
that could have similarly been reprioritised in the same way.

That's not the way that you *want* things to work -- ideally people
should be raising the concerns beforehand, and they should be taken
seriously and fixed or addressed beforehand. That did happen with Mark's
concerns -- heck, I raised it as a question ~6 hours after Greg's original
taproot proposal -- and it's directly addressed in the rationale section
of BIP341.

But in the worst case; maybe that doesn't happen. Maybe bitcoin-dev and
other places are somehow being censored, or sensible critics are being
demonised and ignored. The advantage of a hashrate veto here is that it's
hard to fake and hard to censor -- whereas with mailing list messages and
the like, it's both easy to fake (setup sockpuppets and pay troll farms)
and easy to censor (ban/moderate people for spamming say). So as a last
ditch "we've been censored, please take us seriously" method of protest,
it seems worthwhile to have to me.

(Of course, a 90% majority might *still* choose to not take the concerns
of the 10% minority seriously, and just continue to ignore the concern
and followup with an immediate mandatory activation. But if that's what
happening, you can't stop it; you can't only choose whether you want to
be a part of it, or leave)

Another example: if we'd had a 3-month speedy trial for segwit, that would
presumably have run from 2016-11-15 to 2017-02-15, and been successfully
blocked by people objecting to segwit activation. That would have left a
clean slate for either a simple and safe BIP149 style UASF activation of
segwit (shaolinfry introduced the concept of "user activated softfork
activation" in a post on 2017-02-25), or redesigning segwit to be
compatible with covert ASICBoost (which Greg Maxwell revealed publicly
on 2017-04-05, after apparently realising the potential interaction
with segwit a month earlier) and retrying segwit activation with that
approach via a new speedy trial later in the year.

> > For comparison, the UASF activation attempt for segwit took between 4
> > to 6 months to coordinate, assuming you start counting from either the
> > "user activated soft fork" concept being raised on bitcoin-dev or the
> > final params for BIP 148 being merged into the bips repo, and stop
> > counting when segwit locked in.
> That was extremely risky and could have been a disaster. 

The question that comment was addressing wasn't whether BIP148 was a
good idea, it was how quickly users can coordinate a software update to
respond to consensus rules heading in a direction they find unacceptable.

All the risk and potential for disaster was due to the goals of BIP148:
to get segwit locked in prior to its activation timeout in Nov 2017,
even if only supported by a minority of hashrate.

> >  2) If that somehow doesn't work, and people are pushing ahead with a
> >     consensus change despite significant reasonable opposition; the next
> >     thing to do would be to establish if either side is a paper tiger
> >     and setup a futures market. That has the extra benefit of giving
> >     miners some information about which (combination of) rules will be
> >     most profitable to mine for.
> >
> >     Once that's setup and price discovery happens, one side or the other
> >     will probably throw in the towel -- there's not much point have a
> >     money that other people aren't interested in using. (And that more
> >     or less is what happened with 2X)
> Future markets can be manipulated.

Futures markets measure people's beliefs weighted by wealth and
confidence; and unlike with hashrate signalling there's a real cost to
lying/being wrong. They're certainly not perfect, but nothing is.

> Regarding 2x, that's not how I remember it. If I remember correctly,
> "discovered" a price in btc for bcash that was
> orders of magnitude higher than what it is today.

2x and BCH were two different things.

For BCH, the only futures market was run by viabtc (one of the main
advocates of BCH), was only available a week before the split, and was
(I think?) only available to Chinese investors (at least, it was only
traded against CNY). Nevertheless, the price stabilised at around
$300USD equivalent (0.1 BTC) prior to the split, and that was fairly
in line with the spot price after the split had occurred. That price
dropped during the next two weeks to ~0.07 BTC, then rose to ~0.2 BTC,
and has since dropped to ~0.008 BTC. Coincidentally that's about $300USD
in today's market, so if you're pricing things in USD, the futures market
was actually weirdly accurate.

Viabtc also launched a market for BIP148, though in addition to the
problems with its BCH market, it was pretty unusable in that if the
BIP148-valid chain was the most-work chain, the BIP148 token wouldn't
be redeemed.

But the 2x market I was thinking of was bitfinex's; afaik bitfinex is
reasonably unbiased, the market was fairly accessible and could be traded
against the USD, and it was open for a month before the question of 2x
was definitevely resolved. The discovered price was about 0.2 BTC up
until it was announced that 2x was being abandoned at which point it
dropped to something like 0.02 BTC, representing holding costs until
the market was finalised about 2 months later.

> >     If a futures market like that is going to be setup, I think it's
> >     best if it happens before signalling for the soft fork starts --
> >     the information miners will get from it is useful for figuring out
> >     how much resources to invest in signalling, eg. I think it might even
> >     be feasible to set something up even before activation parameters are
> >     finalised; you need something more than just one-on-one twitter bets
> >     to get meaningful price discovery, but I think you could probably
> >     build something based on a reasonably unbiassed oracle declaring an
> >     outcome, without precisely defined parameters fixed in a BIP.
> Whatever miners signal, until there are two chains and their real
> rewards can be traded, it's hard to know what they will mine
> afterwards.

I don't agree. The BCH futures market accurately predicted the rewards
(and hence hashrate) for mining BCH in the first couple of weeks after
the split.

On the same basis, the 2x futures market predicted that mining the 2x
chain would be massively unprofitable: immediately after the split,
both the 2x chain and the original-rules chain would have the same
difficulty and hence have the same expected cost to mine a block; but
the 2x chain would only have 25% of the reward (0.2 vs 0.8 valuation per
the futures market). Without someone subsidising the first 2016 blocks on
the 2x chain to the tune of about ~15,000 pre-split bitcoin (or ~75,000
post-split 2x coins; or between $80M-$150M USD), either directly, or by
mining at an economic loss, the 2x chain could only collapse.

BCH avoided that fate by having a new difficulty adjustment algorithm
that allowed the difficulty to drop immediately, rather than only on
the next 2016 block boundary.

> They could signal a change with 100% and then after it is activated on
> one chain and resisted on another, they 95% of them may switch to the
> old chain simply because its rewards are 20 times more valuable. This
> may happen 3 days after activation or 3 months, or more.

If it's an either-or choice, it's likely that 99.9% of hashrate will
switch even if the rewards are only 0.1 times more valuable (or 1.1
times as valuable if you prefer). That's why you run a futures market,
to figure out which will be more valuable and by how much.

We saw the either-or case happen with BCH vs BTC; the difficulty of BCH
would drop quickly due to the "EDA", but only rise slowly, making BCH
mining more profitable for an extended period so that opportunistic miners
would switch to BCH for a while until it got expensive again then switch
back to BTC, causing both chains' hashrate to be unstable. 

But if you don't hard fork to a different difficulty adjustment algorithm
the way BCH did on day one, then it doesn't matter how long miners
don't mine on your chain, your chain's difficulty won't adjust, and so
you'll need to instead wait until BTC's difficulty doubles or more,
or its reward halves or more, or some combination of the two. That's
likely much more than 3 months away. I can't imagine why anyone would
still care about your proposed chain months or years later.

So hardforking in merge-mining (so it's not an either-or question) or
a new difficulty adjustment algorithm (so you don't have to wait months
or years) seems a much more realistic approach.

> >     So if acting like reasonable people and talking it through doesn't
> >     work, this seems like the next step to me.
> Not to me, but you're free to create your future markets or trade in them.
> I wouldn't do any of them, and I would advice against it.

*shrug* Do what you like (and I mean, I don't trade in futures markets
either) but I think you'd be missing out on very useful information,
and losing a chance for people who aren't devs to offer tangible and
objective support for your cause.

> >     I think the speedy trial approach here is ideal for a last ditch
> >     "everyone stays on the same chain while avoiding this horrible change"
> >     attempt. The reason being that it allows everyone to agree to not
> >     adopt the new rules with only very little cost: all you need is for
> >     10% of hashpower to not signal over a three month period.
> No, 10% of hashpower is not "very little cost", that's very expensive.

If we're talking about consensus changes, the target is 100% of hashpower,
and also something approaching 100% of nodes. By comparison 10% of
hashpower is *much* cheaper, especially when the 100% have to actively
upgrade in order to support, while the 10% just have to not do anything
in order to oppose.

To be clear: You don't have to setup the 10% of hashpower yourself,
you just have to convince the existing owners of 10% of hashpower to
not actively support the change.

> >     That's cheaper than bip9 (5% over 12 months requires 2x the
> >     cumulative hashpower), and much cheaper than bip8 which requires
> >     users to update their software
> Updating software is not expensive. the code for bip8 could have been
> merged long before taproot was even initially proposed.
> It could be merged now before another proposal.

The BIP8 spec we have today is very different to the BIP8 spec when
taproot was merged, let alone before it was even proposed. As it was,
it had serious problems that hadn't been addressed, and the version we
have today likewise has significant problems that haven't been addressed,
which is why it wasn't and shouldn't be merged.

> Updating software is certainly not more expensive than getting 10% of
> the hashrate.

Updating software (or not updating software) is precisely *how* to get
10% of hashrate. It's not more or less expensive -- it *is* the expense.

> >  4) At this point, if you were able to prevent activation, hopefully
> >     that's enough of a power move that people will take your concerns
> >     seriously, and you get a second chance at step (1). If that still
> >     results in an impasse, I'd expect there to be a second, non-speedy
> >     activation of the soft fork, that either cannot be blocked at all, or
> >     cannot be blocked without having control of at least 60% of hashpower.
> And if you never got 10% hashpower, we move to the next step, I guess.

Yes; you then move to the next step knowing that what level of
interest/support you actually have.

> >  5) If you weren't able to prevent activation (whether or not you
> >     prevented speedy trial from working), then you should have a lot
> >     of information:
> >
> >       - you weren't able to convince people there was a problem
> >
> >       - you either weren't in the economic majority and people don't
> >         think your concept of bitcoin is more valuable (perhaps they
> >         don't even think it's valuable enough to setup a futures market
> >         for you)
> >
> >       - you can't get control of even 10% of hashpower for a few months
> >
> >     and your only option is to accept defeat or create a new chain.
> What if it's still the other people who are lacking information?

If it's other people that lack information, there's two options. One,
you might be able to explain things to them, so that they learn and gain
the information. The other is that for whatever reason they're not willing
to listen to the truth and will remain ignorant. If it's the first case,
you'd have succeeded in an earlier step. If it's the latter, then it's
not something you can change, and it doesn't really matter in how you
decide what to do next.

> It wouldn't be a new chain, it would be the old chain without the new
> evil change, until you manage to show the other people that the change
> was indeed evil.
> Remember, in this example, the new change being evil is not a
> possibility, but an assumption.

It's extremely unhelpful to call things "evil" if what you want is a
reasonable discussion. And if reasonable discussion isn't what you want,
you're in the wrong place.

At this point in the hypothetical you're in a small minority, and have
been unable to convince people of your point of view. Calling the people
you disagree with "evil" (and saying they support something that's evil
is exactly that) isn't going to improve your situation, and doing it in
a hypothetical sure feels like bad faith.

> What you're arguing is "if you haven't been able to stop the evil
> change, then perhaps it wasn't evil all along and the people trying to
> resist it were wrong and don't know it".

If it's an evil change, then good people will oppose it. You've tried
convincing devs in the "discuss the proposal" stage, whales in the
"futures market" stage, and miners in the "hashpower signalling" phase,
and failed each time because the good people in each of those groups
haven't opposed it. So yes, I think the most likely explanation is that
you're wrong in thinking it's evil.

But hey what about the worst case: what if everyone else in bitcoin
is evil and supports doing evil things. And maybe that's not even
implausible: maybe it's not an "evil" thing per se, perhaps it's simply
equally "misguided" as the things that central banks or wall street or
similar are doing today. Perhaps bitcoin becomes the world currency,
and in 100 or 200 years time, whether through complacency and forgetting
the lessons of the past, or too much adherence to dogma that no longer
matches reality, or just hitting some new problem that's never been seen
before and an inability to perfectly predict the future, and as a result
most of the world opts into some change that will cause bitcoin to fail.

In that scenario, I think a hard fork is the best choice: split out a new
coin that will survive the upcoming crash, adjust the mining/difficulty
algorithm so it works from day one, and set it up so that you can
maintain it along with the people who support your vision, rather than
having to constantly deal with well-meaning attacks from "bitcoiners"
who don't see the risks and have lost the plot.

Basically: do what Satoshi did and create a better system, and let
everyone else join you as the problems with the old one eventually become
unavoidably obvious.

> But that contradicts the premise: an evil change being deployed using
> speedy trial.

Again: any change that could be avoided if it were deployed via BIP8,
can also be avoided *by the exact same techniques* if it were deployed
via speedy trial or a similar approach.

> >     Since your new chain won't have a hashpower majority, you'll likely
> >     have significant problems if you don't hard fork in a change to
> >     how proof-of-work works; my guess is you'd either want to switch
> >     to a different proof-of-work algorithm, or make your chain able
> >     to be merge-mined against bitcoin, though just following BCH/BSV's
> >     example and tweaking the difficulty adjustment to be more dynamic
> >     could work too.
> No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.

The value of the subsidy is something you can directly figure out from
running a futures market; and unless you're deliberately subsidising fees,
they'll almost certainly be ~0.

> >     (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
> >     BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
> >     merge-mining, are apparently at 68%, 42% and 17% respectively)
> Google tells me 0.0073BTC.

I think you're reading too much precision into those numbers? When
I looked again the other day, I got a figure of 0.66%; today I get
0.75%. I'm sure I rounded whatever figure I saw to one significant figure,
so it might have been 0.75% then too.

https://bitinfocharts.com/comparison/bitcoin-hashrate.html#3y
https://bitinfocharts.com/comparison/bitcoin%20cash-hashrate.html#3y

> In perfect competition and leaving fees aside (in which probably
> bitcoin wins too), BCH should have approximately 0.0073% the hashrate
> bitcoin hash.

Oh, or you're just getting the percentage conversion wrong -- 0.0073
BTC is 0.73% of a BTC, and thus it would be expected to have about 0.73%
of the hashrate.

> >     At the point that you're doing a hard fork, making a clean split is
> >     straightforward: schedule the hard fork for around the same time as
> >     the start of enforcement of the soft fork you oppose, work out how
> >     to make sure you're on your own p2p network, and figure out how
> >     exchanges and lightning channels and everything else are going to
> >     cope with the coin split.
> You shouldn't need to do a hardfork to resist a consensus change you don't like.

Of course; that's why option (1) is to talk to people about why it's a
bad idea so it doesn't get proposed in the first place.

But if you want to resist a consensus change that is overwhelmingly
supported by the rest of the bitcoin economy, and for which your reasons
aren't even considered particularly logical by everyone else, then yeah,
if you really want to go off on your own because everyone else is wrong,
you *should* do a hardfork.

If a change doesn't have overwhelming support, then hopefully the costs
to get 90% of hashrate signalling is a significant impediment. If you do
have overwhelming support, then the cost to get 90% of hashrate signalling
(or even apparently 99.8%, see getdeploymentinfo on block 693503) --
doesn't seem to be too bad.

> "around the same time", with bip8 and the resistance mechanism
> proposed by luke, it doesn't need to be "around the same time
> according to some expert who will tell you what to put in your
> software", but "exactly at the same time, and you only need to know
> which pproposal version bit you're opposing".

(Arguing semantics: You can't do the split at exactly the same time,
because the split starts with each chain finding a new block, and blocks
are found probabilistically depending on hashrate, so they won't be found
at the same time. Or, alternatively, the split happens whenever either
client considers the other chain invalid, and always happens at the
"same" time)

If you want to do things at exactly the same height, you can do that if
the soft fork is activated by speedy trial as well.

I'd say the same height approach works better on speedy trial than
with BIP8/BIP343, since with speedy trial signalling is only for a
short period, and hence you know well in advance if and when you'll be
splitting, whereas with an extended signalling period that goes for a
year past the minimum activation height, you may find yourself splitting
at any point in that year with as little as two week's notice.

If I were doing a hardfork coin split to avoid following some new soft
forked rules that I think were horrible, I think I'd prefer to do the
split in advance of the softfork -- that way exchanges/wallets/lightning
channels/etc that have to do work to deal with the coinsplit aren't
distracted by simultaneously having to pay attention to the new softfork.
YMMV of course.

> Yeah, great example. It doesn't have to be an "evil change" as such,
> it can just be a "deeply wrong change" or something.
> Or if we were using BIP8 and had the resistance mechanism proposed by
> luke, all we would need to do is change one line and recompile:
> I don't remember his enumeration constants but, something like...
> - bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
> + bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;
> Say we discover it 3 days before forced activation.
> Well, that would still be much less rushed that the berkeleyDB thing,
> wouldn't it?

No, exactly the opposite.

In order to abort a BIP8 activation, 100% of hashpower and 100% of
node software needs to downgrade from anything that specifies BIP8 with
mandatory activation.

The "berkelyDB thing" was an accidental hard fork due to the updated
software with leveldb being able to accept larger blocks than the old
bdb-based bitcoind could. 

The result was two chains: one with a large block in it, that could
only be validated by the newer software, and a less work chain with only
smaller chains, that could be validated by both versions of the software;
the problem was ~60% of hashpower was on the larger-block chain, but
many nodes including those with ~40% hashpower. The problem was quickly
mitigated by encouraging a majority of hashpower to downgrade to the
old software, resulting in them rejecting the larger-block chain,
at which point a majority of hashpower was mining the smaller-block
chain, and the smaller-block chain eventually having more work than
the larger-block chain. At that point any newer nodes reorged to the
more-work, smaller-block chain, and everyone was following the same chain.

What that means is that the operators of *two* pools downgraded their
software, and everything was fixed. That's a *lot* less work than
everyone who upgraded their node having to downgrade/re-update, and
it was done that way to *avoid* having to rush to get everyone to do
an emergency update of their node software to be compatible with the
larger-block chain.

See https://bitcoin.org/en/alert/2013-03-11-chain-fork
and https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

On the other hand, that approach only works because it takes advantage
of a lot of hashrate being centralised around a few pools; if we succeed
in making block construction more decentralised, solutions here will
only become harder.

> If there's only opposition after it is deployed, whatever the
> activation mechanism, in that particular case, would be irrelevant.

Once you've released software with a softfork activated via BIP8 with
mandatory activation (ie, lot=true), and it has achieved any significant
adoption, the soft fork is already deployed and you need to treat it as
such. If you want to have an easier way of undoing the softfork than
you would have for one that's already active on the network, you need
a different activation method than BIP8/lot=true.

Cheers,
aj

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

Sorry, I won't answer to everything, because it's clear you're not listening.
In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
is a PREMISE of that hypothetical case, a GIVEN.
Your claim that "if it's evil, good people would oppose it" is a NON
SEQUITUR, "good people" aren't necessarily perfect and all knowing.
good people can make mistakes, they can be fooled too.
In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
don't complain, it is because they didn't realize that the given fork
was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
hypothetical case where there's a fork some people think it's evil but
it's not really evil.

Repeat with me: in the hypothetical case that there's an evil fork,
then the fork is evil by definition, that's the hypothetical case
we're discussing.

Once you understand what hypothetical case I'm talking about, maybe
you can understand the rest of my reasoning.
But if you don't understand the PREMISES of my example, it is
impossible that you can understand my reasonings about the
hypothetical example.

I'm sorry about the upper cases, but I really don't know how else I
could be clearer about the PREMISES being PREMISES and not just
possibilities. If you can't imagine a scenario where good people don't
oppose an evil fork, then you can't imagine the scenario I'm talking
about, sorry.

Evil fork deployed with speedy trial vs evil fork deployed with BIP8,
that's what I'm talking about.
Please, stop the "then it's not an evil fork" contradiction of the premises.

At this point, I don't think I can be clearer about the main premise
of my example, sorry.

On Wed, Mar 23, 2022 at 12:50 AM Anthony Towns <aj@erisian.com.au> wrote:
>
> On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote:
> > On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns <aj@erisian.com.au> wrote:
> > > On Fri, Mar 11, 2022 at 02:04:29PM +0000, Jorge Timón via bitcoin-dev wrote:
> > > People opposed to having taproot transactions in their chain had over
> > > three years to do that coordination before an activation method was merged
> > > [0], and then an additional seven months after the activation method was merged before taproot enforcement began [1].
> > >
> > > [0] 2018-01-23 was the original proposal, 2021-04-15 was when speedy
> > >     trial activation parameters for mainnet and testnet were merged.
> > > [1] 2021-11-14
> > People may be opposed only to the final version, but not the initial
> > one or the fundamental concept.
> > Please, try to think of worse case scenarios.
>
> I mean, I've already spent a lot of time thinking through these worst
> cast scenarios, including the ones you bring up. Maybe I've come up with
> wrong or suboptimal conclusions about it, and I'm happy to discuss that,
> but it's a bit hard to avoid taking offense at the suggestion that I
> haven't even thought about it.
>
> In the case of taproot, the final substantive update to the BIP was PR#982
> merged on 2020-08-27 -- so even if you'd only been opposed to the changes
> in the final version (32B pubkeys perhaps?) you'd have had 1.5 months to
> raise those concerns before the code implementing taproot was merged,
> and 6 months to raise those concerns before activation parameters were
> set. If you'd been following the discussion outside of the code and BIP
> text, in the case of 32B pubkeys, you'd have had an additional 15 months
> from the time the idea was proposed on 2019-05-22 (or 2019-05-29 if you
> only follow optech's summaries) until it was included in the BIP.
>
> > Perhaps there's no opposition until after activation code has been
> > released and miners are already starting to signal.
> > Perhaps at that moment a reviewer comes and points out a fatal flaw.
>
> Perhaps there's no opposition until the change has been deployed and in
> wide use for 30 years. Aborting activation isn't the be-all and end-all
> of addressing problems with a proposal, and it's not going to be able to
> deal with every problem. For any problems that can be found before the
> change is deployed and in use, you want to find them while the proposal
> is being discussed.
>
>
>
> More broadly, what I don't think you're getting is that *any* method you
> can use to abort/veto/revert an activation that's occuring via BIP8 (with
> or without mandatory activation), can also be used to abort/veto/revert
> a speedy trial activation.
>
> Speedy trial simply changes two things: it allows a minority (~10%)
> of hashpower to abort the activation; and it guarantees a "yes" or "no"
> answer within three months, while with BIP343 you initially don't know
> when within a ~1 year period activation will occur.
>
> If you're part of an (apparent) minority trying to abort/veto/reject
> activation, this gives you an additional option: if you can get support
> from ~10% of hashpower, you can force an initial "no" answer within
> three months, at which point many of the people who were ignoring your
> arguments up until then may be willing to reconsider them.
>
> For example, I think Mark Friedenbach's concerns about unhashed pubkeys
> and quantum resistance don't make sense, and (therefore) aren't widely
> held; but if 10% of blocks during taproot's speedy trial had included a
> tagline indicating otherwise and prevented activation, that would have
> been pretty clear objective evidence that the concern was more widely
> held than I thought, and might be worth reconsidering. Likewise, there
> could have somehow been other problems that somehow were being ignored,
> that could have similarly been reprioritised in the same way.
>
> That's not the way that you *want* things to work -- ideally people
> should be raising the concerns beforehand, and they should be taken
> seriously and fixed or addressed beforehand. That did happen with Mark's
> concerns -- heck, I raised it as a question ~6 hours after Greg's original
> taproot proposal -- and it's directly addressed in the rationale section
> of BIP341.
>
> But in the worst case; maybe that doesn't happen. Maybe bitcoin-dev and
> other places are somehow being censored, or sensible critics are being
> demonised and ignored. The advantage of a hashrate veto here is that it's
> hard to fake and hard to censor -- whereas with mailing list messages and
> the like, it's both easy to fake (setup sockpuppets and pay troll farms)
> and easy to censor (ban/moderate people for spamming say). So as a last
> ditch "we've been censored, please take us seriously" method of protest,
> it seems worthwhile to have to me.
>
> (Of course, a 90% majority might *still* choose to not take the concerns
> of the 10% minority seriously, and just continue to ignore the concern
> and followup with an immediate mandatory activation. But if that's what
> happening, you can't stop it; you can't only choose whether you want to
> be a part of it, or leave)
>
> Another example: if we'd had a 3-month speedy trial for segwit, that would
> presumably have run from 2016-11-15 to 2017-02-15, and been successfully
> blocked by people objecting to segwit activation. That would have left a
> clean slate for either a simple and safe BIP149 style UASF activation of
> segwit (shaolinfry introduced the concept of "user activated softfork
> activation" in a post on 2017-02-25), or redesigning segwit to be
> compatible with covert ASICBoost (which Greg Maxwell revealed publicly
> on 2017-04-05, after apparently realising the potential interaction
> with segwit a month earlier) and retrying segwit activation with that
> approach via a new speedy trial later in the year.
>
> > > For comparison, the UASF activation attempt for segwit took between 4
> > > to 6 months to coordinate, assuming you start counting from either the
> > > "user activated soft fork" concept being raised on bitcoin-dev or the
> > > final params for BIP 148 being merged into the bips repo, and stop
> > > counting when segwit locked in.
> > That was extremely risky and could have been a disaster.
>
> The question that comment was addressing wasn't whether BIP148 was a
> good idea, it was how quickly users can coordinate a software update to
> respond to consensus rules heading in a direction they find unacceptable.
>
> All the risk and potential for disaster was due to the goals of BIP148:
> to get segwit locked in prior to its activation timeout in Nov 2017,
> even if only supported by a minority of hashrate.
>
> > >  2) If that somehow doesn't work, and people are pushing ahead with a
> > >     consensus change despite significant reasonable opposition; the next
> > >     thing to do would be to establish if either side is a paper tiger
> > >     and setup a futures market. That has the extra benefit of giving
> > >     miners some information about which (combination of) rules will be
> > >     most profitable to mine for.
> > >
> > >     Once that's setup and price discovery happens, one side or the other
> > >     will probably throw in the towel -- there's not much point have a
> > >     money that other people aren't interested in using. (And that more
> > >     or less is what happened with 2X)
> > Future markets can be manipulated.
>
> Futures markets measure people's beliefs weighted by wealth and
> confidence; and unlike with hashrate signalling there's a real cost to
> lying/being wrong. They're certainly not perfect, but nothing is.
>
> > Regarding 2x, that's not how I remember it. If I remember correctly,
> > "discovered" a price in btc for bcash that was
> > orders of magnitude higher than what it is today.
>
> 2x and BCH were two different things.
>
> For BCH, the only futures market was run by viabtc (one of the main
> advocates of BCH), was only available a week before the split, and was
> (I think?) only available to Chinese investors (at least, it was only
> traded against CNY). Nevertheless, the price stabilised at around
> $300USD equivalent (0.1 BTC) prior to the split, and that was fairly
> in line with the spot price after the split had occurred. That price
> dropped during the next two weeks to ~0.07 BTC, then rose to ~0.2 BTC,
> and has since dropped to ~0.008 BTC. Coincidentally that's about $300USD
> in today's market, so if you're pricing things in USD, the futures market
> was actually weirdly accurate.
>
> Viabtc also launched a market for BIP148, though in addition to the
> problems with its BCH market, it was pretty unusable in that if the
> BIP148-valid chain was the most-work chain, the BIP148 token wouldn't
> be redeemed.
>
> But the 2x market I was thinking of was bitfinex's; afaik bitfinex is
> reasonably unbiased, the market was fairly accessible and could be traded
> against the USD, and it was open for a month before the question of 2x
> was definitevely resolved. The discovered price was about 0.2 BTC up
> until it was announced that 2x was being abandoned at which point it
> dropped to something like 0.02 BTC, representing holding costs until
> the market was finalised about 2 months later.
>
> > >     If a futures market like that is going to be setup, I think it's
> > >     best if it happens before signalling for the soft fork starts --
> > >     the information miners will get from it is useful for figuring out
> > >     how much resources to invest in signalling, eg. I think it might even
> > >     be feasible to set something up even before activation parameters are
> > >     finalised; you need something more than just one-on-one twitter bets
> > >     to get meaningful price discovery, but I think you could probably
> > >     build something based on a reasonably unbiassed oracle declaring an
> > >     outcome, without precisely defined parameters fixed in a BIP.
> > Whatever miners signal, until there are two chains and their real
> > rewards can be traded, it's hard to know what they will mine
> > afterwards.
>
> I don't agree. The BCH futures market accurately predicted the rewards
> (and hence hashrate) for mining BCH in the first couple of weeks after
> the split.
>
> On the same basis, the 2x futures market predicted that mining the 2x
> chain would be massively unprofitable: immediately after the split,
> both the 2x chain and the original-rules chain would have the same
> difficulty and hence have the same expected cost to mine a block; but
> the 2x chain would only have 25% of the reward (0.2 vs 0.8 valuation per
> the futures market). Without someone subsidising the first 2016 blocks on
> the 2x chain to the tune of about ~15,000 pre-split bitcoin (or ~75,000
> post-split 2x coins; or between $80M-$150M USD), either directly, or by
> mining at an economic loss, the 2x chain could only collapse.
>
> BCH avoided that fate by having a new difficulty adjustment algorithm
> that allowed the difficulty to drop immediately, rather than only on
> the next 2016 block boundary.
>
> > They could signal a change with 100% and then after it is activated on
> > one chain and resisted on another, they 95% of them may switch to the
> > old chain simply because its rewards are 20 times more valuable. This
> > may happen 3 days after activation or 3 months, or more.
>
> If it's an either-or choice, it's likely that 99.9% of hashrate will
> switch even if the rewards are only 0.1 times more valuable (or 1.1
> times as valuable if you prefer). That's why you run a futures market,
> to figure out which will be more valuable and by how much.
>
> We saw the either-or case happen with BCH vs BTC; the difficulty of BCH
> would drop quickly due to the "EDA", but only rise slowly, making BCH
> mining more profitable for an extended period so that opportunistic miners
> would switch to BCH for a while until it got expensive again then switch
> back to BTC, causing both chains' hashrate to be unstable.
>
> But if you don't hard fork to a different difficulty adjustment algorithm
> the way BCH did on day one, then it doesn't matter how long miners
> don't mine on your chain, your chain's difficulty won't adjust, and so
> you'll need to instead wait until BTC's difficulty doubles or more,
> or its reward halves or more, or some combination of the two. That's
> likely much more than 3 months away. I can't imagine why anyone would
> still care about your proposed chain months or years later.
>
> So hardforking in merge-mining (so it's not an either-or question) or
> a new difficulty adjustment algorithm (so you don't have to wait months
> or years) seems a much more realistic approach.
>
> > >     So if acting like reasonable people and talking it through doesn't
> > >     work, this seems like the next step to me.
> > Not to me, but you're free to create your future markets or trade in them.
> > I wouldn't do any of them, and I would advice against it.
>
> *shrug* Do what you like (and I mean, I don't trade in futures markets
> either) but I think you'd be missing out on very useful information,
> and losing a chance for people who aren't devs to offer tangible and
> objective support for your cause.
>
> > >     I think the speedy trial approach here is ideal for a last ditch
> > >     "everyone stays on the same chain while avoiding this horrible change"
> > >     attempt. The reason being that it allows everyone to agree to not
> > >     adopt the new rules with only very little cost: all you need is for
> > >     10% of hashpower to not signal over a three month period.
> > No, 10% of hashpower is not "very little cost", that's very expensive.
>
> If we're talking about consensus changes, the target is 100% of hashpower,
> and also something approaching 100% of nodes. By comparison 10% of
> hashpower is *much* cheaper, especially when the 100% have to actively
> upgrade in order to support, while the 10% just have to not do anything
> in order to oppose.
>
> To be clear: You don't have to setup the 10% of hashpower yourself,
> you just have to convince the existing owners of 10% of hashpower to
> not actively support the change.
>
> > >     That's cheaper than bip9 (5% over 12 months requires 2x the
> > >     cumulative hashpower), and much cheaper than bip8 which requires
> > >     users to update their software
> > Updating software is not expensive. the code for bip8 could have been
> > merged long before taproot was even initially proposed.
> > It could be merged now before another proposal.
>
> The BIP8 spec we have today is very different to the BIP8 spec when
> taproot was merged, let alone before it was even proposed. As it was,
> it had serious problems that hadn't been addressed, and the version we
> have today likewise has significant problems that haven't been addressed,
> which is why it wasn't and shouldn't be merged.
>
> > Updating software is certainly not more expensive than getting 10% of
> > the hashrate.
>
> Updating software (or not updating software) is precisely *how* to get
> 10% of hashrate. It's not more or less expensive -- it *is* the expense.
>
> > >  4) At this point, if you were able to prevent activation, hopefully
> > >     that's enough of a power move that people will take your concerns
> > >     seriously, and you get a second chance at step (1). If that still
> > >     results in an impasse, I'd expect there to be a second, non-speedy
> > >     activation of the soft fork, that either cannot be blocked at all, or
> > >     cannot be blocked without having control of at least 60% of hashpower.
> > And if you never got 10% hashpower, we move to the next step, I guess.
>
> Yes; you then move to the next step knowing that what level of
> interest/support you actually have.
>
> > >  5) If you weren't able to prevent activation (whether or not you
> > >     prevented speedy trial from working), then you should have a lot
> > >     of information:
> > >
> > >       - you weren't able to convince people there was a problem
> > >
> > >       - you either weren't in the economic majority and people don't
> > >         think your concept of bitcoin is more valuable (perhaps they
> > >         don't even think it's valuable enough to setup a futures market
> > >         for you)
> > >
> > >       - you can't get control of even 10% of hashpower for a few months
> > >
> > >     and your only option is to accept defeat or create a new chain.
> > What if it's still the other people who are lacking information?
>
> If it's other people that lack information, there's two options. One,
> you might be able to explain things to them, so that they learn and gain
> the information. The other is that for whatever reason they're not willing
> to listen to the truth and will remain ignorant. If it's the first case,
> you'd have succeeded in an earlier step. If it's the latter, then it's
> not something you can change, and it doesn't really matter in how you
> decide what to do next.
>
> > It wouldn't be a new chain, it would be the old chain without the new
> > evil change, until you manage to show the other people that the change
> > was indeed evil.
> > Remember, in this example, the new change being evil is not a
> > possibility, but an assumption.
>
> It's extremely unhelpful to call things "evil" if what you want is a
> reasonable discussion. And if reasonable discussion isn't what you want,
> you're in the wrong place.
>
> At this point in the hypothetical you're in a small minority, and have
> been unable to convince people of your point of view. Calling the people
> you disagree with "evil" (and saying they support something that's evil
> is exactly that) isn't going to improve your situation, and doing it in
> a hypothetical sure feels like bad faith.
>
> > What you're arguing is "if you haven't been able to stop the evil
> > change, then perhaps it wasn't evil all along and the people trying to
> > resist it were wrong and don't know it".
>
> If it's an evil change, then good people will oppose it. You've tried
> convincing devs in the "discuss the proposal" stage, whales in the
> "futures market" stage, and miners in the "hashpower signalling" phase,
> and failed each time because the good people in each of those groups
> haven't opposed it. So yes, I think the most likely explanation is that
> you're wrong in thinking it's evil.
>
> But hey what about the worst case: what if everyone else in bitcoin
> is evil and supports doing evil things. And maybe that's not even
> implausible: maybe it's not an "evil" thing per se, perhaps it's simply
> equally "misguided" as the things that central banks or wall street or
> similar are doing today. Perhaps bitcoin becomes the world currency,
> and in 100 or 200 years time, whether through complacency and forgetting
> the lessons of the past, or too much adherence to dogma that no longer
> matches reality, or just hitting some new problem that's never been seen
> before and an inability to perfectly predict the future, and as a result
> most of the world opts into some change that will cause bitcoin to fail.
>
> In that scenario, I think a hard fork is the best choice: split out a new
> coin that will survive the upcoming crash, adjust the mining/difficulty
> algorithm so it works from day one, and set it up so that you can
> maintain it along with the people who support your vision, rather than
> having to constantly deal with well-meaning attacks from "bitcoiners"
> who don't see the risks and have lost the plot.
>
> Basically: do what Satoshi did and create a better system, and let
> everyone else join you as the problems with the old one eventually become
> unavoidably obvious.
>
> > But that contradicts the premise: an evil change being deployed using
> > speedy trial.
>
> Again: any change that could be avoided if it were deployed via BIP8,
> can also be avoided *by the exact same techniques* if it were deployed
> via speedy trial or a similar approach.
>
> > >     Since your new chain won't have a hashpower majority, you'll likely
> > >     have significant problems if you don't hard fork in a change to
> > >     how proof-of-work works; my guess is you'd either want to switch
> > >     to a different proof-of-work algorithm, or make your chain able
> > >     to be merge-mined against bitcoin, though just following BCH/BSV's
> > >     example and tweaking the difficulty adjustment to be more dynamic
> > >     could work too.
> > No, I disagree. You'll just get the hashpower you pay for with subsidy and fees.
>
> The value of the subsidy is something you can directly figure out from
> running a futures market; and unless you're deliberately subsidising fees,
> they'll almost certainly be ~0.
>
> > >     (For comparison, apparently BCH has 0.8% of bitcoin's hashrate,
> > >     BSV has 0.2%. Meanwhile, Namecoin, RSK and Syscoin, which support
> > >     merge-mining, are apparently at 68%, 42% and 17% respectively)
> > Google tells me 0.0073BTC.
>
> I think you're reading too much precision into those numbers? When
> I looked again the other day, I got a figure of 0.66%; today I get
> 0.75%. I'm sure I rounded whatever figure I saw to one significant figure,
> so it might have been 0.75% then too.
>
> https://bitinfocharts.com/comparison/bitcoin-hashrate.html#3y
> https://bitinfocharts.com/comparison/bitcoin%20cash-hashrate.html#3y
>
> > In perfect competition and leaving fees aside (in which probably
> > bitcoin wins too), BCH should have approximately 0.0073% the hashrate
> > bitcoin hash.
>
> Oh, or you're just getting the percentage conversion wrong -- 0.0073
> BTC is 0.73% of a BTC, and thus it would be expected to have about 0.73%
> of the hashrate.
>
> > >     At the point that you're doing a hard fork, making a clean split is
> > >     straightforward: schedule the hard fork for around the same time as
> > >     the start of enforcement of the soft fork you oppose, work out how
> > >     to make sure you're on your own p2p network, and figure out how
> > >     exchanges and lightning channels and everything else are going to
> > >     cope with the coin split.
> > You shouldn't need to do a hardfork to resist a consensus change you don't like.
>
> Of course; that's why option (1) is to talk to people about why it's a
> bad idea so it doesn't get proposed in the first place.
>
> But if you want to resist a consensus change that is overwhelmingly
> supported by the rest of the bitcoin economy, and for which your reasons
> aren't even considered particularly logical by everyone else, then yeah,
> if you really want to go off on your own because everyone else is wrong,
> you *should* do a hardfork.
>
> If a change doesn't have overwhelming support, then hopefully the costs
> to get 90% of hashrate signalling is a significant impediment. If you do
> have overwhelming support, then the cost to get 90% of hashrate signalling
> (or even apparently 99.8%, see getdeploymentinfo on block 693503) --
> doesn't seem to be too bad.
>
> > "around the same time", with bip8 and the resistance mechanism
> > proposed by luke, it doesn't need to be "around the same time
> > according to some expert who will tell you what to put in your
> > software", but "exactly at the same time, and you only need to know
> > which pproposal version bit you're opposing".
>
> (Arguing semantics: You can't do the split at exactly the same time,
> because the split starts with each chain finding a new block, and blocks
> are found probabilistically depending on hashrate, so they won't be found
> at the same time. Or, alternatively, the split happens whenever either
> client considers the other chain invalid, and always happens at the
> "same" time)
>
> If you want to do things at exactly the same height, you can do that if
> the soft fork is activated by speedy trial as well.
>
> I'd say the same height approach works better on speedy trial than
> with BIP8/BIP343, since with speedy trial signalling is only for a
> short period, and hence you know well in advance if and when you'll be
> splitting, whereas with an extended signalling period that goes for a
> year past the minimum activation height, you may find yourself splitting
> at any point in that year with as little as two week's notice.
>
> If I were doing a hardfork coin split to avoid following some new soft
> forked rules that I think were horrible, I think I'd prefer to do the
> split in advance of the softfork -- that way exchanges/wallets/lightning
> channels/etc that have to do work to deal with the coinsplit aren't
> distracted by simultaneously having to pay attention to the new softfork.
> YMMV of course.
>
> > Yeah, great example. It doesn't have to be an "evil change" as such,
> > it can just be a "deeply wrong change" or something.
> > Or if we were using BIP8 and had the resistance mechanism proposed by
> > luke, all we would need to do is change one line and recompile:
> > I don't remember his enumeration constants but, something like...
> > - bip8Params.EvilProposalActivationMode = FORCE_ACTIVATION;
> > + bip8Params.EvilProposalActivationMode = FORBID_ACTIVATION;
> > Say we discover it 3 days before forced activation.
> > Well, that would still be much less rushed that the berkeleyDB thing,
> > wouldn't it?
>
> No, exactly the opposite.
>
> In order to abort a BIP8 activation, 100% of hashpower and 100% of
> node software needs to downgrade from anything that specifies BIP8 with
> mandatory activation.
>
> The "berkelyDB thing" was an accidental hard fork due to the updated
> software with leveldb being able to accept larger blocks than the old
> bdb-based bitcoind could.
>
> The result was two chains: one with a large block in it, that could
> only be validated by the newer software, and a less work chain with only
> smaller chains, that could be validated by both versions of the software;
> the problem was ~60% of hashpower was on the larger-block chain, but
> many nodes including those with ~40% hashpower. The problem was quickly
> mitigated by encouraging a majority of hashpower to downgrade to the
> old software, resulting in them rejecting the larger-block chain,
> at which point a majority of hashpower was mining the smaller-block
> chain, and the smaller-block chain eventually having more work than
> the larger-block chain. At that point any newer nodes reorged to the
> more-work, smaller-block chain, and everyone was following the same chain.
>
> What that means is that the operators of *two* pools downgraded their
> software, and everything was fixed. That's a *lot* less work than
> everyone who upgraded their node having to downgrade/re-update, and
> it was done that way to *avoid* having to rush to get everyone to do
> an emergency update of their node software to be compatible with the
> larger-block chain.
>
> See https://bitcoin.org/en/alert/2013-03-11-chain-fork
> and https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki
>
> On the other hand, that approach only works because it takes advantage
> of a lot of hashrate being centralised around a few pools; if we succeed
> in making block construction more decentralised, solutions here will
> only become harder.
>
> > If there's only opposition after it is deployed, whatever the
> > activation mechanism, in that particular case, would be irrelevant.
>
> Once you've released software with a softfork activated via BIP8 with
> mandatory activation (ie, lot=true), and it has achieved any significant
> adoption, the soft fork is already deployed and you need to treat it as
> such. If you want to have an easier way of undoing the softfork than
> you would have for one that's already active on the network, you need
> a different activation method than BIP8/lot=true.
>
> Cheers,
> aj
>

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev wrote:
> Sorry, I won't answer to everything, because it's clear you're not listening.

I'm not agreeing with you; that's different to not listening to you.

> In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
> is a PREMISE of that hypothetical case, a GIVEN.

Do you really find people more inclined to start agreeing with you when
you begin yelling at them? When other people start shouting at you,
do you feel like it's a discussion that you're engaged in?

> Your claim that "if it's evil, good people would oppose it" is a NON
> SEQUITUR, "good people" aren't necessarily perfect and all knowing.
> good people can make mistakes, they can be fooled too.
> In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
> don't complain, it is because they didn't realize that the given fork
> was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
> DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
> hypothetical case where there's a fork some people think it's evil but
> it's not really evil.

The problem with that approach is that any solution we come up with
doesn't only have to deal with the hypotheticals you want to discuss.

In particular, any approach that allows you to block an evil fork,
even when everyone else doesn't agree that it's evil, would also allow
an enemy of bitcoin to block a good fork, that everyone else correctly
recognises is good. A solution that works for an implausible hypothetical
and breaks when a single attacker decides to take advantage of it is
not a good design.

And I did already address what to do in exactly that scenario:

> > But hey what about the worst case: what if everyone else in bitcoin
> > is evil and supports doing evil things. And maybe that's not even
> > implausible: maybe it's not an "evil" thing per se, perhaps [...]
> >
> > In that scenario, I think a hard fork is the best choice: split out a new
> > coin that will survive the upcoming crash, adjust the mining/difficulty
> > algorithm so it works from day one, and set it up so that you can
> > maintain it along with the people who support your vision, rather than
> > having to constantly deal with well-meaning attacks from "bitcoiners"
> > who don't see the risks and have lost the plot.
> >
> > Basically: do what Satoshi did and create a better system, and let
> > everyone else join you as the problems with the old one eventually become
> > unavoidably obvious.

> Once you understand what hypothetical case I'm talking about, maybe
> you can understand the rest of my reasoning.

As I understand it, your hypothetical is:

 0) someone has come up with a bad idea
 1) most of bitcoin is enthusiastically behind the idea
 2) you are essentially alone in discovering that it's a bad idea
 3) almost everyone remains enthusiastic, despite your explanations that
    it's a bad idea
 4) nevertheless, you and your colleagues who are aware the idea is bad
    should have the power to stop the bad idea
 5) bip8 gives you the power to stop the bad idea but speedy trial does not

Again given (0), I think (1) and (2) are already not very likely, and (3)
is simply not plausible. But in the event that it does somehow occur,
I disagree with (4) for the reasons I describe above; namely, that any
mechanism that did allow that would be unable to distinguish between the
"bad idea" case and something along the lines of:

 0') someone has come up with a good idea (yay!)
 1') most of bitcoin is enthusiastically behind the idea
 2') an enemy of bitcoin is essentially alone in trying to stop it
 3') almost everyone remains enthusiastic, despite that guy's incoherent
     raving
 4') nevertheless, the enemies of bitcoin should have the power to stop
     the good idea

And, as I said in the previous mail, I think (5) is false, independently
of any of the other conditions.

> But if you don't understand the PREMISES of my example, 

You can come up with hypothetical premises that invalidate bitcoin,
let alone some activation method. For example, imagine if the Federal
Reserve Board are full of geniuses and know exactly when to keep issuance
predictable and when to juice the economy? Having flexibility gives more
options than hardcoding "21M" somewhere, so clearly the USD's approach
is the way to go, and everything is just a matter of appointing the
right people to the board, not all this decentralised stuff. 

The right answer is to reject bad premises, not to argue hypotheticals
that have zero relationship to reality.

Cheers,
aj

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

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

On Sat, Mar 26, 2022, 01:45 Anthony Towns <aj@erisian.com.au> wrote:

> On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > Sorry, I won't answer to everything, because it's clear you're not
> listening.
>
> I'm not agreeing with you; that's different to not listening to you.
>

You're disagreeing with thw premises of the example. That's not
disagreeing, that's refusing to understand the example.


> > In the HYPOTHETICAL CASE that there's an evil for, the fork being evil
> > is a PREMISE of that hypothetical case, a GIVEN.
>
> Do you really find people more inclined to start agreeing with you when
> you begin yelling at them? When other people start shouting at you,
> do you feel like it's a discussion that you're engaged in?
>

I just wanted to make sure you catched the PREMISE word.


> > Your claim that "if it's evil, good people would oppose it" is a NON
> > SEQUITUR, "good people" aren't necessarily perfect and all knowing.
> > good people can make mistakes, they can be fooled too.
> > In the hypothetical case that THERE'S AN EVIL FORK, if "good people"
> > don't complain, it is because they didn't realize that the given fork
> > was evil. Because in our hypothetical example THE EVIL FORK IS EVIL BY
> > DEFINITION, THAT'S THE HYPOTHETICAL CASE I WANT TO DISCUSS, not the
> > hypothetical case where there's a fork some people think it's evil but
> > it's not really evil.
>
> The problem with that approach is that any solution we come up with
> doesn't only have to deal with the hypotheticals you want to discuss
>

Sure, but if it doesn't deal with this hypothetical, one canbot pretending
it does by explaing how it does in a different hypothetical.

In particular, any approach that allows you to block an evil fork,
> even when everyone else doesn't agree that it's evil, would also allow
> an enemy of bitcoin to block a good fork, that everyone else correctly
> recognises is good. A solution that works for an implausible hypothetical
> and breaks when a single attacker decides to take advantage of it is
> not a good design.
>

Let's discuss those too. Feel free to point out how bip8 fails at some
hypothetical cases speedy trial doesn't.

And I did already address what to do in exactly that scenario:
>
> > > But hey what about the worst case: what if everyone else in bitcoin
> > > is evil and supports doing evil things. And maybe that's not even
> > > implausible: maybe it's not an "evil" thing per se, perhaps [...]
> > >
> > > In that scenario, I think a hard fork is the best choice: split out a
> new
> > > coin that will survive the upcoming crash, adjust the mining/difficulty
> > > algorithm so it works from day one, and set it up so that you can
> > > maintain it along with the people who support your vision, rather than
> > > having to constantly deal with well-meaning attacks from "bitcoiners"
> > > who don't see the risks and have lost the plot.
> > >
> > > Basically: do what Satoshi did and create a better system, and let
> > > everyone else join you as the problems with the old one eventually
> become
> > > unavoidably obvious.
>
> > Once you understand what hypothetical case I'm talking about, maybe
> > you can understand the rest of my reasoning.
>
> As I understand it, your hypothetical is:
>
>  0) someone has come up with a bad idea
>  1) most of bitcoin is enthusiastically behind the idea
>  2) you are essentially alone in discovering that it's a bad idea
>  3) almost everyone remains enthusiastic, despite your explanations that
>     it's a bad idea
>  4) nevertheless, you and your colleagues who are aware the idea is bad
>     should have the power to stop the bad idea
>  5) bip8 gives you the power to stop the bad idea but speedy trial does not
>



Again given (0), I think (1) and (2) are already not very likely, and (3)
> is simply not plausible. But in the event that it does somehow occur,
> I disagree with (4) for the reasons I describe above; namely, that any
> mechanism that did allow that would be unable to distinguish between the
> "bad idea" case and something along the lines of
>

Ok, yeah, the bitcoin developers currently paying attention to the mailibg
list being fooled or making a review mistake is completely unfeasible.
They're all way to humble for that, obviously...sigh.

 0') someone has come up with a good idea (yay!)
>  1') most of bitcoin is enthusiastically behind the idea
>  2') an enemy of bitcoin is essentially alone in trying to stop it
>  3') almost everyone remains enthusiastic, despite that guy's incoherent
>      raving
>  4') nevertheless, the enemies of bitcoin should have the power to stop
>      the good idea
>
> And, as I said in the previous mail, I think (5) is false, independently
> of any of the other conditions.
>

"That guy's incoherent raving"
"I'm just disagreeing".

Never mind, anthony.
Ypu absolutely understood what I'm saying. It's just that I'm also
incoherent to you, it seems. But, hey, again, no contradiction here, I
guess.



> But if you don't understand the PREMISES of my example,
>
> You can come up with hypothetical premises that invalidate bitcoin,
> let alone some activation method. For example, imagine if the Federal
> Reserve Board are full of geniuses and know exactly when to keep issuance
> predictable and when to juice the economy? Having flexibility gives more
> options than hardcoding "21M" somewhere, so clearly the USD's approach
> is the way to go, and everything is just a matter of appointing the
> right people to the board, not all this decentralised stuff.
>
> The right answer is to reject bad premises, not to argue hypotheticals
> that have zero relationship to reality
>

Ok, stop arguing a hypothetical you don't want to arhue about. But you
can't say both "I don't want to consider that hypothetical" and "we
considered all hypotheticals" at the same time.
I mean, you can, you only can't if you don't want to contradict yourself.

I'll have to wait for someone who actually can both understand the
hypothetical and ve willing to discuss it.
I think you didn't understand it, but either way: thank you for admitting
you don't want to discuss it.
Let's stop wasting each other's time then.


Cheers,
> aj
>
>

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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev wrote:
> > In particular, any approach that allows you to block an evil fork,
> > even when everyone else doesn't agree that it's evil, would also allow
> > an enemy of bitcoin to block a good fork, that everyone else correctly
> > recognises is good. A solution that works for an implausible hypothetical
> > and breaks when a single attacker decides to take advantage of it is
> > not a good design.
> Let's discuss those too. Feel free to point out how bip8 fails at some
> hypothetical cases speedy trial doesn't.

Any case where a flawed proposal makes it through getting activation
parameters set and released, but doesn't achieve supermajority hashpower
support is made worse by bip8/lot=true in comparison to speedy trial.

That's true both because of the "trial" part, in that activation can fail
and you can go back to the drawing board without having to get everyone
upgrade a second time, and also the "speedy" part, in that you don't
have to wait a year or more before you even know what's going to happen.

> >  0') someone has come up with a good idea (yay!)
> >  1') most of bitcoin is enthusiastically behind the idea
> >  2') an enemy of bitcoin is essentially alone in trying to stop it
> >  3') almost everyone remains enthusiastic, despite that guy's incoherent
> >      raving
> >  4') nevertheless, the enemies of bitcoin should have the power to stop
> >      the good idea
> "That guy's incoherent raving"
> "I'm just disagreeing".

Uh, you realise the above is an alternative hypothetical, and not talking
about you? I would have thought "that guy" being "an enemy of bitcoin"
made that obvious... I think you're mistaken; I don't think your emails
are incoherent ravings.

It was intended to be the simplest possible case of where someone being
able to block a change is undesirable: they're motivated by trying to
harm bitcoin, they're as far as possible from being part of some economic
majority, and they don't even have a coherent rationale to provide for
blocking the idea.

Cheers,
aj

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

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

On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj@erisian.com.au> wrote:

> On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev
> wrote:
> > > In particular, any approach that allows you to block an evil fork,
> > > even when everyone else doesn't agree that it's evil, would also allow
> > > an enemy of bitcoin to block a good fork, that everyone else correctly
> > > recognises is good. A solution that works for an implausible
> hypothetical
> > > and breaks when a single attacker decides to take advantage of it is
> > > not a good design.
> > Let's discuss those too. Feel free to point out how bip8 fails at some
> > hypothetical cases speedy trial doesn't.
>
> Any case where a flawed proposal makes it through getting activation
> parameters set and released, but doesn't achieve supermajority hashpower
> support is made worse by bip8/lot=true in comparison to speedy trial
>

I disagree. Also, again, not the hypothetical case I want to discuss.


> That's true both because of the "trial" part, in that activation can fail
> and you can go back to the drawing board without having to get everyone
> upgrade a second time, and also the "speedy" part, in that you don't
> have to wait a year or more before you even know what's going to happen.
>
> > >  0') someone has come up with a good idea (yay!)
> > >  1') most of bitcoin is enthusiastically behind the idea
> > >  2') an enemy of bitcoin is essentially alone in trying to stop it
> > >  3') almost everyone remains enthusiastic, despite that guy's
> incoherent
> > >      raving
> > >  4') nevertheless, the enemies of bitcoin should have the power to stop
> > >      the good idea
> > "That guy's incoherent raving"
> > "I'm just disagreeing".
>
> Uh, you realise the above is an alternative hypothetical, and not talking
> about you? I would have thought "that guy" being "an enemy of bitcoin"
> made that obvious... I think you're mistaken; I don't think your emails
> are incoherent ravings.
>

Do you realize IT IS NOT the hypothetical case I wanted to discuss. Seems
like that hypothetical case where a crazy person can be safely ignored
covered already.


> It was intended to be the simplest possible case of where someone being
> able to block a change is undesirable: they're motivated by trying to
> harm bitcoin, they're as far as possible from being part of some economic
> majority, and they don't even have a coherent rationale to provide for
> blocking the idea.
>
> Cheers,
> aj
>

Either I'm explaining my self very badly, you don't want to understand me,
or you can't understand me for whatever reason.
I don't feel listened or that "my concerns have been addressed", but at
this point  I feel we're wasting each others time.Perhaps my rational
against speedy trial is not coherent, or perhaps you haven't understand it
yet.
I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
don't seem interested in listening to me and understanding me at all, but
only in "addressing my concerns". Obviously we understand different things
by "addressing concerns".
Perhaps it's the language barrier or something.

Good bye.

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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev wrote:
> On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj@erisian.com.au> wrote:
> > > Let's discuss those too. Feel free to point out how bip8 fails at some
> > > hypothetical cases speedy trial doesn't.
> > Any case where a flawed proposal makes it through getting activation
> > parameters set and released, but doesn't achieve supermajority hashpower
> > support is made worse by bip8/lot=true in comparison to speedy trial
> I disagree. Also, again, not the hypothetical case I want to discuss.

You just said "Let's discuss those" and "Feel free to point out how bip8
fails at some hypothetical cases speedy trial doesn't", now you're
saying it's not what you want to discuss?

But the above does include your "evil soft fork" hypothetical (I mean,
unless you think being evil isn't a flaw?). The evil soft fork gets
proposed, and due to some failure in review, merged with activation
parameters set (via either speedy trial or bip8), then:

 a) supermajority hashpower support is achieved quickly:
     - both speedy trial and bip8+lot=true activate the evil fork

 b) supermajority hashpower support is achieved slowly:
     - speedy trial does *not* activate the evil fork, as it times out
       quickly
     - bip8 *does* activate the fork

 c) supermajority hashpower support support is never achieved:
     - speedy trial does *not* activate the evil fork
     - bip8+lot=false does *not* activate the evil fork, but only after a
       long timeout
     - bip8+lot=true *does* activate the evil fork

In case (a), they both do the same thing; in case (b) speedy trial is
superior to bip8 no matter whether lot=true/false since it blocks the
evil fork, and in case (c) speedy trial is better than lot=false because
it's quicker, and much better than lot=true because lot=true activates
the evil fork.

> > > >  0') someone has come up with a good idea (yay!)
> > > >  1') most of bitcoin is enthusiastically behind the idea
> > > >  2') an enemy of bitcoin is essentially alone in trying to stop it
> > > >  3') almost everyone remains enthusiastic, despite that guy's
> > incoherent
> > > >      raving
> > > >  4') nevertheless, the enemies of bitcoin should have the power to stop
> > > >      the good idea
> > > "That guy's incoherent raving"
> > > "I'm just disagreeing".
> >
> > Uh, you realise the above is an alternative hypothetical, and not talking
> > about you? I would have thought "that guy" being "an enemy of bitcoin"
> > made that obvious... I think you're mistaken; I don't think your emails
> > are incoherent ravings.
> Do you realize IT IS NOT the hypothetical case I wanted to discuss. 

Yes, that's what "alternative" means: a different one.

> I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
> don't seem interested in listening to me and understanding me at all, but
> only in "addressing my concerns". Obviously we understand different things
> by "addressing concerns".
> Perhaps it's the language barrier or something.

My claim is that for *any* bad (evil, flawed, whatever) softfork, then
attempting activation via bip8 is *never* superior to speedy trial,
and in some cases is worse.

If I'm missing something, you only need to work through a single example
to demonstrate I'm wrong, which seems like it ought to be easy... But
just saying "I disagree" and "I don't want to talk about that" isn't
going to convince anyone.

I really don't think the claim above should be surprising; bip8 is meant
for activating good proposals, bad ones need to be stopped in review --
as "pushd" has said in this thread: "Flawed proposal making it through
activation is a failure of review process", and Luke's said similar things
as well. The point of bip8 isn't to make it easier to reject bad forks,
it's to make it easier to ensure *good* forks don't get rejected. But
that's not your hypothetical, and you don't want to talk about all the
ways to stop an evil fork prior to an activation attempt...

Cheers,
aj

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

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

You're not even considering user resistance in your cases. You're purely
relying on miners and calling speedy trial superior. I don't know if you're
being obtuse on purpose, I'm explaining myself very badly...

I DON'T WANT TO RELY ON MINERS TO RESIST CHANGES I DON'T WANT TO.
Sorry for the tone, but, please, make sure you understand that before
answering further, or otherwise it is a waste of time.

Note that it doesn't have to be in bitcoin core, speedy trial could be used
for attempting to activate a controversial softfork (it doesn't need to be
an evil fork, even) outside of core. Like what jeremy is trying to do with
his proposal, for example.
Now, go ahead and tell me that if miners reject it, then doesn't matter,
because nobody ever has told me that before, I need to hear it one more
time.
And I'll tell you I don't care about what miners will do, because you
obviously need to hear it one more time as well.
Or just tell the list that you resolved all my concerns, like jeremy does
about any criticism of his proposals, "well, it has consensus because only
people seeking dissent don't like it". Likd with speedy trial.
"Some people conplained, but we told them theur concerns were addressed and
even though they disagreed and claimed we didn't understand their
concerns...it looked like they were seeking dissent, so we told them to f@$k
off and now there's consensus".

Sorry for the aggressive tone, but I when people ignore some of my points
repeteadly, I start to wonder if they do it on purpose. You're not ignoring
my points on purpose, are you?
Nah, of course not, it's just that communication is hard.
Surely it wouldn't be fair if I accused you of being dishonest or
pretending to be dumb.
Most probably, I'm not clear or direct enough.
Whatever the real explanation is for you not understanding me, you're not
understanding me and it feels luke a waste of time for both of us.
So, I'm sorry, it's over.


On Mon, Apr 11, 2022, 14:05 Anthony Towns <aj@erisian.com.au> wrote:

> On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev
> wrote:
> > On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns <aj@erisian.com.au> wrote:
> > > > Let's discuss those too. Feel free to point out how bip8 fails at
> some
> > > > hypothetical cases speedy trial doesn't.
> > > Any case where a flawed proposal makes it through getting activation
> > > parameters set and released, but doesn't achieve supermajority
> hashpower
> > > support is made worse by bip8/lot=true in comparison to speedy trial
> > I disagree. Also, again, not the hypothetical case I want to discuss.
>
> You just said "Let's discuss those" and "Feel free to point out how bip8
> fails at some hypothetical cases speedy trial doesn't", now you're
> saying it's not what you want to discuss?
>
> But the above does include your "evil soft fork" hypothetical (I mean,
> unless you think being evil isn't a flaw?). The evil soft fork gets
> proposed, and due to some failure in review, merged with activation
> parameters set (via either speedy trial or bip8), then:
>
>  a) supermajority hashpower support is achieved quickly:
>      - both speedy trial and bip8+lot=true activate the evil fork
>
>  b) supermajority hashpower support is achieved slowly:
>      - speedy trial does *not* activate the evil fork, as it times out
>        quickly
>      - bip8 *does* activate the fork
>
>  c) supermajority hashpower support support is never achieved:
>      - speedy trial does *not* activate the evil fork
>      - bip8+lot=false does *not* activate the evil fork, but only after a
>        long timeout
>      - bip8+lot=true *does* activate the evil fork
>
> In case (a), they both do the same thing; in case (b) speedy trial is
> superior to bip8 no matter whether lot=true/false since it blocks the
> evil fork, and in case (c) speedy trial is better than lot=false because
> it's quicker, and much better than lot=true because lot=true activates
> the evil fork.
>
> > > > >  0') someone has come up with a good idea (yay!)
> > > > >  1') most of bitcoin is enthusiastically behind the idea
> > > > >  2') an enemy of bitcoin is essentially alone in trying to stop it
> > > > >  3') almost everyone remains enthusiastic, despite that guy's
> > > incoherent
> > > > >      raving
> > > > >  4') nevertheless, the enemies of bitcoin should have the power to
> stop
> > > > >      the good idea
> > > > "That guy's incoherent raving"
> > > > "I'm just disagreeing".
> > >
> > > Uh, you realise the above is an alternative hypothetical, and not
> talking
> > > about you? I would have thought "that guy" being "an enemy of bitcoin"
> > > made that obvious... I think you're mistaken; I don't think your emails
> > > are incoherent ravings.
> > Do you realize IT IS NOT the hypothetical case I wanted to discuss.
>
> Yes, that's what "alternative" means: a different one.
>
> > I'm sorry, but I'm tired of trying to explain. and quite, honestly, you
> > don't seem interested in listening to me and understanding me at all, but
> > only in "addressing my concerns". Obviously we understand different
> things
> > by "addressing concerns".
> > Perhaps it's the language barrier or something.
>
> My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> attempting activation via bip8 is *never* superior to speedy trial,
> and in some cases is worse.
>
> If I'm missing something, you only need to work through a single example
> to demonstrate I'm wrong, which seems like it ought to be easy... But
> just saying "I disagree" and "I don't want to talk about that" isn't
> going to convince anyone.
>
> I really don't think the claim above should be surprising; bip8 is meant
> for activating good proposals, bad ones need to be stopped in review --
> as "pushd" has said in this thread: "Flawed proposal making it through
> activation is a failure of review process", and Luke's said similar things
> as well. The point of bip8 isn't to make it easier to reject bad forks,
> it's to make it easier to ensure *good* forks don't get rejected. But
> that's not your hypothetical, and you don't want to talk about all the
> ways to stop an evil fork prior to an activation attempt...
>
> Cheers,
> aj
>
>

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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
> You're not even considering user resistance in your cases. 

Of course I am. Again:

> > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> > attempting activation via bip8 is *never* superior to speedy trial,
> > and in some cases is worse.
> >
> > If I'm missing something, you only need to work through a single example
> > to demonstrate I'm wrong, which seems like it ought to be easy... But
> > just saying "I disagree" and "I don't want to talk about that" isn't
> > going to convince anyone.

The "some cases" where bip8 with lot=true is *worse* than speedy trial
is when miners correctly see that a bad fork is bad.

Under *any* other circumstance, when they're used to activate a bad soft
fork, speedy trial and bip8 are the same. If a resistance method works
against bip8, it works against speedy trial; if it fails against speedy
trial, it fails against bip8.

> Sorry for the aggressive tone, but I when people ignore some of my points
> repeteadly, I start to wonder if they do it on purpose. 

Perhaps examine the beam in your own eye.

Cheers,
aj

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

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

On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns <aj@erisian.com.au> wrote:

> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
> > You're not even considering user resistance in your cases.
>
> Of course I am. Again:
>

No, you're relying on miners to stop bad proposals.


> > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
> > > attempting activation via bip8 is *never* superior to speedy trial,
> > > and in some cases is worse.
> > >
> > > If I'm missing something, you only need to work through a single
> example
> > > to demonstrate I'm wrong, which seems like it ought to be easy... But
> > > just saying "I disagree" and "I don't want to talk about that" isn't
> > > going to convince anyone.
>
> The "some cases" where bip8 with lot=true is *worse* than speedy trial
> is when miners correctly see that a bad fork is bad.
>
> Under *any* other circumstance, when they're used to activate a bad soft
> fork, speedy trial and bip8 are the same. If a resistance method works
> against bip8, it works against speedy trial; if it fails against speedy
> trial, it fails against bip8.
>

You're wrong.


> > Sorry for the aggressive tone, but I when people ignore some of my points
> > repeteadly, I start to wonder if they do it on purpose.
>
> Perhaps examine the beam in your own eye.
>

Yeah, whether you do that yourself or not: sorry, it's over.


> Cheers,
> aj
>

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

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland]

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

Hi AJ,

> Under *any* other circumstance, when they're used to activate a bad soft
fork, speedy trial and bip8 are the same. If a resistance method works
against bip8, it works against speedy trial; if it fails against speedy
trial, it fails against bip8.

IIRC one essential difference between ST (which is a variant of BIP9) and
BIP8 is that since there is no mandatory signaling during the lockin
period, you can't do a counter soft fork as easily. This is one of the
points that Luke mentioned to me that made clear the benefits of the
mandatory signaling. A variant of ST that does require mandatory signaling
may actually be something that can improve the process and give users a
more effective means of forking away from SF changes that they reject.

Keagan

On Sun, Apr 24, 2022 at 12:58 PM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns <aj@erisian.com.au> wrote:
>
>> On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote:
>> > You're not even considering user resistance in your cases.
>>
>> Of course I am. Again:
>>
>
> No, you're relying on miners to stop bad proposals.
>
>
>> > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then
>> > > attempting activation via bip8 is *never* superior to speedy trial,
>> > > and in some cases is worse.
>> > >
>> > > If I'm missing something, you only need to work through a single
>> example
>> > > to demonstrate I'm wrong, which seems like it ought to be easy... But
>> > > just saying "I disagree" and "I don't want to talk about that" isn't
>> > > going to convince anyone.
>>
>> The "some cases" where bip8 with lot=true is *worse* than speedy trial
>> is when miners correctly see that a bad fork is bad.
>>
>> Under *any* other circumstance, when they're used to activate a bad soft
>> fork, speedy trial and bip8 are the same. If a resistance method works
>> against bip8, it works against speedy trial; if it fails against speedy
>> trial, it fails against bip8.
>>
>
> You're wrong.
>
>
>> > Sorry for the aggressive tone, but I when people ignore some of my
>> points
>> > repeteadly, I start to wonder if they do it on purpose.
>>
>> Perhaps examine the beam in your own eye.
>>
>
> Yeah, whether you do that yourself or not: sorry, it's over.
>
>
>> Cheers,
>> aj
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev wrote:
> > Under *any* other circumstance, when they're used to activate a bad soft
> > fork, speedy trial and bip8 are the same. If a resistance method works
> > against bip8, it works against speedy trial; if it fails against speedy
> > trial, it fails against bip8.
> IIRC one essential difference between ST (which is a variant of BIP9) and
> BIP8 is that since there is no mandatory signaling during the lockin
> period, 

BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period. 

> you can't do a counter soft fork as easily.

The "counter" for bip8 activation is to reject any block during either
the started or must_signal phases that would meet the threshold. In that
case someone running bip8 might see blocks:

  [elapsed=2010, count=1813, signal=yes]
  [elapsed=2011, count=1813, signal=no]
  [elapsed=2012, count=1814, signal=yes]
  [elapsed=2013, count=1815, signal=yes, will-lockin!]
  [elapsed=2014, count=1816, signal=yes]
  [elapsed=2015, count=1816, signal=no]
  [elapsed=2016, count=1816, signal=no]
  [locked in!]

But running software to reject the soft fork, you would reject the
elapsed=2013 block, and any blocks that build on it. You would wait for
someone else to mine a chain that looked like:

  [elapsed=2013, count=1814, signal=no]
  [elapsed=2014, count=1814, signal=no]
  [elapsed=2015, count=1814, signal=no]
  [elapsed=2016, count=1814, signal=no]
  [failed!]

That approach works *exactly* the same with speedy trial.

Jeremy's written code that does exactly this using the getdeploymentinfo
rpc to check the deployment status, and the invalidateblock rpc to
reject a block. See: https://github.com/JeremyRubin/forkd

The difference to bip8 with lot=true is that nodes running speedy trial
will reorg to follow the resisting chain if it has the most work. bip8
with lot=true nodes will not reorg to a failing chain, potentially
creating an ongoing chain split, unless one group or the other gives up,
and changes their software.

Cheers,
aj

[0] Semi-mandatory in that only "threshold" blocks must signal, so if
    only 4% or 9% of miners aren't signalling and the threshold is set
    at 95% or 90%, no blocks will be orphaned.

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland]

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

> BIP8 doesn't have mandatory signaling during the lockin period, it has
semi-mandatory [0] signalling during the must_signal period.

Thanks for the clarification.

> Semi-mandatory in that only "threshold" blocks must signal, so if
    only 4% or 9% of miners aren't signalling and the threshold is set
    at 95% or 90%, no blocks will be orphaned.

How do nodes decide on which blocks are orphaned if only some of them have
to signal, and others don't? Is it just any block that would cause the
whole threshold period to fail?

Keagan

On Mon, Apr 25, 2022 at 11:00 AM Anthony Towns <aj@erisian.com.au> wrote:

> On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Under *any* other circumstance, when they're used to activate a bad
> soft
> > > fork, speedy trial and bip8 are the same. If a resistance method works
> > > against bip8, it works against speedy trial; if it fails against speedy
> > > trial, it fails against bip8.
> > IIRC one essential difference between ST (which is a variant of BIP9) and
> > BIP8 is that since there is no mandatory signaling during the lockin
> > period,
>
> BIP8 doesn't have mandatory signaling during the lockin period, it has
> semi-mandatory [0] signalling during the must_signal period.
>
> > you can't do a counter soft fork as easily.
>
> The "counter" for bip8 activation is to reject any block during either
> the started or must_signal phases that would meet the threshold. In that
> case someone running bip8 might see blocks:
>
>   [elapsed=2010, count=1813, signal=yes]
>   [elapsed=2011, count=1813, signal=no]
>   [elapsed=2012, count=1814, signal=yes]
>   [elapsed=2013, count=1815, signal=yes, will-lockin!]
>   [elapsed=2014, count=1816, signal=yes]
>   [elapsed=2015, count=1816, signal=no]
>   [elapsed=2016, count=1816, signal=no]
>   [locked in!]
>
> But running software to reject the soft fork, you would reject the
> elapsed=2013 block, and any blocks that build on it. You would wait for
> someone else to mine a chain that looked like:
>
>   [elapsed=2013, count=1814, signal=no]
>   [elapsed=2014, count=1814, signal=no]
>   [elapsed=2015, count=1814, signal=no]
>   [elapsed=2016, count=1814, signal=no]
>   [failed!]
>
> That approach works *exactly* the same with speedy trial.
>
> Jeremy's written code that does exactly this using the getdeploymentinfo
> rpc to check the deployment status, and the invalidateblock rpc to
> reject a block. See: https://github.com/JeremyRubin/forkd
>
> The difference to bip8 with lot=true is that nodes running speedy trial
> will reorg to follow the resisting chain if it has the most work. bip8
> with lot=true nodes will not reorg to a failing chain, potentially
> creating an ongoing chain split, unless one group or the other gives up,
> and changes their software.
>
> Cheers,
> aj
>
> [0] Semi-mandatory in that only "threshold" blocks must signal, so if
>     only 4% or 9% of miners aren't signalling and the threshold is set
>     at 95% or 90%, no blocks will be orphaned.
>
>

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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns]

On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via bitcoin-dev wrote:
> > Semi-mandatory in that only "threshold" blocks must signal, so if
>     only 4% or 9% of miners aren't signalling and the threshold is set
>     at 95% or 90%, no blocks will be orphaned.
> How do nodes decide on which blocks are orphaned if only some of them have
> to signal, and others don't? Is it just any block that would cause the
> whole threshold period to fail?

Yes, exactly those. See [0] or [1].

[0] https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling

[1] https://github.com/bitcoin/bips/pull/1021
    (err, you apparently acked that PR)

Cheers,
aj

Re: [bitcoin-dev] Speedy Trial

[Erik Aronesty]

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

- it occurs to me that the real problem we have isn't whether miners lead
or users lead.   we know that users lead, we just need miners to be "ready"
and have time to upgrade their software

 - in the case of "evil" forks, i also don't need or want miners to
"defend" bitcoin... (if bitcoin is so broken that a bad fork gets past all
of the users, the miners have lost their purpose, so that is a fallacy of
reification and should be ignored)

 - we cannot measure user consensus in any systematic way, or else we
resort to gaming the system or centralization

    - wallet votes (sign a message signalling... ), can cause
centralization pressures
    - node signals (node published signal) will be sybil attacked
    - eyeballs... (lol)

 - can we all agree that this verbal and social wrangling and chest
pounding seems, right now, to remain the best system of achieving
consensus?  or can we do better?










On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Semi-mandatory in that only "threshold" blocks must signal, so if
> >     only 4% or 9% of miners aren't signalling and the threshold is set
> >     at 95% or 90%, no blocks will be orphaned.
> > How do nodes decide on which blocks are orphaned if only some of them
> have
> > to signal, and others don't? Is it just any block that would cause the
> > whole threshold period to fail?
>
> Yes, exactly those. See [0] or [1].
>
> [0]
> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling
>
> [1] https://github.com/bitcoin/bips/pull/1021
>     (err, you apparently acked that PR)
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

@Erik
>  can we all agree that this verbal and social wrangling and chest
pounding seems, right now, to remain the best system of achieving
consensus?  or can we do better?

I would love to see more people interested in discussing this. Social
wrangling is certainly the best we have, but is it the best we can do?
Certainly a certain amount of discussion and back and forth is necessary to
come to consensus, but it would be nice to have a discussion and come to a
consensus on things like the minimum things required to decided consensus
is for something (the absence of which makes it obvious that consensus is
currently against), and the maximum amount of things required after which
it would be clear and obvious that consensus for something has been
achieved.

> wallet votes (sign a message signalling... ), can cause centralization
pressures

I'm curious to know why you think this is the case. If you mean that
centralization of custody is a problem for this, I very much agree.
However, I don't see how having wallet votes would incentivize
centralization of custody. Rather the opposite actually - one more reason
to self-custody.

Regardless, I wouldn't suggest having wallet *votes* per se. I would doubt
we'd get a high enough response rate on that to really determine what
broader consensus of coin-owners is. However, if we had coin-weighted
polling, it would I think be a very useful signal by which we could
determine something (to some degree of uncertainty) about what consensus is
among that group (of coin owners who take the poll).

Theoretically, the economic majority of bitcoin holders can direct the
majority of mining power, and can control where the current chain goes (of
course not discounting the ability of the economic minority to hard fork
away if they want, taking a proportional minority amount of mining power
with them).

One could also think of it like Polybius's three part government, where the
parts in bitcoin would be: developers, miners, and holders. Perhaps a
consensus among all of them should be ideally sought after for a smooth
upgrade. Because of the blocksize wars, many think miners should simply act
as a machine to implement the will of the bitcoiners. However, I think
people sometimes forget that miners are also bitcoiners and they have a
unique and important perspective. If the opinions and interests of miners
is already adequately considered as part of our chaotic discussions on what
consensus is, then great. If not, it would seem that the miner signaling
process is a reasonable place for miners to decide to delay and force more
discussion. While its unlikely the average user knows much about the
technical aspects of consensus changes, the fact is that there are many
non-developer stakeholders, and it would I think be a very beneficial
achievement to figure out a way to incorporate those stakeholders into the
process of determining consensus on the most important changes to bitcoin:
consensus changes.



On Tue, Apr 26, 2022 at 11:32 AM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> - it occurs to me that the real problem we have isn't whether miners lead
> or users lead.   we know that users lead, we just need miners to be "ready"
> and have time to upgrade their software
>
>  - in the case of "evil" forks, i also don't need or want miners to
> "defend" bitcoin... (if bitcoin is so broken that a bad fork gets past all
> of the users, the miners have lost their purpose, so that is a fallacy of
> reification and should be ignored)
>
>  - we cannot measure user consensus in any systematic way, or else we
> resort to gaming the system or centralization
>
>     - wallet votes (sign a message signalling... ), can cause
> centralization pressures
>     - node signals (node published signal) will be sybil attacked
>     - eyeballs... (lol)
>
>  - can we all agree that this verbal and social wrangling and chest
> pounding seems, right now, to remain the best system of achieving
> consensus?  or can we do better?
>
>
>
>
>
>
>
>
>
>
> On Tue, Apr 26, 2022 at 1:42 AM Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via
>> bitcoin-dev wrote:
>> > > Semi-mandatory in that only "threshold" blocks must signal, so if
>> >     only 4% or 9% of miners aren't signalling and the threshold is set
>> >     at 95% or 90%, no blocks will be orphaned.
>> > How do nodes decide on which blocks are orphaned if only some of them
>> have
>> > to signal, and others don't? Is it just any block that would cause the
>> > whole threshold period to fail?
>>
>> Yes, exactly those. See [0] or [1].
>>
>> [0]
>> https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki#Mandatory_signalling
>>
>> [1] https://github.com/bitcoin/bips/pull/1021
>>     (err, you apparently acked that PR)
>>
>> Cheers,
>> aj
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

Thanks for pointing out that PR @pushd. Looks like pretty good evidence for
what the status of consensus was around BIP8 in the last 2 years.

@Jorge, I tried to engage with you on the topic of activation rules last
year. This is where we left it
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019172.html>.
If I'm being frank, you were not clear about what you advocated for, you
didn't seem to take the time to understand what I was advocating for and
what I was asking you and trying to discuss with you, and you ghosted some
of my questions to you. I think you have some ideas that are important to
consider, but you're quite a bit more difficult to communicate with than
the average bitcoin-dev user, and I'd suggest that if you want your
concerns addressed, you figure out how to interact more constructively with
people on here. You're being very defensive and adversarial. Please take a
step back and try to be more objective. That is IHMO the best way for your
thoughts to be heard and understood.

I think involving users more in activation is a good avenue of thought for
improving how bitcoin does soft forks. I also think the idea you brought up
of some way for people to signal opposition is a good idea. I've suggested
a mechanism for signature-based user polling
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/019022.html>,
I've also suggested a mechanism
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019117.html>
where miners can actively signal for opposing a soft fork. It seems like
there should be some common ground between us in those ideas. Where it
seems we may perhaps unreconcilably disagree are that A. miners are users
too and generally have interests that are important and different than most
users, and giving them at least some mechanism to force discussion is
appropriate, and B. chain splits are no joke and should almost never be
possible accidentally and therefore we should make a significant effort to
avoid them, which almost definitely means orderly coordination of miners.

Do you have anything concrete you want to propose? An example mechanism?
Are you simply here advocating your support for BIP8+LOT=true?


On Fri, Mar 11, 2022 at 7:47 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón <jtimon@jtimon.cc> wrote:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this "faction" and addressed all
>> its concerns, I guess.
>> Or perhaps it's just "prosectution complex", but, hey, what do I know
>> about psychology?
>>
>
> Your accusations of bad faith on the part of myself and pretty much
> everyone else makes me disinclined to continue this discussion with you.
> I'll reply, but if you want me to continue beyond this, then you need to
> knock it off with the accusations.
>
>
>> A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr.  It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling.  That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed.  Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>> Yes, I like this solution too, with a little caveat: an easy mechanism
>> for users to actively oppose a proposal.
>> Luke alao talked about this.
>> If users oppose, they should use activation as a trigger to fork out of
>> the network by invalidating the block that produces activation.
>> The bad scenario here is that miners want to deploy something but users
>> don't want to.
>> "But that may lead to a fork". Yeah, I know.
>> I hope imagining a scenario in which developers propose something that
>> most miners accept but some users reject is not taboo.
>>
>
> This topic is not taboo.
>
> There are a couple of ways of opting out of taproot.  Firstly, users can
> just not use taproot.  Secondly, users can choose to not enforce taproot
> either by running an older version of Bitcoin Core or otherwise forking the
> source code.  Thirdly, if some users insist on a chain where taproot is
> "not activated", they can always softk-fork in their own rule that
> disallows the version bits that complete the Speedy Trial activation
> sequence, or alternatively soft-fork in a rule to make spending from (or
> to) taproot addresses illegal.
>
> As for mark, he wasn't talking about activation, but quantum computing
>> concerns. Perhaps those have been "addressed"?
>> I just don't know where.
>>
>
> Quantum concerns were discussed.  Working from memory, the arguments were
> (1) If you are worried about your funds not being secured by taproot, then
> don't use taproot addresses, and (2) If you are worried about everyone
> else's funds not being quantum secure by other people choosing to use
> taproot, well it is already too late because over 5M BTC is currently
> quantum insecure due to pubkey reuse <
> https://nitter.net/pwuille/status/1108091924404027392>.  I think it is
> unlikely that a quantum breakthrough will sneak up on us without time to
> address the issue and, at the very least, warn people to move their funds
> off of taproot and other reused addresses, if not forking in some quantum
> secure alternative.  A recent paper <
> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>
> suggest that millions physical qubits will be needed to break EC in a day
> with current error correction technology.  But even if taproot were to be
> very suddenly banned, there is still a small possibility for recovery
> because one can prove ownership of HD pubkeys by providing a zero-knowledge
> proof of the chaincode used to derive them.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón]

On Fri, Mar 11, 2022 at 5:32 PM Billy Tetrud via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I think involving users more in activation is a good avenue of thought for improving how bitcoin does soft forks. I also think the idea you brought up of some way for people to signal opposition is a good idea. I've suggested a mechanism for signature-based user polling, I've also suggested a mechanism where miners can actively signal for opposing a soft fork. It seems like there should be some common ground between us in those ideas. Where it seems we may perhaps unreconcilably disagree are that A. miners are users too and generally have interests that are important and different than most users, and giving them at least some mechanism to force discussion is appropriate, and B. chain splits are no joke and should almost never be possible accidentally and therefore we should make a significant effort to avoid them, which almost definitely means orderly coordination of miners.

Any user polling system is going to be vulnerable to sybil attacks.

> Do you have anything concrete you want to propose? An example mechanism? Are you simply here advocating your support for BIP8+LOT=true?

Yes, I want BIP+LOT=true (aka the original bip8).
I also want users to be easily able to coordinate resistance to any
given change, as I described in this thread and others and luke has
done many times.
I also generally oppose to speedy trial being used for any consensus
rule change deployment.

Imagine someone comes and proposes a block size increase through
extension block softfork.
Would you like them to use speedy trial or BIP8+LOT=true for deployment?

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some evidence<https://www.youtube.com/watch?v=U7rXOgL4oFQ>; and present it.

This pull request had some support and a few disagreements: https://archive.fo/uw1cO

pushd
---parallel lines meet at infinity?

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

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> A mechanism of soft-forking against activation exists. What more do you
want? Are we supposed to write the code on behalf of this hypothetical
group of users who may or may not exist for them just so that they can have
a node that remains stalled on Speedy Trial lockin? That simply isn't
reasonable, but if you think it is, I invite you to create such a fork.
I want BIP 8. And less invitations to fork or provoke people.

> If I believe I'm in the economic majority then I'll just refuse to upgrade
my node, which was option 2. I don't know why you dismissed it.

> Not much can prevent a miner cartel from enforcing rules that users don't
want other than hard forking a replacement POW. There is no effective
difference between some developers releasing a malicious soft-fork of
Bitcoin and the miners releasing a malicious version themselves. And when
the miner cartel forms, they aren't necessarily going to be polite enough
to give a transparent signal of their new rules.

Miners get paid irrespective of rules as long as subsidy doesn't change. You can affect their fees, bitcoin and that should be termed as an attack on bitcoin.

> However, without the
economic majority enforcing their set of rules, the cartel continuously
risks falling apart from the temptation of transaction fees of the censored
transactions.

Transaction fee isn't as expected even if we leave censored transactions in a censorship resistant network. If cartel of developers affect it in long term, there will be a time when nobody wants to mine for loss or less profit.

> Look, you cannot have the perfect system of money all by your
lonesome self.

I agree with this and I can't do the same thing with my local government.

pushd
---
parallel lines meet at infinity?

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

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> I've done it in about 40 lines of python:
https://github.com/jeremyrubin/forkd

This python script using `invalidateblock` RPC is an attack on Bitcoin. Just kidding although I won't be surprised if someone writes about it on reddit.

Thanks for writing the script, it will be helpful.

pushd
---
parallel lines meet at infinity?

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

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> 0') someone has come up with a good idea (yay!)
> 1') most of bitcoin is enthusiastically behind the idea
> 2') an enemy of bitcoin is essentially alone in trying to stop it
> 3') almost everyone remains enthusiastic, despite that guy's incoherent raving
> 4') nevertheless, the enemies of bitcoin should have the power to stop
the good idea

How do we know if someone is enemy or not in step 2 and step 4?

why bip 8:

- gives more power to users
- miners signaling is not considered voting
- less politics and controversies

During the taproot activation parameters meeting on 2021-02-16,
participants expressed their preferences with regards to BIP 8's lockinontimeout (LOT) parameter:
https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c

pushd
---
parallel lines meet at infinity?

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

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> Any case where a flawed proposal makes it through getting activation
parameters set and released, but doesn't achieve supermajority hashpowersupport is made worse by bip8/lot=true in comparison to speedy trial.

- Flawed proposal making it through activation is a failure of review process

- Supermajority hashpower percentage decided by bitcoin core developers can choose to not follow old or new consensus rules at any point

- Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated

- BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus rules as they do right now if they wish to mine blocks for subsidy and fees.

Note: Mining pools or individual miners can participate in soft fork discussions regardless of activation method and share their concern which can be evaluated based on technical merits.

pushd
---
parallel lines meet at infinity?

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

@Pushd

> Speedy trial makes it worse by misleading lot of bitcoin users including
miners to consider signaling as voting and majority votes decide if a soft
fork gets activated

No it does not. This narrative is the worst. A bad explanation of speedy
trial can mislead people into thinking miner signalling is how Bitcoin
upgrades are voted in. But a bad explanation can explain anything badly.
The solution is not to change how we engineer soft forks, it's to explain
speedy trial better to this imaginary group of important people that think
miner signaling is voting.

We shouldn't change how we engineer Bitcoin because of optics. I completely
object to that point continuing to be used.

On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Any case where a flawed proposal makes it through getting activation
> parameters set and released, but doesn't achieve supermajority hashpower
> support is made worse by bip8/lot=true in comparison to speedy trial.
>
> - Flawed proposal making it through activation is a failure of review
> process
>
> - Supermajority hashpower percentage decided by bitcoin core developers
> can choose to not follow old or new consensus rules at any point
>
> - Speedy trial makes it worse by misleading lot of bitcoin users including
> miners to consider signaling as voting and majority votes decide if a soft
> fork gets activated
>
> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
> rules as they do right now if they wish to mine blocks for subsidy and fees.
>
>
> Note: Mining pools or individual miners can participate in soft fork
> discussions regardless of activation method and share their concern which
> can be evaluated based on technical merits.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> No it does not. This narrative is the worst. A bad explanation of speedy trial can mislead people into thinking miner signalling is how Bitcoin upgrades are voted in. But a bad explanation can explain anything badly.

I agree it is worst but why do you think this narrative exists? People have tried explaining it. Many users, miners and exchanges still think its voting. I think the problem is with activation method so BIP 8/LOT=TRUE is a solution.

> The solution is not to change how we engineer soft forks, it's to explain speedy trial better to this imaginary group of important people that think miner signaling is voting.

We can suggest different solutions but the problem exists and it is not an imaginary group of people.

One example of a mining pool: https://archive.ph/oyH04

> We shouldn't change how we engineer Bitcoin because of optics. I completely object to that point continuing to be used.

Voting as described on wiki is quite similar to what happens during miners signaling followed by activation if a certain threshold is reached. If some participants in this process consider it voting instead of signaling for readiness then listing advantages of a better activation method should help everyone reading this thread/email.

Sorry, I don't understand your objection. I see a problem that exists since years and a better activation method fixes it. There are other positives for using BIP 8/LOT=TRUE which I shared in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html

I will continue to discuss this problem with solutions until we use better activation methods for future soft forks in any discussion about activation methods.

pushd
---
parallel lines meet at infinity?

------- Original Message -------
On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <billy.tetrud@gmail.com> wrote:

> @Pushd
>
>> Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated
>
> No it does not. This narrative is the worst. A bad explanation of speedy trial can mislead people into thinking miner signalling is how Bitcoin upgrades are voted in. But a bad explanation can explain anything badly. The solution is not to change how we engineer soft forks, it's to explain speedy trial better to this imaginary group of important people that think miner signaling is voting.
>
> We shouldn't change how we engineer Bitcoin because of optics. I completely object to that point continuing to be used.
>
> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>> Any case where a flawed proposal makes it through getting activation
>> parameters set and released, but doesn't achieve supermajority hashpowersupport is made worse by bip8/lot=true in comparison to speedy trial.
>>
>> - Flawed proposal making it through activation is a failure of review process
>>
>> - Supermajority hashpower percentage decided by bitcoin core developers can choose to not follow old or new consensus rules at any point
>>
>> - Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated
>>
>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus rules as they do right now if they wish to mine blocks for subsidy and fees.
>>
>> Note: Mining pools or individual miners can participate in soft fork discussions regardless of activation method and share their concern which can be evaluated based on technical merits.
>>
>> pushd
>> ---
>> parallel lines meet at infinity?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

>  Many users, miners and exchanges still think its voting

Why do you care what they think? Why does it matter if they misunderstand?

> it is not an imaginary group of people

If the people aren't imaginary, then its their importance that's imaginary.

> One example of a mining pool

This isn't even sufficient evidence that they don't understand. Its quite
possible they're using the word "voting" loosely or that they don't
understand english very well. And again, so what if they tweet things that
are not correctly worded? This is not a reason to change how we design
bitcoin soft forks.

Its not even wrong to say that a particular signaling round is very much
like voting. What's wrong is saying that bitcoin upgrades are made if and
only if miners vote to approve those changes.

> I see a problem that exists

You haven't convinced me this is a significant problem. What are the
concrete downsides? Why do you think this can't be fixed by simple
persistent explaining? You can find groups of people who misunderstand
basically any aspect of bitcoin. The solution to people misunderstanding
the design is never to change how bitcoin is designed.


On Wed, Mar 30, 2022 at 4:14 PM pushd <pushd@protonmail.com> wrote:

> > No it does not. This narrative is the worst. A bad explanation of
> speedy trial can mislead people into thinking miner signalling is how
> Bitcoin upgrades are voted in. But a bad explanation can explain anything
> badly.
>
> I agree it is worst but why do you think this narrative exists? People
> have tried explaining it. Many users, miners and exchanges still think its
> voting. I think the problem is with activation method so BIP 8/LOT=TRUE is
> a solution.
>
>
> > The solution is not to change how we engineer soft forks, it's to
> explain speedy trial better to this imaginary group of important people
> that think miner signaling is voting.
>
> We can suggest different solutions but the problem exists and it is not an
> imaginary group of people.
>
> One example of a mining pool: https://archive.ph/oyH04
>
>
> > We shouldn't change how we engineer Bitcoin because of optics. I
> completely object to that point continuing to be used.
>
> Voting as described on wiki is quite similar to what happens during miners
> signaling followed by activation if a certain threshold is reached. If some
> participants in this process consider it voting instead of signaling for
> readiness then listing advantages of a better activation method should help
> everyone reading this thread/email.
>
> Sorry, I don't understand your objection. I see a problem that exists
> since years and a better activation method fixes it. There are other
> positives for using BIP 8/LOT=TRUE which I shared in
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>
> I will continue to discuss this problem with solutions until we use better
> activation methods for future soft forks in any discussion about activation
> methods.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <
> billy.tetrud@gmail.com> wrote:
>
> @Pushd
>
> > Speedy trial makes it worse by misleading lot of bitcoin users
> including miners to consider signaling as voting and majority votes decide
> if a soft fork gets activated
>
> No it does not. This narrative is the worst. A bad explanation of speedy
> trial can mislead people into thinking miner signalling is how Bitcoin
> upgrades are voted in. But a bad explanation can explain anything badly.
> The solution is not to change how we engineer soft forks, it's to explain
> speedy trial better to this imaginary group of important people that think
> miner signaling is voting.
>
> We shouldn't change how we engineer Bitcoin because of optics. I
> completely object to that point continuing to be used.
>
> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > Any case where a flawed proposal makes it through getting activation
>> parameters set and released, but doesn't achieve supermajority hashpower
>> support is made worse by bip8/lot=true in comparison to speedy trial.
>>
>> - Flawed proposal making it through activation is a failure of review
>> process
>>
>> - Supermajority hashpower percentage decided by bitcoin core developers
>> can choose to not follow old or new consensus rules at any point
>>
>> - Speedy trial makes it worse by misleading lot of bitcoin users
>> including miners to consider signaling as voting and majority votes decide
>> if a soft fork gets activated
>>
>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
>> rules as they do right now if they wish to mine blocks for subsidy and fees.
>>
>>
>> Note: Mining pools or individual miners can participate in soft fork
>> discussions regardless of activation method and share their concern which
>> can be evaluated based on technical merits.
>>
>>
>> pushd
>> ---
>>
>> parallel lines meet at infinity?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

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

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> Why do you care what they think? Why does it matter if they misunderstand?

I care about improving soft fork activation mechanism and shared one of the advantages that helps avoid misleading things. It matters because they are participants in this process.

> If the people aren't imaginary, then its their importance that's imaginary.

Neither the people nor their importance is imaginary. They are a part of Bitcoin and as important as our opinion about soft forks on this mailing list.

> This isn't even sufficient evidence that they don't understand.

One example of an exchange: https://i.postimg.cc/zv4M6MSp/2KM5tcE.png

One example of a user: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/

3 examples for each (user, mining pool and exchange) are enough to discuss a problem or list advantages of BIP 8/LOT=TRUE. I can create an archive with more if it helps during next soft fork.

> You haven't convinced me this is a significant problem. What are the concrete downsides? Why do you think this can't be fixed by simple persistent explaining?

I am not trying to convince you and we can have different opinions.

Downsides:

- Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics or influenced by councils such as BMC or governments during signaling

- It is considered as voting not just by people outside Bitcoin but the participants itself

- It gives miners an edge over economic nodes that enforce consensus rules
Simple persistent explaining has not helped in last few years. I don't see anything wrong in listing this as one of the advantages for BIP8/LOT=TRUE.

pushd
---
parallel lines meet at infinity?

------- Original Message -------
On Thursday, March 31st, 2022 at 10:01 AM, Billy Tetrud <billy.tetrud@gmail.com> wrote:

>> Many users, miners and exchanges still think its voting
>
> Why do you care what they think? Why does it matter if they misunderstand?
>
>> it is not an imaginary group of people
>
> If the people aren't imaginary, then its their importance that's imaginary.
>
>> One example of a mining pool
>
> This isn't even sufficient evidence that they don't understand. Its quite possible they're using the word "voting" loosely or that they don't understand english very well. And again, so what if they tweet things that are not correctly worded? This is not a reason to change how we design bitcoin soft forks.
>
> Its not even wrong to say that a particular signaling round is very much like voting. What's wrong is saying that bitcoin upgrades are made if and only if miners vote to approve those changes.
>
>> I see a problem that exists
>
> You haven't convinced me this is a significant problem. What are the concrete downsides? Why do you think this can't be fixed by simple persistent explaining? You can find groups of people who misunderstand basically any aspect of bitcoin. The solution to people misunderstanding the design is never to change how bitcoin is designed.
>
> On Wed, Mar 30, 2022 at 4:14 PM pushd <pushd@protonmail.com> wrote:
>
>>> No it does not. This narrative is the worst. A bad explanation of speedy trial can mislead people into thinking miner signalling is how Bitcoin upgrades are voted in. But a bad explanation can explain anything badly.
>>
>> I agree it is worst but why do you think this narrative exists? People have tried explaining it. Many users, miners and exchanges still think its voting. I think the problem is with activation method so BIP 8/LOT=TRUE is a solution.
>>
>>> The solution is not to change how we engineer soft forks, it's to explain speedy trial better to this imaginary group of important people that think miner signaling is voting.
>>
>> We can suggest different solutions but the problem exists and it is not an imaginary group of people.
>>
>> One example of a mining pool: https://archive.ph/oyH04
>>
>>> We shouldn't change how we engineer Bitcoin because of optics. I completely object to that point continuing to be used.
>>
>> Voting as described on wiki is quite similar to what happens during miners signaling followed by activation if a certain threshold is reached. If some participants in this process consider it voting instead of signaling for readiness then listing advantages of a better activation method should help everyone reading this thread/email.
>>
>> Sorry, I don't understand your objection. I see a problem that exists since years and a better activation method fixes it. There are other positives for using BIP 8/LOT=TRUE which I shared in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>>
>> I will continue to discuss this problem with solutions until we use better activation methods for future soft forks in any discussion about activation methods.
>>
>> pushd
>> ---
>> parallel lines meet at infinity?
>>
>> ------- Original Message -------
>> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <billy.tetrud@gmail.com> wrote:
>>
>>> @Pushd
>>>
>>>> Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated
>>>
>>> No it does not. This narrative is the worst. A bad explanation of speedy trial can mislead people into thinking miner signalling is how Bitcoin upgrades are voted in. But a bad explanation can explain anything badly. The solution is not to change how we engineer soft forks, it's to explain speedy trial better to this imaginary group of important people that think miner signaling is voting.
>>>
>>> We shouldn't change how we engineer Bitcoin because of optics. I completely object to that point continuing to be used.
>>>
>>> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>>> Any case where a flawed proposal makes it through getting activation
>>>> parameters set and released, but doesn't achieve supermajority hashpowersupport is made worse by bip8/lot=true in comparison to speedy trial.
>>>>
>>>> - Flawed proposal making it through activation is a failure of review process
>>>>
>>>> - Supermajority hashpower percentage decided by bitcoin core developers can choose to not follow old or new consensus rules at any point
>>>>
>>>> - Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated
>>>>
>>>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus rules as they do right now if they wish to mine blocks for subsidy and fees.
>>>>
>>>> Note: Mining pools or individual miners can participate in soft fork discussions regardless of activation method and share their concern which can be evaluated based on technical merits.
>>>>
>>>> pushd
>>>> ---
>>>> parallel lines meet at infinity?
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud]

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

> I am not trying to convince you

 If that's really true then you're wasting my and everyone's time here.

> Signaling period is a waste of time if mining pools that agreed on a soft
fork earlier do politics

They can and will do politics regardless of why misunderstandings about
signaling. This is not a relevant point.

> It is considered as voting not just by people outside Bitcoin but the
participants itself

This is not a concrete downside. You are simply restating the premise.

> It gives miners an edge over economic nodes that enforce consensus rules

This is completely false. I have to assume you don't include yourself in
the list of users who think a passing vote of miners is required to upgrade
Bitcoin. Am I wrong? If not, then you should know that this
misunderstanding gives no one an edge.

So I'm counting 0 concrete downsides of this misunderstanding of how
signaling works that are both relevant and true. I'm going to stick with my
conclusion that this is a pointless dead end argument to make about soft
fork deployment in particular, and literally any technical design in
general.

You will be able to find 3 people who misunderstand BIP8, or literally any
other thing you come up with. You could probably find thousands. Or
millions if you ask people who've never heard of it. The argument that
changing the design will somehow improve that situation is perplexing, but
the argument that changing the idea might be a good idea on that basis is
completely unconscionable.


On Thu, Mar 31, 2022, 09:19 pushd <pushd@protonmail.com> wrote:

> > Why do you care what they think? Why does it matter if they
> misunderstand?
>
> I care about improving soft fork activation mechanism and shared one of
> the advantages that helps avoid misleading things. It matters because they
> are participants in this process.
>
>
> > If the people aren't imaginary, then its their importance that's
> imaginary.
>
> Neither the people nor their importance is imaginary. They are a part of
> Bitcoin and as important as our opinion about soft forks on this mailing
> list.
>
>
> > This isn't even sufficient evidence that they don't understand.
>
> One example of an exchange: https://i.postimg.cc/zv4M6MSp/2KM5tcE.png
>
> One example of a user:
> https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/
>
> 3 examples for each (user, mining pool and exchange) are enough to discuss
> a problem or list advantages of BIP 8/LOT=TRUE. I can create an archive
> with more if it helps during next soft fork.
>
>
> > You haven't convinced me this is a significant problem. What are the
> concrete downsides? Why do you think this can't be fixed by simple
> persistent explaining?
>
> I am not trying to convince you and we can have different opinions.
>
> Downsides:
>
> - Signaling period is a waste of time if mining pools that agreed on a
> soft fork earlier do politics or influenced by councils such as BMC or
> governments during signaling
>
> - It is considered as voting not just by people outside Bitcoin but the
> participants itself
>
> - It gives miners an edge over economic nodes that enforce consensus rules
>
> Simple persistent explaining has not helped in last few years. I don't see
> anything wrong in listing this as one of the advantages for BIP8/LOT=TRUE.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Thursday, March 31st, 2022 at 10:01 AM, Billy Tetrud <
> billy.tetrud@gmail.com> wrote:
>
> > Many users, miners and exchanges still think its voting
>
> Why do you care what they think? Why does it matter if they misunderstand?
>
> > it is not an imaginary group of people
>
> If the people aren't imaginary, then its their importance that's imaginary.
>
> > One example of a mining pool
>
> This isn't even sufficient evidence that they don't understand. Its quite
> possible they're using the word "voting" loosely or that they don't
> understand english very well. And again, so what if they tweet things that
> are not correctly worded? This is not a reason to change how we design
> bitcoin soft forks.
>
> Its not even wrong to say that a particular signaling round is very much
> like voting. What's wrong is saying that bitcoin upgrades are made if and
> only if miners vote to approve those changes.
>
> > I see a problem that exists
>
> You haven't convinced me this is a significant problem. What are the
> concrete downsides? Why do you think this can't be fixed by simple
> persistent explaining? You can find groups of people who misunderstand
> basically any aspect of bitcoin. The solution to people misunderstanding
> the design is never to change how bitcoin is designed.
>
>
> On Wed, Mar 30, 2022 at 4:14 PM pushd <pushd@protonmail.com> wrote:
>
>> > No it does not. This narrative is the worst. A bad explanation of
>> speedy trial can mislead people into thinking miner signalling is how
>> Bitcoin upgrades are voted in. But a bad explanation can explain anything
>> badly.
>>
>> I agree it is worst but why do you think this narrative exists? People
>> have tried explaining it. Many users, miners and exchanges still think its
>> voting. I think the problem is with activation method so BIP 8/LOT=TRUE is
>> a solution.
>>
>>
>> > The solution is not to change how we engineer soft forks, it's to
>> explain speedy trial better to this imaginary group of important people
>> that think miner signaling is voting.
>>
>> We can suggest different solutions but the problem exists and it is not
>> an imaginary group of people.
>>
>> One example of a mining pool: https://archive.ph/oyH04
>>
>>
>> > We shouldn't change how we engineer Bitcoin because of optics. I
>> completely object to that point continuing to be used.
>>
>> Voting as described on wiki is quite similar to what happens during
>> miners signaling followed by activation if a certain threshold is reached.
>> If some participants in this process consider it voting instead of
>> signaling for readiness then listing advantages of a better activation
>> method should help everyone reading this thread/email.
>>
>> Sorry, I don't understand your objection. I see a problem that exists
>> since years and a better activation method fixes it. There are other
>> positives for using BIP 8/LOT=TRUE which I shared in
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>>
>> I will continue to discuss this problem with solutions until we use
>> better activation methods for future soft forks in any discussion about
>> activation methods.
>>
>>
>> pushd
>> ---
>>
>> parallel lines meet at infinity?
>>
>> ------- Original Message -------
>> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <
>> billy.tetrud@gmail.com> wrote:
>>
>> @Pushd
>>
>> > Speedy trial makes it worse by misleading lot of bitcoin users
>> including miners to consider signaling as voting and majority votes decide
>> if a soft fork gets activated
>>
>> No it does not. This narrative is the worst. A bad explanation of speedy
>> trial can mislead people into thinking miner signalling is how Bitcoin
>> upgrades are voted in. But a bad explanation can explain anything badly.
>> The solution is not to change how we engineer soft forks, it's to explain
>> speedy trial better to this imaginary group of important people that think
>> miner signaling is voting.
>>
>> We shouldn't change how we engineer Bitcoin because of optics. I
>> completely object to that point continuing to be used.
>>
>> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> > Any case where a flawed proposal makes it through getting activation
>>> parameters set and released, but doesn't achieve supermajority hashpower
>>> support is made worse by bip8/lot=true in comparison to speedy trial.
>>>
>>> - Flawed proposal making it through activation is a failure of review
>>> process
>>>
>>> - Supermajority hashpower percentage decided by bitcoin core developers
>>> can choose to not follow old or new consensus rules at any point
>>>
>>> - Speedy trial makes it worse by misleading lot of bitcoin users
>>> including miners to consider signaling as voting and majority votes decide
>>> if a soft fork gets activated
>>>
>>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
>>> rules as they do right now if they wish to mine blocks for subsidy and fees.
>>>
>>>
>>> Note: Mining pools or individual miners can participate in soft fork
>>> discussions regardless of activation method and share their concern which
>>> can be evaluated based on technical merits.
>>>
>>>
>>> pushd
>>> ---
>>>
>>> parallel lines meet at infinity?
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>

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

Re: [bitcoin-dev] Speedy Trial

[pushd]

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

> If that's really true then you're wasting my and everyone's time here.

It isn't waste of time but important for everyone to understand different opinions about soft fork activations before moving to next soft fork.

The reason I am not trying to convince you or others but sharing my opinion: https://www.vox.com/science-and-health/2016/12/28/14088992/brain-study-change-minds

> This is completely false. I have to assume you don't include yourself in the list of users who think a passing vote of miners is required to upgrade Bitcoin. Am I wrong? If not, then you should know that this misunderstanding gives no one an edge.

It is not false because it has been misused by mining pools in past so provides an edge to delay things and create contentious environment.

> You will be able to find 3 people who misunderstand BIP8, or literally any other thing you come up with.
Sorry, I cannot ignore things or live in denial at least when we have better alternatives for activation available.

pushd
---
parallel lines meet at infinity?

------- Original Message -------
On Thursday, March 31st, 2022 at 9:04 PM, Billy Tetrud <billy.tetrud@gmail.com> wrote:

>> I am not trying to convince you
>
> If that's really true then you're wasting my and everyone's time here.
>
>> Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics
>
> They can and will do politics regardless of why misunderstandings about signaling. This is not a relevant point.
>
>> It is considered as voting not just by people outside Bitcoin but the participants itself
>
> This is not a concrete downside. You are simply restating the premise.
>
>> It gives miners an edge over economic nodes that enforce consensus rules
>
> This is completely false. I have to assume you don't include yourself in the list of users who think a passing vote of miners is required to upgrade Bitcoin. Am I wrong? If not, then you should know that this misunderstanding gives no one an edge.
>
> So I'm counting 0 concrete downsides of this misunderstanding of how signaling works that are both relevant and true. I'm going to stick with my conclusion that this is a pointless dead end argument to make about soft fork deployment in particular, and literally any technical design in general.
>
> You will be able to find 3 people who misunderstand BIP8, or literally any other thing you come up with. You could probably find thousands. Or millions if you ask people who've never heard of it. The argument that changing the design will somehow improve that situation is perplexing, but the argument that changing the idea might be a good idea on that basis is completely unconscionable.
>
> On Thu, Mar 31, 2022, 09:19 pushd <pushd@protonmail.com> wrote:
>
>>> Why do you care what they think? Why does it matter if they misunderstand?
>>
>> I care about improving soft fork activation mechanism and shared one of the advantages that helps avoid misleading things. It matters because they are participants in this process.
>>
>>> If the people aren't imaginary, then its their importance that's imaginary.
>>
>> Neither the people nor their importance is imaginary. They are a part of Bitcoin and as important as our opinion about soft forks on this mailing list.
>>
>>> This isn't even sufficient evidence that they don't understand.
>>
>> One example of an exchange: https://i.postimg.cc/zv4M6MSp/2KM5tcE.png
>>
>> One example of a user: https://bitcoin.stackexchange.com/questions/97043/is-there-an-active-list-of-bips-currently-open-for-voting/
>>
>> 3 examples for each (user, mining pool and exchange) are enough to discuss a problem or list advantages of BIP 8/LOT=TRUE. I can create an archive with more if it helps during next soft fork.
>>
>>> You haven't convinced me this is a significant problem. What are the concrete downsides? Why do you think this can't be fixed by simple persistent explaining?
>>
>> I am not trying to convince you and we can have different opinions.
>>
>> Downsides:
>>
>> - Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics or influenced by councils such as BMC or governments during signaling
>>
>> - It is considered as voting not just by people outside Bitcoin but the participants itself
>>
>> - It gives miners an edge over economic nodes that enforce consensus rules
>> Simple persistent explaining has not helped in last few years. I don't see anything wrong in listing this as one of the advantages for BIP8/LOT=TRUE.
>>
>> pushd
>> ---
>> parallel lines meet at infinity?
>>
>> ------- Original Message -------
>> On Thursday, March 31st, 2022 at 10:01 AM, Billy Tetrud <billy.tetrud@gmail.com> wrote:
>>
>>>> Many users, miners and exchanges still think its voting
>>>
>>> Why do you care what they think? Why does it matter if they misunderstand?
>>>
>>>> it is not an imaginary group of people
>>>
>>> If the people aren't imaginary, then its their importance that's imaginary.
>>>
>>>> One example of a mining pool
>>>
>>> This isn't even sufficient evidence that they don't understand. Its quite possible they're using the word "voting" loosely or that they don't understand english very well. And again, so what if they tweet things that are not correctly worded? This is not a reason to change how we design bitcoin soft forks.
>>>
>>> Its not even wrong to say that a particular signaling round is very much like voting. What's wrong is saying that bitcoin upgrades are made if and only if miners vote to approve those changes.
>>>
>>>> I see a problem that exists
>>>
>>> You haven't convinced me this is a significant problem. What are the concrete downsides? Why do you think this can't be fixed by simple persistent explaining? You can find groups of people who misunderstand basically any aspect of bitcoin. The solution to people misunderstanding the design is never to change how bitcoin is designed.
>>>
>>> On Wed, Mar 30, 2022 at 4:14 PM pushd <pushd@protonmail.com> wrote:
>>>
>>>>> No it does not. This narrative is the worst. A bad explanation of speedy trial can mislead people into thinking miner signalling is how Bitcoin upgrades are voted in. But a bad explanation can explain anything badly.
>>>>
>>>> I agree it is worst but why do you think this narrative exists? People have tried explaining it. Many users, miners and exchanges still think its voting. I think the problem is with activation method so BIP 8/LOT=TRUE is a solution.
>>>>
>>>>> The solution is not to change how we engineer soft forks, it's to explain speedy trial better to this imaginary group of important people that think miner signaling is voting.
>>>>
>>>> We can suggest different solutions but the problem exists and it is not an imaginary group of people.
>>>>
>>>> One example of a mining pool: https://archive.ph/oyH04
>>>>
>>>>> We shouldn't change how we engineer Bitcoin because of optics. I completely object to that point continuing to be used.
>>>>
>>>> Voting as described on wiki is quite similar to what happens during miners signaling followed by activation if a certain threshold is reached. If some participants in this process consider it voting instead of signaling for readiness then listing advantages of a better activation method should help everyone reading this thread/email.
>>>>
>>>> Sorry, I don't understand your objection. I see a problem that exists since years and a better activation method fixes it. There are other positives for using BIP 8/LOT=TRUE which I shared in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html
>>>>
>>>> I will continue to discuss this problem with solutions until we use better activation methods for future soft forks in any discussion about activation methods.
>>>>
>>>> pushd
>>>> ---
>>>> parallel lines meet at infinity?
>>>>
>>>> ------- Original Message -------
>>>> On Thursday, March 31st, 2022 at 1:40 AM, Billy Tetrud <billy.tetrud@gmail.com> wrote:
>>>>
>>>>> @Pushd
>>>>>
>>>>>> Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated
>>>>>
>>>>> No it does not. This narrative is the worst. A bad explanation of speedy trial can mislead people into thinking miner signalling is how Bitcoin upgrades are voted in. But a bad explanation can explain anything badly. The solution is not to change how we engineer soft forks, it's to explain speedy trial better to this imaginary group of important people that think miner signaling is voting.
>>>>>
>>>>> We shouldn't change how we engineer Bitcoin because of optics. I completely object to that point continuing to be used.
>>>>>
>>>>> On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>
>>>>>>> Any case where a flawed proposal makes it through getting activation
>>>>>> parameters set and released, but doesn't achieve supermajority hashpowersupport is made worse by bip8/lot=true in comparison to speedy trial.
>>>>>>
>>>>>> - Flawed proposal making it through activation is a failure of review process
>>>>>>
>>>>>> - Supermajority hashpower percentage decided by bitcoin core developers can choose to not follow old or new consensus rules at any point
>>>>>>
>>>>>> - Speedy trial makes it worse by misleading lot of bitcoin users including miners to consider signaling as voting and majority votes decide if a soft fork gets activated
>>>>>>
>>>>>> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus rules as they do right now if they wish to mine blocks for subsidy and fees.
>>>>>>
>>>>>> Note: Mining pools or individual miners can participate in soft fork discussions regardless of activation method and share their concern which can be evaluated based on technical merits.
>>>>>>
>>>>>> pushd
>>>>>> ---
>>>>>> parallel lines meet at infinity?
>>>>>> _______________________________________________
>>>>>> bitcoin-dev mailing list
>>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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