path: root/d8/14d78ee134f9a2142dc1af1356b4e80bae7a6a

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gmaxwell@gmail.com>) id 1U5mh1-0003kh-6P
	for bitcoin-development@lists.sourceforge.net;
	Thu, 14 Feb 2013 00:28:51 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.174 as permitted sender)
	client-ip=209.85.217.174; envelope-from=gmaxwell@gmail.com;
	helo=mail-lb0-f174.google.com; 
Received: from mail-lb0-f174.google.com ([209.85.217.174])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1U5mgy-0006sS-F6
	for bitcoin-development@lists.sourceforge.net;
	Thu, 14 Feb 2013 00:28:51 +0000
Received: by mail-lb0-f174.google.com with SMTP id l12so1388112lbo.33
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 Feb 2013 16:28:41 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.125.237 with SMTP id mt13mr21995923lab.45.1360801721806; 
	Wed, 13 Feb 2013 16:28:41 -0800 (PST)
Received: by 10.112.96.164 with HTTP; Wed, 13 Feb 2013 16:28:41 -0800 (PST)
In-Reply-To: <CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
	<CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
	<CAN1xFdrGiWmn_EaBNMXXZAV38oeqP14YiMzMZQrkA+WL9QEMfA@mail.gmail.com>
	<CAAS2fgR5=nLTBQUBzjZQs91AVw5XSTiqe-KB_T9R9wKfBrOq6Q@mail.gmail.com>
	<CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
	<CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
Date: Wed, 13 Feb 2013 16:28:41 -0800
Message-ID: <CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Stephen Pair <stephen@bitpay.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
X-Headers-End: 1U5mgy-0006sS-F6
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule
 modifications into the block chain
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: Thu, 14 Feb 2013 00:28:51 -0000

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 n=
ot 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 transact=
ions 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=E2=80=94 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=E2=80=94 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=E2=80=94 mathematical law=E2=80=94 inst=
ead 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 mes=
h network isn't really an essential part of Bitcoin.

Thats absolutely true=E2=80=94 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 tr=
ansactions and blocks.

They can=E2=80=94 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=E2=80=94 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=E2=80=94 which which participants =
can
join or enter at any time, which doesn't require exponential
communication, and which is robust against sock-puppet participants=E2=80=
=94
was long believed to be practically impossible.  Bitcoin solved the
problem by using hashcash to vote=E2=80=94 because real resources were fore=
ver
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=E2=80=94 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=E2=80=94 if ever=E2=80=
=94 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 re=
quired 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=E2=80=94 where by some consensus mechanism (????) some super large m=
ass
of participants agree to reject blocks according 'extrajudicial
rules', some rule existing outside of Bitcoin itself=E2=80=94 but there mus=
t
be a consensus because rejecting blocks by yourself only gets you
ripped off.

I don't see how this works=E2=80=94 it basically embeds another hard consen=
sus
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=E2=80=94
locally-greedy miners obviously want to produce the largest blocks
possible=E2=80=94 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=E2=80=94 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=E2=80=94 keeping the system honest a=
nd
decentralized as it was envisioned=E2=80=94 without worrying about the cost
requires that the cost be almost unnoticeable. A tiny fraction of what
some industrial player=E2=80=94 who profit from consolidation and
manipulation=E2=80=94 could easily handle.  I'm skeptical about the system
internally self-regulating the size because of what gets called
"evaporative cooling" in social sciences=E2=80=94 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=E2=80=94 they're well established and have a lot less overhead t=
han
this decentralized stuff.

(And generally=E2=80=94 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 rat=
her than rules about spammy transactions

Our current anti-spam one is primarily an economic one=E2=80=94 transaction=
s
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=E2=80=94 using a dozen (=E2=80=94 sometimes thousands) of transa=
ctions
where one or two would be adequate. This isn't limited to just one or
two sites=E2=80=94 many parties are using inefficient transaction patterns=
=E2=80=94
creating externalized costs on all future Bitcoin users=E2=80=94, 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=E2=80=94 the minim=
um
output size=E2=80=94 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).