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] Improving RBF Policy

[Billy Tetrud via bitcoin-dev]

Hi Gloria,

>  1. Transaction relay rate limiting

I have a similar concern as yours, that this could prevent higher fee-rate
transactions from being broadcast.

> 2. Staggered broadcast of replacement transactions: within some time
interval, maybe accept multiple replacements for the same prevout, but only
relay the original transaction.

By this do you mean basically having a batching window where, on receiving
a replacement transaction, a node will wait for a period of time,
potentially receiving many replacements for the same transaction (or many
separate conflicting transactions), and only broadcasting the "best" one(s)
at the end of that time window?

Its an interesting idea, but it would produce a problem. Every hop that
replacement transaction takes would be delayed by this staggered window. If
the window were 3 minutes and transactions generally take 20 hops to get to
the majority of miners, a "best-case average" delay might be 3.75 minutes
(noting that among your 8 nodes, its quite likely one of them would have a
window ending much sooner than 3 minutes). Some (maybe 3% of) nodes would
experience delays of more than 20 minutes. That kind of delay isn't great.

However it made me think of another idea: a transaction replacement
broadcast cooldown. What if nodes kept track of the time they broadcasted
the last replacement for a package and had a relay cooldown after the last
replacement was broadcasted? A node receiving a replacement would relay the
replacement immediately if the package its replacing was broadcasted more
than X seconds ago, and otherwise it would wait until the time when that
package was broadcasted at least X seconds ago to broadcast it. Any
replacements it receives during that waiting period would replace as
normal, meaning the unrebroadcasted replacement would never be
broadcasted, and only the highest value replacement would be broadcasted at
the end of the cooldown.

This wouldn't prevent a higher-fee-rate transaction from being broadcasted
(like rate limiting could), but would still be effective at limiting
unnecessary data transmission. Another benefit is that in the
non-adversarial case, replacement transactions wouldn't be subject to any
delay at all (while in the staggered broadcast idea, most replacements
would experience some delay). And in the adversarial case, where a
malicious actor broadcasts a low-as-possible-value replacement just before
yours, the worst case delay is just whatever the cooldown period is. I
would imagine that maybe 1 minute would be a reasonable worst-case delay.
This would limit spam for a transaction that makes it into a block to ~10x
(9 to 1). I don't see much of a downside to doing this beyond just the
slight additional complexity of relay rules (and considering it could save
substantial additional code complexity, even that is a benefit).

All a node would need to do is keep a timestamp on each transaction they
receive for when it was broadcasted and check it when a replacement comes
in. If now-broadcastDate < cooldown, set a timer for cooldown -
(now-broadcastDate) to broadcast it. If another replacement comes in, clear
that timer and repeat using the original broadcast date (since the
unbroadcast transaction doesn't have a broadcast date yet).

I think it might also be useful to note that eliminating "extra data"
caused by careless or malicious actors (spam or whatever you want to call
it) should not be the goal. It is impossible to prevent all spam. What we
should be aiming for is more specific: we should attempt to design a system
where spam is manageable. Eg if our goal is to ensure that a bitcoin node
uses no more than 10% of the bandwidth of a "normal" user, if current
non-spam traffic only requires 1% of a "normal" users's bandwidth, then the
network can bear a 9 to 1 ratio of spam. When a node spins up, there is a
lot more data to download and process. So we know that all full nodes can
handle at least as much traffic as they handle during IBD. What's the
difference between those amounts? I'm not sure, but I would guess that IBD
is at least a couple times more demanding than a fully synced node. So I
might suggest that as long as spam can be kept below a ratio of maybe 2 to
1, we should consider the design acceptable (and therefore more complexity
unnecessary).

The 1 minute broadcast cooldown I mentioned before wouldn't be quite
sufficient to achieve that ratio. But a 3.33 minute cooldown would be.
Whether this is "too much" is something that would have to be discussed, I
suspect a worst-case adversarial 3.33 minute delay would not be "too much".
Doing this could basically eliminate any risk of actual service denial via
replacement transactions.

However, I do think that these DOS concerns are quite overblown. I wrote up a
comment on your rbf-improvements.md

detailing
my thought process on that. The summary is that as 

Re: [bitcoin-dev] Jets (Was: `OP_FOLD`: A Looping Construct For Bitcoin SCRIPT)

[Billy Tetrud via bitcoin-dev]

> I think we would want to have a cleanstack rule at some point

Ah is this a rule where a script shouldn't validate if more than just a
true is left on the stack? I can see how that would prevent the
non-soft-fork version of what I'm proposing.

> How large is the critical mass needed?

Well it seems we've agreed that were we going to do this, we would want to
at least do a soft-fork to make known jet scripts lighter weight (and
unknown jet scripts not-heavier) than their non-jet counterparts. So given
a situation where this soft fork happens, and someone wants to implement a
new jet, how much critical mass would be needed for the network to get some
benefit from the jet? Well, the absolute minimum for some benefit to happen
is that two nodes that support that jet are connected. In such a case, one
node can send that jet scripted transaction along without sending the data
of what the jet stands for. The jet itself is pretty small, like 2 or so
bytes. So that does impose a small additional cost on nodes that don't
support a jet. For 100,000 nodes, that means 200,000 bytes of transmission
would need to be saved for a jet to break even. So if the jet stands for a
22 byte script, it would break even when 10% of the network supported it.
If the jet stood for a 102 byte script, it would break even when 2% of the
network supported it. So how much critical mass is necessary for it to be
worth it depends on what the script is.

>  Than using a dynamic lookup table, which is how I understood your
previous email about "scripts in the 1000 past blocks".

Ah, I didn't mean using a dynamic lookup. This was about the idea of jet
registration, where registered jets would be kept a count of for some
number of blocks (eg 1000) and dropped if they don't reach a threshold rate
of usage. A static lookup table would work for this, I agree.

> It would have to validate as well that the SCRIPT sub-section matches the
jet

Seems like a good idea.

> Adler32 seems a bit short though

You might be right. Certainly some more care would need to be taken in an
actual implementation than I've taken writing my back of the napkin idea
out ; )

> nothing prevents anyone from using a different SCRIPT subsection for a
particular Adler32 hash if they find a collision and can somehow convince
people to run their modified software.

Someone that can convince people to run their modified software can
*always* cause those people to chainsplit from the main chain, so I don't
think the above ideas are special in this regard.

>> it might not be worth doing it this way without a soft fork
> Which is why I pointed out that each individual jet may very well require
a softfork, or enough buy-in that you might as well just softfork.

I'm saying something rather different actually. I don't think each
individual jet requires a softfork to be quite useful. What I meant by "it
might not be worth doing it this way without a soft fork" is that we
probably want to implement a soft fork to allow all jet scripts to have
reduced blockweight. However, once most nodes support that soft fork, new
individual jets do not need a softfork for the network to take advantage of
them. As I mused about above, even 10% of the network supporting a jet
standin for a medium length script could result in significant network
bandwidth savings. Different sections of the network could decide
individually what jets they want to support without needing the usual chaos
of a soft fork for each one, but of course the more the better for a
popular jet. There would be benefits for eventually soft forking such jets
in (to make them weigh even less based on implementation of optimized
validation functions), and real life usage of those jets could inform the
decisions around them. They could already be well tested in the wild before
being upgraded in a softfork.

> Yes, but that implies additional operations (and execution overhead),
increasing the costs to use jets, which makes it even less palatable to use
jets, *in addition to* the witness hack disincentivizing jets.

For the use of a single jet, this can be completely solved by that jet. All
the additional operations you're talking about only need to happen in a
general bitcoin script evaluator. But a jet evaluator can be hand optimized
for that jet, which could operate in exactly the the function-like way you
suggested, because it would actually be a function, under the hood.

> this helps jets compose more easily; if we want a SCRIPT that
incorporates an existing jet, we do not have to manipulate the stack in a
way that the existing jet expects, we just load the proper data into the
constants table.

I think I see what you're saying about multiple jets composing together
easily. I think your idea about loading constants from their initial
positions has merit - basically function arguments that you can reference
by position rather than needing to arrange them in the right order on the
stack. Such is the existence of a stack-based 

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