From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7CA0EC000B for ; Fri, 18 Mar 2022 23:01:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 5720884849 for ; Fri, 18 Mar 2022 23:01:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfv2ikeziERN for ; Fri, 18 Mar 2022 23:01:49 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) by smtp1.osuosl.org (Postfix) with ESMTPS id 8C3758480A for ; Fri, 18 Mar 2022 23:01:49 +0000 (UTC) Date: Fri, 18 Mar 2022 23:01:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1647644507; bh=1zoaYGzaSOfMab/6MFdpJGS818611PV8Biuh+iWcTfg=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=i4SJyZd976UMxxbCvkeVVydtmW0pS2O3UiDGgUipck6Ki1/S30EieEO7a+wzPJEeH HXbrzxe3DUvguSdE9o+5QHaypC6xFxUV+sW345bHHHiXnoxEO7wTeVGgRNGf/gFmkh NYeYrZqcb0cY4R8x2lPr29tT6IwQwG89ISI5mdKNYXwG0TJSWvzJR4y3TL+kaQDFkZ WFxIuB7PfyNbgLjy9d4upZT0c2UwnueLEQ0JLlgyDxyGKDGw5tv+UgVdh+FkyuB1DG 44H2/4WojIU7F2Ozi8y3i0ipEBrsSSzKda6b1cDMP7z/Sxv+jqvtZ5mdGh4iI5EizB GVNLLTLZPGmEw== To: Billy Tetrud , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 18 Mar 2022 23:01:50 -0000 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