Re: [bitcoin-dev] Speedy Trial

From: pushd <pushd@protonmail•com>
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Speedy Trial
Date: Wed, 30 Mar 2022 21:14:16 +0000	[thread overview]
Message-ID: <D908viKzD2oAEvIxutANq_OUQ1izhkDvUEb1lybk1Qg1EAyqyGi0FrLICo6VwGr8lAW3IlSUIw3MOKG8S0yvmwexkQ91Ych8sctJ0qkfnvI=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDYCVq-15d-hwMWGs=WoG7=7n7zR-pUrx9ANNpYb5z-31A@mail.gmail.com>

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

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

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

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

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

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

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

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

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

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

pushd
---
parallel lines meet at infinity?

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

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

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