Reject UTXO double spends #2511

teor2345 · 2021-07-20T04:51:08Z

Motivation

We don't want users to be able to create new coins by spending transparent outputs more than once.

Specifications

Validation state associated with transparent inputs and outputs, such as the UTXO (Unspent Transaction Output) set, is not described in this document; it is used in essentially the same way as in Bitcoin.

https://zips.z.cash/protocol/protocol.pdf#transactions

each output of a particular transaction can only be used as an input once in the block chain.
Any subsequent reference is a forbidden double spend - an attempt to spend the same satoshis twice.

https://developer.bitcoin.org/devguide/block_chain.html#introduction

Any input within this block can spend an output which also appears in this block (assuming the spend is otherwise valid).
However, the TXID corresponding to the output must be placed at some point before the TXID corresponding to the input.
This ensures that any program parsing block chain transactions linearly will encounter each output before it is used as an input.

https://developer.bitcoin.org/reference/block_chain.html#merkle-trees

Designs

https://github.com/ZcashFoundation/zebra/blob/main/book/src/dev/rfcs/0005-state-updates.md#pub-fn-pushmut-self-block-arcblock

Solution

In the non-finalized state, check transparent spends against previous transactions in the block, the relevant non-finalized chain, and the finalized state
Add errors for each of these cases
Add useful methods to existing types

Closes #2231.

Testing

Test that duplicate transparent UTXOs are rejected by the non-finalized state
- later transactions in this block
- not in the non-finalized state or the finalized state
- previously spent and never created
Fix other tests that fail these new checks
Add test-only methods to existing types
Move existing test functions so they can be used by multiple tests

Review

I'd like a review from @jvff.

This PR will conflict with a bunch of other recent/upcoming state PRs, but the conflicts should be easy enough to resolve.

Reviewer Checklist

Code implements Specs and Designs
Tests for Expected Behaviour
Tests for Errors

zebra-chain/src/block/arbitrary.rs

zebra-state/src/service/check/utxo.rs

zebra-state/src/service/non_finalized_state/chain.rs

zebra-chain/src/block/arbitrary.rs

jvff

Looks good so far. There's only one optional suggestion that I'm not sure if it's valid, but if so it might affect the API of the function in the check module.

zebra-state/src/service/check/utxo.rs

Check that transparent spends use unspent outputs from: * earlier transaction in the same block, * earlier blocks in the parent non-finalized chain, or * the finalized state.

Co-authored-by: Janito Vaqueiro Ferreira Filho <janito.vff@gmail.com>

- split each error case into a separate check - combine `contains` and `insert` - add a missing check against the non-finalized unspent UTXOs - rename arguments and edit error strings for clarity

- accept output and spend in the same block - accept output and spend in a later block - reject output and double-spend all in the same block - reject output then double-spend in a later block - reject output, spend, then double-spend all in different blocks

jvff

I still haven't finished reviewing the tests, I apologize for that :/

zebra-state/src/service/check/tests/utxo.rs

Co-authored-by: Janito Vaqueiro Ferreira Filho <janito.vff@gmail.com>

jvff

Looks good. I just added some optional comments.

That was a lot of tests. If we end up having to write more tests like these, it might make sense to look into writing some more abstractions 🤔

zebra-state/src/service/check/tests/utxo.rs

teor2345 · 2021-07-22T23:06:55Z

That was a lot of tests. If we end up having to write more tests like these, it might make sense to look into writing some more abstractions 🤔

Honestly I tried, there's already a lot of abstractions in there.

teor2345 · 2021-07-22T23:22:08Z

That was a lot of tests. If we end up having to write more tests like these, it might make sense to look into writing some more abstractions 🤔

Honestly I tried, there's already a lot of abstractions in there.

Thinking about this a bit more, we could use something like the contains_(shielded)_nullifier and best_contains_(shielded)_nullifier methods for UTXOs.

But I think the tests are good enough for now.

* ZIPs were updated to remove ambiguity, this was tracked in #1267. * #2105 was fixed by #3039 and #2379 was closed by #3069 * #2230 was a duplicate of #2231 which was closed by #2511 * #3235 was obsoleted by #2156 which was fixed by #3505 * #1850 was fixed by #2944, #1851 was fixed by #2961 and #2902 was fixed by #2969 * We migrated to Rust 2021 edition in Jan 2022 with #3332 * #1631 was closed as not needed * #338 was fixed by #3040 and #1162 was fixed by #3067 * #2079 was fixed by #2445 * #4794 was fixed by #6122 * #1678 stopped being an issue * #3151 was fixed by #3934 * #3204 was closed as not needed * #1213 was fixed by #4586 * #1774 was closed as not needed * #4633 was closed as not needed * Clarify behaviour of difficulty spacing Co-authored-by: teor <teor@riseup.net> * Update comment to reflect implemented behaviour Co-authored-by: teor <teor@riseup.net> * Update comment to reflect implemented behaviour when retrying block downloads Co-authored-by: teor <teor@riseup.net> * Update `TODO` to remove closed issue and clarify when we might want to fix Co-authored-by: teor <teor@riseup.net> * Update `TODO` to remove closed issue and clarify what we might want to change in future Co-authored-by: teor <teor@riseup.net> * Clarify benefits of how we do block verification Co-authored-by: teor <teor@riseup.net> * Fix rustfmt errors --------- Co-authored-by: teor <teor@riseup.net>

teor2345 added A-consensus Area: Consensus rule updates NU Sprout Network Upgrade: Sprout specific tasks (before Overwinter) A-rust Area: Updates to Rust code C-enhancement Category: This is an improvement P-Medium labels Jul 20, 2021

teor2345 requested a review from jvff July 20, 2021 04:51

teor2345 self-assigned this Jul 20, 2021