path: root/33/8479220f4a34356965fc9fa96c6bdffbbc775d

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 241D2C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:37:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 05A3F40891
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:37:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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,
 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 7O2wgsaIkAIV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:37:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo94.poczta.onet.pl (smtpo94.poczta.onet.pl
 [213.180.149.147])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 28614402F6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 16:37:09 +0000 (UTC)
Received: from mta1.m5r2.onet (mta1.m5r2.onet [10.174.35.135])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4KNHFT2KkNzly6;
 Tue, 22 Mar 2022 17:37:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1647967021; bh=JIeQZ84PbUi7SszUqEGlOsRIYGeo4DvNYR17hOycYQ4=;
 h=From:To:Cc:In-Reply-To:Subject:Date:From;
 b=VtGDhsIgvsvLQxf91Id2aRd/41LZi6fYjb+iSRr7APwdiZamD/PdEAxOJ+WBFklv6
 ElfR5I/FEK28pfs9GuT0NnG/ceaMxfIgpvK6H8dpBFLsyuavlOlRcL6nNPeUBAie2y
 /gbhUq/ldDzrec5BFvLh/Qyn+UPKyu5uGlK5NG2g=
Content-Type: text/plain; charset=utf-8
X-Mailer: onet.poczta
X-Priority: 3
X-Onet-Pmq: <vjudeu@gazeta.pl>;5.173.248.89;PL;1
Received: from [5.173.248.89] by mta1.m5r2.onet with HTTP id
 ca5509168820d332; Tue, 22 Mar 2022 17:36:51 +0100
From: vjudeu@gazeta.pl
To: Billy Tetrud <billy.tetrud@gmail.com>
In-Reply-To: <CAGpPWDa1Ax0S0Op20Wi0VPohALL9y-62iETOF3d1FgGqxh-tdQ@mail.gmail.com>
Message-ID: <3e4f7fa0-9a07-976b-ac6f-bd63232e928b@gazeta.pl>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 22 Mar 2022 16:37:01 +0000
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 22 Mar 2022 18: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: Tue, 22 Mar 2022 16:37:12 -0000

> What do you mean "capture that" and "your network"? I was imagining a =
scenario where these poll messages are always broadcast globally. Are you =
implying more of a private poll?

If you vote by making a Bitcoin =
transaction, then someone could move real bitcoins, just by including your =
transaction into a block. I thought you only want to get some feedback, in =
this case you only need to sign things, not to move real coins. So, there =
will be one network for moving bitcoins and one network for =
signalling/voting/whatever. If you combine both of them to be the same =
network, then you end up in a situation, where moving coins is needed to =
signal anything (that may quickly fill mempools and increase on-chain fees)=
.

Also, as you earlier proposed custom data format for signing, I thought =
you want to create a separate network.

> I still don't understand. Why =
would a signed transaction be invalid anywhere? Wouldn't a signed =
transaction be valid everywhere?

It depends what is signed and how it is =
signed. A transaction moving "1 BTC -> 1.5 BTC" with =
SIGHASH_SINGLE|SIGHASH_ANYONECANPAY cannot be included directly into a =
block, but can be turned into a valid transaction, just by attaching more =
inputs. A signed "Bitcoin Message" can be used to prove ownership, but =
cannot be included into a block as a valid transaction. So, if you want to =
move coins and vote, you can just sign a transaction (or even just observe =
your mempool and receive new blocks, then you can use existing transactions=
 and pretend they are all signalling for or against something). But if you =
want to only move coins or to only vote, then you need to carefully choose =
data for signing, just to do one thing and not the other.

> Perhaps I don't understand how signet works well enough to understand =
this, but I would think that signing an message would work with signet just=
 as well as mainnet. I get the feeling perhaps we're misunderstanding each =
other in some fundamental way.

In signet, whole transactions are signed. =
There are separate BIP's that describe signing in a different way than =
famous "Bitcoin Message". Because if you sign just some message, extending =
such format is complicated. But if you sign a transaction, then you can =
sign P2SH address, P2WSH address, Taproot address, and potentially even =
not-yet-implemented-future-soft-fork-address.

> But it would require an =
on-chain transaction. We don't want 6 billion people to have to send an =
on-chain transaction all in the same week in order to register their =
preference on something.

It would require an on-chain transaction every =
sometimes, not every vote. If someone is going to do some on-chain =
transaction, then that person could attach some commitment for the whole =
network. So, instead of just doing regular transaction, people could attach=
 commitments at the same cost, with the same on-chain transaction size. The=
 only needed change is just tweaking their own keys and informing your =
network about pushed commitment.


On 2022-03-22 16:19:49 user Billy Tetrud=
 <billy.tetrud@gmail.com> wrote:
>=C2=A0 If you vote by making transactions=
, then someone could capture that and broadcast to nodes
>=C2=A0 you can only send that to your network



What do you mean "capture=
 that" and "your network"? I was imagining a scenario where these poll =
messages are always broadcast globally. Are you implying more of a private =
poll?


> If it will be sent anywhere else, it will be invalid


I still don't understand. Why would a signed transaction be invalid =
anywhere? Wouldn't a signed transaction be valid everywhere?=C2=A0


> Another reason to sign transactions and not just some custom data is to =
make it compatible with "signet way of making signatures", the same as used=
 in signet challenge.


Perhaps I don't understand how signet works well =
enough to understand this, but I would think that signing an message would =
work with signet just as well as mainnet. I get the feeling perhaps we're =
misunderstanding each other in some fundamental way.


> Even if it is not needed, it is kind of "free" if you take transaction =
size into account


But it would require an on-chain transaction. We don't =
want 6 billion people to have to send an on-chain transaction all in the =
same week in order to register their preference on something.=C2=A0


On Mon, Mar 21, 2022 at 10:56 AM <vjudeu@gazeta.pl> wrote:

> 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?

It is simple. If you vote by making transactions, then someone could =
capture 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 "signet 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_RETURN <commitment>" in TapScript, just to save =
commitments. Then, even if someone is not in your network from the very =
beginning, that person could still collect commitments and find out how =
they are connected with on-chain transactions.

> Perhaps one day it could =
be used for something 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 set of responders.

If it will be ever implemented, it =
should be done in a similar way as difficulty: if you want 90%, you should =
calculate, what amount in satoshis is needed 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 have a system, where you =
can compare uint64 amounts to quickly get "yes/no" answer to the question, =
if something should be triggered (also, you can compress 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 all commitments of arbitrary size for=
 "free", so that on-chain transaction size 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 same way as LN nodes store data, you =
could use something else, it doesn't really matter, because on-chain =
commitments could be constructed in the same way (also, as long as the =
transaction creator keeps those commitments as a secret, there is no way to=
 get them; that means you can add them later if needed 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 tied to the fulfillment of the forwarding =
request.


You're right that there's some nuance there. You could add a =
block hash into the poll message and define things so any subsequent poll =
message sent with 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/opposition 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 =
wants 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 be handled without any commitment to the blockchain. A simple =
thing to do would be to simply invalidate poll messages that conflict (ie =
include them both 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 produce biased incomplete counts, since anyone can show a =
provably more complete 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 practically useful compared to recent poll data. So we =
can kind of side step things 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 trusted 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 =
access 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=
 signing, that's up to them as well. You could even mirror wallet-vault =
constructs by overriding a poll message signed with fewer key using one =
signed with more keys. The trade offs you bring up are reasonable =
considerations, and 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-binding nature of a poll makes the risks here pretty =
small for most situations you would want to use this in (eg in a soft-fork =
poll). It should be reasonable to consider any signed poll message valid, =
regardless of possibilities of theft or key renting shinanigans. Nacho keys=
 nacho coins would of course be important in this scenario.=C2=A0


>=C2=A0 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 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 having 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 necessary 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 that leaf would be a =
public key you can then verify the signaling signature against.=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 just 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 signature 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 separate 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 primarily suggesting this as a method=
 to help the debate about a soft fork have better information about what =
broader users think about a particular soft fork proposal, so such data =
would simply inform whether or not we decide to continue work on an upgrade=
. I don't think you'd want to require any validation of this data by all =
full nodes, because the data could be hundreds of gigabytes in size (let's =
say 1 billion people respond). You'd have to run some kind of random =
sampling (more like actual proof of stake) to get this data 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 any bitcoin transaction involves =
proof of coin ownership.


I was pretty careful to avoid the word "voting",=
 since I'm not proposing that this be used with definite thresholds that =
trigger action, but more of an information gathering mechanism. Perhaps one=
 day it could be used for something 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 set 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 tool for resolving some contention.=C2=A0


But on that note, I was thinking that it might be interesting to have an =
optional human readable message into these poll messages. Those messages =
could be then read through to gain a better understanding of why people are=
 supporting and why people are rejecting a particular thing. It could =
inform how we might change how we explain a technical change to make it =
easier for less technical folks (who don't post on twitter) to understand. =
It could potentially=C2=A0give insight into an otherwise quiet majority (or=
 large minority).


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


Interesting. I'm not sure I fully grok his idea, but I think he was =
suggesting that a proof of stake consensus protocol pay attention to =
bitcoin transactions formatted in a particular way. I think I've hopefully =
clarified above 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% support: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, where the support and opposition responses=
 are weighted by the UTXO amount (and the 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 and 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 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 stops 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 lightning channels would, where each participant=
 disagrees with the other. They need to sign together, so they can have an =
agreement to sign for the fractions 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 any time.
I might agree that you have 90% of the channel and I have 10% of the =
channel right now, but if you then send a request to forward your funds out=
, I need to be able to invalidate the previous signal, one that is tied to =
the fulfillment 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, =
otherwise you could cheaty cheat your effective balance by moving your =
funds around.
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 spending for current addresses. But that could be fixed =
with a new address type that 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, with "hot" keys having partial access.
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 =
trusted 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 (consider 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 softfork, so you have a =
chicken-and-egg problem...

Regards,
ZmnSCPxj