Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix and improve txn_doublespend.py test #5881

Merged
merged 3 commits into from Jul 2, 2015

Conversation

dgenr8
Copy link
Contributor

@dgenr8 dgenr8 commented Mar 12, 2015

The first commit illustrates a problem with the current txn_doublespend.py test. The test relies on unsupportable behavior in the wallet's SyncMetaData method. The test is made to produce inconsistent results by making a small change to specific test "amount" parameters.

The second commit introduces a primitive method CTransaction::IsEquivalentTo and uses it in the wallet to ensure that SyncMetaData is only called for malleability clones, not general conflict (doublespend) transactions. This makes the output of the illustrative version of txn_doublespend.py consistent and predictable.

The third commit is a revised txn_doublespend.py test that does not rely on broken SyncMetaData. Instead, it expects the fixed version of SyncMetaData. It also removes a dependency on the soon-to-be-deprecated accounting "move" method.

@jonasschnelli
Copy link
Contributor

jonasschnelli commented Mar 12, 2015

utACK.
Travis fails test_bitcoin: chainparams.cpp:286: const CChainParams& Params(): Assertion 'pCurrentParams' failed..
You probably need to rebase because there was a travis error after a certain commit on master.

@gavinandresen
Copy link
Contributor

gavinandresen commented Mar 18, 2015

I don't like the new unit test-- you are testing the new "" account gets debited on a non-malleated doublespend.

But our wallet code will never produce a non-malleated double-spend (at least not without the user jumping through some hoops to copy the wallet to two machines, etc etc etc).

I'd be happier if the new unit test tested the new code, and created a malleated version of the spend-to-foo and made sure The Right Thing happened.

I'm also uncertain about changing the SyncMetaData behavior to only work for malleated transactions, but I think I can live with that (mostly because what you get depends on the order your node sees transactions, accounts are being deprecated, and non-malleated double-spends of a "spendfrom" should never happen unless you jump through hoops).

@dgenr8 dgenr8 force-pushed the better_doublespend_test branch 2 times, most recently from e433686 to d92e611 Compare Mar 24, 2015
@dgenr8
Copy link
Contributor Author

dgenr8 commented Mar 24, 2015

Per @gavinandresen review:

  • Improved implementation of IsEquivalentTo
  • Added txn_clone.py, which tests malleability clone accounting
  • Updated rpc-tests.sh to call the new test with and without the --mineblock option

The new test relies on setting nlocktime via createrawtransaction. There is also a stand-alone #5936 for this change.

dgenr8 added 2 commits Apr 12, 2015
Define CTransaction::IsEquivalentTo(const CTransaction& tx)

True if only scriptSigs are different.  In other words, true if
the two transactions are malleability clones.  In other words,
true if the two transactions have the same effect on the
outside universe.

In the wallet, only SyncMetaData for equivalent transactions.
Remove reliance on accounting "move" ledger entries.  Instead,
create funding transactions (and deal with fee complexities).

Do not rely on broken SyncMetaData.  Instead expect double-spend
amount to be debited from the default "" account.
@dgenr8 dgenr8 force-pushed the better_doublespend_test branch from d92e611 to 62be2e2 Compare Apr 12, 2015
@dgenr8
Copy link
Contributor Author

dgenr8 commented Apr 12, 2015

  • Problem illustration squashed, archived here.
  • txn_clone.py updated to use rpc generate(...)

@laanwj
Copy link
Member

laanwj commented Apr 15, 2015

ACK on new test, for discussion with regard to adding a field to createrawtransaction RPC see #5936

@laanwj laanwj added the Tests label Apr 15, 2015
@dgenr8 dgenr8 force-pushed the better_doublespend_test branch from 62be2e2 to 8b224dd Compare May 12, 2015
@dgenr8
Copy link
Contributor Author

dgenr8 commented May 12, 2015

Removed the change to createrawtransaction.

Does what the old txnmall.sh test did.

Creates an equivalent malleated clone and tests that SyncMetaData
syncs the accounting effects from the original transaction to the
confirmed clone.
@dgenr8 dgenr8 force-pushed the better_doublespend_test branch from 8b224dd to 5d34e16 Compare May 12, 2015
@laanwj laanwj merged commit 5d34e16 into bitcoin:master Jul 2, 2015
laanwj added a commit that referenced this pull request Jul 2, 2015
5d34e16 Add txn_clone.py test (Tom Harding)
defd2d5 Better txn_doublespend.py test (Tom Harding)
b2b3619 Implement CTransaction::IsEquivalentTo(...) (Tom Harding)
laanwj added a commit that referenced this pull request Jul 2, 2015
Solve merge conflict of test added in #5881 with #6097.
laanwj added a commit to laanwj/bitcoin that referenced this pull request Jul 2, 2015
CTransAction::IsEquivalentTo was introduced in bitcoin#5881.
This functionality is only useful to the wallet, and should never have
been added to the primitive transaction type.
jonasschnelli pushed a commit to jonasschnelli/bitcoin that referenced this pull request Jul 8, 2015
CTransAction::IsEquivalentTo was introduced in bitcoin#5881.
This functionality is only useful to the wallet, and should never have
been added to the primitive transaction type.
zkbot added a commit to zcash/zcash that referenced this pull request Feb 15, 2017
zkbot added a commit to zcash/zcash that referenced this pull request Feb 20, 2017
@dgenr8 dgenr8 deleted the better_doublespend_test branch Sep 19, 2018
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants