Topic: What happens if BU fails VS What happens if SegWit fails - page 8. (Read 6407 times)

until you read the code and grasp the concepts of bitcoin. you will be stuck in the social drama of politics.
dont be so easy to grab onto some human and kiss their ass because of X or Y.
one day that human wont be here, but bitcoin will. so care more about bitcoin and less about the human

learn what the code does and let the code help you make your decisions.

core code is not a simple fix. its about changing the network topology and favouring nodes (centralising)

other implementations such as xt, classic, bitcoinj, btcd, bu and half a dozen others  are not about kings or gaining control of the network. they ALL want to use consensus to have all implementations on the same level playing field where nodes have the independent decentralised power, not devs not miners.

the whole point of bitcoin is that its not reliant on some central team of decision makers

so instead of playing the social games of which team is better. instead think.
let there be many teams so that none have power and only the nodes form a consensus of what should move forward.

that way the 'teams' become more like workers rather than managers. where the teams work to find the best solutions to bitcoin problems. instead of fighting to be kings and herding sheep in only a direction they want

I admit that I still try to wrap my mind around the technical discussions about Bitcoin but knowing that there is politics involved here still makes me doubt what the hard fork to BU, Classic or XT is really all about. There has to be something like a power grab here. Also the argument that the Bitcoin Unlimited developers are not as good as the Core developers and contributors deserves notice.

Actually it would make more sense to increase the blocksize First before ever adding segwit.

Your Saint G.Maxwell has been quoted in the past saying blocksize increases would be needed after segwit.

I will tell you why they should do it first, their is a Security vulnerability in the LN whitepaper,
where if you can trigger a delay in the Blockchain's ability to process transactions , you can delay LN, until the timelocks have been released
and wait for it .............. STEAL THE BTC RIGHT OFF OF THE BLOCKCHAIN!!!

Larger the blocksize the safer the community from that direct vulnerability.  

So Blocksize should be increased first, but they know no one wants segwit and would ignore it completely ,
which is why all of this effort to force it down everyone's throat.  

 

FYI:
Segwit 4MB is not the same as a 4MB blocksize increase.
Segwit only gives a usable 1.7 MB of the current style blockchain which is theoretical , (may be higher , may be less.)
A direct 4MB blocksize increase without segwit would give 4X the current transaction capacity, which would actually hold BTC for years and keep transactions Onchain and completely avoid LN Offchain Counterfeit coins.

I was attempting to be diplomatic and impartial...but thank you

FTFY

The opponents of BU are small block advocates that prefer the average user be
able to run a full node than be able to transaction on chain and are more
concerned about having transaction fees pay be able to pay for security
in the future even though that concern is decades away.

While I fully disagree with both of those reasons, at least they have some inkling of plausibility.
However I haven't seen any credible argument for the possibility of a technical problem with BU.

 

^ look at him talking about something he doesnt understand

segwit only works for people using segwit keys. anyone sticking with native keys can still cause signop issues within blocks.
the only way to avoid sigop issues in blocks is that 0% .. ZERO .. again ZERO(emphasised 3 times) users have funds on native tx's.

segwit does not disarm native transactions so sigop and malleability will continue.
segwit only disarms the innocent that voluntarily move funds to segwit tx's.. it does not disarm the malicious users

segwits 4mb wight is not a real 'feature' that all bitcoin users get to benefit from.

firstly only IF 100% of users use segwit keys, they would notice about a 2.1mb transaction one time boost.
the other 1.9mb is spare and unusable for anyone until future features ar added that append trivial data to the end of a tx for things like
confidential tx's

if the base block sticks to 1mb. the max expectation is ~4500tx with 2.1mb weight.
then if confidential payment codes and other features append data.. its still 4500tx but bloated to take up the spare space of the 4mb weight

You don't mean privatisation, Bitcoin is already privately owned (in a similar way to how shareholders own businesses)

Your suggestion to "just" increase to 2-4MB is bizarre.

1. Validation attacks on blocks more than 1 MB mean Segwit is needed before any blocksize increases
2. Segwit increases the blocksize to 4MB anyway



Some claim that limiting sigops on both the base blocks and the witness blocks is a workable solution to validation attacks, but this could prevent the witness blocks from reaching capacity, making some part of the 3MB witness blocks redundant.

Claims that attacking non-Segwit addresses are equally incorrect; that attack can be performed today. It doesn't work at 1MB, so no-one tries. After Segwit activation, the situation will be identical to today; only the base 1MB can be attacked with a sigops validation attack, not the witness blocks. Miners could detect and drop transactions that attempt validation attacks.

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.

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.

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

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/
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)


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

---

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

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.  

 

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

nope
learn consensus and orphans
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.

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.

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 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.

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.

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).

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