MIME-Version: 1.0
In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Thu, 4 Aug 2016 00:55:00 +0100
Message-ID: <CAE-z3OU+9hB7xFqYsn1-enuonxHB8E415P_Mf3b93p9MpYugjQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114fee30b390a70539338f91
Subject: Re: [bitcoin-dev] BIP clearing house addresses
Precedence: list

--001a114fee30b390a70539338f91
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The reason why I bring this up is existing OP codes and TX types don't
> seem suitable for a secure clearing mechanism;
>

I think reversing transactions is not likely to be acceptable.  You could
add an opcode that requires that an output be set to something.

[target script] SPENDTO

This would require that [target script] is the script for the corresponding
output.  This is a purely local check.

For example, if SPENDTO executes as part of the script for input 3, then it
checks that output 3 uses the given script as its scriptPubKey.  The value
of input 3 and output 3 would have to be the same too.

This allows check sequence verify to be used to lock the spending script
for a while.  This doesn't allow reversal, but would give a 24 hour window
where the spenders can reverse the transaction.

[IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected
key> CHECKSIG] SPENDTO <live public key2> CHECKSIG

Someone with the live public key can create a transaction that spends the
funds to the script in the square brackets.

Once that transaction hits the blockchain, then someone with the <offline
protected key> has 24 hours to spend the output before the person with the
live keys can send the funds onward.

--001a114fee30b390a70539338f91
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <span dir=3D"lt=
r">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">The reason why I bring this up i=
s
existing OP codes and TX types don&#39;t seem suitable for a secure
clearing mechanism; </div></blockquote><div><br></div><div>I think reversin=
g transactions is not likely to be acceptable.=C2=A0 You could add an opcod=
e that requires that an output be set to something.<br><br></div><div>[targ=
et script] SPENDTO<br><br></div><div>This would require that [target script=
] is the script for the corresponding output.=C2=A0 This is a purely local =
check.=C2=A0 <br><br>For example, if SPENDTO executes as part of the script=
 for input 3, then it checks that output 3 uses the given script as its scr=
iptPubKey.=C2=A0 The value of input 3 and output 3 would have to be the sam=
e too.<br><br></div><div>This allows check sequence verify to be used to lo=
ck the spending script for a while.=C2=A0 This doesn&#39;t allow reversal, =
but would give a 24 hour window where the spenders can reverse the transact=
ion.<br><br></div><div>[IF &lt;1 day&gt; CSV DROP &lt;live public key&gt; C=
HECKSIG ELSE &lt;offline protected key&gt; CHECKSIG] SPENDTO &lt;live publi=
c key2&gt; CHECKSIG<br></div><div><br></div><div>Someone with the live publ=
ic key can create a transaction that spends the funds to the script in the =
square brackets.<br><br></div><div>Once that transaction hits the blockchai=
n, then someone with the &lt;offline protected key&gt; has 24 hours to spen=
d the output before the person with the live keys can send the funds onward=
.<br></div></div></div></div>

--001a114fee30b390a70539338f91--