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

It is backwards compatible. If the current implementations that already exist chose not to use segwit, they would be fine and can continue to function. What I meant is that if those implementations want to support segwit, it is up to them to implement it in their own software without any bugs. They can follow the publicly available documents that specify the exact changes that segwit makes.

nooo
backward compatible soft fork means that segwit has be be sure to work with other implementations that already exist.. not the other way round

this is why a hard fork would be better. as it forces all implementations to be on the same level playing ground. rather then a handfull of coders just making sure their version works and blaming everyone else for not upgrading if it hard forks..

seriously are you that devoted that you can no longer think impartially

Segwit is conceptually sound. When it comes to implementation, there can be bugs, and that is what the testing is for, finding the implementation bugs and making sure that it is implemented to spec in their software. It is up to the developers of the other software to follow the publicly available specs to properly implement segwit.

Also the segwit irc is #segwit-dev and that is where segwit discussion happens, not #bitcoin-dev or #bitcoin-core-dev

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.

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

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.

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

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.

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

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.

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.

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

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!

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
To spend it, I need to provide a valid signature in the scriptsig. The scriptsig in the spending transaction will look like

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

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

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.

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.



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.

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.


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.

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.



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.

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

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

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.

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.