From: Gregory Maxwell <gmaxwell@gmail.com>
To: Stephen Pair <stephen@bitpay.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain
Date: Wed, 13 Feb 2013 16:28:41 -0800 [thread overview]
Message-ID: <CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com> (raw)
In-Reply-To: <CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair <stephen@bitpay.com> wrote:
> If you've already validated the majority of transactions in a block, isn't validating the block not all that compute intensive? Thus, it's really not blocks that should be used to impose any sort of scarcity, but rather it's the costs associated with the validation and propagation of the transactions themselves...which is the way it should be.
The cost to whom? This is important because the cost of validating
blocks is borne by all the participants in Bitcoin— or at least all
the participants who haven't given up on the decenteralized trustless
stuff and are simply trusting someone else. Even a small cost
becomes large when hundreds of thousands.
And perhaps you don't lament people delegating their trust to large
entities— but keep in mind: Bitcoin was created for the express
purpose of creating a money system which didn't require trust because
it was based on cryptographic proof— mathematical law— instead of
politics and human law. Take that away and you have a really poorly
understood inefficient system operated by entities which are less
trustworthy and rightfully entitled to authority than the ones
operating the established major currencies.
> When I think about issues like this, I like to remind myself that the mesh network isn't really an essential part of Bitcoin.
Thats absolutely true— but I don't know that it's relevant in this case.
> Nodes can at some point start to charge fees to collect and distribute transactions and blocks.
They can— but doing so would radically undermine Bitcoin.
A refresher:
If you combine digital signatures with simple transaction rules you
can have a purely autonomous monetary system based entirely on math.
It would be perfect, anonymous, scalable ... except for the problem
of double spending. To solve double spending the participants must
agree on which of a set of duplicated payments is one the
authoritative one. Coming to this agreement is fundamentally hard just
at the basics of physics— a result of relativity is that observers
will perceive events in different orders depending on the observer's
and the events relative locations. If no observer is privileged (a
decenteralized system) you have to have a way of reaching a consensus.
This kind of efficient consensus we need— which which participants can
join or enter at any time, which doesn't require exponential
communication, and which is robust against sock-puppet participants—
was long believed to be practically impossible. Bitcoin solved the
problem by using hashcash to vote— because real resources were forever
expended in the process the sock-puppet problem is solved. But the
vote only works if everyone can see the results of it: We assume that
the majority of hashpower isn't a dishonest party, and that honest
nodes can't be prevented from hearing the honest history. Nodes choose
then rules-valid history that has the most work (votes) expended on
it... but they can only choose among what they know of. As Satoshi,
wrote: "[Bitcoin] takes advantage of the nature of information being
easy to spread but hard to stifle".
The requirement for everyone to hear the history doesn't get talked
about much— at least with reasonably sized blocks and today's
technical and common political climates the assumption that
information is easy to spread but hard to stifle is a very sound one.
It's a good thing, because this assumption is even more important than
the hash-power honesty assumption (a malicious party with a simple
majority of hashpower is much weaker than one who can partition the
network). ... but that all goes out the window if communicating
blocks is costly enough that the only way to sustain it is to
jealously guard and charge for access/forwarding.
The consequence of such a change is that the Bitcoin consensus
algorithm would be handicapped. How long must you wait before you know
that the history you have won't get replaced by a more authoritative
one? Today an hour or two seems relatively solid. In a world with
non-uniform block forwarding perhaps it takes days— if ever— before
any participant is confident that there isn't a better history
lurking.
All doubly so if the bookkeeping required for this payment ends up
necessitating additional transactions and adds to the load.
[This is also the flaw in the 'Red Balloons' paper, making
transactions a dozen times longer just to attach credit for forwarding
doesn't seem wise compared to keep transactions so cheap to transmit
that even a small number of altruists make the equilibrium state be
liberally-forwarding]
> They would also charge for the propagation of blocks based on the work required to validate them.
Large miners would obviously locate and connect to each other. Even
enormous blocks are no problems for big industrial players.
Don't want to pay the cost to get their big blocks from them? Your
loss: If you don't take their blocks and they constitute the longest
history, you'll be believing the wrong history until such a time as
you wise up and pay the piper. Your transactions will be reversed and
you'll lose money.
You can hypothesize some cartel behavior external to the rules of the
system— where by some consensus mechanism (????) some super large mass
of participants agree to reject blocks according 'extrajudicial
rules', some rule existing outside of Bitcoin itself— but there must
be a consensus because rejecting blocks by yourself only gets you
ripped off.
I don't see how this works— it basically embeds another hard consensus
problem (what is the criteria for blocks to be valid?) inside our
solution to a hard consensus problem (which are the best valid
blocks?), but doesn't benefit from the same incentive structure—
locally-greedy miners obviously want to produce the largest blocks
possible— and in hashpower consensus non-miners don't have a voice.
That might be acceptable for ordering, but now you're deciding on the
rules of the system which all non-trusting participants must validate.
You could instead solve that consensus problem with politically
stipulated regulation or industry cartels, or good old-fashion kneecap
busting or whathave you. But then Bitcoin loses the transparency and
determinism that make it worthwhile.
I sure hope to hear something better than that.
This is basically the gap: Right now I could afford hardware that
could process multiple gigabyte blocks— maybe it only costs as much as
a small house which is not an insane cost for a large business. But
the cost would be decidedly non-negligible and it would be rational
for me to let someone else take it. Applied to everyone, you end up
with a small number of the most vested parties doing all the
validation, and so they have full ability to manipulate like today's
central banks.
For a great many to perform validation— keeping the system honest and
decentralized as it was envisioned— without worrying about the cost
requires that the cost be almost unnoticeable. A tiny fraction of what
some industrial player— who profit from consolidation and
manipulation— could easily handle. I'm skeptical about the system
internally self-regulating the size because of what gets called
"evaporative cooling" in social sciences— the cost goes up, some
people cross their "hey, I'm better off if I externalize the cost of
keeping Bitcoin secure by not participating" boundary and lose their
voice.
There is probably some equilibrium where Bitcoin is compromised
frequently enough that more validators spin up (and ignore past rule
violations which can't be undone without economic Armageddon), and eat
the costs even though there is an insane amount of freeloading going
on. The trustworthiness of today's monetary systems suggests to me
that if there is an equilibrium point here it isn't a very trustworthy
one. There is an even stronger equilibrium state available too: don't
use Bitcoin at at all. If you want a system which is dominated by
political whim and expedience and large industrial players and is, as
a result, only somewhat trustworthy you can just use government issued
currencies— they're well established and have a lot less overhead than
this decentralized stuff.
(And generally— Security makes for a terrible market, security is
naturally a lemon market. The need is only clear in hindsight. In our
case it would be one with an enormous freeloading problem)
> P.S. such a fee structure would address the spam issue with economics rather than rules about spammy transactions
Our current anti-spam one is primarily an economic one— transactions
prioritized based on fee per KB in scarce blocks or priority (another
scarce commodity), the only really non-very-economic part is the
very-small-output heuristic. I would argue that our economic
anti-spam mechanisms are currently failing at their job: Various
parties are engaging in transaction patterns with near pessimal
efficiency— using a dozen (— sometimes thousands) of transactions
where one or two would be adequate. This isn't limited to just one or
two sites— many parties are using inefficient transaction patterns—
creating externalized costs on all future Bitcoin users—, simply
because there is hardly any incentive not to.
Though much discussion among technical people, no one has come up with
any reparametrizations that seem likely to achieve the desired
incentive alignment in the near term. Of all the elements of the
anti-spam policy, it seems to me that the least economic— the minimum
output size— is actually the most effective (most spam suppression
relative to efficient usage suppression), especially as we move to
focusing on the UTXO set size. (The minimum output value requirement
discourages the creation of UTXOs which will never be economically
rational to redeem).
next prev parent reply other threads:[~2013-02-14 0:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 13:49 [Bitcoin-development] Incorporating block validation rule modifications into the block chain Raph Frank
2013-02-12 15:49 ` Gregory Maxwell
2013-02-13 14:58 ` Raph Frank
2013-02-13 15:42 ` Gregory Maxwell
2013-02-13 21:02 ` Gavin Andresen
2013-02-13 21:05 ` Gregory Maxwell
2013-02-13 23:10 ` Stephen Pair
2013-02-14 0:28 ` Gregory Maxwell [this message]
2013-02-14 2:44 ` Stephen Pair
2013-02-14 3:38 ` Gregory Maxwell
2013-02-14 5:36 ` Stephen Pair
2013-02-14 6:07 ` Peter Todd
2013-02-14 12:59 ` Stephen Pair
2013-02-18 16:22 ` Peter Todd
2013-02-14 1:02 ` Gregory Maxwell
2013-02-14 6:39 ` 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='CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com' \
--to=gmaxwell@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=stephen@bitpay.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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