* [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-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 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-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: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
* 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: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 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 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
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