There is an easy way to move bitcoin forward.

[puppy647]

The miners want at least 2mb with segwit as per HK agreement.

Take 0.13.1 with segwit, add 2000000 MAX_BLOCKSIZE

Call your version "bitcoin compromise" or "bitcoin community" and create a basic webpage so people can download BC from it. A simple github link would do too ( do it anonymously so that politics don't get in the way)

PROBLEM solved.



What are the benefits of doing this?  We will keep all developers ( BU and core),their ego won't be hurt and bitcoin can move forward.

[puppy647]

Correct me if i'm wrong, but i think if you that, you would make your own blockchain network

That's what a hard fork is. That's also what BU is proposing.

If it's that simple, i think we already see 2mb max block size long time ago.

People still havn't realized that the situation is not black and white and that the solution is actually very simple.

[franky1]

Correct me if i'm wrong, but i think if you that, you would make your own blockchain network

That's what a hard fork is. That's also what BU is proposing.

its not.. learn consensus..
any node (mine already does) has and can have a blocksize buffer more than 1mb.. (unless you are using the precompiled core that doesnt let you change it post compile, soo need to change the code then compile it)

hundreds of nodes already do have buffers above 1mb.. yet no 2nd network is formed, yep thats right nothing bad has happened.

the rule change is that anything BELOW 2000000 is acceptable. meaning right now 1mb is being passed around happily. because 1mb is below 2mb.
ill explain the rest after the next quote

If it's that simple, i think we already see 2mb max block size long time ago.

People still havn't realized that the situation is not black and white and that the solution is actually very simple.

those that want a second network are CORE. but those that are not core want consensus to keep the network together as one chain
here is cores chief technical officer proving its the core mindset that wants a network split and the others reject his plan

What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

The ethereum hardfork was bilateral, probably the only thing they did right--

so those others want consensus, not a 'bilateral' split.
this means if nodes actually set their nodes to 2000000 and the pools see a high enough majority that wont cause much/any orphan risk. the pools can then make blocks above 1mb.
this just causes the minority opposition from being able to sync to the network. and causing them to simply stall..
not creating a second chain. but just left stuck at a certain blockheight.

emphasis.. not 2 chains. not a bilateral fork.

the only way to make a second chain/network aka bilateral fork is to get the opposition to intentionally not communicate with the majority thus not be left stuck because they are no longer receiving/rejecting blocks from the majority. and instead start building their own chain.
(simply put ignoring consensus, ignoring the orphaning mechanism, ignoring the majority)

ethereum was not a consensus fork, was not even a controversial fork.. it was an intentional bilateral split
research:  --oppose-dao-fork

[puppy647]

@franky1


BU is basically a completely separate fork that has nothing to do with bitcoin core.
If the majority of miners, nodes, exchanges, wallets decide to use BU instead of core then BU is the new bitcoin.
This however is most likely never going to happen since a large group of people, miners, developers,etc… do not support BU.( that’s probably what you refer as consensus)

However if someone published the segwit core code with a 2mb anonymously, then the miners are most likely to show their support for this version because that’s basically what they want.

Both XT and classic didn’t get miner support because they didn’t have unanimous support . So does Segwit today.
Segwit+2mb pretty much has unanimous support, even the most hard core CORE crowd would support it, and the BU camp is just whining because core don’t want to compromise .

The problem we have now is not how we should scale , but it is who will control bitcoin in the future. The only way you can get rid of the politics is for someone to anonymously publish code that everyone wants. You will be surprised by how much support such code would have, especially in these uncertain times.

[franky1]

@franky1

BU is basically a completely separate fork that has nothing to do with bitcoin core.
If the majority of miners, nodes, exchanges, wallets decide to use BU instead of core then BU is the new bitcoin.
This however is most likely never going to happen since a large group of people, miners, developers,etc… do not support BU.( that’s probably what you refer as consensus)

you have fallen too deep into the blockstream owns bitcoin.
no one should own bitcoin.
secondly BU and XT are running right now on bitcoin and no fork is occuring. yep they even right now have larger blocksizes and nothing has gone wrong..

However if someone published the segwit core code with a 2mb anonymously, then the miners are most likely to show their support for this version because that’s basically what they want.

also segwit is not active you cannot make a P2WPKH transaction right now.. so segwit is not part off bitcoin.
its just a bitcoin release with an inactive feature thats sitting on the side thats not allowed on bitcoin yet.

Both XT and classic didn’t get miner support because they didn’t have unanimous support . [neither] does Segwit today.
Segwit+2mb pretty much has unanimous support, even the most hard core CORE crowd would support it, and the BU camp is just whining because core don’t want to compromise .

well having a release that has both dynamic and segwit would be the "have the cake and be able to eat it" best of both propositions which would actually get better acceptance rate by the community as a whole.
sorry but spoonfeeding with just a release thats hardcoded as 2000000 fixed. is still just kicking the can down the road. relying on devs to release a EG 3000000 buffer later on.. which still feels like a oliver twist "please sir can i have some more" begging to devs game.

The problem we have now is not how we should scale , but it is who will control bitcoin in the future. The only way you can get rid of the politics is for someone to anonymously publish code that everyone wants. You will be surprised by how much support such code would have, especially in these uncertain times.

consensus is about no one controlling
meaning its not devs setting the setting. but offering a settings panel or a method for users to set what they want AFTER compiling and using it. thus not need continual spoonfeeding of devs. because consensus changes by what majority of nodes allow. which can change when USERS choose. not devs.

i agree that there should be more diverse implementations released. where it dilutes cores dictatorship. so that

if cores 1mb dictatorship wall dilutes to became only 5% dominance.. meaning the 1mb becomes small minority. then what the majority accept as the next safe buffer is what the pools choose to move towards. then users get to set what they are happy with. and if a majority show acceptance, things move forward. all without constant waiting for dev's to spoonfeed the setting.

ill save repeating myself by rewritting it again how consensus works

imagine the network had 55 nodes. for easy display purposs of 5500

and the acceptable node tolerances(user settings) were all collated and put into order
1.0mb, 1.5mb, 1.5mb, 2.0mb, 2.3mb, 2.5mb, 2.6mb, 2.7mb, 2.8mb, 2.9mb, 3.0mb,
3.0mb, 3.0mb, 3.2mb, 3.5mb, 3.6mb, 3.6mb, 3.7mb, 3.8mb, 4.0mb, 4.1mb, 4.1mb,
4.1mb, 4.3mb, 4.6mb, 4.7mb, 4.8mb, 4.9mb, 4.9mb, 5.0mb, 5.0mb, 5.1mb, 5.1mb,
5.2mb, 5.6mb, 5.8mb, 5.9mb, 5.9mb, 5.9mb, 5.9mb, 6.0mb, 6.1mb, 6.1mb, 6.2mb,
6.2mb, 6.2mb, 6.2mb, 6.3mb, 6.3mb, 6.4mb, 6.4mb, 6.5mb, 6.5mb, 6.6mb, 6.6mb,

the pool then takes away three nodes (~275 of 5500) to get to what would be ~95%
1.0mb, 1.5mb, 1.5mb, 2.0mb, 2.3mb, 2.5mb, 2.6mb, 2.7mb, 2.8mb, 2.9mb, 3.0mb,
3.0mb, 3.0mb, 3.2mb, 3.5mb, 3.6mb, 3.6mb, 3.7mb, 3.8mb, 4.0mb, 4.1mb, 4.1mb,
4.1mb, 4.3mb, 4.6mb, 4.7mb, 4.8mb, 4.9mb, 4.9mb, 5.0mb, 5.0mb, 5.1mb, 5.1mb,
5.2mb, 5.6mb, 5.8mb, 5.9mb, 5.9mb, 5.9mb, 5.9mb, 6.0mb, 6.1mb, 6.1mb, 6.2mb,
6.2mb, 6.2mb, 6.2mb, 6.3mb, 6.3mb, 6.4mb, 6.4mb, 6.5mb, 6.5mb, 6.6mb, 6.6mb,

then knowing that all remaining 52 nodes can accept 2mb.. thats what they make..

now here is the fun part most people forget.

pools start a flagging vote consensus saying we will make upto 2mb.. once the pools get 95% consensus.. those 3(275) nodes in the minority can up their limit.. as it takes time for pool consensus to get reached.. (eg 2 months for segwit and not near 95% yet)
so plenty of time for them to change a setting.

then. lets say it activates. pools can now push passed the 1mb old barrier and start moving to 2mb (much like the 2013DB bug where it pushed passed the 500k barrier even when nodes had a higher buffer.)

and guess what.. they wont jump straight to 2mb.. (much like they didnt jump straight to 1mb in 2013). they would try 1.001mb and test the water, see if any bugs present themselves any orphan risk. any issues.. if not. they push on 1.002mb, 1.003mb and so on over time naturally growing until* they get to 2mb due to demand and need.

*side note the 2 grey nodes(1.5mb i underlined) actually still happily accept blocks during the early movements meaning they dont actually need to decide to join consensus as early as the lowest single node at 1mb.. so while pools are testing the water only 1 node (100 of 5500) need to make a decision during the pool consensus+grace period before activation. the other 2(200 of 5500) can have a bit of breathing room ontop of pools consensus+grace period..

then when the limit is reached, finally after a lengthy natural growth period. the process begins again.
slow natural risk averting process where the nodes decide the tolerance

so dont expect a spammer to force a pools hand to make a pool jump up to 2mb on day one of activation.. pools are smarter then that
(much like the spam attacks of 2012-2015 didnt cause blocks to all be 1mb non stop, it was a slow curve over a couple of years)

[puppy647]

you have fallen too deep into the blockstream owns bitcoin.

How did you come to that conclusion?

"" cores dictatorship ""  Those are you words not mine

well having a release that has both dynamic and segwit would be the "have the cake and be able to eat it" best of both propositions which would actually get better acceptance rate by the community as a whole.

I disagree. BU has very little support from the community besides /r/btc. Most exchanges, wallet, miners don’t want it as it hasn’t been thoroughly tested and developers have pointed out potential vulnerabilities with it.

sorry but spoonfeeding with just a release thats hardcoded as 2000000 fixed. is still just kicking the can down the road.

ok so what is your permanent solution ?

BU and segwit are not going to happen. BU will never get unanimous support as it is pre-mature and not enough tested.
Segwit won’t either. The closer we get to that activation deadline the more likely both miners and core won't compromise.

meaning its not devs setting the setting. but offering a settings panel or a method for users to set what they want AFTER compiling and using it. thus not need continual spoonfeeding of devs

What I proposed is to distance ourselves from both development teams and create a neutral implementation, how is this spoon-feeding the devs?

[RodeoX]

What you are proposing is an alt coin, which is absolutely feasible. In fact no one can stop anyone from doing it. However the problem is not creating the coin but getting a consensus to move to your fork. That will be hard.

[puppy647]

What you are proposing is an alt coin, which is absolutely feasible. In fact no one can stop anyone from doing it. However the problem is not creating the coin but getting a consensus to move to your fork. That will be hard.

BU is also an altcoin . How is it going to be harder for segwit+2mb coin to get support than BU? 

[RodeoX]

What you are proposing is an alt coin, which is absolutely feasible. In fact no one can stop anyone from doing it. However the problem is not creating the coin but getting a consensus to move to your fork. That will be hard.

BU is also an altcoin . How is it going to be harder for segwit+2mb coin to get support than BU? 

It may be even easier? But still could be hard. There are so many competing interests now, ideas have quite a headwind to overcome.

[puppy647]

What you are proposing is an alt coin, which is absolutely feasible. In fact no one can stop anyone from doing it. However the problem is not creating the coin but getting a consensus to move to your fork. That will be hard.

BU is also an altcoin . How is it going to be harder for segwit+2mb coin to get support than BU? 

It may be even easier? But still could be hard. There are so many competing interests now, ideas have quite a headwind to overcome.

Let me ask you a question. If an anon published the code for segwit+2mb, that the code has been reviewed by multiple developers and has miners support. Would you run it?  If not why?

[puppy647]

What you are proposing is an alt coin, which is absolutely feasible. In fact no one can stop anyone from doing it. However the problem is not creating the coin but getting a consensus to move to your fork. That will be hard.

BU is also an altcoin . How is it going to be harder for segwit+2mb coin to get support than BU?  

There are so many competing interests now.

Exactly. There is a reason satoshi decided to remain anonymous, it was to keep the protocol as neutral as possible.
If satoshi ’s identity was known people would turn to him for advice about scaling which would ultimately influence the crowd

When there is such strong disagreement within the community the best course of action is to go back to the roots and use an anon implementation, free of politics that can satisfy both camps.

[franky1]

meaning its not devs setting the setting. but offering a settings panel or a method for users to set what they want AFTER compiling and using it. thus not need continual spoonfeeding of devs

What I proposed is to distance ourselves from both development teams and create a neutral implementation, how is this spoon-feeding the devs?

because simply changing a 1 to a 2. is just kicking the stone down the road. where the community then have to beg devs for a 3 instead of a 2

thus we are playing the oliver twist script of "please sir can i have some more"  dev:"MORE!?!?!"
then the devs spoonfeeding an implementations with 3000000 instead of 2000000

however if devs just have an options/setting where, while compiled people can just change the value themselves.. there would be no spoonfeeding and no kicking the can down the road, and no 2 year waiting for the less technical people to be spoonfed, because they can feed themselves

which is the whole point of bitcoin

[mtnsaa]

I don't think this will be as easy as it sounds since there are two opposite sides that won't back down. To me this is an issue that will only intensify in the upcoming months and it's very overlooked. SegWit won't happen anytime soon and this could create a temporary bear season for BTC. There are a lot of devs and people in the know that already said that there's a strong possibility of a hard fork. Many should do some research because a lot of US companies and early adopters of Bitcoin like Circle are dropping out or steering away from it (Coinbase). I feel it is because of all these disagreements and lack of development progress.

[puppy647]

meaning its not devs setting the setting. but offering a settings panel or a method for users to set what they want AFTER compiling and using it. thus not need continual spoonfeeding of devs

What I proposed is to distance ourselves from both development teams and create a neutral implementation, how is this spoon-feeding the devs?

because simply changing a 1 to a 2. is just kicking the stone down the road. where the community then have to beg devs for a 3 instead of a 2

thus we are playing the oliver twist script of "please sir can i have some more"  dev:"MORE!?!?!"
then the devs spoonfeeding an implementations with 3000000 instead of 2000000

however if devs just have an options/setting where, while compiled people can just change the value themselves.. there would be no spoonfeeding and no kicking the can down the road, and no 2 year waiting for the less technical people to be spoonfed, because they can feed themselves

which is the whole point of bitcoin

It is not simply changing 1 to 2. The fork would include segwit too. The bump to 2 is merely to give what miners and some users want which is a block size increase.  As Charlie Lee said, if segwit had not been 'advertised' as a scaling solution there would be no discussion as to whether it should be implemented or not.

[puppy647]

I don't think this will be as easy as it sounds since there are two opposite sides that won't back down.

The 2 opposite sides could quickly become irrelevant, most people want a bitcoin free from drama and politics. All the noise you hear is made by a small minority. If you look at software signaling graph you will see that most of the hashing power is not voting for anything, these miners are just waiting for community consensus. This is also why I doubt BU will get more than 50% hashing power in the current state of affairs, however if segwit doesn't activate before deadline and no block size increase from core is made I believe BU could gain more support from the community and so miners will follow.

As you said a hard fork is inevitable if no compromise is agreed upon, so if we are going to do a hard fork how about do one that is not contentious?  how about we leave the politics aside and move forward ?