2017-01-23 16:13:29 +01:00
#!/usr/bin/env python3
# Copyright (c) 2017 The Bitcoin Core developers
# Distributed under the MIT software license, see the accompanying
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
2020-03-09 21:15:56 +01:00
""" Test the listsinceblock RPC. """
2017-01-23 16:13:29 +01:00
2021-05-31 11:26:16 +02:00
from test_framework . blocktools import COINBASE_MATURITY
2017-01-23 16:13:29 +01:00
from test_framework . test_framework import BitcoinTestFramework
2019-11-05 09:55:38 +01:00
from test_framework . messages import BIP125_SEQUENCE_NUMBER
2019-09-18 20:41:14 +02:00
from test_framework . util import (
assert_array_result ,
assert_equal ,
assert_raises_rpc_error ,
)
2017-01-23 16:13:29 +01:00
2019-11-05 09:55:38 +01:00
from decimal import Decimal
2019-09-18 20:41:14 +02:00
class ListSinceBlockTest ( BitcoinTestFramework ) :
2017-09-01 18:47:13 +02:00
def set_test_params ( self ) :
2017-01-23 16:13:29 +01:00
self . num_nodes = 4
2017-09-01 18:47:13 +02:00
self . setup_clean_chain = True
2017-01-23 16:13:29 +01:00
2018-09-13 12:33:15 +02:00
def skip_test_if_missing_module ( self ) :
self . skip_if_no_wallet ( )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
def run_test ( self ) :
2019-09-18 20:41:14 +02:00
# All nodes are in IBD from genesis, so they'll need the miner (node2) to be an outbound connection, or have
# only one connection. (See fPreferredDownload in net_processing)
2022-09-24 14:36:35 +02:00
self . connect_nodes ( 1 , 2 )
2021-05-31 11:26:16 +02:00
self . nodes [ 2 ] . generate ( COINBASE_MATURITY + 1 )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
self . sync_all ( )
2017-11-01 14:12:50 +01:00
self . test_no_blockhash ( )
self . test_invalid_blockhash ( )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
self . test_reorg ( )
self . test_double_spend ( )
self . test_double_send ( )
2019-11-05 09:55:38 +01:00
self . double_spends_filtered ( )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
2017-11-01 14:12:50 +01:00
def test_no_blockhash ( self ) :
2020-03-09 21:15:56 +01:00
self . log . info ( " Test no blockhash " )
2017-11-01 14:12:50 +01:00
txid = self . nodes [ 2 ] . sendtoaddress ( self . nodes [ 0 ] . getnewaddress ( ) , 1 )
blockhash , = self . nodes [ 2 ] . generate ( 1 )
2019-11-12 20:43:26 +01:00
blockheight = self . nodes [ 2 ] . getblockheader ( blockhash ) [ ' height ' ]
2017-11-01 14:12:50 +01:00
self . sync_all ( )
txs = self . nodes [ 0 ] . listtransactions ( )
assert_array_result ( txs , { " txid " : txid } , {
" category " : " receive " ,
" amount " : 1 ,
" blockhash " : blockhash ,
2019-11-12 20:43:26 +01:00
" blockheight " : blockheight ,
2017-11-01 14:12:50 +01:00
" confirmations " : 1 ,
} )
assert_equal (
self . nodes [ 0 ] . listsinceblock ( ) ,
{ " lastblock " : blockhash ,
" removed " : [ ] ,
" transactions " : txs } )
assert_equal (
self . nodes [ 0 ] . listsinceblock ( " " ) ,
{ " lastblock " : blockhash ,
" removed " : [ ] ,
" transactions " : txs } )
def test_invalid_blockhash ( self ) :
2020-03-09 21:15:56 +01:00
self . log . info ( " Test invalid blockhash " )
2017-11-01 14:12:50 +01:00
assert_raises_rpc_error ( - 5 , " Block not found " , self . nodes [ 0 ] . listsinceblock ,
" 42759cde25462784395a337460bde75f58e73d3f08bd31fdc3507cbac856a2c4 " )
assert_raises_rpc_error ( - 5 , " Block not found " , self . nodes [ 0 ] . listsinceblock ,
" 0000000000000000000000000000000000000000000000000000000000000000 " )
2018-09-24 20:54:10 +02:00
assert_raises_rpc_error ( - 8 , " blockhash must be of length 64 (not 11, for ' invalid-hex ' ) " , self . nodes [ 0 ] . listsinceblock ,
2017-11-01 14:12:50 +01:00
" invalid-hex " )
2018-09-24 20:54:10 +02:00
assert_raises_rpc_error ( - 8 , " blockhash must be hexadecimal string (not ' Z000000000000000000000000000000000000000000000000000000000000000 ' ) " , self . nodes [ 0 ] . listsinceblock ,
" Z000000000000000000000000000000000000000000000000000000000000000 " )
2017-11-01 14:12:50 +01:00
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
def test_reorg ( self ) :
2017-01-23 16:13:29 +01:00
'''
` listsinceblock ` did not behave correctly when handed a block that was
no longer in the main chain :
ab0
/ \
aa1 [ tx0 ] bb1
| |
aa2 bb2
| |
aa3 bb3
|
bb4
Consider a client that has only seen block ` aa3 ` above . It asks the node
to ` listsinceblock aa3 ` . But at some point prior the main chain switched
to the bb chain .
Previously : listsinceblock would find height = 4 for block aa3 and compare
this to height = 5 for the tip of the chain ( bb4 ) . It would then return
results restricted to bb3 - bb4 .
Now : listsinceblock finds the fork at ab0 and returns results in the
range bb1 - bb4 .
This test only checks that [ tx0 ] is present .
'''
2020-03-09 21:15:56 +01:00
self . log . info ( " Test reorg " )
2017-01-23 16:13:29 +01:00
# Split network into two
self . split_network ( )
# send to nodes[0] from nodes[2]
senttx = self . nodes [ 2 ] . sendtoaddress ( self . nodes [ 0 ] . getnewaddress ( ) , 1 )
# generate on both sides
2020-03-31 01:06:40 +02:00
nodes1_last_blockhash = self . nodes [ 1 ] . generate ( 6 ) [ - 1 ]
nodes2_first_blockhash = self . nodes [ 2 ] . generate ( 7 ) [ 0 ]
self . log . debug ( " nodes[1] last blockhash = {} " . format ( nodes1_last_blockhash ) )
self . log . debug ( " nodes[2] first blockhash = {} " . format ( nodes2_first_blockhash ) )
2017-01-23 16:13:29 +01:00
2020-04-14 12:00:16 +02:00
self . sync_all ( self . nodes [ : 2 ] )
self . sync_all ( self . nodes [ 2 : ] )
2017-01-23 16:13:29 +01:00
self . join_network ( )
2020-03-31 01:06:40 +02:00
# listsinceblock(nodes1_last_blockhash) should now include tx as seen from nodes[0]
# and return the block height which listsinceblock now exposes since a5e7795.
transactions = self . nodes [ 0 ] . listsinceblock ( nodes1_last_blockhash ) [ ' transactions ' ]
found = next ( tx for tx in transactions if tx [ ' txid ' ] == senttx )
assert_equal ( found [ ' blockheight ' ] , self . nodes [ 0 ] . getblockheader ( nodes2_first_blockhash ) [ ' height ' ] )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
def test_double_spend ( self ) :
'''
This tests the case where the same UTXO is spent twice on two separate
blocks as part of a reorg .
ab0
/ \
aa1 [ tx1 ] bb1 [ tx2 ]
| |
aa2 bb2
| |
aa3 bb3
|
bb4
Problematic case :
1. User 1 receives BTC in tx1 from utxo1 in block aa1 .
2. User 2 receives BTC in tx2 from utxo1 ( same ) in block bb1
3. User 1 sees 2 confirmations at block aa3 .
4. Reorg into bb chain .
5. User 1 asks ` listsinceblock aa3 ` and does not see that tx1 is now
invalidated .
Currently the solution to this is to detect that a reorg ' d block is
asked for in listsinceblock , and to iterate back over existing blocks up
until the fork point , and to include all transactions that relate to the
node wallet .
'''
2020-03-09 21:15:56 +01:00
self . log . info ( " Test double spend " )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
self . sync_all ( )
# Split network into two
self . split_network ( )
# share utxo between nodes[1] and nodes[2]
utxos = self . nodes [ 2 ] . listunspent ( )
utxo = utxos [ 0 ]
privkey = self . nodes [ 2 ] . dumpprivkey ( utxo [ ' address ' ] )
self . nodes [ 1 ] . importprivkey ( privkey )
# send from nodes[1] using utxo to nodes[0]
change = ' %.8f ' % ( float ( utxo [ ' amount ' ] ) - 1.0003 )
2021-04-12 16:58:49 +02:00
recipient_dict = {
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
self . nodes [ 0 ] . getnewaddress ( ) : 1 ,
self . nodes [ 1 ] . getnewaddress ( ) : change ,
}
2021-04-12 16:58:49 +02:00
utxo_dicts = [ {
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
' txid ' : utxo [ ' txid ' ] ,
' vout ' : utxo [ ' vout ' ] ,
} ]
txid1 = self . nodes [ 1 ] . sendrawtransaction (
2018-02-20 03:29:22 +01:00
self . nodes [ 1 ] . signrawtransactionwithwallet (
2021-04-12 16:58:49 +02:00
self . nodes [ 1 ] . createrawtransaction ( utxo_dicts , recipient_dict ) ) [ ' hex ' ] )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
# send from nodes[2] using utxo to nodes[3]
2021-04-12 16:58:49 +02:00
recipient_dict2 = {
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
self . nodes [ 3 ] . getnewaddress ( ) : 1 ,
self . nodes [ 2 ] . getnewaddress ( ) : change ,
}
self . nodes [ 2 ] . sendrawtransaction (
2018-02-20 03:29:22 +01:00
self . nodes [ 2 ] . signrawtransactionwithwallet (
2021-04-12 16:58:49 +02:00
self . nodes [ 2 ] . createrawtransaction ( utxo_dicts , recipient_dict2 ) ) [ ' hex ' ] )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
# generate on both sides
lastblockhash = self . nodes [ 1 ] . generate ( 3 ) [ 2 ]
self . nodes [ 2 ] . generate ( 4 )
self . join_network ( )
self . sync_all ( )
# gettransaction should work for txid1
assert self . nodes [ 0 ] . gettransaction ( txid1 ) [ ' txid ' ] == txid1 , " gettransaction failed to find txid1 "
# listsinceblock(lastblockhash) should now include txid1, as seen from nodes[0]
lsbres = self . nodes [ 0 ] . listsinceblock ( lastblockhash )
assert any ( tx [ ' txid ' ] == txid1 for tx in lsbres [ ' removed ' ] )
# but it should not include 'removed' if include_removed=false
lsbres2 = self . nodes [ 0 ] . listsinceblock ( blockhash = lastblockhash , include_removed = False )
assert ' removed ' not in lsbres2
def test_double_send ( self ) :
'''
This tests the case where the same transaction is submitted twice on two
separate blocks as part of a reorg . The former will vanish and the
latter will appear as the true transaction ( with confirmations dropping
as a result ) .
ab0
/ \
aa1 [ tx1 ] bb1
| |
aa2 bb2
| |
aa3 bb3 [ tx1 ]
|
bb4
Asserted :
1. tx1 is listed in listsinceblock .
2. It is included in ' removed ' as it was removed , even though it is now
present in a different block .
2018-03-21 16:16:28 +01:00
3. It is listed with a confirmation count of 2 ( bb3 , bb4 ) , not
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
3 ( aa1 , aa2 , aa3 ) .
'''
2020-03-09 21:15:56 +01:00
self . log . info ( " Test double send " )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
self . sync_all ( )
# Split network into two
self . split_network ( )
# create and sign a transaction
utxos = self . nodes [ 2 ] . listunspent ( )
utxo = utxos [ 0 ]
change = ' %.8f ' % ( float ( utxo [ ' amount ' ] ) - 1.0003 )
2021-04-12 16:58:49 +02:00
recipient_dict = {
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
self . nodes [ 0 ] . getnewaddress ( ) : 1 ,
self . nodes [ 2 ] . getnewaddress ( ) : change ,
}
2021-04-12 16:58:49 +02:00
utxo_dicts = [ {
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
' txid ' : utxo [ ' txid ' ] ,
' vout ' : utxo [ ' vout ' ] ,
} ]
2018-02-20 03:29:22 +01:00
signedtxres = self . nodes [ 2 ] . signrawtransactionwithwallet (
2021-04-12 16:58:49 +02:00
self . nodes [ 2 ] . createrawtransaction ( utxo_dicts , recipient_dict ) )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
assert signedtxres [ ' complete ' ]
signedtx = signedtxres [ ' hex ' ]
# send from nodes[1]; this will end up in aa1
txid1 = self . nodes [ 1 ] . sendrawtransaction ( signedtx )
# generate bb1-bb2 on right side
self . nodes [ 2 ] . generate ( 2 )
# send from nodes[2]; this will end up in bb3
txid2 = self . nodes [ 2 ] . sendrawtransaction ( signedtx )
assert_equal ( txid1 , txid2 )
# generate on both sides
lastblockhash = self . nodes [ 1 ] . generate ( 3 ) [ 2 ]
self . nodes [ 2 ] . generate ( 2 )
self . join_network ( )
self . sync_all ( )
# gettransaction should work for txid1
2019-11-12 20:43:26 +01:00
tx1 = self . nodes [ 0 ] . gettransaction ( txid1 )
assert_equal ( tx1 [ ' blockheight ' ] , self . nodes [ 0 ] . getblockheader ( tx1 [ ' blockhash ' ] ) [ ' height ' ] )
Merge #9622: [rpc] listsinceblock should include lost transactions when parameter is a reorg'd block
876e92b Testing: listsinceblock should display all transactions that were affected since the given block, including transactions that were removed due to a reorg. (Karl-Johan Alm)
f999c46 listsinceblock: optionally find and list any transactions that were undone due to reorg when requesting a non-main chain block in a new 'removed' array. (Karl-Johan Alm)
Pull request description:
The following scenario will not notify the caller of the fact `tx0` has been dropped:
1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks `listsinceblock aa3` and does not see that tx0 is now invalidated.
See `listsinceblock.py` commit for related test.
The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the `listsinceblock` output in a new `replaced` array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.
Example output:
```Python
{
'transactions': [],
'replaced': [
{
'walletconflicts': [],
'vout': 1,
'account': '',
'timereceived': 1485234857,
'time': 1485234857,
'amount': '1.00000000',
'bip125-replaceable': 'unknown',
'trusted': False,
'category': 'receive',
'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
'label': '',
'confirmations': -7
}
],
'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}
```
I believe this addresses the comment by @luke-jr in https://github.com/bitcoin/bitcoin/pull/9516#issuecomment-274190081 but I could be wrong..
Tree-SHA512: 607b5dcaeccb9dc0d963d3de138c40490f3e923050b29821e6bd513d26beb587bddc748fbb194503fe618cfe34a6ed65d95e8d9c5764a882b6c5f976520cff35
2017-07-24 12:56:56 +02:00
# listsinceblock(lastblockhash) should now include txid1 in transactions
# as well as in removed
lsbres = self . nodes [ 0 ] . listsinceblock ( lastblockhash )
assert any ( tx [ ' txid ' ] == txid1 for tx in lsbres [ ' transactions ' ] )
assert any ( tx [ ' txid ' ] == txid1 for tx in lsbres [ ' removed ' ] )
# find transaction and ensure confirmations is valid
for tx in lsbres [ ' transactions ' ] :
if tx [ ' txid ' ] == txid1 :
assert_equal ( tx [ ' confirmations ' ] , 2 )
# the same check for the removed array; confirmations should STILL be 2
for tx in lsbres [ ' removed ' ] :
if tx [ ' txid ' ] == txid1 :
assert_equal ( tx [ ' confirmations ' ] , 2 )
2017-01-23 16:13:29 +01:00
2019-11-05 09:55:38 +01:00
def double_spends_filtered ( self ) :
'''
` listsinceblock ` was returning conflicted transactions even if they
occurred before the specified cutoff blockhash
'''
2020-03-09 21:15:56 +01:00
self . log . info ( " Test spends filtered " )
2019-11-05 09:55:38 +01:00
spending_node = self . nodes [ 2 ]
double_spending_node = self . nodes [ 3 ]
dest_address = spending_node . getnewaddress ( )
tx_input = dict (
sequence = BIP125_SEQUENCE_NUMBER , * * next ( u for u in spending_node . listunspent ( ) ) )
rawtx = spending_node . createrawtransaction (
[ tx_input ] , { dest_address : tx_input [ " amount " ] - Decimal ( " 0.00051000 " ) ,
spending_node . getrawchangeaddress ( ) : Decimal ( " 0.00050000 " ) } )
double_rawtx = spending_node . createrawtransaction (
[ tx_input ] , { dest_address : tx_input [ " amount " ] - Decimal ( " 0.00052000 " ) ,
spending_node . getrawchangeaddress ( ) : Decimal ( " 0.00050000 " ) } )
2022-09-24 14:36:35 +02:00
self . isolate_node ( 3 )
2019-11-05 09:55:38 +01:00
signedtx = spending_node . signrawtransactionwithwallet ( rawtx )
orig_tx_id = spending_node . sendrawtransaction ( signedtx [ " hex " ] )
original_tx = spending_node . gettransaction ( orig_tx_id )
double_signedtx = spending_node . signrawtransactionwithwallet ( double_rawtx )
dbl_tx_id = double_spending_node . sendrawtransaction ( double_signedtx [ " hex " ] )
double_tx = double_spending_node . getrawtransaction ( dbl_tx_id , 1 )
lastblockhash = double_spending_node . generate ( 1 ) [ 0 ]
2022-09-24 14:36:35 +02:00
self . reconnect_isolated_node ( 3 , 2 )
2019-11-05 09:55:38 +01:00
self . sync_all ( )
spending_node . invalidateblock ( lastblockhash )
# check that both transactions exist
block_hash = spending_node . listsinceblock (
spending_node . getblockhash ( spending_node . getblockcount ( ) ) )
original_found = False
double_found = False
for tx in block_hash [ ' transactions ' ] :
if tx [ ' txid ' ] == original_tx [ ' txid ' ] :
original_found = True
if tx [ ' txid ' ] == double_tx [ ' txid ' ] :
double_found = True
assert_equal ( original_found , True )
assert_equal ( double_found , True )
lastblockhash = spending_node . generate ( 1 ) [ 0 ]
# check that neither transaction exists
block_hash = spending_node . listsinceblock ( lastblockhash )
original_found = False
double_found = False
for tx in block_hash [ ' transactions ' ] :
if tx [ ' txid ' ] == original_tx [ ' txid ' ] :
original_found = True
if tx [ ' txid ' ] == double_tx [ ' txid ' ] :
double_found = True
assert_equal ( original_found , False )
assert_equal ( double_found , False )
2017-01-23 16:13:29 +01:00
if __name__ == ' __main__ ' :
ListSinceBlockTest ( ) . main ( )