Quote from: RoadTrain on December 12, 2015, 09:29:13 PM

Quote from: franky1 on December 12, 2015, 06:57:28 PM

Quote from: RoadTrain on December 12, 2015, 06:53:42 PM

Ok, ask a question and I'll try my best to answer it. But as you are waiting for a detailed answer, I'll have to spent a significant amount of time replying. So please make it concrete.

i know splitting the blockchain into 2 is not needed.. SWliteclients can prune what they like how they like without messing with the real blockchain.
i understand the benefits of adding new opcodes..

but the real question is.. how is the fraud proof so special that only SW proposition can implement it. explain how the fraud proof works in your own words

"Have you stopped beating your wife?" Who argues that only SW can implement fraud proofs? It's a neat additional feature that is relatively straighforward to implement with SW.

Fraud proof is simply some compact data telling you that Bitcoin rules were violated. For many of the rules we can create compact proofs that they were violated. But there are two types of fraud that we can't compactly prove right now. These are subsidy fraud (inflated fees) and spending from a non-existent input. Pieter Wuille suggests we store additional data with SW, that isn't present with blocks currently, so by having it we can compactly prove these types of fraud. These data are input values, and a 'path' of inputs (original block height containing that input and a position within that block). Once this data is made a consensus rule, full nodes can simply broadcast, say, a message telling you "This input is invalid because it doesn't exist within the block it claims to", then you check that and decide to ignore the chain with this invalid input.

Fraud proofs are still more of a theoretical approach, and will require careful engineering to make them operational. But making all consensus rules compactly provable is a necessary step towards that.

or more simply.. if someone has already checked it.. instead of writing in an opcode to say its invalid.. they just dont relay it..
relying on someone else to do checks, to trust them when they say everything is ok, and only double check when they say is wrong seems a little backwards

even right now i can check a tx from back in 2009 and see if its valid just searching the txid....
i agree that adding in the blockheight and tx position of originating confirmed funds in a new unconfirmed tx can make searching the original tx easier.. but if its invalid.. you simply dont relay it.. bt i still dont see this a fraud proofing.. just making the checking mechanism slight faster (microseconds) by having the header and tx index.
i hopefully dont want to see anyone relaying an invalid tx just to tell someone its invalid. and they blindly trust opcodes without checking source.

i think every bitcoin software whether its SPV, SW, LN or core all check every transaction before saving to file or relaying. never should they just see
OP_Check="im legit" and accept it blindly. nor should they ever receive a invalid transaction, thats already been checked as invalid

that said im all for blockheight txindex.. just not the other part