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 D0EE7955 for ; Thu, 3 Nov 2016 17:42:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.161.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 426BC1FC for ; Thu, 3 Nov 2016 17:42:54 +0000 (UTC) Received: by mail-yw0-f173.google.com with SMTP id r204so57438676ywb.0 for ; Thu, 03 Nov 2016 10:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rgrant-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=FIjp76ilMBQcL7hhU5IgRYrdwNo5wkkcOTxIoMI5TYQ=; b=sGIsFISPW+r8/ojPt40KNMIfYuODdKJqck4yJ3PgGbgKCZMzEdSvq1V7oJVFBgNkKy lQldcplh4mu0nb+nuvoK1305UOy6TBAnBE2TyEBF+x0p7cGqlpn+zg/ye3KTcqF/UR5v kUhCDqRhopzK3jIqKZYQqGXp1TzCaFusXhFBncw9A+MepOTjKSn5swP93SRSfj+5i/1+ HYWo8BF7yGZLk2GXwvWEGR3tUaHp8zKaxvBi5orVTHu25U2m2GxCz+yymm/krx+b/y8v BZc2VxhRIDGsFiNlNGUluxx6jCk9lNDe4ZUhbOmKeqZcCGc8QUQI9fDPJMAXS8+3J0Yl wyIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=FIjp76ilMBQcL7hhU5IgRYrdwNo5wkkcOTxIoMI5TYQ=; b=BQ/U4ItZZU2QkEf01BkBwZp60kSthihOUT90NCA9v5Hnm+CDS31JpaomguPuQjOluO 6ol5k7QtR8ExQFKDVoCmGNCbeA1CW7Iag2+nYtrsht6p7inlHkEN/kvNkVXmDXS+S7R8 un8QhOP2fPfK8p5W3axxgN5TrMqwjqV0EzKyzb8HiLj/viUE65yBeJEtvnUOigj7ml2s aV38DZqQzzgA4nzUdQtC4Pn6usqdcoYjvy6jbt47DgHbIxr2Uldv4cmFO7VQaPc7ME+W r6jhfTn2yKXoFj/sNhgDnReWm+Nu1z/PlmnaHZOTDu+KZeyz0mYjy0hw0nLd/Lu68b52 MjRA== X-Gm-Message-State: ABUngvcbhNipoa2lcgfZJ7cwcE9XRR7krUN4zLUijTN2gOFY1py3kivKU7aGZGSxdZ/vbuDaDupxECfUdZbv0Q== X-Received: by 10.129.95.11 with SMTP id t11mr8853506ywb.349.1478194973376; Thu, 03 Nov 2016 10:42:53 -0700 (PDT) MIME-Version: 1.0 Sender: rgrant@rgrant.org Received: by 10.37.174.16 with HTTP; Thu, 3 Nov 2016 10:42:22 -0700 (PDT) In-Reply-To: References: From: Ryan Grant Date: Thu, 3 Nov 2016 13:42:22 -0400 X-Google-Sender-Auth: ypuug_4VK0m3TiLb0uDpbqfA8dM Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Implementing Covenants with OP_CHECKSIGFROMSTACKVERIFY 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: Thu, 03 Nov 2016 17:42:54 -0000 On Wed, Nov 2, 2016 at 1:30 PM, Russell O'Connor via bitcoin-dev wrote: > I'm interested in collecting and implementing other useful covenants, so if > people have ideas, please post them. I know of a good business case that could benefit from two nice features. As an example: Two parties have initiated a transaction designed with counterparty-minimization in mind. It uses MAST and has many different payout distributions. Both parties enter expecting to gain from the transaction, but both take on risk due to external factors. Because of the risks involved, there exist possible times when one party may wish to renegotiate the exit distribution, and might threaten to block any exit. Or, either party might get hit by the proverbial bus. During such times, the other party's eventual exit is protected by using a multisig which includes an oracle determination. The oracle's trusted role is bound to this example's unstated "external factors" in a very limited sense, and does not include broader concerns, such as determining whether a party to the transaction is of "sound mind and body". The singular term "oracle" hides a set of entities participating in m-of-n multisig, which we can name the "oracle-set". Transaction terms include a CLTV lasting perhaps several years, applied whenever the exit requires the oracle-set's signatures. Both parties may mutually select and sign one of the payout distributions, to exit early. The example, as I've described it so far, doesn't need anything other than MAST. It isn't a covenant, because it doesn't impose any forward restrictions when satisfied; despite the contractual complications of executing the oracle-set's signatures. As covenant features are considered across updated instances of what is otherwise a singular transaction, it's important that none carry into the final payout distribution, and that this is easy to verify. Features desired: - One party would like to unilaterally sell their participation in the transaction, to a previously unknown recipient, before the CLTV becomes valid. The other originating party's stored MAST should either continue to function, or require minimal replacements that can be deterministically applied using data visible on the blockchain. It should not be necessary to ask permission from - or coordinate online communication with - the other originating party. (This can also be viewed as a key rotation problem for any long-lasting multisig transaction.) - Both parties would like to mutually revoke rouge oracle-entities from the oracle-set, without exposing each other to any possible renegotiation of other terms. Note that these features affect each other, since if one party sells their participation after any oracle-entities have been revoked, then the revocations should not reset, but rather remain in effect, until a proper payout executes the final agreement in the contract. Of course, if there's a way to achieve these features with less risk than evaluating covenant logic, I would very much like to hear how to do so.