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 <vizeet@gmail.com>
Date: Thu, 6 Sep 2018 21:44:59 +0530
Message-ID: <CAEmwXH=BZgceLogi+QTA3sLdy8gVFW=wCdt5f9ZS6br=4ktcdg@mail.gmail.com>
To: Alejandro Ranchal Pedrosa <a.ranchalpedrosa@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000089c9b057536326c"
Cc: TUCCI Sara <sara.tucci@cea.fr>,
	=?UTF-8?B?w5ZuZGVyIEfDnFJDQU4=?= <Onder.GURCAN@cea.fr>
Subject: Re: [bitcoin-dev] A BIP proposal for transactions that are
	'cancellable'
Precedence: list

--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 <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-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

<div dir=3D"auto">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.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu =
6 Sep, 2018, 6:37 PM Alejandro Ranchal Pedrosa via bitcoin-dev, &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello e=
veryone,<br>
<br>
We would like to propose a new BIP to extend OP_CSV (and/or OP_CLTV) in<br>
order for these to allow and interpret negative values. This way,<br>
taking the example shown in BIP 112:<br>
<br>
HASH160 &lt;revokehash&gt; EQUAL<br>
IF<br>
=C2=A0=C2=A0=C2=A0=C2=A0 &lt;Bob&#39;s pubkey&gt;<br>
ELSE<br>
=C2=A0=C2=A0=C2=A0=C2=A0 &quot;24h&quot; CHECKSEQUENCEVERIFY DROP<br>
=C2=A0=C2=A0=C2=A0=C2=A0 &lt;Alice&#39;s pubkey&gt;<br>
ENDIF<br>
CHECKSIG<br>
<br>
that gives ownership only to Bob for the first 24 hours and then to<br>
whichever spends first, we basically propose using the negative bit value:<=
br>
<br>
HASH160 &lt;revokehash&gt; EQUAL<br>
IF<br>
=C2=A0=C2=A0=C2=A0=C2=A0 &lt;Bob&#39;s pubkey&gt;<br>
ELSE<br>
=C2=A0=C2=A0=C2=A0=C2=A0 &quot;-24h&quot; CHECKSEQUENCEVERIFY DROP<br>
=C2=A0=C2=A0=C2=A0=C2=A0 &lt;Alice&#39;s pubkey&gt;<br>
ENDIF<br>
CHECKSIG<br>
<br>
meaning that both would have ownership for the first 24 hours, but<br>
after that only Bob would own such coins. Its implementation should<br>
not be too tedious, and in fact it simply implies considering negative<br>
values that are at the moment discarded as for the specification of<br>
BIP-112, leaving the sign bit unused.<br>
<br>
This, we argue, an increase the fairness of the users, and can at times<br>
be more cost-effective for users to do rather than trying a Replace-By-Fee<=
br>
transaction, should they want to modify such payment.<br>
<br>
We would like to have a discussion about this before proposing the<br>
BIP, for which we are preparing the text.<br>
<br>
You can find our paper discussing it here:<br>
<a href=3D"https://hal-cea.archives-ouvertes.fr/cea-01867357" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">https://hal-cea.archives-ouvertes.fr/cea=
-01867357</a> (find attached as well)<br>
<br>
Best,<br>
<br>
-- <br>
Alejandro Ranchal Pedrosa, =C3=96nder G=C3=BCrcan and Sara Tucci-Piergiovan=
ni<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000089c9b057536326c--