Clearing the FUD around segwit

[franky1]

you do realise that its not actually an anyonecanspend script. and as soon as someone without segwit tried to spend it in an anyonecanspend.. it wont get accepted by legit ethical pools...

Yes, I know. Maybe I wasn't clear, but I meant BEFORE segwit's deployment. Right now, you can create a transaction that has a segwit output. Right now that output is an anyonecanspend output.

Pools would not accept an attempt to spend a segwit output as anyonecanspend AFTER segwit's deployment.

blindly passing it on..

They do not blindly pass on segwit transactions because those are considered non-standard and thus rejected.

not because it actually is an anyonecanspend. otherwise thats another way of breaking bitcoin.. by old clients spending segwit transactions.(which u think is possible)

See above.

only a malicious miner can bend their rules and accept a malicious transaction into their block, to be treated as funky by everyone else blindly accepting it as funky. but if USERS tries to make a transaction and pushed it to a pool. unless the pool was malicious and wanted strangers to spend their previous tx, then it wouldnt get in a new block. so people cant spend the funky tx...

AFTER segwit's activation, such malicious transactions spending segwit outputs as anyonecanspend are invalid.

this is why i have used the word funky instead of anyonecanspend. because the anyonecanspend was for analogical reasons not technical

Anyonecanspend is technical, not analogical. An OLD node validates segwit outputs as anyonecanspend because under the old rules they are anyonecanspend.

my scenario is about the block creation by a malicious pool. not the user creating transactions (which pools would dump)

Miners won't mine an an invalid block.

maybe time you re-read it.

remember NON-segwit clients do not change. so all your fluffing around saying things will change means that you are assuming that old clients will some how understand things differently.. please think about that..

again. let this settle in
non upgraded clients do not change. they treat the transaction the same now as they would in a month. and so if you are saying that old clients can spend segwits now then you are saying that they can spend them later too... but they dont change..

my reading is that segwit transactions ARE NOT!!!! i repeat.. ARE NOT anyonecanspends. they would fail the test of anyonecanspend. HOWEVER for ONLY analogy purposes people say segwit transactions added to a block will be blindly accepted just like anyonecanspends are blindly accepted by old clients.

now onto the separate issue you keep meandering to..
please do not confuse the issue of block confirmed transactions with the relay of unconfirmed transactions.

so one more time

A POOL (not a user) a POOL adds a segwit transaction to its block, but because segwit is not activated by other POOLS the malicious pool can grab any input and pretend it is theirs becasue it knows the network wont be checking signatures yet. so it doesnt need to sign the input... and then give the the destination as a real privkey owned by them..

because the other pools dont understand segwit. they will blindly accept the block because they cannot check the signature of the input. and so it gets confirmed and the network accepts it. a confirmed transaction in a block where the originating funds do not belong.. but cannot be validated because the pools dont know what they are handling.

2000 blocks later. when segwit is activated the malicious pool can use the malicious block transaction as a valid input because it has 2000 confirmations and because the pool has the privkey to now sign (what was the old destination) as a new input for a new transaction to then send it out as a legitimate transaction to all the ethical pools

[BitcoinNewsMagazine]

I wrote a post on my website to try to clear up the misunderstandings that people have and spread about Segregated Witness.

http://www.achow101.com/2016/04/Segwit-FUD-Clearup

If you think I missed something or made a mistake, please let me know and I will change it. Feel free to discuss what I have written however I ask that you keep the discussion more technically oriented and less politically.

If you have any additional questions about segwit, I will try to answer them. If I think it is something that many people will ask or misunderstand, I will add it to the post.

Local rule: no posts about blockstream or claims that blockstream controls core development.

*Disclaimer: I am not one of the developers of Segwit although I have done extensive research and am in the process of writing segwit code for Armory.

Good article on your blog, thanks for taking the time. I enjoyed the read.

[achow101]

maybe time you re-read it.

remember NON-segwit clients do not change. so all your fluffing around saying things will change means that you are assuming that old clients will some how understand things differently.. please think about that..

again. let this settle in
non upgraded clients do not change. they treat the transaction the same now as they would in a month. and so if you are saying that old clients can spend segwits now then you are saying that they can spend them later too... but they dont change..

The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output. However, after segwit activates, if you were to create a transaction with a segwit output, it is not an anyonecanspend output and only the recipient can spend from it. To a non-segwit node, in both cases, it could create a spending transaction treating the output as anyonecanspend. Before the deployment, the spending transaction would be accepted, but after, it would be rejected.

my reading is that segwit transactions ARE NOT!!!! i repeat.. ARE NOT anyonecanspends. they would fail the test of anyonecanspend. HOWEVER for ONLY analogy purposes people say segwit transactions added to a block will be blindly accepted just like anyonecanspends are blindly accepted by old clients.

To new nodes, they are not anyonecanspends. To old nodes they are. It is not an analogy because old clients will validate it according to their rules and that is as an anyonecanspend output.

Okay, maybe I should stop use anyonecanspend outputs. Maybe this will help you understand it:

A p2wpkh (a type of segwit output) is as follows

Code:

OP_0 <20 byte hash>

The corresponding input scriptsig is then just

Code:

00

For a non upgraded node, it validates this by first pushing 0 bytes to the stack, then pushing OP_0, then pushing the 20 byte hash of the witness script. The stack will look like this:

Code:

0
<20 byte hash>

Because the stack is not zero, it is true and thus validates. Anyone can produce a transaction which has a scriptsig of 00 and with a segwit output, it is considered anyonecanspend by old nodes because anyone can create that scriptsig.

However, segwit nodes will recognize that he OP_0 means it is a version 0 witness program and validates it as such.

now onto the separate issue you keep meandering to..
please do not confuse the issue of block confirmed transactions with the relay of unconfirmed transactions.

so one more time

A POOL (not a user) a POOL adds a segwit transaction to its block, but because segwit is not activated by other POOLS the malicious pool can grab any input and pretend it is theirs becasue it knows the network wont be checking signatures yet. so it doesnt need to sign the input... and then give the the destination as a real privkey owned by them..

Segwit only creates a new OUTPUT type that is spent in a specific way. It doesn't affect how other CURRENTLY USED OUTPUT TYPES are spent. If you have a p2pkh output, to spend it, no matter of when, you MUST spend it as it is currently done. This will not change. Segwit activation does not make p2pkh and p2sh outputs magically be spent differently. Because the pool cannot spend from a p2pkh output that isn't theirs, it can't do this.

The pool cannot grab any input and spend it as their because the way to spend the currently used output types are not going to change.

[johnyj]

The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output

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

[franky1]

A p2wpkh (a type of segwit output) is as follows

Code:

OP_0 <20 byte hash>

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

[johnyj]

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

[achow101]

The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output

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

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.

A p2wpkh (a type of segwit output) is as follows

Code:

OP_0 <20 byte hash>

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

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.

[adamstgBit]

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

LMAO!

[franky1]

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.

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.

[achow101]

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.

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

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.

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

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!

[johnyj]

The node itself does not change, but the context in which they are spending in does. Thus, if RIGHT NOW you were to create a transaction with a segwit output, it is an anyonecanspend output and anyone can spend from that output

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

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.

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

[franky1]

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!

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

[achow101]

ok i think you are getting confused..

I think you're getting confused about how bitcoin works

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

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.

[johnyj]

ok i think you are getting confused..

I think you're getting confused about how bitcoin works

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

[franky1]

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? 1

The input does not dictate how the output is spent, the output does. 2

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

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

[vinaha]

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.

[vinaha]

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? 1

The input does not dictate how the output is spent, the output does. 2

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

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

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.

[franky1]

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.

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

[achow101]

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

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.

[Lauda]

You do present a valid flaw of a hypothetical one-time remotely possible transaction that may or may not exist.

He doesn't.

I wrote a post on my website to try to clear up the misunderstandings that people have and spread about Segregated Witness.

http://www.achow101.com/2016/04/Segwit-FUD-Clearup

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.

While Segwit is complex and introduces many changes, it is still about the same number of lines of code as the Bitcoin Classic implementation of the 2 Mb hard fork because that implementation still needs additional changes to mitigate the problems with quadratic hashing.

This is false IMO.

On segnet4 consensus changes are in commits 7c68afbd747ad57391fcb66485c377298fb02a8e to 4dd3d7dd8bf2f9dd7a5e62c3cb2ca8dbd1146daa
Git diffstats says 65 files changed, 1262 insertions(+), 350 deletions(-)