public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Billy Tetrud <billy.tetrud@gmail•com>
To: Erik Aronesty <erik@q32•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: Anthony Towns <aj@erisian•com.au>
Subject: Re: [bitcoin-dev] Speedy Trial
Date: Tue, 26 Apr 2022 21:35:49 -0500	[thread overview]
Message-ID: <CAGpPWDY0H2d8wMyY+X1fFOtn0aKLi_+2BT8AoDS0+Yae+-8EEg@mail.gmail.com> (raw)
In-Reply-To: <CAJowKg+HM6Z44rOVrS0_g=GdzWPZVwggxgQYGPTBrZDir5W4Hw@mail.gmail.com>

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

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

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

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

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

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

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

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



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

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

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

  reply	other threads:[~2022-04-27  2:36 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2022-03-11 16:26     ` Billy Tetrud
2022-03-17 11:32       ` Jorge Timón
2022-03-11 11:14 pushd
2022-03-12 17:11 pushd
2022-03-17 14:34 pushd
2022-03-26 12:59 pushd
2022-03-30 10:34 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
2022-03-31 15:34         ` Billy Tetrud
2022-03-31 15:55           ` pushd

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=CAGpPWDY0H2d8wMyY+X1fFOtn0aKLi_+2BT8AoDS0+Yae+-8EEg@mail.gmail.com \
    --to=billy.tetrud@gmail$(echo .)com \
    --cc=aj@erisian$(echo .)com.au \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=erik@q32$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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