path: root/28/ce6993dcb5675359870702ee2536e3797c09bf

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 96278C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 16:43:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 6DC9040137
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 16:43:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id j948BhbWUUHk
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 16:43:54 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo41.poczta.onet.pl (smtpo41.poczta.onet.pl
 [213.180.142.172])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 473EE400F2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Mar 2022 16:43:53 +0000 (UTC)
Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4KLRXd0xzBz1qnq;
 Sat, 19 Mar 2022 17:43:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1647708225; bh=8mT6LjAqIeJHidiTUCI4mN1X4i3mVnE3R58nRM475/Y=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=H6tX5mgeqIzqRJYAKeRzepdjiRSF5IAAUwNLBNsIpxq/OcNRurwcauwikWikR8efG
 zvk558d+ghvWhIMbuwCNezyEgc+FimcxZ0jSo3TaMjOaB5gbZEa0rjuseIbZt/042s
 xtSQP05RA0sGHGt8L+E8/f2Pes/cQJQhhp6xJgjo=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.241.5] by pmq7v.m5r2.onet via HTTP id ;
 Sat, 19 Mar 2022 17:43:45 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Billy Tetrud <billy.tetrud@gmail.com>,
 =?utf-8?q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAGpPWDbHz=+6yEvEjouSPRBpUJqxquHf_izGEj8iVhfkLwOxcA@mail.gmail.com>
Date: Sat, 19 Mar 2022 17:43:42 +0100
Message-Id: <158761067-5972eed5dc932b75482a9a8415f63503@pmq7v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.241.5;PL;3
X-Mailman-Approved-At: Sat, 19 Mar 2022 19:25:47 +0000
Subject: Re: [bitcoin-dev] Speedy Trial
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: Sat, 19 Mar 2022 16:43:56 -0000

> A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% su=
pport:10%}> for each UTXO they want to respond to the poll with.

It should not be expressed in percents, but in amounts. It would be easier =
and more compatible with votes where there is 100% oppose or 100% support (=
and also easier to handle if some LN user would move one satoshi, because r=
ounding percents would be tricky). Anyway, you need to convert percents to =
amounts, so better use amounts from the very beginning. Also, it could be j=
ust some kind of transaction, where you have utxo_id just as transaction in=
put, amount of coins as some output, and then add your message as "OP_RETUR=
N <commitment>" in your input, in this way your signature would be useless =
in a different context than voting.

Also note that such voting would be some kind of Proof of Stake. And it doe=
s not really matter if you store that commitments on-chain to preserve sign=
alling results in consensus rules or if there would be some separate chain =
for storing commitments and nothing else. It would be Proof of Stake, where=
 users would put their coins at stake to vote. Also, you probably solved "n=
othing at stake" problem in a nice way, because it would be protected by Pr=
oof of Work chain to decide who can vote. So, voters could only freeze thei=
r coins for getting some voting power or move their coins and lose their vo=
tes.

For me, it sounds similar to "Merged Signing" proposed by stwenhao here: ht=
tps://bitcointalk.org/index.php?topic=3D5390027.0. I think it is kind of da=
ngerous and unstoppable (so nobody could stop you if you would ignore any c=
riticism and implement that). Fortunately, it is also possible to add some =
Proof of Work if any staking-like system would be present in Bitcoin, just =
OP_SUBSTR would do the trick (if enabled; if not, we could still use OP_HAS=
H256 and force the target by some kind of soft-fork on top of your voting s=
ystem).


On 2022-03-17 20:58:35 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.


Not the one I'll propose right here. What I propose specifically is a=C2=A0=
coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like <utxo_id, {soft_fork: 9 oppose:90% supp=
ort:10%}> for each UTXO they want to respond to the poll with.
B. A signed message like that is valid only while that UTXO has not been sp=
ent.
C. Poll results are considered only at each particular block height, where =
the support and opposition responses are weighted by the UTXO amount (and t=
he support/oppose fraction in the message). This means you'd basically see =
a rolling poll through the blockchain as new signed poll messages come in a=
nd as their UTXOs are spent.=C2=A0


This is not vulnerable to sybil attacks because it requires access to UTXOs=
 and response-weight is directly tied to UTXO amount. If someone signs a po=
ll message with a key that can unlock (or is in some other designated way a=
ssociated with) a UTXO, and then spends that UTXO, their poll response stop=
s being counted for all block heights after the UTXO was spent.=C2=A0


Why put support and oppose fractions in the message? Who would want to both=
 support and oppose something? Any multiple participant UTXO would. Eg ligh=
tning channels would, where each participant disagrees with the other. They=
 need to sign together, so they can have an agreement to sign for the fract=
ions that match their respective channel balances (using a force channel cl=
ose as a last resort against an uncooperative partner as usual).=C2=A0


This does have the potential issue of public key exposure prior to spending=
 for current addresses. But that could be fixed with a new address type tha=
t has two public keys / spend paths: one for spending and one for signing.=
=C2=A0



> In perfect competition the mining power costs per chain tends to equal th=
e rewards offered by that chain, both in subsidy and transaction fees.


Agreed, but it takes time for an economic shock to reach its new equilibriu=
m. That period of time, which might be rather precarious, should be conside=
red in a plan to preserve a minority fork.=C2=A0


> Would you rather that proposal be deployed with speedy trial activation o=
r with BIP8+LOT=3Dtrue activation?


For a proposal I don't want to succeed, I absolutely would prefer speedy tr=
ial over BIP8+LOT=3Dtrue. Speedy trial at 90% signaling threshold can quick=
ly determine that the proposal (hopefully) does not have enough consensus a=
mong miners. By contrast, BIP8+LOT=3Dtrue could polarize the debate, worsen=
ing the community's ability to communicate and talk through issues. It woul=
d also basically guarantee that a fork happens, which in the best case (in =
my hypothetical point of view where I don't like the proposal) would mean s=
ome small minority forks off the network, which reduces the main chain's va=
lue somewhat (at least temporarily). Worst case a small majority forces the=
 issue at near 50% which would cause all sorts of blockchain issues and wou=
ld have a high probability of leading to a hardfork=C2=A0by the minority.=
=C2=A0


All this sounds rather more tenable with speedy trial. Any proposal has les=
s chance of causing an actual fork (soft or otherwise) with speedy trial vs=
 LOT=3Dtrue. LOT=3Dtrue guarantees a fork if even a single person is runnin=
g it. LOT=3Dtrue could certainly come in handy to initiate a UASF, but IMO =
that's better left as a plan B or C.=C2=A0


> segwit... all the consequences of the change are not opt in.


I definitely agree there. The consequences of a soft fork are not always op=
t in. That's basically what my example of a "dumb majority soft fork" is, a=
nd sounds like what your "evil fork" basically is.=C2=A0


On Thu, Mar 17, 2022 at 7:19 AM Jorge Tim=C3=B3n via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> A mechanism of soft-forking against activation exists.=C2=A0 What more do=
 you want? Are we supposed to write the code on behalf of this hypothetical=
 group of users who may or may not exist for them just so that they can hav=
e a node that remains stalled on Speedy Trial lockin?=C2=A0 That simply isn=
't reasonable, but if you think it is, I invite you to create such a fork.

I want BIP+LOT=3Dtrue to be used. I want speedy trial not to be used.
Luke wrote the code to resist BIP8+LOT=3Dtrue, and if he didn't, I could
write it myself, yes.
If you think that's not reasonable code to ever run, I don't think
you're really getting the "softfork THAT YOU OPPOSE" part of the
hypothetical right. Let me try to help with an example, although I
hope we don't get derailed in the implementation details of the
hypothetical evil proposal.

Suppose someone proposes a weight size limit increase by a extension
block softfork.
Or instead of that, just imagine the final version of the covenants
proposal has a backdoor in it or something.


Would you rather that proposal be deployed with speedy trial
activation or with BIP8+LOT=3Dtrue activation?

>>
>> Please, try to imagine an example for an activation that you wouldn't li=
ke yourself. Imagine it gets proposed and you, as a user, want to resist it.
>
>
> If I believe I'm in the economic majority then I'll just refuse to upgrad=
e my node, which was option 2. I don't know why you dismissed it.

Not upgrading your node doesn't prevent the softfork from being
activated in your chain.
A softfork may affect you indirectly even if you don't use the new
features yourself directly.
You may chose to stay in the old chain even if you don't consider
you're "in the economic majority" at that moment.

> Not much can prevent a miner cartel from enforcing rules that users don't=
 want other than hard forking a replacement POW.=C2=A0 There is no effectiv=
e difference between some developers releasing a malicious soft-fork of Bit=
coin and the miners releasing a malicious version themselves.=C2=A0 And whe=
n the miner cartel forms, they aren't necessarily going to be polite enough=
 to give a transparent signal of their new rules.=C2=A0 However, without th=
e economic majority enforcing their set of rules, the cartel continuously r=
isks falling apart from the temptation of transaction fees of the censored =
transactions.

It is true that a mining cartel doesn't need to use speedy trial or
BIP8+LOT=3Dtrue to apply rule changes they want just because we do.
But they would do if they wanted to maintain the appearance of benevolence.

> On the other hand, If I find out I'm in the economic minority then I have=
 little choice but to either accept the existence of the new rules or sell =
my Bitcoin.=C2=A0 Look, you cannot have the perfect system of money all by =
your lonesome self.=C2=A0 Money doesn't have economic value if no one else =
wants to trade you for it.=C2=A0 Just ask that poor user who YOLO'd his own=
 taproot activation in advance all by themselves.=C2=A0 I'm sure they think=
 they've got just the perfect money system, with taproot early and everythi=
ng.=C2=A0 But now their node is stuck at block 692261 and hasn't made progr=
ess since.=C2=A0 No doubt they are hunkered down for the long term, absolut=
ely committed to their fork and just waiting for the rest of the world to c=
ome around to how much better their version of Bitcoin is than the rest of =
us.

Well, you could also have the option to stay in the old chain with the
economic minority, it doesn't have to be you alone.
We agree that one person alone can't use a currency.

> Even though you've dismissed it, one of the considerations of taproot was=
 that it is opt-in for users to use the functionality.=C2=A0 Future soft-fo=
rks ought to have the same considerations to the extent possible.

Well, the same could be said about segwit. And yet all the
consequences of the change are not opt in.
For example, segwit contained a block size limit increase.
Sure, you can just not validate the witnesses, but then you're no
longer a full node.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev