-
Notifications
You must be signed in to change notification settings - Fork 212
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
BU doesn't sync transactions #2059
Comments
Certainly tx are synced all the time in our extensive regtest QA suite in the /qa directory. I'm going to make a stab in the dark here: the nodes are in IBD (initial block download) mode. If you restore a blockchain from a saved state, that blockchain's blocks are often older than the arbitrary cutoff where the code assumes that some blocks must have been generated during that interval. So it drops into IBD mode. For efficiency, transactions are not accepted during IBD. The solution is to generate a single block at the top of your test. This will advance the blockchain time to "now", kicking nodes out of IBD. If that's not the problem, can you share your test? |
Yes, that seems to work around the issue. May I suggest redefining the rule on when to not accept transactions based on the distance between validated tip and header-chain tip? (i.e. when your headers are 100 blocks ahead, don't do tx gets). This would solve the issue and would also correct ignore transactions while doing a larger catch-up after a node has not run for some time. |
This takes the DoubleSpendProof functionality written by Tom Zander elsewhere and imports it into Bitcoin Unlimited, granting BU the ability to create, validate, store and propagate DSPs. Testing strategy; use a known regtest chain; https://gitlab.com/FloweeTheHub/thehub/blob/2b68d149/testing/api/blk00000.dat $ mkdir node1 node2 copy the blk file into the `node1/regtest/blocks/` dir and make sure that the node using that dir will start with 'reindex'. $ bitcoin-qt -regtest -datadir=node1 -connect=localhost -printtoconsole=true \ -consensus.enableCanonicalTxOrder=0 -listen=false -server=false -reindex \ -debug=dsproof And for node2 you'd use either of these two; $ bitcoin-qt -regtest -datadir=node2 -printtoconsole=true -debug=dsproof \ -listen=true -consensus.enableCanonicalTxOrder=0 -server=false $ hub-qt -datadir=node2 -regtest -reindex -listen=true -server=false Then when both are at block height 115, using the debugging console, insert one transaction in each node software. Note; in BU you need to call 'generate' once as long as issue BitcoinUnlimited#2059 is unresolved. Order is relevant, you want to repeat the process in reverse order to make sure each is tested to be the one generating and propagating or the one downloading and validating. Use `sendrawtransaction` 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100b34a120e69bc933ae16c10db0f565cb2da1b80a9695a51707e8a80c9aa5c22bf02206c390cb328763ab9ab2d45f874d308af2837d6d8cfc618af76744b9eeb69c3934121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01faa7be00000000001976a9148438266ad57aa9d9160e99a046e39027e4fb6b2a88ac00000000 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100d9d22406611228d64e6b674de8b16e802f8f789f8338130506c7741cdae9116602202dc63a4f5f9e750eec9dfc1557469bda43d3491b358484e5c25992a381048a494121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01ea80be00000000001976a914a449b2bf8b8092a810ee3b4ba102037bf4b96d2288ac00000000
This takes the DoubleSpendProof functionality written by Tom Zander elsewhere and imports it into Bitcoin Unlimited, granting BU the ability to create, validate, store and propagate DSPs. Testing strategy; use a known regtest chain; https://gitlab.com/FloweeTheHub/thehub/blob/2b68d149/testing/api/blk00000.dat $ mkdir node1 node2 copy the blk file into the `node1/regtest/blocks/` dir and make sure that the node using that dir will start with 'reindex'. $ bitcoin-qt -regtest -datadir=node1 -connect=localhost -printtoconsole=true \ -consensus.enableCanonicalTxOrder=0 -listen=false -server=false -reindex \ -debug=dsproof And for node2 you'd use either of these two; $ bitcoin-qt -regtest -datadir=node2 -printtoconsole=true -debug=dsproof \ -listen=true -consensus.enableCanonicalTxOrder=0 -server=false $ hub-qt -datadir=node2 -regtest -reindex -listen=true -server=false Then when both are at block height 115, using the debugging console, insert one transaction in each node software. Note; in BU you need to call 'generate' once as long as issue BitcoinUnlimited#2059 is unresolved. Order is relevant, you want to repeat the process in reverse order to make sure each is tested to be the one generating and propagating or the one downloading and validating. Use `sendrawtransaction` 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100b34a120e69bc933ae16c10db0f565cb2da1b80a9695a51707e8a80c9aa5c22bf02206c390cb328763ab9ab2d45f874d308af2837d6d8cfc618af76744b9eeb69c3934121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01faa7be00000000001976a9148438266ad57aa9d9160e99a046e39027e4fb6b2a88ac00000000 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100d9d22406611228d64e6b674de8b16e802f8f789f8338130506c7741cdae9116602202dc63a4f5f9e750eec9dfc1557469bda43d3491b358484e5c25992a381048a494121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01ea80be00000000001976a914a449b2bf8b8092a810ee3b4ba102037bf4b96d2288ac00000000
This takes the DoubleSpendProof functionality written by Tom Zander elsewhere and imports it into Bitcoin Unlimited, granting BU the ability to create, validate, store and propagate DSPs. Testing strategy; use a known regtest chain; https://gitlab.com/FloweeTheHub/thehub/blob/2b68d149/testing/api/blk00000.dat $ mkdir node1 node2 copy the blk file into the `node1/regtest/blocks/` dir and make sure that the node using that dir will start with 'reindex'. $ bitcoin-qt -regtest -datadir=node1 -connect=localhost -printtoconsole=true \ -consensus.enableCanonicalTxOrder=0 -listen=false -server=false -reindex \ -debug=dsproof And for node2 you'd use either of these two; $ bitcoin-qt -regtest -datadir=node2 -printtoconsole=true -debug=dsproof \ -listen=true -consensus.enableCanonicalTxOrder=0 -server=false $ hub-qt -datadir=node2 -regtest -reindex -listen=true -server=false Then when both are at block height 115, using the debugging console, insert one transaction in each node software. Note; in BU you need to call 'generate' once as long as issue BitcoinUnlimited#2059 is unresolved. Order is relevant, you want to repeat the process in reverse order to make sure each is tested to be the one generating and propagating or the one downloading and validating. Use `sendrawtransaction` 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100b34a120e69bc933ae16c10db0f565cb2da1b80a9695a51707e8a80c9aa5c22bf02206c390cb328763ab9ab2d45f874d308af2837d6d8cfc618af76744b9eeb69c3934121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01faa7be00000000001976a9148438266ad57aa9d9160e99a046e39027e4fb6b2a88ac00000000 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100d9d22406611228d64e6b674de8b16e802f8f789f8338130506c7741cdae9116602202dc63a4f5f9e750eec9dfc1557469bda43d3491b358484e5c25992a381048a494121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01ea80be00000000001976a914a449b2bf8b8092a810ee3b4ba102037bf4b96d2288ac00000000
This takes the DoubleSpendProof functionality written by Tom Zander elsewhere and imports it into Bitcoin Unlimited, granting BU the ability to create, validate, store and propagate DSPs. Testing strategy; use a known regtest chain; https://gitlab.com/FloweeTheHub/thehub/blob/2b68d149/testing/api/blk00000.dat $ mkdir node1 node2 copy the blk file into the `node1/regtest/blocks/` dir and make sure that the node using that dir will start with 'reindex'. $ bitcoin-qt -regtest -datadir=node1 -connect=localhost -printtoconsole=true \ -consensus.enableCanonicalTxOrder=0 -listen=false -server=false -reindex \ -debug=dsproof And for node2 you'd use either of these two; $ bitcoin-qt -regtest -datadir=node2 -printtoconsole=true -debug=dsproof \ -listen=true -consensus.enableCanonicalTxOrder=0 -server=false $ hub-qt -datadir=node2 -regtest -reindex -listen=true -server=false Then when both are at block height 115, using the debugging console, insert one transaction in each node software. Note; in BU you need to call 'generate' once as long as issue #2059 is unresolved. Order is relevant, you want to repeat the process in reverse order to make sure each is tested to be the one generating and propagating or the one downloading and validating. Use `sendrawtransaction` 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100b34a120e69bc933ae16c10db0f565cb2da1b80a9695a51707e8a80c9aa5c22bf02206c390cb328763ab9ab2d45f874d308af2837d6d8cfc618af76744b9eeb69c3934121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01faa7be00000000001976a9148438266ad57aa9d9160e99a046e39027e4fb6b2a88ac00000000 01000000010b9d14b709aa59bd594edca17db2951c6660ebc8daa31ceae233a5550314f158000000006b483045022100d9d22406611228d64e6b674de8b16e802f8f789f8338130506c7741cdae9116602202dc63a4f5f9e750eec9dfc1557469bda43d3491b358484e5c25992a381048a494121022708a547a1d14ba6df79ec0f4216eeec65808cf0a32f09ad1cf730b44e8e14a6ffffffff01ea80be00000000001976a914a449b2bf8b8092a810ee3b4ba102037bf4b96d2288ac00000000
Following the testing schema to test double spend proofs I found a rather basic feature missing in BU that is needed.
I start 2 BUs in regtest mode. Both have the same chain. I use 'sendrawtransaction' in one client and notice that the debug window shows that there is now 1 transaction in the mempool.
The other BU that is connected keeps its mempool count at zero.
The last line in the logs is:
2020-01-08 12:37:43 got inv: tx 480710661d0e35f614fab63ec48c277552c3f09294f8874545e589311fc0a4d0 have: 0 peer=localhost (2)
This is with the dev branch (21aaee4).
The testing strategy is described here; https://gitlab.com/snippets/1928055
you can reproduce the issue with that.
The text was updated successfully, but these errors were encountered: