Block size/weight fraud proofs #10074

luke-jr commented at 8:06 AM on March 25, 2017: member

Status: Untested, could use further optimisation

Implements BIP 180 to a usable state. Only provides proofs, but also implements and uses verification internally.

CSHA256: Allow importing/exporting midstate 26331e3051

proofs/size: Initial size fraud proof class and code e256cd9350

proofs/size: Check full-size proof itself 4e8c2138fc

Move GetWitnessCommitmentIndex onto CBlock (plus minor optimisation) 64a4dd54f2

proofs/size: Check witness hash 7529a7089c

proofs/size: Reject proofs with duplicate merkle hashes in proof-provided data 9bc68f1532

proofs/size: Fix serialization a719965900

P2P: Support getfraud/fraud protocol 8f625c4f5c

buuser commented at 9:04 AM on March 25, 2017: none

NACK

This is an unnecessary addition to the codebase and consensus protocol.

jonasschnelli commented at 11:15 AM on March 25, 2017: contributor

@buuser: please add some technical arguments or observations. Simply saying no is not appropriate here.

in src/net_processing.cpp:2616 in 8f625c4f5c

2611 | +                if (pindex->nStatus & BLOCK_FAILED_VALID) {
2612 | +                    if ((pindex->nStatus & BLOCK_VALID_MASK) >= BLOCK_VALID_TRANSACTIONS) {
2613 | +                        // These are only reached when block size/weight are known to be good
2614 | +                    } else {
2615 | +                        CBlock block;
2616 | +                        const bool ret = ReadBlockFromDisk(block, pindex, chainparams.GetConsensus());

NicolasDorier commented at 8:50 AM on March 30, 2017:

probably need to test (pIndex->nStatus & BLOCK_HAVE_DATA) in case of pruned node.

sdaftuar commented at 4:05 PM on March 30, 2017: member

I think BIP 180 is an interesting observation, but I don't think that it makes sense to merge an implementation of it into Bitcoin Core.

For BIP 180 support to be useful, Bitcoin Core would need to go out of its way to download and store invalid blocks to be able to generate proofs for light clients. Currently, we make no effort to do this (in fact, from a very quick glance at the code in this PR, I don't see how this code can possibly work, because blocks whose invalidity is detected in CheckBlock or ContextualCheckBlock aren't even written to disk, and that's where the size checks are done).

While we could attempt to "fix" that narrow issue, I also don't think it's worth pursuing as a goal: BIP 180 only makes sense in the context of a non-cooperative forking chain (as a cooperative one would e.g. provide signaling so that SPV clients could choose the headers chain they wish to follow), and if we assume non-cooperation, then BIP 180 wouldn't make sense if it's easy to subvert -- which it is. For instance, suppose the first block in the forking chain had too many sigops but passed the blocksize/weight checks. Bitcoin Core would not download any blocks that build off such an invalid block hash, because we'd know the chain to be invalid from the headers, and then wouldn't be able to provide any BIP 180 proofs to light clients.

We could try to rearchitect Bitcoin Core's consensus logic to try to make such fraud proofs available, by downloading later invalid blocks on a known-to-be-invalid chain and storing them, but this is a big change and IMO not worth doing. I think we have a number of obstacles to overcome in order to make this work (see eg #9530, I think the improvements discussed there will already be review-intensive) and adding everything we need to ensure that BIP 180 would always work in Bitcoin Core seems like too much of a burden.

Anyone who wanted to provide BIP 180-proofs to the network could do so as a separate service, and I think this is actually substantially easier to implement outside Bitcoin Core (since if you're providing these proofs as a separate service, you can solve the DoS issues more easily than we can do in Bitcoin Core, where the assumptions are different).

Concept NACK.

NicolasDorier commented at 3:03 PM on April 1, 2017: contributor

I think that a better, less intrusive way to do it, is to make it works in a "gossip" manner. Instead of having the client asking fraud proof for all the blocks, it would be up to the node to broadcast fraud messages in an unsollicited manner to other peers.

A way of doing that would be: If node detect a fraud which pass PoW, then store in RAM up to X proofs, then broadcast them unsollicited. (like addr messages)

This would make it more trivial and less intrusive to implement. And even pruned node would be able to do it.

This would be enough for SPV client to "discard" one chain.

jnewbery commented at 6:37 PM on April 1, 2017: member

It'd be great to see BIP180 as a separate application or a fork of bitcoind, but concept NACK merging this to core for the reasons @sdaftuar sets out above. Adding this kind of functionality and the architecture changes required to make it work place too much of a maintenance burden on bitcoin core.

jnewbery commented at 7:13 PM on April 1, 2017: member

Alternatively, you could offer this as a PR to https://github.com/BitcoinUnlimited/BitcoinUnlimited . They already have all the necessary functionality to propogate and store invalid blocks, but I hear they've been having stability issues of late.

gmaxwell commented at 10:51 PM on April 1, 2017: contributor

Is there any willingness to support such a thing in any existing lite-clients?

I think suhas' concern could be addressed by constructing a proof at the time we reject the block and saving it--- but the matter is moot unless someone will use it.

As an aside, thanks for going and implementing. It's good to see a version of this that isn't just talk.

NicolasDorier commented at 5:47 AM on April 2, 2017: contributor

pinging @voisine

laanwj added the label Validation on Jun 26, 2017

luke-jr commented at 6:31 AM on July 17, 2017: member

Closing due to lack of interest.

luke-jr closed this on Jul 17, 2017

jtimon commented at 1:26 AM on July 18, 2017: contributor

I am very interested in this, but I thought you said there was a flaw/missing_piece in the design on the mailing list.

DrahtBot locked this on Sep 8, 2021