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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Y9atE-0007VB-HF
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 14:50:16 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.176 as permitted sender)
client-ip=209.85.223.176; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f176.google.com;
Received: from mail-ie0-f176.google.com ([209.85.223.176])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Y9atC-0007yN-M8
for bitcoin-development@lists.sourceforge.net;
Fri, 09 Jan 2015 14:50:16 +0000
Received: by mail-ie0-f176.google.com with SMTP id tr6so15341132ieb.7
for <bitcoin-development@lists.sourceforge.net>;
Fri, 09 Jan 2015 06:50:09 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.178.143 with SMTP id cy15mr2818449igc.8.1420815009373;
Fri, 09 Jan 2015 06:50:09 -0800 (PST)
Received: by 10.107.16.30 with HTTP; Fri, 9 Jan 2015 06:50:09 -0800 (PST)
In-Reply-To: <CANEZrP1H-_4XiG+Azm7M4FgLrayuML+kdQ7LineXsU3FUH6=Qw@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>
Date: Fri, 9 Jan 2015 14:50:09 +0000
Message-ID: <CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Y9atC-0007yN-M8
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 14:50:16 -0000
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn <mike@plan99.net> wrote:
> 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
This being unsafe doesn't require "a lot" though, if 1% of the
hashpower is naughty, an attacker will have a 1% success rate. Naughty
can also just mean broken in various ways, like mining while somewhat
partitioned (didn't hear the update) potentially due to a DOS attack,
or because of some garbage collection policy made it forget the
transaction to conserve resources. An unkind user can simply run
software that automatically attempts (by sending naughty miners an
earlier conflict right before the locktime expires). "Use Blue
Rewards wallet for 2% cash back for all the Bitcoin purchases you make
online!" :P
Of course, all the miners who don't play along will very much see how
much income they're missing.
> so clients can enforce that all versions have the same fee attached
Sadly, they cannot. This is why I specifically mentioned child pays for parent.
In any case, sometimes a 1% fault rate is acceptable. But generally
for cases that they are, even weaker constructs (e.g. no payment
channel at all, just accept an IOU) are also often acceptable, and
cannot be modulated in their success by resource starvation attacks on
the network.
We have objective proof of substantial miners behaving maliciously,
that much isn't a speculative concern.
The school of thought view is a bit too black and white. My
perspective is that absolute soundness is best (rules which cannot be
broken at all), followed by cryptographic soundness (rules that
breaking requires P=NP, theft of a secret, or insane luck), followed
by economic soundness (rules that cannot be profitably broken),
followed by honesty soundness (rules that hold when the participants
follow the rules and aren't faulty). We should try to move up that
stack as far towards absolutely soundness as possible; and be
increasingly cautious about compromises as we move down it espeically
because the last two are unstable and difficult to reason about
because they strongly import the vulgarities of humanity into the
security model. If we could make the whole system absolutely sound
or cryptographically sound, I would think we should (and would) even
if it implied other compromises. But we can't and so users of Bitcoin
must navigate this risk stack.
One thing that I think you miss in this argument is that one man's
integrity is another man's malice. The history of security and
privacy is filled with instances where someone's trust was violated
because there someone was, rightly or wrongly, convinced that Some
Reason was Good Enough to justify it. Because of this a risk analysis
has to import the clarity of judgement, morality, coerceability,
personal values, etc. of everyone in the trust chain; and many of
these things are unknowable; this greatly increases the costs of
transacting, and the efforts to mitigate those costs (and the failures
to remove the harms) result in an unequitable enviroment where some
people get unjust rewards and unequal access to justice. The gain from
cryptographic tools is being able to make some level of stronger
assurances which cut out most of that trust, they're predictable,
'cheap' on a marginal basis, and fair in a fundamental sense (in
theory everyone has equal access to math). So, while I could even buy
the argument that miners will never believe themselves to be "actually
malicious", history shows that people's ability to convince themselves
of the justification of something is basically unbounded, even
outright thieves often believe they're owed their spoils-- and there
are a lot of ways to misbehave in Bitcoin that stop short of theft.
And so, where we cannot have cryptographic security enforce the rules,
we-- those who use and depend on Bitcoin-- _generally_ ought to behave
in ways that cannot be harmed by a failure to follow the rules so that
we don't _invite_ failures to follow the rules and thereby create an
institution of it.
Of course, all things equal I don't want to choose for other people
what tools they can use and what risks they take. But in the case of
relaying locked transactions this isn't an otherwise neutral choice: A
straight forward "relay and store any locked spend" policy has
unbounded space and communications complexity. It's not clear to me
that if any real degree of "you can take your risks, it'll probably
work, but maybe not" can be supported without a very large resource
cost to the network, and without creating incentives to DOS attack the
network (e.g. to make it forget previous spends). It may be that
there is some set of constraints that actually do make it workable and
don't create the incentives though... meaning that it may _merely_ be
unsafe for people who choose to use it. If so, then it might be
reasonable but we also cannot ignore the incentives it creates in a
wider ecosystem and what their ultimate conclusion might be. E.g. If
you put a bounty for miners to behave 'wrong' in a way the system
cannot prevent, some will. Is the next step to try to say that only
"good" miners can mine? If so, how many more steps until every
transaction is being tested against a set of system external goodness
criteria? In that state, is Bitcoin any better than a very
computationally and bandwidth inefficient version of Paypal?
Slipper slope arguments can be a bit slippery. I don't have any clear
answers. I do know that ignoring the risks we know about isn't a good
path.
|
