Topic: The dangerously shifted incentives of SegWit (Read 958 times)

A 51% attack is always bad - also to non-SW TXs. But SW makes it more attractive to do. On the other hand there is also risk that miners just skip SW TXs - esp when enough non SW TXs  are there with good fees.

Implement SW is a economic AND systemic (check the complex code!) risky thing and many different business provider just do not like it - the soft fork also allow this to NOT do it.

So SW has some issues - yes. 2x is very very very simple. HF just as clear as possible - all do it!

I'm sorry, but can anyone else back this up? This sounds like bullshit. I read from many reputable sources that SegWit transactions only have this "potential reversible transaction" vulnerability only for unconfirmed transactions. Once a transaction is confirmed, then it is secure.

What do you use now?

Mike Hearns rage quit was a wake up call to look into 'core'. They are undermined...

Although I'm not an expert, I can not understand everything, but in part, I see the danger when we all choose segwit. I used to support segwit, because I thought it was superior. However, I never doubted Core. Currently, I really feel confused about this issue.

With something like this I always have one reminder to people, if we don't fix something like this now we're just going to be sitting in the same old problems which we haven't been able to fix for so much time. I'd rather go ahead and activate Segwit to be able to fix the pressing issues which have been heeding back our growth for so long, and then we'd be able to address any issues we created along with Segwit. I just think that it's probably best to fix Segwit later on rather then sit here and watch the community fall back more and more.

I think it's worth the risk yall.

i'd be more interested in hearing about this from someone who doesn't have an agenda of their own. what about segwit implemented on litecoin and others? have they addressed the fix?

ive read it ages ago, i have also seen many many many many more attack vectors.

as for todds OLD 'fix' of requiring pools to add a few tx's to a block has his way of thinking it proves pools 'validate' blocks is false hope of trust/belief.

a pool can easily fool this 'fix' of belief of validating.. simply with a template of a block where they, on many blocks ahead of time know which tx's are not already confirmed, to know what to add to meet the threshold...
this is done by a pool not broadcasting unconfirmed tx's to the network but only build blocks with new unspents from their own stash of coins. spending them to themselves. thus then having extra tx's in a block to fool the "we validate because we have tx's" test. but. totally missing the actual flaw of 'empty block(validationless) mining

i have already stated ever since segwit is a thing that there are issues.
even their tier network cludge doesnt solve it
even their dns seed changes and filter/stripping and other things doesnt solve it
even killing off non segwit nodes and pools does not solve it.

the only way to truly prove that a segwit tx was added to a block and that its validated and wont cause issues in the cludgy tier network is to do away with the 2 merkle (1*b, 3*w) block inside a block and just go straight for a single blockspace where segwit and legacy tx's sit side by side fully serialised and in full. and where the entire network is ready to validate the full data

meaning a hard fork to a proper 4mb blocksize

that way the spv and 'backward compatible' nodes are not having to rely/trust that the stripped block they get has been fully validated first then stripped second.. because the blocks would be full and the full nodes would have upgraded to properly validate a serialised block. rather than pushing around stripped/filtered base blocks that are 'presumed' valid.

my point though is that the 2017 'sgwit is utopia' bubble is being burst and people are admitting it has issues

it might help the discussion if you two ^ actually read the quoted material; the twitter convo and the few emails

lol
that ACK was from 2015.. before a line of code for segwit on bitcoin was actually wrote.
yep peter todd loved segwit before it was wrote but is now saying it has flaws..

seems it took 2 years for the sheep to wake up and stop promoting things before code was actually available. because later they retract their promoting once they see the code.
atleast they are open to now point out the flaws and stop shouting utopia

That gives us all a 'strong' confidence into SW and testing that a long KNOWN issue is not fixed.
What about the iceberg ones? Sorry I stop here for now....


 

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012185.html:
Peter Todd seemed happy that the issue went on to be fixed.

"Incidentally, based the positive response to fixing this issue w/
segregated witnesses - my main objection to the plan - I've signed the
Bitcoin Core capacity increases statement:

https://github.com/bitcoin-dot-org/bitcoin.org/pull/1165#issuecomment-168263005 "

Very intriguing article. I can't really say it's eye opening to me cause I got no idea what's really going on. But appreciate the post


https://twitter.com/petertoddbtc/status/881202125312847874

Segwit has the issue of being totally reversible. For the coins or transactions done on Segwit they can be manipulated successfully by a 51% attack so well that they won't even have transaction IDs on the Segwit chain any more.

If you choose to use Segwit you are risking a 51% attack miner who can literally take the entire history of the blockchain of Segwit, wipe it, and take the coins.

As it stands now with the current BTC blockchain it is unlikely that a 51% attack can affect more than the last 2 or 3 blocks.

A very interesting article.

Not much response from the so-called experts so far.

Thx. 

..where I've this seen before ...   

https://bitcrust.org/blog-incentive-shift-segwit.html