Gold collapsing. Bitcoin UP.

[satoshis_sockpuppet]

https://pbs.twimg.com/media/Cw8z0sjXgAEiL0S.jpg:large

I like how Bitcoin Unlimited is seen as just "Bitcoin".

 

[AdrianX]

@satoshis_sockpuppet that's just the way it is I hope it's not a graphic glitch as BS/Core could get the same treatment when it fades away.

@jonny1000 stick to mining in the ground. Bitcoin mining only pays if you mine a block that's accepted by the network. Until you convince me why a miner should mine on top an orphaned block there is nothing to talk about.

 

[albin]

I take that all to mean, that in the above scenario, you don't know what chain a new BU node will build on?

I am convinced it's the blue one, but when I ask these basic questions you guys just waffle on without understanding how, why or if BU nodes (Even with the same AD and EB values) converge on the same chain.

It's contingent upon the settings of the node, but cut the shit please, we know you know that, and this is all an effort to confuse people into thinking that the intended behavior of BU is a bug.

 

[Peter R]

@jonny1000:

For the last few days, you were claiming that a miner mining 1 block on the small-block chain could cause BU nodes to orphan 3 blocks on the large-block chain and thus BU was broken. I showed that this is not true and I think you even agree now.

Before we move on to your entirely different argument for why you still think BU is broken, can you please say "yeah OK I was wrong, a miner mining a new block on the small-block chain will NOT cause BU nodes to orphan three blocks on the big-block chain."

 

[solex]

Bitcoin Unlimited will become even more busy over the next few months with lots of projects underway, as the following BUIPs have been passed by the membership:

Technical
BUIP023: Miner block creation latency optimization [funded]
BUIP033: Parallel Validation

Operational
BUIP034: Ecosystem Outreach for Onchain Scaling [funded]
BUIP035: New Bitcoin Unlimited Website [funded]

Membership
BUIP036: New Members for Election #3

Congratulations to @deadalnix, @jcliff and @Richy_T as new members. Welcome aboard!

More draft BUIPs are always invited. This was the last vote of 2016 with the next likely in January.

 

[jonny1000]

Until you convince me why a miner should mine on top an orphaned block there is nothing to talk about.

Because that is how BU nodes are configured to automatically act. If you want the human mining operator to manually check the economic and social merit before building on each block that is not Bitcoin, not unique nor is it convergent.
[doublepost=1478911095][/doublepost]

It's contingent upon the settings of the node

AD = 4 and EB =1...
[doublepost=1478911375][/doublepost]

@jonny1000:

For the last few days, you were claiming that a miner mining 1 block on the small-block chain could cause BU nodes to orphan 3 blocks on the large-block chain and thus BU was broken. I showed that this is not true and I think you even agree now.

Before we move on to your entirely different argument for why you still think BU is broken, can you please say "yeah OK I was wrong, a miner mining a new block on the small-block chain will NOT cause BU nodes to orphan three blocks on the big-block chain."

I have not been claiming this for a few days, but several months.

To clarify again, I still do claim that:

"a miner mining 1 block on the small-block chain could cause BU nodes to orphan 3 blocks on the large-block chain"

The scenario is the one you drew in the diagram, with the blue block orphaning 3 blocks.

Please can you kindly show me this is wrong. I think I missed this part of your comments. Especially from the perspective of a new node joining the network right after the blue block is mined.

 

[Peter R]

@jonny1000 said: "To clarify again, I still do claim that: a miner mining 1 block on the small-block chain could cause BU nodes to orphan 3 blocks on the large-block chain. The scenario is the one you drew in the diagram, with the blue block orphaning 3 blocks. Please can you kindly show me this is wrong."

This doesn't happen though. If the nodes learn of the blue block after the nodes have switched over to the new chain tip THE NODES DO NOT ORPHAN THREE BLOCKS like you claim. The blue block is essentially ignored.

But I don't know how I can "show" you that your claim is wrong beyond what I've already done. Go read the code I guess, or simulate it on testnet and see for yourself.

"Especially from the perspective of a new node joining the network right after the blue block is mined."

We can talk about this once you can grasp the simpler scenario above.

 

[solex]

Satoshi is equally clear:

It is strictly necessary that the longest chain is always considered the valid
one. Nodes that were present may remember that one branch was there first and
got replaced by another, but there would be no way for them to convince those
who were not present of this. We can't have subfactions of nodes that cling to
one branch that they think was first, others that saw another branch first, and
others that joined later and never saw what happened. The CPU power
proof-of-work vote must have the final say. The only way for everyone to stay
on the same page is to believe that the longest chain is always the valid one,
no matter what.

My emphasis. Miners that cling to the blue block are in a subfaction.

 

[jonny1000]

If the blue block is mined after the nodes have switched over to the new chain tip THE NODES DO NOT ORPHAN THREE BLOCKS like you claim. The blue block is essentially ignored.

"After" the nodes have switched over to the new chain, according to what? There are two ways (I can think of) of determining whether the blue or green block came first:

1. Looking at the timestamps in blocks
2. Each node keeping a record of which one it received and validated first

The point of proof of work(PoW) in Bitcoin is to determine the order of blocks, if either of the above two things worked, we wouldn't need PoW, we could just use timestamps or the order the blocks came in. Timestamps can easily be gamed and nodes do not have consensus of the order they received conflicting blocks. That is why I gave the example of a new node joining the network, since this node doesn't have the order it received historic blocks, its an obvious example that this mechanism doesn't work.

My emphasis. Miners that cling to the blue block are in a subfaction.

Great quote Solex. This really gets to the point, we should not create a client e.g. BU, that has these "subfactions", which Satoshi designed the system to avoid.

 

[Roger_Murdock]

"After" the nodes have switched over to the new chain, according to what?

"After" according to your hypothetical which imagined a scenario in which the mining of 1 block on the small-block chain could cause BU nodes to orphan 3 blocks on the large-block chain. And again, that scenario reflected a misunderstanding of how BU actually works.

But to clarify a subtle point about how BU's AD setting works, even if the blue block in that bottom right diagram were mined / seen by your node prior to the green block, the green block would still become your chain tip upon being mined. (The key point here is that your AD isn't "triggered" by an excessive-block-containing chain achieving a "lead" of AD blocks over a competitor chain; instead, once the requisite number of blocks have been built on an excessive block, that chain becomes an accepted candidate for the longest valid chain.)

Great quote Solex. This really gets to the point, we should not create a client e.g. BU, that has these "subfactions", which Satoshi designed the system to avoid.

It is a great quote, but you seem to have missed the point. It is those individuals running Core who risk becoming part of a "subfaction" by refusing to accept the validity of the longest chain.

 

[Peter R]

"After" the nodes have switched over to the new chain, according to what? There are two ways (I can think of) of determining whether the blue or green block came first:

1. Looking at the timestamps in blocks
2. Each node keeping a record of which one it received and validated first

#2.
More precisely: If the nodes learn of the blue block after the nodes have switched over to the new chain tip THE NODES DO NOT ORPHAN THREE BLOCKS like you claim. The blue block is essentially ignored.

Do you still think that BU nodes will orphan three blocks on the large-block chain if the blue block is mined on the small-block chain?

 

[jonny1000]

But to clarify a subtle point about how BU's AD setting works, even if the blue block in that bottom right diagram were mined / seen by your node prior to the green block, the green block would still become your chain tip upon being mined. (The key point here is that your AD isn't "triggered" by an excessive-block-containing chain achieving a "lead" of AD blocks over a competitor chain; instead, once the requisite number of blocks have been built on an excessive block, that chain becomes an accepted candidate for the longest valid chain.)

Ok, I have had a quick review of the BU code, and I think this is correct. It seems the client finds the longest chain regardless of blocksize, then does a loop to keep checking historic blocks are not EB, until the loop has been done AD times. Is this correct, this is not how BU was explained to me. This makes more sense. This way BU nodes with the same AD and EB settings should converge with each other, right?

#2.
More precisely: If the nodes learn of the blue block after the nodes have switched over to the new chain tip THE NODES DO NOT ORPHAN THREE BLOCKS like you claim. The blue block is essentially ignored.

It looks like this is not the case. The order between the blue and green blocks appears not to matter in this scenario. Is this correct?

 

[awemany]

@jonny1000: Maybe I am missing something here, but isn't this just basic Nakamoto consensus stuff? If the blue block appears after the two gray blocks, the red + gray chain still is the longest (as in has the most proof of work) and stays valid?

Of course, there are scenarios where a block is orphaned. But that's the case today as well. Your point being?

Asymptotically, the mining decides whether a block is in the longest chain, or whether it is not. With exponentially increasing likelihood over time. That is the core insight from Satoshi. That eventual, probabilistic consensus is found.

You (and I guess quite a few of the other 'consensus fetish' small blockers) seem to have a hang-up on the 'asymptotically'. Yet that is the whole frickin' basis on which Bitcoin works!

 

[Peter R]

It looks like this is not the case. The order between the blue and green blocks appears not to matter in this scenario. Is this correct?

If the node learns of the blue block first, then the blue block will briefly become the chain tip. Later, when the node learns of the green block, the blue block will be orphaned and the green block will become the new chain tip. On the other hand, if the green block comes first, the blue block will never be the chain tip; the blue block will essentially be ignored. Unlike what you were claiming, it will not cause three blocks to be orphaned.

 

[theZerg]

He never bothered to learn how it works even after almost a year. He just makes guesses and assumptions and then forces us through trolling to engage in what's got to be the least efficient educational process possible.

 

[Bagatell]

jonny's a troll. Starve him.

 

[albin]

I'm sure he does know how it works, he's just setting up an elaborate strawman to confuse people about BUIP001 in the first place. I would put my money on the notion that he's playing to lurkers who landed here interested in finding out more about BU.

 

[jonny1000]

If the node learns of the blue block first, then the blue block will briefly become the chain tip. Later, when the node learns of the green block, the blue block will be orphaned and the green block will become the new chain tip. On the other hand, if the green block comes first, the blue block will never be the chain tip; the blue block will essentially be ignored

Ok I see, this seems interesting. Can we try to get this tested on an altcoin or sidechain first? Before pushing for this experimental change to convergence go on the main chain.?
[doublepost=1479006195][/doublepost]

He never bothered to learn how it works even after almost a year.

Yes I finally read through the BU main.cpp file yesterday, as the communication ect was contradictory or poorly informed

 

[Peter R]

Before I deal with your next round of FUD, I need to make sure that we're actually getting somewhere. Do you now agree that your earlier claim was wrong? Do you now agree that mining a single block on the small-block chain will NOT orphan three blocks on the big-block chain?

Now moving on: Do you think Bitcoin Unlimited has stronger, weaker or the same convergence guarantees as Bitcoin Core?

 

[jonny1000]

it will not cause three blocks to be orphaned.

One block can orphan three, even with normal Nakamoto consensus. With Nakamoto consensus this can only happen when a new chain "takes the lead" and becomes longer. With BU one block can orphan three in more ways, for example not when "taking the lead" but when already in the lead.

Now you may say this doesn't matter, as user wallets will let them know. I kindly ask you get SPV wallets to implement this first, rather than pushing BU on the network now. Oh wait, I thought you hardforkers didn't want SPV wallets to upgrade.

Now moving on: Do you think Bitcoin Unlimited has stronger, weaker or the same convergence guarantees as Bitcoin Core?

Obviously weaker. Because different BU clients will still be mining on shorter chains, for some periods of time.

Do you now agree that your earlier claim was wrong?

Yes, after reading the code, I now cannot see how a shorter chain can orphan a longer one, with BU