public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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: Thu, 31 Mar 2022 14:19:36 +0000	[thread overview]
Message-ID: <ewwe4V1o9Vhw3O3L6h8Eolcr16ilAewpxRsHEMC_VNllnfut7uHeQgSjA4ghapjo6QbBO9fDk8dk16w3FBfGI3ds7Y3J-38mZ4ydKg9T7Oo=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDbTfW3fTO1K=aFj1vUym5zbDes8DgifqLHUGCCV7Vgh4g@mail.gmail.com>

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

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

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

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

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

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

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

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

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

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

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

Downsides:

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

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

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

pushd
---
parallel lines meet at infinity?

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

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

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

  reply	other threads:[~2022-03-31 14:19 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 10:34 [bitcoin-dev] Speedy Trial pushd
2022-03-30 20:10 ` Billy Tetrud
2022-03-30 21:14   ` pushd
2022-03-31  4:31     ` Billy Tetrud
2022-03-31 14:19       ` pushd [this message]
2022-03-31 15:34         ` Billy Tetrud
2022-03-31 15:55           ` pushd
  -- strict thread matches above, loose matches on Subject: below --
2022-03-26 12:59 pushd
2022-03-17 14:34 pushd
2022-03-12 17:11 pushd
2022-03-11 11:14 pushd
2022-03-11  0:12 Russell O'Connor
2022-03-11  0:28 ` Luke Dashjr
2022-03-11  5:41   ` Billy Tetrud
2022-03-11 12:19 ` Jorge Timón
2022-03-11 13:47   ` Russell O'Connor
2022-03-11 14:04     ` Jorge Timón
2022-03-12 13:34       ` Russell O'Connor
2022-03-12 17:52         ` Billy Tetrud
2022-03-17 12:18           ` Jorge Timón
2022-03-23 22:34           ` Kate Salazar
2022-03-15 17:21         ` Jeremy Rubin
2022-03-17  4:17           ` Billy Tetrud
2022-03-18 18:36           ` Jorge Timón
2022-03-17 12:08         ` Jorge Timón
2022-03-17 15:38           ` Billy Tetrud
2022-03-18 23:01             ` ZmnSCPxj
2022-03-21  3:41               ` Billy Tetrud
2022-03-21 15:56                 ` vjudeu
2022-03-22 15:19                   ` Billy Tetrud
2022-03-22 15:45                     ` Eric Voskuil
2022-03-22 16:37                     ` vjudeu
2022-03-19 16:43             ` vjudeu
2022-03-15 15:45       ` Anthony Towns
2022-03-17 14:04         ` Jorge Timón
2022-03-22 23:49           ` Anthony Towns
2022-03-24 18:30             ` Jorge Timón
2022-03-26  1:45               ` Anthony Towns
2022-03-28  8:31                 ` Jorge Timón
2022-03-30  4:21                   ` Anthony Towns
2022-04-08  9:58                     ` Jorge Timón
2022-04-11 13:05                       ` Anthony Towns
2022-04-24 11:13                         ` Jorge Timón
2022-04-24 12:14                           ` Anthony Towns
2022-04-24 12:44                             ` Jorge Timón
2022-04-25 16:11                               ` Keagan McClelland
2022-04-25 17:00                                 ` Anthony Towns
2022-04-25 17:26                                   ` Keagan McClelland
2022-04-26  5:42                                     ` Anthony Towns
2022-04-26 13:05                                       ` Erik Aronesty
2022-04-27  2:35                                         ` Billy Tetrud
2022-03-11 16:26     ` Billy Tetrud
2022-03-17 11:32       ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ewwe4V1o9Vhw3O3L6h8Eolcr16ilAewpxRsHEMC_VNllnfut7uHeQgSjA4ghapjo6QbBO9fDk8dk16w3FBfGI3ds7Y3J-38mZ4ydKg9T7Oo=@protonmail.com' \
    --to=pushd@protonmail.com \
    --cc=aj@erisian.com.au \
    --cc=billy.tetrud@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox