On 07/04/2015 12:44 AM, Peter Todd wrote: > Fact is, SPV means you're trusting other people to check the rules for > you. In this particular case bitcoinj could have - and should have - > checked the BIP66 soft-fork rules, but in general there's no easy > solution to this problem.
In general, the situation can be improved if there existed proofs which validating full nodes could broadcast which would tell SPV nodes why the branch it sees with the most proof of work is actually invalid. As far as I can tell, producing such proofs is reasonably straightforward for all cases except the case where a block is invalid because it contains a transaction which references a non-existent output. The shortest proof that a particular transaction does not exist in the blockchain is the entire blockchain. If each transaction input identified the block containing the referenced outpoint, then the proof of non-existence is either the block in question, or the list of block headers (to show that the block doesn't exist). That's a significant improvement in proof size over the entire blockchain. Proving the non-existence of a particular transaction in a specific block could be made easier for future blocks by requiring transactions to be ordered in the merkle tree by their hashes. Then it would just require a few nodes in the tree to show that the transaction isn't in the place where it should be. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623
0xEAD9E623.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
