From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B2E21C000B for ; Mon, 21 Mar 2022 15:56:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 9938A401D6 for ; Mon, 21 Mar 2022 15:56:16 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl 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 DdArKcG6WAv0 for ; Mon, 21 Mar 2022 15:56:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo41.poczta.onet.pl (smtpo41.poczta.onet.pl [213.180.142.172]) by smtp4.osuosl.org (Postfix) with ESMTPS id E56D04019F for ; Mon, 21 Mar 2022 15:56:14 +0000 (UTC) Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4KMfNj0WzTz1smH; Mon, 21 Mar 2022 16:56:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1647878165; bh=ghyZq8Pjxv7jvU96jJLQ+kCIik1J1dNF7N75lRuzA8E=; h=From:Cc:To:In-Reply-To:Date:Subject:From; b=fb2W7hqpOVbRms1RN17v2RGNkX/BXwQ18gHKTkPfUot2tr7IaMRBA3JUHsS0Bd2Lb iXwf4fjLKiCud/e08J4EGGzCAvAhE12k8nvIjhRiYf9DszGSndEUC0xPja+nNYBF3f vujOr0dM5/hO9Wi+gY2QhIBh4zhfLx8f9dmtM1IU= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.240.65] by pmq1v.m5r2.onet via HTTP id ; Mon, 21 Mar 2022 16:56:05 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: Billy Tetrud ,ZmnSCPxj In-Reply-To: Date: Mon, 21 Mar 2022 16:56:03 +0100 Message-Id: <159790950-91b98cf7c46005fc096979a329d90e1b@pmq1v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.240.65;PL;3 X-Mailman-Approved-At: Mon, 21 Mar 2022 16:03:31 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 15:56:16 -0000 > I don't quite understand this part. I don't understand how this would mak= e your signature useless in a different context. Could you elaborate? It is simple. If you vote by making transactions, then someone could captur= e 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 "s= ignet 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_R= ETURN " in TapScript, just to save commitments. Then, even if s= omeone is not in your network from the very beginning, that person could st= ill collect commitments and find out how they are connected with on-chain t= ransactions. > Perhaps one day it could be used for something akin to voting, but certai= nly 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 diffi= culty: if you want 90%, you should calculate, what amount in satoshis is ne= eded 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 ha= ve a system, where you can compare uint64 amounts to quickly get "yes/no" a= nswer to the question, if something should be triggered (also, you can comp= ress 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 " inside TapScript is enough to produce a= ll commitments of arbitrary size for "free", so that on-chain transaction s= ize 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 sa= me way as LN nodes store data, you could use something else, it doesn't rea= lly matter, because on-chain commitments could be constructed in the same w= ay (also, as long as the transaction creator keeps those commitments as a s= ecret, there is no way to get them; that means you can add them later if ne= eded and easily pretend that "it was always possible"). On 2022-03-21 10:17:29 user Billy Tetrud via bitcoin-dev wrote: Good Evening ZmnSCPxj, >=C2=A0 I need to be able to invalidate the previous signal, one that is ti= ed to the fulfillment of the forwarding request. You're right that there's some nuance there. You could add a block hash int= o the poll message and define things so any subsequent poll message sent wi= th 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.=C2=A0 Or you could remove the ability to specify=C2=A0fractional support/oppositi= on 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 w= ants 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 b= e handled without any commitment to the blockchain. A simple thing to do wo= uld be to simply invalidate poll messages that conflict (ie include them bo= th in your list of counted=C2=A0messages, 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 pro= duce biased incomplete counts, since anyone can show a provably more comple= te 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 prac= tically useful compared to recent poll data. So we can kind of side step th= ings 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 t= rusted 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 a= ccess 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= =C2=A0as 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 si= gning, that's up to them as well. You could even mirror wallet-vault constr= ucts by overriding a poll message signed with fewer key using one signed wi= th more keys. The trade offs you bring up are reasonable considerations, an= d 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-bi= nding nature of a poll makes the risks here pretty small for most situation= s you would want to use this in (eg in a soft-fork poll). It should be reas= onable to consider any signed poll message valid, regardless of possibiliti= es of theft or key renting shinanigans. Nacho keys nacho coins would of cou= rse be important in this scenario.=C2=A0 >=C2=A0 if I need to be able to somehow indicate that a long-term-cold-stor= age UTXO has a signaling pubkey, I imagine this mechanism of indioating mig= ht 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 ha= ving this mechanism, and if necessary we could do another one to enable it. However, I think=C2=A0taproot can enable this mechanism without a soft fork= . It should be possible to include a taproot leaf that has the data necessa= ry 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 th= at leaf would be a public key you can then verify the signaling signature a= gainst.=C2=A0 @vjudeu > It should not be expressed in percents, but in amounts Agreed. You make a good case for that. >=C2=A0it could be just some kind of transaction, where you have utxo_id ju= st as transaction input, amount of coins as some output, and then add your = message as "OP_RETURN " in your input, in this way your signatu= re would be useless in a different context than voting. =C2=A0 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? =C2=A0 >=C2=A0it does not really matter if you store that commitments on-chain to = preserve signalling results in consensus rules or if there would be some se= parate chain for storing commitments and nothing else =C2=A0 I don't think any kind of chain is necessary to store this data. I'm primar= ily suggesting this as a method to help the debate about a soft fork have b= etter information about what broader users think about a particular soft fo= rk proposal, so such data would simply inform whether or not we decide to c= ontinue work on an upgrade. I don't think you'd want to require any validat= ion of this data by all full nodes, because the data could be hundreds of g= igabytes in size (let's say 1 billion people respond). You'd have to run so= me kind of random sampling (more like actual proof of stake) to get this da= ta down to a manageable size.=C2=A0 > 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 a= ny bitcoin transaction involves proof of coin ownership. I was pretty careful to avoid the word "voting", since I'm not proposing th= at this be used with definite thresholds that trigger action, but more of a= n information gathering mechanism. Perhaps one day it could be used for som= ething 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 s= et 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 too= l for resolving some contention.=C2=A0 But on that note, I was thinking that it might be interesting to have an op= tional human readable message into these poll messages. Those messages coul= d be then read through to gain a better understanding of why people are sup= porting and why people are rejecting a particular thing. It could inform ho= w we might change how we explain a technical change to make it easier for l= ess technical folks (who don't post on twitter) to understand. It could pot= entially=C2=A0give insight into an otherwise quiet majority (or large minor= ity). > it sounds similar to "Merged Signing"=C2=A0 Interesting. I'm not sure I fully grok his idea, but I think he was suggest= ing that a proof of stake consensus protocol pay attention to bitcoin trans= actions formatted in a particular way. I think I've hopefully clarified abo= ve 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 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=C2= =A0coin-weighted signature-based poll with the following components: > A. Every pollee signs messages like 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