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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <matthew@roberts.pm>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 76995724
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2016 02:07:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f169.google.com (mail-io0-f169.google.com
[209.85.223.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4742D12C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2016 02:07:07 +0000 (UTC)
Received: by mail-io0-f169.google.com with SMTP id 38so260227083iol.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 03 Aug 2016 19:07:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=roberts-pm.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=heLRVsyzTEPIKCx9phkusxURRVIHMHobXcVx/qUQUIc=;
b=kh2QOtJ4WzCd7vD3Poh5+HfO7dudLwrpz+OZmpub3tWMZ/twYIdBPiZ0b9Ywj4gyjO
tulXWhY2lWBznVa8OkCSsadcMlsK2BC4n6MQAp0ojIklBgov517Bc2i6pLZn9/7jvufJ
p9LmyleLO6JcgIY0XCUqRHj53glEwgIZZc0f8PRDAqiZ4fF9fXUSHdqaFpzTdhpANMGX
NHmSoVucPJgEubMVpn405szH+MycwkPlBOWq1OwtYiMF8Q9ypE0K4ChIIbq2J0R9Eh0Q
M00QlBFdFdyomRJGjqwr5Z4Kbk3dHaz/iwnde2972LmlT+RVIJo4x4qk82wozltWE1W0
Y2kg==
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=heLRVsyzTEPIKCx9phkusxURRVIHMHobXcVx/qUQUIc=;
b=UH0nyDiwmQckRNSH2zHzmJsenUVS4YGMuNGnPf7K2dJDR0H5DJKCrXXGc6j3ci7P7E
A4YB7Ae7zB5UitwHcPBTr3ICQdZgaC6YxfzVk783NoxUagjxDNfC2H6sTUt+jx12qXFF
naHe+LGZ8eQ+XxY6u21zM9b+11cVdpXyq5Y01hG1EknwqFFN65lgAAvVhOWjb5dePY43
M4VfFJ5VSdqSksTCtMmPJxkB7Zjtl1BXP+OqoC1vAm+qCdhl+JF+5sF24VOPzph7bfvJ
yMY0rozjV315yMHy6ryiiInMOhNnIduZwVjTeDBw3i+vk5jpyu34ammzr5E/ukZgmI0A
cxFw==
X-Gm-Message-State: AEkoouu4EPjzY1oCFZKfmVMAzFEkM2+DJkPDUPoFX+QDMcn9yo2ph3nX1xLO0vxgJAW102To+dY2cON19tbQOQ==
X-Received: by 10.107.23.66 with SMTP id 63mr79814834iox.169.1470276426562;
Wed, 03 Aug 2016 19:07:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.57.69 with HTTP; Wed, 3 Aug 2016 19:07:06 -0700 (PDT)
X-Originating-IP: [115.70.56.56]
In-Reply-To: <CAE-z3OU+9hB7xFqYsn1-enuonxHB8E415P_Mf3b93p9MpYugjQ@mail.gmail.com>
References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com>
<CAE-z3OU+9hB7xFqYsn1-enuonxHB8E415P_Mf3b93p9MpYugjQ@mail.gmail.com>
From: Matthew Roberts <matthew@roberts.pm>
Date: Thu, 4 Aug 2016 12:07:06 +1000
Message-ID: <CAAEDBiF=xzOodTZ++WrRhESFqyvE+p0hVCx657WgocRtY5yG3g@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c05c23e20a7c605393568c4
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Thu, 04 Aug 2016 09:05:37 +0000
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: Thu, 04 Aug 2016 02:07:08 -0000
--94eb2c05c23e20a7c605393568c4
Content-Type: text/plain; charset=UTF-8
This would honestly work. It forces the attacker to go through with the
clearing phase which simultaneously makes it possible to "cancel" the TX
through another logic branch before the timeout occurs. I'd say that would
meet the needs of a clearing mechanism / fraud prevention system for an
exchange perfectly while requiring minimal changes to the software.
Very, very smart idea. A++, would read again.
On Thu, Aug 4, 2016 at 9:55 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--94eb2c05c23e20a7c605393568c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This would honestly work. It forces the attacker to g=
o through with the clearing phase which simultaneously makes it possible to=
"cancel" the TX through another logic branch before the timeout =
occurs. I'd say that would meet the needs of a clearing mechanism / fra=
ud prevention system for an exchange perfectly while requiring minimal chan=
ges to the software.<br><br></div>Very, very smart idea. A++, would read ag=
ain.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Thu, Aug 4, 2016 at 9:55 AM, Tier Nolan via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><span class=3D"">On Wed, Aug 3, 2016 at 7:16 PM, Matthew =
Roberts via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev=
@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda=
tion.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">The reason why I bring this up is
existing OP codes and TX types don't seem suitable for a secure
clearing mechanism; </div></blockquote><div><br></div></span><div>I think r=
eversing transactions is not likely to be acceptable.=C2=A0 You could add a=
n opcode that requires that an output be set to something.<br><br></div><di=
v>[target 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 scriptPubKey.=C2=A0 The value of input 3 and output 3 would have to be =
the same too.<br><br></div><div>This allows check sequence verify to be use=
d to lock the spending script for a while.=C2=A0 This doesn't allow rev=
ersal, but would give a 24 hour window where the spenders can reverse the t=
ransaction.<br><br></div><div>[IF <1 day> CSV DROP <live public ke=
y> CHECKSIG ELSE <offline protected key> CHECKSIG] SPENDTO <liv=
e public key2> CHECKSIG<br></div><div><br></div><div>Someone with the li=
ve public 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 bl=
ockchain, 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.<br></div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
--94eb2c05c23e20a7c605393568c4--
|
