Clearing the FUD around segwit

[franky1]

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.

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

[1714756829]

1714756829

[1714756829]

1714756829

[1714756829]

1714756829

[achow101]

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

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.

[ATguy]

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

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)

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

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

[achow101]

--snip--

You are horribly misunderstanding segwit just like franky is. You need to realize that segwit does not affect how p2pkh, p2sh, and p2pk outputs are spent so transactions spending those outputs are still malleable. The part about not including the signatures in the scriptsig is only for the segwit output types.

[ATguy]

The part about not including the signatures in the scriptsig is only for the segwit output types.

This I meant, use SegWit transactions for low valued transactions only, because they meant to be as anyone can spend and the signature is required only in withness data by certain block versions, but this signature  in withness data requiremet can be changed with future soft fork and new block version again.

[achow101]

This I meant, use SegWit transactions for low valued transactions only, because they meant to be as anyone can spend and the signature is required only in withness data by certain block versions,

They are not meant as anyonecanspend outputs after the activation because they aren't anyonecanspend outputs after segwit activates.

but this signature  in withness data requiremet can be changed with future soft fork and new block version again.

Literally anything can be changed with any kind of fork. This is not a valid argument.

[ATguy]

This I meant, use SegWit transactions for low valued transactions only, because they meant to be as anyone can spend and the signature is required only in withness data by certain block versions,

They are not meant as anyonecanspend outputs after the activation because they aren't anyonecanspend outputs after segwit activates.

I understand this, these SegWit transactions are meant as anyonecanspend outputs after the de-activation, the same way as today. The only thing what protects SegWit transactions from anyonecanspend after activation is just another Soft fork which deactivates use of withness part to check signatures, users should be well aware of this and act accordingly.

but this signature  in withness data requiremet can be changed with future soft fork and new block version again.

Literally anything can be changed with any kind of fork. This is not a valid argument.

No, you can not spend normal transaction after any Soft fork without valid signature, but you can spend SegWit transaction without signature afer Soft fork, so "Literally anything can be changed with any kind of fork" is invalid statement.

[achow101]

I understand this, these SegWit transactions are meant as anyonecanspend outputs after the de-activation, the same way as today. The only thing what protects SegWit transactions from anyonecanspend after activation is just another Soft fork which deactivates use of withness part to check signatures, users should be well aware of this and act accordingly.

What do you mean deactivation? There is no plan to deactivate segwit, why would there be? By that logic, we shouldn't have use p2sh or OP_CLTV because after activation another soft fork can be used to deactivate it and those features are gone. This is an unnecessary fear and is just spreading FUD to get people to not use segwit.

No, you can not spend normal transaction after any Soft fork without valid signature, but you can spend SegWit transaction without signature afer Soft fork, so "Literally anything can be changed with any kind of fork" is invalid statement.

You can create a transaction with the segwit outputs before the fork right now and be able to spend that without a signature. you cannot do that after the fork because after the fork you will need a signature to have that transaction considered valid.

[ATguy]

I understand this, these SegWit transactions are meant as anyonecanspend outputs after the de-activation, the same way as today. The only thing what protects SegWit transactions from anyonecanspend after activation is just another Soft fork which deactivates use of withness part to check signatures, users should be well aware of this and act accordingly.

What do you mean deactivation? There is no plan to deactivate segwit, why would there be? By that logic, we shouldn't have use p2sh or OP_CLTV because after activation another soft fork can be used to deactivate it and those features are gone. This is an unnecessary fear and is just spreading FUD to get people to not use segwit.

There are no plans for deactivation today, but it might change in future. Bitcoin is meant to be trustless, so Im not going to store Bitcoin long term with SegWit transaction, because I would need to trust another Soft Fork wont deactivate the use of withness part where signatures are checked. No FUD, just rational from my part as I will be using SegWit transactions only for hot wallet and low amounts, not for a cold longterm storage.

No, you can not spend normal transaction after any Soft fork without valid signature, but you can spend SegWit transaction without signature afer Soft fork, so "Literally anything can be changed with any kind of fork" is invalid statement.

You can create a transaction with the segwit outputs before the fork right now and be able to spend that without a signature. you cannot do that after the fork because after the fork you will need a signature to have that transaction considered valid.

Yes, but after another Sof Fork you could spend SegWit transaction without signature. But you cant do it with normal transaction after Sof Fork. That was my point.

[achow101]

There are no plans for deactivation today, but it might change in future. Bitcoin is meant to be trustless, so Im not going to store Bitcoin long term with SegWit transaction, because I would need to trust another Soft Fork wont deactivate the use of withness part where signatures are checked. No FUD, just rational from my part as I will be using SegWit transactions only for hot wallet and low amounts, not for a cold longterm storage.

You can use the witness outputs nested in a p2sh output (the kind of address that segwit wallets will be creating). The witness output scripts act as the redeemscript of the p2sh address, and because that is hashed, no one will be able to spend your coins even if for some reason a soft fork happened which deactivates segwit.

This is an irrational fear and not a particularly valid one because segwit fixes the transaction malleability problem, and deactivating it would simply reintroduce the issue, something that no one wants to happen.

[franky1]

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

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 are as naive and stck in the box as lauda..

its time you took off the fanboy hat and thought outside of the box.

i said the malicious pool will make a segwit!!!!!!!!!!!!!
a segwit transaction
a segwit transaction
a segwit transaction

why the F*ck are you talking about p2pkh... seriously..

so one more time.

malicious pool makes a segwit transaction.. that is using op_0.. not a op_true..(they are different things)
the transaction grabbed a random input from anyone. knowing that right now today the signature was not important. because current network wont see or care about signatures.(because of op_0)
again remember its a segwit transaction not a standard p2pkh.. so the arrangement of where the signature should exist would be different and thus old clients would just see it as funky
it puts it into a block.
so now its in a block, old clients cant just drop it. instead old clients look passed it not checking it because its set as op_0 so they will blindly say it the block seems ok even with the funky TX..
this funky Tx has a destination output of 1MaliciouspoolAddress (which the pool does own the privkey too, and will use later)
lets say this happens today.. long before segit is a thing

now.. have a coffee and let that part settle in.. do not confuse the part above with the part below.

ok, fast foward one month..
the pool has lots of confirmations accrued for that transaction and no chance of an orphan..
now all the pool needs to do is spend that 1MaliciouspoolAddress output in a new input the standard way signing it with the privkey they do have

[achow101]

you are as naive and stck in the box as lauda..

its time you took off the fanboy hat and thought outside of the box.

It is time you actually think about what you are saying and realize you have no idea what the fuck you are talking about.

i said the malicious pool will make a segwit!!!!!!!!!!!!!
a segwit transaction
a segwit transaction
a segwit transaction

Define a segwit transaction. There are segwit outputs, p2wpkh and p2wsh. When these outputs are spent by the input of another transaction, the signature is not in the scriptsig. THAT IS ALL THAT THIS DOES!

malicious pool makes a segwit transaction.. that is using op_0.. not a op_true..(they are different things)
the transaction grabbed a random input from anyone. knowing that right now today the signature was not important. because current network wont see or care about signatures.

How so? How can they grab any input from anyone if the output that they are spending requires a valid sig?

Let's simulate this using specific transactions and actual technical terms. Pick a random transaction and lay out exactly how this would work with the OP codes in the inputs and outputs.


This is what you are telling me:

Pick a random transaction output A. I chose the first output from https://blockchain.info/tx/eecd0da0ed0c5c6a633ff23c30591af798592f4b62d10a24e21739dde0270e7f
The output is

Code:

OP_DUP OP_HASH160 66e7f6ecddc8a15903acc24339c3ff1d5406da9a OP_EQUALVERIFY OP_CHECKSIG 

To spend it, I need to provide a valid signature in the scriptsig. The scriptsig in the spending transaction will look like

Code:

30..... 02.....

THIS DOESN"T CHANGE AT ALL!!  WITH SEGWIT I CANNOT SPEND THIS INPUT WITHOUT PROVIDING THAT SCRIPTSIG.

[franky1]

When these outputs are spent by the input of another transaction, the signature is not in the scriptsig. THAT IS ALL THAT THIS DOES!

seriously you said it yourself but you are not realising what you are saying
read the part i quoted you.. and realise that because OLD clients wont see the signatures because of exactly what you said.. then there does not need to be a signature..

because old clients wont validate it.. they would blindly overlook it if they seen a funky transaction in a block that has no scriptsig where it suppose to be..
so a malicious miner can just not sign it. (because they dont even have that random inputs key), knowing the rest of the network would overlook it.

its only weeks later as a separate transaction that things will be signed. and what would be signed is what was the output address of that funky transaction that has been blindly confirmed by 3000+confirms.

[achow101]

When these outputs are spent by the input of another transaction, the signature is not in the scriptsig. THAT IS ALL THAT THIS DOES!

seriously you said it yourself but you are not realising what you are saying
read the part i quoted you.. and realise that because OLD clients wont see the signatures because of exactly what you said.. then there does not need to be a signature..

because old clients wont validate it.. they would blindly overlook it if they seen a funky transaction in a block that has no scriptsig where it suppose to be..

so a malicious miner can just not sign it. (because they dont even have that random inputs key), knowing the rest of the network would overlook it.

But only the segwit output types can be spent like that. Only p2wpkh and p2wsh do not need the signatures in the scriptsig. And those outputs right now do not exist, or if they do, they are intentionally created to be able to be spent by anyone.

[franky1]

And those outputs right now do not exist, or if they do, they are intentionally created

welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that..

finally i think you are piecing it all together, bravo.

like i said. made today. intentionally. knowing its locked and unspendable until segwit is released in a few weeks.. it can spend the funds now confirmed to 1MaliciouspoolAddress

[achow101]

And those outputs right now do not exist, or if they do, they are intentionally created

welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that..

finally i think you are piecing it all together, bravo.

The code is different from actual transaction outputs. Actual transaction outputs do not exist that are the segwit output type that anyone can spend from. They can't just use that code and grab any random output to spend from like that because that isn't how it works.

[franky1]

And those outputs right now do not exist, or if they do, they are intentionally created

welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that..

finally i think you are piecing it all together, bravo.

The code is different from actual transaction outputs. Actual transaction outputs do not exist that are the segwit output type that anyone can spend from. They can't just use that code and grab any random output to spend from like that because that isn't how it works.

why the F*ck are you talking about anyone can spends.. ur obsessed with trying to make op_0 sound like op_true..
please think outside of the spoonfd mantra of the glossy magazines you have been handed

i have no clue why you are trying to bring in op_true scenario's into this..

sit back, dont reply. make yourself a cup of coffee and in your head think only about op_0 transactions. repeat the words op_0 over and over until you forget about anyonecanspend.(op_true/op_1)

once you mind is clear. think about the lack of signatures seen by old clients and not validated by OLD CLIENTS due to op_0
take a breath. relax
take another sip of coffee..

then think about that transaction being locked and unspendable by old clients.
imagine time passes you by nothing happens. more confirmations pile up.. nothing happens..

then when segwit is released oh look there is an output that has 3000 confirmations that segwit clients understand. and the pool has a privley for that output. meaning it can happily make a new transaction to spend it legitimately using the release segwit

[achow101]

And those outputs right now do not exist, or if they do, they are intentionally created

welcome to the conversation.. like i said pages ago. a MALICIOUS pool grabs the code from testnet/github. to do exactly that..

finally i think you are piecing it all together, bravo.

The code is different from actual transaction outputs. Actual transaction outputs do not exist that are the segwit output type that anyone can spend from. They can't just use that code and grab any random output to spend from like that because that isn't how it works.

why the F*ck are you talking about anyone can spends.. ur obsessed with trying to make op_0 sound like op_true..
please think outside of the spoonfd mantra of the glossy magazines you have been handed

i have no clue why you are trying to bring in op_true scenario's into this..

I'm not talking about OP_TRUE"s. Why the fuck do you think I am talking about those. When I refer to anyone can spend, I mean that the script is in such a way (doesn't matter how) that anyone is able to spend that output.

Why don't you do as I said above and give specific examples of how exactly your attack would work. And by specific I mean writing out what the input and output scripts would look like and taking a random transaction that currently exists and explain how that works with the attack.

[rizzlarolla]

"Before being added to Bitcoin Core, it will be tested very thoroughly over several days or even weeks to make sure that it is all ready."

Is that really enough?

[achow101]

"Before being added to Bitcoin Core, it will be tested very thoroughly over several days or even weeks to make sure that it is all ready."

Is that really enough?

It is also being tested right now and has been tested for the past couple of months since the first segnet went up.

With the amount of testing going on, it is enough.