From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Billy Tetrud <billy.tetrud@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy Trial
Date: Fri, 18 Mar 2022 23:01:43 +0000 [thread overview]
Message-ID: <oQXPJ9nMW3rFcYu91HDjfzVJI3pS4rGHOl2zFoAWJ5YJRpgeqoUUtEv-2Xy5WkDuoPcQj4AMAV6jODB24ImqUohsnF0aFXgBFUhmDvjpwtU=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDbHz=+6yEvEjouSPRBpUJqxquHf_izGEj8iVhfkLwOxcA@mail.gmail.com>
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
next prev parent reply other threads:[~2022-03-18 23:01 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 0:12 Russell O'Connor
2022-03-11 0:28 ` Luke Dashjr
2022-03-11 5:41 ` Billy Tetrud
2022-03-11 12:19 ` Jorge Timón
2022-03-11 13:47 ` Russell O'Connor
2022-03-11 14:04 ` Jorge Timón
2022-03-12 13:34 ` Russell O'Connor
2022-03-12 17:52 ` Billy Tetrud
2022-03-17 12:18 ` Jorge Timón
2022-03-23 22:34 ` Kate Salazar
2022-03-15 17:21 ` Jeremy Rubin
2022-03-17 4:17 ` Billy Tetrud
2022-03-18 18:36 ` Jorge Timón
2022-03-17 12:08 ` Jorge Timón
2022-03-17 15:38 ` Billy Tetrud
2022-03-18 23:01 ` ZmnSCPxj [this message]
2022-03-21 3:41 ` Billy Tetrud
2022-03-21 15:56 ` vjudeu
2022-03-22 15:19 ` Billy Tetrud
2022-03-22 15:45 ` Eric Voskuil
2022-03-22 16:37 ` vjudeu
2022-03-19 16:43 ` vjudeu
2022-03-15 15:45 ` Anthony Towns
2022-03-17 14:04 ` Jorge Timón
2022-03-22 23:49 ` Anthony Towns
2022-03-24 18:30 ` Jorge Timón
2022-03-26 1:45 ` Anthony Towns
2022-03-28 8:31 ` Jorge Timón
2022-03-30 4:21 ` Anthony Towns
2022-04-08 9:58 ` Jorge Timón
2022-04-11 13:05 ` Anthony Towns
2022-04-24 11:13 ` Jorge Timón
2022-04-24 12:14 ` Anthony Towns
2022-04-24 12:44 ` Jorge Timón
2022-04-25 16:11 ` Keagan McClelland
2022-04-25 17:00 ` Anthony Towns
2022-04-25 17:26 ` Keagan McClelland
2022-04-26 5:42 ` Anthony Towns
2022-04-26 13:05 ` Erik Aronesty
2022-04-27 2:35 ` Billy Tetrud
2022-03-11 16:26 ` Billy Tetrud
2022-03-17 11:32 ` Jorge Timón
2022-03-11 11:14 pushd
2022-03-12 17:11 pushd
2022-03-17 14:34 pushd
2022-03-26 12:59 pushd
2022-03-30 10:34 pushd
2022-03-30 20:10 ` Billy Tetrud
2022-03-30 21:14 ` pushd
2022-03-31 4:31 ` Billy Tetrud
2022-03-31 14:19 ` pushd
2022-03-31 15:34 ` Billy Tetrud
2022-03-31 15:55 ` pushd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='oQXPJ9nMW3rFcYu91HDjfzVJI3pS4rGHOl2zFoAWJ5YJRpgeqoUUtEv-2Xy5WkDuoPcQj4AMAV6jODB24ImqUohsnF0aFXgBFUhmDvjpwtU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox