From: vjudeu@gazeta•pl
To: Billy Tetrud <billy.tetrud@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy Trial
Date: Tue, 22 Mar 2022 16:37:01 +0000 [thread overview]
Message-ID: <3e4f7fa0-9a07-976b-ac6f-bd63232e928b@gazeta.pl> (raw)
In-Reply-To: <CAGpPWDa1Ax0S0Op20Wi0VPohALL9y-62iETOF3d1FgGqxh-tdQ@mail.gmail.com>
> 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:
> 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
next prev parent reply other threads:[~2022-03-22 16:37 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
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 [this message]
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=3e4f7fa0-9a07-976b-ac6f-bd63232e928b@gazeta.pl \
--to=vjudeu@gazeta$(echo .)pl \
--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