RCP-240313A: SPV proofs for anchor transactions

[adambor]

layers: consensus, standard library
consensus: fast-forward

Currently all anchors inside a consignments are identified by just by their transaction ID. Verification of a consignment therefore requires an access to a fully indexed bitcoin node and checking many random transactions by their transaction ID - this might be impractical and slow for many user (with those users resorting to 3rd party nodes and blindly trusting those).

A solution is to include the SPV proof (merkle proof + raw bitcoin transaction) for all the anchor transactions. This way a client can quickly (in ~15 double SHA256 hash invocations) check that an anchor transaction is valid while only having access to bitcoin blockheaders (such as when running a heavily pruned bitcoin node, or even just a bitcoin light client node).

The SPV proof should be included in the anchor transaction definition as an optional parameter. It is important to note that an SPV proof for the latest state transition is not immediately available (since SPV proof can only be obtained once the anchor transaction is included in a block). There also might be some anchor transactions for which there is no SPV proof provided in the consignment, this is not a problem since anyone can look up those transaction and add SPV proofs for them later - this also means adding SPV proofs will be backwards compatible with old consignments.

As discussed in the RGB WG by @fedsten the requirement for having SPV proofs in the consignments should be indicated by the recipient in the RGB invoice, because the recipient might not have an access to a fully indexed bitcoin node (and is therefore unable to verify consignments without SPV proofs).

[dr-orlovsky]

Concept and approach ACK

[22388o]

Wow! This is a awesome idea! :)

ACK.

[dr-orlovsky]

I found that we do not need to modify consensus or use anchors for this: instead, we can store all SPV proofs in consignments, since they do not participate the validation. It is up to the "resolver" which asks Electrum/Esplora/Bitcoin Core, which now instead of calling that network services can just failback to use SPVs in the consignment

[adambor]

Makes sense, SPV should be just "hints" for the tx resolver. So doesn't need to be part of RGB consensus but should be passed to the tx resolver.