Gold collapsing. Bitcoin UP.

[freetrader]

I am fine with Core competing with other implementations based on the merits of technical and economic arguments (and hard work by those involved!).

If we can set aside ugly political debate then we are all one step ahead already.

BTW, @SysMan: I would be interested to know how recent developments in the node client landscape (increased proportion of > 1MB supporting nodes) changes the numbers in the whitepaper you presented. Surely quite a bit has changed since Sep 2015. But I must study your whitepaper more closely - it looks like solid analysis, which is to be respected.

 

[rocks]

So this is the person who has taken over as CEO of bitcoin

 

[VeritasSapere]

@SysMan Then we can agree that 2MB is safe, the improvements present in Core's 0.12 release are also present in both Classic and Unlimited. And as @Peter R said you can always increase the blocksize limit your self inside of your own client. It is the nature of open source software.

In regards to control, open source projects are by necessity types of dictatorships. The only way to democratize this control is through decentralization, further distributing development across several implementations. This is what gives people the freedom of choice, represented by the miners. We can use the software that Core develops but we do not necessarily need to follow the economic policy they dictate. This is about not allowing any development team to have excessive power over the development of Bitcoin.

 

[SysMan]

whoever ran the Bitfury account on BCT in 2013 is a genius. i used to follow his dev threads and they were remarkable. i, in fact, bought several of the first generation BF boards back then. @SysMan is right, Bitcoin is about POW and real work, ie, sweat labor. that's what helps prevent 51% attacks by state actors. but Bitcoin is also about understand economics and game theory, which is what alot of the current miners don't seem to have a good handle on. that's why we're in the mess we're in right now.

1st This Genius is still here and more new are joined
2nd - just by the way ... Miners has some education, even just mining DC operations require to have them, more deeper then just running single CPU/GPU.
3d - I btw, I don't know what about other miners, I can reply for myself - has 2 economical educations, fin risk management experience & enough good math/game theory background + analytical type of thinking.
P.s. I'm moderately frugal, has realistic view & I know my own strengths...
[doublepost=1457118296][/doublepost]

@SysMan If you are referring to block propagation times you might want to check out Xthin which increases block propagation speeds for mining by a factor of fifteen. This in itself justifies a blocksize increase if that is one of the main reasons for not increasing the blocksize limit for some people. Especially considering the economic advantages of doing so.

https://bitco.in/forum/threads/buip010-passed-xtreme-thinblocks.774/

Its not only about block propagation !
Its overall load in construction of bitcoind full node ! there are a lot of performance issues & locks.
you talking minin/ xthin - is only small part of this. you talking half-nodes/SPV nodes - its also not a solution!
more full nodes will be under heavy-load, less nodes we has - more risks about nodes consensus in bitcoin network will be.

nodes should be efficient and affordable for resources for wider users as possible. This meas open network principle.

 

[cypherdoc]

I'm realist - I listen carefully what other ppls are wrote/say...
there is couple of other aspects outside the technical level from "classic" what make me worry about.
/ block version(I know how it seriously impact the core code, and all version control ideology) and other tech issues looks like just brave small issues out of concept sometime, but that's almost ok/

If we talking just about pure block-size increase and the same offer about HF will be from CORE - then I'm almost 90% in, but I hate politics behind the classic scene, this - makes me worry about...
my IMHO classic is not about block-size changes, its looks more about control...

i don't think you've been around long enough to understand the mentality behind folks like gmax, lukejr, Todd, etc. i've observed these guys for years since 2011 and they, imo, are not doing what's right for Bitcoin's long term future. w/o that history, i'm sure you can't relate. and that history explains quite clearly why they'd organize a company around Blockstream to capitalize on their imagined deficiencies in how Bitcoin operates. i think it's corrupt as do many others and goes against Bitcoin being a cheap, accessible, revolutionary form of money that can be used by ppl the world over.
[doublepost=1457118802][/doublepost]

1st This Genius is still here and more new are joined
2nd - just by the way ... Miners has some education, even just mining DC operations require to have them, more deeper then just running single CPU/GPU.
3d - I btw, I don't know what about other miners, I can reply for myself - has 2 economical educations, fin risk management experience & enough good math/game theory background + analytical type of thinking.
P.s. I'm moderately frugal, has realistic view & I know my own strengths...
[doublepost=1457118296][/doublepost]
Its not only about block propagation !
Its overall load in construction of bitcoind full node ! there are a lot of performance issues & locks.
you talking minin/ xthin - is only small part of this. you talking half-nodes/SPV nodes - its also not a solution!
more full nodes will be under heavy-load, less nodes we has - more risks about nodes consensus in bitcoin network will be.

nodes should be efficient and affordable for resources for wider users as possible. This meas open network principle.

you small blockists have been complaining about the decrease in FN's for years now but have you seen the significant growth in FN's recently? you may try and write it off to the competition btwn code implementations but i also think there's a message there that FN's can be increased when and if necessary to respond to any given situation. in fact, i'd go as far to say that with bigger blks we get inc users, inc merchants, and inc FN's above and beyond what we have today.

 

[rocks]

@cypherblock
On top of all of this they have managed to both kick out all opposing early developers and successfully rewrite history claiming that they developed bitcoin. It is time to stop engaging with these people and take real steps to break away

 

[VeritasSapere]

@SysMan I can appreciate wanting to keep the minimum requirements for running a full node low, but surely there should be a lower bound that moves up as technology progresses.

I recall reading the paper you linked, I remember the power of the computer that was used in the testing was not that impressive, I do not recall the exact specifications. However with say an average desktop computer in the developed world as our lower bound with the improvements present in 0.12 it seems like we could easily increase the blocksize. Even if we do so very conservatively. However Core has still been very clear in their opposing vision of Bitcoin that it should not be scaled directly at all beyond segwit.

It's not about Core (team) vs Classic (team). That's a construction, similar when a politician says: My way or I step back. The truth is - it's about one single decision: scaling onchain vs. scaling not onchain.

 

[Aquent]

@SysMan you have to consider the risks of full blocks and the other risks. This isn't a black and white picture, that is, it isn't the case that one can say well 2mb or a hardfork is risky, so I'll just stick with 1mb. That is because 1mb or the segwit implementation of an increase has many risks. You need to consider the whole picture, you have to consider the tradeoffs, and come to a decision when considering all factors.

Segwit for example is not really aimed at increasing the blocksize. It is a full re-writing of some crucial parts of consensus code, with thousands of lines which necessarily contain bugs because we are humans, therefore should not in any way be rushed, lest it creates some crazy bug like bringing up 1 billion bitcoins out of thin air. Segwit is more focused on tx malleability and other features, with the blocksize beaing an afterthought. Rushing this work because of some blocksize can be existentially reckless in my view.

Now if you are fine with waiting you have to consider that full blocks mean people actually leave. People leaving means less profits for companies, so we have bankruptcy across the system, including perhaps bitpesa which relies on cheap money transfers, and that has huge risks.

So, don't just criticise one thing, asking for perfection. We humans, in an imperfect world. Sure, hardforks have risks, sure, we can't offer a perfect 100% safe upgrade, but the alternative has risks too and they can not offer anywhere near a 100% safe upgrade. Segwit's softfork can become a hardfork and many say it is actually a hardfork and if it is rushed it can have drastic consequences for the network and blocks are full right now, we have a media storm declaring that bitcoin is no longer usable.

You have to balance the tradeoffs and come to a decision on what is the best way forward, not just criticise looking for perfection, because the current path we are on is fully imperfect with huge costs for many use cases of bitcoin, for many bitcoin companies, for bitcoin users, and with high risks of an outright disaster.

 

[cypherdoc]

https://slushpool.com/news/2016/03/04/block-size-voting-feature/

[doublepost=1457119861][/doublepost]fyi, Alex Petrov @SysMan is "CIO Chief Informational Officer" of Bitfury.

 

[AdrianX]

The biggest reason to fork away from Blockstream/Core is to move Bitcoin away from this:

http://betakit.com/montreal-angel-austin-hill-failed-spectacularly-before-later-success/

I cringed when I read this: Austin Hill advertised “watch your favourite television shows and earn $400-$600 dollars a week watching TV. Send a self-addressed envelope with your favourite television shows listed below.” then knowing full well he was lying, at dinners he would mock the “hall-of-fame letters” who responded.

So proud to have people like this dictating Bitcoin policy. It's particularly ironic when you're asked to ignore the obvious conflict of interest with Blockstream's actions - an attempt to limiting bitcoin block transactions that directly creates a demand for their off chain for profit solution. and we're told to trust them and give them the benefit of the doubt.

It does not take much convincing that the Blockstream business plan is not one that appeals to investors with a high moral consciousness.

 

[Justus Ranvier]

my IMHO classic is not about block-size changes, its looks more about control...

That is exactly it.

Blocksteam/Core believes they should control Bitcoin. This must not be allowed, no only because it's dangerous, but because anyone who wants to control Bitcoin shouldn't by definition.

 

[SysMan]

@SysMan I can appreciate wanting to keep the minimum requirements for running a full node low, but surely there should be a lower bound that moves up as technology progresses.

I recall reading the paper you linked, I remember the power of the computer that was used in the testing was not that impressive, I do not recall the exact specifications. However with say an average desktop computer in the developed world as our lower bound with the improvements present in 0.12 it seems like we could easily increase the blocksize. Even if we do so very conservatively. However Core has still been very clear in their opposing vision of Bitcoin that it should not be scaled directly at all beyond segwit.

I perform full topology test using 50+ nodes, aprox year ago.
test in virtual environment simulating linux qos/delays & packet losses to be more realistic.
each node was loaded by rpc request in random order (perl), each node generate & send-out new transactions, also I was using 6 miners with low hashrate just to simulate blockchain mining.
(blockchain was cut version from 2012, something like from block #200000)
I was testing 0.8.6 increasing the blocksize. measured cpu/net load.
reaction on 6-8Mb blocks was very far from perfect.

Seems we need to redo the tests. But I'm occupied by primary business work now 100%.

 

[Richy_T]

Looks like something went wrong when testing segwit and testnet forked:

It would be funny if SPEND ANY was actually broken or non-functional on older clients and brought this whole sad spectacle to an end.

 

[SysMan]

That is exactly it.

Blocksteam/Core believes they should control Bitcoin. This must not be allowed, no only because it's dangerous, but because anyone who wants to control Bitcoin shouldn't by definition.

I'm okey with core. I'm happy that Classic arrive as balance vs core... But I'm afraid how classic trying to perform some changes right now, looks like as bitcoinXT before, more looks like takeover + Brian's coinbase words in Florida...

 

[VeritasSapere]

I perform full topology test using 50+ nodes, aprox year ago.
test in virtual environment simulating linux qos/delays & packet losses to be more realistic.
each node was loaded by rpc request in random order (perl), each node generate & send-out new transactions, also I was using 6 miners with low hashrate just to simulate blockchain.
I was testing 0.8.6 increasing the blocksize. measured cpu/net load.

Seems we need to redo the tests. But I'm occupied by primary business work now 100%.

I would say this issue is very important to your business. I personally think that if the blocksize limit is not increased Bitcoin will simply just be obsolesced and out competed.

I'm okey with core. I'm happy that Classic arrive as balance vs core... But I'm afraid how classic trying to perform some changes right now, looks like as bitcoinXT before, more looks like takeover + Brian's coinbase words in Florida.

If it is a take over, it is a community take over. Taking away control of Bitcoin from Core, distributing that power as it should be.

 

[SysMan]

@VeritasSapere
1. Block-size should be increased but in safe way.
2. I was not performing it only for biz purposes, more educational to understand and realize reality. I was test a lot of scenarios during last 2 years.
3. core - development style should be improved and changed, but step-by-step. right now on _fly_ in will be harder and definitely right now not the best time to do it.

 

[Justus Ranvier]

I'm okey with core. I'm happy that Classic arrive as balance vs core... But I'm afraid how classic trying to perform some changes right now, looks like as bitcoinXT before, more looks like takeover + Brian's coinbase words in Florida...

That's the point.

If Classic is a coup or a takeover, then it proves that it's needed because one group of people believe they are the legitimate rulers!

If people stop buying iPhones and start buying Android phones instead, nobody calls this a coup, because nobody believes that Apple has the right to demand that people only buy their phones.

If Core believes that other people to choose other software is coup, then they believe themselves to be the rulers of Bitcoin. For holding that belief, they are not qualified to be Bitcoin developers and every responsible business should stop using their software.

This doesn't mean use Classic necessarily - it would be even better for more people to start running their own implementations.

 

[cypherdoc]

1. Some of them show very poor communication skills or a lack of maturity — this has hurt bitcoin’s ability to bring new protocol developers into the space.
2. They prefer ‘perfect’ solutions to ‘good enough’. And if no perfect solution exists they seem ok with inaction, even if that puts bitcoin at risk.
3. They seem to have a strong belief that bitcoin will not be able to scale long term, and any block size increase is a slippery slope to a future that they are unwilling to allow.

https://medium.com/@barmstrong/what-happened-at-the-satoshi-roundtable-6c11a10d8cdf#.bw9e1idye

 

[AdrianX]

What mean's adaptive block-size ? shoot first then think about ? you starting self-adjusting mechanism -without understanding how it will works and future, without calculations what it requires.
looks like opening blockchain for spamers/malicious/abuse - like pandora box ?
Bitcoin is young economy, we should more balanced adjust, like the new car engine - it you just increase or just self-regulate, it may be risky.

p.s. Once again I'm not again block-size increase, but its should be done in more safe and balanced way. not like 1st jump, think later.

Hey @SysMan, it's great to have your participation thanks for making an effort.

A lot of this debate revolves around "spamers and malicious abuse" I hate to belittle these concerns but they need to be put in context and the risks evaluated. First off no one in Bitcoin can define them in an objective way that does not discriminate and push out legitimate uses for Bitcoin.

I'd like to address the spam issue with regards to block size, it was introduced when one could produce blocks up to 32MB at a cost below $1.50, and lose less than $200.00 in income should one attempt to maliciously flous the network with large blocks for 24hrs. Today it costs a lot more to produce a block you know better than any of us, and the approximate loss of income is in the millions of dollars for the same interval today - at approximately $10,000 per block.

The spam attack is no longer a viable threat given the profit incentives and costs involved in malicious abuse. admittedly there are many other variants of this attack but they are not viable, limiting the block size is not what's preventing them, it's the economic viability to execute the attacks that prevents them from happening. the real risks facing bitcoin today is not how it grows in 10 years time, but how it grows in the next 10 minutes.

If one had an objective measure of the assessed risks, it's the prevailing opinion that limiting on blockchain growth is more damaging then the likelihood of a malicious attack given the cost.

 

[cypherdoc]

I perform full topology test using 50+ nodes, aprox year ago.
test in virtual environment simulating linux qos/delays & packet losses to be more realistic.
each node was loaded by rpc request in random order (perl), each node generate & send-out new transactions, also I was using 6 miners with low hashrate just to simulate blockchain mining.
(blockchain was cut version from 2012, something like from block #200000)
I was testing 0.8.6 increasing the blocksize. measured cpu/net load.
reaction on 6-8Mb blocks was very far from perfect.

Seems we need to redo the tests. But I'm occupied by primary business work now 100%.

isn't this an argument for removing the cap altogether?

if FN's start suffering/overload with bigger blks, then they get orphaned. miners won't like that as they'd be losing money. thus, they immediately dial back to block sizes that WILL get propagated in a timely fashion.
[doublepost=1457122538][/doublepost]

I'm okey with core. I'm happy that Classic arrive as balance vs core... But I'm afraid how classic trying to perform some changes right now, looks like as bitcoinXT before, more looks like takeover + Brian's coinbase words in Florida...

if you'd open your eyes you'd see that within Classic core dev, there is no financial COI. nor is their from any of us here arguing for a blocksize increase. otoh, Blockstream is clearly a for profit who stands to benefit from the 1MB cap as they develop LN & SC's. wake up man.