Date: Fri, 18 Mar 2022 23:01:43 +0000
To: Billy Tetrud <billy.tetrud@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <oQXPJ9nMW3rFcYu91HDjfzVJI3pS4rGHOl2zFoAWJ5YJRpgeqoUUtEv-2Xy5WkDuoPcQj4AMAV6jODB24ImqUohsnF0aFXgBFUhmDvjpwtU=@protonmail.com>
In-Reply-To: <CAGpPWDbHz=+6yEvEjouSPRBpUJqxquHf_izGEj8iVhfkLwOxcA@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Speedy Trial
Precedence: list

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