Quote from: knightdk on April 03, 2016, 01:52:45 PM

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