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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YxYJB-0006GR-IO
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 10:11:33 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.178 as permitted sender)
client-ip=209.85.212.178; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f178.google.com;
Received: from mail-wi0-f178.google.com ([209.85.212.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YxYJA-0001Bh-E0
for bitcoin-development@lists.sourceforge.net;
Wed, 27 May 2015 10:11:33 +0000
Received: by wicmc15 with SMTP id mc15so88830122wic.1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 27 May 2015 03:11:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.9.161 with SMTP id a1mr58097137wjb.39.1432721486453;
Wed, 27 May 2015 03:11:26 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.194.143.9 with HTTP; Wed, 27 May 2015 03:11:26 -0700 (PDT)
In-Reply-To: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
Date: Wed, 27 May 2015 12:11:26 +0200
X-Google-Sender-Auth: YPUBf6Z8JP5H1ZKmK1ixO64Zdkk
Message-ID: <CANEZrP0QMHp9PwBr=ekkujtA+=LXbgiL4xkXRSmcOGqaLJEp0g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=047d7b5d34fa4324d705170d7716
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: 1YxYJA-0001Bh-E0
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
replacement via sequence numbers
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, 27 May 2015 10:11:33 -0000
--047d7b5d34fa4324d705170d7716
Content-Type: text/plain; charset=UTF-8
>
> Sequence numbers appear to have been originally intended as a mechanism
> for transaction replacement within the context of multi-party transaction
> construction, e.g. a micropayment channel.
>
Yes indeed they were. Satoshis mechanism was more general than micropayment
channels and could do HFT between any set of parties.
> As it happens, this cannot be made safe in the bitcoin protocol as
> deployed today, as there is no enforcement of the rule that miners include
> the most recent transaction in their blocks.
>
Safe is relative - this is the same logic the original replace-by-fee
argument uses. There's no enforcement that miners use any particular
ordering of transactions.
As I believe out of all proposed protocols Satoshi's is still the most
powerful, I would suggest that any change to the semantics on nSequence be
gated by a high bit or something, so the original meaning remains available
if/when resource scheduling and update flood damping are implemented. That
way people can try it out and if miners are breaking things too frequently
by ignoring the chronological ordering people can abandon protocols that
rely on it, and if they aren't they can proceed and benefit from the
greater flexibility.
--047d7b5d34fa4324d705170d7716
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"><blo=
ckquote 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;paddi=
ng-left:1ex"><div dir=3D"ltr">Sequence numbers appear to have been original=
ly intended as a mechanism for transaction replacement within the context o=
f multi-party transaction construction, e.g. a micropayment channel. </div>=
</blockquote><div><br></div><div>Yes indeed they were. Satoshis mechanism w=
as more general than micropayment channels and could do HFT between any set=
of parties.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">As it=
happens, this cannot be made safe in the bitcoin protocol as deployed toda=
y, as there is no enforcement of the rule that miners include the most rece=
nt transaction in their blocks.<br></div></blockquote><div><br></div><div>S=
afe is relative - this is the same logic the original replace-by-fee argume=
nt uses. There's no enforcement that miners use any particular ordering=
of transactions.</div><div><br></div><div>As I believe out of all proposed=
protocols Satoshi's is still the most powerful, I would suggest that a=
ny change to the semantics on nSequence be gated by a high bit or something=
, so the original meaning remains available if/when resource scheduling and=
update flood damping are implemented. That way people can try it out and i=
f miners are breaking things too frequently by ignoring the chronological o=
rdering people can abandon protocols that rely on it, and if they aren'=
t they can proceed and benefit from the greater flexibility.</div><div><br>=
</div></div></div></div>
--047d7b5d34fa4324d705170d7716--
|
