From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C7BDCC000B for ; Wed, 16 Mar 2022 23:29:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B695860F6F for ; Wed, 16 Mar 2022 23:29:49 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO7L9taw-dVo for ; Wed, 16 Mar 2022 23:29: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 smtp3.osuosl.org (Postfix) with ESMTPS id F2C8260F6A for ; Wed, 16 Mar 2022 23:29:48 +0000 (UTC) Date: Wed, 16 Mar 2022 23:29:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1647473385; bh=lN25IhNyVMoNYn1jKKqNpVdL6RRXrEzv1U9JwDcfP4M=; 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=BPays0XI3WOjKEECGszCZOJiNT4Y9a58T+syeu/Harv4g2bmO6o0LBbq6ZY4Pd9CZ zMTOs4G6mQI9M3D5nYj9T4Prr24/WQaDsdpJDQhKm0DYowh6qbIQ89iY4cb4xiX6JV Q23vZmmPk4CHM/g5fkKxcl3CBCy/HoxNAla7mALT/d1wLNBgiANTdjfeUOzTYFFWq5 s6YEmpf58z6/yZTJooTPGLsEnhCdBbhzcejJiD75tDSCIx7faTcUS/jcPVrdCaKxDE QyhCtB6KbWl8XFNBHTMoDsHsqzsl6oMxfAl3VlCymqyErHyZbhcHS9GLvKWvB4/J8G FfHhmk+QOptZQ== To: darosior , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <8Mc_c0hIjnY5JmWk7h9ttnnXF5NqBTKIDtFBIqZ7kg3J444fZrcG25UZvSkG4aeB0ZXGmSmZQHotwKonP1FL_lW3y2_bj7DJJPDM8M8r60s=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Wed, 16 Mar 2022 23:29:49 -0000 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 h= igher the DOS risk (as you duplicate > the key).. That's why i asked if anybody had some thoughts about this and= 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 m= ultiple versions of a transaction with varying feerates. And you have a set of network monitors / watchtowers that are supposed to w= atch the chain on your behalf in case your ISP suddenly hates you for no re= ason. The more monitors there are, the more likely that one of them will be corru= pted by a miner and jump to the highest-feerate version, overpaying fees an= d making miners very happy. Such is third-party trust. Is my understanding correct? A cleverer way, which requires consolidating (but is unable to eliminate) t= hird-party trust, would be to use a DLC oracle. The DLC oracle provides a set of points corresponding to a set of feerate r= anges, and commits to publishing the scalar of one of those points at some = particular future block height. Ostensibly, the scalar it publishes is the one of the point that correspond= s to the feerate range found at that future block height. You then create adaptor signatures for each feerate version, corresponding = to the feerate ranges the DLC oracle could eventually publish. The adaptor signatures can only be completed if the DLC oracle publishes th= e corresponding scalar for that feerate range. You can then send the adaptor signatures to multiple watchtowers, who can o= nly publish one of the feerate versions, unless the DLC oracle is hacked an= d publishes multiple scalars (at which point the DLC oracle protocol reveal= s a privkey of the DLC oracle, which should be usable for slashing some bon= d of the DLC oracle). This prevents any of them from publishing the highest-feerate version, as t= he adaptor signature cannot be completed unless that is what the oracle pub= lished. 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 maybe = not so clever. Regards, ZmnSCPxj