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

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.

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

The corresponding input scriptsig is then just

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:

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.

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.

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

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

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.

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

See above.

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

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

Miners won't mine an an invalid block.

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

for instance. lets assume that i knew someone else made a segwit next month. and i knew of 1 pool that had not upgraded. by saying that old clients can spend segwit. means that i can push the transaction to an old pool and spend someone segwit..

it is said it is LIKE an anyonecanspend and treated as an an anyonecanspend, for the sole laymen purpose and analogy purpose of a node not understanding what it is and blindly passing it on.. 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)

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

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

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

LOL. You drive a personal attack against 'every single person' there by accusing all of them of using personal attacks. You are a joke.

No, I prefer a forum where you can have a semi-intelligent discussion about the merits of the various software proposals instead of a forum where every single person has a bias towards one specific proposal and uses personal attacks and spreads misinformation about other proposals. Also, that thread is really freaking long and I don't want to read it and attempt to debunk all of the false information in one post.

---

This is simply not possible. Anyonecanspend is an output type, not an input type. It is not possible to spend from addresses (from now on I will refer to them as p2pkh and p2sh outputs) that you don't own the private keys for. If it were an anyonecanspend output (like an actual one or one in segwit format) then, as the name of the output suggests, anyone could spend from that output legitimately and create whatever outputs they want.

I don't see how that would even be the case. A segwit output would be able to be spent by everyone before segwit's activation because it is anyonecanspend.

See above.

The biggest property of segwit is that the more you talk about it, the more FUD you get  

If changing 1 to 2 require 18 months of talk, then changing several thousand lines would require many decades of talk if not centuries

1. malicious pool makes a segwit transaction to pay themselves lots of coins. from an address they dont own to an address they do own. BUT. because its 2 weeks before anyone else has segwit, it appears to others as a funky transaction. in a block.. so they blindly accept it as a block with funky transaction.

2. so now the receiving addresses is technically classed as having lots of funds.. but no one can spend them as they dont have the keys to do so. so the transaction is locked in the block unspendable becuse although people can try making an anyone can spend, it wont be accepted into other blocks as its not technically an anyone can spend..

3. weeks later when the malicious block has over 2000 confirmations. the owner of the privkey that received the funds can then move them because segwit is now live and segwit pools will see that the transaction is spending funds with 2000 confirmations(even though the tx before that is technically invalid)

You seem to prefer a theymos ruled forum over an uncensored one. No surprise.

Sorry, but I still don't understand your scenario. Can you describe it more specifically with reference to the output type that was used in the outputs?

i do understand it. but your diverting away from a block containing transactions where the pool is paying themselves..  to talk about a different scenario about spending later....

because after the 2 weeks of the transactions being (kind of stuck) in a block.. when segwit becomes live for everyone else. the pool can then move the funds using segwit legitimately because they are moving funds from the confirmed blocks using the privkeys they own.

only way to prevent it is to roll back the chain two weeks orphaning off 2016 blocks just to make that malicious block disapear from being confirmed..

as for your newly elaborate scenario about anyone can spend.. those transactions wont be accepted in mempool of old clients. not until segwit is live.
so as i said. a malicious pool can create a block. with a 2 week headstart (2016 blocks) to secure their transaction. and then when live. they can spend the transaction.

Clearly you don't know how segwit works. A segwit output is understood by old nodes as an anyonecanspend outputs. Spending a segwit output has a blank script sig and this is valid because the stack is not 0. So if anyone were to create a segwit transaction now, anyone could spend from the output. Segwit does not allow people to spend from normal p2pkh or p2sh outputs in a special way, they still have to spend from them in the old way. The change of segwit is the new output types and spending from those output types requires an empty script sig and a witness. I suggest that you read the BIPs for the full technical description of segwit and you should really understand how it works. I linked them in the bottom of the blog post.

The fees are lower. I'm pretty sure a lot of people care about the fees, especially if you are making many transactions. Those fees do add up. Since the size of the transaction that goes towards the block size count is less, the fees will thus be lower and that incentivises people to use segwit.

exactly. its being falsely told that upgrading is not a priority and you can happily stay with old versions.... basically making yourself more impotent due to pure ignorance and lack of true information.

a hard fork with a short grace period emphasizes the priority and gets people to upgrade. its happened atleast 3 times before where loads of nodes upgraded in hours... its not a big deal to implement. if you highlight the priority of implementation

What do you think about the using of segwit?
Let me explain.
Today almost nobody cares about the transaction size and the fees.
What will force the users like casino, exchanges, doublers, etc to abadon their currens software which accepts p2pkh addresses and move to segwit addresses?

ur assuming a pool cannot made a funky segwit without 95%.. if it was impossible.. then that blows apart your whole argument about backward compatibility accepting segwit.

so lets assume a pool got the code on day one and made a funky tx, added it to a block before any of the other pools upgraded. they would treat it as a valid block with a funky tx that they just blindly pass on.

EG lets say segwit is not publicly released for 2 weeks. but a pool grabbed the code from testnet today and made loads of transactions in their pools paying themselves. knowing they have 2 weeks of never being checked

hash power doesnt even come into the argument

Sure. This is my impartial view of various scenarios that could attempt to exploit this (also the impartial view that I try to post with).

Scenario 1:
A malicious node (not a miner) creates a transaction that is invalid under segwit rules but valid under old rules and broadcasts it to the network.

Result:
Non-upgraded nodes see the transaction and label it non-standard. They don't relay it and reject it. Segwit nodes see the transaction and they find it invalid. They don't relay it and reject it. Segwit miners do the same as the segwit nodes and the transaction is never included into the blockchain.

Scenario 2:
A malcious miner creates a transaction that is invalid under segwit rules but valid under old rules and includes it into a block he mines.

Result:
A non-upgraded node would validate the block and accept it because it is valid under the old rules. The segwit nodes and miners would see it and reject it because it includes an invalid transaction. If we assume that the segwit miners have a majority of the hash power (as it should be when segwit is deployed with a 95% threshold), then the malicious miner cannot keep up with the network and produce a longer blockchain. The rest of the miners would produce blocks that orphan the invalid one and non-upgraded nodes would go back to the correct blockchain after it grows longer than the malicious one.

If we assume that the malicious miner has a majority of the has power, then we have ourselves a 51% attack which we all know is a problem by itself. This attack is made worse since the old nodes could be tricked to believe that those malicious transactions are legit and that miner can basically trick that part of the network into thinking the miner has more money than he actually does.


Short of a 51% attack, I don't see a problem. Do you have any other scenarios you want me to examine?

= blindly accepting a block that contains data it cannot verify..

can you atleast wear your impartial hat for 1 minute to see how this can be abused..
EG someone makes a nonstandard tx to pay themselves alot of bitcoins and gets it added to pool that wont check it.
(yes its possible to push tx to pools you know of directly..)

please just take off the fanboy hat for 1 minute. and put on the sceptical, impartial, bug finding, risk analysing hat.. just once

Wanna post that here? Besides the fact that that post is full of incorrect statements, I don't want to post in that cesspool of a forum.

Thanks, I fixed those.

No (okay, maybe like three words of what you said I might include).

I agree that they are just "compatible nodes".

Not true. The standardness rules says that anyonecanspend outputs are non-standard and are thus not relayed. Thus non-upgraded nodes will consider segwit transactions as non-standard and refure to relay them. However, when it sees that the transactions are in a block, it will still be able to validate the block and accept it even though it contains non-standard transactions.

The physical data will be more than 1 Mb for segwit capable nodes. This has never been claimed otherwise.

The real data hitting the hard drive will be less than 1 Mb for a non-segwit capable node. Because it doesn't have the NODE_WITNESS service bit set, then it will not receive blocks and transactions with the witness serialization format. The data in the normal transaction format will still be less than 1 Mb.

You should do the same with playing up the benefits of hard forks.

change to

Segwit deployed as a soft fork is sometimes safer than a hard fork. A soft fork means that backwards compatibility can still function even if they no longer know what they are processing. Old versions of Bitcoin software will be able to function but without fully checking new features when a soft fork is deployed.

In contrast, a hard fork and softfork both require that every single Bitcoin user upgrade their software to support the new consensus rules, but softforks can still function by just confusing the old clients into not bothering to check what they are processing, making the old node no longer full nodes. but 'compatible nodes'

the danger is that the majority do not upgrade because they have been lied to saying that there is not a problem, and basically passing a blind parcel of data around the network that they dont check.

hard forks with a small priority grace period to kick peoples ass into action can be safer. because by upgrading you regain full node status, and by making it a short priority grace period you wont run into the issues of lazy people avoiding the upgrade because they stupidly think there is no reason to do it straight away.

---

change to
The other difference is whether to include the witness data in the block size count, and to maintain backwards compatibility while also having the capacity increase, it was decided to not do so. meaning the point of the maxblocksize variable becomes useless because physical data will no longer be 1mb, but more

PS.
if you think the above is Fud. then i dare you to stick with 0.8 for the rest of your life and try to claim that you are still a full node. and pretend that for the next year every real data hitting your hard drive will continue to be less than 1mb.

please try not to play down the risks like a biased fanboy, pretending the world is made of candy floss clouds and everything is perfect.