path: root/da/85af4a348ed9e992d0377111a459f21d00ad1b

Return-Path: <yanmaani@cock.li>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2B14DC0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 21:39:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0503D6F98C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 21:39:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 2.74
X-Spam-Level: **
X-Spam-Status: No, score=2.74 tagged_above=-999 required=5
 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347,
 RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RDNS_NONE=0.793,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=cock.li
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id AVMpbNudiYLM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 21:39:44 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.cock.li (unknown [37.120.193.123])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 29721606D0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  3 Mar 2021 21:39:44 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
 t=1614807573; bh=FVlnGlzmfUTmHiFApzQPiVeTfqy2vl//dZE3MrHFFqE=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=VQMXrCTpj14qR4rXKOHlEWHI8t7tPKODaKlpDsmXnsiJW0l6fZoi5Qdr1lkdnKdNk
 H1NJkilgYNzzTBxmkq+O2iAvvIaphCtBS5JUA/CATwOFYvUd6BaS7aNd5uI6EBnEO9
 t1oQ8diFNSfQ7uCndtOyLgv+g5bGh3GoUK0oDj/WNUMD1GonfJ8MDm0U5nNljTfpII
 +q4nhhoLvparWUpURxISjR4J15yEVsbPmfQKVeYEjqbeRp8N/znoqUHWWVN4qnOc/S
 SSKRUvSq1lRmUvpw0APlALctOSy2WU/Xd+SjeTeEOsHd7BsfzxsnOerA5AS/6hStUH
 elrx8vNym0t3w==
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 03 Mar 2021 21:39:33 +0000
From: yanmaani@cock.li
To: Chris Belcher <belcher@riseup.net>
In-Reply-To: <839ee260-7ac0-9c78-5348-28e80b69799f@riseup.net>
References: <3286a7eb-9deb-77d6-4527-58e0c5882ae2@riseup.net>
 <85745a38e4464541d6357408fae1cfed@cock.li>
 <839ee260-7ac0-9c78-5348-28e80b69799f@riseup.net>
Message-ID: <4b89f7feb5d5442527644852188def49@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.15
X-Mailman-Approved-At: Wed, 03 Mar 2021 22:09:55 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Making the case for flag day activation of taproot
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2021 21:39:48 -0000

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