Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: achow101 on January 30, 2017, 02:32:33 AM



Title: Bitcoin.com almost forks the blockchain with buggy BU
Post by: achow101 on January 30, 2017, 02:32:33 AM
Bitcoin.com's mining pool, running Bitcoin Unlimited, recently accidentally mined a block (https://live.blockcypher.com/btc/block/000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5/) greater than 1,000,000 bytes. This block is considered invalid under the current consensus rules and was subsequently rejected. This resulted in Bitcoin.com to lose the ~13.2 BTC block reward of that block and waste their miner's time and electricity.

This invalid block also resulted in many BU nodes being banned by other nodes for relaying an invalid block.

Note that this is different from normal block orphaning as this could have resulted in a consensus split, not just a normal small fork with all full nodes switching to follow the longest chain. The longest chain could have been built off of the invalid block due to BU and SPV miners making up nearly half of the network hashrate.

This block could have resulted in an actual hard fork and chain split due to BU miners and SPV miners. Some BU miners would have considered this block valid and thus mined on top of it. SPV miners would have received the block header and mined on top of that without checking the validity of the actual block itself until later. This could have resulted in a blockchain split similar to the July 2015 fork (https://bitcoin.org/en/alert/2015-07-04-spv-mining). Fortunately neither of those happened and there was no chain split.

The reason for this block is that BU changed some important code regulating the size of the block. Specifically, they removed something that reserved space for the coinbase transaction and thus once the transactions had been selected and the coinbase transaction were added, the size was too big. This bug appears to have been introduced here (https://github.com/BitcoinUnlimited/BitcoinUnlimited/commit/eb7db8b15dce186870568c6b0dc156bdb179710a#diff-4a59b408ad3778278c3aeffa7da33c3cL124) which was also committed directly to the source code with a Pull Request, so it is likely that the change was not reviewed.

See also: Reddit discussion (https://www.reddit.com/r/Bitcoin/comments/5qwtr2/bitcoincom_loses_132btc_trying_to_fork_the/)


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Quickseller on January 30, 2017, 02:56:51 AM
I don't think there was any real risk of Bitcoin forking because AFAIK no merchants have indicated they will solely use BU and not core, nor is there any substantial mining capacity running solely on BU.

I believe that Rodger Ver said on r/btc that the Bitcoin.com pool is PPS, so he will bear the full cost of this. Similarly, I think the major pools had learned from the July 2015 fork that they need to fully validate blocks ASAP, even if they SPV mine for a few seconds after receiving a block from a trusted source.

Similar to the July 15 fork, if the miners had continued to mine on this invalid block (effectively changing what they consider valid), then major Bitcoin business would need to decide on the fly if they will accept these changes concensus rules (note: I specifically did not say "nodes"), under the understanding that if these changed concensus rules are not accepted then they would be only accepting Bitcoin from a network with decreased security and increased block times for a long time.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: -ck on January 30, 2017, 03:05:04 AM
Actually quite a number of pools that use header only mining, btc.com viabtc f2pool btcc and btc.top all were mining on the invalid chain for a while there. I suspect the only reason there wasn't an extended fork was because the next block found was on the valid chain making them reorganise their own chains back to the correct one. Since the pools are not clear on when they switch from invalidated headers to validated blocks, it's hard to know exactly what might have happened.

Here is the log of it hitting my pool's bitcoind and how my (0.13.2 core based) node handled it:
Code:
2017-01-29 06:58:50.871920 ERROR: ContextualCheckBlock(): weight limit failed
2017-01-29 06:58:50.896292 ERROR: AcceptBlock: bad-blk-weight (code 16)
2017-01-29 06:58:50.896352 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-01-29 06:58:50.896433 Misbehaving: 54.213.163.201 (0 -> 100) BAN THRESHOLD EXCEEDED
resulting in the propagating BU node being banned by my node.

Followed by another node trying to submit the block again
Code:
2017-01-29 07:01:21.701452 ERROR: AcceptBlockHeader: block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 is marked invalid


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: achow101 on January 30, 2017, 03:08:22 AM
I don't think there was any real risk of Bitcoin forking because AFAIK no merchants have indicated they will solely use BU and not core, nor is there any substantial mining capacity running solely on BU.
The issue is more of miners mining on top of the invalid block due to SPV mining.

I believe that Rodger Ver said on r/btc that the Bitcoin.com pool is PPS, so he will bear the full cost of this. Similarly, I think the major pools had learned from the July 2015 fork that they need to fully validate blocks ASAP, even if they SPV mine for a few seconds after receiving a block from a trusted source.
While I am sure that many pools learned that they need to fully validate the blocks ASAP, I am fairly certain that many large mining pools still do SPV mining and thus could have accidentally mined a block on top of the invalid one before completing validation of it. It would be similar to the July 2015 fork.

Similar to the July 15 fork, if the miners had continued to mine on this invalid block (effectively changing what they consider valid), then major Bitcoin business would need to decide on the fly if they will accept these changes concensus rules (note: I specifically did not say "nodes"), under the understanding that if these changed concensus rules are not accepted then they would be only accepting Bitcoin from a network with decreased security and increased block times for a long time.
The major difference here is that the fork would not be known or obvious to those businesses unless they follow media (or Reddit) that have reported a fork. No block explorer has information about the invalid block except for blockcypher. Anyone running software other than BU would not have known that a fork was happening. The only indications that a fork was happening would be that the log files for full nodes would be reporting invalid blocks briefly until those nodes relaying them got themselves banned and that blocks would simply be produced at a slower pace.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Foxpup on January 30, 2017, 03:54:18 AM
This is delicious. ;D

Code:
2017-01-29 07:00:22 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)
2017-01-29 07:00:22 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-01-29 07:00:22 Misbehaving: 127.0.0.1:57226 (0 -> 100) BAN THRESHOLD EXCEEDED
2017-01-29 07:00:22 Warning: not banning local peer 127.0.0.1:57226!
2017-01-29 07:00:34 receive version message: /btcwire:0.5.0/btcd:0.12.0(EB4; AD99999)/: version 70012, blocks=450529, us=[scrubbed].onion:8333, peer=1638
2017-01-29 07:00:34 AdvertiseLocal: advertising address [scrubbed].onion:8333
2017-01-29 07:00:36 ERROR: AcceptBlockHeader: block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 is marked invalid
2017-01-29 07:00:36 ERROR: invalid header received
2017-01-29 07:00:36 ProcessMessages(headers, 82 bytes) FAILED peer=1638

I'm archiving this log as a permanent reminder of BU's incompetence.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 03:55:06 AM
1. orphans/rejects happen often but you dont see blockstream orgasming when those orphans/rejects are based on bad core code
2. the block got rejected in 3 seconds .. end of drama.. but core nodes were set to ban nodes in such an event (over dramatics)
3. this block rejected, like other orphans/rejects proves that consensus and validation mechanism works
4. this proves that altcoins are not created just due to a slightly larger block
5. this proves that all the core rhetorical and scripted doomsdays are wrong.

people need to realise that within 3 seconds the block got rejected. orphaned off.. thrown away, put in the trash, not used,  gone
Quote
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 from  peer=729
2017-01-29 06:59:15 received block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 peer=729
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

meaning consensus works. bitcoin is still in one piece.

the network will only validate and accept blocks over 1mb when there is a majority.
so this is actually a positive by squashing all the fake doomsdays of altcoins and splits by BU.

WAKE UP PEOPLE

the real funny part is, although bitcoins built in mechanism from 2009 works as it should..
the core blockstream fans fear consensus, soo much they actually manually and automatically banned nodes AFTER bitcoins built in code done what it should, thus now core are the risk of causing an intentional bilateral split.. by avoiding the natural orphan/validation mechanism by ignoring nodes instead of just rejecting blocks.

here is what would happen is they didnt ban nodes and someone passed them the same block
Quote
2017-01-29 07:02:10 receive version message: /BitcoinUnlimited:0.12.1(EB16; AD4)/: version 80002, blocks=450529, peer=737
2017-01-29 07:02:10 received: headers (82 bytes) peer=737
2017-01-29 07:02:10 ERROR: AcceptBlockHeader: block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 is marked invalid

meaning its already been marked as dead, so dont handle it. IN THE SAME SECOND
thus no need to block nodes. as bitcoins consensus already pushed it to the side as a non issue within the same second

ha ha ha. im laughing

ofcourse gmaxwell instead of highlighting that consensus worked and issue resolved in 3 seconds where that block is automaticaly flagged as invalid if picked up again by another node..is do nothing more within a second.. (meaning he didnt highlight what consensus does). but instead orgasmed at the opportunity that his auto ban settings in core intentionally banned the nodes.. thus making a bilateral split possible due to core ignorance and use of an auto node ban feature.
(desperation i smell in gmaxwells pants)

Quote
Every Bitcoin Core node happily banned the BU peers that gave them this invalid block,

he kind of back tracked after to half explain consensus, where he said (not verbatim) 'an SPV would see the block until a new block officially pushes it away'.
although spv clients also rejected it in SECONDS using consensus without having to ban nodes. but maxwell didnt highlight the no need to ban peers aspect..

Quote
SPV wallet user who were connected to BU nodes may have seen a false confirmations for 24 minutes until 450530 was mined which decisively overtook the invalid 450529. Fortunately, in this case it doesn't appear that SPV miners exacerbated the invalid block fork though several did follow it briefly.

gmaxwell is desparate to cause an altcoin. he is even celebrating it
Quote
You missed a great opportunity for alliteration: Bugged block brings blanket BU bans. :P

desperate man, afraid of consensus that much he is willing to bilateral split the network.. as shown by earlier evidence of even wanting to bilateral split the network just to force segwit in
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.


summary
CORE can cause a bilateral split by banning BU. not the other way round.
there is and was no need to ban the nodes.. bitcoins validation mechanism took care of the block but core went one stage to far banning nodes..
desperate move blockstream.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: -ck on January 30, 2017, 03:59:27 AM
For the record, this is nothing like a regular orphan so drawing any comparisons based on that assumption are all misguided at best.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 04:07:41 AM
For the record, this is nothing like a regular orphan so drawing any comparisons based on that assumption are all misguided at best.

like your pretending this has not happened before.
blocks over 1mb have been rejected before now. but blockstram fans are over dramatizing it to make it sound like BU could have caused a bilateral split, when infact it was cores heavy hand that went a step too far to possibly cause one. rather then just reject the block and move one

need i bring up sipa's 2013 DB boo boo..where core bugged out when blocks went over 500kb.. oops i better not mention a blockstream paid dev's boo boo's


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: achow101 on January 30, 2017, 04:10:36 AM
1. orphans happen often but you dont see blockstream orgasming when those orphans are based on bad core code
This is not an orphan. An orphan is a valid block. This block is invalid, entirely different from an orphan. An orphan can lead to a valid chain which EVERYONE will follow. This block is invalid, and can lead to a chain where SOME NODES (not all nodes) follow.

When has a miner running just Bitcoin Core as their node (and thus not SPV mining) mined an invalid block?

2. the block got rejectct in 3 seconds .. end of drama..
3 seconds in which an SPV miner could have found a block on top of the invalid one and thereby causing a chain split.

but core nodes were set to ban nodes in such an event (over dramatics)
Rejecting a block for being invalid and subsequently banning the node that sent the block is not behavior just limited to Bitcoin Core. It is present in Bitcoin Unlimited as well and any other software derived from Core. Such behavior has been in the code for a very long time.

3. this block reject, like other oprhans proves that consensus and orphans work
Again, this block was invalid and rejected. It is not an orphan. They are two very different things.

4. this proves that altcoins are not created just due to a slightly larger block
5. this proves that all the core rhetorical and scripted doomsdays are wrong.
This just shows that it will not always happen. This does not mean that it can't happen.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 04:34:20 AM
and the only knitpick you can find is that i over used the buzzword orphan..
aww you may consider an orphan to be strictly related to a bad parent being taken away leaving the child to be lost in the system and rejected as a consequence, even if the child is a good child..

i consider all rejections where having a parent or not, whether the child is good or bad ends up as the same result.
ends up with the same result
in laymans:
lost and rejected, cast aside. in the dustbin, thrown away, disguarded. bye bye gone!
(and dont even bother replying there is no dustbin in bitcoin.. )

your just going to nd up looking pedantic again

orphans/rejects do not cause altcoins. orphans/rejects sort themselves out in the end.
what causes altcoins is when nodes are triggered to ban other nodes to not see a orphan/reject. which then leads to two nodes seeing or not seeing the same data.


When has a miner running just Bitcoin Core as their node (and thus not SPV mining) mined an invalid block?
happens more often then you think
https://blockchain.info/orphaned-blocks


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: DannyHamilton on January 30, 2017, 04:36:42 AM
Note that this is different from normal block orphaning

Only because this block was invalid.  It is identical to what happens (and is supposed to happen) any time a node receives an invalid block.

as this would have resulted in a consensus split

Absolute nonsense.  Unless you are saying that a significant majority of all mining nodes are willing to accept a block larger than 1 megabyte (in which case it is Core that is trying to create a consensus split by refusing to accept the longest chain). No. In this case, a minority of miners would be willing to accept such a block.  As a result the valid chain would quickly grow longer.  Only those nodes foolish enough to accept and mine on top of an invalid block (such as so-called SPV miners) would be affected, and any miner dumb enough to accept an invalid block deserves to waste hash power on a dead chain.

This block could have resulted in an actual hard fork and chain split due to BU miners and SPV miners.

No. Not in any real way, it couldn't.  That's a whole lot of FUD and nonsense.  If I didn't know better, I'd think you were just another sig ad spammer.

Some BU miners would have considered this block valid and thus mined on top of it.

Let them.  Thats what they get for running code that will mine on top of invalid blocks.  They'll lose some revenue and learn an important lesson.

SPV miners would have received the block header and mined on top of that without checking the validity of the actual block itself until later.

Then they deserve to waste their hashpower and resources on an invalid block.

This is not an orphan. An orphan is a valid block. This block is invalid, entirely different from an orphan. An orphan can lead to a valid chain which EVERYONE will follow. This block is invalid,

Exactly.  If bitcoin can't handle some nodes receiving invalid blocks occasionally, then it has already failed and we should all abandon the whole experiment.  Those dumb enough to mine on top of an invalid block deserve what they get (which entertainingly enough is literally "nothing").

and can lead to a chain where SOME NODES (not all nodes) follow.

Only nodes that are willing to risk wasting time and money on a useless endeavor.

Rejecting a block for being invalid and subsequently banning the node that sent the block is not behavior just limited to Bitcoin Core. It is present in Bitcoin Unlimited as well and any other software derived from Core. Such behavior has been in the code for a very long time.

Which is why this is nothing more than people blowing a lot of smoke and then trying to claim there is a fire.

Again, this block was invalid and rejected. It is not an orphan. They are two very different things.

And yet you continue to act like it was somehow a valid block that could have "forked the network!"  Nonsense.

This just shows that it will not always happen. This does not mean that it can't happen.

Like I said, if it can then bitcoin is already a failed experiment and we should all abandon the entire concept immediately.  There is nothing more to see here than fools seeing rain and believing that the sky is collapsing on them.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 04:47:13 AM
i completely agree with danny hamilton. including the hard/expensive lesson for BU to learn.

but technically.. they never actually got the funds in the first place. so its just like all blocks... there is only one winner, and BU simply didnt win


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: DannyHamilton on January 30, 2017, 04:57:00 AM
but technically.. they never actually got the funds in the first place.

The point is that they waste time and money running equipment generating hashes that will never be part of the blockchain.  That's the expensive lesson.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Warg on January 30, 2017, 08:11:15 AM
This resulted in Bitcoin.com to lose the ~13.2 BTC block reward of that block and waste their miner's time and electricity.

May be they run out of money eventually, and people start to abandon them. And they go bankrupt. I think everyone get tired of obstinate bastards


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: aarturka on January 30, 2017, 08:29:03 AM
Right. I think the BU issue is solved now for good. If these morons may allow such mistakes, Who will trust them implement their hardfork?  :)


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: aarturka on January 30, 2017, 08:36:29 AM

I believe that Rodger Ver said on r/btc that the Bitcoin.com pool is PPS, so he will bear the full cost of this.
When he breaks Bitcoin with his hardfork and millions of people lose their money, he's going to compensate them too?


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: jacaf01 on January 30, 2017, 09:19:08 AM
Right. I think the BU issue is solved now for good. If these morons may allow such mistakes, Who will trust them implement their hardfork?  :)

This is my concern with BU, they don't have what is takes to implement a successful hard fork they are advocating for. That is why they embark on divided and rule strategy between the miners and core team


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: iCEBREAKER on January 30, 2017, 10:48:05 AM
Here is the log of it hitting my pool's bitcoind and how my (0.13.2 core based) node handled it:
Code:
2017-01-29 06:58:50.871920 ERROR: ContextualCheckBlock(): weight limit failed
2017-01-29 06:58:50.896292 ERROR: AcceptBlock: bad-blk-weight (code 16)
2017-01-29 06:58:50.896352 ERROR: ProcessNewBlock: AcceptBlock FAILED
2017-01-29 06:58:50.896433 Misbehaving: 54.213.163.201 (0 -> 100) BAN THRESHOLD EXCEEDED
resulting in the propagating BU node being banned by my node.

Banhammered at the protocol level.  That is glorious.

Time to make an "BitcoinUnlimite Officially #REKT" thread.   :D

Working title:

BU Builds Broken Block, Blundering Bigblocker Buffoons BTFO



TIL Roger Ver, franky1, Quickseller, and DannyHamilton have very weak, incomplete, and/or just plain old wrong (mis)understandings of Bitcoin's specialized definitions for Orphan, Chain Fork, and Consensus Critical.

For years, these people have stubbornly insisted on telling us how Bitcoin is supposed to work.  Now we have confirmation they don't understand the basic concepts.

"but but orphans happen all the time"

BWAHAHAHA.   ;D

"but but there was no danger of the fork persisting"

BWAHAHAHA.   ;D

"but but the pool didn't really lose money"

BWAHAHAHA.   ;D


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: aarturka on January 30, 2017, 11:17:38 AM



TIL Roger Ver, franky1, Quickseller, and DannyHamilton have very weak, incomplete, and/or just plain old wrong (mis)understandings of Bitcoin's specialized definitions for Orphan, Chain Fork, and Consensus Critical.

For years, these people have stubbornly insisted on telling us how Bitcoin is supposed to work.  Now we have confirmation they don't understand the basic concepts.

"but but orphans happen all the time"

BWAHAHAHA.   ;D

"but but there was no danger of the fork persisting"

BWAHAHAHA.   ;D
I earnestly suggest to franky1 to learn something elementary, research harder, run some code, begin with 'hello world' then research, research research, just not to look like complete oaf,
but he prefer not to wake up, to act like Ver constantly takes care of him, continue dreaming in his imaginary world... 


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 11:18:00 AM
..

i understand the terms. i just dont go batshit crazy when talking generally.

take for instance achowe himself.. deeming a 3 second reject as a fork..
that is achowe doing a grammar boo boo missuse of buzzwording.

infact achowe went sooo deep he wanted to take a zero drama non-event such as a 3second reject. to make it into some 'BU caused a bilateral fork'. that he forgot that core closed the connections to make it bilateral rather than leave the connections open to stick with consensus

but it is good to see the only argument left to sustain this non event, is the grammar nazi argument.

so i find it funny that you think that this non event deserves its own r3cked topic all because you are a grammar nazi, as your only ammo to defend your corporate pals.

gmaxwll hates it when i dont
call his confidential payment codes, 'confidential Pedersen commitment'
call an intentional split, 'bilateral split'

so forgetting blockstreams buzzword anal desires. and instead thinking real world scenario use of words so common people can get the general context without having to decypher buzzwords

an orphan is not just where the parent is killed and the good child ends up being sidelined and alone, forgotton about.
an orphan is where the parent themselves choose to giveup the child, dont put their names on the birth certificate and instead choose to adopt another child.

so the child in both circumstances is an orphan. because it has no ties to a parent. and doesnt continue the family tree legacy.

a child can be an orphan whether the parent is alive or dead

Quote
noun
2.
a young animal that has been deserted by or has lost its mother.
3.
a person or thing that is without protective affiliation, sponsorship, etc.:
The committee is an orphan of the previous administration.


adjective
7.
not authorized, supported, or funded; not part of a system; isolated; abandoned:
an orphan research project.

i fully understand the terms. i just choose to translate the nazi buzzword's into common tongue.
for instance if i decided to become a medical doctor. i would refuse to tell a patient they had a 'acute myocardial infarction' to sound smart. i would instead say their heart stopped for 30 seconds. because its better to tell the person what actually happened rather than sound like a smart ass

oh well enjoy your social campaigns


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 11:33:48 AM
I earnestly suggest to franky1 to learn something elementary, research harder, run some code, begin with 'hello world' then research, research research, just not to look like complete oaf,
but he prefer not to wake up, to act like Ver constantly takes care of him, continue dreaming in his imaginary world... 

sounds familiar.
oh i forgot you are in the r/bitcoin tribe that loves to read and repeat. rather then learn and think independently.

time for you stop rehearsing lines,


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: aarturka on January 30, 2017, 12:03:45 PM
I earnestly suggest to franky1 to learn something elementary, research harder, run some code, begin with 'hello world' then research, research research, just not to look like complete oaf,
but he prefer not to wake up, to act like Ver constantly takes care of him, continue dreaming in his imaginary world... 

sounds familiar.
oh i forgot you are in the r/bitcoin tribe that loves to read and repeat. rather then learn and think independently.

time for you stop rehearsing lines,

lol
Why do you always do what Ver tells you?
Dont you have your own thoughts and your own feeling?

stop acting like Roger Ver will always be with you,  you dont need him holding your hand...  today he lost $12000... he cant always pay his shills...
...As I said before, my errant friend, researh, research, research, try different ways to broaden your horizons and someday you will hear way to go!..

untill learn something begin now, dont waste your time posting here it would have no relevance anyway...


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 12:10:25 PM
lol
Why do you always do what Ver tells you?
Dont you have your own thoughts and your own feeling?

stop acting like Roger Ver will always be with you,  you dont need him holding your hand...  today he lost $12000... he cant always pay his shills...
...As I said before, my errant friend, researh, research, research, try different ways to broaden your horizons and someday you will hear way to go!..

untill learn something begin now, dont waste your time posting here it would have no relevance anyway...


here is the funny part
you have said nothing original. you repeat what others have said. you dont even care who says it.
and it has been a few days since you yourself were told to research. and all you manage to do is repeat other peoples words.

i see nothing new and you are just trolling.

for your own sake atleast spend a few minutes reading the truth and not just reading r/bitcoin scripts. or copying other people.

p.s
i dont even run a BU node. i have my own :D
funnier part is icebreaker tried to sideline me into classic camp, then xt camp last year.. rather then admit the truth and just realise i simply hate blockstreams corporate paid backing and core paid devs employee contracted terms to meet certain code/commercial service objectives to make financial returns for their investors.

pretty much a shame that you are wanting blockstream to be king..
where as i prefer diverse USER consensus with no dev control.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: aarturka on January 30, 2017, 12:31:18 PM
i prefer diverse USER consensus with no dev control.

then research harder... Ver is not the one you want to be under
have a good researchin'!  ;)


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: iCEBREAKER on January 30, 2017, 01:18:57 PM
"Bitcoin Unlimited is building the highest quality, most stable, Bitcoin client available. We have a strong commitment to quality and testing"


https://i.imgur.com/fx5Q1PK.jpghttps://i.imgur.com/fx5Q1PK.jpghttps://i.imgur.com/fx5Q1PK.jpghttps://i.imgur.com/fx5Q1PK.jpg


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: hv_ on January 30, 2017, 01:24:04 PM
Nice shill parade.


BU code seems to be recognized.


And it has a luxury issue: It's been used.


And yes it's code.


And yes, code has bugs


All begining is hard.


And  yes bitcoin is strong and will stay.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Lauda on January 30, 2017, 02:06:41 PM
"Bitcoin Unlimited is building the highest quality, most stable, Bitcoin client available. We have a strong commitment to quality and testing"
https://i.makeagif.com/media/10-01-2015/_sbYKw.gif

Where is all this 'quality' and 'testing' that they are speaking of?

Nice shill parade.
Who exactly are the shills? Known members of the community?  ::)

BU code seems to be recognized trash.
FTFY.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: d5000 on January 30, 2017, 02:51:59 PM
Until yesterday I was not totally against Bitcoin Unlimited - at a first glance it seems to be an attractive way to adapt block size to the needs of users and miners. But this event shows us that it's basically beta (or even alpha) software. And I really fear worse things could happen to BTC if BU really becomes the dominant chain, as after looking into the details even from my layman's view the consensus method could lead to different types of "attacks" from interest groups to rise or shrink the maximal block size.

Changes of this magnitude should really be tested and reviewed extensively.

For now, because of this event, I am again more in favour of the Core fraction, although I would prefer a conservative maximal block size increase of 10 or 20% per year.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Lauda on January 30, 2017, 03:08:39 PM
For now, because of this event, I am again more in favour of the Core fraction, although I would prefer a conservative maximal block size increase of 10 or 20% per year.
Most definitely. I'm certain that there would be a fair amount of support for a proposal (post SegWit) that increases it somewhere between 10-20% yearly. However, there is definitely going to be very little-to-no support for proposal such as the one from Luke-jr. That proposal even goes as far as reducing the current block size. :D


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: achow101 on January 30, 2017, 06:03:34 PM
Absolute nonsense.  Unless you are saying that a significant majority of all mining nodes are willing to accept a block larger than 1 megabyte (in which case it is Core that is trying to create a consensus split by refusing to accept the longest chain). No. In this case, a minority of miners would be willing to accept such a block.  As a result the valid chain would quickly grow longer.  Only those nodes foolish enough to accept and mine on top of an invalid block (such as so-called SPV miners) would be affected, and any miner dumb enough to accept an invalid block deserves to waste hash power on a dead chain.
...
No. Not in any real way, it couldn't.  That's a whole lot of FUD and nonsense.  If I didn't know better, I'd think you were just another sig ad spammer.
A fork most certainly could have happened because of the BU and SPV miners. Those miners make up nearly half of the entire hash rate of the network. If the SPV miners and BU miners began building on the invalid block, then there would be two branches that are just about the same length. As we have seen in the July 2015 fork, the SPV miners could accidentally cause this to happen. One chain would probably die off once the human operators got involved as happened with the July 2015 fork.

Now those miners should have learned from the July 2015 fork that SPV mining can be problematic, but I don't think any of them have stopped doing SPV mining. It really all depends on how their validation systems work, but such a scenario is entirely possible as we have seen in the past.

I apologize about some poor word choice in my earlier posts. I will fix them.



Most definitely. I'm certain that there would be a fair amount of support for a proposal (post SegWit) that increases it somewhere between 10-20% yearly. However, there is definitely going to be very little-to-no support for proposal such as the one from Luke-jr. That proposal even goes as far as reducing the current block size. :D
Supposedly Luke-Jr is going to modify it so that by the time the hard fork is predicted to be ready to activate, the period of the smaller blocks has already passed.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on January 30, 2017, 06:25:24 PM
A fork most certainly could have happened because of the BU and SPV miners. Those miners make up nearly half of the entire hash rate of the network. If the SPV miners and BU miners began building on the invalid block, then there would be two branches that are just about the same length. As we have seen in the July 2015 fork, the SPV miners could accidentally cause this to happen. One chain would probably die off once the human operators got involved as happened with the July 2015 fork.

it was disregarded in 3 seconds.. a new block would not have built ontop if it..
if it stupidly did. then the reject would "officially" be named an orphan event in your eyes because the reject becomes the parents of the child and the parent and child still end up being cast aside.

WAKE UP

stop making mountains out of mole hills about events that didnt happen and then you meandering into fake narratives of if's and maybes..
. especially when the real problem of the real non event.. which you worry about concerting a bilateral split, would have been caused only by CORES REACTION to the mole hill. by banning the nodes to make the mountain... not due simply to a reject/bad block/invalid block/orphan.

rejects occur alot. orphans happen too. but CORE banning NODES is what would cause bilateral forks.
however sticking to consensus would have just dropped the dodgy block and thats it.. no drama.. gone, forgot about, life moves on without it.. non event

CORE have set the 'banscore' biasedly high for this event. but its funny that core then went and blamed it on non-core nodes for why CORE had so much biased in such a non event.

Now those miners should have learned from the July 2015 fork that SPV mining can be problematic, but I don't think any of them have stopped doing SPV mining. It really all depends on how their validation systems work, but such a scenario is entirely possible as we have seen in the past.

I apologize about some poor word choice in my earlier posts. I will fix them.



Most definitely. I'm certain that there would be a fair amount of support for a proposal (post SegWit) that increases it somewhere between 10-20% yearly. However, there is definitely going to be very little-to-no support for proposal such as the one from Luke-jr. That proposal even goes as far as reducing the current block size. :D
Supposedly Luke-Jr is going to modify it so that by the time the hard fork is predicted to be ready to activate, the period of the smaller blocks has already passed.

both luke Jr and Gmaxwell are devising the worse methods of dynamic block implementation.. maybe not for the intention of breaking the chain to make a point.. but to just to scare people from wanting to accept them as the ruse to then pretend people dont want dynamic blocks..

EG here is a banana, but if i wipe it under my armpit after a sweaty game of tennis, i can make a banana lover decline wanting a banana and then tell the world banana's are now bad because banana lovers refuse to eat banana's.

Gmaxwell wants to mess with the block reward and luke wants to make blocks shrink.. both are silly and are going to fail the user desire.
lets delve into lukes idea.
if all nodes can accept 1.5mb blocks.. they by default wont reject a block of 0.75mb or an 'empty block'.. because bitcoins consensus in that activation is that anything under 1.5mb is acceptable. so there is no need to dowgrade nodes.
much like todays reality we dont need to downgrade nodes consensus rules if a pool decides to create 'empty blocks'

lets delve into gmaxwells desire of an idea.
if pools X wants to increase 25% the pool C makes block with 75% reward. and the the other 25% is handed over to the next block solver.
firstly messing with the block reward is dangerous, so using it as a ploy. makes a dynamic block more dangerous to get people confident about

but not to due with lack of desire for dynamic blocks, but for HOW they are implemented and what penalties/downsides the core devs decide to add to scare their sheep. its obvious even now what their insidious plan is.

like they said 'look the community asked for 2mb or even 4mb.. we are offering them 4mb weight and they are declining' - fully aware of why the community is declining 4mb weight.. but core devs not being ethical to admit the reason for not wanting 4mb of empty gesture


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: DannyHamilton on January 30, 2017, 07:30:49 PM
A fork most certainly could have happened because of the BU and SPV miners.

As I said, not in any real way, it couldn't.

Those miners make up nearly half of the entire hash rate of the network. If the SPV miners and BU miners began building on the invalid block, then there would be two branches that are just about the same length.

And the moment that the valid chain was 1 block longer than the invalid chain, all miners would abandon the invalid chain.  It might even happen sooner if people looked at what was happening and realized they were wasting time and resources.  Either way, it wouldn't have any real effect on the valid chain.

As we have seen in the July 2015 fork, the SPV miners could accidentally cause this to happen.

And they deserve to waste their time and resources on an invalid chain if they are dumb enough to mine on it.  It won't matter to me or anyone else on the valid chain.  Why should we care?

One chain would probably die off once the human operators got involved as happened with the July 2015 fork eventually, one way or another.

Fixed that for you.

Now those miners should have learned from the July 2015 fork that SPV mining can be problematic, but I don't think any of them have stopped doing SPV mining.

Then they are foolish.  A fool and his money are soon parted.  That's the way bitcoin (And the world) works.

It really all depends on how their validation systems work, but such a scenario is entirely possible as we have seen in the past.

A scenario where foolish people waste time and resources on a foolis endeavor?  Sure, it has happened throughout all of human history.  It isn't going to stop anytime soon.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: iCEBREAKER on February 01, 2017, 11:09:49 AM
Must see:

https://twitter.com/WhalePanda/status/826418860731535360

lol rekt  :D :D


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Carlton Banks on February 01, 2017, 11:36:17 AM
A fork most certainly could have happened because of the BU and SPV miners.

As I said, not in any real way, it couldn't.

Those miners make up nearly half of the entire hash rate of the network. If the SPV miners and BU miners began building on the invalid block, then there would be two branches that are just about the same length.

And the moment that the valid chain was 1 block longer than the invalid chain, all miners would abandon the invalid chain.  It might even happen sooner if people looked at what was happening and realized they were wasting time and resources.  Either way, it wouldn't have any real effect on the valid chain.

Riiiiiiiight. So you're saying that because only a minority of the hashrate chose the Unlimited fork, the design of BU doesn't massively lower the bar for those wishing to design and promote their own forks?

"If Bitcoin can't handle it, it was a failure to begin with"

Yes, but you're not talking about Bitcoin, you're talking about a Bitcoin fork. Bitcoin wasn't designed to let users provoke a fork with the GUI, that's how your Bitcoin fork BU was designed.

A fool and his money are soon parted.  That's the way bitcoin (And the world) works.

And if you proceed with your present course of action, you will be parted from yours. There is no value in a system that can be so easily denuded of it's Metcalffe network effect when it splinters into several forks per week.


So, I have a futures contract for you: I will sell you 0.2 ULC: 1 BTC, after any BU chainfork. I will buy in bulk. Generous offer, ends at the end of February.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Daedra on February 01, 2017, 11:47:12 AM
How could that have happened? ??? Seems those BU guys dont care of anything except their proceeds  :(


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Cubic Earth on February 01, 2017, 12:16:51 PM
Yes, but you're not talking about Bitcoin, you're talking about a Bitcoin fork. Bitcoin wasn't designed to let users provoke a fork with the GUI, that's how your Bitcoin fork BU was designed.

So much for Honey Badger, it seems bitcoin might have a serious flaw, if what you are saying is correct.
Much cheaper than a 51% attack. Just spin up a handful of non-conforming nodes and mine an invalid block. Boom! And Bitcoin is done for.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Invincible on February 01, 2017, 12:26:11 PM

So much for Honey Badger, it seems bitcoin might have a serious flaw, if what you are saying is correct.
Much cheaper than a 51% attack. Just spin up a handful of non-conforming nodes and mine an invalid block. Boom! And Bitcoin is done for.
People would deny fork as other alts


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Xester on February 01, 2017, 12:30:38 PM
I thought only Chinese Miners are using BU but according to the author and I read it clearly even Bitcoin.com is using BU in their mining activities. But I guess there is no wrong with it and the mining community should just be wary if an invalid block or a block that is considered illegal with pertains to consensus has been mined. The best thing for bitcoin.com to do is to specify in the contract with the miners that are mining under them that they are using BU. They must also specify the advantages and disadvantages this style of mining will give to the miners.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on February 01, 2017, 12:49:18 PM
Yes, but you're not talking about Bitcoin, you're talking about a Bitcoin fork. Bitcoin wasn't designed to let users provoke a fork with the GUI, that's how your Bitcoin fork BU was designed.

So much for Honey Badger, it seems bitcoin might have a serious flaw, if what you are saying is correct.
Much cheaper than a 51% attack. Just spin up a handful of non-conforming nodes and mine an invalid block. Boom! And Bitcoin is done for.

and yet this non event of just a reject occuring and thrown aside in 3 seconds. proves consensus works.

what would actually cause the bilateral split. is what core done next in this non-event. by over using the banscore tweaks to drop connections to NODES even when the nodes were not the cause.

leaving the connection open would have done no harm because core nodes already rejected the block.. and the block drama was over in 3 seconds.
but by dropping the connections aswell, they then no longer play by consensus rules and the two non-communicating nodes could end up following different data. because they no longer allow communication with each other to reject/accept the same data.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Foxpup on February 01, 2017, 01:02:13 PM
How could that have happened? ???
They changed the code that calculates the block size without understanding how it works, and pushed out the change without any review or testing. This is standard practice for Bitcoin Unlimited developers, and nobody is the least bit surprised that it blew up in their faces. It may be the first time Bitcoin Unlimited users have lost money as a direct result of the developers' incompetence, but it's unlikely to be the last.



leaving the connection open would have done no harm because core nodes already rejected the block..
It harms nodes with limited connection slots. Banning misbehaving nodes frees up slots for correctly behaving nodes. Any node that relays an invalid block is either defective or malicious, and there's no point in maintaining a connection to such nodes.

but by dropping the connections then no longer plays by consensus rules and the two non-communicating nodes could end up following different data. because they no longer allow communication with each other to reject/accept the same data.
They're already following different data, whether they're communicating or not. By definition, there can be no consensus when one node thinks a block is valid and another does not.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: Invincible on February 01, 2017, 01:03:13 PM

leaving the connection open would have done no harm because core nodes already rejected the block.. and the block drama was over in 3 seconds.

What I ask myself is why did BU nodes allow to screw themselves up, so core nodes should intervene to prevent a catastrophe. No sir, It doesn't characterise BU team as reliable profy


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: vapourminer on February 01, 2017, 01:09:04 PM
because the BU nodes were banned for 24 hours does this mean during that time that any pools that used BU and then found a valid block on the valid chain (assuming they switched to the valid chain eventually) would be lost as they could not broadcast it to the majority nodes?


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: ranochigo on February 01, 2017, 01:11:41 PM
because the BU nodes were banned for 24 hours does this mean during that time that any pools that used BU and then found a valid block on the valid chain (assuming they switched to the valid chain eventually) would be lost as they could not broadcast it to the majority nodes?
Likely not. Once the connection is dropped, the node will find another node to connect to. The ban doesn't apply to all the nodes in the network, each will have their individual ban list.

As long as the miner have at least a Core node connected, they should be fine.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: manselr on February 01, 2017, 01:14:07 PM
BU doesn't work. It sounds good in practice, "wow automatically adjusted blockchain? just what we need" but in practice it opens a can of worms. Too many possible attack vectors.

If it was as easy I would support a dynamic blocksize, I don't because there are big tradeoffs by doing so that I don't want to deal with. I want to be able to find my bitcoin on my wallet 20 years from now. BU does not give me that peace of mind. They will fuck up hard.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on February 01, 2017, 03:22:07 PM
What I ask myself is why did BU nodes allow to screw themselves up, so core nodes should intervene to prevent a catastrophe. No sir, It doesn't characterise BU team as reliable profy

it was a reject.
it would have always been a reject.
it was handled and pushed the side in 3 seconds.
it would have always been pushed the side in 3 seconds.

by the way
https://blockchain.info/orphaned-blocks
care to comment about the other rejects/orphans? that happen alot
oh wait they are core based. im guessing you wont comment


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on February 01, 2017, 03:27:43 PM
BU doesn't work. It sounds good in practice, "wow automatically adjusted blockchain? just what we need" but in practice it opens a can of worms. Too many possible attack vectors.

If it was as easy I would support a dynamic blocksize, I don't because there are big tradeoffs by doing so that I don't want to deal with. I want to be able to find my bitcoin on my wallet 20 years from now. BU does not give me that peace of mind. They will fuck up hard.

do you even understand bitcoin or consensus.

you do know funds are locked to private keys.
an orphan/reject cannot steal your funds.

but blockstreams future feature mimble wimble can.

its worth reading and learning

but start at the basics of consensus vs bilateral.
as thats what im seeing most r/bitcoin script readers and blocksteam king defenders are mainly not understanding. plus it doesnt take years to learn. so theres no excuse to not spend just 30 minutes learning about consensus(majority agreement stay together) vs bilateral(walk in separate direction splits)


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: TooDumbForBitcoin on February 01, 2017, 03:48:24 PM
Must see:

https://twitter.com/WhalePanda/status/826418860731535360

lol rekt  :D :D

Icebreaker is the last person I would expect to endorse a Peter R gif.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: manselr on February 01, 2017, 03:51:50 PM
BU doesn't work. It sounds good in practice, "wow automatically adjusted blockchain? just what we need" but in practice it opens a can of worms. Too many possible attack vectors.

If it was as easy I would support a dynamic blocksize, I don't because there are big tradeoffs by doing so that I don't want to deal with. I want to be able to find my bitcoin on my wallet 20 years from now. BU does not give me that peace of mind. They will fuck up hard.

do you even understand bitcoin or consensus.

you do know funds are locked to private keys.
an orphan/reject cannot steal your funds.

but blockstreams future feature mimble wimble can.

its worth reading and learning

but start at the basics of consensus vs bilateral.
as thats what im seeing most r/bitcoin script readers and blocksteam king defenders are mainly not understanding. plus it doesnt take years to learn. so theres no excuse to not spend just 30 minutes learning about consensus(majority agreement stay together) vs bilateral(walk in separate direction splits)

What I do know is BU is shit and nobody that wants to keep holding their digital gold for +1 decade is going to want any of those developers taking the main role of the network, jeopardizing their digital gold holdings by replacing a strong solid bunker with plastic elastic walls.


Title: Re: Bitcoin.com almost forks the blockchain with buggy BU
Post by: franky1 on February 01, 2017, 04:04:12 PM
taking the main role of the network,

if you think devs of any implementation should take the main role. you have already surrendered and missed out on what bitcoin is all about.

you have already given up your independence.
please learn consensus, redeem yourself