Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A3CB8DA2 for ; Thu, 6 Sep 2018 13:37:48 +0000 (UTC) X-Greylist: delayed 00:05:22 by SQLgrey-1.7.6 Received: from mail.bluematt.me (static-100-38-11-146.nycmny.fios.verizon.net [100.38.11.146]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 146AC7CB for ; Thu, 6 Sep 2018 13:37:47 +0000 (UTC) Received: from [IPv6:2607:fb90:13dc:5c95:3c82:1ed7:b899:7e6] (unknown [172.56.2.140]) by mail.bluematt.me (Postfix) with ESMTPSA id 492881834CF; Thu, 6 Sep 2018 13:32:25 +0000 (UTC) Date: Thu, 06 Sep 2018 13:31:58 +0000 In-Reply-To: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com> References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----QK4OH3B8YS861OAM93PGRGNMAEYAIF" Content-Transfer-Encoding: 7bit To: Alejandro Ranchal Pedrosa , Bitcoin Protocol Discussion , Alejandro Ranchal Pedrosa via bitcoin-dev , bitcoin-dev@lists.linuxfoundation.org From: Matt Corallo Message-ID: <8CA4E834-061C-4EE9-A69D-CAE69A08FE7D@mattcorallo.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE 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 16:20:38 +0000 Cc: TUCCI Sara , =?ISO-8859-1?Q?=D6nder_G=DCRCAN?= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 13:37:48 -0000 ------QK4OH3B8YS861OAM93PGRGNMAEYAIF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 broadcast= able at the 24h mark and has different spendability=2E This avoids introduc= ing reorg-induced invalidity=2E 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=2E This way, >taking the example shown in BIP 112: > >HASH160 EQUAL >IF > =C2=A0=C2=A0=C2=A0 >ELSE > =C2=A0=C2=A0=C2=A0 "24h" CHECKSEQUENCEVERIFY DROP > =C2=A0=C2=A0=C2=A0 >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 > =C2=A0=C2=A0=C2=A0 >ELSE > =C2=A0=C2=A0=C2=A0 "-24h" CHECKSEQUENCEVERIFY DROP > =C2=A0=C2=A0=C2=A0 >ENDIF >CHECKSIG > >meaning that both would have ownership for the first 24 hours, but >after that only Bob would own such coins=2E 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=2E > >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=2E > >We would like to have a discussion about this before proposing the >BIP, for which we are preparing the text=2E > >You can find our paper discussing it here: >https://hal-cea=2Earchives-ouvertes=2Efr/cea-01867357 (find attached as >well) > >Best, > >--=20 >Alejandro Ranchal Pedrosa, =C3=96nder G=C3=BCrcan and Sara Tucci-Piergiov= anni ------QK4OH3B8YS861OAM93PGRGNMAEYAIF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think a simple approach to what you want to acco= mplish is to simply have a multisig option with a locktime pre-signed trans= action which is broadcastable at the 24h mark and has different spendabilit= y=2E This avoids introducing reorg-induced invalidity=2E

On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Ped= rosa via bitcoin-dev <bitcoin-dev@lists=2Elinuxfoundation=2Eorg> wrot= e:
Hello everyone,

We would like to propose a ne=
w BIP to extend OP_CSV (and/or OP_CLTV) in
order for these to allow and =
interpret negative values=2E This way,
taking the example shown in BIP 1=
12:

HASH160 <revokehash> EQUAL
IF
     &l=
t;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 towhichever spends first, we basically propose using the negative bit value:=


HASH160 <revokehash> EQUAL
IF
     <B=
ob's pubkey>
ELSE
     "-24h" CHECKSEQUENCEVERIFY D=
ROP
     <Alice's pubkey>
ENDIF
CHECKSIG
<=
br>meaning that both would have ownership for the first 24 hours, but
af=
ter that only Bob would own such coins=2E Its implementation should
not =
be too tedious, and in fact it simply implies considering negative
value=
s that are at the moment discarded as for the specification of
BIP-112, =
leaving the sign bit unused=2E

This, we argue, an increase the fairn=
ess of the users, and can at times
be more cost-effective for users to d=
o rather than trying a Replace-By-Fee
transaction, should they want to m=
odify such payment=2E

We would like to have a discussion about this =
before proposing the
BIP, for which we are preparing the text=2E

=
You can find our paper discussing it here:
https://hal-cea=2Earchives-ouvertes=2E=
fr/cea-01867357 (find attached as well)

Best,
------QK4OH3B8YS861OAM93PGRGNMAEYAIF--