public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Arkady <necronomics@riseup.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Date: Fri, 08 May 2015 06:33:18 +0000	[thread overview]
Message-ID: <4726ecd29577c6271e9e9dfdc5fc2a86@riseup.net> (raw)
In-Reply-To: <20150508000556.GA16794@savin.petertodd.org>

--[remove this line and above]--
On Thu, 7 May 2015, Gregory Maxwell wrote:

> Date: Thu, 7 May 2015 00:37:54 +0000
> From: Gregory Maxwell <gmaxwell@gmail.com>
> To: Matt Corallo <bitcoin-list@bluematt.me>
> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: Re: [Bitcoin-development] Block Size Increase
> 
> Thanks Matt; I was actually really confused by this sudden push with
> not a word here or on Github--so much so that I responded on Reddit to
> people pointing to commits in Gavin's personal repository saying they
> were reading too much into it.

I saw this. I was also pointing this out to the people who were asking 
me. A
commit to a personal repository does not at first seem more than
experimental. sipa commits weird/neat things to private branches all the
time, after all.

> to share behavior. In the case of mining, we're trying to optimize the
> social good of POW security. (But the analogy applies in other ways 
> too:

About the only argument IMO in favour of block size increases is to 
assume
that making more room in a block will make it attractive to use for more
people at some point in the future: increasing transaction velocity,
increasing economy size, increasing value overall.

> increases to the chain side are largely an externality; miners enjoy 
> the
> benefits, everyone else takes the costs--either in reduced security or
> higher node operating else.)

Who else but miners and pool operators will run full nodes when full 
nodes
are being shut down because they are too large and unwieldy to maintain? 
It
is already so that casual users refuse to run full nodes. This fact is
indisputable. The only question remaining is, "Do we care?" Arguments
against users who feel that the dataset is too large to run a full node,
full-time, start from a premise that these users are a static and 
irrelevant
fraction. Is this even true? "Do we care?" I do. I will shortly only be 
able
to run half the nodes I currently do thanks to the growth of the 
blockchain
at its current rate.

> One potential argument is that maybe miners would be _regulated_ to
> behave correctly. But this would require undermining the openness of 
> the
> system--where anyone can mine anonymously--in order to enforce 
> behavior,
> and that same enforcement mechanism would leave a political level to
> impose additional rules that violate the extra properties of the 
> system.

I would refuse to mine under such a regulated regime; moreover, I would
enjoy forking away from this, and, I suspect, the only miners who remain
would be those whose ultimate motivations do not coincide with the 
users.
That is, the set of miners who are users, and the set of users who are
miners, would be wholly non-intersecting.

> So far the mining ecosystem has become incredibly centralized over 
> time.

This is unfortunate but true.

> of the regular contributors to Bitcoin Core do. Many participants
> have never mined or only did back in 2010/2011... we've basically
> ignored the mining ecosystem, and this has had devastating effects,
> causing a latent undermining of the security model: hacking a dozen or
> so computers--operated under totally unknown and probably not strong
> security policies--could compromise the network at least at the tip...

The explicit form of the block dictated by the reference client and
agreed-to by the people who were sold on bitcoin near the beginning 
(myself
included) was explicitly the notion that the rules were static; that the
nature of transaction foundations and the subsidies would not be 
altered.
Here we have a hardfork being contemplated which is not only 
controversial,
but does not even address some of the highest-utility and most-requested
features in peoples' hardfork wishlists.

The fact that mining has effectively been centralized directly implies 
that
destabilizing changes that some well-heeled (and thus theoretically 
capable,
at least) people have explicitly begun plans to fork the blockchain 
about
will have an unknown, and completely unforeseen combined effect.

We can pretend that, "If merchants and miners and exchanges go along, 
then
who else matters," but the reality is that the value in bitcoin exists
because *people* use it for real transactions: Not miners, whose profits 
are
parasitically fractionally based on the quality and strength of the 
bitcoin
economy as a whole; not exchanges who lubricate transactions in service 
to
the economy; not even today's merchants whose primary means of accepting
bitcoin seems to be to convert them instantly to fiat and not 
participate
meaningfully in the economy at all; not enriched felons; but actual 
users
themselves.

> Rightfully we should be regarding this an an emergency, and probably
> should have been have since 2011.

There are two ways to look at it, assuming that the blocksize change
increases bitcoin's value to people after all: mining centralization 
will be
corrected; or, mining centralization will not be corrected.

I would argue that rapidly increasing profitability at this point will
exacerbate the mining centralization problem, and in much the same way 
as
when people were throwing money and unknowingly funding the massive 
frauds
of the current cabals when bitcoin's exchange-driven rise to $1200 was 
first
realized.

Thus, even if the premise were true, what will a blocksize increase 
achieve
given mining centralization itself is a bigger systemic risk?

> Hardfork changes should only be made if they're almost completely
> uncontroversial--where virtually everyone can look at the available 
> data
> and say "yea, that isn't undermining my property rights or future use
> of Bitcoin; it's no big deal".

The recent "revelation" that there are masses of paid trolls on popular
forum sites like reddit who supposedly don't even know who is hiring 
them,
and the anger of more vociferous commenters in general, does not 
invalidate
the relevance of every non-"industry" voice.  I think elevating the
discussion away from the users does the system and the development 
process
as a whole quite an injustice.

> I'm curious as to what discussions people have seen; e.g., are people
> even here aware of these concerns? Are you aware of things like the
> hashcash mediated dynamic blocksize limiting?

I have seen most of these; or the ideas seem obvious based on their 
names.

> About proposals like lightning network (instant transactions and 
> massive
> scale, in exchange for some short term DOS risk if a counterparty opts
> out)? Do people (other than Mike Hearn; I guess) think a future where
> everyone depends on a small number of "Google scale" node operations 
> for
> the system is actually okay? (I think not, and if so we're never going 
> to
> agree--but it can be helpful to understand when a disagreement is
> ideological).

It is not okay. If the current mining cabals continue to exist, and
flourish, and the developers make major changes that ignore this glaring
elephant, then the decentralized promise of bitcoin will be put more at
risk.

signmessage 1DdcrjT9Yqb6U58wVMA2e7untFbz2rmZd4 
"49786791f4d0a260689867ccdfb2cc5b8460984e335504444ade113d2768505c"
G6NPl7Wklo9lcdgeVI2H2pexzgqD0KPHhI/wAe32DBm8m59Qf31j5d4tsx5drcql/8wPeIb0QGarr/o4VIOLLGE=

--[remove this line and below]--
HHsTfiZ/S7+GNYRwws+QyAr+6/MgDz0Jyntl7CAvjhdfzbnwPorybQUXxRw3CE4DgYgAy1zLanE8H/5NK+l3UlE=




  reply	other threads:[~2015-05-08  6:33 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-07 22:02 [Bitcoin-development] Block Size Increase Requirements Matt Corallo
2015-05-07 23:24 ` Joseph Poon
2015-05-08  0:05 ` Peter Todd
2015-05-08  6:33   ` Arkady [this message]
2015-05-08 10:03 ` Mike Hearn
2015-05-08 16:37   ` Peter Todd
2015-05-08 19:47     ` Tier Nolan
2015-05-09  3:08       ` Peter Todd
2015-05-16  4:39         ` Stephen
2015-05-16 11:29           ` Tier Nolan
2015-05-16 11:25         ` Tier Nolan
2015-05-29 22:36 ` Gavin Andresen
2015-05-29 23:25   ` Matt Corallo
     [not found]     ` <CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
2015-05-30 19:32       ` Matt Corallo
2015-05-30 20:37         ` Gavin Andresen
2015-05-31 14:46           ` Jorge Timón
2015-05-31 14:49             ` Gavin Andresen
2015-05-31 14:59               ` Jorge Timón
2015-05-31 15:08                 ` Gavin Andresen
2015-05-31 15:45                   ` Jorge Timón
2015-05-29 23:42 ` Chun Wang
2015-05-30 13:57   ` Gavin Andresen
2015-05-30 14:08     ` Pindar Wong
2015-05-30 22:05     ` Alex Mizrahi
2015-05-30 23:16       ` Brian Hoffman
2015-05-31  0:13         ` Alex Mizrahi
2015-05-31  5:05       ` gb
     [not found]     ` <CAFzgq-z5WCznGhbOexS0XESNGAVauw45ewEV-1eMij7yDT61=Q@mail.gmail.com>
2015-05-31  1:31       ` [Bitcoin-development] Fwd: " Chun Wang
2015-05-31  2:20         ` Pindar Wong
2015-05-31 12:40         ` Gavin Andresen
2015-05-31 13:45           ` Alex Mizrahi
2015-05-31 14:54             ` Gavin Andresen
2015-05-31 22:55               ` Alex Mizrahi
2015-05-31 23:23                 ` Ricardo Filipe
2015-05-31 23:40                   ` Pindar Wong
2015-05-31 23:58                     ` Ricardo Filipe
2015-06-01  0:03                       ` Pindar Wong
2015-06-01  7:57                   ` Alex Mizrahi
2015-06-01 10:13                     ` Mike Hearn
2015-06-01 10:42                       ` Pindar Wong
2015-06-01 11:26                         ` Peter Todd
2015-06-01 12:19                           ` Pindar Wong
2015-06-01 11:02                       ` Chun Wang
2015-06-01 11:09                         ` Pindar Wong
2015-06-01 11:20                         ` Chun Wang
2015-06-01 13:59                           ` Gavin Andresen
2015-06-01 14:08                             ` Chun Wang
2015-06-01 15:33                               ` Mike Hearn
2015-06-01 16:06                                 ` Ángel José Riesgo
2015-06-01 14:46                             ` Oliver Egginger
2015-06-01 14:48                               ` Chun Wang
2015-06-01 16:43                             ` Yifu Guo
2015-06-01 20:01                             ` Roy Badami
2015-06-01 20:15                               ` Roy Badami
2015-06-01 13:21                         ` Mike Hearn
2015-06-01 12:29                       ` Warren Togami Jr.
2015-06-01 13:15                 ` Gavin Andresen
2015-05-31 12:52         ` Gavin Andresen
2015-05-31 13:31           ` [Bitcoin-development] [Bulk] " gb
2015-05-31 19:49             ` Gavin Andresen
2015-05-31 14:17           ` [Bitcoin-development] " Dave Hudson
2015-05-31 14:34         ` Yifu Guo
2015-05-31 14:47           ` Gavin Andresen
2015-05-31  7:05   ` [Bitcoin-development] " Peter Todd
2015-05-31 12:51     ` Gavin Andresen
2015-05-30 23:18 Raystonn
2015-05-31  0:32 ` Alex Mizrahi

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=4726ecd29577c6271e9e9dfdc5fc2a86@riseup.net \
    --to=necronomics@riseup.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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