path: root/95/0b9bd3407ffcd34ae6eea0fd4e5694ca5de49c

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 18916C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 03:42:02 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id EF39D40916
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 03:42:01 +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: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 Oa9Wv8ONfB2z
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 03:42:00 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com
 [IPv6:2a00:1450:4864:20::62b])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 36C27408C6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Mar 2022 03:42:00 +0000 (UTC)
Received: by mail-ej1-x62b.google.com with SMTP id j15so13266835eje.9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 20 Mar 2022 20:42:00 -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=xbdgvTmFcTHNDaG1VV4jxfegbVsPTgijr1EGoiFt/p8=;
 b=QFVK0+ACYCJQF+uIHLPPg/9eU0KGfr9KlCnaXlqA4DEyMwWoiXqzJhMJqJhOjomzIB
 GAJpulz8lnVJBLjL9LVFKY9RdUq3K5BnphshMAbN70VtLgPpRFAoUwdehKU5FD1MFuvw
 uzT5GyXZMiPEFc1y7xGNW3dgUJUuI0epepSYPQOEs8DkU+T5oGqvKBao7gy7v0ya4jH8
 Qs5jCq4KAFTgjlsgaJSClfNTwaN2n31EgxXIwJbhdyzveOgxoh4N1UwH9W1PCf+82VYJ
 Se0FrQKvVXyh6mJGt5Dl6WPCTc7VeXbI1DefZ2heEWoTRMnttv6YSZQvBh0iv2ddNX0h
 mfnw==
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=xbdgvTmFcTHNDaG1VV4jxfegbVsPTgijr1EGoiFt/p8=;
 b=z6oPGmgBNqRN7NlzXCvEBlDfAUxh4DZZcGyHHcsT8K26rv5YwG2v+oRsqZNagO5VB6
 GMTc9Tx2AHe5dbZnIqV8fbhw3J+G0FvpcBC/O4PiOeHTmadwuBboL/30Xm5mg0nGRTkN
 YLPIYFgwtfeAhukwbwsS8T2WVTj3X/3C4EITX7+o3ztjz9TBS87TyPqL/QBXEUb9Vanh
 TIGw1yOy5CYnbGu+8wlO5rmqIcOBcj21pfbhQzGYTwn6gTOk812fh8+L6ttupD+7oRLP
 0234cCg1Xt1i5lFxY/Exe7+AL16sdqxPCsvBF7rcD6k47NGGytUYz0VKoJUIPzC2S1wx
 FuaQ==
X-Gm-Message-State: AOAM5323mim01hKGKeGNXahm4on/MgiYdX8kviiQFX+uJzqyvjk6f+S7
 trMcjRLMlM3Qf53IzixP1S23LHW98Af3aoGNkA6d61Ts
X-Google-Smtp-Source: ABdhPJzlWw58eAYz3jRzY0OZQRjsjGZFjtMo8T0rvV0GqFWf3bD/1ibmJrSMUKE6yaXtm/F10e4xINQKxsjHZjBFFHY=
X-Received: by 2002:a17:906:4fc7:b0:6da:92b2:f572 with SMTP id
 i7-20020a1709064fc700b006da92b2f572mr18968736ejw.184.1647834118316; Sun, 20
 Mar 2022 20:41:58 -0700 (PDT)
MIME-Version: 1.0
References: <CAMZUoKkTDjDSgnqhYio8Lnh-yTdsNAdXbDC9RQwnN00RdbbL6w@mail.gmail.com>
 <CABm2gDrdoD3QZ=gZ_nd7Q+AZpetX32dLON7pfdC4aAwpLRd4xA@mail.gmail.com>
 <CAMZUoK=kpZZw++WmdRM0KTkj6dQhmtsanm9eH1TksNwypKS8Zw@mail.gmail.com>
 <CABm2gDpFFg47Ld3HHhTq2SVTaCusm1ybDpEmvKV=S3cFTAQwoA@mail.gmail.com>
 <CAMZUoKkPF6gPGpDWy1U+0GCONF-_qsTcOz0S1X+vx8_Kfqr8mw@mail.gmail.com>
 <CABm2gDpFCcNcJEwia-nBhpWSjQv7DPEpqTu-bRC8RDHaoDU-=g@mail.gmail.com>
 <CAGpPWDbHz=+6yEvEjouSPRBpUJqxquHf_izGEj8iVhfkLwOxcA@mail.gmail.com>
 <oQXPJ9nMW3rFcYu91HDjfzVJI3pS4rGHOl2zFoAWJ5YJRpgeqoUUtEv-2Xy5WkDuoPcQj4AMAV6jODB24ImqUohsnF0aFXgBFUhmDvjpwtU=@protonmail.com>
In-Reply-To: <oQXPJ9nMW3rFcYu91HDjfzVJI3pS4rGHOl2zFoAWJ5YJRpgeqoUUtEv-2Xy5WkDuoPcQj4AMAV6jODB24ImqUohsnF0aFXgBFUhmDvjpwtU=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 20 Mar 2022 22:41:42 -0500
Message-ID: <CAGpPWDZjdF1DQ6MrGDgq+2dz4+HJKP1FZDmMJ=UvmUDF1QUzjA@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="00000000000045671305dab24769"
X-Mailman-Approved-At: Mon, 21 Mar 2022 09:17:13 +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 03:42:02 -0000

--00000000000045671305dab24769
Content-Type: text/plain; charset="UTF-8"

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
>

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

<div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"ltr"><div>Good Evening ZmnSC=
Pxj,</div><div><br></div>&gt;=C2=A0

I need to be able to invalidate the previous signal, one that is tied to th=
e fulfillment of the forwarding request.<div><br></div><div>You&#39;re righ=
t that there&#39;s some nuance there. You could add a block hash into the p=
oll message and define things so any subsequent poll message sent with a ne=
wer block hash overrides the old poll message at the block with that hash a=
nd later blocks. That way if a channel balance changes significantly, a new=
 poll message can be sent out.=C2=A0</div><div><br></div><div>Or you could =
remove the ability to specify=C2=A0fractional support/opposition and exclud=
e multiparty UTXOs from participation. I tend to like the idea of the possi=
bility of full participation tho, even in a world that mainly uses lightnin=
g.</div><div><br></div><div>&gt; if the signaling is done onchain</div><div=
><br></div><div>I don&#39;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 tog=
ether all these poll messages and count up the weighted preferences. Yes, i=
t would be possible for one person to send out many conflicting poll messag=
es, but this could be handled without any commitment to the blockchain. A s=
imple 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 th=
em in your weighted-sums of poll preferences). As long as these polls are s=
imply 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 fo=
r example be used 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 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&#39;t recent.</div><div><br></div><div>&gt; Semantically, we woul=
d consider the &quot;cold&quot; key to be the &quot;true&quot; owner of the=
 fund, with &quot;hot&quot; key being delegates who are semi-trusted, but n=
ot as trusted as the &quot;cold&quot; key.</div><div><br></div><div>I&#39;m=
 not sure I agree with those semantics as a hard rule. I don&#39;t consider=
 a &quot;key&quot; to be an owner of anything. A person owns a key, which g=
ives them access to funds. A key is a tool, and the owner of a key or walle=
t vault can define whatever semantics they want. If they want to designate =
a hot key=C2=A0as their poll-signing key, that&#39;s their prerogative. If =
they want to require a cold-key as their message-signing key or even requir=
e multisig signing, that&#39;s up to them as well. You could even mirror wa=
llet-vault constructs by overriding a poll message signed with fewer key us=
ing one signed with more keys. The trade offs you bring up are reasonable c=
onsiderations, and I think which trade offs to choose may vary by the indiv=
idual 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 f=
or 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, regardle=
ss of possibilities of theft or key renting shinanigans. Nacho keys nacho c=
oins would of course be important in this scenario.=C2=A0</div><div><br></d=
iv><div>&gt;=C2=A0 if I need to be able to somehow indicate that a long-ter=
m-cold-storage UTXO has a signaling pubkey, I imagine this mechanism of ind=
ioating might itself require a softfork, so you have a chicken-and-egg prob=
lem...</div><div><br></div><div>If such a thing did need a soft fork, the c=
hicken and egg question would be easy to answer: the soft fork comes first.=
 We&#39;ve done soft forks before having this mechanism, and if necessary w=
e could do another one to enable it.</div><div><br></div><div>However, I th=
ink=C2=A0taproot can enable this mechanism without a soft fork. It should b=
e possible to include a taproot leaf that has the data necessary to validat=
e a signaling signature. The tapleaf would contain an invalid script that h=
as an alternative interpretation, where your poll message can include the m=
erkle 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=
</div><div><br></div><div dir=3D"auto">@vjudeu</div><br><span style=3D"font=
-size:12.8px">&gt; It should not be expressed in percents, but in amounts</=
span><div dir=3D"auto"><br></div><div dir=3D"auto">Agreed. You make a good =
case for that.</div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt;=C2=
=A0<span style=3D"font-size:12.8px">it could be just some kind of transacti=
on, where you have utxo_id just as transaction input, amount of coins as so=
me output, and then add your message as &quot;OP_RETURN &lt;commitment&gt;&=
quot; in your input, in this way your signature would be useless in a diffe=
rent context than voting.</span></div><div dir=3D"auto"><span style=3D"font=
-size:12.8px"><br></span></div><div dir=3D"auto"><span style=3D"font-size:1=
2.8px">I don&#39;t quite understand this part. I don&#39;t understand how t=
his would make your signature useless in a different context. Could you ela=
borate?</span></div><div dir=3D"auto"><span style=3D"font-size:12.8px"><br>=
</span></div><div dir=3D"auto">&gt;=C2=A0<span style=3D"font-size:12.8px">i=
t 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 c=
hain for storing commitments and nothing else</span></div><div dir=3D"auto"=
><span style=3D"font-size:12.8px"><br></span></div><div dir=3D"auto"><span =
style=3D"font-size:12.8px">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 fork have better information about what broader use=
rs think about a particular soft fork proposal, so such data would simply i=
nform whether or not we decide to continue work on an upgrade. I don&#39;t =
think you&#39;d want to require any validation of this data by all full nod=
es, 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 sampli=
ng (more like actual proof of stake) to get this data down to a manageable =
size.=C2=A0</span></div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; =
It would be Proof of Stake, where users would put their coins at stake to v=
ote.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Sure, as long as by=
 this you mean simply proof of coin ownership. Just as any bitcoin transact=
ion involves proof of coin ownership.</div><div dir=3D"auto"><br></div><div=
 dir=3D"auto">I was pretty careful to avoid the word &quot;voting&quot;, si=
nce I&#39;m not proposing that this be used with definite thresholds that t=
rigger 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 ver=
y likely be a quite biased set of responders. We would want to take that in=
to account when deciding how to interpret the data. Even with biased data t=
ho, it could be a useful tool for resolving some contention.=C2=A0</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">But on that note, I was thinking=
 that it might be interesting to have an optional human readable message in=
to these poll messages. Those messages could be then read through to gain a=
 better understanding of why people are supporting and why people are rejec=
ting 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&#39=
;t post on twitter) to understand. It could potentially=C2=A0give insight i=
nto an otherwise quiet majority (or large minority).</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">&gt; it sounds similar to &quot;Merged Signing=
&quot;=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Interesting=
. I&#39;m not sure I fully grok his idea, but I think he was suggesting tha=
t a proof of stake consensus protocol pay attention to bitcoin transactions=
 formatted in a particular way. I think I&#39;ve hopefully clarified above =
why the idea I&#39;m suggesting is rather different from this (eg in that n=
o special commitments need to be made).</div><div dir=3D"auto"><br></div><d=
iv>Cheers,</div><div>BT</div><div><br></div><div><br></div><div><br></div><=
div><br></div><div><br></div><div><br></div></div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 18, 2022 at 6:01 PM=
 ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonmail.com" rel=3D"noreferrer =
noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer" target=
=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">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></div>
</div>

--00000000000045671305dab24769--