Payment verification workflow for SPV with UTXO proof

[greenhat]

After ergoplatform/ergo#1525 is implemented we can get the UTXO proof (unspent box) in the current state (block). See details in ergoplatform/ergo#1525 (comment)

For a recent payment, we can get the UTXO proof in the current block and wait for n blocks for confirmation.

For an old payment, it's faster to use NiPoPoW proof described in #495

Goal

Confirm that boxes with the given ids are in the UTXO, i.e. are not spent. Confirm that the contents of the boxes are indeed as expected.

Step 1. Choose randomly N nodes from the known nodes list.

Step 2. Ask each node for:

• 2.1 blocks/lastHeaders/1 to get the last header and verify the received header with AutolykosPowScheme::validate() and check that header.timestamp is no more than block time(5 min) old. Also, verify that the received block is in the chain via Step 1.1 from NiPoPoW workflow Payment verification workflow for SPV with NiPoPoW #495.
• 2.2 utxo/getBoxesBinaryProof with the given boxes id;

Step 3. Verify the boxes.

• 3.1 Verify UTXO proof from every node (from 2.2) via AdProofs::verify using last header's stateRoot (from 2.1) as previous hash(digest) and Lookup op(state change) for every box. Where to get the expected hash? For all N nodes UTXO proofs must be verified. The only reason for the verification to fail is either node's last header is too old (before the box was created) or the box was already spent.
• 3.2 Ask any node from the list of known nodes for /utxo/byId/{boxId} for each box id to get the box contents;
• 3.3 Verify that the received box content corresponds to the box id by checking that the id of the parsed box from JSON is the same.
• 3.4 Verify that box content is as expected (guarding script == your PK, coins and/or tokens amount, etc.).

Needs to be implemented

Rust equivalent of

• AdProofs.verify
• AutolykosPowScheme.validate()

[greenhat]

@kushti @knizhnik
I have some questions:

• What is a minimum N in step 1? I mean we cannot trust a single node in steps 2.1, 2.2. Or can we?
• What if utxo/getBoxesBinaryProof in step 2.1 is requested multiple times on the same node before the next block arrives? New previous digest to be used in verification on every subsequent call will be different until the new block arrives?
• Where to get the expected digest for the verification (via AdProofs.verify) of the UTXO proof received in step 2.2?

[kushti]

@greenhat "For a recent payment, we can get the UTXO proof in the current block and wait for n blocks for confirmation" - without validating the chain first with the help of nipopows that is not secure simply.

For checking nipopows, if peers are chosen randomly, N = 2 would be enough even. Please note multiple nodes are needed to validate NiPoPoWs just, proof of utxo/getBoxesBinaryProof relies on hash function security if the chain is proven.

Why to ask utxo/getBoxesBinaryProof multiple times ?

[greenhat]

@greenhat "For a recent payment, we can get the UTXO proof in the current block and wait for n blocks for confirmation" - without validating the chain first with the help of nipopows that is not secure simply.

Thanks. I'll add the nipopow check.

For checking nipopows, if peers are chosen randomly, N = 2 would be enough even. Please note multiple nodes are needed to validate NiPoPoWs just, proof of utxo/getBoxesBinaryProof relies on hash function security if the chain is proven.

Got it.

Why to ask utxo/getBoxesBinaryProof multiple times ?

If a user initiates a second check on the same payment, or one of the subsequent network requests fails and the user starts it from the beginning.