Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1CD14C000B for ; Mon, 21 Mar 2022 12:07:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 043484058D for ; Mon, 21 Mar 2022 12:07:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY5ForR_wSXo for ; Mon, 21 Mar 2022 12:06:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp2.osuosl.org (Postfix) with ESMTPS id 3065E40447 for ; Mon, 21 Mar 2022 12:06:58 +0000 (UTC) Date: Mon, 21 Mar 2022 12:06:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1647864415; bh=pU51Y3R2iqrVs/yyWZSTOepdUnlyAURFNYCEJx6gnQg=; 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=V8ewehXnE/DtI8oMVDhc3b6/K3q/U2rFjguoedcD8PwmpBUAXIYtsRU01rsBBZGuq lZL+W8Rn/Evvbica9fhsxLazII7s6Rr9uhO2TEScA/dil12h5gt16tqXybTsQUJ8Ki KPJiTQ04g4QQbgNpwjeMyggwMnWC3ehFhlxw25RGPLFfG0+i0LOjxjkKuy7qAiIIGc 1KPYegt2bNSEzZoizNQAa8naxSWIebu0esccxEvLBn4vV0ZuJJaB+Tw7FSxZ6diQvr 0WK5J69NFZV4xd1bjjiumBUVpuq35gI0E2qcvnLVCc5PX5EP5FIVyqpNJzrvguSLws 46JsUAnf6y6ZQ== To: ZmnSCPxj From: darosior Reply-To: darosior Message-ID: In-Reply-To: <8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com> References: <8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Mar 2022 12:36:50 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Covenants and feebumping 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 12:07:02 -0000 Hi ZmnSCPxj, Thanks for the feedback. The DLC idea is interesting but you are centralizi= ng the liveness requirements, effectively creating a SPOF: in order to bypass the revocation clause no ne= ed to make sure to down each and every watchtower anymore, just down the oracle and you are sure no revocati= on transaction can be pushed. > Okay, let me see if I understand your concern correctly. > When using a signature challenge, the concern is that you need to presign= multiple versions of a transaction with varying feerates. I was thinking of having a hot key (in this case probably shared amongst th= e monitors) where they would sign the right fee level at broadcast time. Pre-signing makes it quickly too man= y signatures (and kills the purpose of having covenants in the first place). > And you have a set of network monitors / watchtowers that are supposed to= watch the chain on your behalf in case your ISP suddenly hates you for no = reason. > The more monitors there are, the more likely that one of them will be cor= rupted by a miner and jump to the highest-feerate version, overpaying fees = and making miners very happy. > Such is third-party trust. > Is my understanding correct? Your understanding of the tradeoff is correct. ------- Original Message ------- Le jeudi 17 mars 2022 =C3=A0 12:29 AM, ZmnSCPxj a= =C3=A9crit : > Good morning Antoine, > > > For "hot contracts" a signature challenge is used to achieve the same. = I know the latter is imperfect, since > > > > the lower the uptime risk (increase the number of network monitors) the= higher the DOS risk (as you duplicate > > > > the key).. That's why i asked if anybody had some thoughts about this a= nd if there was a cleverer way of doing > > > > it. > > Okay, let me see if I understand your concern correctly. > > When using a signature challenge, the concern is that you need to presign= multiple versions of a transaction with varying feerates. > > And you have a set of network monitors / watchtowers that are supposed to= watch the chain on your behalf in case your ISP suddenly hates you for no = reason. > > The more monitors there are, the more likely that one of them will be cor= rupted by a miner and jump to the highest-feerate version, overpaying fees = and making miners very happy. > > Such is third-party trust. > > Is my understanding correct? > > A cleverer way, which requires consolidating (but is unable to eliminate)= third-party trust, would be to use a DLC oracle. > > The DLC oracle provides a set of points corresponding to a set of feerate= ranges, and commits to publishing the scalar of one of those points at som= e particular future block height. > > Ostensibly, the scalar it publishes is the one of the point that correspo= nds to the feerate range found at that future block height. > > You then create adaptor signatures for each feerate version, correspondin= g to the feerate ranges the DLC oracle could eventually publish. > > The adaptor signatures can only be completed if the DLC oracle publishes = the corresponding scalar for that feerate range. > > You can then send the adaptor signatures to multiple watchtowers, who can= only publish one of the feerate versions, unless the DLC oracle is hacked = and publishes multiple scalars (at which point the DLC oracle protocol reve= als a privkey of the DLC oracle, which should be usable for slashing some b= ond of the DLC oracle). > > This prevents any of them from publishing the highest-feerate version, as= the adaptor signature cannot be completed unless that is what the oracle p= ublished. > > There are still drawbacks: > > * Third-party trust risk: the oracle can still lie. > > * DLC oracles are prevented from publishing multiple scalars; they cannot= be prevented from publishing a single wrong scalar. > > * DLCs must be time bound. > > * DLC oracles commit to publishing a particular point at a particular fix= ed time. > > * For "hot" dynamic protocols, you need the ability to invoke the oracle = at any time, not a particular fixed time. > > The latter probably makes this unusable for hot protocols anyway, so mayb= e not so clever. > > Regards, > > ZmnSCPxj