path: root/a7/845cccb34ab48e008642d3ef71697c83778596

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B2E21C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 15:56:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 9938A401D6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 15:56:16 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id DdArKcG6WAv0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 15:56:15 +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 smtp4.osuosl.org (Postfix) with ESMTPS id E56D04019F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 15:56:14 +0000 (UTC)
Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4KMfNj0WzTz1smH;
 Mon, 21 Mar 2022 16:56:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1647878165; bh=ghyZq8Pjxv7jvU96jJLQ+kCIik1J1dNF7N75lRuzA8E=;
 h=From:Cc:To:In-Reply-To:Date:Subject:From;
 b=fb2W7hqpOVbRms1RN17v2RGNkX/BXwQ18gHKTkPfUot2tr7IaMRBA3JUHsS0Bd2Lb
 iXwf4fjLKiCud/e08J4EGGzCAvAhE12k8nvIjhRiYf9DszGSndEUC0xPja+nNYBF3f
 vujOr0dM5/hO9Wi+gY2QhIBh4zhfLx8f9dmtM1IU=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.240.65] by pmq1v.m5r2.onet via HTTP id ;
 Mon, 21 Mar 2022 16:56:05 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Billy Tetrud <billy.tetrud@gmail.com>,ZmnSCPxj <ZmnSCPxj@protonmail.com>
In-Reply-To: <CAGpPWDZjdF1DQ6MrGDgq+2dz4+HJKP1FZDmMJ=UvmUDF1QUzjA@mail.gmail.com>
Date: Mon, 21 Mar 2022 16:56:03 +0100
Message-Id: <159790950-91b98cf7c46005fc096979a329d90e1b@pmq1v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.240.65;PL;3
X-Mailman-Approved-At: Mon, 21 Mar 2022 16:03:31 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Mon, 21 Mar 2022 15:56:16 -0000

> I don't quite understand this part. I don't understand how this would mak=
e your signature useless in a different context. Could you elaborate?

It is simple. If you vote by making transactions, then someone could captur=
e that and broadcast to nodes. If your signature is "useless in a different=
 context", then you can only send that to your network. If it will be sent =
anywhere else, it will be invalid, so also useless. Another reason to sign =
transactions and not just some custom data is to make it compatible with "s=
ignet way of making signatures", the same as used in signet challenge.

> I don't think any kind of chain is necessary to store this data.

Even if it is not needed, it is kind of "free" if you take transaction size=
 into account. Because each person moving coins on-chain could attach "OP_R=
ETURN <commitment>" in TapScript, just to save commitments. Then, even if s=
omeone is not in your network from the very beginning, that person could st=
ill collect commitments and find out how they are connected with on-chain t=
ransactions.

> Perhaps one day it could be used for something akin to voting, but certai=
nly if we were going to implement this to help decide on the next soft fork=
, it would very likely be a quite biased set of responders.

If it will be ever implemented, it should be done in a similar way as diffi=
culty: if you want 90%, you should calculate, what amount in satoshis is ne=
eded to reach that 90%, and update it every two weeks, based on all votes. =
In this way, you reduce floating-point operations to a bare minimum, and ha=
ve a system, where you can compare uint64 amounts to quickly get "yes/no" a=
nswer to the question, if something should be triggered (also, you can comp=
ress it to 32 bits in the same way as 256-bit target is compressed).

> But on that note, I was thinking that it might be interesting to have an =
optional human readable message into these poll messages.

As I said, "OP_RETURN <commitment>" inside TapScript is enough to produce a=
ll commitments of arbitrary size for "free", so that on-chain transaction s=
ize is constant, no matter how large that commitment is. And about storage:=
 you could create a separate chain for that, you could store that in the sa=
me way as LN nodes store data, you could use something else, it doesn't rea=
lly matter, because on-chain commitments could be constructed in the same w=
ay (also, as long as the transaction creator keeps those commitments as a s=
ecret, there is no way to get them; that means you can add them later if ne=
eded and easily pretend that "it was always possible").


On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
Good Evening ZmnSCPxj,


>=C2=A0 I need to be able to invalidate the previous signal, one that is ti=
ed to the fulfillment of the forwarding request.


You're right that there's some nuance there. You could add a block hash int=
o the poll message and define things so any subsequent poll message sent wi=
th a newer block hash overrides the old poll message at the block with that=
 hash and later blocks. That way if a channel balance changes significantly=
, a new poll message can be sent out.=C2=A0


Or you could remove the ability to specify=C2=A0fractional support/oppositi=
on and exclude multiparty UTXOs from participation. I tend to like the idea=
 of the possibility of full participation tho, even in a world that mainly =
uses lightning.


> if the signaling is done onchain


I don't think any of this signaling needs to be done on-chain. Anyone who w=
ants to keep a count of the poll can simply collect together all these poll=
 messages and count up the weighted preferences. Yes, it would be possible =
for one person to send out many conflicting poll messages, but this could b=
e handled without any commitment to the blockchain. A simple thing to do wo=
uld be to simply invalidate poll messages that conflict (ie include them bo=
th in your list of counted=C2=A0messages, but ignore them in your weighted-=
sums of poll preferences). As long as these polls are simply used to inform=
 action rather than to trigger action, it should be ok that someone can pro=
duce biased incomplete counts, since anyone can show a provably more comple=
te set (a superset) of poll messages. Also, since this would generally be a=
 time-bound thing, where this poll information would for example be used to=
 gauge support for a soft fork, there isn't much of a need to keep the poll=
 messages on an immutable ledger. Old poll data is inherently not very prac=
tically useful compared to recent poll data. So we can kind of side step th=
ings like history attacks by simply ignoring polls that aren't recent.


> Semantically, we would consider the "cold" key to be the "true" owner of =
the fund, with "hot" key being delegates who are semi-trusted, but not as t=
rusted as the "cold" key.


I'm not sure I agree with those semantics as a hard rule. I don't consider =
a "key" to be an owner of anything. A person owns a key, which gives them a=
ccess to funds. A key is a tool, and the owner of a key or wallet vault can=
 define whatever semantics they want. If they want to designate a hot key=
=C2=A0as their poll-signing key, that's their prerogative. If they want to =
require a cold-key as their message-signing key or even require multisig si=
gning, that's up to them as well. You could even mirror wallet-vault constr=
ucts by overriding a poll message signed with fewer key using one signed wi=
th more keys. The trade offs you bring up are reasonable considerations, an=
d I think which trade offs to choose may vary by the individual in question=
 and their individual situation. However, I think the time-bound and non-bi=
nding nature of a poll makes the risks here pretty small for most situation=
s you would want to use this in (eg in a soft-fork poll). It should be reas=
onable to consider any signed poll message valid, regardless of possibiliti=
es of theft or key renting shinanigans. Nacho keys nacho coins would of cou=
rse be important in this scenario.=C2=A0


>=C2=A0 if I need to be able to somehow indicate that a long-term-cold-stor=
age UTXO has a signaling pubkey, I imagine this mechanism of indioating mig=
ht itself require a softfork, so you have a chicken-and-egg problem...


If such a thing did need a soft fork, the chicken and egg question would be=
 easy to answer: the soft fork comes first. We've done soft forks before ha=
ving this mechanism, and if necessary we could do another one to enable it.


However, I think=C2=A0taproot can enable this mechanism without a soft fork=
. It should be possible to include a taproot leaf that has the data necessa=
ry to validate a signaling signature. The tapleaf would contain an invalid =
script that has an alternative interpretation, where your poll message can =
include the merkle path to tapleaf (the invalid-script), and the data at th=
at leaf would be a public key you can then verify the signaling signature a=
gainst.=C2=A0


@vjudeu

> It should not be expressed in percents, but in amounts


Agreed. You make a good case for that.


>=C2=A0it could be just some kind of transaction, where you have utxo_id ju=
st as transaction input, amount of coins as some output, and then add your =
message as "OP_RETURN <commitment>" in your input, in this way your signatu=
re would be useless in a different context than voting.
=C2=A0
I don't quite understand this part. I don't understand how this would make =
your signature useless in a different context. Could you elaborate?
=C2=A0
>=C2=A0it does not really matter if you store that commitments on-chain to =
preserve signalling results in consensus rules or if there would be some se=
parate chain for storing commitments and nothing else
=C2=A0
I don't think any kind of chain is necessary to store this data. I'm primar=
ily suggesting this as a method to help the debate about a soft fork have b=
etter information about what broader users think about a particular soft fo=
rk proposal, so such data would simply inform whether or not we decide to c=
ontinue work on an upgrade. I don't think you'd want to require any validat=
ion of this data by all full nodes, because the data could be hundreds of g=
igabytes in size (let's say 1 billion people respond). You'd have to run so=
me kind of random sampling (more like actual proof of stake) to get this da=
ta down to a manageable size.=C2=A0


> It would be Proof of Stake, where users would put their coins at stake to=
 vote.


Sure, as long as by this you mean simply proof of coin ownership. Just as a=
ny bitcoin transaction involves proof of coin ownership.


I was pretty careful to avoid the word "voting", since I'm not proposing th=
at this be used with definite thresholds that trigger action, but more of a=
n information gathering mechanism. Perhaps one day it could be used for som=
ething akin to voting, but certainly if we were going to implement this to =
help decide on the next soft fork, it would very likely be a quite biased s=
et of responders. We would want to take that into account when deciding how=
 to interpret the data. Even with biased data tho, it could be a useful too=
l for resolving some contention.=C2=A0


But on that note, I was thinking that it might be interesting to have an op=
tional human readable message into these poll messages. Those messages coul=
d be then read through to gain a better understanding of why people are sup=
porting and why people are rejecting a particular thing. It could inform ho=
w we might change how we explain a technical change to make it easier for l=
ess technical folks (who don't post on twitter) to understand. It could pot=
entially=C2=A0give insight into an otherwise quiet majority (or large minor=
ity).


> it sounds similar to "Merged Signing"=C2=A0


Interesting. I'm not sure I fully grok his idea, but I think he was suggest=
ing that a proof of stake consensus protocol pay attention to bitcoin trans=
actions formatted in a particular way. I think I've hopefully clarified abo=
ve why the idea I'm suggesting is rather different from this (eg in that no=
 special commitments need to be made).


Cheers,
BT














On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
Good morning Billy,

> @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=
=A0coin-weighted signature-based poll with the following components:
> 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.
> B. A signed message like that is valid only while that UTXO has not been =
spent.
> C. Poll results are considered only at each particular block height, wher=
e the support and opposition responses are weighted by the UTXO amount (and=
 the support/oppose fraction in the message). This means you'd basically se=
e a rolling poll through the blockchain as new signed poll messages come in=
 and as their UTXOs are spent.=C2=A0
>
> This is not vulnerable to sybil attacks because it requires access to UTX=
Os and response-weight is directly tied to UTXO amount. If someone signs a =
poll message with a key that can unlock (or is in some other designated way=
 associated with) a UTXO, and then spends that UTXO, their poll response st=
ops 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 bo=
th support and oppose something? Any multiple participant UTXO would. Eg li=
ghtning channels would, where each participant disagrees with the other. Th=
ey need to sign together, so they can have an agreement to sign for the fra=
ctions that match their respective channel balances (using a force channel =
close as a last resort against an uncooperative partner as usual).=C2=A0

This does not quite work, as lightning channel balances can be changed at a=
ny time.
I might agree that you have 90% of the channel and I have 10% of the channe=
l right now, but if you then send a request to forward your funds out, I ne=
ed to be able to invalidate the previous signal, one that is tied to the fu=
lfillment of the forwarding request.
This begins to add complexity.

More pointedly, if the signaling is done onchain, then a forward on the LN =
requires that I put up invalidations of previous signals, also onchain, oth=
erwise you could cheaty cheat your effective balance by moving your funds a=
round.
But the point of LN is to avoid putting typical everyday forwards onchain.

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

This issue is particularly relevant to vault constructions.
Typically a vault has a "cold" key that is the master owner of the fund, wi=
th "hot" keys having partial access.
Semantically, we would consider the "cold" key to be the "true" owner of th=
e fund, with "hot" key being delegates who are semi-trusted, but not as tru=
sted as the "cold" key.

So, we should consider a vote from the "cold" key only.
However, the point is that the "cold" key wants to be kept offline as much =
as possible for security.

I suppose the "cold" key could be put online just once to create the signal=
 message, but vault owners might not want to vote because of the risk, and =
their weight might be enough to be important in your voting scheme (conside=
r that the point of vaults is to protect large funds).


A sub-issue here with the spend/signal pubkey idea is that if I need to be =
able to somehow indicate that a long-term-cold-storage UTXO has a signaling=
 pubkey, I imagine this mechanism of indioating might itself require a soft=
fork, so you have a chicken-and-egg problem...

Regards,
ZmnSCPxj