path: root/cc/7020927b6001695188a6fc70f52785dad1c86f

Return-Path: <fresheneesz@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 82FE6C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 15:19:52 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 63C8084772
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 15:19:52 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id gVbqsF_-anUc
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 15:19:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com
 [IPv6:2a00:1450:4864:20::62d])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 1C1E38474A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 15:19:50 +0000 (UTC)
Received: by mail-ej1-x62d.google.com with SMTP id bi12so36972194ejb.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 08:19:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=AG3J8hEhwjJY36NQvZX8HSLZF2XOpjb9+aH3GrwBr00=;
 b=CHAXxHHxScKXPUhCrr6IWVrJGzE+Cpyvty88Setf0+qKq3cAl9xU77BjaN0D/4Zbr1
 xeNforYfdw2sk8mAVfkfUu5USq2Bf724Lx0Sy7ryR+C2UfGgpBxonjtpIwFdMVETKG5v
 DGo6L6LUmSXnvgOJ4oj1qgeTmI3eeoJm6N1l2tHXDPJMEJ1t2Ru6JTlJe9wOT0o/p4Wr
 vWn5VNmDLIlWcewb2XLShCewVbRs3vn9RVu8YIkvgYdeZJl2SjtWt4cTAnxzrgCq+x1g
 fL8RWtPS/ajWWb9g03kg4ibir9tj/Sw5hO2tcNUDDzHw7pe0ncRRhLtrtYMCVbpbgAHF
 cgZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=AG3J8hEhwjJY36NQvZX8HSLZF2XOpjb9+aH3GrwBr00=;
 b=YBX35SiHsPQnFJsP+Gh3Y4seYNkvvf5iS/35mQKHXcHT6kKUfsWRo06pcbEzjWiQNa
 pSQVf0S7P9RYDA9B4N109zwZn3x72GC9SsfB3l1VRDl5FeiKmLSKt5/XGTT+ryvv30rp
 IuMjKafM4q6Bx4bCUYmjMpsC5yiBeUw1TxEvSlbzm7SDaqjrlgHX8Rnt2jaNyQWS9Wm7
 3jlohQuldv5tFNJe/tPWoJUJXlHLvXPDnwe1oP8FkmnAD+2T76zWJi6xfFvhEiSJlh+M
 mHx8jUuEZCio+UN49C8MM7UhSjt7hygdTkCSlfW4E8RQim7PU5CIDBeJEtY5toCIwtQv
 iQmw==
X-Gm-Message-State: AOAM530+lCICZ9IK5PUewBikKAuoyxQUKlx6oW26xPG5ONjeZxi0lpjW
 SnWm1wOiTvz7k9AICWc14uYQks0Eq0xlf+FGTjQ=
X-Google-Smtp-Source: ABdhPJwQoYrT6C4EveIw97UHpFg+DJrTylw5yKIKSZin4Ciqvhgm2whpl5PLmiLF2RLFb2bYrGjq3gZ268wBV2X3rCw=
X-Received: by 2002:a17:906:9741:b0:6da:c274:6b18 with SMTP id
 o1-20020a170906974100b006dac2746b18mr26047418ejy.207.1647962387979; Tue, 22
 Mar 2022 08:19:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDZjdF1DQ6MrGDgq+2dz4+HJKP1FZDmMJ=UvmUDF1QUzjA@mail.gmail.com>
 <159790950-91b98cf7c46005fc096979a329d90e1b@pmq1v.m5r2.onet>
In-Reply-To: <159790950-91b98cf7c46005fc096979a329d90e1b@pmq1v.m5r2.onet>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 22 Mar 2022 10:19:30 -0500
Message-ID: <CAGpPWDa1Ax0S0Op20Wi0VPohALL9y-62iETOF3d1FgGqxh-tdQ@mail.gmail.com>
To: vjudeu@gazeta.pl
Content-Type: multipart/alternative; boundary="000000000000bd2c6c05dad02429"
X-Mailman-Approved-At: Tue, 22 Mar 2022 15:23:23 +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 15:19:52 -0000

--000000000000bd2c6c05dad02429
Content-Type: text/plain; charset="UTF-8"

>  If you vote by making transactions, then someone could capture that and
broadcast to nodes
>  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?

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

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,
>
>
> >  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.
>
>
> Or you could remove the ability to specify fractional 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 messages, 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 as 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.
>
>
> >  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 taproot 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.
>
>
> @vjudeu
>
> > It should not be expressed in percents, but in amounts
>
>
> Agreed. You make a good case for that.
>
>
> > it 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.
>
> 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 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
>
> 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.
>
>
> > 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.
>
>
> 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 give insight into an otherwise quiet majority (or large
> minority).
>
>
> > it sounds similar to "Merged Signing"
>
>
> 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 coin-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.
> >
> > 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.
> >
> > 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).
>
> 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.
>
> 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
>

--000000000000bd2c6c05dad02429
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt;=C2=A0

If you vote by making transactions, then someone could capture that and bro=
adcast to nodes<div>&gt;=C2=A0

you can only send that to your network<br><div><br></div><div>What do you m=
ean &quot;capture that&quot; and &quot;your network&quot;? I was imagining =
a scenario where these poll messages are always broadcast globally. Are you=
 implying more of a private poll?</div></div><div><br></div><div>&gt; If it=
 will be sent anywhere else, it will be invalid</div><div><br></div><div>I =
still don&#39;t understand. Why would a signed transaction be invalid anywh=
ere? Wouldn&#39;t a signed transaction be valid everywhere?=C2=A0</div><div=
><br></div><div>&gt; Another reason to sign transactions and not just some =
custom data is to make it compatible with &quot;signet way of making signat=
ures&quot;, the same as used in signet challenge.</div><div><br></div><div>=
Perhaps I don&#39;t understand how signet works well enough to understand t=
his, but I would think that signing an message would work with signet just =
as well as mainnet. I get the feeling perhaps we&#39;re misunderstanding ea=
ch other in some fundamental way.</div><div><br></div><div>&gt; Even if it =
is not needed, it is kind of &quot;free&quot; if you take transaction size =
into account</div><div><br></div><div>But it would require an on-chain tran=
saction. We don&#39;t want 6 billion people to have to send an on-chain tra=
nsaction all in the same week in order to register their preference on some=
thing.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Mon, Mar 21, 2022 at 10:56 AM &lt;<a href=3D"mailto:vj=
udeu@gazeta.pl" target=3D"_blank">vjudeu@gazeta.pl</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">&gt; I don&#39;t quite un=
derstand this part. I don&#39;t understand how this would make your signatu=
re useless in a different context. Could you elaborate?<br>
<br>
It is simple. If you vote by making transactions, then someone could captur=
e that and broadcast to nodes. If your signature is &quot;useless in a diff=
erent context&quot;, then you can only send that to your network. If it wil=
l be sent anywhere else, it will be invalid, so also useless. Another reaso=
n to sign transactions and not just some custom data is to make it compatib=
le with &quot;signet way of making signatures&quot;, the same as used in si=
gnet challenge.<br>
<br>
&gt; I don&#39;t think any kind of chain is necessary to store this data.<b=
r>
<br>
Even if it is not needed, it is kind of &quot;free&quot; if you take transa=
ction size into account. Because each person moving coins on-chain could at=
tach &quot;OP_RETURN &lt;commitment&gt;&quot; in TapScript, just to save co=
mmitments. Then, even if someone is not in your network from the very begin=
ning, that person could still collect commitments and find out how they are=
 connected with on-chain transactions.<br>
<br>
&gt; Perhaps one day it could be used for something akin to voting, but cer=
tainly if we were going to implement this to help decide on the next soft f=
ork, it would very likely be a quite biased set of responders.<br>
<br>
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 &quot;yes/=
no&quot; answer to the question, if something should be triggered (also, yo=
u can compress it to 32 bits in the same way as 256-bit target is compresse=
d).<br>
<br>
&gt; But on that note, I was thinking that it might be interesting to have =
an optional human readable message into these poll messages.<br>
<br>
As I said, &quot;OP_RETURN &lt;commitment&gt;&quot; inside TapScript is eno=
ugh to produce all commitments of arbitrary size for &quot;free&quot;, so t=
hat on-chain transaction size is constant, no matter how large that commitm=
ent 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 some=
thing else, it doesn&#39;t really matter, because on-chain commitments coul=
d 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 mean=
s you can add them later if needed and easily pretend that &quot;it was alw=
ays possible&quot;).<br>
<br>
<br>
On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev &lt;<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
Good Evening ZmnSCPxj,<br>
<br>
<br>
&gt;=C2=A0 I need to be able to invalidate the previous signal, one that is=
 tied to the fulfillment of the forwarding request.<br>
<br>
<br>
You&#39;re right that there&#39;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 w=
ith that hash and later blocks. That way if a channel balance changes signi=
ficantly, a new poll message can be sent out.=C2=A0<br>
<br>
<br>
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.<br>
<br>
<br>
&gt; if the signaling is done onchain<br>
<br>
<br>
I don&#39;t think any of this signaling needs to be done on-chain. Anyone w=
ho 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 possi=
ble for one person to send out many conflicting poll messages, but this cou=
ld be handled without any commitment to the blockchain. A simple thing to d=
o would be to simply invalidate poll messages that conflict (ie include the=
m both in your list of counted=C2=A0messages, but ignore them in your weigh=
ted-sums of poll preferences). As long as these polls are simply used to in=
form action rather than to trigger action, it should be ok that someone can=
 produce biased incomplete counts, since anyone can show a provably more co=
mplete set (a superset) of poll messages. Also, since this would generally =
be a time-bound thing, where this poll information would for example be use=
d to gauge support for a soft fork, there isn&#39;t much of a need to keep =
the poll messages on an immutable ledger. Old poll data is inherently not v=
ery practically useful compared to recent poll data. So we can kind of side=
 step things like history attacks by simply ignoring polls that aren&#39;t =
recent.<br>
<br>
<br>
&gt; Semantically, we would consider the &quot;cold&quot; key to be the &qu=
ot;true&quot; owner of the fund, with &quot;hot&quot; key being delegates w=
ho are semi-trusted, but not as trusted as the &quot;cold&quot; key.<br>
<br>
<br>
I&#39;m not sure I agree with those semantics as a hard rule. I don&#39;t c=
onsider a &quot;key&quot; 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 o=
r wallet vault can define whatever semantics they want. If they want to des=
ignate a hot key=C2=A0as their poll-signing key, that&#39;s their prerogati=
ve. If they want to require a cold-key as their message-signing key or even=
 require multisig signing, that&#39;s up to them as well. You could even mi=
rror 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 reaso=
nable considerations, and I think which trade offs to choose may vary by th=
e individual in question and their individual situation. However, I think t=
he 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, r=
egardless of possibilities of theft or key renting shinanigans. Nacho keys =
nacho coins would of course be important in this scenario.=C2=A0<br>
<br>
<br>
&gt;=C2=A0 if I need to be able to somehow indicate that a long-term-cold-s=
torage UTXO has a signaling pubkey, I imagine this mechanism of indioating =
might itself require a softfork, so you have a chicken-and-egg problem...<b=
r>
<br>
<br>
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&#39;ve done soft forks befor=
e having this mechanism, and if necessary we could do another one to enable=
 it.<br>
<br>
<br>
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<br>
<br>
<br>
@vjudeu<br>
<br>
&gt; It should not be expressed in percents, but in amounts<br>
<br>
<br>
Agreed. You make a good case for that.<br>
<br>
<br>
&gt;=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 yo=
ur message as &quot;OP_RETURN &lt;commitment&gt;&quot; in your input, in th=
is way your signature would be useless in a different context than voting.<=
br>
=C2=A0<br>
I don&#39;t quite understand this part. I don&#39;t understand how this wou=
ld make your signature useless in a different context. Could you elaborate?=
<br>
=C2=A0<br>
&gt;=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<br>
=C2=A0<br>
I don&#39;t think any kind of chain is necessary to store this data. I&#39;=
m primarily suggesting this as a method to help the debate about a soft for=
k have better information about what broader users think about a particular=
 soft fork proposal, so such data would simply inform whether or not we dec=
ide to continue work on an upgrade. I don&#39;t think you&#39;d want to req=
uire any validation of this data by all full nodes, because the data could =
be hundreds of gigabytes in size (let&#39;s say 1 billion people respond). =
You&#39;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<br>
<br>
<br>
&gt; It would be Proof of Stake, where users would put their coins at stake=
 to vote.<br>
<br>
<br>
Sure, as long as by this you mean simply proof of coin ownership. Just as a=
ny bitcoin transaction involves proof of coin ownership.<br>
<br>
<br>
I was pretty careful to avoid the word &quot;voting&quot;, since I&#39;m no=
t proposing that this be used with definite thresholds that trigger action,=
 but more of an information gathering mechanism. Perhaps one day it could b=
e used for something akin to voting, but certainly if we were going to impl=
ement 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 whe=
n deciding how to interpret the data. Even with biased data tho, it could b=
e a useful tool for resolving some contention.=C2=A0<br>
<br>
<br>
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&#39;t post on twitter) to understand. It could=
 potentially=C2=A0give insight into an otherwise quiet majority (or large m=
inority).<br>
<br>
<br>
&gt; it sounds similar to &quot;Merged Signing&quot;=C2=A0<br>
<br>
<br>
Interesting. I&#39;m not sure I fully grok his idea, but I think he was sug=
gesting that a proof of stake consensus protocol pay attention to bitcoin t=
ransactions formatted in a particular way. I think I&#39;ve hopefully clari=
fied above why the idea I&#39;m suggesting is rather different from this (e=
g in that no special commitments need to be made).<br>
<br>
<br>
Cheers,<br>
BT<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Fri, Mar 18, 2022 at 6:01 PM ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@pro=
tonmail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br>
Good morning Billy,<br>
<br>
&gt; @Jorge<br>
&gt; &gt; Any user polling system is going to be vulnerable to sybil attack=
s.<br>
&gt;<br>
&gt; Not the one I&#39;ll propose right here. What I propose specifically i=
s a=C2=A0coin-weighted signature-based poll with the following components:<=
br>
&gt; A. Every pollee signs messages like &lt;utxo_id, {soft_fork: 9 oppose:=
90% support:10%}&gt; for each UTXO they want to respond to the poll with.<b=
r>
&gt; B. A signed message like that is valid only while that UTXO has not be=
en spent.<br>
&gt; C. Poll results are considered only at each particular block height, w=
here the support and opposition responses are weighted by the UTXO amount (=
and the support/oppose fraction in the message). This means you&#39;d basic=
ally see a rolling poll through the blockchain as new signed poll messages =
come in and as their UTXOs are spent.=C2=A0<br>
&gt;<br>
&gt; 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<=
br>
&gt;<br>
&gt; 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 chann=
el close as a last resort against an uncooperative partner as usual).=C2=A0=
<br>
<br>
This does not quite work, as lightning channel balances can be changed at a=
ny time.<br>
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.<br>
This begins to add complexity.<br>
<br>
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.<br>
But the point of LN is to avoid putting typical everyday forwards onchain.<=
br>
<br>
&gt; This does have the potential issue of public key exposure prior to spe=
nding for current addresses. But that could be fixed with a new address typ=
e that has two public keys / spend paths: one for spending and one for sign=
ing.=C2=A0<br>
<br>
This issue is particularly relevant to vault constructions.<br>
Typically a vault has a &quot;cold&quot; key that is the master owner of th=
e fund, with &quot;hot&quot; keys having partial access.<br>
Semantically, we would consider the &quot;cold&quot; key to be the &quot;tr=
ue&quot; owner of the fund, with &quot;hot&quot; key being delegates who ar=
e semi-trusted, but not as trusted as the &quot;cold&quot; key.<br>
<br>
So, we should consider a vote from the &quot;cold&quot; key only.<br>
However, the point is that the &quot;cold&quot; key wants to be kept offlin=
e as much as possible for security.<br>
<br>
I suppose the &quot;cold&quot; 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 schem=
e (consider that the point of vaults is to protect large funds).<br>
<br>
<br>
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...<br>
<br>
Regards,<br>
ZmnSCPxj<br>
</blockquote></div>

--000000000000bd2c6c05dad02429--