Topic: Clearing the FUD around segwit - page 2. (Read 3963 times)

No, that block will not be invalid. The rule is not enforced for any blocks before the specific block where the activation starts, all at once for everyone upgraded (including the 95%+ hashpower that triggered it). The blockchain itself assures that the triggering is coordinated and that almost all the hashpower is running software that can enforce at that coordinated point.

i think knightdb cannot get beyond the concept that segwit is not foolproof. so its best i leave him to wallow in his small box of bug free perfect code, cushioning himself with candyfloss clouds and pink unicorns. blissfully ignorant that the world is not the dream laid out on whitepapers, while he pretends it is

have a good month everyone

before segwit is released someone can make a segwit tx. where the witness data is not part of the transaction.

a better analogy than anyone can spend is that any signature data is treated as just a 'message'. that is overlooked and not checked or done anything to.
old clients will just see it as a funky tx.

again segwit tx is not a op-true so please look away from the anyonecanspend analogy and concentrate on op_0. and only op_0.. they are different things entirely.

so knowing old clients are backward compatible to blindly look passed segwits. it proves that old clients would not reject or orphan a block containing a segwit. otherwise segwit is not backward compatible. and blocks would get rejected all the time by old clients.(if the opposite to reality could occur)

its just basic logic/common sense.
old clients wont reject a segwit transaction

and nothing in the future when the real segwit it activated changes for old clients.. remember old clients wont upgrade so nothing changes for them. what they look blindly passed now they will look blindly passed in the future.

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.

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?

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.

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

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

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.

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 ?

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

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.

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

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.

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

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.

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

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

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?

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

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!