What happens if BU fails VS What happens if SegWit fails

[Senor.Bla]

Let us try an new perspective to the whole block size debate.
Two scenarios i like to discuss.

1. BU gets the support and we all hard fork to BU, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? Another fork? Can we still go to SegWit at this point? Something else?

2. SegWit gets the support and we all soft fork to SegWit, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? A hard fork? Can we still go to BU at this point? Something else?

[1714064341]

1714064341

[1714064341]

1714064341

[1714064341]

1714064341

[Carlton Banks]

BU breaking is guaranteed, 100%. It's design basically is an attack waiting to happen.


Segwit breaking isn't guaranteed, but not impossible.

[franky1]

as unbiased as possible

with BU
users still use native keypairs. the thing is when a hard consensus activates a bilateral split does NOT occur... also pools WONT jump straight to filling a block right to the top of the limit. they will try a block at 1.001mb first and see what the orphan risk is. and progress from there. it may take hours or months depending on safety/demand for it to actually hit the new limit.

so lets say there was issue with blocks over 1mb.. pools simply mine 0.999mb blocks again.. end of drama



with segwit
SW positions pools and segwit nodes as upstream filters and users need to move their funds over to segwit keys to actually be disarmed from the mallicious things that segwit meant to fix.
so lets say there was an issue with segwit. all the pools and nodes need to down grade back to native nodes and find a way to move funds back to native keys.

[binarygold]

I used ZeroBlock app on my phone to kill time. 

saw a content item (swipe left) link, about segwit issues blog post.

1) user asked for a link to explain "what's wrong with segwit" maybe on reddit
2) child post provided link to GoT character avatar ("a girl has no name" guy) posted blog entry listing issues in a rather factual method.

trying to find now, and not coming up in ZB.   would post for refernece, but can't find.  have you seen this blog?

[Senor.Bla]

I have no idea what you are talking about, but i wounder that besides franky nobody could answer this. Usually the users on this forum act like they now it all. 

[kiklo]

Segwit breaking isn't guaranteed, but not impossible.

Lauda's Face when she read your statement.  




 

FYI: Lauda trying to think of a response to Segwit breaking.

[Jerean]

BU breaking is guaranteed, 100%. It's design basically is an attack waiting to happen.


Segwit breaking isn't guaranteed, but not impossible.

Can you explain why BU breaking is guaranteed? and Segwit is not?

[d5000]

Trying to answer that at least partially, from a "advanced non-programmer's" point of view (techies may correct me):

1. BU gets the support and we all hard fork to BU, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? Another fork? Can we still go to SegWit at this point? Something else?

In this case, I think there would be no problem to "go to Segwit", as Segwit is not tied to a certain block size. What must be done is a "BU-Segwit" transition version that enables the Segwit soft fork in the BU code and possibly goes back to a static block size, so at the end all more or less would be the same outcome than without the BU intermezzo.

2. SegWit gets the support and we all soft fork to SegWit, but then something happens.[...] Can we still go to BU at this point? Something else?

In this case, it's similar but a little bit more complicated because Segwit changes the block structure. We then cannot go back to the BU we know now, but we could go on with a BU fork that includes Segwit. So the outcome could be a client with the BU blocksize consensus mechanism but Segwit cannot be "erased" that easy from the code.

[Kakmakr]

In the end, we are dealing with a piece of code. There has been "flaws" in Bitcoin before and it was rectified. If ArtForz wanted to take all our coins in the early years, then he could have done that, but he told Satoshi about the flaw and he fixed it.

This is the thing about Bitcoin, if it fails, we all lose money. A consensus about the critical change that would be needed to "fix" it, will receive quick consensus once it was published, because it will be in our best interest. ^smile^

A lot of Peer review goes into this code, because it is OpenSource, so chances of "critical flaws" being identified is reduced.

[Amph]

In the end, we are dealing with a piece of code. There has been "flaws" in Bitcoin before and it was rectified. If ArtForz wanted to take all our coins in the early years, then he could have done that, but he told Satoshi about the flaw and he fixed it.

This is the thing about Bitcoin, if it fails, we all lose money. A consensus about the critical change that would be needed to "fix" it, will receive quick consensus once it was published, because it will be in our best interest. ^smile^

A lot of Peer review goes into this code, because it is OpenSource, so chances of "critical flaws" being identified is reduced.

bitcoin almost failed in the past, remember the 2010 bug? but nothing really happen to its value, the marketcap is way too big now to simple fail because someone is not in agreement

in the worst case it would remain as it is now with the 1 MB block, without the possibility to scale, miners actually are not against segwits but more against LN, they think that segwit will lead to LN eventually

bitcoin unlimtied my look like a fork but unless i'm missing all the change it's just look like the first client version with the 32MB limit

[Carlton Banks]

BU breaking is guaranteed, 100%. It's design basically is an attack waiting to happen.


Segwit breaking isn't guaranteed, but not impossible.

Can you explain why BU breaking is guaranteed? and Segwit is not?

BU has known attack vectors, it's part of the BU "design".

The BU concept is presented as that everyone is perfectly rational and has perfect goodwill towards BU, and so picks a sensible figure that everyone can handle. The reality is the soft 16MB limit can be quickly and easily reached if someone malicious floods the network with 16MB signalling.

Also, BU wasn't (in the past) programmed to follow the longest PoW chain. That would cause the BU blockchain to fork spontaneously into different blockchains as long as there's sufficient disagreement between the nodes about what the blocksize should be (a minor incident like this happened recently with a BU mining node, implying these kind of risks are still programmed into the software not as a bug, but as a feature).



Segwit has an attack that can be easily stopped: sighashing attack can be performed on the 1MB base block (and not on the 3MB of witness block).


But that attack can be done today without Segwit, but it's not being used, because it's not very effective at this scale. And miners can easily detect transactions crafted to attack in this way and simply not confirm them in their blocks. A malicious miner could still include them, but that will still be as ineffective as the attack is today, as it's identical (only the 1MB base can be attacked).

[Wind_FURY]

The problem with Bitcoin Unlimited if it "breaks" is it will have "not as good" developers. All they great thinkers in Bitcoin is at Core and all the good contributers support Segwit in my opinion.

[calkob]

Let us try an new perspective to the whole block size debate.
Two scenarios i like to discuss.

1. BU gets the support and we all hard fork to BU, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? Another fork? Can we still go to SegWit at this point? Something else?

2. SegWit gets the support and we all soft fork to SegWit, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? A hard fork? Can we still go to BU at this point? Something else?

I think the 1st option would be madness and would probably destroy bitcoin.  The idea that we can move to a completely new consensus method and that it not have problems is to me just ridiculous and also leads to far more control for larger miners.  What i learnt yesterday about attack blocks and how long they can take to validate is another problem.  Just research it if you havnt heard of it before.

The 2nd option is the sensible option and it has been thoroughly tested by the core devs,  and i think that if there was a problem with the softfork it would be fixed rather quickly, due to the fact Core has such a massive dev team compared to BU.

[kiklo]

IF BU Fails the Transactions problem will never be fixed.


If Segwit Fails, EVIL BTC Core Dev will not be able to Steal transaction fees away from the Miners.
And LN will not become a fractional reserve style system that BTC Core totally controls.
LN will not become Crypto banking 2.0 and we keep the dirty bankers out of crypto until the slick bastards make another attempt.  


 

FYI:
IF BTC Core was worth a crap ,
they would release a hardfork with a simple 2MB blocksize instead of letting the fees skyrocket and transaction delay for 3 days.

[pinkflower]

IF BU Fails the Transactions problem will never be fixed.


If Segwit Fails, EVIL BTC Core Dev will not be able to Steal transaction fees away from the Miners.
And LN will not become a fractional reserve style system that BTC Core totally controls.
LN will not become Crypto banking 2.0 and we keep the dirty bankers out of crypto until the slick bastards make another attempt.  


 

FYI:
IF BTC Core was worth a crap ,
they would release a hardfork with a simple 2MB blocksize instead of letting the fees skyrocket and transaction delay for 3 days.

I think youre misinformed or youre misinforming others about the Lightning Network. BTC Core doesnt have a monopoly on what layer is built on the network if segwit is activated. There are other groups who are already coding other executions of it.

[franky1]

BU has known attack vectors, it's part of the BU "design".

The BU concept is presented as that everyone is perfectly rational and has perfect goodwill towards BU, and so picks a sensible figure that everyone can handle. The reality is the soft 16MB limit can be quickly and easily reached if someone malicious floods the network with 16MB signalling.

its called a sybil attack.
a malicious core loving pool can also sybil attack with loads of core nodes flooding the network and then make changes too..
same thing. nothing specific that is only attackable via BU

Also, BU wasn't (in the past) programmed to follow the longest PoW chain. That would cause the BU blockchain to fork spontaneously into different blockchains

nope
learn consensus and orphans

as long as there's sufficient disagreement between the nodes about what the blocksize should be (a minor incident like this happened recently with a BU mining node, implying these kind of risks are still programmed into the software not as a bug, but as a feature).

and that block was orphaned in 2 seconds

orphans happen daily. orphans are a protection mechanism. orphans are good. yes it causes drama but the end result is a single chain

pools know orphans have a positive job of cleaning up the disagreements. pools also know they cause drama for the community so pools usuallly dont do anything to cause much drama.

hense why pools would take baby steps, testing the water and seeing how much orphan drama is or is not caused.

[kiklo]

IF BU Fails the Transactions problem will never be fixed.


If Segwit Fails, EVIL BTC Core Dev will not be able to Steal transaction fees away from the Miners.
And LN will not become a fractional reserve style system that BTC Core totally controls.
LN will not become Crypto banking 2.0 and we keep the dirty bankers out of crypto until the slick bastards make another attempt.  


 

FYI:
IF BTC Core was worth a crap ,
they would release a hardfork with a simple 2MB blocksize instead of letting the fees skyrocket and transaction delay for 3 days.

I think youre misinformed or youre misinforming others about the Lightning Network. BTC Core doesnt have a monopoly on what layer is built on the network if segwit is activated. There are other groups who are already coding other executions of it.

I think if you bothered to study Segwit & LN and study the history of Banking, you might have a clue to how much they are going to Dominate BTC if segwit is activated.
Start with the LN white paper, then google the history of how fractional reserve banking began, then do something really hard Read them and then think on it.  

 

[franky1]

just to clarify kilo's point because he appears to be a hott head that runs in different directions rather than explaining the point rationally

pink flower said

I think youre misinformed or youre misinforming others about the Lightning Network. BTC Core doesnt have a monopoly on what layer is built on the network if segwit is activated. There are other groups who are already coding other executions of it.

well core have already positioned themselves as a ringfence around the pools with their "fibre" nodes.
if pools adopt segwit then the segwit pools will white list the "fibre" nodes as their way to maximise propagation efficiency.

segwit is known to blacklist nodes they dislike and whitelist other nodes. known to not relay certain transactions.

 so they can be biased against any smart contract that is not produced by LN(blockstreams version of second layer smart contracts) by  not relaying those to pools.
causing the issues for opposing second layer services by not being able to settle or set up channels in a timely manner. because their transactions will not be added to pools mempool or refused to enter a block
(much like core loving pools refuse to do 'first seen, first added' for transactions. and instead biasedly add transactions by who sent it and how much is paid(BTCC does this))

with core being the upstream filters (gmaxwells own words) and also demonstrated in cores own userguide.. core have set themselves up to centralise the network.

try reading the documentation and code whilst wearing a critical /logical thinking cap. and not a fanboy cap.
dont think about the limited benefits, promotional sales pitches.. look for the fine print limitations and realities.
EG
https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/

If you still don’t wish to upgrade, it is possible to use a newer Bitcoin Core release as a filter for older Bitcoin Core releases.

meaning you have to have a segwit node. to be able to be accepted by the other nodes.. and you are then able to whitelist your own non segwit node. (basically other peers will reject you unless you pretend you are a segwit node)

In this configuration, you set your current Bitcoin Core node (which we’ll call the “older node”) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which we’ll call the “newer node”). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it won’t relay invalid blocks or transactions to the older node—but it will relay everything else.

When using this configuration, please note that the older node, if it uses Bitcoin Core defaults, will not see transactions using segwit features until those transactions are included in a block.

Configuration:

For the newer node, start it normally and let it sync the blockchain. At present, you cannot use a pruned node for this purpose because pruned nodes will not act as relay nodes. You may optionally start the newer node with either or both of the following command line parameters so that it treats the older node as special (these options may also be placed in Bitcoin Core’s configuration file):

  -whitebind=<addr>
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6

  -whitelist=<netmask>
       Whitelist peers connecting from the given netmask or IP address. Can be
       specified multiple times. Whitelisted peers cannot be DoS banned
       and their transactions are always relayed, even if they are
       already in the mempool, useful e.g. for a gateway

For the older node, first wait for the newer node to finish syncing the blockchain and then restart the older node with the following command line parameter (this may also be placed in the Bitcoin Core configuration file):

-connect=<IP_address_or_DNS_name_of_newer_node>

if you think the image is some anti core propaganda wallpaper from reddit.. check where the image is coming from (hint here is the link)
https://bitcoincore.org/assets/images/filtering-by-upgraded-node.svg

there are other little tip-bits of agenda hinted at in the userguide. how segwit will reject blocks that are not produced by segwit pools ensuring core has control of the network

If segwit reaches locked-in, you still don’t need to upgrade, but upgrading is strongly recommended. The segwit soft fork does not require you to produce segwit-style blocks, so you may continue producing non-segwit blocks indefinitely. However, once segwit activates, it will be possible for other miners to produce blocks that you consider to be valid but which every segwit-enforcing node rejects; if you build any of your blocks upon those invalid blocks, your blocks will be considered invalid too.

oh and by the way.
when pools make segwit blocks.. they wont be organically backward compatible. they will need to be 'filtered' to be presentable in a manner old nodes can understand.

meaning if segwit has a bug. the you cant just turn off segwit nodes and go back to old nodes which will understand the blockchain.
pools then have to do the filtering of the blocks while they too downgrade which can cause alot of disruption. due to them having to move funds back to native key types and other things to undo a segwit activation

where as a bu pool simply make blocks under 0.999mb without needing to downgrade/filter or move funds back. because BU uses the same mechanisms and transactions that were around for 2009-2016


p.s
if you feel my post is just a wall of text and you have not bothered reading it simply because its a wall of text. then you obviously dont have the concentration span to read userguides or code. this lack of attention span reduces your ability to understand bitcoin fully, so work on it

[Pettuh4]

Let us try an new perspective to the whole block size debate.
Two scenarios i like to discuss.

1. BU gets the support and we all hard fork to BU, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? Another fork? Can we still go to SegWit at this point? Something else?

2. SegWit gets the support and we all soft fork to SegWit, but then something happens. A technical issue that does not break Bitcoin but makes it hard to use (long confirmation time, high fees etc).
What could be done? A hard fork? Can we still go to BU at this point? Something else?

If both should fail it means we wouldn't get a shot at addressing the confirmation times and high fees issues that we find ourselves in so at least one should get the support for us to either try a hard fork or a soft fork of the Bitcoin core. I'm just for the change and not necessarily BU or segwit.

[Senor.Bla]

Now this is the discussion i was looking for. I've some questions, but i make a research on my own, since right now i have a more important question, let me first sum it up as i see it.
Both solutions bring dangers with them. Regarding BU people are more concerned about the risk of an technical problem. In case of an Problem another hard fork could quickly resolve the problem.
With SegWit the concerns are more political. SegWit per se may not be dangerous, but it could open doors for the privatization of Bitcoin. This could make Bitcoin controllable by few and goes against one of the main principals of Bitcoin. I think many argue here that just because one can act bad (not in Bitcoins and it users interest) doesn't mean he will do so. To which the classic answer would be that if it's possible, then people will do it (act badly ).
Also SegWit is a soft fork, but going back from it seems not to be so easy.

Seeing this i wounder why there is no big support for a third solution. Just buy some time by increasing the Size to 2 or 4 MB and look for a better and more permanent solution.
I see why both sides would prefer to see there solution implemented and therefore pushing for it, but i feel like this is one of those situations where you should stand back for the greater good.