What is changed in BU software besides removing the block size limit? how could someone attack BU nodes and not Core nodes while the Core rules were in place and obeyed? that shows BU software is something different than what it should be, they've tailored the code to their liking, made it seem exclusive aka closed source.
Anyways as long as the majority (nodes/miners/pools) agrees on any change ( consensus) we should follow the majority as minority always doomed.
Topic: SegWit2MB does nothing at all to fix the real problem - page 2. (Read 1563 times)
This is something I've been saying and worried about, while Segwit looks like it is becoming the only option for really changing the blocksize due to some of the plans BU has in mind, they also aren't doing well in their own way and it just holes up more power for those that design the system. I have said we need more devs coming forward with their own solutions. The question becomes whether or not we'll see any of those.
So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else?
It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either.
Quote
to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands.
- Jeff GarzikQuote
implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal.
- Olivier Janssensyup. should have been done that way from day -1. never should have released the software without it. now we'll never even get the consensus needed to implement this, because it would still be a fork.
So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else?
If you're talking about Antpool, it's more like 15% than 50%. Not even close. Giant pools supporting BU do show what BU would actually do though. 
Now those clever fuckers at Blockstream seem to want to concede somewhat. However, SegWit with 2MB does NOTHING to get rid of the real problem. The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors.
SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream.
Fuck Core/Blockstream and their SegWit2MB
SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream.
Fuck Core/Blockstream and their SegWit2MB
Get out of here with your crazy theories. If you re so worried just FORK ALREADY.
The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors.
Incorrect. Nobody can force you to use their "private sidechains".
There are a LOT of 2nd layer proposals, not only the centralized ones. I'm also against centralized sidechains and a centralized LN. But the possibilities of 2nd layers go far beyond that. Read, for example, the "Drivechain" proposal - it would give the additional income to miners. The same is true for "extension blocks" (a form of "sharding" where a second type of blocks is introduced that must not be processed by all nodes/miners). Only problem is that there is an opcode missing.
For me, 2 MB with segwit is enough for now - it would be a maximal 8 MB (base + weight) block size. Realistically, it would be a 3x to 4x increase of the actual capacity - and that would be enough for the coming 3-4 years.
this is looking good and all, but it's even feasible, no other dev talk about this possibility, did you test it in testnet? and it work? also this remind me of the solution for the longest chain in case of a 51% attack, and the logest chain should not be the one that count longest
?? your quoting about transaction FEE's but responding about longest chains??
new priority fee formulae needs to be introduced that cannot be easily countered by just using more btc VALUE as your change back to yourself per tx like the old formulae did..
soo..
soo..
so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat.
lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.
and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae which was more about the value of the tx
where if they want to spend more then once a day, then obviously things like LN would be of benefit
as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price
lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.
and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae which was more about the value of the tx
where if they want to spend more then once a day, then obviously things like LN would be of benefit
as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price
this is looking good and all, but it's even feasible, no other dev talk about this possibility, did you test it in testnet? and it work? also this remind me of the solution for the longest chain in case of a 51% attack, and the logest chain should not be the one that count as the longest
So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else?
pool can only make something the nodes will accept..
it might help if you understood dynamics... so here goes
imagine a case where there were 2 limits.(4 overal 2 for nodes 2 for pools)
hard technical limit that everyone agree's on. and below that a preference limit (adjustable to demand of dynamics).
now imagine
we call the hard technical limit (like old consensus.h) that only moves when the NETWORK as a whole has done speed tests to say what is technically possible and come to a consensus.
EG 8mb has been seen as acceptable today by all speed tests.
the entire network agrees to stay below this, pools and nodes
as a safety measure its split up as 4mb for next 2 years then 8mb 2 years after that..
thus allowing for upto 2-4 years to tweak and make things leaner and more efficient and allow time for real world tech to enhance.
(fibre obtic internet adoption and 5G mobile internet) before stepping forward the consensus.h again
then the preferential limit(further safety measure) that is adjustable and dynamic (policy.h) and keeps pools and nodes inline in a more fluid temporary adjustable agreement. to stop things moving too fast. but fluid if demand occurs
now then, nodes can flag the policy.h whereby if the majority of nodes preferences are at 2mb. pools consensus.h only goes to 1.999
however if under 5-25% of nodes are at 2mb and over 75% of nodes are above 2mb. then POOLS can decide on the orphan risk of raising their pools consensus.h above 2mb but below the majority node policy
also note: pools actual block making is below their(pools) consensus.h
lets make it easier to imagine.. with a picture
black line.. consensus.h. whole network RULE. changed by speed tests and real world tech / internet growth over time (the ultimate consensus)
red line.. node policy.h. node dynamic preference agreement. changed by dynamics or personal preference
purple line.. pools consensus.H. below network RULE. but affected by mempool demand vs nodes overall preference policy.h vs (orphan)risk
orange line.. pools policy.h below pools consensus.h
so imagine
2010
32mb too much, lets go for 1mb
2015
pools are moving thier limit up from 0.75mb to 0.999mb
mid 2017
everyone agree's 2 years of 4mb network capability (then 2 years of 8mb network capability)
everyone agree's to 2mb preference
pools agree their max capability will be below everyones network capability but steps up due to demand and node preference MAJORITY
pools preference(actual blocks built). below other limits but can affect the node minority to shift(EB)
mid 2019
everyone agree's 2 years of 8mb network capability then 2 years of 16mb network capability
some move preference to 4mb, some move under 3mb some dont move
late 2019
MINORITY of nodes have their preference shifted by dynamics of (EB)
2020
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
late 2020
MINORITY of nodes have their preference shifted by dynamics of (EB)
2021
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
mid 2021
a decision is made whereby nodes preference and pools preference are safe to control blocks at X% scaling per difficulty adjustment period
pools preference(actual blocks built). below other limits but can shift the MINORITY nodes preference via (EB) should they lag behind
p.s
its just a brainfart. no point knit picking the numbers or dates. just read the concept. i even made a picture to keep peoples attention span entertained.
and remember all of these 'dynamic' fluid agreements are all extra safety limits BELOW the black network consensus limit
hard technical limit that everyone agree's on. and below that a preference limit (adjustable to demand of dynamics).
now imagine
we call the hard technical limit (like old consensus.h) that only moves when the NETWORK as a whole has done speed tests to say what is technically possible and come to a consensus.
EG 8mb has been seen as acceptable today by all speed tests.
the entire network agrees to stay below this, pools and nodes
as a safety measure its split up as 4mb for next 2 years then 8mb 2 years after that..
thus allowing for upto 2-4 years to tweak and make things leaner and more efficient and allow time for real world tech to enhance.
(fibre obtic internet adoption and 5G mobile internet) before stepping forward the consensus.h again
then the preferential limit(further safety measure) that is adjustable and dynamic (policy.h) and keeps pools and nodes inline in a more fluid temporary adjustable agreement. to stop things moving too fast. but fluid if demand occurs
now then, nodes can flag the policy.h whereby if the majority of nodes preferences are at 2mb. pools consensus.h only goes to 1.999
however if under 5-25% of nodes are at 2mb and over 75% of nodes are above 2mb. then POOLS can decide on the orphan risk of raising their pools consensus.h above 2mb but below the majority node policy
also note: pools actual block making is below their(pools) consensus.h
lets make it easier to imagine.. with a picture
black line.. consensus.h. whole network RULE. changed by speed tests and real world tech / internet growth over time (the ultimate consensus)
red line.. node policy.h. node dynamic preference agreement. changed by dynamics or personal preference
purple line.. pools consensus.H. below network RULE. but affected by mempool demand vs nodes overall preference policy.h vs (orphan)risk
orange line.. pools policy.h below pools consensus.h
so imagine
2010
32mb too much, lets go for 1mb
2015
pools are moving thier limit up from 0.75mb to 0.999mb
mid 2017
everyone agree's 2 years of 4mb network capability (then 2 years of 8mb network capability)
everyone agree's to 2mb preference
pools agree their max capability will be below everyones network capability but steps up due to demand and node preference MAJORITY
pools preference(actual blocks built). below other limits but can affect the node minority to shift(EB)
mid 2019
everyone agree's 2 years of 8mb network capability then 2 years of 16mb network capability
some move preference to 4mb, some move under 3mb some dont move
late 2019
MINORITY of nodes have their preference shifted by dynamics of (EB)
2020
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
late 2020
MINORITY of nodes have their preference shifted by dynamics of (EB)
2021
MINORITY nodes manually change their preference to not be controlled by dynamics of (EB)
mid 2021
a decision is made whereby nodes preference and pools preference are safe to control blocks at X% scaling per difficulty adjustment period
pools preference(actual blocks built). below other limits but can shift the MINORITY nodes preference via (EB) should they lag behind
p.s
its just a brainfart. no point knit picking the numbers or dates. just read the concept. i even made a picture to keep peoples attention span entertained.
and remember all of these 'dynamic' fluid agreements are all extra safety limits BELOW the black network consensus limit
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else?
It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either.
Quote
to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands.
- Jeff GarzikQuote
implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal.
- Olivier Janssens
So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else?
SegWit has no chance to be activated (it does only 5% of incompatible blocks to activate while the camp Bitcoin Unlimited and Bitcoin Classic is very strongly opposed and mine already 40% of the blocks). Second, SegWit introduces a step backward it multiplies the size of blocks by 4 for only double the throughput of transactions-chain. It creates greater centralisation because being rich allow to create a hub of major transaction (more on deposits, more you can have links). This will make banks, exchanges and States the new masters of the money
new priority fee formulae needs to be introduced that cannot be easily countered by just using more btc VALUE as your change back to yourself per tx like the old formulae did..
soo..
soo..
so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat.
lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.
and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae which was more about the value of the tx
where if they want to spend more then once a day, then obviously things like LN would be of benefit
as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price
lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours.
and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae which was more about the value of the tx
where if they want to spend more then once a day, then obviously things like LN would be of benefit
as you can see its not about tx value. its about bloat and age.
this way
those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain.
if you are willing to wait a day but your taking up 1% of the blockspace. you pay more
if you want to be a spammer spending every block. you pay the price
and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price
Now those clever fuckers at Blockstream seem to want to concede somewhat. However, SegWit with 2MB does NOTHING to get rid of the real problem. The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors.
SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream.
Fuck Core/Blockstream and their SegWit2MB
SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream.
Fuck Core/Blockstream and their SegWit2MB
That is the big disadvantage of using segwit, we cannot guarantee to decrease the miners fee and other fees perhaps. There are many rumors spreading around such as an increased in the fees much higher than what we are paying now. It sounds discouraging but what we can do we are only holders that hopes when segwit will take over the fees will reduced.
Now those clever fuckers at Blockstream seem to want to concede somewhat. However, SegWit with 2MB does NOTHING to get rid of the real problem. The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors.
SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream.
Fuck Core/Blockstream and their SegWit2MB
SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream.
Fuck Core/Blockstream and their SegWit2MB
Jump to: