From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CB6608DC for ; Wed, 22 May 2019 06:04:35 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D37AB6C5 for ; Wed, 22 May 2019 06:04:34 +0000 (UTC) Date: Wed, 22 May 2019 06:04:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1558505072; bh=B7HG4Zb+h+F2NgmpZz7xsvpJAsGTB5glTAT/596V/Rg=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=U39q3RQZSaY1WeK+rbhLGFs+K01P+MguwihvzmWEPWxJS9RvXd8K3wuS8dM7v6imr vFgEfwkhMA8q/jUZJ23FnCX8EJBDJLt8l4Or+gqEoVAKTcCcAseYl7xBewYk4uBlQk /p8MuUXw5lTwjPwJrbZ1dbCxh6BIGLV3JV4SNMzI= To: Jeremy From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 22 May 2019 13:30:30 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Congestion Control via OP_CHECKOUTPUTSHASHVERIFY proposal X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 06:04:35 -0000 Good morning, Some more comments. * I do not think CoinJoin is much improved by this opcode. Typically, you would sign off only if one of the outputs of the CoinJoin = transaction is yours, and this does not really improve this situation. * Using this for congestion control increases blockchain usage by one TXO a= nd one input, ending up with *more* bytes onchain, and a UTXO that will be = removed later in (we hope) short time. I do not know if this is a good idea, to increase congestion by making un= necessary intermediate transaction outputs, at times when congestion is a p= roblem. * I cannot find a way to implement Decker-Russell-Osuntokun (or any offchai= n update mechanism) on top of this opcode, so I cannot support replacing `S= IGHASH_NOINPUT` with this opcode. In particular, while the finite loop support by this opcode appears (at f= irst glance) to be useable as the "stepper" for an offchain update mechanis= m, I cannot find a good way to short-circuit the transaction chain without = `SIGHASH_NOINPUT` anyway. * Channel factories created by this opcode do not, by themselves, support u= pdates to the channel structure. But such simple "close only" channel factories can be done using n-of-n a= nd a pre-signed offchain transaction (especially since the entities interes= ted in the factory are known and enumerable, and thus can be induced to sig= n in order to enter the factory). More complex channel factories that can update the division of the factor= y to channels cannot be done without a multiparty offchain update mechanism= such as Decker-Wattenhofer or Decker-Russell-Osuntokun. So, similarly to CoinJoin, I do not think it is much improved by this opc= ode. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Wednesday, May 22, 2019 1:11 PM, Jeremy wrote: > Morning, > > Yes, in general, Bitcoin does not do anything to prevent users from disca= rding their keys. > > I don't think this will be fixed anytime soon. > > There are some protocols where, though, knowing that a key was once known= to the recipients may make it legally valid to inflict a punitive measure = (e.g., via HTLC), whereas if the key was never known that might be a breach= of contract for the payment provider. > > Best, > > Jeremy > > On Tue, May 21, 2019 at 7:52 PM ZmnSCPxj wrote: > > > Good morning Jeremy, > > > > >If a sender needs to know the recipient can remove the covenant before= spending, they may request a signature of an challenge string from the rec= ipients > > > > The recipients can always choose to destroy the privkey after providing= the above signature. > > Indeed, the recipients can always insist on not cooperating to sign usi= ng the taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHV= ERIFY`. > > > > Regards, > > ZmnSCPxj