Yep.. BU absolutely definitely possibly maybe ready for prime time..

[AngryDwarf]

BU's acceptance depth approach, I consider it to be a terrible approach to bigger blocks.

Usually 6 confirms is considered as statistically set in stone. Not with BU, all of a sudden a bigger block might fall through the gate causing a chain reorganisation and potentially the transaction might not have any confirmations at all due to the mining policy on the new longer chain.

It's overcomplicated approach introduces new economic risks, even if its bugs are fixed.

I am all for bigger blocks. However you can call BU Bitcoin Unavailable, Bitcoin Uncredible, Bitcoin Unneeded or the Bitcoin Undead for all I care.

[iamTom123]

We all know that BU does not have great coders and is terrible. Only the big block shills will say different.

Yes their dev team looks like don't have enough coding knowledge or time to fix one problem for over a month. They are aware of this bug for several months now but they haven't been successful to find a better solution to this.

How they can expect to gain support from bitcoin community if they can't deliver a proper stable software.

They need better and more experienced people behind to make things working well and really be deserving to be the one chosen to solve the current problems bugging Bitcoin for years. This another crash can already be putting more nails into its coffin as confidence and trust are two important elements in the cryptocurrency world. We all have our own financial interest and we should be able to protect them as no one else will.

[franky1]

BU's acceptance depth approach, I consider it to be a terrible approach to bigger blocks.

Usually 6 confirms is considered as statistically set in stone. Not with BU, all of a sudden a bigger block might fall through the gate causing a chain reorganisation and potentially the transaction might not have any confirmations at all due to the mining policy on the new longer chain.

It's overcomplicated approach introduces new economic risks, even if its bugs are fixed.

I am all for bigger blocks. However you can call BU Bitcoin Unavailable, Bitcoin Uncredible, Bitcoin Unneeded or the Bitcoin Undead for all I care.

imagine this though..

ALL nodes had a 1mb block consensus rule

but below that they had lets say a preference of .. well lets say the majority was viewed as preferring 0.25 in 2011 and where they would accept 0.25+ only after 6 confirms

it does not break the consensus rules. but does publicly show pools that the majority of node prefer only 0.25mb blocks.

pools wont want to go passed 0.25 because the majority of nodes wont like it.
(the nodes would accept the blocks, but wont treat them as set in stone unless 5 other blocks are ontop)

the pools would weigh upt the pro's and cons of going passed 0.25 much more wisely, rather than just doing it
EG pool A may want to make a block 0.26mb but pool B,C,D,E,F,G  are building blocks that are only 0.249
so theres a chance pool A's block may get orphaned.

but all nodes would still be all on one chain due to all blocks being under 1mb.. the dynamics is just about orphan risk not chain splitting(altcoin creating)

now say its 2012 and nodes moved their preference of to a majority of 0.5mb..
EG pool B,C,D,E,F,G that were listening to community demand will happily make blocks over 0.25mb meaning so can pool A without any orphan risk

as you can see this is not about causing chain splits because all blocks under 1mb are acceptable. all its doing is keeping pools under control

[AngryDwarf]

Sorry franky1, but I think under BU's acceptance depth mechanism, every time some miners want to up the limit there becomes a temporary chain split with orphan drama as the miners fight out whether the block size can be upped or not. An acceptance depth of '1' simplifies things a lot.

[Lauda]

you would use LN to pay small amounts randomly multiple times a day..

Who said anything about small amounts? Now you are advertising LN? That is ironic.

you would decide that your sig campaign management should adapt in daily batches to cut costs onchain instead of many times a day.

I don't make any signature campaign payments on Bitcoin. You're confused.

whats wrong with paying $60 fee.. thats only 8 hours minimum wage labour in UK/america??

now you may emotionally understand third world countries where for the last year you and others have said 40c (8hour labour) is ok

False comparison.

your stuck in the 'its us or them' corporate takeover mindset..

There is "us", as in the people who are in Bitcoin for the right reasons. Then there is "them", all kinds of groups wanting to attack Bitcoin (see BTU).

imagine this though..

-snip-
as you can see this is not about causing chain splits because all blocks under 1mb are acceptable. all its doing is keeping pools under control

You don't even understand how EC works. Your comparison makes zero sense. EC allows for chain reorganizations, it's technically a "feature". Your script is wrong.

[franky1]

Sorry franky1, but I think under BU's acceptance depth mechanism, every time some miners want to up the limit there becomes a temporary chain split with orphan drama as the miners fight out whether the block size can be upped or not. An acceptance depth of '1' simplifies things a lot.

its not a chain split.
both blocks are stored and accepted. just not treated as set in stone until which ever one gets the 6th confirm (5 blocks ontop)

its actually avoiding chain splits happening so easily because both block A at 0.26 and block B 0.249 sit in the node.

however if block B gets built on for next 5 blocks then block A is rejcted.

its not about altcoin creation.. just about orphan drama.. which if you check the stats is happening all the time anyway.
orphan mechanism is a good thing. its the shield that throws out what the network as a whole doesnt agree with.

it makes pools think before they act. and to keep pools inline with what the network find acceptable.

[AngryDwarf]

Sorry franky1, but I think under BU's acceptance depth mechanism, every time some miners want to up the limit there becomes a temporary chain split with orphan drama as the miners fight out whether the block size can be upped or not. An acceptance depth of '1' simplifies things a lot.

its not a chain split.
both blocks are stored and accepted. just not treated as set in stone until which ever one gets the 6th confirm (5 blocks ontop)

its actually avoiding chain splits happening so easily because both block A at 0.26 and block B 0.249 sit in the node.

however if block B gets built on for next 5 blocks then block A is rejcted.

its not about altcoin creation.. just about orphan drama.. which if you check the stats is happening all the time anyway.
orphan mechanism is a good thing. its the shield that throws out what the network as a whole doesnt agree with.

it makes pools think before they act. and to keep pools inline with what the network find acceptable.

You could end up with a network with a multitude of different excessive block and acceptance depth settings. That sounds like a complete clusterfuck to me.

[franky1]

whats wrong with paying $60 fee.. thats only 8 hours minimum wage labour in UK/america??

now you may emotionally understand third world countries where for the last year you and others have said 40c (8hour labour) is ok

False comparison.

get your mind out of first world only mindset

8 hours labour for millions of people you deem ok.. you have said it many times.. "40c is cheap"
... right up until you start seeing that fee's of 8 hours .. are in prices of first world countries '8 hours'

atleast wake up to the point.. you have been dribbling for a year now that 8 hours labour is ok.. so whats wrong with you paying $60

$60 is only 8 hours labour. you have been telling the third world and many unbanked countries that 8 hours labour is fine/cheap for a year

[franky1]

You could end up with a network with a multitude of different excessive block and acceptance depth settings. That sounds like a complete clusterfuck to me.

or
pools see it can be a cluster fuck and dont go passed a limit unless majority of preference says its not going to be a clusterfuck

[AngryDwarf]

You could end up with a network with a multitude of different excessive block and acceptance depth settings. That sounds like a complete clusterfuck to me.

or
pools see it can be a cluster fuck and dont go passed a limit unless majority of preference says its not going to be a clusterfuck

A simple block acceptance size with an acceptance depth of '1' achieves that without the unnecessary complexity.

[franky1]

You could end up with a network with a multitude of different excessive block and acceptance depth settings. That sounds like a complete clusterfuck to me.

or
pools see it can be a cluster fuck and dont go passed a limit unless majority of preference says its not going to be a clusterfuck

A simple block acceptance size with an acceptance depth of '1' achieves that without the unnecessary complexity.

the blocks are "accepted" EG say a block A 0.251 received and also block B 0.249
(both accepted because they are both under 1mb consensus)
both sit there accepted.. but not set in stone.

yes some nodes are happy to accept blocks upto 0.5 some are happy with 0.25 and some are happy with 0.25 only after 6 confirms.

but all are holding both blocks until conditions are met.

the acceptable depth is the deterrent.. for pools
it adds a bit of risk to the pools to not push forward too quick, because nodes may reject them if other pools are following the node 'preference' majority

pools wont want to risk going to 0.26 unless high majority say its ok. because their is a risk their 0.26 block may get rejected if the majority dont want anything above 0.25

thus if the other pools were building on block B.. A will drop off once B gets its 5th confirm

however lets say the 'majority threshold was 75%

if there was 75% acceptance of 0.3 where by looking further at nodes its seen 80% acceptance of 0.25
pools would work out the risks of going to 0.3. by looking at the acceptable depth of the group below 0.3mb.
if everyone had only 1 AD then pools will say yep very small chance of orphan risk going to 0.3..
but if there was AD12.. pools may say, hmm maybe best to stick with 0.25mb and re-assess later as there is a chance that if i make a 0.26mb block other pools may not. due to such a high AD

(yes im using low numbers of blocksize so people can imagine dynamics in a scenario of 1mb consensus but where nodes had dynamic 'preference' below that since 2009) thus nodes having more control over what pools move to.

(please dont just take the reddit doomsday scenario rhetoric as gospel. do proper independent research)

remember all these blocks are still under 1mb. so its still going to be just 1 chain. in the end. its just a way to deter pools from jumping the gun rushing to 1mb 2009-2017 by knowing some nodes prefer only 0.x..
and pools become more obliged to follow node preference because their competitors pools may only build ontop of node preference.

[AngryDwarf]

You could end up with a network with a multitude of different excessive block and acceptance depth settings. That sounds like a complete clusterfuck to me.

or
pools see it can be a cluster fuck and dont go passed a limit unless majority of preference says its not going to be a clusterfuck

A simple block acceptance size with an acceptance depth of '1' achieves that without the unnecessary complexity.

the blocks are "accepted" EG say a block A 0.251 received and also block B 0.249
both sit there accepted.. but not set in stone.
the acceptable depth is the deterrent.. for pools

pools wont want to risk going to 0.26 unless high majority say its ok. bcause their is a risk their 0.26 block may get rejected if the majoriry dont want anything above 0.25 (yes im using low numbers so people can imagine dynamics in a scenario of todays 1mb consensus and nodes 'preference' below that)

Acceptance size set at 0.25, Block A gets rejected end of. Block B gets built on. Acceptance size moved to 0.3, Block A or B win the block propagation race as exists now an will get built on with blocks of up to 0.3MB in size.

Personally I think it's time to get rid of this protocol enforced block size limits all together. We have SPV wallets now. Miners should be able to create blocks of dynamic sizes which they see fit to maintain the network and manage the network mempool demand with slight fee pressure.
The protocol enforced limit is creating problems that need to be solved. Removing it means it will be working as intended in accordance with the original whitepaper.
There are enough exchanges, online wallets, payment providers, other businesses that can cope with data centre traffic levels to ensure the blockchain database is validated and distributed. Let the miners get on with building the blockchain.