Topic: Clearing the FUD around segwit - page 4. (Read 3874 times)

Your right, SegWit might not be backward compatible if some pool today add 2 tansactions to the block today: Send bitcoin to SegWit address anyone can spend and spend it in second transaction without the signature to normal address. Because witness part where the signatures are stored does not exist today, this SegWit transaction wont be backward compatible after SegWit is activated. This means SegWit transaction signatures has to be just validated only after SegWit activation, so no need to make the block created today invalid if it contains SegWit transaction without the signature in witness part (which does not exist)




It is important to understand SegWit should be used only for low value transactions, because softfork rules can be changed anytime with 51% of hashpower and future block versions might not use SegWit withness data to check signatures anymore, so really anyone could spend SegWit transactions.

But you should be not surprised because you dont require the signature to be used to spend Bitcoins from SegWit transaction given today Bitcoin consensus rules (which requires hardfork to change) - so keep SegWit only to low valued transactions should be reccomended.

And indeed if SegWit transactions become used for high value transactions then if miners become unprofitable with lowering block rewards, they may use the hashpower to softwork again and get the SegWit transactions themselves legitimately (from anyone fool enought to send anyone can spend transactions by Bitcoin consensus rules).

To maintain compatibility, p2sh, p2pkh, and p2pk outputs are not change at all. There is nothing that changes how to spend from those outputs. So if you spend from p2pkh and p2pk outputs, you are still vulnerable to transaction malleability attacks (p2sh outputs are different because with segwit there will be p2wpkh and p2wsh outputs nested inside a p2sh outputs and those aren't malleable, but the old type are). The only way to not be able to have your transaction malleated is to use the segwit outputs types as your inputs.

you realise the whole point of segwit is that scriptsig is not part of the transaction right... you know to prevent people from tweaking it for malleability..

thus old clients wont see that area to be able to check it or not, so having a signature or no signature is meaningless as it would still be the same funky tx in a block..

then later after proper segwit is released the new block will have a separate transaction spending the pools funds. because the pool has the key to the funds

if your saying that old clients can read signatures of inputs of a segwit transaction. then that just defeats the whole malleability fix proposal. because segwit promises to not have signatures as part of the transaction. and its all put into a witness section that is not 'seen'
meaning old clients dont see the signatures and treat it as a funky tx.

remember the signatures are moved. to allow them to be processed differently. and old clients cant reject the transaction simply because it doesnt have a signature, if its locked into a confirmed block by a malicious miner. instead its just overlooked.

then later when they want to spend the funds they use the privkey to the public key they put as the destination(of previous transaction). and because the details of the destination are confirmed as holding funds. then the destination funds can be spent in a normal way.
(if it could reject a block with a funky tx. then that defeats the whole backward compatibility promise)

PS, lauda has no clue, he has just been handed a glossy image to look at and now thinks he is an expert. he has no clue about a single line of code.
maybe lauda cant admit that segwit is now on version 5 and still not proven to work, its not even publicly available so he has no proof its bug free or that people cannot abuse it.

i think his blind faith in something not yet released is clouding his judgement.
now i wait for him to link in his glossy images of what segwit proposes and say how everything is more perfect then a sunny day

He doesn't.

Even though the article is nice, I think that you're wasting your time with this thread. Initially, they were complaining that Segwit is complex and now they're making up scenarios in which it is supposed to be 'insecure'. I doubt that you're going to reach a point where they admit to being wrong.

This is false IMO.

Here is the flaw in your logic. The scriptsig stuff is only stored outside of the transaction for the NEW SEGWIT OUTPUT TYPES. Segwit specified two new output types and only those two output types can have their signatures not in scriptsig. If you are spending from an OLD OUTPUT TYPE LIKE P2PKH and P2SH then you still have to have the signatures in the scriptsig.

Maybe the example here: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Example will help you understand it better. Because one input in that example is p2pk, IT MUST HAVE THE SIGNATURE IN THE SCRIPTSIG. The other input is a p2wpkh (new segwit output type) which requires that the signature is in the script witness.

no, because any solution involves people upgrading to have that solution.. and so the only real solution is to stop playing the "everything is ok" card, blindly turning old full nodes into less then full nodes.

but to instead say.. look everyone its time to upgrade, THIS MONTH

doing all the crap like saying its safe not to upgrade. or 12 month grace periods so no one hash to rush or bother right away does absolutely nothing to kick people up the ass to upgrade. meaning things can go wrong.

the only solution is to not have such lax policies.


but it this way. what would have happened if in 2010 peopler were told, dont worry about the millions of bitcoins created in 1 transaction.. we will give you 12 months to upgrade everything is fine

what would have happened in 2013 when the DB bug became apparent. and the devs told everyone.. dont worry you dont need to go above 500k limit we will give you 12 months to upgrade in your own time..

You do present a valid flaw of a hypothetical one-time remotely possible transaction that may or may not exist. Do you have a solution that does not involve a hard fork? Because I am sure a hard fork also has many more hypothetical flaws.

Thank you Knightdk.
This is a clear explanation of SegWit and I'm looking forward to its implementation. Because of your article I can clearly see why it makes total sense to implement SegWit before making the block size huger.

We don't need a larger block size if we are filling that block size with bloat.

1. because the block was made before other pools had segwit.. so they would blindly accept the block containing the funky transaction!!!!!!!!!
again. the malicious transaction would be put into a block by a malicious pool BEFORE others had segwit. knowing that old nodes would blindly not care about it because they dont understand it and wont check for signatures because they cant see the witness(signature) area

2. exactly.. the initial transaction in the malicious block has NO signed input. but is not checked because its a funky tx.

3. all the scriptsig crap is stored OUTSIDE of the tx, in the witness area.. old clients wont see it and blindly accept it without a signature.. thats the whole point of segwit.

now when a second transaction is made later it is grabbing the OUTPUT of the first transaction (not the input) which basically says 1MaliciouspoolAddress gets the coin. and uses the OUTPUT as an input for the second transaction.. and signs for it normally. because the pool owns the key for 1MaliciouspoolAddress and the confirmed block is saying that 1MaliciouspoolAddress now owns coins thanks to the funky tx before segwit

I think I understand Franky1's sense of security here, let me make a simpler example:

As soon as segwit code is out, some malicious miner create an illegal segwit transaction and mined it into a old style block, for example block 420001. All the old nodes will accept this block since they can not verify if the transaction is correct. So this block containing illegal segwit transaction will be berried deep down until the day segwit activates, lets say 425000

After segwit activation, all segwit nodes detected this illegal transaction (because they could not find the witness part at all) and illegal blocks,  they have to abandon all the blocks after this block and build from block 420001, since that is the latest block they consider to be valid, so network split into two chains from 420000 and all the transactions after 420001 disappear in segwit nodes after the activation

I think you're getting confused about how bitcoin works

What about a segwit transaction would make it so that he can ignore the signatures? Why would he be able to spend from an input he does not own?

The input does not dictate how the output is spent, the output does. If the output says that it needs a signature in the scriptsig (e.g. a p2pkh output), then it needs a signature in the scriptsig regardless of segwit activation.

ok i think you are getting confused..
so pretend it is sunday the 3rd of april. the network is not using segwit.
BUT
on this same day a malicious miner makes a block paying a destination address he owns. dstination/output: 1MaliciouspoolAddress
he makes the block that has the transaction included to pay 1MaliciouspoolAddress
he owns the key for 1MaliciouspoolAddress

BUT is using inputs of funds he does not own. but knowing he is making a segwit transaction he doesnt need to worry about signatures because the old clients will ignore it they wont get to see the witness data so they couldnt even validate the inputs even if they tried. to them its just a funky transaction..

so he is makes the block.. and the network accepts it because although the transaction should be invalid.. the segwit bait and switch allows for transactions in a block to be overlooked.

and so it becomes part of the chain..

then LATER lets call it May 17th and segwit is available.
the block created on april 3rd now has 6336 confirmations with a transaction inside saying that 1MaliciouspoolAddress has coins.

to old clients they are thinking its a funky tx that is unspendable(its not a op_true like you thought but op-0).. but to the segwit clients they can see the 1MaliciouspoolAddress and they see the tx is confirmed with 6336 confirmations.

so a new tx is created in May and signed using the private key of 1MalicouspoolAddress and pushed out to the network.

remember old clients did not orphan the block on the 3rd of april..
remember the next transaction in May is using the output 1MalicouspoolAddress as a new input.. and a valid private key aswell

when segwit is available to all pools. then all the pools instead of ignoring shit, they would see a new transaction waiting to be added to a new block. where there is a signature to a valid publickey input because as i said many times the pool would have put the funds into a key they own. and that new transaction would go into that new block allowing the funds to be moved legitimately..

Notice the activation happens after the grace period. What prevent miners from switching back to original version after the activation? If there are so many anyonecanspend transactions to grab. You must collude with miners, so that is the problem with segwit, without miners cooperate, this system will fail, and bitcoin by design should not need devs to collude with miners to implement a change, that is too large degree of central planning

Even if you can collude with miners, in case the segwit upgrade failed, e.g. lots of security problem in live traffic after the activation, because of these anyonecanspend transactions, miners can not roll back to old version, since all these transactions will be spendable if they revert. In that case bitcoin is dead either way: Keep running segwit, customer losing money, roll back, customer losing money

Fine, semantics, whatever. When I refer to an anyonecanspend output, I will be referring to a output that can be spent without knowledge of the private key for the address.

NOOO! The anyonecanspend output does not affect the input. What part of that do you not understand? If I take any UTXO and put that as my input, I HAVE TO SPEND FROM IT AS THE OUTPUT DICTATES. THE INPUT SCRIPT COMBINED WITH THE OUTPUT SCRIPT HAVE TO RESULT IN A NON-ZERO NON-EMPTY STACK!! The outputs of the SPENDING transaction can be anyonecanspend but THAT DOESN"T AFFECT HOW THE INPUTS OF THE TRANSACTION ARE VALIDATED!

i love how you try to remain disagreeing, but when you try to explain it you are actually explaining that the op_0 is like i said NOT anyone can spend. and so its not exactly like an anyone can spend transaction at all.. like i said. and that the use of the example of anyone can spend is only as an analogy comparison and not a technical duplicate..

so back to my point. if a malicious pool adds segwit transaction the OLD clients will look passed it. meaning that the pool could grab any input from anyone and make a transaction that has a destination of a privkey the pool owns..

once locked in the block. other pools and nodes will see it as a FUNKY tx to overlook and they themselves cannot spend it. but when segwit is released, the malicious pool can grab that now 2000 confirmed tx output, sign it as an input because they have the key of the funds that are now 2000 confirmed. and so when they send out the transaction it would then be verified properly and see that it says the funds are valid because they are confirmed. and a valid key was used on the new tx.

LMAO!

Nope. It's all in the deployment. There is a lock in period (grace period) before the rules go in effect. See BIP 9: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki for how the deployment actually works because they will be using versionbits.

Uh. No. OP_0 is currently treated as a counter, but basically as a NOP now. After segwit is released, it is treated as script versioning. The OP_0 isn't the part that matters, but rather the fact that the stack is not zero or empty and thus is true. That is what makes it anyonecanspend because if the scriptsig is empty then the stack will always evaluate to true.

And this one, replace the word "bitcoin" with "segwit" 
https://www.youtube.com/watch?v=4APcgsRdW6w

op_true is used for anyone can spend.. and valid to be relayed and valid/accepted into blocks
currently op_0 does nothing.. so would get rejected when relayed but accepted(blindly ignored) in blocks

however after segwit is released op_0 can be treated similarly to op_true by upgraded nodes. but still rejected at relay and blindly ignored in blocks by older nodes.

there is a difference

So the security is to make sure this output can never be spent by old nodes, how can you be sure of that?

Suppose two pools with 60% hash rate, and they are sitting on the side line watching the mined blocks, once 35% of blocks are mined as segwit support, they switch to mine segwit blocks and activate it, then there will be many segwit transactions out there, and then they switch back to original software

Now network are full of anyonecanspend transactions that is free for them to grab, and they have 60% of hash power so their chain become the longest, since majority of the nodes are still old style nodes (as in soft fork you don't need nodes to upgrade),  these nodes will build on their chain, and the rest of the segwit nodes will fork into a minority chain since now they reject old style blocks

So it is a mess after this accident, all the people who used segwit transaction will lose their money and they don't even understand what happened