Stop fuckin' around, fork the son-of-a-bitch already.

[exstasie]

so abusing the consensus mechanism by not allow users to choose, thus not even giving any new rules a chance.

Anyone is free to choose. Why don't you fork the code and promote it? See if users actually support your fork? Why do people insist on leveraging hash rate to provoke users to change networks?

Just leave miners out of it. If forkers had support, they would fork, and the community would follow. That they refuse to fork and instead lobby miners to pressure the rest of us to fork is very telling.

[1714833228]

1714833228

[1714833228]

1714833228

[franky1]

so abusing the consensus mechanism by not allow users to choose, thus not even giving any new rules a chance.

Anyone is free to choose. Why don't you fork the code and promote it? See if users actually support your fork? Why do people insist on leveraging hash rate to provoke users to change networks?

Just leave miners out of it. If forkers had support, they would fork, and the community would follow. That they refuse to fork and instead lobby miners to pressure the rest of us to fork is very telling.

the code of a 2mb block is not the problem.. even core agree 4mb is fine..

but there is drama and doomsday scenarios that stop a consensual fork.. not related to code.
but related to actually making implementations have the same rules so that no one has control and freedom of choice to use different implementations.

core want to take bitcoin offchain and away from the original idea, and they will do this without nodes needing to vote. they want full control
there have already been 6 attempts to offer an onchain solution. but the debate has not been about code logic. but social illogics.

even now.. Luke JR is starting to receive the R3kt campaign experience of social illogics, because luke wants to release a consensual hardfork using cores code.(meaning a safe option)

again its not about code. but they want to attack the social illogics because the code allows true capacity growth safely. the activation parameters offers hassle free rule changes.. but because it puts a dent into the plan of moving users offchain and into sidechains, the social debate begins trying to kill off freedom of choice by using false doomsdays and personality attacks.

in short core want to be the sole decision makers. and even if one of their own wants freedom of choice, they will throw them under the bus

to answer your question directly..
anyone can make the most majestic code ever that does exactly as expected. but it would get wrecked in the social drama of going against cores corporate plan of offchain middlemen controls

[exstasie]

so abusing the consensus mechanism by not allow users to choose, thus not even giving any new rules a chance.

Anyone is free to choose. Why don't you fork the code and promote it? See if users actually support your fork? Why do people insist on leveraging hash rate to provoke users to change networks?

Just leave miners out of it. If forkers had support, they would fork, and the community would follow. That they refuse to fork and instead lobby miners to pressure the rest of us to fork is very telling.

the code of a 2mb block is not the problem.. even core agree 4mb is fine..

but there is drama and doomsday scenarios that stop a consensual fork.. not related to code.
but related to actually making implementations have the same rules.

core want to take bitcoin offchain and away from the original idea, and they will do this without nodes needing to vote.
there have already been 6 attempts to offer an onchain solution. but the debate has not been about code logic. but social illogics.

even now.. Luke JR is starting to recieve the R3kt campaign experience of social illogics, because luke wants to release a consensual hardfork using cores code.

again its not about code. but they want to attack the social illogics because the code allows true capacity growth. the activation parameters offers hassle free rule changes.. but because it puts a dent into the plan of moving users offchain and into sidechains, the social debate begins trying to kill off freedom of choice by using false doomsdays and personality attacks.

in short core want to be the sole decision makers. and even if one of their own wants freedom of choice, its time to throw them under the bus

You completely avoided what I asked. "Why don't you fork the code and promote it? See if users actually support your fork? Why do people insist on leveraging hash rate to provoke users to change networks?"

Instead you troll these forums day in, day out, talking shit about Core. What's the point? If people support the rule changes you propose, they will migrate to your fork. Endlessly insulting Core doesn't give merit to your fork.

[franky1]

You completely avoided what I asked. "Why don't you fork the code and promote it? See if users actually support your fork? Why do people insist on leveraging hash rate to provoke users to change networks?"

Instead you troll these forums day in, day out, talking shit about Core. What's the point? If people support the rule changes you propose, they will migrate to your fork. Endlessly insulting Core doesn't give merit to your fork.

to answer your question directly..
anyone can make the most majestic code ever that does exactly as expected. but it would get wrecked in the social drama of going against cores corporate plan of offchain middlemen controls

look at the propaganda
to change networks
migrate to your fork

seems you have not understood the difference of consensual and controversial. and you think that a hard fork is only controversial.
trying to scare everyone by saying a fork is not bitcoin by using propaganda buzzwords like "changing networks" or "migrating"

please learn consensual vs controversial

[exstasie]

You completely avoided what I asked. "Why don't you fork the code and promote it? See if users actually support your fork? Why do people insist on leveraging hash rate to provoke users to change networks?"

Instead you troll these forums day in, day out, talking shit about Core. What's the point? If people support the rule changes you propose, they will migrate to your fork. Endlessly insulting Core doesn't give merit to your fork.

to answer your question directly..
anyone can make the most majestic code ever that does exactly as expected. but it would get wrecked in the social drama of going against cores corporate plan of offchain middlemen controls

look at the propaganda
to change networks
migrate to your fork

seems you have not understood the difference of consensual and controversial. and you think that a hard fork is only controversial.
trying to scare everyone by saying a fork is not bitcoin by using propaganda buzzwords like "changing networks" or "migrating"

please learn consensual vs controversial

Propaganda?

By definition a hard fork creates a new network. This a matter of fact, not opinion.

What I said didn't contemplate whether a hard fork is controversial. What I said was, why don't you fork the code? Why do you need miners to pressure users to switch clients?

It seems the answer you buried in your long-winded posts was "nobody would support my fork." Okay then. There's your answer.

[VeritasSapere]

snip

they way you see a fork is an intentional split.(controversial). and keeping both side alive..

to me i would call that a controversial fork where a clear defined single direction cannot be established and so extra code is added so the 2 decisions do not rule each other out(blacklisting opposing user agents/flags), which allows both decisions to survive.

a consensual fork is when there is adequate demand and utility that the rules can change without causing a second chain, where the natural consensus mechanism of orphans that would kill off a minority and everyone continues in a single direction of new rules..

I entirely agree.

in the last year of debate.. the conclusion is that all software implementations should have released a fork code with a consensual activation mechanism. meaning if a high majority desire shows, it activates and then orphans take care of the minority until the minority move over. leading to a single chain.
emphasis high majority desire to move in a single direction

i do not favour controversial forks that add code to force the minority chain to survive. (clams)

but that said i also do not favour a certain dev team to veto even releasing code out of fear that everyone would actually show a high desire for it. so abusing the consensus mechanism by not allow users to choose, thus not even giving any new rules a chance.

core fans scream doomsdays of controversial hard forks. but dont realise that core is preventing consensual forks by vetoing a release to ensure the community never get to a healthy majority. thus causing the controversy

This is a good point, we can always say that we have alternatives, like Classic and Unlimited for example but you are right in that this is what causes the controversy in the first place.

so here is the thing.
if cores only worry is a healthy majority.
how about include the hardfork in their softfork code as both require high majority activation parameters. thus when it activates there is no harm because of the consensus mechanism is there to resolve it.

I agree entirely, if only Core actually did such a thing, I might even support it. Chances are that this will not happen, which is why splitting the chain might be the next best solution, it does not actually matter what we think about it, I am confident it will happen regardless there are already enough motivated people working on it. The only way I see this not happening would be if Core compromises in their position and includes a hard fork for increasing the blocksize limit in one of their following releases.

Anyone is free to choose. Why don't you fork the code and promote it? See if users actually support your fork? Why do people insist on leveraging hash rate to provoke users to change networks?

Just leave miners out of it. If forkers had support, they would fork, and the community would follow. That they refuse to fork and instead lobby miners to pressure the rest of us to fork is very telling.

The beautiful thing is that nobody has to follow, as a holder of Bitcoin you will have the same share of Bitcoins in both chains. You can just sell the "big block" coins and ignore that chain and just continue as if nothing has changed. I would advise holding coins on both chains after a split, better to hedge our bets.

You asked for promotion: https://www.reddit.com/r/btcfork/

This is how I learned to stop worrying and love the fork.

[franky1]

Propaganda?

By definition a hard fork creates a new network. This a matter of fact, not opinion.

What I said didn't contemplate whether a hard fork is controversial. What I said was, why don't you fork the code? Why do you need miners to pressure users to switch clients?

It seems the answer you buried in your long-winded posts was "nobody would support my fork." Okay then. There's your answer.

again your only seeing a hard fork through the eyes of controversial.

EG if core released
0.14A(just segwit)
0.14B(segwit+ hardfork)

and other implementations also done the same
bitcoin knots, airbitz, BU, classix, XT, and all the others
XA traditional
XB hardfork

then there is a fully open choice. even the core fanboys dont have to defect away from their religion(core) if they secretly want more real onchain capacity growth because every version in existance has a agreed consensus change, including core.
making EVERYONE on the same level playing field

but by core not even trying to make it (lets hope luke releases it before getting thrown out) then there will never be a healthy majority, due to
the loyal flock wanting core to dominate(even if the flock dont understand the route core prefers) and make decisions for them (centrally)

so yea bitcoin knots, airbitz and others can have perfect code.. but core fanboys will doomsday call anything not core.. purely because core doesnt want a consensual fork(real onchain capacity).. they want to lead and control decisions. not allow an open decentralized free choice.

the funny thing is. core can easily release 0.14B(segwit+ hardfork) and then just see if people download A or B.
and if 95% have not downloaded version B of their favourite. then it will not activate and nothing is lost.
but by core vetoing any chance of a core version B. they are not even allowing users a free choice, even amungst their own flock

its like having 12 jurers where it requires unanimous favour of one decision to get a perfect conviction.
core are telling just 1 jurers to not vote at all, neither innocent or guilty.. purely to cause controversy and not have a consensual judgement.

[Lauda]

its not about a bigger market capitalization..
its not about more money.

Nonsense. The people who are primarily pushing for ridiculous block sizes are the ones crying out that we need more users. It's obviously about money. If it wasn't about money, you'd be taking a safe path with scaling as there is zero need to risk anything. As I've previously stated, I'm not anti-HF as in consensual upgrades, not controversial splits.

I think that Bitcoin will split multiple times, within the next six months. Nobody can really stop it, that is a beautiful thing. I suppose somebody could create a "genesis fork" with a six month grace period, it would most likely not be the first chain to split off the Bitcoin network and gain a significant market share.

Just by saying that splitting up the userbase, infrastructure and network as a whole is a "beautiful thing" makes me question the sanity of some people. Nothing good can nor will come out of that. Just confusion that will generally have negative side-effects.

core fans scream doomsdays of controversial hard forks. but dont realise that core is preventing consensual forks by vetoing a release to ensure the community never get to a healthy majority. thus causing the controversy

No, Core isn't prevent anything. You're free to write a HF proposal as a BIP and see whether it gains attraction.

[Kakmakr]

I am going to walk on the safe path, and go with the direction these Core guys are going. Why do we need to change anything if it is working? The big blockers were creating Apocalyptic scenarios since this debate has started many moons ago, and guess what, nothing happened.

We have seen strange stress tests being done, to make people believe that bigger blocks are necessary, but the network came through with flying colors and these people lost money. Let's just take hands, smoke some weed and sing Bitcoin songs. ^smile^ After all, people are saying we are a bunch of perverted drug heads, so just make the best of it.    

[franky1]

its not about a bigger market capitalization..
its not about more money.

Nonsense. The people who are primarily pushing for ridiculous block sizes are the ones crying out that we need more users. It's obviously about money. If it wasn't about money, you'd be taking a safe path with scaling as there is zero need to risk anything. As I've previously stated, I'm not anti-HF as in consensual upgrades, not controversial splits.

ridiculous blocksizes??

sorry but segwit is 4mb.. i proven that in a different topic and even supplied you a link.
so how is 2mb ridiculous??

I think that Bitcoin will split multiple times, within the next six months. Nobody can really stop it, that is a beautiful thing. I suppose somebody could create a "genesis fork" with a six month grace period, it would most likely not be the first chain to split off the Bitcoin network and gain a significant market share.

Just by saying that splitting up the userbase, infrastructure and network as a whole is a "beautiful thing" makes me question the sanity of some people. Nothing good can nor will come out of that. Just confusion that will generally have negative side-effects.

i actually agree with lauda's sentiment..

core fans scream doomsdays of controversial hard forks. but dont realise that core is preventing consensual forks by vetoing a release to ensure the community never get to a healthy majority. thus causing the controversy

No, Core isn't prevent anything. You're free to write a HF proposal as a BIP and see whether it gains attraction.

submit a bip to.............. ?
go on.. say it
CORE
well there already has been logical bips submitted, and the decision against implementing it was not vetoed out due to code, or logic or real reason. but due to false doomsdays and fake stats.. mainly illogical scare stories

which from reading your little awakening in another topic, you are beginning to see

[Lauda]

ridiculous blocksizes??

sorry but segwit is 4mb.. i proven that in a different topic and even supplied you a link.
so how is 2mb ridiculous??

Yes, I'm talking about ridiculous block sizes. Examples of those being suggested by irrational people: 8 MB, 20 MB (remember 2015 20 MB now or doomsday?), unlimited. 2 MB should be fine after validation time is linear and not quadratic.

i actually agree with lauda's sentiment..

Additionally, I strongly believe that any controversial fork is an altcoin in a sense where a very small minority split away from the majority. We define pretty much any coin that does this as an altcoin; the primary difference is that they: 1) Change some specifications; 2) Don't retain the current blockchain information but rather start 'fresh'.

well there already has been logical bips submitted, and the decision against implementing it was not vetoed out due to code, or logic or real reason. but due to false doomsdays and fake stats.. mainly illogical scare stories

You can't get something merged into Core without consensus. What you could do is: Write a BIP -> provide the code for it -> if it gets rejected, then provide your own implementation for it. I'm also not aware of any "false doomsdays or fake stats" that were used as arguments against any of those BIPs.

[franky1]

I'm also not aware of any "false doomsdays or fake stats" that were used as arguments against any of those BIPs.

Yes, I'm talking about ridiculous block sizes. Examples of those being suggested by irrational people: 8 MB, 20 MB (remember 2015 20 MB now or doomsday?), unlimited. 2 MB should be fine after validation time is linear and not quadratic.

sorry to tell you this but 2mb is actually healthy right now..
libsecp256k1 alone (released ages ago) has actually made enough efficiency boost to make 2mb blocks healthily able to run on a raspberry pi.

the debate about linear validation. is absolutely nothing to do with bitcoin right now. absolutely nothing about a 2mb block of traditional bitcoin transaction, but only a worry in regards to when lightning network is active, which is not any time soon.

ill emphasise it again, linear signatures only really see a benefit in regards to multisigs which will gain dominance when lightning network is activated, but offers little to no noticeable difference to.... wait.. you may pick up your own rhetoric here... "median" size transactions(226byte), or as i say average transactions(~450byte)

(and im being subtle, but hopefully previous conversations give you enough of a hint)
so try not to back track on average/median transaction sizes to now argue about large 1kbyte multisigs being a big deal right now

[Lauda]

sorry to tell you this but 2mb is actually healthy right now..
libsecp256k1 alone (released ages ago) has actually made enough efficiency boost to make 2mb blocks healthily able to run on a raspberry pi.

No, that's not right (if it was right, there would be no need for sigops limitations in Bitcoin Classic). I've addressed this issue about 6 months ago already:

in order to sign or verify the tx, each input has to construct a special version of the tx and hash it. so if there are n inputs there are nxn hashes to be done. hence quadratic scaling.
the TLDR I believe is: ecdsa operations are the most computationally expensive part of verifying transactions, for normal, small size transactions, but they scale linearly with the size (number of inputs).whereas if a transaction in current bitcoin has tons of inputs, the bottleneck moves over to the hashing/preparing data to to be signed, because that time depends on the *square* of the number of inputs.
so usually it's ultra small, but it blows up for large N inputs.

Why doesn't libsecp256k1 have an effect on this?

because libsecp256k1 is an ECC library so it's only the "ecdsa" part in the above.

I don't know why you keep persisting that it doesn't. You should run a benchmark on that raspberry PI and validate only the block full of spam that was mined by F2Pool back in 2015 or 2014 (it was mentioned in the conference).

[franky1]

sorry to tell you this but 2mb is actually healthy right now..
libsecp256k1 alone (released ages ago) has actually made enough efficiency boost to make 2mb blocks healthily able to run on a raspberry pi.

No, that's not right (if it was right, there would be no need for sigops limitations in Bitcoin Classic). I've addressed this issue about 6 months ago already:

in order to sign or verify the tx, each input has to construct a special version of the tx and hash it. so if there are n inputs there are nxn hashes to be done. hence quadratic scaling.
the TLDR I believe is: ecdsa operations are the most computationally expensive part of verifying transactions, for normal, small size transactions, but they scale linearly with the size (number of inputs).whereas if a transaction in current bitcoin has tons of inputs, the bottleneck moves over to the hashing/preparing data to to be signed, because that time depends on the *square* of the number of inputs.
so usually it's ultra small, but it blows up for large N inputs.

Why doesn't libsecp256k1 have an effect on this?

because libsecp256k1 is an ECC library so it's only the "ecdsa" part in the above.

I don't know why you keep persisting that it doesn't. You should run a benchmark on that raspberry PI and validate only the block full of spam that was mined by F2Pool back in 2015 or 2014 (it was mentioned in the conference).

i was gonna waffle but..

block: 364292 validated in 2 seconds..
as oppose to pre libsecp256k1 optimisation, which took far far far longer.

other standard blocks 0-400,000 validated in under 6 hours (18 blocks per second)
which took far far longer pre libsecp256k1 optimisation

yes pre-libsecp256k1 estimated 11 minutes for an 8mb block(without the antispam sigops/hash limits)..
but due to the antispam limits, the only way to fill an 8mb block with spam is as 8x 1mb transactions..
which libsecp256k1 optimisations would bring about ~16 seconds validation time for 8mb (1mb processing repeated 8 times)
but we all know that for the last year, 8mb-20mb was not rational and 2mb was rational and overall approved. your buddy carlton approved it and even today your saying 2mb is ok...

so based on 2mb blocks of spam would require tweaking out some of the antispam limits to perform the test based on old metrics. but lets say with the anti-spam limits inplace it was treated as block364292 repeated twice (the only way to get 2mb of spam is to do 2 transactions to stay under the sigop/hash limits).

which would result in a 4second validation time.

so its not exactly killing a raspberry pi.. compared to the non antispam, non optimised doomsday pitch you and your cohorts of last year were crying by saying 11minutes+..

i do agree that linear would make a 4second spam block into a 10milisecond validation time just like any non spam transaction block.

but 4 seconds for the rare occassion is not killing bitcoin
and is definitely not anywear near a doomsday pitch "more than 10 minutes of DDoS via spam" Armageddon war-cry

[Lauda]

lol so transactions are no longer median 226 bytes? or as i said average ~450bytes

Median is still 226 bytes, as shown on this website.

remember the sigops issue is not a problem for median/average transactions.(you know transactions that dont have much signatures) and only a problem for bloated transactions (you know such as what will be noticeable when lightning hubs start dealing with many signatures) where the average and even your magical median increase.

No, neither one holds true. Nobody ever claimed that the quadratic scaling is problematic with normal transactions. It is just an attack vector that could be abused by a malicious miner. "Could be" doesn't mean that it "will be" though.

block: 364292 validated in 2 seconds..
as oppose to pre libsecp256k1 which took far far far longer.

Where is the source of this result ("2 seconds")?

other standard blocks 0-400,000 validated in under 6 hours (18 blocks per second)
as oppose to pre libsecp256k1 which took far far far longer.

That doesn't matter. As previously stated, while libsecp256k1 improves validation time significantly it does not mitigate the attack vector at 2 MB (Gavin even confirmed this somewhere).

[franky1]

lol so transactions are no longer median 226 bytes? or as i said average ~450bytes

Median is still 226 bytes, as shown on this website.

remember the sigops issue is not a problem for median/average transactions.(you know transactions that dont have much signatures) and only a problem for bloated transactions (you know such as what will be noticeable when lightning hubs start dealing with many signatures) where the average and even your magical median increase.

No, neither one holds true. Nobody ever claimed that the quadratic scaling is problematic with normal transactions. It is just an attack vector that could be abused by a malicious miner. "Could be" doesn't mean that it "will be" though.

block: 364292 validated in 2 seconds..
as oppose to pre libsecp256k1 which took far far far longer.

Where is the source of this result ("2 seconds")?

other standard blocks 0-400,000 validated in under 6 hours (18 blocks per second)
as oppose to pre libsecp256k1 which took far far far longer.

That doesn't matter. As previously stated, while libsecp256k1 improves validation time significantly it does not mitigate the attack vector at 2 MB (Gavin even confirmed this somewhere).

i even bothered to check a few websites to see several benchmarks to to make sure its not a fluke..
but heres one.. which also covers the bits about 8mb too
https://rusty.ozlabs.org/?p=515

seems rusty can get better than 2 seconds, but im guessing from reading it he was using a i3 laptop.
there were other sites and benchmarks saying increasing the dbcache also improved things too, but yea that digresses off the point

basically 2mb spam tx is not a bottleneck of doom 11minute scare story.. but a 4 second validation time
by the way google and a thing called research is your friend.

[Lauda]

i even bothered to check a few websites to see several benchmarks to to make sure its not a fluke..
but heres one.. which also covers the bits about 8mb too
https://rusty.ozlabs.org/?p=515

Initially I've asked you to provide your own benchmarks on a raspberry PI. These are not your results.

seems rusty can get better than 2 seconds, but im guessing from reading it he was using a i3 laptop.
there were other sites and benchmarks saying increasing the dbcache also improved things too, but yea that digresses off the point

Increasing the dbcache does speed up overall time, but that's not what we're trying to accomplish. I'm talking about default settings, and raspberry PI (since you've mentioned it).

basically 2mb spam tx is not a bottleneck of doom 11minute scare story.. but a 4 second validation time

That's not correct.

by the way google and a thing called research is your friend.

You've made claims, ergo you should back them up with sources. I'm not going to do the homework for you.

[RawDog]

Blah, blah, blah

Hey Lauda, do you take drugs?

[Slark]

Planned, well executed, not rushed hard fork for the sake of achieving  better performance, stability, speed -  pushing evolution in general is welcomed and needed.
The problem is that some users are scared/don't know what forking is about and I'm afraid that forking will always cause problems and panic - at least initially.

[VeritasSapere]

I am going to walk on the safe path, and go with the direction these Core guys are going. Why do we need to change anything if it is working? The big blockers were creating Apocalyptic scenarios since this debate has started many moons ago, and guess what, nothing happened.

We have seen strange stress tests being done, to make people believe that bigger blocks are necessary, but the network came through with flying colors and these people lost money.

Because it is not working as intended, a congested network leads to longer and more unreliable confirmation times and higher fees. This is not good for Bitcoin adoption, much has happened over the last year in this debate including Bitcoin continuously losing more of its market share to its competitors. Keeping this limit in place restricts the amount of people that can use Bitcoin regardless of the fee that is payed. This one simple parameter is hurting the adoption and growth of Bitcoin which is critical over the long term for its decentralization and expansion. Here is proof that this is occurring: