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
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YANgj-0007B5-3X
for bitcoin-development@lists.sourceforge.net;
Sun, 11 Jan 2015 18:56:37 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YANgh-00073Y-JC
for bitcoin-development@lists.sourceforge.net;
Sun, 11 Jan 2015 18:56:37 +0000
Received: by mail-wi0-f177.google.com with SMTP id l15so10876928wiw.4
for <bitcoin-development@lists.sourceforge.net>;
Sun, 11 Jan 2015 10:56:29 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.235.193 with SMTP id uo1mr22486627wjc.105.1421002589508;
Sun, 11 Jan 2015 10:56:29 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.9 with HTTP; Sun, 11 Jan 2015 10:56:29 -0800 (PST)
In-Reply-To: <CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com>
References: <CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com>
<CANEZrP0ZabL2S=UhB2u7en2AfrckPk5CQe0YN-i4eDXQK-LF6A@mail.gmail.com>
<CAJHLa0NoDU+DOPfubhbVs8_Y92+uGG=mZ2+ruRCXkeULghWVVg@mail.gmail.com>
<CANEZrP1H-_4XiG+Azm7M4FgLrayuML+kdQ7LineXsU3FUH6=Qw@mail.gmail.com>
<CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com>
Date: Sun, 11 Jan 2015 19:56:29 +0100
X-Google-Sender-Auth: E1_XvjJfst6sXmf-NKniuEHG-WM
Message-ID: <CANEZrP3SE_=w_3K5YK2_L3JpiPp27Ykzbk79vn+3PsUAVWgzYg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e01419e02929aba050c64f292
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: 1YANgh-00073Y-JC
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with
CHECKLOCKTIMEVERIFY
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: Sun, 11 Jan 2015 18:56:37 -0000
--089e01419e02929aba050c64f292
Content-Type: text/plain; charset=UTF-8
Firstly, apologies to Nathan for not actually providing feedback on his
protocol. I've put pondering it onto my mental todo list. The notion of a
payment tree is interesting but complicated - I would need to think about
it and maybe draw myself some diagrams before having useful feedback here.
If you wanted to implement it, you could fork the existing code in bitcoinj
and extend it with the new functionality.
I raised the original Satoshi design mainly to inform and so the approaches
can be compared. It may well be that this proposed protocol is superior in
every way, in which case the nSequence approach would be of no further use,
assuming Nathan's protocol generalises to n-party HFT.
Replying now to Gregory:
I think we agree, and are just phrasing things differently (or slowly
groping towards consensus at the speed of email threads :-).
It's likely that over time Bitcoin will end up being multi-layered, with
the block chain being the base layer that syncs everyone up, and higher
layers doing things that miners either can't do or can't be trusted to do.
Like the proposal from GreenAddress to be a well known signer who is
trusted to not double spend.
From miners perspective, there are multiple schemes where they are viable
if cost(fraud) < benefit, at the moment unconfirmed transactions appear to
be an example of that, and putting resource control considerations to one
side, it's possible that tx replacement would be the same. Or not. The
calculation for miners isn't easy, because if they play by the rules then
they may have a long term and reliable income stream, but if they break the
rules then that payment traffic will migrate to other solutions and they
end up with nothing. Whether it's worth it depends on how long term they're
thinking.
If we imagine a hypothetical future where lots of economic activity is
being done over Satoshi-style replaceable contracts, and suddenly a new big
short-termist miner comes along who decides that just breaking the rules
will give him more profit before the business dries up, what would happen?
If fraud costs get too extreme the old fallback of a purely centralised
solution is always there - for software compatibility purposes this would
look like a trusted node who doesn't broadcast the transactions at all and
just keeps them centrally, then mines or broadcasts the final version
themselves. Client apps would just be configured to connect directly to
that node.
Making that more competitive means having more such nodes/miners, until
eventually you have a network of miners that are regulated by identity and
bannable and don't share the tx's outside their network. That probably gets
you 95% of the benefit of the old model with maybe 150% (wild ass guess) of
the costs. "Identity" in this case can mean lots of fancy crypto things
beyond old-fashioned govt name+address style.
I don't think that'd be just an expensive and inefficient PayPal, as you'd
still have the key difference that simplifies so much - the trusted third
party doesn't hold any funds on deposit and can't directly
steal/lend/gamble with any funds. To earn money by being corrupt requires
complicated schemes where they strike secret deals to favour one party or
another, and that corruption can then be easily detected and published, so
it seems like the risk is much lower.
Bitcoin is already a pretty complex ecosystem with different kinds of trust
and decentralisation models in use. I see the next 5-10 years as a giant
cost optimisation experiment .... where are the best settings of the
various decentralisation/speed/fees/complexity/identity knobs for different
kinds of people?
--089e01419e02929aba050c64f292
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"><div=
>Firstly, apologies to Nathan for not actually providing feedback on his pr=
otocol. I've put pondering it onto my mental todo list. The notion of a=
payment tree is interesting but complicated - I would need to think about =
it and maybe draw myself some diagrams before having useful feedback here. =
If you wanted to implement it, you could fork the existing code in bitcoinj=
and extend it with the new functionality.</div><div><br></div><div>I raise=
d the original Satoshi design mainly to inform and so the approaches can be=
compared. It may well be that this proposed protocol is superior in every =
way, in which case the nSequence approach would be of no further use, assum=
ing Nathan's protocol generalises to n-party HFT.</div><div><br></div><=
div>Replying now to Gregory:</div><div><br></div><div>I think we agree, and=
are just phrasing things differently (or slowly groping towards consensus =
at the speed of email threads :-).</div><div><br></div><div>It's likely=
that over time Bitcoin will end up being multi-layered, with the block cha=
in being the base layer that syncs everyone up, and higher layers doing thi=
ngs that miners either can't do or can't be trusted to do. Like the=
proposal from GreenAddress to be a well known signer who is trusted to not=
double spend.</div><div><br></div><div>From miners perspective, there are =
multiple schemes where they are viable if cost(fraud) < benefit, at the =
moment unconfirmed transactions appear to be an example of that, and puttin=
g resource control considerations to one side, it's possible that tx re=
placement would be the same. Or not. The calculation for miners isn't e=
asy, because if they play by the rules then they may have a long term and r=
eliable income stream, but if they break the rules then that payment traffi=
c will migrate to other solutions and they end up with nothing. Whether it&=
#39;s worth it depends on how long term they're thinking.<br></div><div=
><br></div><div>If we imagine a hypothetical future where lots of economic =
activity is being done over Satoshi-style replaceable contracts, and sudden=
ly a new big short-termist miner comes along who decides that just breaking=
the rules will give him more profit before the business dries up, what wou=
ld happen? If fraud costs get too extreme the old fallback of a purely cent=
ralised solution is always there - for software compatibility purposes this=
would look like a trusted node who doesn't broadcast the transactions =
at all and just keeps them centrally, then mines or broadcasts the final ve=
rsion themselves. Client apps would just be configured to connect directly =
to that node.</div><div><br></div><div>Making that more competitive means h=
aving more such nodes/miners, until eventually you have a network of miners=
that are regulated by identity and bannable and don't share the tx'=
;s outside their network. That probably gets you 95% of the benefit of the =
old model with maybe 150% (wild ass guess) of the costs. "Identity&quo=
t; in this case can mean lots of fancy crypto things beyond old-fashioned g=
ovt name+address style.</div><div><br></div><div>I don't think that'=
;d be just an expensive and inefficient PayPal, as you'd still have the=
key difference that simplifies so much - the trusted third party doesn'=
;t hold any funds on deposit and can't directly steal/lend/gamble with =
any funds. To earn money by being corrupt requires complicated schemes wher=
e they strike secret deals to favour one party or another, and that corrupt=
ion can then be easily detected and published, so it seems like the risk is=
much lower.</div><div><br></div><div>Bitcoin is already a pretty complex e=
cosystem with different kinds of trust and decentralisation models in use. =
I see the next 5-10 years as a giant cost optimisation experiment =C2=A0...=
. where are the best settings of the various decentralisation/speed/fees/co=
mplexity/identity knobs for different kinds of people?</div></div></div></d=
iv>
--089e01419e02929aba050c64f292--
|
