From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY
Date: Fri, 9 Jan 2015 14:50:09 +0000 [thread overview]
Message-ID: <CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1H-_4XiG+Azm7M4FgLrayuML+kdQ7LineXsU3FUH6=Qw@mail.gmail.com>
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.
next prev parent reply other threads:[~2015-01-09 14:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 11:40 Nathan Cook
2015-01-09 13:20 ` Mike Hearn
2015-01-09 13:22 ` Jeff Garzik
2015-01-09 13:42 ` Mike Hearn
2015-01-09 14:50 ` Gregory Maxwell [this message]
2015-01-11 18:56 ` Mike Hearn
2015-01-11 9:16 ` odinn
2015-01-09 13:26 ` Gregory Maxwell
2015-01-11 22:24 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAS2fgTMKwo2LOAmW+WzFnHcE7UXvCKgi7WCQLMtGDn2eaxLDA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox