From: Billy Tetrud <billy.tetrud@gmail•com>
To: vjudeu@gazeta•pl
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy Trial
Date: Tue, 22 Mar 2022 10:19:30 -0500 [thread overview]
Message-ID: <CAGpPWDa1Ax0S0Op20Wi0VPohALL9y-62iETOF3d1FgGqxh-tdQ@mail.gmail.com> (raw)
In-Reply-To: <159790950-91b98cf7c46005fc096979a329d90e1b@pmq1v.m5r2.onet>
[-- Attachment #1: Type: text/plain, Size: 15393 bytes --]
> 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
>
[-- Attachment #2: Type: text/html, Size: 16796 bytes --]
next prev parent reply other threads:[~2022-03-22 15:19 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 [this message]
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=CAGpPWDa1Ax0S0Op20Wi0VPohALL9y-62iETOF3d1FgGqxh-tdQ@mail.gmail.com \
--to=billy.tetrud@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vjudeu@gazeta$(echo .)pl \
/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