On 2021-03-03 20:48, Chris Belcher wrote:
On 03/03/2021 17:30, yanma...@cock.li wrote:
Is that supposed to be a good thing? "We should do X because it'll
work"
doesn't prove X is actually good. These things can be evil, but they
can
also be legitimate opposition to a change. Taking away the power of a
"social media blitz" is not guaranteed to be a good thing!
It is good that social media drama can only make its own followers fork
away. In bitcoin people represent themselves, if they want certain
rules
enforced they should have to actually tell their software to do that.
The problem with BIP8 is that social media drama has a incentive to
promote brinksmanship.
Tell their software to do it, yes, but fork it? That seems like a big
"I'm sorry Dave, I'm afraid I can't do that" moment. If I tell Bitcoin
Core to do something, it seems like a bad thing that it would favor the
Core devs' wishes ("Get Taproot done") over mine.
That will only work for really egregious changes. In practice, most
people will trust Core on all other (non-egregious) decisions, because
of the inertia inherent in disobeying them.
[...]
You're right in suggesting that it will work, but the reason why it
will
work is because nobody wants to disobey Core. It seems immoral to
exploit this fact.
It is not correct to say that this will work because "nobody will
disobey Core". In reality it will work because basically everyone
either
wants taproot or has no opinion about taproot.
Both can be true at the same time. This is going to work because
basically nobody opposes Taproot. But if you did have some people
opposing Taproot, it would still work, because nobody would want to
disobey Core.
Your argument depends heavily on the word "egregious". I've shown that
for harmful changes like censorship can be resisted by the bitcoin
community. Can you come up with an example of a bad change which won't
be resisted?
Example 1: There is currently a specific mining pool planning to
blacklist addresses on sanctions lists. If they were to
convince/bribe/threaten Core to soft-fork so as to burn one specific
UTXO worth $1, the only direct victim of that would be the holder of
that UTXO, who loses only $1 from it.
Example 2: A soft fork to decrease the block size by 0.1%.
If we assume that the current block size is optimal and censorship is
bad, it seems simultaneously true that
1) it would be bad to decrease the block size or to burn that UTXO
2) nobody would be wiling to fight a war over a 0.1% decrease or a $1
loss to one guy
You might say that these are minor changes. Sure. But that's what I'm
saying: if the change is big ("egregious") enough to seriously
inconvenience people, they would fight it, but if it's trivial (thought
still bad), the inertia of Core would force them to accept it.
Here's another example of an easily-resisted change: A Core team that's
been compromised might do a flag-day UASF where transactions are only
confirmed if they pay a minimum of 1000 sat/vbyte in miner fee. The
community could resist this by doing a counter-UASF where a transaction
paying just 1 sat/vbyte is required to be included in the first block
after the flay day.
(Nitpick: Miners would probably not support it, because less people
would be willing to pay that fee.)
Sure, and this change would be resisted because it seriously
inconveniences people. But what if it's just 2sat/vbyte?
At least you shouldn't hard-code it and require dissenters to fork
away.
I exhort you to consider making all this controversial stuff settings
that can be changed by RPC command or command-line flag; set the
default
value sure, but requiring a fork to change it is, in my opinion,
oppressive.
What alternative do you suggest? If you advocate allowing miners to
activate soft forks then that still won't protect users. Because miners
won't save users in my above example of a 1000 sat/vbyte price floor,
in
fact miners would see their income greatly increased if the soft fork
was successful. So in fact the ability to do a counter-UASF is always
what actually protected users, miner protection is nothing something to
count on.
I don't disagree. The ability to do a counter-UASF should also be added,
if it's envisioned somebody might want to do that.
Basically, I think that Core should provide users with the tools to
express their views and to exercise their economic power, and they could
give them default values according to what they think best.
However, they shouldn't force people to use a forked client if they want
to disobey them. That would be to abuse the power vested in the
development group.
On 2021-03-03 14:39, Chris Belcher via bitcoin-dev wrote:
Enter flag day activation. With a flag day there can be no
brinksmanship. A social media blitz cant do anything except have its
own
followers fork away. Crucially, miner signalling cant be used to
change
the activation date for nodes that didn't choose to and just
passively
follow signalling. Changing the activation date requires all those
users
to actually run different node software.
What if one day the Core developer team uses the flag
day method to do something bad? The bitcoin user
community who wants to resist this can create their own
counter-soft-fork full node. This forces a chain
split. The real bitcoin which most people follow will be
the chain without censorship.
[edited for brevity]
What you suggest may be an efficient way to ram taproot through, but
is
it inherently good? Nothing is free. This seems like de-facto forcing
people to go along with you, because you're convinced you're right. In
this case, you are, but you'd be convinced you'd be right even if you
weren't so.
(Also consider some compromise, such as ">95% miner support before
flag
day or >33% on flag day")
Best wishes
Yanmaani
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
