Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[Erik Aronesty via bitcoin-dev]

- 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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland via bitcoin-dev]

> 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  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.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

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.

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

Re: [bitcoin-dev] Speedy Trial

[Keagan McClelland via bitcoin-dev]

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  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
>
___
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 via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns  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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

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

___
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 via bitcoin-dev]

On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> 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  
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 
>  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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

@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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> 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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

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

___
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 via bitcoin-dev]

On Sat, Mar 26, 2022, 01:45 Anthony Towns  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.



> 

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> 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?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

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

___
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 via bitcoin-dev]

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  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  wrote:
> > > On Fri, Mar 11, 2022 at 02:04:29PM +, 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 

Re: [bitcoin-dev] Speedy Trial

[Kate Salazar via bitcoin-dev]

Hey

On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
 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 
>  wrote:
>>
>> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón  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 

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

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  wrote:
> > On Fri, Mar 11, 2022 at 02:04:29PM +, 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 

Re: [bitcoin-dev] Speedy Trial

[vjudeu via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[Eric Voskuil via bitcoin-dev]

> > 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

>  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  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 " 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 " 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. 

Re: [bitcoin-dev] Speedy Trial

[vjudeu via bitcoin-dev]

> 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 
" 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 " 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 
 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, 

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[vjudeu via bitcoin-dev]

> A. Every pollee signs messages like  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 " 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 
 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  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 

Re: [bitcoin-dev] Speedy Trial

[ZmnSCPxj via bitcoin-dev]

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  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
___
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 via bitcoin-dev]

On Tue, Mar 15, 2022 at 6:25 PM Jeremy Rubin via bitcoin-dev
 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

@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  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
>  wrote:
> >
> > On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón  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 

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> 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?___
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 via bitcoin-dev]

On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns  wrote:
>
> On Fri, Mar 11, 2022 at 02:04:29PM +, 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 

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
 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.
___
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 via bitcoin-dev]

On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
 wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón  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

[Jorge Timón via bitcoin-dev]

On Fri, Mar 11, 2022 at 5:32 PM Billy Tetrud via bitcoin-dev
 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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

@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

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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Jeremy Rubin via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[Anthony Towns via bitcoin-dev]

On Fri, Mar 11, 2022 at 02:04:29PM +, 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 

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

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

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> 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?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Russell O'Connor via bitcoin-dev]

On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón  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

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

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
.
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
,
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.

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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

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  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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Speedy Trial

[Russell O'Connor via bitcoin-dev]

On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón  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

Re: [bitcoin-dev] Speedy Trial

[Jorge Timón via bitcoin-dev]

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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[pushd via bitcoin-dev]

> Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some 
evidence; and present it.

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

pushd
---parallel lines meet at infinity?___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Billy Tetrud via bitcoin-dev]

>  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
 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Speedy Trial

[Luke Dashjr via bitcoin-dev]

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