1MB is still silly..BU seems to be gaining traction .. :S..

[spazzdla]

BU is going to be the way we go?  Anything else out there besides segwit or BU? (like that is actually doing something). 

I don't know how I feel about nodes deciding block size.  Seems like a good idea but I also see the potential for a group to control the blocksize..

[1714231307]

1714231307

[1714231307]

1714231307

[1714231307]

1714231307

[manselr]

BU is going to be the way we go?  Anything else out there besides segwit or BU? (like that is actually doing something). 

I don't know how I feel about nodes deciding block size.  Seems like a good idea but I also see the potential for a group to control the blocksize..

The solution is already there: segwit, then once we get segwit, a blocksize increase, as suggested by all experts.

If this doesn't happen, blame the miners.

BU will never get anywhere, stop making threads about it.

[spazzdla]

I've never heard of this two step process before..

I like that idea.  IDGAF how we move forward but we must.

[franky1]

The solution is already there: segwit, then once we get segwit, a blocksize increase, as suggested by all experts.

blocksize only increases if USERS move funds over from native keys to segwit keys.

but..
malicious users will stick to native keys and continue spamming. so dont expect much of a change. and dont think that the problems are solved.
segwit is an empty temporary gesture that is dependant on users using segwit keys.

blockstream have bypassed node consensus. (for many negative/hidden reasons)
if it does not activate, blockstream stupidly shift the blame to the pools
if it activates blockstream take the glory (typical bait and switch)

yet even after activation. if users dont move funds to segwit keys
if it doesnt make a difference, blockstream stupidly shift the blame to the users
if it does make a difference blockstream take the glory (typical bait and switch)

pools are not 60%+ undecided because they prefer X instead of Y. they are undecided because they see segwits HIDDEN negatives and they see the promised positives are less than whats been promised.
plus pools wont push out blocks that are only 50% validation safe by nodes so although nodes dont get an official vote, pools will wait to see what nodes do, to know what is going to be FULLY validated(i dont mean compatibly 'accepted') by the majority of the network

[d5000]

Although Bitcoin Unlimited has increased its numbers regarding mined blocks and nodes, it is still very far away from a majority. The support for Bitcoin Core is still more than 7x higher, and also most users would prefer Core.

But Segwit is still stalled. I have still a bit of optimism that it could be adopted pressured by alt-coins like Litecoin adopting it (with miners agreeing to Segwit with the goal for BTC not losing market share) but even the Litecoin adoption is not sure so it's possible we will continue a year or so with the current stalemate, and that would be catastrophical for Bitcoin's mass adoption plans. There are altcoins with well-thought-out scalability systems like Byteball, Iota and Ardor - if they prove to work, then Bitcoin will have a hard time.

Wouldn't there be a new Roundtable Agreement possible? That would be the best plan, I think.

[panju1]

I've never heard of this two step process before..
I like that idea.  IDGAF how we move forward but we must.

It is not a 2 step. The first step (Segwit) seems to be dead on arrival.
We must move to a larger block size to deal with the problems of transaction backlog.

[spazzdla]

I've never heard of this two step process before..
I like that idea.  IDGAF how we move forward but we must.

It is not a 2 step. The first step (Segwit) seems to be dead on arrival.
We must move to a larger block size to deal with the problems of transaction backlog.

Yes we must but too many people have hard ons for their idea and won't budge.

Frankly I do not give a fuck what method as long as it makes some sense.

[unamis76]

There's Segwit, BU, Classic, XT and allegedly there's someone who found a way to have 100 tps without increasing blocksize, as seen on the forums a few weeks ago (although I doubt this is true...).

Both Segwit and BU adoption seem to be kind of stalled. At least they have moved more previously.

Frankly I do not give a fuck what method as long as it makes some sense.

Pretty much this, as long as it's still Bitcoin, makes sense and scales successfully according to our needs, I'm fine with it.

[Kprawn]

The solution is already there: segwit, then once we get segwit, a blocksize increase, as suggested by all experts.

blocksize only increases if USERS move funds over from native keys to segwit keys.

but..
malicious users will stick to native keys and continue spamming. so dont expect much of a change. and dont think that the problems are solved.
segwit is an empty temporary gesture that is dependant on users using segwit keys.

blockstream have bypassed node consensus. (for many negative/hidden reasons)
if it does not activate, blockstream stupidly shift the blame to the pools
if it activates blockstream take the glory (typical bait and switch)

yet even after activation. if users dont move funds to segwit keys
if it doesnt make a difference, blockstream stupidly shift the blame to the users
if it does make a difference blockstream take the glory (typical bait and switch)

pools are not 60%+ undecided because they prefer X instead of Y. they are undecided because they see segwits HIDDEN negatives and they see the promised positives are less than whats been promised.
plus pools wont push out blocks that are only 50% validation safe by nodes so although nodes dont get an official vote, pools will wait to see what nodes do, to know what is going to be FULLY validated(i dont mean compatibly 'accepted') by the majority of the network

Care to elaborate on that statement, because I am not aware of any method to bypass node consensus? In my view nothing will be implemented

if consensus is not reached with a 95% majority.  ... If Blockstream has done this, then why are we not seeing the benefit of SegWit & LN

features? This will be interesting, if this is true. 

[Ayers]

I've never heard of this two step process before..

I like that idea.  IDGAF how we move forward but we must.

bu is stupid if miners can't agree on hardforking to 2mb or 4mb what make you think they will enjoy BU? what i've heard is 2mb is possible this years if segwit is not activated, which look the case, otherwise they are going to not care until a very large amount of transaction will be delayed

[cellard]

There's Segwit, BU, Classic, XT and allegedly there's someone who found a way to have 100 tps without increasing blocksize, as seen on the forums a few weeks ago (although I doubt this is true...).

Both Segwit and BU adoption seem to be kind of stalled. At least they have moved more previously.

Frankly I do not give a fuck what method as long as it makes some sense.

Pretty much this, as long as it's still Bitcoin, makes sense and scales successfully according to our needs, I'm fine with it.

Im looking forward Sergio's stuff, he's the guy that is developing rootstock so we are in good hands. I don't like this teasing bullshit tho. Present the code or keep quiet until you have something to show, otherwise it will only lead to more speculation and probably a letdown if he can't deliver.

[numismatist]

United we stand, divided we'll fall.

There are some several coding projects out there that announce adaptable blocksize or blockchain structures that run in parallel (however timescale can apply there, that concept seems faulty) and they will eagerly dillute the initial ideal of a limited supply.
People watching this will consider sticking with traditional greenbacks instead.

[franky1]

blockstream have bypassed node consensus. (for many negative/hidden reasons)

Care to elaborate on that statement, because I am not aware of any method to bypass node consensus? In my view nothing will be implemented
if consensus is not reached with a 95% majority.   ... If Blockstream has done this, then why are we not seeing the benefit of SegWit & LN
features? This will be interesting, if this is true.  

blockstream only want activating segwit to be done via ONLY a POOL vote.. not the USERS NODES vote.

95% of blocks
not 95% of nodes
(soft =pools only... hard= nodes then pools)

i have already said several times. if blockstream want to give the 60%+ UNDECIDED POOLS confidence.
they need to get a pool that is 'segwit ready' to make a block including a segwit TX. to show how "compatible" the network is to not need to care about the user nodes.

right now althought user NODES are not part of the official vote. smart POOLS are still hesitant to flag desire either way without seeing what NODES can cope with. so although activation is only dependant on POOLS BLOCK flags.. POOLS wont flag until thier cautious and safety concerns are addressed

simpl solution for blockstream is to bribe BTCC with $13k (out of blockstreams $90m) to make a segwit block to see if the node network cause fuss or happily accept segwit.

then that would show how "backward compatible" blocks are.
..

but i see other issues. atleast doing a mainnet test will result in either a orphan.. or acceptance.

[jackg]

BU is going to be the way we go?  Anything else out there besides segwit or BU? (like that is actually doing something). 

I don't know how I feel about nodes deciding block size.  Seems like a good idea but I also see the potential for a group to control the blocksize..

I skimmed through this thread and didn't find it mentioned that the blocksize can already be changed by the miners/pools. Currently most of them have it set to 1MB so that's what they went with. by defaut (for some reason) it's at about 750KB (in core) so there has already been an increase at some point.
Other than increasing blocksizes, using segwit and attempting code to merge scripts (which may make new hacks) I don't think there are any other ways.

[Senor.Bla]

BU is going to be the way we go?  Anything else out there besides segwit or BU? (like that is actually doing something). 

I don't know how I feel about nodes deciding block size.  Seems like a good idea but I also see the potential for a group to control the blocksize..

I skimmed through this thread and didn't find it mentioned that the blocksize can already be changed by the miners/pools. Currently most of them have it set to 1MB so that's what they went with. by defaut (for some reason) it's at about 750KB (in core) so there has already been an increase at some point.
Other than increasing blocksizes, using segwit and attempting code to merge scripts (which may make new hacks) I don't think there are any other ways.

You can chose how full your blocks are that you mine. 750KB is the default, so about 75% of the maximum. But you can not chose a bigger number than 1MB. The talk about increasing the Blocksize is a debate about increasing the maximum Blocksize.

If BU will gain more support and SegWit will clearly be not going to happen, then i imagine that Core is prepared to adopt a new strategy where they make a BU like suggestion in order to give the mines and user what they want but on the terms of core (so maybe minor changes compared to BU). The pressure would have to be big enough and adopting BU just around the corner to see this.

[jackg]

BU is going to be the way we go?  Anything else out there besides segwit or BU? (like that is actually doing something). 

I don't know how I feel about nodes deciding block size.  Seems like a good idea but I also see the potential for a group to control the blocksize..

I skimmed through this thread and didn't find it mentioned that the blocksize can already be changed by the miners/pools. Currently most of them have it set to 1MB so that's what they went with. by defaut (for some reason) it's at about 750KB (in core) so there has already been an increase at some point.
Other than increasing blocksizes, using segwit and attempting code to merge scripts (which may make new hacks) I don't think there are any other ways.

You can chose how full your blocks are that you mine. 750KB is the default, so about 75% of the maximum. But you can not chose a bigger number than 1MB. The talk about increasing the Blocksize is a debate about increasing the maximum Blocksize.

If BU will gain more support and SegWit will clearly be not going to happen, then i imagine that Core is prepared to adopt a new strategy where they make a BU like suggestion in order to give the mines and user what they want but on the terms of core (so maybe minor changes compared to BU). The pressure would have to be big enough and adopting BU just around the corner to see this.

Yes, but changing the blocksize setting on your copy of bitcoin core, if you're a miner and many others do the same, will increase the blocksize. The network is configured by how nodes function. There is no central server that dictates the blocks are too large and rejects them. If enough miners change their blocksize limits then the limits of the entire network will be increased (if a small percentage of miners still use smaller blocks then they will also be added to the network but there's quite a good incentive to increase the price → you get more bitcoins from mining as a reward).

[Senor.Bla]

BU is going to be the way we go?  Anything else out there besides segwit or BU? (like that is actually doing something). 

I don't know how I feel about nodes deciding block size.  Seems like a good idea but I also see the potential for a group to control the blocksize..

I skimmed through this thread and didn't find it mentioned that the blocksize can already be changed by the miners/pools. Currently most of them have it set to 1MB so that's what they went with. by defaut (for some reason) it's at about 750KB (in core) so there has already been an increase at some point.
Other than increasing blocksizes, using segwit and attempting code to merge scripts (which may make new hacks) I don't think there are any other ways.

You can chose how full your blocks are that you mine. 750KB is the default, so about 75% of the maximum. But you can not chose a bigger number than 1MB. The talk about increasing the Blocksize is a debate about increasing the maximum Blocksize.

If BU will gain more support and SegWit will clearly be not going to happen, then i imagine that Core is prepared to adopt a new strategy where they make a BU like suggestion in order to give the mines and user what they want but on the terms of core (so maybe minor changes compared to BU). The pressure would have to be big enough and adopting BU just around the corner to see this.

Yes, but changing the blocksize setting on your copy of bitcoin core, if you're a miner and many others do the same, will increase the blocksize. The network is configured by how nodes function. There is no central server that dictates the blocks are too large and rejects them. If enough miners change their blocksize limits then the limits of the entire network will be increased (if a small percentage of miners still use smaller blocks then they will also be added to the network but there's quite a good incentive to increase the price → you get more bitcoins from mining as a reward).

I think it is a bit more complicated then just changing one line of code and replacing "Max_Blocksize = 1 MB" with "Max_Blocksize = 2 MB". If the limit of the entire network will be increased like you suggested, then the small percentage of miners (and nodes) who use smaller blocks would fork, as they would consider blocks with a size of >1MB as invalid. This could be quite many miners and nodes. Also many are looking for a more permanent solution.

[jackg]

BU is going to be the way we go?  Anything else out there besides segwit or BU? (like that is actually doing something). 

I don't know how I feel about nodes deciding block size.  Seems like a good idea but I also see the potential for a group to control the blocksize..

I skimmed through this thread and didn't find it mentioned that the blocksize can already be changed by the miners/pools. Currently most of them have it set to 1MB so that's what they went with. by defaut (for some reason) it's at about 750KB (in core) so there has already been an increase at some point.
Other than increasing blocksizes, using segwit and attempting code to merge scripts (which may make new hacks) I don't think there are any other ways.

You can chose how full your blocks are that you mine. 750KB is the default, so about 75% of the maximum. But you can not chose a bigger number than 1MB. The talk about increasing the Blocksize is a debate about increasing the maximum Blocksize.

If BU will gain more support and SegWit will clearly be not going to happen, then i imagine that Core is prepared to adopt a new strategy where they make a BU like suggestion in order to give the mines and user what they want but on the terms of core (so maybe minor changes compared to BU). The pressure would have to be big enough and adopting BU just around the corner to see this.

Yes, but changing the blocksize setting on your copy of bitcoin core, if you're a miner and many others do the same, will increase the blocksize. The network is configured by how nodes function. There is no central server that dictates the blocks are too large and rejects them. If enough miners change their blocksize limits then the limits of the entire network will be increased (if a small percentage of miners still use smaller blocks then they will also be added to the network but there's quite a good incentive to increase the price → you get more bitcoins from mining as a reward).

I think it is a bit more complicated then just changing one line of code and replacing "Max_Blocksize = 1 MB" with "Max_Blocksize = 2 MB". If the limit of the entire network will be increased like you suggested, then the small percentage of miners (and nodes) who use smaller blocks would fork, as they would consider blocks with a size of >1MB as invalid. This could be quite many miners and nodes. Also many are looking for a more permanent solution.

That's not really true? My bitcoin core software is set tothe default of 750kb because I don't mine with it and it syncronies with blocks greater than that amount. It doesn't reject the blocks, like you suggested. However, it would take quite a lot to get the majority vote of the mining power (around 95% it was for segwit) before the blocks were acceptd so of course the majority of miners have to accept the new block. But, if companies like Bitmain, Bitfury and the other giant mining firms considered changing that then the blocksize could increse (but it'd still take the 95% to change that).

[franky1]

That's not really true? My bitcoin core software is set tothe default of 750kb because I don't mine with it and it syncronies with blocks greater than that amount. It doesn't reject the blocks, like you suggested. However, it would take quite a lot to get the majority vote of the mining power (around 95% it was for segwit) before the blocks were acceptd so of course the majority of miners have to accept the new block. But, if companies like Bitmain, Bitfury and the other giant mining firms considered changing that then the blocksize could increse (but it'd still take the 95% to change that).

yep meaning out of say 6000 nodes only 300 nodes will rect blocks and end up unsynced and lft in orphan hell

and 1 out of 20 pools would end up in orphan hell wher the blocks they try to create wont get height. so that pool and 300 nodes would eventually upgrade to stay with the network rather than be left unsynced in orphan hell.

remember
consensus(minority in orphan hell, not syncing)
is different to
bilateral split (intentionally banning oppositions communication's and avoiding orphans to form an altcoin)

[jackg]

That's not really true? My bitcoin core software is set tothe default of 750kb because I don't mine with it and it syncronies with blocks greater than that amount. It doesn't reject the blocks, like you suggested. However, it would take quite a lot to get the majority vote of the mining power (around 95% it was for segwit) before the blocks were acceptd so of course the majority of miners have to accept the new block. But, if companies like Bitmain, Bitfury and the other giant mining firms considered changing that then the blocksize could increse (but it'd still take the 95% to change that).

yep meaning out of say 6000 nodes only 300 nodes will rect blocks and end up unsynced and lft in orphan hell

and 1 out of 20 pools would end up in orphan hell wher the blocks they try to create wont get height. so that pool and 300 nodes would eventually upgrade to stay with the network rather than be left unsynced in orphan hell.

remember
consensus(minority in orphan hell, not syncing)
is different to
bilateral split (intentionally banning oppositions communication's and avoiding orphans to form an altcoin)

Oooh, the network is much more decentralised then when I last checked this.
You'd have to get the majority of them to comply with the new rules before they are submitted and added so if they're not added in the sotware then it is much more difficult to get them all to agree and the company with a 10% stake in mining shares could just "accidently forget to change it for an hour" meaning they get all of the rewards for that hour!