Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DE9B29D for ; Wed, 22 May 2019 05:12:11 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A19A6C5 for ; Wed, 22 May 2019 05:12:10 +0000 (UTC) Received: from mail-ed1-f43.google.com (mail-ed1-f43.google.com [209.85.208.43]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4M5C74s023720 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 22 May 2019 01:12:08 -0400 Received: by mail-ed1-f43.google.com with SMTP id p27so1871402eda.1 for ; Tue, 21 May 2019 22:12:08 -0700 (PDT) X-Gm-Message-State: APjAAAWF2DYVKjGBj0OH3DScJQWXfJunCsmoPlmMdVANTec/rR3QP+4q FsdjL5TYm2HI3Bj2srylCQT1ulmxceJPERRXMB0= X-Google-Smtp-Source: APXvYqwz/1jJ2MrOu/fm7bw1bwXnB8MX1ZiWWkPTnt+EHEee6cDyAbpjVhdJ8S5Hg/gcMBRrHQxVHImzM7b79bC0jB4= X-Received: by 2002:a50:addc:: with SMTP id b28mr88735860edd.7.1558501927219; Tue, 21 May 2019 22:12:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Tue, 21 May 2019 22:11:55 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000c0faba058973012e" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED 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 05:12:12 -0000 --000000000000c0faba058973012e Content-Type: text/plain; charset="UTF-8" Morning, Yes, in general, Bitcoin does not do anything to prevent users from discarding 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 > recipients > > 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 using > the taproot branch and thus force spending via the > `OP_CHECKOUTPUTSHASHVERIFY`. > > Regards, > ZmnSCPxj > --000000000000c0faba058973012e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Morning,

Yes, in g= eneral, Bitcoin does not do anything to prevent users from discarding their= keys.

I don't think this will be fixed anytime soon.

T= here 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
<= /div>
O= n Tue, May 21, 2019 at 7:52 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> 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 reci= pients

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 using t= he taproot branch and thus force spending via the `OP_CHECKOUTPUTSHASHVERIF= Y`.

Regards,
ZmnSCPxj
--000000000000c0faba058973012e--