Clearing the FUD around segwit

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

4 years of thousands of people using bitcoin and they still found a bug in 2013.
and 2014
and 2015

so ahandful of people now and again doing transactions in their spare time.. well it really doesnt compare.

by the way reading the irc logs, you cannot really see much chatter about then trying to break it using scenarios it seems more like making sure coins arnt accidentally lost rather then purposefully trying to gain/move/create/destroy coins.

try not to have blind faith in a system thats not even released.
after all everything thinks windows works but i bet everyone knows what a blue screen of death is

there are atleast 12 different implementations of bitcoin all wrote with different languages and multiple version.. im damn sure they are not going to test all of them to live up to the promise of bug free backward compatibility that cannot be hacked or abused.

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

[1713892175]

1713892175

[1713892175]

1713892175

[franky1]

It is up to the developers of the other software to follow the publicly available specs

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

[achow101]

It is up to the developers of the other software to follow the publicly available specs

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

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.

[bitboy11]

If I don't keep reading threads like this every week, then the new technical jargon being spouted out in these threads will leave me in the backwoods. I can imagine people who are not so tech savvy will get confused easily.
How is this supposed to become mainstream again?
Certainly, we are going to have to come up with easier explanations for the consumption of the general public.

Gold certainly isn't this complicated!

[franky1]

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.

but how do you know that.. like i said have they tried segwit on the testnet and then had other non-segwit implementations on the same chain to see how they react..

like i said unless they are going to try everything they cannot promise everything

[LovelyDay]

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.

If I sold you a car radio, and claimed that it was 'backwards compatible' with your car, and then later you read the manual and discovered that it causes your airbags to no longer work, and you'd have to buy some new airbags from me as well just to be safe and secure again - you wouldn't call my radio 'compatible' with your car, would you?

[franky1]

If I don't keep reading threads like this every week, then the new technical jargon being spouted out in these threads will leave me in the backwoods. I can imagine people who are not so tech savvy will get confused easily.
How is this supposed to become mainstream again?
Certainly, we are going to have to come up with easier explanations for the consumption of the general public.

Gold certainly isn't this complicated!

i know what you mean. i have tried to use the least technical jargon, EG saying how its funky tx as oppose to op_0.. but there are some that try to be technical by saying UTXO, instead of unspents.. yet they are so technically one-minded, they cant think outside of the box at the bigger picture.
it becomes even funnier when their use of buzzwords fail. it adds to the confusion because people blindly believe them because they have thrown in some buzzwords to seem technical.

by far the worsed culprit of this is Lauda. who pretends to be a know it all but thought that bitcoin-core wrote the code in java..

they have blind faith that things will work perfectly. when the mindset should be to treat it as always broken until you tried every single different possibility until its not broken anymore.

blindly saying something is perfect or works before its released is like bill gates saying that blue screens of death will never happen
even now many smart people do not instantly download the new versions of windows. but wait for a couple service packs to be released. and that is the mindset everyone should have

[achow101]

but how do you know that.. like i said have they tried segwit on the testnet and then had other non-segwit implementations on the same chain to see how they react..

like i said unless they are going to try everything they cannot promise everything

They will be. Prior to deployment on the mainnet, segwit will be deployed on the testnet. I do not know whether they have had non-segwit nodes on the segnet chain. It is fairly trivial though to implement a node to run on segnet and see if it works.

If you think that they aren't going to test everything, why don't you help out and test things yourself? It is all publicly available.

If I sold you a car radio, and claimed that it was 'backwards compatible' with your car, and then later you read the manual and discovered that it causes your airbags to no longer work, and you'd have to buy some new airbags from me as well just to be safe and secure again - you wouldn't call my radio 'compatible' with your car, would you?

Clearly that isn't backwards compatible, but that is not an analogy for segwit.

[johnyj]

If I don't keep reading threads like this every week, then the new technical jargon being spouted out in these threads will leave me in the backwoods. I can imagine people who are not so tech savvy will get confused easily.
How is this supposed to become mainstream again?
Certainly, we are going to have to come up with easier explanations for the consumption of the general public.

Gold certainly isn't this complicated!

That's the problem with current core's approach, they don't make things easier to understand, they make it more difficult to understand, thus any technical debate would easily extend to several thousand lines and just become TL'DR for average people, so no decisions can be made

In principle, changing the current way of signing the transaction is a simplification of the transaction format and can be considered an improvement towards simpler design (even that require months of discussion). However, by doing soft fork, it separate the signature and scripts into another block structure, that is a total complication of the bitcoin architecture and created many new added logic that make the system much more error prone

Of course you can make millions of tests and make the system work to a certain degree, but a slightest future change to the environment will make majority of those tests fail and certain parts have to be redesigned, but you can't do this when a financial system is on 24/7 live traffic. Complex system is fragile, you don't want to build a financial system on a rocket that can explode any time

The complex way of turning a page  
https://www.youtube.com/watch?v=GOMIBdM6N7Q

[LFC_Bitcoin]

knightdk - You really are one of the most knowledgable posters on this forum.

Ignore any pathetic trolling you get in this thread & keep up the good work.

[franky1]

knightdk - You really are one of the most knowledgable posters on this forum.

Ignore any pathetic trolling you get in this thread & keep up the good work.

lol knowledgable.
1. he does not know if segwit is fully backward compatible, as he doesnt even know if other implementations have been tested to ensure there are no bugs.
afterall if a v2 segwit can cause a bug with v3.. then obviously there is a chance that segwit can cause forks vs old clients

2. the anyonecanspend analogy is so much fail. NO ONE can spend because right now it would look like a funky transaction that is unspendable. because no one would see the sigops. and when segwit is released its already in a block covered by hundreds of confirmations so the other features like not revalidating old blocks before a checkpoint wont be done as its falsely presumed the checks must have been done by other nodes in the passed (yes thats right they actually added a feature to not re-validate blocks they are syncing to)

3. when segwit is released it shows to segwit the sigops because segwit understands the order of the tx. and so it sees the malicious address owns the funds now and then the malicious address then spends them using their privkey

the reason the anyonecanspend is so much fail. is because a real anyonecanspend is an op_true. where part of the transaction has the signature for the input included but the destination is funky.. segwit utilizes op_0 to make both input and output signatures funky. thus its not an anyonecanspend, but a no one can spend funky transaction locked into a block..(in the eyes of an old client)

he is working on blind faith of what has been proposed in a glossy leaflet(whitepaper to be more precise). he lacks the critical mind to examine everything and trust nothing until its proven, and you cant prove vapour is solid until you handle it and it has cooled down and settled

[Dusty]

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.

Your example is invalid because this "malicious miner" can't include an invalid tx in a block, otherwise the whole block would be invalid and hence rejected by the network.

The tx would be invalid, no matter how "funky" it is, because you have to correctly sign the inputs, and if you do not have the private keys of the inputs, you can't provide signatures.

No way to bypass that step, it's how Bitcoin works, and it's made expressly to avoid the attacks you are describing.

[franky1]

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.

Your example is invalid because this "malicious miner" can't include an invalid tx in a block, otherwise the whole block would be invalid and hence rejected by the network.

The tx would be invalid, no matter how "funky" it is, because you have to correctly sign the inputs, and if you do not have the private keys of the inputs, you can't provide signatures.

No way to bypass that step, it's how Bitcoin works, and it's made expressly to avoid the attacks you are describing.

to a old client its not invalid.. its just funky.. just like old clients would treat transactions in the future after segwit is released.. still funky to old clients.
remember old clients WILL NOT see the signature area. so they wont validate the transaction. they will just blindly accept it.
if you think old clients wont accept blocks accepting segwit style tx's then segwit is not backward compatible.. (yet it is so that ends that debate)

its not an anyone can spend because of other consensus rules that prevent that too.. (otherwise old clients can abuse segwit later by pushing transactions to nonupgraded pools)

once you understand that segwit is not the exact same as an anyone can spend. but is similar only in the lack of validation part. you will start to see the bigger picture.

my scenario is that while funky in an old client.. its added before segwit clients exist. and so its accepted as funky (op_0). but unspendable due to being funky(different to a true anyonecanspend)

later. separately (please put the first scenario into a box and push it back in time by a month, no longer caring about it because its in the past confirmed into a block but no one can do anything with it back then..)

now new segwits put a checkmark in and dont bother checking the old blocks as they are deemed as pre-checked..
so again even the new segwits wont orphan off the block from a month ago. and if they did, well thats atleast 3000 other blocks they need to orphan off..
(think about it, have a cup of coffee and think about it).

so they havnt orphaned off the first scenario block from one month ago.

but now someone knowing that segwit hasnt checked the old block but has built up a list of utxo's and can see that the first scenario did actually have an output to an address because segwit can now see the sig-ops...

so the owner of the keys to that output now makes a new transaction using a private key to spend that..

[hv_]

Just to summ up / that attack would be like that:

A miner

1) modifies his own mining code to enter  already the SW link into the correct place

2) mines a BAD block NOW, Long time before SW goes live

3) Now he can do lots of real txs like spending BTC (but get back when)

4) SW goes live and all blocks down to his BAD block get orphaned and his spending from 3) are neglegted

? correct ?

[achow101]

franky went on irc to try to explain his scenario. this is the part of the exchange that matters because this is wher ethe flaw in his attack is explained (and i have been giving this explanation for the past couple of pages). Franky is testicools here.

testicools> ok.. lets try this from a different angle. maybe that would clarify it. i make a transaction to spend satoshis 2009 stash.. BEFORE the checkpoint. if your saying anyone can spend that transaction after i have made it.. then goodluck
<CodeShark> how do you intend to spend satoshi's 2009 stash unless you have satoshi's private keys?
<testicools> because im using segwit code before its released so the signature doesnt get validated..
<CodeShark> you still need to have valid signatures to spend satoshi's stash
<CodeShark> satoshi's stash is not held in anyone-can-spend outputs
<testicools> old clients wont see the signature area..
<CodeShark> those signatures will be in the old area
<CodeShark> to spend a nonsegwit output you use a nonsegwit input
<testicools> not if i write a segwit transaction
<sipa> that would be invalid
<sipa> he output being soent determines where the signatures go
<testicools> but sgwit transactions are not invalid because old clients just treat them as funky transactions
<sipa> the outout being soent determines where the signatures go
<sipa> you can't use a segwit transaction to spend satoshi's coins. not to old clients, not to new ones
<sipa> please read up on the design
<testicools> so no one can move coins between old and new.. that makes segwit useless ..
<sipa> yes you can
<sipa> being segwit is a per-input and per-output thing
<CodeShark> to spend a nonsegwit output you use a nonsegwit input - the transaction containing this input can still have segwit outputs
<sipa> you can have a transaction that spends from a segwit output and moves to a normal one or the other way around
<sipa> but to spend a non-segwit output, you need non-segwit input
<sipa> and the other way aroundt

[Dusty]

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.

Your example is invalid because this "malicious miner" can't include an invalid tx in a block, otherwise the whole block would be invalid and hence rejected by the network.
The tx would be invalid, no matter how "funky" it is, because you have to correctly sign the inputs, and if you do not have the private keys of the inputs, you can't provide signatures.
[...]

to a old client its not invalid.. its just funky.. just like old clients would treat transactions in the future after segwit is released.. still funky to old clients.
remember old clients WILL NOT see the signature area. so they wont validate the transaction. they will just blindly accept it.

I'm sorry, but you just don't understand how bitcoin works (and hence segwit): as many others have already explained to you, you are just confusing inputs with outputs.
While it's true that old clients will not verify segwit signatures, those signatures are for segwit outputs. Old transactions (like the one of satoshi you would suggest) are old-style transactions and hence, with new or old rules, needs normal signatures for their inputs.
So you can't spend them in both old or new network rules without having the relevant private keys, no matter how "funky" the outputs are (please understand this is the only part of the tx you can mess with).

[Carlton Banks]

knightdk - You really are one of the most knowledgable posters on this forum.

Ignore any pathetic trolling you get in this thread & keep up the good work.

Thread has mostly been one massive Where's Waldo - location troll cave, knightdk as Waldo

[gmaxwell]

Just to summ up / that attack would be like that:
A miner
1) modifies his own mining code to enter  already the SW link into the correct place
2) mines a BAD block NOW, Long time before SW goes live
3) Now he can do lots of real txs like spending BTC (but get back when)
4) SW goes live and all blocks down to his BAD block get orphaned and his spending from 3) are neglegted
? correct ?

Soft-forks are not enforced on the older parts of the chain. Only in blocks from two weeks after 95% of the hash-power had signaled their intent to enforce (counted over a 2016 block interval after the change start-time).

For prior soft-forks, like strictder, there are many historical violations before where it was enforced. It does not make the chain invalid, only violations after the point where the new rule's enforcement begins would do so.

[hv_]

Just to summ up / that attack would be like that:
A miner
1) modifies his own mining code to enter  already the SW link into the correct place
2) mines a BAD block NOW, Long time before SW goes live
3) Now he can do lots of real txs like spending BTC (but get back when)
4) SW goes live and all blocks down to his BAD block get orphaned and his spending from 3) are neglegted
? correct ?

Soft-forks are not enforced on the older parts of the chain. Only in blocks from two weeks after 95% of the hash-power had signaled their intent to enforce (counted over a 2016 block interval after the change start-time).

For prior soft-forks, like strictder, there are many historical violations before where it was enforced. It does not make the chain invalid, only violations after the point where the new rule's enforcement begins would do so.

Thanks & yes, I got that. But this soft fork happens at 4) or two weeks later.
The question is, whether the new coded miners (SW enabled) will orphane the non SW chain down two that BAD block made in 2)  because they will all agree that this BAD but old block is the last valid SW one since it contains the correct LAST  correct SW  entry?

[achow101]

Just to summ up / that attack would be like that:
A miner
1) modifies his own mining code to enter  already the SW link into the correct place
2) mines a BAD block NOW, Long time before SW goes live
3) Now he can do lots of real txs like spending BTC (but get back when)
4) SW goes live and all blocks down to his BAD block get orphaned and his spending from 3) are neglegted
? correct ?

Soft-forks are not enforced on the older parts of the chain. Only in blocks from two weeks after 95% of the hash-power had signaled their intent to enforce (counted over a 2016 block interval after the change start-time).

For prior soft-forks, like strictder, there are many historical violations before where it was enforced. It does not make the chain invalid, only violations after the point where the new rule's enforcement begins would do so.

Thanks & yes, I got that. But this soft fork happens at 4) or two weeks later.
The question is, whether the new coded miners (SW enabled) will orphane the non SW chain down two that BAD block made in 2)  because they will all agree that this BAD but old block is the last valid SW one since it contains the correct LAST  correct SW  entry?

The problem is that the bad block cannot exist in the first place. You cannot spend from an output that you do not own. Segwit does not change this behavior.