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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1USOWs-0002SO-Do
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Apr 2013 09:19:50 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.51 as permitted sender)
client-ip=209.85.219.51; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f51.google.com;
Received: from mail-oa0-f51.google.com ([209.85.219.51])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1USOWr-0003cP-8j
for bitcoin-development@lists.sourceforge.net;
Wed, 17 Apr 2013 09:19:50 +0000
Received: by mail-oa0-f51.google.com with SMTP id k14so1359644oag.24
for <bitcoin-development@lists.sourceforge.net>;
Wed, 17 Apr 2013 02:19:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.226.136 with SMTP id rs8mr2196422obc.50.1366190383823;
Wed, 17 Apr 2013 02:19:43 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.167.169 with HTTP; Wed, 17 Apr 2013 02:19:43 -0700 (PDT)
In-Reply-To: <CAD0SH_WOG8jQvzsNzwud3fYjaxqTJo0CS7yP6XZeKvap_yqtqg@mail.gmail.com>
References: <CANEZrP1yKeQMayFHsEUWtA3=q+v5rPAutjzEFVVHopPGNZ4jGQ@mail.gmail.com>
<CAD0SH_WOG8jQvzsNzwud3fYjaxqTJo0CS7yP6XZeKvap_yqtqg@mail.gmail.com>
Date: Wed, 17 Apr 2013 11:19:43 +0200
X-Google-Sender-Auth: ovaUur7sRF4jRJ5SI37WBvIqziU
Message-ID: <CANEZrP2PEB8n_Ov1bXi_ZoAkLwfz7_JtM9PPHr+8ei5KCgwdEg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Kyle Schlansker <kylesch@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3018a8602c304da8afc81
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1USOWr-0003cP-8j
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Anti DoS for tx replacement
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2013 09:19:50 -0000
--001a11c3018a8602c304da8afc81
Content-Type: text/plain; charset=UTF-8
> Or are you talking about some sort of new decentralized high frequency
> trading system that is self-matching and self-clearing? (I'd be very
> interested in hearing more if this is the case).
>
I'm using the term "high frequency trading" because Satoshi did. Like the
way he used the word "contract" it is perhaps a bit misleading, but we lack
anything better to describe this new concept.
Today HFT typically means companies that submits tons of micro-trades to
centralised asset exchanges to try and exploit statistically expected
correlations. HFT using tx replacement has nothing to do this with - it is
instead a way that N parties can negotiate amongst themselves as fast as
they can compute and verify signatures.
Here is how Satoshi explained it to me, in his words:
An unrecorded open transaction can keep being replaced until nLockTime. It
may contain payments by multiple parties. Each input owner signs their
input. For a new version to be written, each must sign a higher sequence
number (see IsNewerThan). By signing, an input owner says "I agree to put
my money in, if everyone puts their money in and the outputs are this."
There are other options in SignatureHash such as SIGHASH_SINGLE which
means "I agree, as long as this one output (i.e. mine) is what I want, I
don't care what you do with the other outputs.". If that's written with a
high nSequenceNumber, the party can bow out of the negotiation except for
that one stipulation, or sign SIGHASH_NONE and bow out completely.
The parties could create a pre-agreed default option by creating a higher
nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties
to sign to complete the signature. The parties hold this tx in reserve and
if need be, pass it around until it has enough signatures.
One use of nLockTime is high frequency trades between a set of parties.
They can keep updating a tx by unanimous agreement. The party giving
money would be the first to sign the next version. If one party stops
agreeing to changes, then the last state will be recorded at nLockTime. If
desired, a default transaction can be prepared after each version so n-1
parties can push an unresponsive party out. Intermediate transactions do
not need to be broadcast. Only the final outcome gets recorded by the
network. Just before nLockTime, the parties and a few witness nodes
broadcast the highest sequence tx they saw.
--001a11c3018a8602c304da8afc81
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
Or are you talking about some sort of new decentralized high frequency<br>
trading system that is self-matching and self-clearing? (I'd be very<br=
>
interested in hearing more if this is the case).<br></blockquote><div><br><=
/div><div style>I'm using the term "high frequency trading" b=
ecause Satoshi did. Like the way he used the word "contract" it i=
s perhaps a bit misleading, but we lack anything better to describe this ne=
w concept.</div>
<div style><br></div><div style>Today HFT typically means companies that su=
bmits tons of micro-trades to centralised asset exchanges to try and exploi=
t statistically expected correlations. HFT using tx replacement has nothing=
to do this with - it is instead a way that N parties can negotiate amongst=
themselves as fast as they can compute and verify signatures.</div>
<div style><br></div><div style>Here is how Satoshi explained it to me, in =
his words:</div><div style><br></div></div></div><blockquote style=3D"margi=
n:0px 0px 0px 40px;border:none;padding:0px"><div class=3D"gmail_extra" styl=
e>
<div class=3D"gmail_quote" style><div style><span style=3D"font-family:aria=
l,sans-serif;font-size:13px">An unrecorded open transaction can keep being =
replaced until nLockTime. =C2=A0It may contain payments by multiple parties=
. =C2=A0Each input owner signs their input. =C2=A0For a new version to be w=
ritten, each must sign a higher sequence number (see IsNewerThan). =C2=A0By=
signing, an input owner says "I agree to put my money in, if everyone=
puts their money in and the outputs are this." =C2=A0There are other =
options in SignatureHash such as SIGHASH_SINGLE which means "I agree, =
as long as this one output (i.e. mine) is what I want, I don't care wha=
t you do with the other outputs.". =C2=A0If that's written with a =
high nSequenceNumber, the party can bow out of the negotiation except for t=
hat one stipulation, or sign SIGHASH_NONE and bow out completely.</span></d=
iv>
</div></div><div class=3D"gmail_extra" style><div class=3D"gmail_quote" sty=
le><div style><br style=3D"font-family:arial,sans-serif;font-size:13px"></d=
iv></div></div><div class=3D"gmail_extra" style><div class=3D"gmail_quote" =
style>
<div style><span style=3D"font-family:arial,sans-serif;font-size:13px">The =
parties could create a pre-agreed default option by creating a higher nSequ=
enceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to s=
ign to complete the signature. =C2=A0The parties hold this tx in reserve an=
d if need be, pass it around until it has enough signatures.</span></div>
</div></div><div class=3D"gmail_extra" style><div class=3D"gmail_quote" sty=
le><div style><br style=3D"font-family:arial,sans-serif;font-size:13px"></d=
iv></div></div><div class=3D"gmail_extra" style><div class=3D"gmail_quote" =
style>
<div style><span style=3D"font-family:arial,sans-serif;font-size:13px">One =
use of nLockTime is high frequency trades between a set of parties. =C2=A0T=
hey can keep updating a tx by unanimous agreement. =C2=A0The party giving m=
oney would be the first to sign the next version. =C2=A0If one party stops =
agreeing to changes, then the last state will be recorded at nLockTime. =C2=
=A0If desired, a default transaction can be prepared after each version so =
n-1 parties can push an unresponsive party out. =C2=A0Intermediate transact=
ions do not need to be broadcast. =C2=A0Only the final outcome gets recorde=
d by the network. =C2=A0Just before nLockTime, the parties and a few witnes=
s nodes broadcast the highest sequence tx they saw.</span></div>
</div></div></blockquote></div>
--001a11c3018a8602c304da8afc81--
|
