[feat] Add script that extends program arguments with Utreexo state and inclusion proofs

[Jeanmichel7]

• [x] resolves #211
• [x] follows contribution guide
• [ ] code change includes tests

Execute script

cd packages/client && scarb run utreexo [block start] [block end] #default 0 200

• [x] Generates block sequences in the .client_cache file
• [x] Generates Utreexo on these blocks
• [x] Generates data in client/tests/utreexo
• [x] Test 10'000blocks

Hash outpoint from Cairo corelib

cd packages/consensus && scarb cairo-test -f test_poseidon1
//ref oupoint hash : 0x1E8BBC31DA001E7EBACAEBC83DF1FD241040B9525ADEECEADBBC7045C6D1876

Hash outpoint from Python script

cd packages/client/ && scarb run utreexo
// Output point hash: 0x1E8BBC31DA001E7EBACAEBC83DF1FD241040B9525ADEECEADBBC7045C6D1876

The hash appears to be correctly created, added to the Utreexo, and then deleted from the Utreexo in block 170.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
raito	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 26, 2024 5:21pm

[m-kus]

Yeah, there's no reference to compare unfortunately, but the point here mostly is to test that our Cairo accumulator behaves as expected.

What is the exact issue with cached field?

[Jeanmichel7]

Yeah, there's no reference to compare unfortunately, but the point here mostly is to test that our Cairo accumulator behaves as expected.

What is the exact issue with cached field?

When I hash the outpoint to delete, the cache is not the same as when I added it, so booom.

example: utxo spends block 170 tx f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 input.outpoint.hash = false

block9 (original) input.cache = true

I don't really understand why we have values set to true when retrieving data from the RPC, is that normal?

[m-kus]

output.cached is a hint, it's not part of the PRC response. I'm not sure I get it, probably you meant that input.outpoint.data.cached (block 170) != output.cached (block 9)? If so, then there's an error in the script. Cached flag is set to true only if the output is spent within the same block.

[Jeanmichel7]

output.cached is a hint, it's not part of the PRC response. I'm not sure I get it, probably you meant that input.outpoint.data.cached (block 170) != output.cached (block 9)? If so, then there's an error in the script. Cached flag is set to true only if the output is spent within the same block.

Yes, that's right, sorry I wrote nonsense. I use generate_data.py to generate my sequence of blocks, it defines if it's cached or not I'm not supposed to modify the cache right?

Maybe an error in generate_data or I missed something

[m-kus]

Basically, if you see an output with cached=true you don't need to add/remove it to/from the accumulator.

[Jeanmichel7]

Basically, if you see an output with cached=true you don't need to add/remove it to/from the accumulator.

I think the problem came from the generate_data.py script l284 utxo_set = {} was defined before looping through all the blocks, so it defined the cached according to the first block traversed and not from the same block.