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 34FB4F0B for ; Thu, 6 Sep 2018 16:15:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 87F16713 for ; Thu, 6 Sep 2018 16:15:12 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id 13-v6so21690481ois.1 for ; Thu, 06 Sep 2018 09:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X0c/5rbdLRxu2vCd0+fdWbA41yD9TbXf//R9Rroo0nw=; b=mjhcfa7zBHmv9FrpALoUAVOYsDzUqVyYFSR05choZITIgRfM7c03DrR81S1+NMz4+/ /NfDwJnNq2ITvgVU5HJ5qr5qJxnbqWg58cavoCpb+b1KNtZRxWq2+P15dFc0szXU0gtr 1bw8NnOdNdWkCsve7OUdLYSNX4nFd0h+PBD5Yg0+mdaMJWT9XqsBGy0qua049DtlUtwu 664YdRr0tYL3ksS1zOx+cklnyVS56+wukhPFHwcJUAxuZF8eCRHTkRcORXqg2P1myMYw VpiBTE0YzAjo8gFzrjpXT3UnkjjnS2QIFKU8xycjbhXeVvH4rMZC1yuRnw2v8hGp2qtY +Vag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=X0c/5rbdLRxu2vCd0+fdWbA41yD9TbXf//R9Rroo0nw=; b=ttoSpppJq61aoFIxpN4DV8ZA/ko/1Qi1Dy4qydk2SRBP7ET49/4DK52s08Hg+tcrWv Fd2ZwN2idei9pzl5ZhvcHhMh4xd8zJO3LqMX3HXhr68r0NgUdYhZhUUpZORTPtBX5Jz9 LyKJh8sa9dh3iTlaDowY5B7CVSK/cH17j6RX2FMkHN2JDVO398DdtgCwcgtipPRY5XgX izJP1CfO0DNINyb6ovkkCyzJjRyT1Svq8FqOxPjZB4N7dUge80NKxUDMhnaLDKBCimt0 wWQgYU/ud8CFW0IHTuD88D3XPAUAOPuhLfETZOakVidIofRwb426Qs8OsIzSDtiKWWmj i+5Q== X-Gm-Message-State: APzg51D3WDuQ5YO2YsJUcR4HSY7zt3HX16dW2uvovJj3Gq42hKi/SIid vBatbrHoQBWWZvGS/CUlACG7r5ZOR9UnEfZ3qiA= X-Google-Smtp-Source: ANB0VdaycWMiVPNZMXzNCRQFTo6GqL7xvg88HNUJWir6H4Blrfu2n8HUt/y0Hof2bWlMzZXMF8ftjX50v6NasOfhUXw= X-Received: by 2002:aca:3744:: with SMTP id e65-v6mr3743931oia.12.1536250511660; Thu, 06 Sep 2018 09:15:11 -0700 (PDT) MIME-Version: 1.0 References: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com> In-Reply-To: <3d4162e0-1f8b-0f23-85fc-9d18d4352cae@gmail.com> From: vizeet srivastava Date: Thu, 6 Sep 2018 21:44:59 +0530 Message-ID: To: Alejandro Ranchal Pedrosa , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000089c9b057536326c" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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: Thu, 06 Sep 2018 16:20:51 +0000 Cc: TUCCI Sara , =?UTF-8?B?w5ZuZGVyIEfDnFJDQU4=?= 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 16:15:13 -0000 --000000000000089c9b057536326c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I feel it is breaking a principle that if a transaction is valid it remains valid. There might be dangerous repercussions to breaking that rule. For instance chain of transaction become invalid which might lead to losses. On Thu 6 Sep, 2018, 6:37 PM Alejandro Ranchal Pedrosa via bitcoin-dev, < 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 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-Fe= e > 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, > > -- > Alejandro Ranchal Pedrosa, =C3=96nder G=C3=BCrcan and Sara Tucci-Piergiov= anni > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000089c9b057536326c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I feel it is breaking a principle that if a transaction i= s valid it remains valid. There might be dangerous repercussions to breakin= g that rule. For instance chain of transaction become invalid which might l= ead to losses.

On Thu = 6 Sep, 2018, 6:37 PM Alejandro Ranchal Pedrosa via bitcoin-dev, <bitcoin-dev@lists.linuxfo= undation.org> wrote:
Hello e= veryone,

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
=C2=A0=C2=A0=C2=A0=C2=A0 <Bob's pubkey>
ELSE
=C2=A0=C2=A0=C2=A0=C2=A0 "24h" CHECKSEQUENCEVERIFY DROP
=C2=A0=C2=A0=C2=A0=C2=A0 <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:<= br>
HASH160 <revokehash> EQUAL
IF
=C2=A0=C2=A0=C2=A0=C2=A0 <Bob's pubkey>
ELSE
=C2=A0=C2=A0=C2=A0=C2=A0 "-24h" CHECKSEQUENCEVERIFY DROP
=C2=A0=C2=A0=C2=A0=C2=A0 <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<= br> 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,

--
Alejandro Ranchal Pedrosa, =C3=96nder G=C3=BCrcan and Sara Tucci-Piergiovan= ni

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000089c9b057536326c--