Gold collapsing. Bitcoin UP.

[jonny1000]

The consensus system I'm attempting to describe would follow the same chain that core follows up until the point when a block over 1MB is mined. From that point forward, the client will only follow a chain built upon that block. It would mark a distinct schism of the ledger.

We could call it the Luther Block.

So your node is happily following the Core chain, then one 1.1MB block is mined 10,000 blocks in the past, and that then becomes the valid chain and 10,000 blocks of history are undone based on one block?

 

[Richy_T]

If the 1MB chain got the lead, at any point ever, the 2MB chain would cease to exist and disappear. Investors would then lose their funds. Therefore, if there was not "perverted strong consensus bullshit" in the first place:

We have been over this before. The chance of such a reorg is small at 75% activation, merely resets the clock and in any case, quickly becomes irrelevant within the first hour or two as the better supported chain pulls ahead rapidly.

At this point, I think your purpose is simply to waste the time of those on this forum because as with so many small blockers (which I believe you to be despite your protestations), you keep coming back to the same old debunked bullshit over and over.

 

[Jonathan Vaage]

Medieval Todd and Maxwell don't look very happy. Haha

@jonny1000: Interesting point. Defecting miners would likely want to coordinate on an explicit designation. This would entail some entrepreneurial risk on the part of the miners. Since I don't think this can be formalized in code, I can understand why you might consider this outside the scope of a consensus system.

I'll defer to @Justus Ranvier's response:

The practical implication is that the separation between the two chains isn't really finished until the large block chain has a sufficient lead in terms of blocks to make a reorg extremely unlikely.

100 blocks is a good number to choose (coin maturation time), and you can calculate for yourselves how likely it is for a 25%/75% split to result in the 25% miners getting 100 blocks in a row.
[doublepost=1469808743][/doublepost]@Jonathan Vaage That modification is entirely unnecessary for clients, assuming a majority of hash power behind the fork.

Only the miners would need to do so, and only temporarily until they establish a sufficient lead over the minority chain.

 

[jonny1000]

How likely is it for a 25% miner to get 100 blocks in a row?

Why is it 100 blocks in a row? The smaller block 25% chain needs to get a lead at any time to win, this is a combinatorics problem and with 25% of the hash power the minority chain has c20% chance of overcoming a 1 block deficit and retaking the lead.

The chance of such a reorg is small at 75% activation, merely resets the clock and in any case, quickly becomes irrelevant within the first hour or two as the better supported chain pulls ahead rapidly.

Have you considered the financial markets aspect to this? Lets say there are investors and traders buying and selling each coin, in volatile, uncertain and speculative markets. If the small block chain begins to get price momentum the large blockers may start to panic, knowing if the price approaches parity the large block chain could eventually disappear. This would give the small block chain a massive advantage in trader/investor sentiment.
[doublepost=1469811052][/doublepost]

The practical implication is that the separation between the two chains isn't really finished until the large block chain has a sufficient lead in terms of blocks to make a reorg extremely unlikely.

100 blocks is a good number to choose

Please can you explain this in more detail. What happens if the larger block chain has fewer than 100 confirmations? Why do you call it a lead, if the lead reached 101 and then falls to 99 again, what is the impact of this?

 

[Justus Ranvier]

How to use a soft fork to ensure the success of a hard fork

1. Get a majority of miners, investors, and businesses to agree to produce and accept >1 MB blocks.
2. Schedule the production of the first > 1 MB block in advance and informal all parties in advance that from the time the hard fork begins until it is complete, users should temporarily require more confirmations (recommended: 100) on incoming transactions.
3. Miners should modify their software to allow the enforcing of soft fork rules in the form: "the hash of the block at height x must equal y" and allow these rules to be inserted at runtime.
4. Once the first >1MB block has been mined, miners begin enforcing the appropriate soft fork rule.
5. After the generation output of the first large block has matured (100 blocks), the fork can be considered over and the soft fork rule is no longer necessary.

Nobody should have any objection to this procedure, since as we all know soft forks are perfectly acceptable ways to change consensus rules.
[doublepost=1469811622][/doublepost]@jonny1000 If 75% of miners are extending the large block chain, their chain will accumulate 3x as much proof of work as the small block chain over the long term.

Random short term variance can cause the small block chain to appear to accumulate work faster than the large block chain, but this is an illusion.

As long as the miners producing the large block chain avoid reorging to the small block chain long enough for their natural advantage in hashing power to overwhelm random variances, they are in no danger of ever losing their chain for as long as they retain more hashing power than the small block chain.

 

[jonny1000]

1. Get a majority of miners, investors, and businesses to agree to produce and accept >1 MB blocks.
2. Schedule the production of the first > 1 MB block in advance and informal all parties in advance that from the time the hard fork begins until it is complete, users should temporarily require more confirmations (recommended: 100) on incoming transactions.
3. Miners should modify their software to allow the enforcing of soft fork rules in the form: "the hash of the block at height x must equal y" and allow these rules to be inserted at runtime.
4. Once the first >1MB block has been mined, miners begin enforcing the appropriate soft fork rule.
5. After the generation output of the first large block has matured (100 blocks), the fork can be considered over and the soft fork rule is no longer necessary.

Nobody should have any objection to this procedure, since as we all know soft forks are perfectly acceptable ways to change consensus rules.

Ok, so the 100 blocks thing is not a rule or anything, its just some recommended behavior that people adopt (I think this is not necessary). This "Soft Harfork" idea is good and exactly how the Core team intend to do their hardfork to 2MB of non witness data. It is great that you agree with this. I particularly like you first step about getting a majority of all those groups, it sounds a lot like strong consensus.

I do not get why the softfork rule should be enforced after the first >1MB block, instead of well before?

Please let me explain my view of how to safely do the hardfork:

1. A softfork is activated (using the normal mechanism), the softfork says that all blocks which do not flag support for blocks >1MB and do not say they have upgraded to the HF client are invalid

2. c150,000 blocks after the softfork activates, the hardfork activates and the blocksize limit is increased

This ensures all exchanges and users should be able to continue to use the network smoothly, without having 100 blocks of downtime

 

[Justus Ranvier]

Thanks for confirming that you've been lying about "strong consensus" all this time.

You've been concern trolling about the 75% BIP activation threshold when you knew perfectly well that it's more than sufficient.

You're just here to waste our time and to discourage anyone who's trying to save Bticoin from the Core monopoly.

 

[Roger_Murdock]

Thought this was a pretty good analogy:

 

[freetrader]

This "Soft Harfork" idea is good and exactly how the Core team intend to do their hardfork to 2MB of non witness data.

Has this been publicly discussed anywhere?
Can you point us to a link?

 

[Justus Ranvier]

@freetrader They were waiting for someone else to solve the problem for them so they can claim credit for it.

 

[jonny1000]

As long as the miners producing the large block chain avoid reorging to the small block chain

If they avoid reorging to the smaller block chain, even if the smaller blockchain has more work, then that is not the Classic/XT node I strongly oppose. I will need to wait and see the specifications of this new idea you are advocating.

 

[Justus Ranvier]

This "Soft Harfork" idea is good and exactly how the Core team intend to do their hardfork to 2MB of non witness data.

I will need to wait and see the specifications of this new idea you are advocating.

You seem to have trouble keeping your story straight. Do you have multiple personality syndrome?

 

[Norway]

Steve Huffman, CEO of Reddit Fireside Chat with Brian Armstrong, CEO of Coinbase, July 13, 2016. Brian starts talking about Theymos here (12:02):

 

[freetrader]

@Justus Ranvier : I've seen mention of multiple developer meetings re: the HF, but none of the results of these meetings have been publicized. It would be very interesting if such a decision had in fact been taken, and the first we hear about it is from @jonny1000 on this forum.

@jonny1000, you are speaking for the Core team in quite a firm manner with that statement. Will you stand behind your statement and point us to the public source?

 

[jonny1000]

jonny1000 said: This "Soft Harfork" idea is good and exactly how the Core team intend to do their hardfork to 2MB of non witness data.

Has this been publicly discussed anywhere?
Can you point us to a link?

Several high profile Core devs mentioned this to me in person. However they mentioned the priority was preventing a HF like Classic without consensus first. I have also mentioned it in this thread before.

We should do a Soft-hardfork, like Core may be planning to do for their 2MB hardfork. What will happen is a new version number will be softforked in at a 95% threshold, once activated miners will refuse to build on blocks which do not comply with this version number, then it will have 100% of the hashrate. Then several months later the hardfork to 2MB will be live and there is no question of miners not having upgraded as 100% of the miners will now enforce this new rule due to the softfork, well before the first 1.01MB block and the actual hardfork.

As for links to public discussion:

Threshold is 95%. Using 4 versoin bits: a) BIP 141; b) BIP HF; c) BIP 141
if BIP HF has already got 95%; d) BIP HF if BIP141 has already got 95%.
Voting a and c (or b and d) at the same time is invalid. BIP 141 is
activated if a>95% or (a+c>95% and b+d>95%). BIP HF is activated if b>95% or
(a+c>95% and b+d>95%).

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012404.html

 

[Norway]

You seem to have trouble keeping your story straight. Do you have multiple personality syndrome?

Maybe they are different persons. My mother actually almost got scammed by nigerian scammers working dating pages for people 60+ in Norway.

After a while, she discovered that they were multiple people behind the handsome, wealthy man moniker.

Wouldn't be supprised if @jonny1000's account is run the same way.

 

[freetrader]

Several high profile Core devs mentioned this to me in person.

@jonny1000 : Ok. So you're making such a prediction for Core here based on hearsay. The linked discussion doesn't propose what @Justus Ranvier proposed, indeed it only seem tangentially related. Thanks for the link anyway, I guess.

 

[jonny1000]

You seem to have trouble keeping your story straight. Do you have multiple personality syndrome?

What story straight? These are different things. The Core team are planning on a "Soft-Hardfork" in the way I described, not the way you described where both the soft and hard bit happen at the same time.

[doublepost=1469813823][/doublepost]

@jonny1000 : Ok. So you're making such a prediction for Core here based on hearsay.
The linked discussion doesn't propose what @Justus Ranvier proposed, indeed it only seem tangentially related. Thanks for the link anyway, I guess.

Based on discussions with Core developers, including the most prominent ones and comments on the forum where the developers chat. I think it is highly likely this methodology will be used. It proposes a Soft-Hardfork like how I mentioned on this forum on 6th June. It seems similar to what Justus is saying, but I do not fully understand his method, especially why the softfork and hardfork happen at the same time.

 

[Aquent]

I think it's time to end all this "rubbish." Fundamentally, we all share same interests, just have different opinions on some aspects, but, we are still one family. I think it's time we all recognize we have different views, accept that, accept we still share so much in common, and move on.

We've been debating for more than a year now and we have nothing to show for it excepted for wasted time and resources and stagnation in the entire bitcoin space. Just, move on. You want whatever? Who you asking permission of?

Lets declare peace! You want a hierarchical system of sidechains, lightning, whatever... fine. No one can currently say it is wrong. You want on-chain scaling? Fine, go ETH, or fork.

Whoever wishes to fork is free to do so for that is inbuilt in bitcoin's system. Whoever wishes to proclaim 1mb forever is too free to do so for that's the definition of permissionless and whoever wishes to choose the more practical path of ETH should be welcomed. Free market and free choice for all. No one in this space can be imposed. Just focus on your path, work on it and build stuff. Tis for history to say which choice is right, not for endless words that, at this point, persuade no one, but waste the time of all.

 

[Zangelbert Bingledack]

@jonny1000 @Justus Ranvier

A hard fork to 2MB with a change in the PoW algorithm would be symmetric, wouldn't it? I'm supposed to be somewhere in a moment so no time to think it through, but in any case it seems to me what we want is a ledger-copy/spinoff (perhaps this is functionally identical to a symmetric fork).

If @jonny1000's problem with Classic is the assymetry and "only assymetric forks require strong consensus," isn't it then just a matter of making the fork symmetric? I'm not very interested in methods that require a majority, in general, because even if we can get a majority now there will be times in the future we cannot.