Triggering needs two consecutive scripthash status changes
in very quick succession. Client gets notification from server,
but then response to "blockchain.scripthash.get_history" will already contain
the changed-again history that has a different status.
20190627T101547.902638Z | INFO | synchronizer.[default_wallet] | receiving history mwXtx49BCGAiy4tU1r7MBX5VVLWSdtasCL 1
20190627T101547.903262Z | INFO | synchronizer.[default_wallet] | error: status mismatch: mwXtx49BCGAiy4tU1r7MBX5VVLWSdtasCL
User has wallet file with history that includes some txid; corresponding
raw tx is not in the "transactions" dict in the file however.
When the synchronizer starts up, it requests this "missing" txn from
the server... but what if the server does not know about it?
Maybe it was reorged and is not in the new best chain,
and not even in mempool. This was not handled previously.
fix#5122
The synchronizer would sometimes not send 'wallet_updated' triggers
if it was fast enough to do all the work between two 0.1 sec ticks.
(is_up_to_date() would return True both before and after)
related: 41e088693d
If our guess of a txn getting confirmed at the same height in the new chain
as it was at in the old chain is incorrect, there is a race between the
verifier and the synchronizer. If the verifier wins, the exception will cause
us to disconnect.
Not sure if it is still useful but in its current form it was giving false positives all the time.
Specifically, the expected sorting is: confirmed txns in blockchain order + mempool txns in arbitrary order.
The "sorted" invocation puts mempool txns at the beginning, so the warning is always triggered if there is any unconfirmed history.
there was some kind of re-org but our reorged transactions did not get into the server's mempool for some reason (and they were not mined either). the synchronizer detected the change in address status and asked for the new address histories but in `on_address_history` it thought it did not ask for the histories.
from log:
[Synchronizer] receiving history (unsolicited) 2N6DydVfmheVM9F94G46pcUi5piyffgNBQ9 0
[Synchronizer] receiving history (unsolicited) 2Mw6LDQUzmmxCX3wouDXo2Pj4wbonJATays 0
[SPV] received an error: {'jsonrpc': '2.0', 'error': {'code': 1, 'message': 'tx hash f7c89eec3454b627dcb8cfc822202a0d1f8b38f2a53db182b607a2f61e6946d1 not in block 000000007ac4e95633a16232bea35bc17edf855e3964dff0ebb108b5887647ff at height 1,325,443'}, 'id': 120, 'method': 'blockchain.transaction.get_merkle', 'params': ['f7c89eec3454b627dcb8cfc822202a0d1f8b38f2a53db182b607a2f61e6946d1', 1325443]}
* Rename synchronous_get to synchronous_send
This makes it more inline with the method 'send' of which
synchronous_send is the, well, synchronous version.
* Move protocol strings from scripts to network
This is again a small step in the right direction. The network module is
going to accumulate more and more of these simple methods. Once
everything is moved into that module, that module is going to be split.
Note that I've left the scripts which use scripts/util.py alone. I
suspect the same functionality can be reached when using just
lib/network.py and that scripts/util.py is obsolete.
* Remove protocol string from verifier and websocket
Websocket still has some references, that'll take more work to remove. Once the
network module has been split this should be easy.
I took the liberty to rename a variable to better show what it is.
* Remove protocol strings from remainder
The naming scheme I'm following for the newly introduced methods in the network
module is: 'blockchain.<subject>.<action>' -> def <action>_(for|to)_<subject>
* Move explicit protocol calls closer to each other
This makes it easier to keep track of the methods which are due to be
extracted.
* Remove `send` when using `get_transaction`
This is the final step to formalize (the informal) interface of the network
module.
A chance of note is changed interface for async/sync calls. It is no longer
required to use the `synchronous_send` call. Merely NOT passing a callback
makes the call synchronous. I feel this makes the API more intuitive to work
with and easier to replace with a different network module.
* Remove send from get_merkle_for_transaction
The pattern which emerged for calling the lambda yielded an slight refactor.
I'm not happy with the name for the `__invoke` method.
* Remove explict send from websockets
* Remove explicit send from scripts
* Remove explicit send from wallet
* Remove explicit sync_send from commands, scripts
* Remove optional timeout parameter
This parameter doesn't seem to be used a lot and removing it makes the
remaining calls easier. Potentionally a contentious choice!
* Rename `broadcast` to `broadcast_transaction`
Doing so makes the method name consistent with the other ElectrumX protocol
method names.
* Remove synchronous_send
Now every method is intuitive in what it does, no special handling required.
The `broadcast_transaction` method is weird. I've opted not to change the
return type b/c I found it hard to know what the exact consequences are. But
ideally this method should just works as all the other ElectrumX related
messages. On the other hand this shows nicely how you _can_ do something
differnt quite easy.
* Rename the awkwardly name `__invoke` method
The new name reflects what it does.
* Process the result of linter feedback
I've used flake8-diff (and ignored a couple of line length warnings).
* Rename tx_response to on_tx_response
This fell through the cracks when this branch was rebased.
* subscript_to_scripthash should be get_balance
An oversight while refactoring.
* Add missing return statement
Without this statement the transaction would have been broadcasted twice.
* Pass list of tuples to send not single tuple
* Add @staticmethod decorator
* Fix argument to be an array
wallet.synchronizer gets assigned a newly constructed Synchronizer instance.
Synchronizer in tx_response refers to the value of wallet.synchronizer.
If the wallet has a missing txn, there could be a race condition that synchronizer asks for a txn and we get the callback from the network WHILE the constructor is still running, in which case wallet.synchronizer would still be None and we would consider the callback "orphan", and the wallet would get "stuck" synchronizing.
SomberNight
ThomasV
Janus
Harm Aarts
Justin Turner Arthur