This was motivated by realisation that torsocks wrapping of the client side fails (in fact, segfaults) as soon as the client starts the http server for receiving notifications (via BitcoinCoreInterface.add_tx_notify) on localhost. This is a bug in torsocks (this should be analyzed and reported), but in any case there are other reasons for switching to a polling approach to receive updates on transactions:
Better twisted compatibility: no need to start separate monitor threads (requiring reactor.callFromThread and violating twisted's basic design approach). Avoiding spawning any threads is a big win. For future research, there might be a "reactive" rather than polling approach that could work with twisted here.
Reduction in size and complexity of the blockchaininterface.py module (although some tx watching loops are added with a bunch of new rpc calls, a lot of code for the monitoring server can be removed).
The final point is that because CoinSwap is not a very fast protocol, an "every few seconds" polling loop is absolutely no problem performance wise. It is a little awkward to keep track of spending out transactions though; but that complexity already existed. Here it is addressed by monitoring utxos dropping out of the listunspent return value, and then scanning with listtransactions and getrawtransaction to find where the utxo was used as input (is there a better way via RPC to do this?).
The return value of listtransactions is reversed to focus on the most recent transactions, to make sure that even users with very large transaction histories will have no trouble finding the relevant spend.
Note that #25 is still not yet addressed, specifically malleation of TX2/TX3 must still trigger the relevant code branch if malleated forms are broadcast.
Leaving notes here for future reference:
This was motivated by realisation that
torsockswrapping of the client side fails (in fact, segfaults) as soon as the client starts the http server for receiving notifications (viaBitcoinCoreInterface.add_tx_notify) on localhost. This is a bug in torsocks (this should be analyzed and reported), but in any case there are other reasons for switching to a polling approach to receive updates on transactions:reactor.callFromThreadand violating twisted's basic design approach). Avoiding spawning any threads is a big win. For future research, there might be a "reactive" rather than polling approach that could work with twisted here.blockchaininterface.pymodule (although some tx watching loops are added with a bunch of new rpc calls, a lot of code for the monitoring server can be removed).The final point is that because CoinSwap is not a very fast protocol, an "every few seconds" polling loop is absolutely no problem performance wise. It is a little awkward to keep track of spending out transactions though; but that complexity already existed. Here it is addressed by monitoring utxos dropping out of the
listunspentreturn value, and then scanning withlisttransactionsandgetrawtransactionto find where the utxo was used as input (is there a better way via RPC to do this?).The return value of
listtransactionsis reversed to focus on the most recent transactions, to make sure that even users with very large transaction histories will have no trouble finding the relevant spend.Note that #25 is still not yet addressed, specifically malleation of TX2/TX3 must still trigger the relevant code branch if malleated forms are broadcast.