Gold collapsing. Bitcoin UP.

jonny1000

Active Member
Nov 11, 2015
380
101
Yes I have. Including the comments about the untested random walk model. Why introduce a new unprove consensus system. Can we please not just increase the blocksize?


[doublepost=1476282488][/doublepost]
The dowside of this perverted nakamoto consensus (5% Veto right to a group of vandals) is, that progress cannot happen. Of course you know that already.
But why give Core the massive asymetric advantage by allowing them to wipe away the BU history, when BU cannot wipe away Core's history? At least make is symmetric then more people may support BU, since many do not want to be on the losing side. Please let me know the disadvantage of removing this large advantage for Core? Or do you people hate me so much for trying to make the hardfork safer and more successful, that you are not even willing to consider this? Please at least hear me out and let me explain why giving Core this asymmetric advantage is so compelling for speculators.

As for 95%, I just have a different vision. I think once you get to 75% the case you can make to the remaining 20% is quite compelling. Just think of 95% as a tactic to get miner support, with a successful track record. If you do not agree with this, please do not use offensive language like perverted.

For example, if hypothetically the SegWit blocksize increase reaches 75%. A strong case can be made to the remaining 25% about joining the majority, they would have too be very desperate to block the the blocksize increase at that point and the pressure could mount for months.

Despite the hatred I receive, I know I am making some progress and some of you are listening. Thanks very much for removing the BIP109 false flag, so that you guys are no longer attacking/tricking you "own side"
 
Last edited:

jonny1000

Active Member
Nov 11, 2015
380
101
Bitcoin.com and BU getting "very huge" are two very different things. Perhaps you do not understand the immense pressure miners are under to just break even, let alone make a profit. Pulling a stunt like this would be an extremely dangerous move for a pool. How exactly would it pay them back in the long run?
They would be buying Core coins or even just double spending.
[doublepost=1476285028][/doublepost]
@jonny1000 You need to remember that BU hasn't actually done anything that isn't already possible. They've simply moved the blocksize parameter from the compiled source code to a variable that can be set by the GUI. That is it! If the Bitcoin ecosystem continues to grow then these types of client modifications will inevitably become common-place and system will need to be able to deal with it. You cannot stop this.
Agreed. That is why I in principle support BU, I just disagree with the default parameters.
[doublepost=1476285109][/doublepost]
And maybe it's time for some people to rethink their assessment of "Chinese" miners. And the alleged culture of leaders and followers. Repeated before, but the most anti-bitcoin pools/miners are Bitfury and BTCC, both lead by people from "the west".
Please be respectful of the ethnicity. None of the problems on ether side are caused by "Chinese culture".
[doublepost=1476285276][/doublepost]
The quoted question is just more trolling again. The author has already give us the answer answer to his question and that is it requires we have 98% agreement on what is safe and what is possible. He may have changed his opinion to 100% - if he has he is welcome to correct me.

A better question to ask is: What is the downside of making the hardfork to increase the blocksize limit practically safe? and I feel confident everyone here agrees the answer is: nothing.
Ok so you do not like a threshold of 90% or more. Would at least 75% be ok?

Also why not remove Core's asymmetric advantage? This makes the hardfork very dangerous, yet nobody has told me any disadvantage of removing it by adding a checkpoint.
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
Thinking through the dynamics of a Segwit soft fork.

Say a Segwit soft fork activates on the network with (for example) 75% support. To the 25% of miners who do not support Segwit, the Segwit outputs appear as "ANYONECANPAY". This creates a danger for this 25% of miner is that if they include a transaction in their block that spends one of these outputs, but does not conform to Segwit rules, then that block would be orphaned by the Segwit-supporting miners. This puts pressure on them to join the 75% majority and support Segwit.

However, another defense for them is to simply exclude all transactions with "ANYONECANPAY" inputs from the blocks they build. This would be a simple protective measure to prevent their blocks from being rejected by the Segwit-enforcing miners, without having to implement Segwit themselves. A side effect, if many miners do this, would be to increase average confirmation times for Segwit transactions, and reduce security of Segwit transactions, possibly discouraging Segwit adoption.
 

jonny1000

Active Member
Nov 11, 2015
380
101
mengerian said:
Say a Segwit soft fork activates on the network with (for example) 75% support. To the 25% of miners who do not support Segwit, the Segwit outputs appear as "ANYONECANPAY". This creates a danger for this 25% of miner is that if they include a transaction in their block that spends one of these outputs, but does not conform to Segwit rules, then that block would be orphaned by the Segwit-supporting miners. This puts pressure on them to join the 75% majority and support Segwit.
No that's not how it works. After activation 100% of miners are required to upgrade or their blocks will be orphaned.

Also activation is 95% not 75%. My understanding is most Core devs respect the rights of a 10% miner to veto SegWit.
 

Mengerian

Moderator
Staff member
Aug 29, 2015
536
2,597
No that's not how it works. After activation 100% of miners are required to upgrade or their blocks will be orphaned.
They can simply set the version bits needed to prevent their blocks from being rejected, build on the longest chain, but refuse to include Segwit inputs in the blocks they build. All this can be done without them needing to run any Segwit-processing code.

Also activation is 95% not 75%. My understanding is most Core devs respect the rights of a 10% miner to veto SegWit.
That's nice. However, I don't think it's in my best interest to restrict my consideration of potential future events to your understanding of Core dev intentions.
 

jonny1000

Active Member
Nov 11, 2015
380
101
That is one shitty high risk attack with low profit potential.
All you need to do is make one block at any time. This is a very easy and cheap attack. Just allocate 0.1% of the global hashpower to it and it happens once per week.
[doublepost=1476290931][/doublepost]
mengerian said:
They can simply set the version bits needed to prevent their blocks from being rejected, build on the longest chain, but refuse to include Segwit inputs in the blocks they build. All this can be done without them needing to run any Segwit-processing code.
Yes miners could false flag and say they upgraded to SegWit when they have not. They could then refuse to include inputs redeemed when the signature is segregated. This is censoring transactions. These miners would still need to upgrade to a special censorship node.

At the same time miners could pick any outputs in the UTXO and refuse to put them in blocks.
 
Last edited:

albin

Active Member
Nov 8, 2015
931
4,008
It's "falsely flag" when flag is a verb, but I imagine that's irrelevant because the resident concern troll is likely trying to conflate the literal adverb-verb English word combo with the widely-known term for surreptitious state-sponsored terrorism on its own population.
 

_mr_e

Active Member
Aug 28, 2015
159
266
All you need to do is make one block at any time. This is a very easy and cheap attack. Just allocate 0.1% of the global hashpower to it and it happens once per week.
Let's just ignore my points and carry on spewing the same bullshit.

Why is the BU community so hostile to skeptics pointing out weaknesses and potential fixes in BU? If the hostility is too strong, BU will be too weak. Skeptics should be welcomed to help make BU robust.
Because your 'weaknesses' are nothing but bullshit you've pulled out of your ass.
 

Norway

Well-Known Member
Sep 29, 2015
2,424
6,410
Why is the BU community so hostile to skeptics pointing out weaknesses and potential fixes in BU? If the hostility is too strong, BU will be too weak. Skeptics should be welcomed to help make BU robust.
I take that as a no.

EDIT: Sorry for feeding the concern troll, guys. I'll put him on ignore.
 

albin

Active Member
Nov 8, 2015
931
4,008
Sometimes it's hard not to engage. It's just super hilarious that practically every single thing he says is some kind of pedantic lecture as though he's talking to children. I sincerely hope that's deliberate in order to get a rise out of people, because while that's not exactly good, the alternative explanation is even more disturbing.