diff options
| author | Alejandro Ranchal Pedrosa <a.ranchalpedrosa@gmail.com> | 2018-09-07 09:07:25 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-09-07 07:07:39 +0000 |
| commit | 9340faede2843c1f4884139f0e3d8ce2821de93d (patch) | |
| tree | 1a408169c788d81e879f214689bc2a1ba77ff2ae | |
| parent | ca57f143b5fb7c9486bbc580a598bee7057b6ff5 (diff) | |
| download | pi-bitcoindev-9340faede2843c1f4884139f0e3d8ce2821de93d.tar.gz pi-bitcoindev-9340faede2843c1f4884139f0e3d8ce2821de93d.zip | |
Re: [bitcoin-dev] A BIP proposal for transactions that are 'cancellable'
| -rw-r--r-- | 9a/3cf58a7a02b3f74e06882f52f5d63d274194c8 | 177 |
1 files changed, 177 insertions, 0 deletions
diff --git a/9a/3cf58a7a02b3f74e06882f52f5d63d274194c8 b/9a/3cf58a7a02b3f74e06882f52f5d63d274194c8 new file mode 100644 index 000000000..d55ca183f --- /dev/null +++ b/9a/3cf58a7a02b3f74e06882f52f5d63d274194c8 @@ -0,0 +1,177 @@ +Return-Path: <a.ranchalpedrosa@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 4BF41CFE + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 7 Sep 2018 07:07:39 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 90257786 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 7 Sep 2018 07:07:30 +0000 (UTC) +Received: by mail-wm0-f53.google.com with SMTP id f21-v6so13614423wmc.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 07 Sep 2018 00:07:30 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=subject:to:cc:references:from:message-id:date:user-agent + :mime-version:in-reply-to:content-transfer-encoding:content-language; + bh=MS6XCKMAZbXYD7LKl3O3yDIHklJ5xEDc9/IwY8HybBM=; + b=MwIxuDvEcQOZZtnuZUoLA9ZdGK3iDveJOXFoglULB+y9t77AAXlSuwGm5JF9KHdA2y + w2Aix+0D6G2pIpUffATDReeBKoHns93TERBRO7s0ax3IBMHuZUBwBExu8rm51sMxemxp + prTq+rJojuFZ03VkhGQRQC9x+cQE+qEhgln1h3+ObrffZkaiUc/wQ1F65z7Uj0BSo1wa + 5gLdxuE1BdAAp4O+lNYN5L0lKN4q0MmmPf200LPxmAJ/dgFFgReEbN0Q0UmBCBTLL1G4 + l2IdYUq5lrgukHDtP+kp5mYSelqPN3v8jO9go5WT1mvUICuV0mSqZMlvG7KqtaMovJWC + ktpg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:subject:to:cc:references:from:message-id:date + :user-agent:mime-version:in-reply-to:content-transfer-encoding + :content-language; + bh=MS6XCKMAZbXYD7LKl3O3yDIHklJ5xEDc9/IwY8HybBM=; + b=q8QVsAmJeQpjuPAK1iF0RQq/YgQWLkAqNuYyP0rZQxlE1GUAKhVGGs4b1KxuGyUZzG + l4puvm8iWjuvzLQddJ/MqLGEj/OGU9ZsUeHr7mvtyEegr29eudlzUKS2Y5jmc9OLAOUt + vJfaIsoG2n0Yey+8dtB5Y1gsG/2NBoNisowNEcS7WjFm485iEbI1WPvjqZeFSkq6mxWm + x+jezvfrtBRBX2usZkoNaADMc/KkxauZxVmXmMaptul+3uAJu2Zo4eW7tlWMhA6P7MRt + iDrUlOoYrXs4o1BB9yE1ilbafbetPNDWiTtDmt32tT7Penha7YXIlX80W1Z+c/TFO7YY + SdMw== +X-Gm-Message-State: APzg51BFBixBg4XoaxM5VUXN0/11NN3cyYYHsg6n0XwGhm1KuGiFXnuo + 3QSZZRicm6nVntNIQ9sfysq6fTUa +X-Google-Smtp-Source: ANB0VdZe2HnDEVhpb44QseziEEdbBjKy5t3foSnig5MkXida/EM1QS9zfnS36LqUCHe/+7v7JmoMwA== +X-Received: by 2002:a1c:f611:: with SMTP id + w17-v6mr4143425wmc.143.1536304048650; + Fri, 07 Sep 2018 00:07:28 -0700 (PDT) +Received: from [10.192.86.228] (clients-xsf-96.upc.es. [147.83.201.96]) + by smtp.googlemail.com with ESMTPSA id + v5-v6sm5697666wru.60.2018.09.07.00.07.26 + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Fri, 07 Sep 2018 00:07:27 -0700 (PDT) +To: Matt Corallo <lf-lists@mattcorallo.com> +References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com> + <8CA4E834-061C-4EE9-A69D-CAE69A08FE7D@mattcorallo.com> + <CABaiX-2L9oVdta=aRH91uE=iPRv4cX6zU0=+oF+2oWqnu=64YQ@mail.gmail.com> + <029a8e95-a265-451d-5417-957d685fa9ce@mattcorallo.com> +From: Alejandro Ranchal Pedrosa <a.ranchalpedrosa@gmail.com> +Message-ID: <14a4d701-54d3-34b0-8eed-07efafd0061c@gmail.com> +Date: Fri, 7 Sep 2018 09:07:25 +0200 +User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 + Thunderbird/57.0 +MIME-Version: 1.0 +In-Reply-To: <029a8e95-a265-451d-5417-957d685fa9ce@mattcorallo.com> +Content-Type: text/plain; charset=utf-8; format=flowed +Content-Transfer-Encoding: 8bit +Content-Language: en-US +X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, + RCVD_IN_DNSWL_NONE 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: Fri, 07 Sep 2018 13:43:39 +0000 +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 07 Sep 2018 07:07:39 -0000 + +Yes I agree with what you mean but this requires Alice to broadcast an +additional transaction. Also, Alice is supposed to be able to 'cancel' +the transaction in the first 24hours, not after them. + +Best, + +Alejandro. + +On 9/6/18 6:33 PM, Matt Corallo wrote: +> 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 <lf-lists@mattcorallo.com +>> <mailto:lf-lists@mattcorallo.com>> 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 <bitcoin-dev@lists.linuxfoundation.org +>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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 <revokehash> EQUAL +>> IF +>> <Bob's pubkey> +>> ELSE +>> "24h" CHECKSEQUENCEVERIFY DROP +>> <Alice's pubkey> +>> 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 <revokehash> EQUAL +>> IF +>> <Bob's pubkey> +>> ELSE +>> "-24h" CHECKSEQUENCEVERIFY DROP +>> <Alice's pubkey> +>> 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, +>> + |