David A. Harding [ARCHIVE] on Nostr: đź“… Original date posted:2021-02-13 đź“ť Original message:On Fri, Feb 05, 2021 at ...
đź“… Original date posted:2021-02-13
đź“ť Original message:On Fri, Feb 05, 2021 at 12:43:57PM +0000, Michael Folkson via bitcoin-dev wrote:
> https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
> [...]
> F6) It is more important that no rules that harm users are deployed
> than it is that new useful rules are deployed quickly. If there is a
> choice between “faster” and “more clear that this isn’t a mechanism to
> force bad things on users” we should prefer the latter. Plenty of
> people just don’t like LOT=true very much absent evidence that miners
> are blocking deployment. To some it just feels needlessly antagonistic
> and distrusting towards part of our community.
I think F6, above, bundles together several of Maxwell's points and
maybe loses something in summary. I'd encourage interested readers to
view the original post that Folkson referenced. I'd like to extract one
part as a separate point and write about it a bit in my own words:
F7) defaulting to LOT=false makes non-activation possible even if people
run the code that developers provide, meaning a successful
activation proves that at least some people (e.g. miners or UASFers)
voluntarily took actions that were well outside the scope of
developer control.
This makes it clear that developers don't control changes to the
system. There are other arguments that demonstrate that developers
aren't in control[1], but they aren't as clear as simply pointing
out that a rule change won't go into effect until at least several
non-developers independently act of their own accord.
Having such a clear argument that developers aren't in control
bolsters the decentralized ethos of Bitcoin and reduces the chance
that bad actors will pressure Bitcoin developers to attempt future
unwanted changes.
-Dave
[1] IMO, the main evidence we have that developers aren't in control of
the system is that Bitcoin Core is free software which gives anyone
who obtains a copy of it the legal right to run it, learn from it,
modify it, and share additional copies of it for any purpose. Each
time someone uses those rights to create alternative Bitcoin
implementations, altcoins, or forkcoins, they demonstrate that users
could change the system---or resist changes to it---in opposition to
the current developer team, should that become necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210213/47a055ac/attachment.sig>;
đź“ť Original message:On Fri, Feb 05, 2021 at 12:43:57PM +0000, Michael Folkson via bitcoin-dev wrote:
> https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
> [...]
> F6) It is more important that no rules that harm users are deployed
> than it is that new useful rules are deployed quickly. If there is a
> choice between “faster” and “more clear that this isn’t a mechanism to
> force bad things on users” we should prefer the latter. Plenty of
> people just don’t like LOT=true very much absent evidence that miners
> are blocking deployment. To some it just feels needlessly antagonistic
> and distrusting towards part of our community.
I think F6, above, bundles together several of Maxwell's points and
maybe loses something in summary. I'd encourage interested readers to
view the original post that Folkson referenced. I'd like to extract one
part as a separate point and write about it a bit in my own words:
F7) defaulting to LOT=false makes non-activation possible even if people
run the code that developers provide, meaning a successful
activation proves that at least some people (e.g. miners or UASFers)
voluntarily took actions that were well outside the scope of
developer control.
This makes it clear that developers don't control changes to the
system. There are other arguments that demonstrate that developers
aren't in control[1], but they aren't as clear as simply pointing
out that a rule change won't go into effect until at least several
non-developers independently act of their own accord.
Having such a clear argument that developers aren't in control
bolsters the decentralized ethos of Bitcoin and reduces the chance
that bad actors will pressure Bitcoin developers to attempt future
unwanted changes.
-Dave
[1] IMO, the main evidence we have that developers aren't in control of
the system is that Bitcoin Core is free software which gives anyone
who obtains a copy of it the legal right to run it, learn from it,
modify it, and share additional copies of it for any purpose. Each
time someone uses those rights to create alternative Bitcoin
implementations, altcoins, or forkcoins, they demonstrate that users
could change the system---or resist changes to it---in opposition to
the current developer team, should that become necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210213/47a055ac/attachment.sig>;