Check Slatepack file size before loading contents

[unseddd]

Check Slatepack file size is within valid range before loading contents into memory.

[antiochp]

Not sure max_block_size is the right thing to base slate size limit off.
A slate will potentially have a max size transaction plus additional data. May be easier to simply hardcode/configure a max size directly in wallet itself.

[unseddd]

Not sure max_block_size is the right thing to base slate size limit off.
A slate will potentially have a max size transaction plus additional data. May be easier to simply hardcode/configure a max size directly in wallet itself.

I had similar reservations about directly basing max Slatepack size on max block size, since the metadata in block is not one-to-one with the metadata in Slatepack. However, hardcoding max size in wallet isn't fool-proof either, and has overhead for any changes to max block size in the node (i.e. developers will have to remember to manually update max Slatepack size).

Ideally, the max Slatepack size would be: MAX_BLOCK - BLOCK_HEADER + SLATEPACK_METADATA (maybe with some extra space for whitespace + >). Though, with Slatepack files, there should be no whitespace, since the files are presumably generated by wallets (not copy-pasted). Slatepack metadata size might be hard to calculate precisely, since it would vary between binary and JSON encoded Slatepacks.

IIUC, the above formula would encode max transaction size + Slatepack metadata size + acceptable whitespace size. WDYT?

[davidtavarez]

It would be nice to write some tests for this.

[unseddd]

Updated with new grin_api::max_tx_size function, and calculation for additional Slatepack metadata. @antiochp let me know what you think.

[antiochp]

I think this looks good.
One question about where to do the size validation.

[unseddd]

Tests are failing to compile due to grin_core::global::max_tx_weight not being tagged. Tests pass local testing, with some workarounds for versioning, changes unrelated to this PR, etc.

[yeastplume]

Tests are failing to compile due to grin_core::global::max_tx_weight not being tagged. Tests pass local testing, with some workarounds for versioning, changes unrelated to this PR, et

For dev on master just run cargo update to get the latest version of master from grin core, it'll make changes to Cargo.lock but that's fine at this stage of development

[unseddd]

For dev on master just run cargo update to get the latest version of master from grin core, it'll make changes to Cargo.lock but that's fine at this stage of development

Build still fails due to traits not being in scope or implemented. Any tips on resolving failures like here and here (here or another PR)?

[yeastplume]

For dev on master just run cargo update to get the latest version of master from grin core, it'll make changes to Cargo.lock but that's fine at this stage of development

Build still fails due to traits not being in scope or implemented. Any tips on resolving failures like here and here (here or another PR)?

hrm.. crap. It looks as if some dependency is trying to pull in a different version of ed25519 dalek then we use. Let me look into this and fix via another PR.

[unseddd]

Let me look into this and fix via another PR.

Sounds good to me, will rebase over the fix.

[yeastplume]

@unseddd Should be all good now, could you try again rebasing with latest master please?

[unseddd]

@yeastplume the fix worked, many thanks 😄