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

BU doesn't sync transactions #2059

Open
zander opened this issue Jan 8, 2020 · 2 comments
Open

BU doesn't sync transactions #2059

zander opened this issue Jan 8, 2020 · 2 comments

Comments

@zander
Copy link
Contributor

zander commented Jan 8, 2020

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.

@gandrewstone
Copy link
Collaborator

gandrewstone commented Jan 8, 2020

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?

@zander
Copy link
Contributor Author

zander commented Jan 8, 2020

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.

ptschip pushed a commit to ptschip/BitcoinUnlimited that referenced this issue Jun 7, 2020
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
ptschip pushed a commit to ptschip/BitcoinUnlimited that referenced this issue Jun 17, 2020
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
ptschip pushed a commit to ptschip/BitcoinUnlimited that referenced this issue Jun 18, 2020
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
sickpig pushed a commit that referenced this issue Aug 17, 2020
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants