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 0B5B0C9A for ; Thu, 6 Sep 2018 16:42:15 +0000 (UTC) X-Greylist: delayed 00:08:33 by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 62DF371C for ; Thu, 6 Sep 2018 16:42:14 +0000 (UTC) Received: from [172.17.0.4] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id DD9BC1833A0; Thu, 6 Sep 2018 16:33:39 +0000 (UTC) From: Matt Corallo To: Alejandro Ranchal Pedrosa References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com> <8CA4E834-061C-4EE9-A69D-CAE69A08FE7D@mattcorallo.com> Message-ID: <029a8e95-a265-451d-5417-957d685fa9ce@mattcorallo.com> Date: Thu, 6 Sep 2018 12:33:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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: Thu, 06 Sep 2018 17:39:45 +0000 Cc: Bitcoin Dev Subject: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable' 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, 06 Sep 2018 16:42:15 -0000 I think you misunderstood my proposal. What you'd do is the transaction is spendable by either Bob OR (Bob AND Alice) and before broadcast/during construction/whatever sign a new transaction that spends it and is only spendable by Alice, but is timelocked for 24 hours. At the 24h mark, Alice broadcasts the transaction and once it is confirmed only Alice can claim the money. On 09/06/18 10:59, Alejandro Ranchal Pedrosa wrote: > Dear Matt, > > Notice that what you suggest has some substantial differences. With your > suggestion of a multisig option with a 24h timelock, once you give Alice > the chance to spend that UTXO without a negative timelock (as we argue), > by means of, say, a transaction that she can use, you cannot enforce > that this is not used by Alice after the 24hs. Perhaps it is possible, > tweaking the Lightning Channel design of Breach Remedy txs, to penalize > Alice if she does this, but this requires Bob to check the Blockchain in > case he needs to publish a proof-of-fraud, think of adding extra funds > to the transaction to account for penalization, etc. > > Feel free to correct me if I got it wrong in your email. > > Best, > Alejandro. > > > On Thu, Sep 6, 2018 at 3:32 PM Matt Corallo > wrote: > > I think a simple approach to what you want to accomplish is to > simply have a multisig option with a locktime pre-signed transaction > which is broadcastable at the 24h mark and has different > spendability. This avoids introducing reorg-induced invalidity. > > On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Pedrosa via > bitcoin-dev > wrote: > > Hello everyone, > > We would like to propose a new BIP to extend OP_CSV (and/or OP_CLTV) in > order for these to allow and interpret negative values. This way, > taking the example shown in BIP 112: > > HASH160 EQUAL > IF >     > ELSE >     "24h" CHECKSEQUENCEVERIFY DROP >     > ENDIF > CHECKSIG > > that gives ownership only to Bob for the first 24 hours and then to > whichever spends first, we basically propose using the negative bit value: > > HASH160 EQUAL > IF >     > ELSE >     "-24h" CHECKSEQUENCEVERIFY DROP >     > ENDIF > CHECKSIG > > meaning that both would have ownership for the first 24 hours, but > after that only Bob would own such coins. Its implementation should > not be too tedious, and in fact it simply implies considering negative > values that are at the moment discarded as for the specification of > BIP-112, leaving the sign bit unused. > > This, we argue, an increase the fairness of the users, and can at times > be more cost-effective for users to do rather than trying a Replace-By-Fee > transaction, should they want to modify such payment. > > We would like to have a discussion about this before proposing the > BIP, for which we are preparing the text. > > You can find our paper discussing it here: > https://hal-cea.archives-ouvertes.fr/cea-01867357 (find attached as well) > > Best, >