[2017-03-13]Bitcoin Unlimited Reaches Almost 40%

[junlyaa]

Bitcoin Unlimited, the new grassroots client, reached 39.6% over a 24 hour period earlier this week, its highest ever. Now standing at more than 30% over the longer one week period.
The new client aims to increase bitcoin’s transaction capacity to meet growing demand and reduce fees as they now average $1 per transaction. It further aims to return more predictable transaction times which currently can be delayed from hours to days.

It has found much support from miners with Antpool, bitcoin’s biggest mining pool, switching to Bitcoin Unlimited on Tuesday. The decision was somewhat surprising, but discussions of a flag day soft fork to force segwit appears to have incentivized the miner to move.


// Let us help you become financially independent. Read exclusive stories, bitcoin analysis and tutorials. Use the coupon code "CCN" and get $10 off. Join Hacked.com now. //

There are now in total ten mining pools on Bitcoin Unlimited, with just one further pool sufficient to allow for near 50% temporary share due to variance. One such pool is to be expected as Chandler Guo, a digital currencies miner, is to open a new pool that will mine on Bitcoin Unlimited.

It is not known if any business is running the new client, but Blockchain.info, Coinbase, Bitpay, Bitgo and many other bitcoin businesses, have advocated for bigger blocks in general and have complained regarding delays.

Critics say Bitcoin Unlimited gives power to miners regarding blocksize decisions and its emergent consensus system is untested. Supporters argue that all nodes decide on the blocksize and the emergent consensus system has been live tested during the increase of the soft limit from 250kb to 500kb to 750kb and then 1MB.

There are arguments on whether the system allows for re-organization with Charlie Lee, Litecoin’s Founder and Coinbase employee, stating that “if at any point, the [Bitcoin Core] chain grows longer (in PoW) than the [Bitcoin Unlimited] chain, the BU client will reorg to the [Bitcoin Core] chain.”

ViaBTC’s founder, Haipo Yang, has suggested that miners wait for Bitcoin Unlimited to reach 75% of the network’s hardware share to avoid a chain split on the same proof of work chain.

There is, however, a community split. Thus, blockstream employees might PoW fork the chain, but BTC.TOP’s founder, Jiang Zhuoer, has stated that $100 million has been set aside to attack any minority chain and make it inoperational.

Any upgrade to bigger blocks is likely to be gradual to give businesses and node operators considerable time. As the client is now nearing 30% share over 1,000 blocks with variance giving it 40%, such upgrade process might begin.

If it nears 40% in the longer 1,000 blocks time-frame, then there might be a shift in attitude as temporary variance would give it 50%. Thus, the client gains serious consideration with activation likelihood considerably increasing.

It is at 50% when, conceptually, it is a done deal. At that point, all businesses will want to be running the BU client. Miners, too, might find it safer, while the general opinion would probably move to ask when, rather than if.

The time frame is probably months, if this year at all. The likelihood of its activation is difficult to predict, but segregated witnesses has stagnated, leaving BU as the only standing option at this point in time.

Once it activates, there is no difference whatever as far as end-users are concerned except that fees would be lower and transaction times would be more predictable. Due to bitcoin’s current politics whereby Michael Marquardt, r/bitcoin’s top moderator, applies biased censorship, miners are incentivized to attack the minority chain to avoid any arguments over the bitcoin name. A chain split therefore appears unlikely, but if there is one, there is no difference for end users except that now they hold their coins on both chains.

If Bitcoin Unlimited does activate, it would be the first time ever in the entire blockchain space that a decision in such a decentralized manner without any guidance or leadership has been made.
https://www.cryptocoinsnews.com/bitcoin-unlimited-reaches-almost-40/

[notthematrix]

Only problem is its not 40%! https://coin.dance/blocks
they cheat and lie ....

[DooMAD]

Only problem is its not 40%! https://coin.dance/blocks
they cheat and lie ....

reached (...) earlier this week

As in past tense.  Previously happened.  Over the last 7 days, it's currently averaging ~30%, in the last 24 hours it currently says 32.6%.  Apparently, some time earlier this week, although they neglected to mention when, cryptocoins news are saying it peaked at 39.6%.  Obviously it's come down since then.  With the way chance and probability factors into mining, it could have been a complete fluke and not representative of their actual hashrate.

[buwaytress]

Any upgrade to bigger blocks is likely to be gradual to give businesses and node operators considerable time. As the client is now nearing 30% share over 1,000 blocks with variance giving it 40%, such upgrade process might begin.

If it nears 40% in the longer 1,000 blocks time-frame, then there might be a shift in attitude as temporary variance would give it 50%. Thus, the client gains serious consideration with activation likelihood considerably increasing.

It is at 50% when, conceptually, it is a done deal. At that point, all businesses will want to be running the BU client. Miners, too, might find it safer, while the general opinion would probably move to ask when, rather than if.

The time frame is probably months, if this year at all. The likelihood of its activation is difficult to predict, but segregated witnesses has stagnated, leaving BU as the only standing option at this point in time.

What happens then, if neither SegWit nor BU reaches the adoption percentage both will require to be fully taken on by the network? It seems strange (or not) that the option that will presumably be eventually taken is only decided because "it is the only standing option".

I'm probably - as article points out - with the general opinion to simply move with the flow. Is 50% really that point of no return?

[notthematrix]

It will get not over 50% , it was never over 40& , the problem with BU is that miner fees will be lower , roger ver is now trying to bet against the market.
using his btc to stop core , in code core is better , so core will win even if it takes a split and a other crash.
But I think this will not happen because creative people will find other solutions like moving towards user activated soft fork activation.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013643.html
the creative people will always win this.
people will in the end go for the better more secure network , and that's not UL , its based on older code.
https://www.youtube.com/watch?v=Ibz_HMKHQl4
explains it very well

P.S if I comment on the article comments do not get true...
this kind of things tells me a lot , because only if you fear losing you resort to cencorship.
I take this article with a big grain of salt!
because its the classic scare & cheer media. in the world of what makes you click.

[TraderTimm]

"Grassroots Client" my ass.

This is a concerted push by a couple of compromised actors to make sure their "vision" of Bitcoin is adopted, nothing less.

I really hope they get a chain going, then watch it crash and burn as everyone cashes out and flees back to the original chain - which is an entirely probable scenario put out by the creator of Litecoin. This is a very dangerous game Ver and the rest are pushing, and they may end up losing their fortunes as a result.

Bitcoin doesn't like to be "told" where to go, and neither do the users. I'm not moving a single coin to a new chain - I think any fork attempt will fail... especially one not supported by the clients, who are massively on the Segwit side of the argument.

[ImHash]

Once again I'll repeat myself, if you think BU is a good solution then run as your pool node.
If you think Core/SW/LN are the good ones, then run Core as your pool node and support signaling activation of SW.
If you think BU has hidden agenda then try to find it and take advantage of whatever they're taking advantage of by having the most hashpower.
If you think SW/Core has hidden agendas, then join them and have whatever they're going to have.
If after BU wins the race you will no longer be able to have access to whatever all other BU users have access to, then discard anything BU related.
If after SW activation you will no longer have access to whatever the features SW users have access to, like for example; you won't be able to run a specific service freely and without the need of an agency/organization approval and you are basically limited and only able to conduct business if a central authority permits you to do so, then refuse to support SW.

You say BU is gonna have some sort of upper hand if achieves the majority consensus? then you'll be able to have the same upper hand if you just adopt whatever the majority agreed upon.

Only start bi*ching around if after of approval of any proposals you'll effectively hit a limit wall while others not.
If people are eating tomato, then start eating tomato, only issue here is whether you are eating the same tomato as everyone else is eating or not:D

I know that was very intense

[notthematrix]

If after SW activation you will no longer have access to whatever the features SW users have access to, like for example; you won't be able to run a specific service freely and without the need of an agency/organization approval and you are basically limited and only able to conduct business if a central authority permits you to do so, then refuse to support SW.

Thats one thing I know for sure the code does not do that!
I allows multiple type of adresses classic ones starting with a 1
and mutisig / segwit ones starting with a 3...
the 3. adresses have other features as the 1. adresses
you can read it all in the code.
 

[Holliday]

I'm not moving a single coin to a new chain

If you control private keys ("own" bitcoins) before a contentious hard fork, you retain control of those keys on each existing chain post-fork.

If there is a market for coins existing on both chains, you can simply "taint" coins existing on one chain by combining them with coins that only exist on that chain (mining rewards or coins that have been combined with mining rewards) and then safely sell them (or transfer them to a new address) without risking your coins on the other chain.

[buwaytress]

I'm not moving a single coin to a new chain

If you control private keys ("own" bitcoins) before a contentious hard fork, you retain control of those keys on each existing chain post-fork.

If there is a market for coins existing on both chains, you can simply "taint" coins existing on one chain by combining them with coins that only exist on that chain (mining rewards or coins that have been combined with mining rewards) and then safely sell them (or transfer them to a new address) without risking your coins on the other chain.

There's a post from a staff member... can't recall where now that was made some time last year with really just one point of advice that would apply to most of us, myself included: do nothing except ensure your coins are on a wallet to which you control the private keys.

If the fork happens, this ensures you have coins on both chains.

[notthematrix]

I think a fork will not happen , it will weaken bitcoin I think people wil prefer the status quo.
And use bitcoin as store of value.
There could be a option build in to connect other payment option indirect to bitcoin.
but what the last bug showed is that making changes is a risky thing.
A segwit system could work as long it is a separate system so when it fails , the real bitcoin blockchain is not effected , if you store to many btc on that channel you could lose those so that makes it only handy for smaller transactions.
that only get fully verified it stored on the real blockchain.
 only fix bitcoin malleability in the original btc code , then add segwit or other features as a separate client structure , so when there is a bug it will not hurt the inter workings of bitcoin it self!

[DooMAD]

I think a fork will not happen , it will weaken bitcoin I think people wil prefer the status quo.
And use bitcoin as store of value.
There could be a option build in to connect other payment option indirect to bitcoin.
but what the last bug showed is that making changes is a risky thing.
A segwit system could work as long it is a separate system so when it fails , the real bitcoin blockchain is not effected , if you store to many btc on that channel you could lose those so that makes it only handy for smaller transactions.
that only get fully verified it stored on the real blockchain.
 only fix bitcoin malleability in the original btc code , then add segwit or other features as a separate client structure , so when there is a bug it will not hurt the inter workings of bitcoin it self!

It sounds like you've got SegWit and the Lightning Network muddled up.  SegWit isn't related to payment channels and off-chain transactions.  Transactions in SegWit's format will still be on the "real" Bitcoin blockchain.  SegWit merely greases the wheel a bit to make it easier to implement Lightning, but has it's own distinct benefits and features aside from that.

[notthematrix]

I think a fork will not happen , it will weaken bitcoin I think people wil prefer the status quo.
And use bitcoin as store of value.
There could be a option build in to connect other payment option indirect to bitcoin.
but what the last bug showed is that making changes is a risky thing.
A segwit system could work as long it is a separate system so when it fails , the real bitcoin blockchain is not effected , if you store to many btc on that channel you could lose those so that makes it only handy for smaller transactions.
that only get fully verified it stored on the real blockchain.
 only fix bitcoin malleability in the original btc code , then add segwit or other features as a separate client structure , so when there is a bug it will not hurt the inter workings of bitcoin it self!

It sounds like you've got SegWit and the Lightning Network muddled up.  SegWit isn't related to payment channels and off-chain transactions.  Transactions in SegWit's format will still be on the "real" Bitcoin blockchain.  SegWit merely greases the wheel a bit to make it easier to implement Lightning, but has it's own distinct benefits and features aside from that.

I dont care abou the politics , if code is not tested wellas explained here

https://twitter.com/TuurDemeester/status/842062133097574403
the choice is simpel.
as andreas puts it.

"BU has shipped an exploitable bug on a code base that is 0.001 of the size of Core's. That's several orders of magnitude worse QA process"

https://twitter.com/aantonop/status/841928772790190080


This is a part of the interview of the bug discoverer. fist link (tuur de meester)

If you have a big size but it does not work reliable when it needs to preform its useless!

[DooMAD]

I think a fork will not happen , it will weaken bitcoin I think people wil prefer the status quo.
And use bitcoin as store of value.
There could be a option build in to connect other payment option indirect to bitcoin.
but what the last bug showed is that making changes is a risky thing.
A segwit system could work as long it is a separate system so when it fails , the real bitcoin blockchain is not effected , if you store to many btc on that channel you could lose those so that makes it only handy for smaller transactions.
that only get fully verified it stored on the real blockchain.
 only fix bitcoin malleability in the original btc code , then add segwit or other features as a separate client structure , so when there is a bug it will not hurt the inter workings of bitcoin it self!

It sounds like you've got SegWit and the Lightning Network muddled up.  SegWit isn't related to payment channels and off-chain transactions.  Transactions in SegWit's format will still be on the "real" Bitcoin blockchain.  SegWit merely greases the wheel a bit to make it easier to implement Lightning, but has it's own distinct benefits and features aside from that.

I dont care abou the politics , if code is not tested wellas explained here

https://twitter.com/TuurDemeester/status/842062133097574403
the choice is simpel.
as andreas puts it.

"BU has shipped an exploitable bug on a code base that is 0.001 of the size of Core's. That's several orders of magnitude worse QA process"

https://twitter.com/aantonop/status/841928772790190080

This is a part of the interview of the bug discoverer. fist link (tuur de meester)

If you have a big size but it does not work reliable when it needs to preform its useless!

Yeah, I'm with you up to that point:

I think a fork will not happen , it will weaken bitcoin I think people wil prefer the status quo.
And use bitcoin as store of value.
There could be a option build in to connect other payment option indirect to bitcoin.
but what the last bug showed is that making changes is a risky thing.

So that's about BU and makes sense.  But then you went on to say:

A segwit system could work as long it is a separate system so when it fails , the real bitcoin blockchain is not effected , if you store to many btc on that channel you could lose those so that makes it only handy for smaller transactions.
that only get fully verified it stored on the real blockchain.
 only fix bitcoin malleability in the original btc code , then add segwit or other features as a separate client structure , so when there is a bug it will not hurt the inter workings of bitcoin it self!

And that's where I lost you, because SegWit has nothing to do with payment channels and off-chain transactions.  That's Lightning, not SegWit.  SegWit is more of an optimisation and a change in the way transactions and blocks are structured so that more transactions can effectively be squeezed in.  Plus it fixes malleability.  But it's all done on the main blockchain.

Lightning is the one that involves opening a payment channel by locking an amount of BTC on the main chain, so that you can transact with that total off-chain both faster and with less fees.  But Lightning is probably still a fair way off and no one is 100% sure what the finished product might look like at this point.

BU isn't related to either and that's the one that had the glaring error.

[notthematrix]

Yes thats true I explained it wrong...
Segwit allows Payment channels...

[Bit_Happy]

I think a fork will not happen , it will weaken bitcoin I think people wil prefer the status quo.
And use bitcoin as store of value.
There could be a option build in to connect other payment option indirect to bitcoin.
but what the last bug showed is that making changes is a risky thing.
A segwit system could work as long it is a separate system so when it fails , the real bitcoin blockchain is not effected , if you store to many btc on that channel you could lose those so that makes it only handy for smaller transactions.
that only get fully verified it stored on the real blockchain.
 only fix bitcoin malleability in the original btc code , then add segwit or other features as a separate client structure , so when there is a bug it will not hurt the inter workings of bitcoin it self!

It sounds like you've got SegWit and the Lightning Network muddled up.  SegWit isn't related to payment channels and off-chain transactions.  Transactions in SegWit's format will still be on the "real" Bitcoin blockchain.  SegWit merely greases the wheel a bit to make it easier to implement Lightning, but has it's own distinct benefits and features aside from that.

I dont care abou the politics , if code is not tested wellas explained here

https://twitter.com/TuurDemeester/status/842062133097574403
the choice is simpel.
as andreas puts it.

"BU has shipped an exploitable bug on a code base that is 0.001 of the size of Core's. That's several orders of magnitude worse QA process"

https://twitter.com/aantonop/status/841928772790190080


This is a part of the interview of the bug discoverer. fist link (tuur de meester)

If you have a big size but it does not work reliable when it needs to preform its useless!

This is getting way too exciting!
We need Bitcoin to remain predicable, almost "boring" or the damage to BTC's image will become extreme.

[Sr.Urbanist]

BU needs more people working on it.  The 100k+ tx queue show how its importance.  

We need to fix layer one (block scaling *options*) before layer two - SegWit and all the cool stuff in two years. Yes, BU may not have the best code, but that is because it is grassroots that started on the site. http://www.coindesk.com/hidden-history-bitcoin-unlimited/

[d5000]

We need to fix layer one (block scaling *options*) before layer two - SegWit and all the cool stuff in two years.

It's actually the other way around. We first need a solution for the quadratic hashing time problem before we can think about a blocksize increase. Otherwise, the danger of spam is too big.

I know, FlexTrans does also provide a solution. But as with Segwit, we would need first a pretty long timeframe to allow nodes to adopt the new transaction format. And when the block size increase goes live, we would need a restriction to legacy transactions because otherwise spammers could simply use them to continue spamming the network with transactions that would crash smaller full nodes.

[Veider_lord]

We need to fix layer one (block scaling *options*) before layer two - SegWit and all the cool stuff in two years.

It's actually the other way around. We first need a solution for the quadratic hashing time problem before we can think about a blocksize increase. Otherwise, the danger of spam is too big.

I know, FlexTrans does also provide a solution. But as with Segwit, we would need first a pretty long timeframe to allow nodes to adopt the new transaction format. And when the block size increase goes live, we would need a restriction to legacy transactions because otherwise spammers could simply use them to continue spamming the network with transactions that would crash smaller full nodes.

If I understand you, we are not yet ready for this growth? Perhaps with the nodes of things are much easier than we think.