1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 28C4771
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2016 23:55:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
[209.85.220.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7428F16C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 3 Aug 2016 23:55:01 +0000 (UTC)
Received: by mail-qk0-f169.google.com with SMTP id v123so85646270qkh.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 03 Aug 2016 16:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=vNsGQPf7udlSy/uFmYDWssuEq5aEprRqAv4Pqr+55QU=;
b=hoFTxFg5YyypRV+b49vMLJwl2s8KKLT8XqNpY8adpt3ztD0jERt0ck76/RwHYbFX1u
LtJoasNnTzlBr//uzIeEPpUZBnV6QkfZeM/uG77ANwCuKmhzzXBvXQdSN/tMCtcOydn9
qaXVlPJ+DQvFLn3v9P+yP3WpJbVKjDp3Z7I5MPZDkpcCvtdDXXCHNp1JEy3kEQyDfHj3
nYJW3AUuiJ7g66IqhAv8ZYAnqbIUdS7FdjwotU5h7YHuaKfkFX3ZA6fqscrCCsaa9ZY6
U3szMpA10A5B7sT4nNREzMl+DL7ZRzAyndqasMGDOYqU6xXPCKAts2OlPEyWETf9L+IV
FDhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=vNsGQPf7udlSy/uFmYDWssuEq5aEprRqAv4Pqr+55QU=;
b=ZXOW9Gu65m91CKVfrtzk+Fi2Cfc5Y+PVbCfx+C1GFf5zddLV2qbJgy9YapOfhHWNuw
6VXkI38FAEqjjcafMof4gZhGTPQfn57hHMJZnKJHU7Ey/ylGzR30rIOaawFFsCzK+Pi/
j9+fNaZ6PhK6r2n/a++dzxN3YuSsRtHmARgWgqUjamZ/xeNnxnrX9DsQ+cINJdFB3YOL
yOPnXuCbdR/U0xvdZSyQ5sZyEwCuwACJyR2XgayuXPRhMp5D1nFbapIEV9InAD+2ACNk
3hR2IeMCzgPwmAZFbMvhuj4JqOqKsj1zSOR4lfMAxo7763B2t7PNBI9PfuPM9HQqRHPF
07vA==
X-Gm-Message-State: AEkoousUA0rsUA6Qe9v+aPO2+dLQ5qodxjEmwhNGEcdUeOkUN/avgwQB6qrXhdpVfRJutdITejbUKA0MaR2VeA==
X-Received: by 10.55.109.196 with SMTP id i187mr3156270qkc.116.1470268500569;
Wed, 03 Aug 2016 16:55:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.46.193 with HTTP; Wed, 3 Aug 2016 16:55:00 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP clearing house addresses
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: Wed, 03 Aug 2016 23:55:02 -0000
--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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_=
blank">bitcoin-dev@lists.linuxfoundation.org</a>></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'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't allow reversal, =
but would give a 24 hour window where the spenders can reverse the transact=
ion.<br><br></div><div>[IF <1 day> CSV DROP <live public key> C=
HECKSIG ELSE <offline protected key> CHECKSIG] SPENDTO <live publi=
c key2> 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 <offline protected key> 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--
|
