Gold collapsing. Bitcoin UP.

[albin]

Just to be clear is everyone here in agreement on the definition of a softfork and hardfork?

• Softfork - A change to the rules on block validity, such that if exisiting nodes do not upgrade, they will still regard the new blocks as valid
• Hardfork - A change to the rules on block validity, such that if exisiting nodes do not upgrade, they will may not regard the new blocks as valid

Now this troll gets to reboot the entire dead horse again by patronizing us.

 

[pekatete]

[doublepost=1465651732][/doublepost]

What about the 85% of non mining nodes, what is your excuse for that?

Which 85% are you referring to? The ones running Core 0.12.1?
[doublepost=1465655616][/doublepost]

Just to be clear is everyone here in agreement on the definition of a softfork and hardfork?

• Softfork - A change to the rules on block validity, such that if exisiting nodes do not upgrade, they will still regard the new blocks as valid
• Hardfork - A change to the rules on block validity, such that if exisiting nodes do not upgrade, they will may not regard the new blocks as valid

Elephant in the room is, are you clear about that kore gang definition? Last I checked you definitely were not clear on it, or you keep changing stances whenever it suits you.

 

[Dusty]

I keep repeating, this should occur when the attempt to change the rules without consensus becomes insignificant. We are getting close to that point, that is why I am commetning a lot. During an attempt to HF without consensus, the community should rally behind the existing rules.

You seems to imply that consensus can be obtained only with changes proposed by Kore. Why is that?

 

[freetrader]

Now this troll gets to reboot the entire dead horse again by patronizing us.

Beep code: 1-1-1-3 Verify Real Mode.

 

[cypherdoc]

But we're not having a technical debate, in case you haven't noticed. It's a political debate. 95 vs 75% is your deconstruction of this matter (so stated) , which I think it's ridiculous because we have not heard one member of the mining community nor kore dev, for that matter, who's ever mentioned this as a key determinant.

If you want to criticize my charecter, rather than the technical content of my comments, that is fine. I graciously accept and agree with any negative comments you have about my charecter. I only seek to discuss the issue with those interested in finding the truth based on technical merit.

[doublepost=1465659181,1465658581][/doublepost]Exactly right. Kore dev would certainly claim that they alone represent at least 5% of the community, or that they believe they can influence at least 5%of miners, which will always ensure they stay in power. This is the real push behind 95 %consensus.

You seems to imply that consensus can be obtained only with changes proposed by Kore. Why is that?

 

[taxed4ever]

Core has displayed the most hostile and damaging tactics I have ever witnessed in business.

 

[AdrianX]

@jonny1000 :

I realize you're being very civil here in your attempts to persuade us, but if you come here to propose a hardfork to 2MB with any sort of consensus, you have to show that Core is actually capable of that.

Right now, hard forking seems to be quite controversial in the Core camp, and we know what Adam Back says about controversial hard forks - they CANNOT happen.

I heartily recommend a re-read of /u/ytdm's post from a while back on the subject:

https://np.reddit.com/r/btc/comments/46052e/adam_back_greg_maxwell_are_experts_in_mathematics/

You're overlooking how hard forks happen as reviewed in my last reply to your misunderstanding.

It's also worth noting that the biggest objection is actually the political controversy propagated by Core.

It's a political block using among other things FUD and censorship and PR to prevent the network form evolving.

 

[Erdogan]

One nice thing with the halving, is that afterwards, the risk of loss with an orphaned large block is almost cut in half.

 

[79b79aa8]

except of course if price doubles.

 

[Erdogan]

Oh shit that must never happen...

 

[freetrader]

You're overlooking how hard forks happen as reviewed in my last reply to your misunderstanding.

I tried hard to find that reply, but failed (is this thread getting too big ?
Anyway, if you could be so kind to point me at it I'll ponder my misunderstanding...

 

[jonny1000]

You seems to imply that consensus can be obtained only with changes proposed by Kore

I do not think that nor have I ever implied that. You are just misunderstanding what I am saying.
[doublepost=1465668840][/doublepost]

that they believe they can influence at least 5%of miners, which will always ensure they stay in power

Stop conflating the issues of a development team being "in power" and a HF. These things are separate. Conflating them is false, misleading and counterproductive. The team "in power" is decided by compatible software people choose to run. Competition between teams is healthy, stop spreading false and divisive rumours that small blockers do not want this competition. A HF can only occur with consensus across the entire community, including any significant node software development team with a significant market share.

One of the advantages of competing software teams is that many teams may need to agree before a HF, making the system more robust.

You probably disagree with this, which is fine, but stop misrepresenting what the opposing view is.

 

[AdrianX]

Stop spreading false, counterproductive, malicous and divisive rumours. Even if that was true, run another compaitible implementation. Once Core market share is low, then the new team can HF, with consensus across the enitire community. If the old Core team oppose it, they could be insigificant.
[doublepost=1465650303][/doublepost]

Stop confusing want you want and fact:
1. 51% of the miners is mechnically not sufficient to HF - This is a fact
2. You would like 51% of the miners to be sufficient to do a HF - This is an opinion

If you use the grace period that Satoshi chose, rather than 28 days, that would be much better.

I'm beginning to understand your argument. I think you're coming around to the fact that those supporting a hard fork to move the block limit, while not your 95% majority are corect. And the opposition is largely irrelevant.

You're advocating (more like begging) those who support a limit increase to stop supporting it until such time as the Core centralized authority says it's acceptable. Then they can claim extreme consensus and legitimately move the limit.
[doublepost=1465669639][/doublepost]

Just to be clear is everyone here in agreement on the definition of a softfork and hardfork?

• Softfork - A change to the rules on block validity, such that if exisiting nodes do not upgrade, they will still regard the new blocks as valid
• Hardfork - A change to the rules on block validity, such that if exisiting nodes do not upgrade, they will may not regard the new blocks as valid

No. you still seem unsure. The case in point is the implementation of the block size limit as a consensus rule. It's a hard fork rule.

 

[jonny1000]

"You're advocating (more like begging) those who support a limit increase to stop supporting it until such time as the Core centralized authority says it's acceptable."

You can still support a block size limit increase. I support it now and always have done. I am asking you to stop supporting the activation of the increase on the network until there is consensus across the entire community.

 

[pekatete]

Stop conflating the issues of a development team being "in power" and a HF. These things are separate. Conflating them is false, misleading and counterproductive. The team "in power" is decided by compatible software people choose to run. Competition between teams is healthy, stop spreading false and divisive rumours that small blockers do not want this competition. A HF can only occur with consensus across the entire community, including any significant node software development team with a significant market share.

One of the advantages of competing software teams is that many teams may need to agree before a HF, making the system more robust.

The only person conflating those two issue here is you. You do it by incorrectly accusing others of conflating those two issues, I suppose in your pathetic way as a means of appeasing the lurkers.

And yes, all you small blockers, more especially your supreme junta loaded with dipshits, are totally averse to viable competing clients, tagging them "attacks on bitcoin" and sorts at every single turn, monopolising contributing to the source code and demonising each and any optimisation that could make the system more robust not originating from within the junta.
In the meantime, YOU come here and pay lip-service to those very deficiencies within the junta.

 

[AdrianX]

I tried hard to find that reply, but failed (is this thread getting too big ?
Anyway, if you could be so kind to point me at it I'll ponder my misunderstanding...

It was meant for @jonny1000

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-620#post-22000
[doublepost=1465671471][/doublepost]

"You're advocating (more like begging) those who support a limit increase to stop supporting it until such time as the Core centralized authority says it's acceptable."

You can still support a block size limit increase. I support it now and always have done. I am asking you to stop supporting the activation of the increase on the network until there is consensus across the entire community.

Nonsense the only support that matters are your actions, political will is nothing.

As I've been saying it's literally 100% supported after the fork or it isn't. A fork to remove the limit comes about the exact same way it was introduced. The obstruction is your insistence on your version of extreme consensus.

 

[freetrader]

You can still support a block size limit increase. I support it now and always have done. I am asking you to stop supporting the activation of the increase on the network until there is consensus across the entire community.

@jonny1000 :

I disapprove of what you say, but I will defend to the death your right to say it

I hereby declare that I do not agree with any block size limit increase⁺.
But I will defend the right of others to hard-fork as they see fit.

As a nod to their rights, I shall release a hard fork which increases the block size limit, without consenting to its activation on the network myself (just like you ask)⁺⁺.

I trust Core and Blockstream will controversialize such forks, which according to their doctrine⁺⁺⁺ ensures that such forks CANNOT happen - ergo: all will be well.

I have a proof that this plan cannot possibly fail to please everyone, but the margins of this forum are too small to contain it.

⁺psst, ∞
⁺⁺who the fuck do you think I am, that you need my consent?
⁺⁺⁺Back-ward logic

 

[jonny1000]

And yes, all you small blockers, more especially your supreme junta loaded with dipshits, are totally averse to viable competing clients,

This is false. Please stop misrepresenting our position. Read my view below in black and white:

I support competing compatible clients

Was that clear enough for you?
[doublepost=1465673127][/doublepost]

Still by your definition at some point the limited transaction volume rule stopped being a soft fork and it became a hard fork rule

The 1MB limit rule was a softfork imposed on the network. At some point removing this becomes a hardfork. We can discuss the techicaliites of this if you want. Was it before the majorty of nodes adopted the rule? 1 block after the rule became active? 2 blocks after the rule became active? 6 blocks after the rule became active? I do not know, but what is clear is several years later, the 1MB rule is adopted by the network and removing now is a hardfork.
[doublepost=1465673368][/doublepost]

As a nod to their rights, I shall release a hard fork which increases the block size limit

That is fine, you are unlikey to get any significant support. In the event that your hardfork has no mechanism or deisre to ensure activation occus with strong consensus and your fork gets significant support, that should cause the community to rally behind the exisiting rules. That should not be a problem because:

1. Support will eventually fall to insignifant levels and then we can do a HF, or
2. If support remains significant, the consensus rules will not be eliminated, but Bitcoin remains flexible since we can do almost anything with softforks

 

[pekatete]

Can I just draw your attention to this: I support competing compatible clients is not the same as: I support viable competing clients.

But as always, I am not surprised you can not give a clear opinion, that and / or your pedantic positions on otherwise straight forward issues.

 

[Peter R]

This is false. Please stop misrepresenting our position. Read my view below in black and white:

I support competing compatible clients

Was that clear enough for you?

I can't remember if this means you support Bitcoin Unlimited or not. BU is compatible with both Core and Classic (regardless of whether the fork activates) and will follow the longest PoW chain composed of valid transactions.

Do you support node operators proactively (and asynchronously) increasing the size of blocks their node will accept?