From: yanmaani@cock•li
To: Chris Belcher <belcher@riseup•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
Date: Wed, 03 Mar 2021 21:39:33 +0000 [thread overview]
Message-ID: <4b89f7feb5d5442527644852188def49@cock.li> (raw)
In-Reply-To: <839ee260-7ac0-9c78-5348-28e80b69799f@riseup.net>
On 2021-03-03 20:48, Chris Belcher wrote:
> On 03/03/2021 17:30, yanmaani@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
next prev parent reply other threads:[~2021-03-03 21:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-03 14:39 Chris Belcher
2021-03-03 16:19 ` Vincent Truong
2021-03-04 23:45 ` Eric Voskuil
2021-03-03 17:30 ` yanmaani
2021-03-03 20:48 ` Chris Belcher
2021-03-03 21:39 ` yanmaani [this message]
2021-03-03 19:08 ` Russell O'Connor
2021-03-03 22:14 ` Matt Corallo
2021-03-04 13:47 ` Russell O'Connor
2021-03-04 18:23 ` Keagan McClelland
2021-03-05 14:51 ` Ryan Grant
2021-03-05 18:17 ` Luke Dashjr
2021-03-06 17:57 ` Matt Corallo
2021-03-29 9:17 ` Anthony Towns
[not found] <mailman.66954.1614808879.32591.bitcoin-dev@lists.linuxfoundation.org>
2021-03-03 22:12 ` Luke Kenneth Casson Leighton
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=4b89f7feb5d5442527644852188def49@cock.li \
--to=yanmaani@cock$(echo .)li \
--cc=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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