Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-26 📝 Original message:- it occurs to me that the ...
📅 Original date posted:2022-04-26
📝 Original message:- 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/6648cced/attachment-0001.html>;
📝 Original message:- 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220426/6648cced/attachment-0001.html>;