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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Y9Zq8-0003mW-JS
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 13:43:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.173 as permitted sender)
client-ip=74.125.82.173; envelope-from=mh.in.england@gmail.com;
helo=mail-we0-f173.google.com;
Received: from mail-we0-f173.google.com ([74.125.82.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y9Zq6-0003Zv-O2
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 13:43:00 +0000
Received: by mail-we0-f173.google.com with SMTP id q58so8013182wes.4
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Jan 2015 05:42:52 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.92.116 with SMTP id cl20mr3521047wjb.71.1420810972698;
Fri, 09 Jan 2015 05:42:52 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.9 with HTTP; Fri, 9 Jan 2015 05:42:52 -0800 (PST)
In-Reply-To: <CAJHLa0NoDU+DOPfubhbVs8_Y92+uGG=mZ2+ruRCXkeULghWVVg@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>
Date: Fri, 9 Jan 2015 14:42:52 +0100
X-Google-Sender-Auth: 2kf2vmocGuIV8-hRWK8Yhdv8nqY
Message-ID: <CANEZrP1H-_4XiG+Azm7M4FgLrayuML+kdQ7LineXsU3FUH6=Qw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeff Garzik <jgarzik@bitpay.com>
Content-Type: multipart/alternative; boundary=047d7bd910c252204b050c38554f
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: 1Y9Zq6-0003Zv-O2
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: Fri, 09 Jan 2015 13:43:00 -0000
--047d7bd910c252204b050c38554f
Content-Type: text/plain; charset=UTF-8
The original design is documented at the bottom of here:
https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
In this design, time locked transactions can be broadcast across the
network and replaced by broadcasting a new transaction that uses higher
sequence numbers. That's what the sequence number field is for. It was
intended to allow arbitrary high frequency trading between a set of
parties, though the "channel" notion is a simple way to think about the two
party case.
The issue is that you can broadcast transactions with a lock time far in
the future to fill up memory, and keep broadcasting replacements to use up
CPU time and bandwidth.
Additionally, there is a school of thought that says Bitcoin must work even
if lots of miners are malicious and willing to break arbitrary things in
order to try and get more money. I don't think Bitcoin can really be a
mainstream success under such a threat model, for a whole bunch of reasons
(e.g. the economy relies pretty heavily on unconfirmed transactions), but
under such a threat model there's nothing that forces miners to actually
include the latest version in the block chain. They could pick any version.
In the 2-of-2 channel model it takes both parties to sign, so clients can
enforce that all versions have the same fee attached.
I disagree with Gregory that people refuse to use protocols that are
affected by malleability. There aren't any user-friendly apps that use
refunds currently, so we have no idea whether people would refuse to use
them or not. It's an open question. The answer would probably depend on the
real prevalence of attacks, which is currently unknowable and likely
application specific.
--047d7bd910c252204b050c38554f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The original design is documented at the bottom of here:<d=
iv><br></div><div><a href=3D"https://en.bitcoin.it/wiki/Contracts#Example_7=
:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party">https://e=
n.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments=
_to_a_pre-determined_party</a><br></div><div><br></div><div>In this design,=
time locked transactions can be broadcast across the network and replaced =
by broadcasting a new transaction that uses higher sequence numbers. That&#=
39;s what the sequence number field is for. It was intended to allow arbitr=
ary high frequency trading between a set of parties, though the "chann=
el" notion is a simple way to think about the two party case.</div><di=
v><br></div><div>The issue is that you can broadcast transactions with a lo=
ck time far in the future to fill up memory, and keep broadcasting replacem=
ents to use up CPU time and bandwidth.</div><div><br></div><div>Additionall=
y, there is a school of thought that says Bitcoin must work even if lots of=
miners are malicious and willing to break arbitrary things in order to try=
and get more money. I don't think Bitcoin can really be a mainstream s=
uccess under such a threat model, for a whole bunch of reasons (e.g. the ec=
onomy relies pretty heavily on unconfirmed transactions), but under such a =
threat model there's nothing that forces miners to actually include the=
latest version in the block chain. They could pick any version. In the 2-o=
f-2 channel model it takes both parties to sign, so clients can enforce tha=
t all versions have the same fee attached.</div><div><br></div><div>I disag=
ree with Gregory that people refuse to use protocols that are affected by m=
alleability. There aren't any user-friendly apps that use refunds curre=
ntly, so we have no idea whether people would refuse to use them or not. It=
's an open question. The answer would probably depend on the real preva=
lence of attacks, which is currently unknowable and likely application spec=
ific.</div><div><br></div></div>
--047d7bd910c252204b050c38554f--
|
