The real disastor that could happen (forking Bitcoin)...

[Lauda]

We don't "need" almost everyone for any change. That's what the minority would like to think but no, if 75% agrees to kick out 25% away. Then 75% have come to a consensus to get rid of the armful 25%. End of story.

Why 75% then? Your argument makes no sense from this perspective: 51% resembles the majority as well and you could time the hard fork with a difficulty adjustment (this wouldn't be a problem). Then the 51% would have come at consensus and got rid of the armful 49%, right?

[blunderer]

At start, Satoshi choose 32MB as consensus rule, then changed it to 1 MB consensus rule, now it can be changed to 2 MB if majority chooses. If you dont want, your free to use 1 MB the same way people were free to choose continue using 32 MB before, none force you anywhere, but you force me to keep using 1 MB. Do you see the difference between dictatorship verus freedoom here ?

No. Stop with the "majority" nonsense when talking about 75%. For an upgrade of the network we need 'almost everyone' (obviously you can't achieve 100% but can come close to it) on board else you break consensus. You are essentially forcing the 1/4 of the current network (and this is a lot of people, hashpower and possibly even more merchants) to join the fork or be left on a slow and dying chain. This is not freedom.

Could you link me to the source of boldface above? I keep searching https://bitcoin.org/bitcoin.pdf, and getting zero hits.
Perhaps alternative spelling?
Or are you simply making stuff up/using air quotes?

[CIYAM]

Yes. Seriously. Did you buy this account?

Would you like me to create a signed message using the 1ciyam address to prove it?

(and if that isn't enough then perhaps use my GPG sig as well?)

[knight22]

We don't "need" almost everyone for any change. That's what the minority would like to think but no, if 75% agrees to kick out 25% away. Then 75% have come to a consensus to get rid of the armful 25%. End of story.

Why 75% then? Your argument makes no sense from this perspective: 51% resembles the majority as well and you could time the hard fork with a difficulty adjustment (this wouldn't be a problem). Then the 51% would have come at consensus and got rid of the armful 49%, right?

I used 75% as per Classic threshold but you are right, any % can make it for a split. Consensus is all about compromise. If one group is unwilling to do ANY compromise then the only thing they should expect is a letter of divorce from the other group, regardless of how much % they represent.

[Cuidler]

At start, Satoshi choose 32MB as consensus rule, then changed it to 1 MB consensus rule, now it can be changed to 2 MB if majority chooses. If you dont want, your free to use 1 MB the same way people were free to choose continue using 32 MB before, none force you anywhere, but you force me to keep using 1 MB. Do you see the difference between dictatorship verus freedoom here ?

No. Stop with the "majority" nonsense when talking about 75%. For an upgrade of the network we need 'almost everyone' (obviously you can't achieve 100% but can come close to it) on board else you break consensus. You are essentially forcing the 1/4 of the current network (and this is a lot of people, hashpower and possibly even more merchants) to join the fork or be left on a slow and dying chain. This is not freedom.

We don't "need" almost everyone for any change. That's what the minority would like to think but no, if 75% agrees to kick out 25% away. Then 75% have come to a consensus to get rid of the armful 25%. End of story. There is nothing the 25% can do to stop the 75% to do whatever they want.

This, plus there are altcoin lovers who dont mind hurting Bitcoin a bit or have different reasons for capping onchain useability. You cant get almost everyone agree becase there are bad actors who dont have best Bitcoin interest in mind. Thats why you cant give too much veto power to small minority.

[Lauda]

Consensus is all about compromise. If one group is unwilling to do ANY compromise then the only thing they should expect is a letter of divorce, regardless of how much % they represent.

These is no group that is unwilling to compromise aside from the forkers. Your support a harmful split of the network; unfortunately we can't banish bad actors from an decentralized platform. I will not respond to further input from a party who is willing to damage the whole ecosystem in order to get their own way.

Could you link me to the source of boldface above? I keep searching https://bitcoin.org/bitcoin.pdf, and getting zero hits.
Perhaps alternative spelling?

Start by reading the mailing list from day one. You're welcome.

This, plus there are altcoin lovers who dont mind hurting Bitcoin a bit or have different reasons for capping onchain useability. You cant get almost everyone agree becase there are bad actors who dont have best Bitcoin interest in mind. Thats why you cant give too much veto power to small minority.

Neither is 10 nor 5% small in the Bitcoin ecosystem. Nobody is capping the onchain usability either.

[knight22]

Consensus is all about compromise. If one group is unwilling to do ANY compromise then the only thing they should expect is a letter of divorce, regardless of how much % they represent.

These is no group that is unwilling to compromise aside from the forkers. Your support a harmful split of the network; unfortunately we can't banish bad actors from an decentralized platform. I will not respond to further input from a party who is willing to damage the whole ecosystem in order to get their own way.

Give me a break, big blockers have been compromising down to 2 mb. That's how you get consensus. How much small blockists have been willing to raise the limit to achieve consensus?



0

[blunderer]

...

Could you link me to the source of boldface above? I keep searching https://bitcoin.org/bitcoin.pdf, and getting zero hits.
Perhaps alternative spelling?

Start by reading the mailing list from day one. You're welcome.
...

Provide source or I'll have to assume you're simply lying.

[jbreher]

Bitcoin is not a political thing

In and of the fact that politics is nothing more or less than the adjudication of who wields power in a group dynamic, this particular part of Bitcoin is indeed 100% political.

One group (small blockers) want one thing, and another group (big blockers) want another. What outcome wins? It will be decided by those who amass political power. Period.

Sure, it all has to operate within the constraints of what technology allows, but it is still political. All your pollyanna posturing can't change that fundamental truth.

[knight22]

Bitcoin is not a political thing

In and of the fact that politics is nothing more or less than the adjudication of who wields power in a group dynamic, this particular part of Bitcoin is indeed 100% political.

One group (small blockers) want one thing, and another group (big blockers) want another. What outcome wins? It will be decided by those who amass political power. Period.

Sure, it all has to operate within the constraints of what technology allows, but it is still political. All your pollyanna posturing can't change that fundamental truth.

Indeed. Consensus does not come from code and math but from people agreeing to run the same code. Convincing people to run the same code as yours is political.  

[jbreher]

If you are an exchange and you decide to "remain open" then you are gambling (i.e. if you end up on the wrong fork and you have paid out fiat to people then you have just lost that fiat and gained nothing of any value).

I don't think that exchanges are going to be so brave as to want to gamble.

Nonsense. Any rational exchange, seeing the threshold nearing, will implement trading for both chains independently. With tools to allocate to such chain funds that are being spent from the common trunk as desired by the nominal 'owner' of such funds. Any exchange that does not is incompetent, and deserves to be put out of business.

I note that even SegWitters are starting to recognize the possibility of chain splitting due to the SegWit fork, anyways.

[jbreher]

Well, no. Only for non-fully-validating nodes. All nodes that ignore the signature chain will need to trust other -- fully-validating nodes (which get no capacity boost) -- to do the validation for them.

It does for those who upgrade; those that don't upgrade never needed the increase in capacity.

I can't tell what is subject and what is object in your reply. But if I have your words parsed properly, than I believe you are making a false statement. Let me try again.

For any given node:
- In order to operate in a trustless manner, a node must fully validate
- In order to fully validate, a node must have access to signature data
- SegWit partitions transaction data into two chains - the operational data and the signature data
- the 'capacity increase' that SegWit claims is entirely due to the fact that they don't tabulate the signature data as being part of the block size accounting

Ergo, any node wishing to operate in a trustless manner does not get any 'block size increase'

You may reply 'but fraud proofs'. But this is yet another mechanism entirely dependent upon outsourcing validation to other nodes. IOW, not trustless. Insecure.

[jbreher]

Yes. Seriously. Did you buy this account?

Would you like me to create a signed message using the 1ciyam address to prove it?

No need. I'll interpret this merely as you replying 'No'.

It is just that I remember interactions in years past whereby I thought you typically provided solid reasoning. Your posts of the last month or so don't seem so to me. More along the lines of axioms stated as proven fact followed by conclusions with no intervening reasoning. Sorry - just calling it as I see it.

[Lauda]

I can't tell what is subject and what is object in your reply. But if I have your words parsed properly, than I believe you are making a false statement. Let me try again.

My post is valid. In Segwit transacting between upgraded clients becomes more efficient; there is no increase in capacity for nodes that have not upgraded (or non-Segwit nodes). They are able to receive the data but are unable to validate it. If it is able to validate it then the client it is a segwit node. Not sure if this was changed in any way since the last time I've read about it (there's also a proposal in regards to it by Peter Todd which I've yet to fully read).

[jbreher]

I can't tell what is subject and what is object in your reply. But if I have your words parsed properly, than I believe you are making a false statement. Let me try again.

My post is valid. In Segwit transacting between upgraded clients becomes more efficient; there is no increase in capacity for nodes that have not upgraded (or non-Segwit nodes). They are able to receive the data but are unable to validate it. If it is able to validate it then the client it is a segwit node. Not sure if this was changed in any way since the last time I've read about it (there's also a proposal in regards to it by Peter Todd which I've yet to fully read).

(bold not in original)

Please define what you mean by 'upgraded client'.

If such a client is getting a 'capacity boost', the only way this can be accomplished is by that node ignoring signature data. Ignoring signature data in and of itself makes that node dependent upon others to perform validation. Accordingly, such a node cannot operate in a trustless manner. It is insecure.

[Lauda]

(bold not in original)

Please define what you mean by 'upgraded client'.

A client that supports Segwit after the activation occurs. Those clients can download and validate the data.

If such a client is getting a 'capacity boost', the only way this can be accomplished is by that node ignoring signature data. Ignoring signature data in and of itself makes that node dependent upon others to perform validation. Accordingly, such a node cannot operate in a trustless manner. It is insecure.

I never said that old nodes would be secure, did I?

[xyzzy099]

At start, Satoshi choose 32MB as consensus rule, then changed it to 1 MB consensus rule, now it can be changed to 2 MB if majority chooses. If you dont want, your free to use 1 MB the same way people were free to choose continue using 32 MB before, none force you anywhere, but you force me to keep using 1 MB. Do you see the difference between dictatorship verus freedoom here ?

No. Stop with the "majority" nonsense when talking about 75%. For an upgrade of the network we need 'almost everyone' (obviously you can't achieve 100% but can come close to it) on board else you break consensus. You are essentially forcing the 1/4 of the current network (and this is a lot of people, hashpower and possibly even more merchants) to join the fork or be left on a slow and dying chain. This is not freedom.

Could you link me to the source of boldface above? I keep searching https://bitcoin.org/bitcoin.pdf, and getting zero hits.
Perhaps alternative spelling?
Or are you simply making stuff up/using air quotes?

If you are really interested in why 75% is not enough, the definitive answer is found here:

http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html

[jbreher]

(bold not in original)

Please define what you mean by 'upgraded client'.

A client that supports Segwit after the activation occurs. Those clients can download and validate the data.

Yes, they can. And they must process more than 1MB of data in order to validate what they are calling a 1MB block. The difference in quantity of data, of course, being the amount of data in the signatures.

So tell me again why this does requirement for more data not lead to node centralization, when many SegWit boosters (perhaps not yourself - I can't keep track) rely upon 'increasing block size to 2MB will lead to node centralization' as one of their strongest arguments? Or at least as their only argument for their claim that a simple block size increase is unsafe?

[jbreher]

If you are really interested in why 75% is not enough, the definitive answer is found here:

http://organofcorti.blogspot.com/2015/08/bip101-implementation-flaws.html

Because the stated 75% criteria produces a negligible yet discernible chance that we get a false trigger at an actual 67% adoption rate due to variance? Yawn. Troll harder.

[Lauda]

Yes, they can. And they must process more than 1MB of data in order to validate what they are calling a 1MB block. The difference in quantity of data, of course, being the amount of data in the signatures.

That was what I initially said. This depends on the exact quantity of data though, just how much more are we talking about here?

So tell me again why this does requirement for more data not lead to node centralization, when many SegWit boosters (perhaps not yourself - I can't keep track) rely upon 'increasing block size to 2MB will lead to node centralization' as one of their strongest arguments? Or at least as their only argument for their claim that a simple block size increase is unsafe?

I don't rely on that argument but I have surely used it a number of times (can't recall all the discussions). I'm just not aware of an estimated factor of increase and have chosen to ignore this information until I have one. Has someone done the math?