I want to ask if it's possible to somewhat combine these two solutions.
The goal of BU is to gain control of the Bitcoin name and software (Roger Ver already owns bitcoin.com). So BU will never "compromise" since that fails to achieve the goal.
Topic: Compromise between SegWit and BU (Read 5753 times)
The goal of BU is to gain control of the Bitcoin name and software (Roger Ver already owns bitcoin.com). So BU will never "compromise" since that fails to achieve the goal.
How about implement Bitpay adaptive block size aside of SegWit?
https://github.com/bitpay/bitcoin/issues/42
https://github.com/bitpay/bitcoin/issues/42
It has the same problem as Unlimited: Can easily be gamed.
In BIP 100/106 a try to game the system to get really high block size value would last years and would be prohibitively expensive (if the increment rate is 5%).
How about implement Bitpay adaptive block size aside of SegWit?
https://github.com/bitpay/bitcoin/issues/42
https://github.com/bitpay/bitcoin/issues/42
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
It's technically possible, as already pointed out by others. But many of the community, including me, consider the Bitcoin Unlimited mechanism to be potentially dangerous as it maybe could lead to network splits and gives the mining pools too much power what could lead to centralization.
"Softer" flexible blockchain proposals are BIP 100 and 106. In this thread some of us are discussing a possibility to restrict miners' power in BIP 100 even further by imposing a hard-coded upper blocksize limit that only moves in slow steps, in addition to Segwit.
'Core' has failed to deliver ...
Core has delivered. If you like it or not is a different topic.
Bitcoin and its code is too important to be just 'liked or disliked' by a single individual.
I liked the fact that they delivered - made decisions and got sth out - hard task!!
I'm agnostic to things that work but are not full in line what I would do.
I only see that we have gotten nothing like German beer we all would agree that we like
What did you order, banana split ?
I still hope / like we can rather repair than throw away.
'Core' has failed to deliver ...
Core has delivered. If you like it or not is a different topic.
SPV Mining is the opposite of playing well!
We can get lost in any detail. The message to the outer world is claer: Bitcoin (as Satoshi designed) is rekt in any case if
nobody steps back from own prios - even with 1MB and no SW (reduced to bank like store of value and infinit tx costs).
'Core' has failed to deliver / merge the 'no-brainer' that fits to all.
Others take over.
Disruption is hard to take if it hits you.
SPV Mining is the opposite of playing well!
It's a natural resistance against Chinese coup d'état. No compromise should be made in such situation, no sane person would make a deal with terrorists.
It's a natural resistance from (Chinese) miners against blockstream terrorists.
Just two ways of view. (Hard for many here to see both, since most just are simple users and don't care about miners investments)
BTW: Miners do safe the blockchain and your bitcoins. They play it well as we see.
It's a natural resistance against Chinese coup d'état. No compromise should be made in such situation, no sane person would make a deal with terrorists.
Hello,
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
Miners can and already and do set the size of the block with soft limits , users set the upper end of the hard limit though . Giving miners control of the blocksize would centralize mining , set a bad precedent that the miners control validation rules and not economic users, and not account for externalities like the cost of nodes on processing the blocks leading to node drop off and centralization. Essentially creating paypal 2.0 with a mining cartel , where everyone eventually is forced to trust third parties instead of validating their own txs.
So , no thank you.
What is your very balanced counter offer ? SW + 2nd layer where 2nd layer will turn out to be the very same you not want?
Hello,
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
I have only a little knowledge about these scaling solutions so I want to ask if it's possible to somewhat combine these two solutions. Like, change the transaction protocol according to SegWit to allow off-chain solutions (Lighting Network) while letting the miners choose a size of the block. Is this possible?
Miners can and already and do set the size of the block with soft limits , users set the upper end of the hard limit though . Giving miners control of the blocksize would centralize mining , set a bad precedent that the miners control validation rules and not economic users, and not account for externalities like the cost of nodes on processing the blocks leading to node drop off and centralization. Essentially creating paypal 2.0 with a mining cartel , where everyone eventually is forced to trust third parties instead of validating their own txs.
So , no thank you.
edit: I opened a thread discuss to my suggestion : https://bitcointalksearch.org/topic/why-bitcoindev-prefer-to-segwit-we-should-represent-block-time-to-2-min-1827943
You're late to your own discussion by several months, this is not an original suggestion.
The block interval target is 10 minutes for important reasons: orphan rate, inherent latency of TCP/IP networks etc. It's also a hard fork change, and so much more could be done with any hard fork that relegates the importance of reducing the block interval target.
It's not the worst idea, but you're not really contributing anything useful by bringing this up for the Nth time.
If Chinese miners don't want to accept SegWit because of possible network issues, still we dont need to Bitcoin Unlimited.
Bitcoin Developers can develop new adaption like bitcoin block timing reduce to 2 minute (now 10 minute) and bitcoin block bounty can be reduced %50^5 percent. Doesn't change on ecosystem
edit: I opened a thread discuss to my suggestion : https://bitcointalksearch.org/topic/why-bitcoindev-prefer-to-segwit-we-should-represent-block-time-to-2-min-1827943
Bitcoin Developers can develop new adaption like bitcoin block timing reduce to 2 minute (now 10 minute) and bitcoin block bounty can be reduced %50^5 percent. Doesn't change on ecosystem
edit: I opened a thread discuss to my suggestion : https://bitcointalksearch.org/topic/why-bitcoindev-prefer-to-segwit-we-should-represent-block-time-to-2-min-1827943
So we are facing a HF I guess no !?
After reading a lot about BU and segwit, the problem with your proposition is the fact that BU just doesn't work. There is not a single "flexible blocksize" approach that properly works without opening nasty cans of worms. Therefore, the conservative approach is still the preferred one.
Better would be hard limit increase. But now we have to deal with block size.
solution like:
-we group blocks into superblocks like 5000 packages every node have to keep last 3 superblocks
-every time when we create superblock we create balance sheet for all adresses
-superblocks have to have conections between each other that you could use all from day 0 and be sure that you use good one superblock
- in such sytuaction blocksize doesn't matter so much and we can grow in size and transaction time.
2nd solution would be 3rd party layers to blockchain
After reading a lot about BU and segwit, the problem with your proposition is the fact that BU just doesn't work. There is not a single "flexible blocksize" approach that properly works without opening nasty cans of worms. Therefore, the conservative approach is still the preferred one.
@DannyHamilton
I think that I can say that mostly all BU supporters agree on enabling all the things of Segwit does as hard fork, after the block size hard fork.
You can already find the specifics to do this
https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/
There is also a proposal from BC:
https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki
So you can be sure that LN and all other good things that segwit is promising to enable, you will still have after a block size fork.
I think that I can say that mostly all BU supporters agree on enabling all the things of Segwit does as hard fork, after the block size hard fork.
You can already find the specifics to do this
https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/
There is also a proposal from BC:
https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki
So you can be sure that LN and all other good things that segwit is promising to enable, you will still have after a block size fork.
Lightning does not require SegWit, and SegWit already is a compromise on block size by increasing it to 4MB.
Couple of comments.
SegWit does not change the actual block size. It stays at 1 MB. That is why SegWit is a soft fork. Nodes running older versions will still accept it.
SegWit moves some data out of the block so that more transactions can fit into a 1 MB block.
The various versions of Lightning need SegWit to fix transaction malleability. It will be very difficult to introduce a version of Lightning if this is not fixed.
Exactly chinese miners and miner mafuf. trying to take over BTC. Main traitor Bitmain.
Jump to: