@ -44,7 +44,7 @@ For the time constraints, consider these points:
* This is *somewhat* experimental; better run it on signet for now, mainnet is not advised.
* If you do run it on mainnet, make an effort to keep backups of your jmdat wallet file; recovery with seed only is possible (a tool is provided), but it's a pain.
* This basically allows coinjoins to be proposed and executed without any interaction by the participants, even over a message channel. You can run it passsively in a yield generator, for example. You can even be paid some small amount of sats for that to happen. But the coinjoins are only 2-party.
* This basically allows coinjoins to be proposed and executed without any interaction by the participants, even over a message channel. You can run it passively in a yield generator, for example. You can even be paid some small amount of sats for that to happen. But the coinjoins are only 2-party.
@ -43,7 +43,7 @@ These are mostly minor bugfixes / smoothing out, but of note is that there is no
### Syncing improvements
As part of an ongoing project to make syncing Joinmarket wallets less cumbersome (there are too many edge cases where long waits or repeated syncing is necessary), these small changes prevent the most common annnoyance, that of being required to run sync twice instead of once after restarting, when transactions have occurred. Users are reminded that the `--fast` option was created to make it much faster to sync a wallet which is fairly heavily used, and that it can be used for all scripts (sendpayment, tumbler, yg); but please note it is also MORE reliable than the detailed (slower) sync, if you have not moved your wallet between Core instances. The latter (non --fast) should only be needed occasionally. More will hopefully be done to improve wallet sync in future, see [359](https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/359). Additionally, we switched to using `importmulti` instead of importing addresses individually, which is faster. Also, the user is now prompted to use the new `rescanblockchain` CLI command in Bitcoin, to which you can provide block height arguments, to help speed up those cases where a rescan is actually needed.
As part of an ongoing project to make syncing Joinmarket wallets less cumbersome (there are too many edge cases where long waits or repeated syncing is necessary), these small changes prevent the most common annoyance, that of being required to run sync twice instead of once after restarting, when transactions have occurred. Users are reminded that the `--fast` option was created to make it much faster to sync a wallet which is fairly heavily used, and that it can be used for all scripts (sendpayment, tumbler, yg); but please note it is also MORE reliable than the detailed (slower) sync, if you have not moved your wallet between Core instances. The latter (non --fast) should only be needed occasionally. More will hopefully be done to improve wallet sync in future, see [359](https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/359). Additionally, we switched to using `importmulti` instead of importing addresses individually, which is faster. Also, the user is now prompted to use the new `rescanblockchain` CLI command in Bitcoin, to which you can provide block height arguments, to help speed up those cases where a rescan is actually needed.
`4b4f8c9` Fix bug in detailed wallet sync relating to gap addrs.
`6c15bd7` Make address imports with address requests in wallet Prior to this commit, there was duplicated code in maker and taker modules to import addresses, now all calls to the wallet for fresh addresses can optionally pass a blockchaininterface instance and if this is done, the new address will be imported to the BCI at the same time.