public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoin-dev] A reason we can all agree on to increase block size
@ 2015-08-02 21:02 Jim Phillips
  2015-08-03  1:21 ` Pindar Wong
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Jim Phillips @ 2015-08-02 21:02 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

China is a communist country. It is no secret that all "capitalist"
enterprises are essentially State controlled, or at the very least are
subject to nationalization should the State deem it necessary. Most ASIC
chips are manufactured in China, so they are cheap and accessible to
Chinese miners. Electricity is subsidized and essentially free. Cooling is
not an issue since large parts of China are mountainous and naturally cool.
In short the Chinese miners have HUGE advantages over all other mining
operations. This is probably why, between just the top 4 Chinese miners,
the People's Republic of China effectively controls 57% of all the Bitcoin
being mined.

The ONLY disadvantage the Chinese miners have in competing with the rest of
the world is bandwidth. China has poor connectivity with the rest of the
world, and Chinese miners have said that an increase in the block size
would be detrimental to them. I say, GOOD! Most of the free world has
enough bandwidth to be able to handle larger blocks. We need to take
advantage of that fact to get mining out of the centralized control of the
Chinese.

If you're truly worried about larger blocks causing centralization, think
about how, by restricting blocksize, you're enabling the Communist Chinese
government to maintain centralized control over 57% of the Bitcoin hashing
power.

--
*James G. Phillips IV*
<https://plus.google.com/u/0/113107039501292625391/posts>
<http://www.linkedin.com/in/ergophobe>

*"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
-- David Ogilvy*

 *This message was created with 100% recycled electrons. Please think twice
before printing.*

[-- Attachment #2: Type: text/html, Size: 2378 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-02 21:02 [bitcoin-dev] A reason we can all agree on to increase block size Jim Phillips
@ 2015-08-03  1:21 ` Pindar Wong
  2015-08-03  4:33   ` Jim Phillips
  2015-08-03  3:13 ` odinn
  2015-08-03  6:34 ` Adam Back
  2 siblings, 1 reply; 19+ messages in thread
From: Pindar Wong @ 2015-08-03  1:21 UTC (permalink / raw)
  To: Jim Phillips; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 2688 bytes --]

Dear Jim,

Thank you for sharing your view w.r.t. the so called 'Chinese Miners'.

Diversity of opinion, and mining, are IMHO both good and it's indeed a
free world.... so others who wish to mine bitcoin should be encouraged  to
make the capital and technical investments to do so.

May I ask what is your technical suggestion to move this discussion forward
beyond your anti-Chinese/anti-China rhetoric?   e.g. I would be
particularly grateful if you could share your  views w.r.t. colluding miner
attacks in draft 0.5.9. of Joseph Poon and Thaddeus Dryja's 'Lightning
network' paper, found here:-

http://lightning.network/lightning-network-paper.pdf

Respectfully,

p.



On Mon, Aug 3, 2015 at 4:02 AM, Jim Phillips via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> China is a communist country. It is no secret that all "capitalist"
> enterprises are essentially State controlled, or at the very least are
> subject to nationalization should the State deem it necessary. Most ASIC
> chips are manufactured in China, so they are cheap and accessible to
> Chinese miners. Electricity is subsidized and essentially free. Cooling is
> not an issue since large parts of China are mountainous and naturally cool.
> In short the Chinese miners have HUGE advantages over all other mining
> operations. This is probably why, between just the top 4 Chinese miners,
> the People's Republic of China effectively controls 57% of all the Bitcoin
> being mined.
>
> The ONLY disadvantage the Chinese miners have in competing with the rest
> of the world is bandwidth. China has poor connectivity with the rest of the
> world, and Chinese miners have said that an increase in the block size
> would be detrimental to them. I say, GOOD! Most of the free world has
> enough bandwidth to be able to handle larger blocks. We need to take
> advantage of that fact to get mining out of the centralized control of the
> Chinese.
>
> If you're truly worried about larger blocks causing centralization, think
> about how, by restricting blocksize, you're enabling the Communist Chinese
> government to maintain centralized control over 57% of the Bitcoin hashing
> power.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
>  *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 4012 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-02 21:02 [bitcoin-dev] A reason we can all agree on to increase block size Jim Phillips
  2015-08-03  1:21 ` Pindar Wong
@ 2015-08-03  3:13 ` odinn
  2015-08-03  6:34 ` Adam Back
  2 siblings, 0 replies; 19+ messages in thread
From: odinn @ 2015-08-03  3:13 UTC (permalink / raw)
  To: bitcoin-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim, some good points... People are rightly concerned about any given
regional or nation-state's dominance in mining, but China has
certainly become more of a subject of concern as of late, and not
simply because it is a communist country and because its economy is
highly centralized and state-run, but rather, because of the advent of
newly proposed or adopted laws (not unlike those which we see being
proposed in the UK or those recently adopted in France, so that no-one
may say I am unfairly targeting China).  Further, the recent shots off
the bow between the USA and China in the latest crypto-wars saga
(whether bluster or ultimately not) mean that we should be seriously
concerned about too much mining happening in one specific region; thus
there shouldn't be too much incentive for that to happen, yet at the
time being (as you've rightly pointed out) the subsidization of
electricity there, combined with the availability of certain
environmental conditions for cooling and / or hydropower, means that
China dominates the mining realm.

Recently I took the time to ask someone associated with a new bitcoin
mining operation in China some questions about the new (apparently
developing) National Security Law of China.

According to an early draft of this National Security Law, "the State
maintains the basic economic system and order of the socialist
marketplace ... safeguarding security in important industries and
fields that influence the populace's economic livelihood ... as well
as other major economic interests."

The Chinese government is currently reviewing another national
security related law, which in its first draft would mandate ALL
Internet companies operating in China to provide backdoor access and
encryption keys to the government.  (One would imagine that would
include any exchanges and mining operations as well.)

The US FBI Director (Comey) has also, of course, made plenty of
arguments for backdoors in encryption.  But as security expert Bruce
Schneier points out, there "really is no way" to keep users' data safe
while providing backdoors. He said:

    "I have two options. I can design a secure system that has no
backdoor access, meaning neither criminals nor foreign intelligence
agencies nor domestic police can get at the data. Or I can design a
system that has backdoor access, meaning they all can."
(Reference:
http://www.zdnet.com/article/because-there-is-no-such-thing-as-a-secure-
backdoor-gosh-darn-it/
)

Anyway, the response of the individual (eric@haobtc - of haobtc.com)
to my questions can be seen here:

https://bitcointalk.org/index.php?topic=1072474.msg11914077#msg11914077

His responses were provided to me before the recent "Crypto Wars"
announcements which I think will only think make things worse:

https://twitter.com/helios_unbound/status/627648646985719809

So, I try to be optimistic, but I'm leaning pessimistic right now
about the situation with the effect of the Crypto Wars combined with
the dominance of Chinese mining plus China's development of new laws
that seem to involve further attempts to backdoor hardware and / or
software.  Obviously this doesn't break bitcoin for mathematical
reasons that everyone on this list is already familiar with I'm sure,
but it is concerning to me, and now I will /endrant

On 08/02/2015 02:02 PM, Jim Phillips via bitcoin-dev wrote:
> China is a communist country. It is no secret that all
> "capitalist" enterprises are essentially State controlled, or at
> the very least are subject to nationalization should the State deem
> it necessary. Most ASIC chips are manufactured in China, so they
> are cheap and accessible to Chinese miners. Electricity is
> subsidized and essentially free. Cooling is not an issue since
> large parts of China are mountainous and naturally cool. In short
> the Chinese miners have HUGE advantages over all other mining
> operations. This is probably why, between just the top 4 Chinese 
> miners, the People's Republic of China effectively controls 57% of
> all the Bitcoin being mined.
> 
> The ONLY disadvantage the Chinese miners have in competing with the
> rest of the world is bandwidth. China has poor connectivity with
> the rest of the world, and Chinese miners have said that an
> increase in the block size would be detrimental to them. I say,
> GOOD! Most of the free world has enough bandwidth to be able to
> handle larger blocks. We need to take advantage of that fact to get
> mining out of the centralized control of the Chinese.
> 
> If you're truly worried about larger blocks causing
> centralization, think about how, by restricting blocksize, you're
> enabling the Communist Chinese government to maintain centralized
> control over 57% of the Bitcoin hashing power.
> 
> -- *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe> /"Don't bunt. Aim out of the
> ball park. Aim for the company of immortals." -- David Ogilvy /
> 
> /This message was created with 100% recycled electrons. Please
> think twice before printing./
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists•linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVvtxQAAoJEGxwq/inSG8CkVEIAJu9XsUzF4CKFD6xF3yofZ6R
l2KcYjX1UegUi5mYAv8BLJVd5ZbRrUfjoIR6dbjMu2q4bYADCt57ZXx7zV8bdHQT
Si9puYe3BboeeKJceS1jU5rkQbXrh/T4owqVMf8VAhDHQHVUVtSEvvx9gmxjFhze
zz/aeWtCKH44EJB8/PqO3nN6iOIhq7QoKmiqqO1HL6lMXNTck8wq07UmhXziGK2F
/5kX/uDM2BlAQs2E1IMeWe9GUJhHOQEqLfUPopfCTS7uTDt8FERWvobe5kPSV/vp
RNmQ5ojhQl7qWIq/I7zmtzDJNNi16PsKxFFl358bXAPzw4bq7ymzniVLqo4C5LE=
=eKYy
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  1:21 ` Pindar Wong
@ 2015-08-03  4:33   ` Jim Phillips
  0 siblings, 0 replies; 19+ messages in thread
From: Jim Phillips @ 2015-08-03  4:33 UTC (permalink / raw)
  To: Pindar Wong; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 4050 bytes --]

I realize that my argument may have come across as anti-Chinese, but I can
assure you that my concerns are not nationalist or racist in nature, so I
apologize if they came across as such. I was raised under another
oppressive regime, the US government, so I am sympathetic to the problems
of the Chinese people.

I am in fact only concerned with the very real fact that a majority of the
Bitcoin network's hashing power is centralized within the political borders
of one country and consequently the entire Bitcoin economy is at risk of
political manipulation. I have seen frequent instances within my own
homeland where the government has seized control over private businesses
through draconian regulation. I have witnessed in other countries where
businesses are seized and nationalized more directly. I am concerned that
the Chinese government might decide to nationalize the Bitcoin mines within
its borders, and what they might do with 57% of the network hashing power.

If it were any other country I would be equally concerned. But it's not any
other country. It's China. And I don't trust the Chinese government any
more than I trust any other government not to take actions that might harm
Bitcoin.
On Aug 2, 2015 8:21 PM, "Pindar Wong" <pindar.wong@gmail•com> wrote:

> Dear Jim,
>
> Thank you for sharing your view w.r.t. the so called 'Chinese Miners'.
>
> Diversity of opinion, and mining, are IMHO both good and it's indeed a
> free world.... so others who wish to mine bitcoin should be encouraged  to
> make the capital and technical investments to do so.
>
> May I ask what is your technical suggestion to move this discussion
> forward beyond your anti-Chinese/anti-China rhetoric?   e.g. I would be
> particularly grateful if you could share your  views w.r.t. colluding miner
> attacks in draft 0.5.9. of Joseph Poon and Thaddeus Dryja's 'Lightning
> network' paper, found here:-
>
> http://lightning.network/lightning-network-paper.pdf
>
> Respectfully,
>
> p.
>
>
>
> On Mon, Aug 3, 2015 at 4:02 AM, Jim Phillips via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> China is a communist country. It is no secret that all "capitalist"
>> enterprises are essentially State controlled, or at the very least are
>> subject to nationalization should the State deem it necessary. Most ASIC
>> chips are manufactured in China, so they are cheap and accessible to
>> Chinese miners. Electricity is subsidized and essentially free. Cooling is
>> not an issue since large parts of China are mountainous and naturally cool.
>> In short the Chinese miners have HUGE advantages over all other mining
>> operations. This is probably why, between just the top 4 Chinese miners,
>> the People's Republic of China effectively controls 57% of all the Bitcoin
>> being mined.
>>
>> The ONLY disadvantage the Chinese miners have in competing with the rest
>> of the world is bandwidth. China has poor connectivity with the rest of the
>> world, and Chinese miners have said that an increase in the block size
>> would be detrimental to them. I say, GOOD! Most of the free world has
>> enough bandwidth to be able to handle larger blocks. We need to take
>> advantage of that fact to get mining out of the centralized control of the
>> Chinese.
>>
>> If you're truly worried about larger blocks causing centralization, think
>> about how, by restricting blocksize, you're enabling the Communist Chinese
>> government to maintain centralized control over 57% of the Bitcoin hashing
>> power.
>>
>> --
>> *James G. Phillips IV*
>> <https://plus.google.com/u/0/113107039501292625391/posts>
>> <http://www.linkedin.com/in/ergophobe>
>>
>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>> immortals." -- David Ogilvy*
>>
>>  *This message was created with 100% recycled electrons. Please think
>> twice before printing.*
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 5622 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-02 21:02 [bitcoin-dev] A reason we can all agree on to increase block size Jim Phillips
  2015-08-03  1:21 ` Pindar Wong
  2015-08-03  3:13 ` odinn
@ 2015-08-03  6:34 ` Adam Back
  2015-08-03  6:53   ` Jim Phillips
                     ` (2 more replies)
  2 siblings, 3 replies; 19+ messages in thread
From: Adam Back @ 2015-08-03  6:34 UTC (permalink / raw)
  To: Jim Phillips; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2535 bytes --]

If block-sizes are increased in a way detrimental to the Chinese miners, it
is not the Chinese miners that lose, it is all of the non-Chinese miners -
this is because the Chinese miners have the slight majority of the
hashrate.  The relatively low external bandwidth connecting China to the
net is actually the problem of the non-Chinese miners problem.  Non Chinese
miners will experience higher orphan rate once Chinese miners cease to
build on top of blocks that are too large to sync in a timely fashion into
China.

Adam

On 2 August 2015 at 23:02, Jim Phillips via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> China is a communist country. It is no secret that all "capitalist"
> enterprises are essentially State controlled, or at the very least are
> subject to nationalization should the State deem it necessary. Most ASIC
> chips are manufactured in China, so they are cheap and accessible to
> Chinese miners. Electricity is subsidized and essentially free. Cooling is
> not an issue since large parts of China are mountainous and naturally cool.
> In short the Chinese miners have HUGE advantages over all other mining
> operations. This is probably why, between just the top 4 Chinese miners,
> the People's Republic of China effectively controls 57% of all the Bitcoin
> being mined.
>
> The ONLY disadvantage the Chinese miners have in competing with the rest
> of the world is bandwidth. China has poor connectivity with the rest of the
> world, and Chinese miners have said that an increase in the block size
> would be detrimental to them. I say, GOOD! Most of the free world has
> enough bandwidth to be able to handle larger blocks. We need to take
> advantage of that fact to get mining out of the centralized control of the
> Chinese.
>
> If you're truly worried about larger blocks causing centralization, think
> about how, by restricting blocksize, you're enabling the Communist Chinese
> government to maintain centralized control over 57% of the Bitcoin hashing
> power.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
> <http://www.linkedin.com/in/ergophobe>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
>  *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 3683 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  6:34 ` Adam Back
@ 2015-08-03  6:53   ` Jim Phillips
  2015-08-04 10:53     ` Jorge Timón
  2015-08-03  7:16   ` Simon Liu
  2015-08-03 13:57   ` Michael Ruddy
  2 siblings, 1 reply; 19+ messages in thread
From: Jim Phillips @ 2015-08-03  6:53 UTC (permalink / raw)
  To: Adam Back; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]

Yes I've had a couple other people point that out to me as well and the
logic is sound. Unfortunately that doesn't help solve the actual issue that
mining is currently consolidated within the jurisdiction of a single
political body that is not exactly Bitcoin friendly. I don't know how to
solve that issue aside from pointing it out and hoping miners outside of
China point to different pools and build more farms in smaller countries.
Venezuela for example has cheap electricity and could be a good place to
mine. Iceland too.
On Aug 3, 2015 1:34 AM, "Adam Back" <adam@cypherspace•org> wrote:

> If block-sizes are increased in a way detrimental to the Chinese miners,
> it is not the Chinese miners that lose, it is all of the non-Chinese miners
> - this is because the Chinese miners have the slight majority of the
> hashrate.  The relatively low external bandwidth connecting China to the
> net is actually the problem of the non-Chinese miners problem.  Non Chinese
> miners will experience higher orphan rate once Chinese miners cease to
> build on top of blocks that are too large to sync in a timely fashion into
> China.
>
> Adam
>
> On 2 August 2015 at 23:02, Jim Phillips via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> China is a communist country. It is no secret that all "capitalist"
>> enterprises are essentially State controlled, or at the very least are
>> subject to nationalization should the State deem it necessary. Most ASIC
>> chips are manufactured in China, so they are cheap and accessible to
>> Chinese miners. Electricity is subsidized and essentially free. Cooling is
>> not an issue since large parts of China are mountainous and naturally cool.
>> In short the Chinese miners have HUGE advantages over all other mining
>> operations. This is probably why, between just the top 4 Chinese miners,
>> the People's Republic of China effectively controls 57% of all the Bitcoin
>> being mined.
>>
>> The ONLY disadvantage the Chinese miners have in competing with the rest
>> of the world is bandwidth. China has poor connectivity with the rest of the
>> world, and Chinese miners have said that an increase in the block size
>> would be detrimental to them. I say, GOOD! Most of the free world has
>> enough bandwidth to be able to handle larger blocks. We need to take
>> advantage of that fact to get mining out of the centralized control of the
>> Chinese.
>>
>> If you're truly worried about larger blocks causing centralization, think
>> about how, by restricting blocksize, you're enabling the Communist Chinese
>> government to maintain centralized control over 57% of the Bitcoin hashing
>> power.
>>
>> --
>> *James G. Phillips IV*
>> <https://plus.google.com/u/0/113107039501292625391/posts>
>> <http://www.linkedin.com/in/ergophobe>
>>
>> *"Don't bunt. Aim out of the ball park. Aim for the company of
>> immortals." -- David Ogilvy*
>>
>>  *This message was created with 100% recycled electrons. Please think
>> twice before printing.*
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4553 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  6:34 ` Adam Back
  2015-08-03  6:53   ` Jim Phillips
@ 2015-08-03  7:16   ` Simon Liu
  2015-08-03  7:34     ` Hector Chu
  2015-08-03  7:46     ` Adam Back
  2015-08-03 13:57   ` Michael Ruddy
  2 siblings, 2 replies; 19+ messages in thread
From: Simon Liu @ 2015-08-03  7:16 UTC (permalink / raw)
  To: Adam Back, Jim Phillips; +Cc: Bitcoin Dev

Increasing the block size shouldn't be a problem for Chinese miners.
Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
already signed a draft agreement indicating they are fine with an
increase to 8 MB: http://www.8btc.com/blocksize-increase-2

With regards to China's international bandwidth, not only is intra-Asia
capacity improving all the time, a major consortium cable FASTER is
coming online Q2 2016.  Backed by Google, China Telecom and others, it
has a capacity of 60 Tbps, making it the highest-capacity data link ever
created across the Pacific.

Interactive map: http://www.submarinecablemap.com/

FASTER: https://plus.google.com/+UrsH%C3%B6lzle/posts/haJzDXnp9Z4

--Simon

On 08/02/2015 11:34 PM, Adam Back via bitcoin-dev wrote:
> If block-sizes are increased in a way detrimental to the Chinese miners,
> it is not the Chinese miners that lose, it is all of the non-Chinese
> miners - this is because the Chinese miners have the slight majority of
> the hashrate.  The relatively low external bandwidth connecting China to
> the net is actually the problem of the non-Chinese miners problem.  Non
> Chinese miners will experience higher orphan rate once Chinese miners
> cease to build on top of blocks that are too large to sync in a timely
> fashion into China.
> 
> Adam
> 
> On 2 August 2015 at 23:02, Jim Phillips via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
> 
>     China is a communist country. It is no secret that all "capitalist"
>     enterprises are essentially State controlled, or at the very least
>     are subject to nationalization should the State deem it necessary.
>     Most ASIC chips are manufactured in China, so they are cheap and
>     accessible to Chinese miners. Electricity is subsidized and
>     essentially free. Cooling is not an issue since large parts of China
>     are mountainous and naturally cool. In short the Chinese miners have
>     HUGE advantages over all other mining operations. This is probably
>     why, between just the top 4 Chinese miners, the People's Republic of
>     China effectively controls 57% of all the Bitcoin being mined.
> 
>     The ONLY disadvantage the Chinese miners have in competing with the
>     rest of the world is bandwidth. China has poor connectivity with the
>     rest of the world, and Chinese miners have said that an increase in
>     the block size would be detrimental to them. I say, GOOD! Most of
>     the free world has enough bandwidth to be able to handle larger
>     blocks. We need to take advantage of that fact to get mining out of
>     the centralized control of the Chinese.
> 
>     If you're truly worried about larger blocks causing centralization,
>     think about how, by restricting blocksize, you're enabling the
>     Communist Chinese government to maintain centralized control over
>     57% of the Bitcoin hashing power.
> 
>     --
>     *James G. Phillips
>     IV* <https://plus.google.com/u/0/113107039501292625391/posts> <http://www.linkedin.com/in/ergophobe>
>     /"Don't bunt. Aim out of the ball park. Aim for the company of
>     immortals." -- David Ogilvy
>     /
> 
>      /This message was created with 100% recycled electrons. Please
>     think twice before printing./
> 
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists•linuxfoundation.org
>     <mailto:bitcoin-dev@lists•linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> 
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  7:16   ` Simon Liu
@ 2015-08-03  7:34     ` Hector Chu
  2015-08-03  7:53       ` Adam Back
  2015-08-03  7:46     ` Adam Back
  1 sibling, 1 reply; 19+ messages in thread
From: Hector Chu @ 2015-08-03  7:34 UTC (permalink / raw)
  To: Simon Liu; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On 3 August 2015 at 08:16, Simon Liu via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> Increasing the block size shouldn't be a problem for Chinese miners.
> Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
> already signed a draft agreement indicating they are fine with an
> increase to 8 MB: http://www.8btc.com/blocksize-increase-2


What's the current stance of the Chinese pools on Bitcoin XT, should
Bitcoin Core refuse to increase the block size to 8 MB in a timely fashion?
Would they run it if the economic majority (e.g. Coinbase, Bitpay, etc.)
publicly stated their support for big blocks?

[-- Attachment #2: Type: text/html, Size: 1066 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  7:16   ` Simon Liu
  2015-08-03  7:34     ` Hector Chu
@ 2015-08-03  7:46     ` Adam Back
  1 sibling, 0 replies; 19+ messages in thread
From: Adam Back @ 2015-08-03  7:46 UTC (permalink / raw)
  To: Simon Liu; +Cc: Bitcoin Dev

On 3 August 2015 at 09:16, Simon Liu <simon@bitcartel•com> wrote:
> Increasing the block size shouldn't be a problem for Chinese miners.
> Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
> already signed a draft agreement indicating they are fine with an
> increase to 8 MB: http://www.8btc.com/blocksize-increase-2

There are two problems with this statement.  Firstly we can not be doing
protocol design via political lobbying - this is not a scientific approach
and for sure leads to disaster; it is not the colour of the paint on the box,
it is the security of the system.

Secondly as I understand it the Chinese miners did this under duress
of threats of worse as a compromise beyond what they felt they could safely
cope with.

> With regards to China's international bandwidth, not only is intra-Asia
> capacity improving all the time, a major consortium cable FASTER is
> coming online Q2 2016.

That is good news.

Aadm


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  7:34     ` Hector Chu
@ 2015-08-03  7:53       ` Adam Back
  2015-08-03  8:06         ` Hector Chu
  0 siblings, 1 reply; 19+ messages in thread
From: Adam Back @ 2015-08-03  7:53 UTC (permalink / raw)
  To: Hector Chu; +Cc: Bitcoin Dev

Again this should not be a political or business compromise model - we
must focus on scientific evaluation, technical requirements and
security.

But specifically as you asked a group of Chinese miners said they
would not run it:

http://cointelegraph.com/news/114657/chinese-mining-pools-call-for-consensus-refuse-switch-to-bitcoin-xt

Imagine if we had a nuclear reactor design criteria - we would not be
asking around with companies what parameter would they compromise on.
We'd be looking to scientific analysis of what is safe, based on
empirical and theoretical work on safety.  If we're risking $4b of
other peoples money (and a little bit of mine) I would strongly want a
scientific approach.

A closer analogy would be the NIST SHA3 design process.  With crypto
building blocks it is a security / speed tradeoff, a little analogous
to the security / throughput trade off in Bitcoin.

They do not ask companies or governments which algorithm they like or
what parameter they'd compromise on.  They have a design competition
and analyse the algorithms and parameters for security margin and
speed optimisation in hardware and software.  Much effort is put in
and it is very rigorous because a lot is at stake if they get it
wrong.

Adam

On 3 August 2015 at 09:34, Hector Chu <hectorchu@gmail•com> wrote:
> On 3 August 2015 at 08:16, Simon Liu via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Increasing the block size shouldn't be a problem for Chinese miners.
>> Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
>> already signed a draft agreement indicating they are fine with an
>> increase to 8 MB: http://www.8btc.com/blocksize-increase-2
>
>
> What's the current stance of the Chinese pools on Bitcoin XT, should Bitcoin
> Core refuse to increase the block size to 8 MB in a timely fashion? Would
> they run it if the economic majority (e.g. Coinbase, Bitpay, etc.) publicly
> stated their support for big blocks?


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  7:53       ` Adam Back
@ 2015-08-03  8:06         ` Hector Chu
  2015-08-03  8:20           ` Eric Lombrozo
  0 siblings, 1 reply; 19+ messages in thread
From: Hector Chu @ 2015-08-03  8:06 UTC (permalink / raw)
  To: Adam Back; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]

On 3 August 2015 at 08:53, Adam Back <adam@cypherspace•org> wrote:

> Again this should not be a political or business compromise model - we
> must focus on scientific evaluation, technical requirements and
> security.
>

I will assert that the block size is political because it affects nearly
all users to some degree and not all those users are technically inclined
or care to keep decentralisation in the current configuration as you do.
This debate has forgotten the current and future users of Bitcoin. Most of
them think the hit to node count in the short term preferable to making it
expensive and competitive to transact.

We all need a little faith that the system will reorganise and readjust
after the move to big blocks in a way that still has a reasonable degree of
decentralisation and trustlessness. The incentives of Bitcoin remain, so
everyone's decentralised decision throughout the system, from miners,
merchants and users, will continue to act according to those incentives.

[-- Attachment #2: Type: text/html, Size: 1371 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  8:06         ` Hector Chu
@ 2015-08-03  8:20           ` Eric Lombrozo
  2015-08-03  8:31             ` Hector Chu
  0 siblings, 1 reply; 19+ messages in thread
From: Eric Lombrozo @ 2015-08-03  8:20 UTC (permalink / raw)
  To: Hector Chu; +Cc: Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 2476 bytes --]

There have already been two notable incidents requiring manual intervention and good-faith cooperation between core devs and mining pool operators that would have either never gotten resolved alone or would have ended up costing a lot of people a lot of money had no action been taken (March 2013 and July 2015). They were both caused by consensus disagreement that directly or indirectly were brought about by bigger blocks. There is *strong* evidence…and a great deal of theory explaining it…that links larger blocks with the propensity for consensus forks that require manual intervention.

Please, can we stop saying this is merely about decentralization and trustlessness? The very model upon which the security of the system is based *broke*…as in, we were only able to recover because a few individuals deliberately manipulated the consensus rules to fix it manually. Shouldn’t we more highly prioritize fixing the issues that can lead to these incidents than trying to increase throughput? Increasing block size cannot possibly make these forking tendencies better…but it very well could make them worse.

- Eric

> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace•org <mailto:adam@cypherspace•org>> wrote:
> Again this should not be a political or business compromise model - we
> must focus on scientific evaluation, technical requirements and
> security.
> 
> I will assert that the block size is political because it affects nearly all users to some degree and not all those users are technically inclined or care to keep decentralisation in the current configuration as you do. This debate has forgotten the current and future users of Bitcoin. Most of them think the hit to node count in the short term preferable to making it expensive and competitive to transact.
> 
> We all need a little faith that the system will reorganise and readjust after the move to big blocks in a way that still has a reasonable degree of decentralisation and trustlessness. The incentives of Bitcoin remain, so everyone's decentralised decision throughout the system, from miners, merchants and users, will continue to act according to those incentives.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2: Type: text/html, Size: 3545 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  8:20           ` Eric Lombrozo
@ 2015-08-03  8:31             ` Hector Chu
  2015-08-03  8:38               ` Eric Lombrozo
  0 siblings, 1 reply; 19+ messages in thread
From: Hector Chu @ 2015-08-03  8:31 UTC (permalink / raw)
  To: Eric Lombrozo; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

What's wrong with a little cooperation to resolve things now and then? Man
is not an island unto himself, we compete with each other and we cooperate
with each other occasionally if it's mutually beneficial.

You said yourself that a lot of money would have been lost if the two hard
forks cited weren't resolved - that's the correct incentives at work again.

On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail•com> wrote:

> There have already been two notable incidents requiring manual
> intervention and good-faith cooperation between core devs and mining pool
> operators that would have either never gotten resolved alone or would have
> ended up costing a lot of people a lot of money had no action been taken
> (March 2013 and July 2015). They were both caused by consensus disagreement
> that directly or indirectly were brought about by bigger blocks. There is
> *strong* evidence…and a great deal of theory explaining it…that links
> larger blocks with the propensity for consensus forks that require manual
> intervention.
>
> Please, can we stop saying this is merely about decentralization and
> trustlessness? The very model upon which the security of the system is
> based *broke*…as in, we were only able to recover because a few individuals
> deliberately manipulated the consensus rules to fix it manually. Shouldn’t
> we more highly prioritize fixing the issues that can lead to these
> incidents than trying to increase throughput? Increasing block size cannot
> possibly make these forking tendencies better…but it very well could make
> them worse.
>
> - Eric
>
> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace•org> wrote:
>
>> Again this should not be a political or business compromise model - we
>> must focus on scientific evaluation, technical requirements and
>> security.
>>
>
> I will assert that the block size is political because it affects nearly
> all users to some degree and not all those users are technically inclined
> or care to keep decentralisation in the current configuration as you do.
> This debate has forgotten the current and future users of Bitcoin. Most of
> them think the hit to node count in the short term preferable to making it
> expensive and competitive to transact.
>
> We all need a little faith that the system will reorganise and readjust
> after the move to big blocks in a way that still has a reasonable degree of
> decentralisation and trustlessness. The incentives of Bitcoin remain, so
> everyone's decentralised decision throughout the system, from miners,
> merchants and users, will continue to act according to those incentives.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

[-- Attachment #2: Type: text/html, Size: 4129 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  8:31             ` Hector Chu
@ 2015-08-03  8:38               ` Eric Lombrozo
  2015-08-03  8:52                 ` Hector Chu
  0 siblings, 1 reply; 19+ messages in thread
From: Eric Lombrozo @ 2015-08-03  8:38 UTC (permalink / raw)
  To: Hector Chu; +Cc: Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 4415 bytes --]

Bah, I don’t know if you’re just trolling me, Hector…but I’ll give you the benefit of the doubt and act like you aren’t.

We already have much more efficient, far more scalable systems that allow this kind of cooperation you speak of without the inconveniences of blockchains and such. These incidents do, fortunately, present some of the better sides of humanity…but…the design of the network *broke* - and for reasons that are now well understood to be only worsened by larger blocks. These incidents are *not supposed to happen* - and if they do, it means we’ve botched something up and need to fix it. And by fix it, I mean fix the protocol so that given our best understanding of things in the present we can significantly reduce the potential for its occurrence in the future.

The correct incentives here were not due to people potentially losing a lot of money. The incentives here were well-intentioned altruism. Some miners lost money as a result of these actions…and they didn’t put up a fight. if you want to design a system around the assumption that this is how all such incidents will be resolved, please don’t spoil this for the rest of us.

- Eric

> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail•com> wrote:
> 
> What's wrong with a little cooperation to resolve things now and then? Man is not an island unto himself, we compete with each other and we cooperate with each other occasionally if it's mutually beneficial.
> 
> You said yourself that a lot of money would have been lost if the two hard forks cited weren't resolved - that's the correct incentives at work again.
> 
> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail•com>> wrote:
> There have already been two notable incidents requiring manual intervention and good-faith cooperation between core devs and mining pool operators that would have either never gotten resolved alone or would have ended up costing a lot of people a lot of money had no action been taken (March 2013 and July 2015). They were both caused by consensus disagreement that directly or indirectly were brought about by bigger blocks. There is *strong* evidence…and a great deal of theory explaining it…that links larger blocks with the propensity for consensus forks that require manual intervention.
> 
> Please, can we stop saying this is merely about decentralization and trustlessness? The very model upon which the security of the system is based *broke*…as in, we were only able to recover because a few individuals deliberately manipulated the consensus rules to fix it manually. Shouldn’t we more highly prioritize fixing the issues that can lead to these incidents than trying to increase throughput? Increasing block size cannot possibly make these forking tendencies better…but it very well could make them worse.
> 
> - Eric
> 
>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>> 
>> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace•org <mailto:adam@cypherspace•org>> wrote:
>> Again this should not be a political or business compromise model - we
>> must focus on scientific evaluation, technical requirements and
>> security.
>> 
>> I will assert that the block size is political because it affects nearly all users to some degree and not all those users are technically inclined or care to keep decentralisation in the current configuration as you do. This debate has forgotten the current and future users of Bitcoin. Most of them think the hit to node count in the short term preferable to making it expensive and competitive to transact.
>> 
>> We all need a little faith that the system will reorganise and readjust after the move to big blocks in a way that still has a reasonable degree of decentralisation and trustlessness. The incentives of Bitcoin remain, so everyone's decentralised decision throughout the system, from miners, merchants and users, will continue to act according to those incentives.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 6358 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  8:38               ` Eric Lombrozo
@ 2015-08-03  8:52                 ` Hector Chu
  2015-08-03  9:01                   ` Eric Lombrozo
  0 siblings, 1 reply; 19+ messages in thread
From: Hector Chu @ 2015-08-03  8:52 UTC (permalink / raw)
  To: Eric Lombrozo; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 4979 bytes --]

On 3 August 2015 at 09:38, Eric Lombrozo <elombrozo@gmail•com> wrote:

> We already have much more efficient, far more scalable systems that allow
> this kind of cooperation you speak of without the inconveniences of
> blockchains and such.
>

There is a degree of difference between cooperation in day-to-day usage of
the system and cooperation in the rare cases the system has a bug.

These incidents do, fortunately, present some of the better sides of
> humanity…but…the design of the network *broke* - and for reasons that are
> now well understood to be only worsened by larger blocks. These incidents
> are *not supposed to happen* - and if they do, it means we’ve botched
> something up and need to fix it. And by fix it, I mean fix the protocol so
> that given our best understanding of things in the present we can
> significantly reduce the potential for its occurrence in the future.
>

Distribution by consensus is inherently a fragile system. The network will
continue to break again and again as long as programmers are fallible. But
the types of bugs that occur will change over time as we learn the best
practices for maintaining the system.

The correct incentives here were not due to people potentially losing a lot
> of money. The incentives here were well-intentioned altruism. Some miners
> lost money as a result of these actions…and they didn’t put up a fight. if
> you want to design a system around the assumption that this is how all such
> incidents will be resolved, please don’t spoil this for the rest of us.
>

Altruism is a facade that hides other motivations. The party cooperating
with the miners losing money were doing so to maintain good relationships
with those miners and to make sure those miners stay within the system and
not attack it.


>
> - Eric
>
> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail•com> wrote:
>
> What's wrong with a little cooperation to resolve things now and then? Man
> is not an island unto himself, we compete with each other and we cooperate
> with each other occasionally if it's mutually beneficial.
>
> You said yourself that a lot of money would have been lost if the two hard
> forks cited weren't resolved - that's the correct incentives at work again.
>
> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>> There have already been two notable incidents requiring manual
>> intervention and good-faith cooperation between core devs and mining pool
>> operators that would have either never gotten resolved alone or would have
>> ended up costing a lot of people a lot of money had no action been taken
>> (March 2013 and July 2015). They were both caused by consensus disagreement
>> that directly or indirectly were brought about by bigger blocks. There is
>> *strong* evidence…and a great deal of theory explaining it…that links
>> larger blocks with the propensity for consensus forks that require manual
>> intervention.
>>
>> Please, can we stop saying this is merely about decentralization and
>> trustlessness? The very model upon which the security of the system is
>> based *broke*…as in, we were only able to recover because a few individuals
>> deliberately manipulated the consensus rules to fix it manually. Shouldn’t
>> we more highly prioritize fixing the issues that can lead to these
>> incidents than trying to increase throughput? Increasing block size cannot
>> possibly make these forking tendencies better…but it very well could make
>> them worse.
>>
>> - Eric
>>
>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace•org> wrote:
>>
>>> Again this should not be a political or business compromise model - we
>>> must focus on scientific evaluation, technical requirements and
>>> security.
>>>
>>
>> I will assert that the block size is political because it affects nearly
>> all users to some degree and not all those users are technically inclined
>> or care to keep decentralisation in the current configuration as you do.
>> This debate has forgotten the current and future users of Bitcoin. Most of
>> them think the hit to node count in the short term preferable to making it
>> expensive and competitive to transact.
>>
>> We all need a little faith that the system will reorganise and readjust
>> after the move to big blocks in a way that still has a reasonable degree of
>> decentralisation and trustlessness. The incentives of Bitcoin remain, so
>> everyone's decentralised decision throughout the system, from miners,
>> merchants and users, will continue to act according to those incentives.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7144 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  8:52                 ` Hector Chu
@ 2015-08-03  9:01                   ` Eric Lombrozo
  2015-08-03  9:22                     ` Hector Chu
  0 siblings, 1 reply; 19+ messages in thread
From: Eric Lombrozo @ 2015-08-03  9:01 UTC (permalink / raw)
  To: Hector Chu; +Cc: Bitcoin Dev


[-- Attachment #1.1: Type: text/plain, Size: 6496 bytes --]


> On Aug 3, 2015, at 1:52 AM, Hector Chu <hectorchu@gmail•com> wrote:
> 
> On 3 August 2015 at 09:38, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail•com>> wrote:
> We already have much more efficient, far more scalable systems that allow this kind of cooperation you speak of without the inconveniences of blockchains and such.
> 
> There is a degree of difference between cooperation in day-to-day usage of the system and cooperation in the rare cases the system has a bug.
> 

If it’s an as-of-yet unidentified issue that comes up, yes…obviously we can’t plan for everything and we’ll make some mistakes. But here we’re talking about specific well-known issues (or at least well-known today) for which several people have proposed potential solutions. However, these things have been all but ignored in the public discourse.

> These incidents do, fortunately, present some of the better sides of humanity…but…the design of the network *broke* - and for reasons that are now well understood to be only worsened by larger blocks. These incidents are *not supposed to happen* - and if they do, it means we’ve botched something up and need to fix it. And by fix it, I mean fix the protocol so that given our best understanding of things in the present we can significantly reduce the potential for its occurrence in the future.
> 
> Distribution by consensus is inherently a fragile system. The network will continue to break again and again as long as programmers are fallible. But the types of bugs that occur will change over time as we learn the best practices for maintaining the system.

I agree. But again, once we’ve identified specific issues, it is irresponsible to continue to pretend they don’t exist…and to more highly prioritize changes that can only make the problem worse.

Again, for the record, I am not against ultimately allowing bigger blocks. I think it would be a good thing to be able to do this…and my main concerns are not around things like equipment costs or typical household bandwidth. I just think security is a more important feature than greater throughput and prioritize it thusly.


> The correct incentives here were not due to people potentially losing a lot of money. The incentives here were well-intentioned altruism. Some miners lost money as a result of these actions…and they didn’t put up a fight. if you want to design a system around the assumption that this is how all such incidents will be resolved, please don’t spoil this for the rest of us.
> 
> Altruism is a facade that hides other motivations. The party cooperating with the miners losing money were doing so to maintain good relationships with those miners and to make sure those miners stay within the system and not attack it.

I don’t disagree…clearly even the miners that lost money believed that consensus was more valuable to them than a few bitcoins. However, it seems to be EXTREMELY dangerous to assume that it will always work out this way. What’s to stop a mining majority from deciding on-the-fly they want to keep a particular consensus rule that benefits them even if the core developers disagree?

> 
> - Eric
> 
>> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail•com <mailto:hectorchu@gmail•com>> wrote:
>> 
>> What's wrong with a little cooperation to resolve things now and then? Man is not an island unto himself, we compete with each other and we cooperate with each other occasionally if it's mutually beneficial.
>> 
>> You said yourself that a lot of money would have been lost if the two hard forks cited weren't resolved - that's the correct incentives at work again.
>> 
>> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail•com>> wrote:
>> There have already been two notable incidents requiring manual intervention and good-faith cooperation between core devs and mining pool operators that would have either never gotten resolved alone or would have ended up costing a lot of people a lot of money had no action been taken (March 2013 and July 2015). They were both caused by consensus disagreement that directly or indirectly were brought about by bigger blocks. There is *strong* evidence…and a great deal of theory explaining it…that links larger blocks with the propensity for consensus forks that require manual intervention.
>> 
>> Please, can we stop saying this is merely about decentralization and trustlessness? The very model upon which the security of the system is based *broke*…as in, we were only able to recover because a few individuals deliberately manipulated the consensus rules to fix it manually. Shouldn’t we more highly prioritize fixing the issues that can lead to these incidents than trying to increase throughput? Increasing block size cannot possibly make these forking tendencies better…but it very well could make them worse.
>> 
>> - Eric
>> 
>>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>>> 
>>> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace•org <mailto:adam@cypherspace•org>> wrote:
>>> Again this should not be a political or business compromise model - we
>>> must focus on scientific evaluation, technical requirements and
>>> security.
>>> 
>>> I will assert that the block size is political because it affects nearly all users to some degree and not all those users are technically inclined or care to keep decentralisation in the current configuration as you do. This debate has forgotten the current and future users of Bitcoin. Most of them think the hit to node count in the short term preferable to making it expensive and competitive to transact.
>>> 
>>> We all need a little faith that the system will reorganise and readjust after the move to big blocks in a way that still has a reasonable degree of decentralisation and trustlessness. The incentives of Bitcoin remain, so everyone's decentralised decision throughout the system, from miners, merchants and users, will continue to act according to those incentives.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>> 
>> 
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 10303 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  9:01                   ` Eric Lombrozo
@ 2015-08-03  9:22                     ` Hector Chu
  0 siblings, 0 replies; 19+ messages in thread
From: Hector Chu @ 2015-08-03  9:22 UTC (permalink / raw)
  To: Eric Lombrozo; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 5095 bytes --]

On 3 August 2015 at 10:01, Eric Lombrozo <elombrozo@gmail•com> wrote:

> I agree. But again, once we’ve identified specific issues, it is
> irresponsible to continue to pretend they don’t exist…and to more highly
> prioritize changes that can only make the problem worse.
>

> Again, for the record, I am not against ultimately allowing bigger blocks.
> I think it would be a good thing to be able to do this…and my main concerns
> are not around things like equipment costs or typical household bandwidth.
> I just think security is a more important feature than greater throughput
> and prioritize it thusly.
>

Security is an ongoing incremental process and everyone is giving it the
highest priority. Forgive me for being a bit behind on this - are you able
to point me to the potential solutions for the problems that were
identified from the unintentional hard forks?


> I don’t disagree…clearly even the miners that lost money believed that
> consensus was more valuable to them than a few bitcoins. However, it seems
> to be EXTREMELY dangerous to assume that it will always work out this way.
> What’s to stop a mining majority from deciding on-the-fly they want to keep
> a particular consensus rule that benefits them even if the core developers
> disagree?
>

The users of Bitcoin are living in a free world. Bitcoin like many
political systems requires the cooperation of the majority. If a majority
of miners decide to change the rules to benefit only themselves then the
system will quickly lead to collapse, until a new system arising from the
ashes of the previous one is erected.

In fact the situation is more optimistic than this. Miners don't set the
rules, the economic majority does. The miners must follow the rules that
are acceptable by the economic majority, or quickly go out of business.


>
>> - Eric
>>
>> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail•com> wrote:
>>
>> What's wrong with a little cooperation to resolve things now and then?
>> Man is not an island unto himself, we compete with each other and we
>> cooperate with each other occasionally if it's mutually beneficial.
>>
>> You said yourself that a lot of money would have been lost if the two
>> hard forks cited weren't resolved - that's the correct incentives at work
>> again.
>>
>> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>
>>> There have already been two notable incidents requiring manual
>>> intervention and good-faith cooperation between core devs and mining pool
>>> operators that would have either never gotten resolved alone or would have
>>> ended up costing a lot of people a lot of money had no action been taken
>>> (March 2013 and July 2015). They were both caused by consensus disagreement
>>> that directly or indirectly were brought about by bigger blocks. There is
>>> *strong* evidence…and a great deal of theory explaining it…that links
>>> larger blocks with the propensity for consensus forks that require manual
>>> intervention.
>>>
>>> Please, can we stop saying this is merely about decentralization and
>>> trustlessness? The very model upon which the security of the system is
>>> based *broke*…as in, we were only able to recover because a few individuals
>>> deliberately manipulated the consensus rules to fix it manually. Shouldn’t
>>> we more highly prioritize fixing the issues that can lead to these
>>> incidents than trying to increase throughput? Increasing block size cannot
>>> possibly make these forking tendencies better…but it very well could make
>>> them worse.
>>>
>>> - Eric
>>>
>>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
>>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace•org> wrote:
>>>
>>>> Again this should not be a political or business compromise model - we
>>>> must focus on scientific evaluation, technical requirements and
>>>> security.
>>>>
>>>
>>> I will assert that the block size is political because it affects nearly
>>> all users to some degree and not all those users are technically inclined
>>> or care to keep decentralisation in the current configuration as you do.
>>> This debate has forgotten the current and future users of Bitcoin. Most of
>>> them think the hit to node count in the short term preferable to making it
>>> expensive and competitive to transact.
>>>
>>> We all need a little faith that the system will reorganise and readjust
>>> after the move to big blocks in a way that still has a reasonable degree of
>>> decentralisation and trustlessness. The incentives of Bitcoin remain, so
>>> everyone's decentralised decision throughout the system, from miners,
>>> merchants and users, will continue to act according to those incentives.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7514 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  6:34 ` Adam Back
  2015-08-03  6:53   ` Jim Phillips
  2015-08-03  7:16   ` Simon Liu
@ 2015-08-03 13:57   ` Michael Ruddy
  2 siblings, 0 replies; 19+ messages in thread
From: Michael Ruddy @ 2015-08-03 13:57 UTC (permalink / raw)
  To: Adam Back; +Cc: Bitcoin Dev

Does that not sound like a useful check-and-balance? It does to me.

In a scenario where these network limitations and miner rate
distributions are the same to begin, and the block and transaction
size limits are raised or removed, your observation would seem to
indicate that blocks that are outstandingly large would not be mined
often or at all (due to orphan risk), until at least the network
limitations or rate distributions changed.

Such a scenario could shape up to be a non-event. Miner majority could
choose to not change their policy regarding effective block and
transaction sizes (which includes both the size of the blocks they
create and the size of the blocks that they choose to build upon). To
make it not a total non-event, then the miners might update their
policy to increase the effective sizes a measured amount. They
wouldn't want to go too far because of the risk of spooking the
economic majority, or because of their own technological limitations
(which I'm supposing would remain transport layer limitations).

To me, in absence of these transport layer limitations that have crept
up into the consensus rules layer (clear layer violations), it seems
that one thing that would otherwise naturally bound the upper and
lower limits of effective block and transaction size is the economic
majority feedback loop to miners. Get too far out of line and the
effect on usefulness, or properties of the system, will make people
react by lowering the purchasing power of the block rewards. For
example, attack other miners to drive more mining centralization, or
create blocks that are currently too big for people to validate/use,
and that feedback loop will start to direct negatively.

Why do miners not currently choose policy that favors smaller blocks
and transactions than they do? Laziness/indifference only explains so
much. I submit that they don't because if they make the system less
useful, then people will react by selling off coins and potentially
leaving the ecosystem (they might also just wait on the sidelines to
see if the system self-corrects). If the miners tested those waters,
and found out that they made a mistake, at least they would be free to
correct their actions (and quickly). Not all would be lost. Some value
could be (temporarily) lost. It could also be re-gained if the system
self-corrected.

To follow-up on the layer violation idea that I started on before, I
think a secondary, non-consensus rule layer, indication of what block
and transaction sizes are acceptable to the economic majority would be
found in the transport protocols that they use. For example, the
effective P2P protocol limit that is 2MB or 32MB (depending on version
of the Core client) would be one such indication. Doesn't anyone think
that separating the consensus layer rules from the transport layer
supporting it should be a goal?

On Mon, Aug 3, 2015 at 2:34 AM, Adam Back via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> If block-sizes are increased in a way detrimental to the Chinese miners, it
> is not the Chinese miners that lose, it is all of the non-Chinese miners -
> this is because the Chinese miners have the slight majority of the hashrate.
> The relatively low external bandwidth connecting China to the net is
> actually the problem of the non-Chinese miners problem.  Non Chinese miners
> will experience higher orphan rate once Chinese miners cease to build on top
> of blocks that are too large to sync in a timely fashion into China.
>
> Adam


^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [bitcoin-dev] A reason we can all agree on to increase block size
  2015-08-03  6:53   ` Jim Phillips
@ 2015-08-04 10:53     ` Jorge Timón
  0 siblings, 0 replies; 19+ messages in thread
From: Jorge Timón @ 2015-08-04 10:53 UTC (permalink / raw)
  To: Jim Phillips; +Cc: Bitcoin Dev

On Mon, Aug 3, 2015 at 8:53 AM, Jim Phillips via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Yes I've had a couple other people point that out to me as well and the logic is sound. Unfortunately that doesn't help solve the actual issue that mining is currently consolidated within the jurisdiction of a single political body that is not exactly Bitcoin friendly. I don't know how to solve that issue aside from pointing it out and hoping miners outside of China point to different pools and build more farms in smaller countries. Venezuela for example has cheap electricity and could be a good place to mine. Iceland too.

It's interesting how realizing that the blocksize consensus limit does
the opposite of what you initially thought when starting the thread
didn't changed your conclusion from

"If you're truly worried about larger blocks causing centralization,
think about how, by restricting blocksize, you're enabling the
Communist Chinese government to maintain centralized control over 57%
of the Bitcoin hashing power."

to

"If you're truly worried about larger blocks causing centralization,
think about how, by INCREASING blocksize, you're enabling the
Communist Chinese government to POTENTIALLY INCREASE ITS centralized
control over 57% of the Bitcoin hashing power."

The new conclusion is just "somebody should mine from Venezuela and
Iceland" instead.

If you were so concerned about mining centralization, now that you
understand how the blocksize maximum influences it (by being the only
consensus rule that limits it) and if you were consequent, now you
would warn about the dangers of increasing the blocksize consensus
limit in this particular moment in time when mining centralization
looks already really bad (ie 57% hashrate in the same jurisdiction).
Another possibility is that you don't really care about mining
centralization and you were only looking for an argument in favor of
increasing the blocksize, which for some other reason you have already
concluded that must be done as soon as possible.


^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2015-08-04 10:53 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-02 21:02 [bitcoin-dev] A reason we can all agree on to increase block size Jim Phillips
2015-08-03  1:21 ` Pindar Wong
2015-08-03  4:33   ` Jim Phillips
2015-08-03  3:13 ` odinn
2015-08-03  6:34 ` Adam Back
2015-08-03  6:53   ` Jim Phillips
2015-08-04 10:53     ` Jorge Timón
2015-08-03  7:16   ` Simon Liu
2015-08-03  7:34     ` Hector Chu
2015-08-03  7:53       ` Adam Back
2015-08-03  8:06         ` Hector Chu
2015-08-03  8:20           ` Eric Lombrozo
2015-08-03  8:31             ` Hector Chu
2015-08-03  8:38               ` Eric Lombrozo
2015-08-03  8:52                 ` Hector Chu
2015-08-03  9:01                   ` Eric Lombrozo
2015-08-03  9:22                     ` Hector Chu
2015-08-03  7:46     ` Adam Back
2015-08-03 13:57   ` Michael Ruddy

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox