CNBC: Bitcoin's 'war' could threaten its survivalBitcoin, the digital currency technology with an ecosystem attracting hundreds of millions of dollars in investment, is struggling through an existential crisis. And what may to outsiders seem like petty squabbling about a single number actually has major financial implications and could even threaten the very survival of the cryptocurrency. The argument—which is pitting Chinese constituencies against largely Western developers, the business community against the often ideological early adopters, and programmer against programmer—centers on a simple number in the global bitcoin system. But if the various parties can't come to an agreement, the whole network could splinter, wrecking its major selling points of security and decentralization. "There is literally a war going on right now in the bitcoin world," Marco Streng, CEO of Genesis Mining, told CNBC last month. What's the issue? There are two major questions facing the technology: Who is bitcoin for? And who gets to decide? Most of the early adopters saw appeal in bitcoin as a decentralized digital currency—(to over-simplify the promise) a sort of virtual gold that could not be touched by governments, banks or corporations. But in seeking to create the perfect system for such a currency, bitcoin's early creators also created a technology that has wide-ranging applications. That technology is called the "blockchain" (CNBC has gone in depth into how it works), and this is basically what it does: It can record any information in a secure way, and make that information both public and unchangeable—doing this without relying on any central authority. Banks, stock exchanges, payment companies and others have already begun exploring how this can be used in their own businesses. The issue at hand is about the structure of bitcoin's blockchain (which is composed of "blocks" of data with each block referring back to the preceding chunk of information—thereby creating a chain). The community is arguing about how big the maximum block size should be: The current max is one megabyte, which only allows for about seven transactions per second—far too few for most businesses currently investing in the technology. This speed is a "roadblock to bitcoin growth," Jeff Garzik, one of five bitcoin core developers who have taken over maintenance of the technology, wrote in a recent paper. (Visa, for comparison, says its network can handle more than 24,000 transactions per second.) "Any responsible business projecting capacity usage into the future sees the system reaching an absolute maximum capacity, with this speed limit in place," he wrote. "Increasing or removing this limit will encourage businesses to view bitcoin as scalable and capable of supporting millions of new users." ... http://www.cnbc.com/2015/07/23/bitcoins-war-could-threaten-its-survival.htmlJeffy G for president dictator. yes, i am glad Garzik recognizes the problem: "Any responsible business projecting capacity usage into the future sees the system reaching an absolute maximum capacity, with this speed limit in place," he wrote. "Increasing or removing this limit will encourage businesses to view bitcoin as scalable and capable of supporting millions of new users."
so i didn't see who was actual backing the "1MB blockers for now" in this "war" I saw these two fores as aligned not pitted gained each-other: " the business community against the often ideological early adopters" not to mention I was under the impression the largely Western Developers were alighted with the Chinese [mining] constituencies. I think the vast majority of the bitcoin ecosystem want bitcoin to scale in the safest manner possible. The '1mb blockers' seem to only have any sway in the argument because of the naturally conservative approach to changing things in Core. another way of saying that inertia is much easier to perpetuate with FUD. |
|
|
|
CNBC: Bitcoin's 'war' could threaten its survivalBitcoin, the digital currency technology with an ecosystem attracting hundreds of millions of dollars in investment, is struggling through an existential crisis. And what may to outsiders seem like petty squabbling about a single number actually has major financial implications and could even threaten the very survival of the cryptocurrency. The argument—which is pitting Chinese constituencies against largely Western developers, the business community against the often ideological early adopters, and programmer against programmer—centers on a simple number in the global bitcoin system. But if the various parties can't come to an agreement, the whole network could splinter, wrecking its major selling points of security and decentralization. "There is literally a war going on right now in the bitcoin world," Marco Streng, CEO of Genesis Mining, told CNBC last month. What's the issue? There are two major questions facing the technology: Who is bitcoin for? And who gets to decide? Most of the early adopters saw appeal in bitcoin as a decentralized digital currency—(to over-simplify the promise) a sort of virtual gold that could not be touched by governments, banks or corporations. But in seeking to create the perfect system for such a currency, bitcoin's early creators also created a technology that has wide-ranging applications. That technology is called the "blockchain" (CNBC has gone in depth into how it works), and this is basically what it does: It can record any information in a secure way, and make that information both public and unchangeable—doing this without relying on any central authority. Banks, stock exchanges, payment companies and others have already begun exploring how this can be used in their own businesses. The issue at hand is about the structure of bitcoin's blockchain (which is composed of "blocks" of data with each block referring back to the preceding chunk of information—thereby creating a chain). The community is arguing about how big the maximum block size should be: The current max is one megabyte, which only allows for about seven transactions per second—far too few for most businesses currently investing in the technology. This speed is a "roadblock to bitcoin growth," Jeff Garzik, one of five bitcoin core developers who have taken over maintenance of the technology, wrote in a recent paper. (Visa, for comparison, says its network can handle more than 24,000 transactions per second.) "Any responsible business projecting capacity usage into the future sees the system reaching an absolute maximum capacity, with this speed limit in place," he wrote. "Increasing or removing this limit will encourage businesses to view bitcoin as scalable and capable of supporting millions of new users." ... http://www.cnbc.com/2015/07/23/bitcoins-war-could-threaten-its-survival.htmlJeffy G for president dictator. yes, i am glad Garzik recognizes the problem: "Any responsible business projecting capacity usage into the future sees the system reaching an absolute maximum capacity, with this speed limit in place," he wrote. "Increasing or removing this limit will encourage businesses to view bitcoin as scalable and capable of supporting millions of new users."
|
|
|
|
|
oops, gold going negative again.
ah, that sweet smell of deflation.
|
|
|
|
iCE, didn't you say you own Hecla? geez man, you gotta get outta that thing. once it breaks the red support line, it's lights out:  |
|
|
|
BlockCypher on board with bigger blocks. their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack: Large mempools are awful
The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.
Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost
What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?
Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4Hmmm sorry but that's mischaracterizing the idea behind this article. They are in fact very neutral and make no mention of a preferred position on the matter. Seems clear the culprit in this whole saga of "network disruption" was misconfigured architecture and apparently inadequate mempool implementations. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.
Evidently the core parameters were not optimized, something they suggest the core devs should concentrate and focus on maybe even before we think about block size. (I am aware there is already progress made toward alleviating this problem) i heard a good argument the other day about this. assuming that there are 1.1MB worth of real tx demand, that means not everyone can fit their tx into the next block and at minimum means 0.1MB worth of tx's have to wait until the next 10 min block to get thru no matter what fee they pay. is Bitcoin a usable system at that point when some ppl may have to wait 20 min and even much longer if you start extrapolating out real use to say 100MB of real user demand? also assume these ppl want max security of transacting on the MC. Wouldn't a real 1.1MB transaction demand mean, that at some point fees would escalate an dsome people could not pay for their fee at all, thus locking them out of their own funds ? (Of course the demand will decrease when fees raise, but what happens if not ?) yes, that's the pt. it's unworkable for many. and not just the poor. i was annoyed the other day having to pay a 0.0002 tx fee to send to someone i did not want to get stuck in the backup of unconf tx's. but it would get much worse with 1.1MB of real demand plus a spam attack. |
|
|
|
remember that CVX chart i kept putting up? well, the entire index is now following it down:  world's largest mine:  mining capitol of the world:  Canada, no mining slouch:  cheap food. you'll need it:  |
|
|
|
$DJT deepening it's losses. $DJI getting dragged down:  |
|
|
|
BlockCypher on board with bigger blocks. their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack: Large mempools are awful
The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.
Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost
What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?
Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4Hmmm sorry but that's mischaracterizing the idea behind this article. They are in fact very neutral and make no mention of a preferred position on the matter. Seems clear the culprit in this whole saga of "network disruption" was misconfigured architecture and apparently inadequate mempool implementations. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.
Evidently the core parameters were not optimized, something they suggest the core devs should concentrate and focus on maybe even before we think about block size. (I am aware there is already progress made toward alleviating this problem) i heard a good argument the other day about this. assuming that there are 1.1MB worth of real tx demand, that means not everyone can fit their tx into the next block and at minimum means 0.1MB worth of tx's have to wait until the next 10 min block to get thru no matter what fee they pay. is Bitcoin a usable system at that point when some ppl may have to wait 20 min and even much longer if you start extrapolating out real use to say 100MB of real user demand? also assume these ppl want max security of transacting on the MC. |
|
|
|
mining centralization? what mining centralization?:  |
|
|
|
BlockCypher on board with bigger blocks. their analysis corresponds with everything i've been saying (& concepts elucidated by awemany) in this thread about the attack: Large mempools are awful
The truth is that “the” mempool is a misnomer; every miner and node has its own mempool, with different sizes, policies, and rules. Mix with a Bitcoin core implementation ill-equipped for massive mempools, and you get chaos and uncertainty. A large mempool stresses Bitcoin’s distributed infrastructure and greatly increases the possibility of user confusion when their transactions are randomly dropped.
Large mempools — relative to block size — are very bad.
Miners and nodes bore the cost
What most don’t realize is the attack was on the miners and nodes validating transactions. When a transaction has been received and validated by the network (but NOT INCLUDED in a block), the cost has already been incurred by the network in sending, validating, and relaying the transactions.
What Next?
Adapt. Upward fee pressure may be inevitable, but it’s important to note that this attack scales linearly with block size. If we had 8MB block size limits, for example, and assuming prior 1–2tps, then the attacker’s transactions would fill 7.5MB of extra transactions instead of 500KB, a full 15x more expensive, on the order of ~$60,000 a day. Still too cheap, but a higher price tag for a prospective malcontent.https://medium.com/blockcypher-blog/a-bitcoin-spam-attack-post-mortem-s-la-ying-alive-654e914edcf4 |
|
|
|
Satoshi clearly didn't have a plan to manage the core devs, or even a code of conduct as it seems. We need a Bitcoin-equivalent Hippocratic Oath for the core devs, as well as a way to tell them to buzz off. Maybe the Foundation can get to work on that.  They signed the Hippocratic Oath equivalent when they joined Blockstream - at least that is what was presented in the media, that they would never hurt bitcoin because of their work contracts. how effective do you expect them to be when they depend on self determination? how much does money & stock options affect their decision making? what does talking with your VC investors everyday do to one's view of the world? since bigger blocks is a no brainer even for SC's & LN, why the delay/stalling? and yeah, i asked these very questions a year ago well before the block size debate was a "thing". |
|
|
|
I wonder if the continuing GLD downtrend (with no near or medium-term end in sight) will spur some goldbugs to jump into BTC as they see it rise while their beloved PM falls. Could be one of the many contributing factors in the inevitable coming BULL run.
you mean this POS? well yeah, that's the whole thrust of this thread for 4y running...:  |
|
|
|
|
all of them have that sick top left to bottom right long term year chart...
|
|
|
|
Satoshi clearly didn't have a plan to manage the core devs, or even a code of conduct as it seems. We need a Bitcoin-equivalent Hippocratic Oath for the core devs, as well as a way to tell them to buzz off. Maybe the Foundation can get to work on that. They signed the Hippocratic Oath equivalent when they joined Blockstream - at least that is what was presented in the media, that they would never hurt bitcoin because of their work contracts. how effective do you expect them to be when they depend on self determination? how much does money & stock options affect their decision making? what does talking with your VC investors everyday do to one's view of the world? since bigger blocks is a no brainer even for SC's & LN, why the delay/stalling? |
|
|
|
$DJT doing the next roll:  |
|
|
|
LOL, the Gavinistas are furiously scribbling their little manifesto. This gonna be good.  Exactly like the Peoples' Front of Judea (or was it the Judean Peoples' Front?) "What have the core devs ever done for us?" I'm grateful to the developers, but this is not about them, I'm also happy that not everyone at central control is part of the heard, everything in this post is good news. if you read that tweet again, it looks like a critique of the mainstream circle jerk. Ah, but BitcoinSX is about the developers. Specifically, SX's lack of them and predictable GFY response from Team Core when larger blocks break something Gavin failed to account for (like upstream bandwidth being ~order-of-magnitude less than down, or catastrophic consensus failure). XT could be an interesting pseudo-test of the thought experiment i've made a coupla times about perhaps Bitcoin needing nothing more than a big enough block size increase with built in upgrades from now until eternity. or at least until an emergency patch is needed for an extraordinary event. |
|
|
|
|
Show Posts
