This code is currently on the zsweep branch, checkout that branch to do testing.
zsweep has various config file options, but the most basic usage just requires two:
zsweep=1
zsweepaddress=zs1...
By default a node will only sweep to a zaddr in the current wallet.dat. To sweep funds out of the current wallet set zsweepexternal=1 :
zsweep=1
zsweepaddress=zs1...
zsweepexternal=1
By default zsweep runs every 5 blocks. To change it:
zsweepinterval=10
By default zsweep makes sure to not reduce the anonset in any tx by having a maximum number of inputs of 8. This should be fine for new wallets, but if you have an existing wallet with many zutxos it can be changed like this:
zsweepmaxinputs=50
Large values will make sweeping faster at the expense of reducing the anonset.
The default zsweep fee is 10000 puposhis or 0.0001 HUSH, the default for all transactions. To use fee=0 for zsweep transactions:
zsweepfee=0
Things To Test
Not setting zsweepaddress gives an error and stops node
Setting an invalid zsweepaddress gives an error and stops node
Setting a zsweepaddress which is not in the current wallet gives an error and stops node
Setting zsweep=1 and zsweepaddress=zaddr works correctly
Setting a zsweepaddress outside wallet and zsweepexternal=1 works correctly
Setting zsweepinterval works correctly
Setting an invalid zsweepinterval (0 or negative) gives gives warning and uses default
Setting zsweepmaxinputs works correctly
Setting an invalid zsweepmaxinputs (0, 1 or negative) gives error and stops node
Setting zsweepfee=0 works correctly
Make sure consolidation=1 and zsweep=1 works correctly together
This code is currently on the `zsweep` branch, checkout that branch to do testing.
zsweep has various config file options, but the most basic usage just requires two:
```
zsweep=1
zsweepaddress=zs1...
```
By default a node will only sweep to a zaddr in the current wallet.dat. To sweep funds out of the current wallet set `zsweepexternal=1` :
```
zsweep=1
zsweepaddress=zs1...
zsweepexternal=1
```
By default `zsweep` runs every 5 blocks. To change it:
```
zsweepinterval=10
```
By default `zsweep` makes sure to not reduce the anonset in any tx by having a maximum number of inputs of 8. This should be fine for new wallets, but if you have an existing wallet with many zutxos it can be changed like this:
```
zsweepmaxinputs=50
```
Large values will make sweeping faster at the expense of reducing the anonset.
The default zsweep fee is 10000 puposhis or 0.0001 HUSH, the default for all transactions. To use fee=0 for zsweep transactions:
```
zsweepfee=0
```
## Things To Test
- [x] Not setting zsweepaddress gives an error and stops node
- [x] Setting an invalid zsweepaddress gives an error and stops node
- [x] Setting a zsweepaddress which is not in the current wallet gives an error and stops node
- [x] Setting zsweep=1 and zsweepaddress=zaddr works correctly
- [x] Setting a zsweepaddress outside wallet and zsweepexternal=1 works correctly
- [x] Setting zsweepinterval works correctly
- [x] Setting an invalid zsweepinterval (0 or negative) gives gives warning and uses default
- [ ] Setting zsweepmaxinputs works correctly
- [ ] Setting an invalid zsweepmaxinputs (0, 1 or negative) gives error and stops node
- [x] Setting zsweepfee=0 works correctly
- [ ] Make sure consolidation=1 and zsweep=1 works correctly together
I am still waiting for test node to finish syncing, but first 4 tests all passed for me as far as either the node giving meaningful error and stopping or starting correctly when zsweep=1 and zsweepaddress=zaddr in wallet. I'll test actual functionality when finished syncing.
I am still waiting for test node to finish syncing, but first 4 tests all passed for me as far as either the node giving meaningful error and stopping or starting correctly when zsweep=1 and zsweepaddress=zaddr in wallet. I'll test actual functionality when finished syncing.
Setting an invalid zsweepinterval (0 or negative) gives error and stops node
I tested with 0 and negative. It gives this message and continues running node with default of 5. I think this is appropriate way to handle if everything else is valid unless we should stop node on error for anything invalid. main_impl: Invalid sweep interval of -22, setting to default of 5
Message is also output every 5 blocks.
Checking z_getoperationstatus, I get output like this every 5 blocks. This is when there are no funds to sweep, so no txs created.
Trying to sweep to external, I get this in debug.log.: AppInit2: sweeping funds to a zaddr in an external wallet
Empty result when I check z_getoperationstatus and doesn't appear to work. Funds stay in address of local node. I added consolidation=1 at same time as adding external config and may be related. Need to test without consolidation=1 as it seems it might make zsweep not work at all. I tested switching back to local address and removing zsweepexternal=1 and zsweep was never running with consolidation=1.
`Setting an invalid zsweepinterval (0 or negative) gives error and stops node`
I tested with 0 and negative. It gives this message and continues running node with default of 5. I think this is appropriate way to handle if everything else is valid unless we should stop node on error for anything invalid.
`main_impl: Invalid sweep interval of -22, setting to default of 5`
Message is also output every 5 blocks.
Checking `z_getoperationstatus`, I get output like this every 5 blocks. This is when there are no funds to sweep, so no txs created.
```
{
"id": "opid-b4ebc95c-ea2c-4fbc-a7b1-09a4cbccca83",
"status": "success",
"creation_time": 1661486559,
"result": {
"num_tx_created": 0,
"amount_swept": "0.00",
"sweep_txids": [
]
},
"execution_secs": 0.04932535,
"method": "sweep",
"target_height": 1059364
}
```
Trying to sweep to external, I get this in debug.log.:
`AppInit2: sweeping funds to a zaddr in an external wallet`
Empty result when I check `z_getoperationstatus` and doesn't appear to work. Funds stay in address of local node. I added `consolidation=1` at same time as adding external config and may be related. Need to test without `consolidation=1` as it seems it might make zsweep not work at all. I tested switching back to local address and removing `zsweepexternal=1` and zsweep was never running with `consolidation=1`.
Sweeping funds from one address that's already been swept to, to a new address seems to report incorrect total and double what was swept. Actual amount was 13.9987:
Sweeping funds from one address that's already been swept to, to a new address seems to report incorrect total and double what was swept. Actual amount was 13.9987:
```
{
"id": "opid-902a57d7-0306-4d47-8c1b-d22777298e9f",
"status": "success",
"creation_time": 1661489117,
"result": {
"num_tx_created": 0,
"amount_swept": "27.9974",
"sweep_txids": [
"7b510b90c3f1647c1e31b888bc5eb1566c10dbc82b3d5dfa9229abcfb8bb15ef"
]
},
"execution_secs": 51.690750292,
"method": "sweep",
"target_height": 1059402
},
```
Setting a zsweepaddress outside wallet and zsweepexternal=1 works correctly
Confirmed this works correctly as long as not using consolidation=1. consolidation=1 seems to break zsweep whether using local or external address.
`Setting a zsweepaddress outside wallet and zsweepexternal=1 works correctly`
Confirmed this works correctly as long as not using consolidation=1. consolidation=1 seems to break zsweep whether using local or external address.
I had to reindex test node because it started showing incorrect low balance in sweep address. Tried rescan first, but still low balance after sweeping. I was trying to send tx every 2-3 minutes and setting zsweepinterval high to test zsweepmaxinputs.
Lots of txs might end up requiring frequent reindexing if something gets jacked up to prevent double spending. This isn't too helpful because I don't have exact message but it was saying something about tx not found during node startup for a bunch of txids and I have a bunch of sapling nullifier exists, prevent double spend in log. May have been calling z_sendmany too quickly or when in invalid state. I'll test more once reindexing finishes.
I had to reindex test node because it started showing incorrect low balance in sweep address. Tried rescan first, but still low balance after sweeping. I was trying to send tx every 2-3 minutes and setting zsweepinterval high to test zsweepmaxinputs.
Lots of txs might end up requiring frequent reindexing if something gets jacked up to prevent double spending. This isn't too helpful because I don't have exact message but it was saying something about tx not found during node startup for a bunch of txids and I have a bunch of sapling nullifier exists, prevent double spend in log. May have been calling z_sendmany too quickly or when in invalid state. I'll test more once reindexing finishes.
@fekt giving a warning and setting to a default value is more user-friendly behavior, I agree, so I changed the checklist item and checked that box. Thanks.
@fekt do you like the current behavior of it giving the warning every X blocks that the value was invalid (makes it more likely the user will see it) or should we update the value so it doesn't spam debug.log as much?
As for the amount swept being incorrect and exactly double, I think it's counting how much is swept out of any zaddr plus how much is swept in to the zsweepaddress, which is not that useful. It should either count how much is swept out of addresses or how much is swept into the zsweepaddress.
I have a hunch on why consolidation=1 and zsweep=1 together are not working. I made sweeping run every 5 blocks but there is logic in consolidation that says "if we are less than 15 blocks until the next sweep, don't run consolidation" and since we are always less than 15 blocks until the next sweep, consolidation never actually runs, it bails out early every time.
@fekt giving a warning and setting to a default value is more user-friendly behavior, I agree, so I changed the checklist item and checked that box. Thanks.
@fekt do you like the current behavior of it giving the warning every X blocks that the value was invalid (makes it more likely the user will see it) or should we update the value so it doesn't spam debug.log as much?
As for the amount swept being incorrect and exactly double, I think it's counting how much is swept out of any zaddr plus how much is swept in to the zsweepaddress, which is not that useful. It should either count how much is swept out of addresses or how much is swept into the zsweepaddress.
I have a hunch on why consolidation=1 and zsweep=1 together are not working. I made sweeping run every 5 blocks but there is logic in consolidation that says "if we are less than 15 blocks until the next sweep, don't run consolidation" and since we are always less than 15 blocks until the next sweep, consolidation never actually runs, it bails out early every time.
This is what I was getting on startup when balance incorrect. It seemed to run OK for awhile until balance got too low.
tx hash 791d2998b4584590823cde3dff3d20d95cdb4601643a36d5952437974ef842fb does not exist!
A bunch of them with different hashes as well as tx is unconfirmed likely for all the related txs and why balance shows incorrect. Seems to think they are spent, but uncofirmed and not actually spent. Also, sometimes get a hash or txid of all 0's, but not sure if from zsweep or existing bug being highlighted by sending a bunch of txs on cron. I was sending 2 txs every 2 minutes.
If I rescan, all those messages still show and balance still incorrect until reindexing. Happened again overnight where balance too low to continue sending txs on cron. It still runs zsweep regularly, but with 0 amount.
This is with no longer using consolidation=1. I am also using deletetx=1 and have zindex=1 if it makes any difference.
I am testing on another node that has been fine for over 12 hours so far.
This is what I was getting on startup when balance incorrect. It seemed to run OK for awhile until balance got too low.
`tx hash 791d2998b4584590823cde3dff3d20d95cdb4601643a36d5952437974ef842fb does not exist!`
A bunch of them with different hashes as well as `tx is unconfirmed` likely for all the related txs and why balance shows incorrect. Seems to think they are spent, but uncofirmed and not actually spent. Also, sometimes get a hash or txid of all 0's, but not sure if from zsweep or existing bug being highlighted by sending a bunch of txs on cron. I was sending 2 txs every 2 minutes.
If I rescan, all those messages still show and balance still incorrect until reindexing. Happened again overnight where balance too low to continue sending txs on cron. It still runs zsweep regularly, but with 0 amount.
This is with no longer using consolidation=1. I am also using deletetx=1 and have zindex=1 if it makes any difference.
I am testing on another node that has been fine for over 12 hours so far.
do you like the current behavior of it giving the warning every X blocks that the value was invalid (makes it more likely the user will see it) or should we update the value so it doesn't spam debug.log as much?
I think it is fine to show it every interval so user is more likely to see it and change it. It is trade off with spamming log, but I don't think it's necessary to change it for them since it's using default value anyway.
> do you like the current behavior of it giving the warning every X blocks that the value was invalid (makes it more likely the user will see it) or should we update the value so it doesn't spam debug.log as much?
>
I think it is fine to show it every interval so user is more likely to see it and change it. It is trade off with spamming log, but I don't think it's necessary to change it for them since it's using default value anyway.
@fekt if zsweepexternal=1 is set but the zsweepaddress is in the current wallet.dat, should we give a warning or error? This is something we can automatically detect and tell a user if they think they are sweeping to an external wallet, but they actually are not.
@fekt if `zsweepexternal=1` is set but the `zsweepaddress` is in the current wallet.dat, should we give a warning or error? This is something we can automatically detect and tell a user if they think they are sweeping to an external wallet, but they actually are not.
Since it's advanced feature, I think a warning is fine every interval if it still sweeps to the address specified, regardless if external or not. Funds never leave their wallet. If it makes more sense with existing logic to error on start, that's fine too though.
Since it's advanced feature, I think a warning is fine every interval if it still sweeps to the address specified, regardless if external or not. Funds never leave their wallet. If it makes more sense with existing logic to error on start, that's fine too though.
Not sure if it's just my wallet or VPS it's on, but I tried latest commit over the weekend and kept getting core dumps. I ended up creating new wallet.dat and was still getting core dumps without sending any transactions and just letting it sweep. I'll check logs later when I can, but I do notice multiple sweep operations that get cancelled before one ends up having a success response. This is with no funds that actually need to be swept and all funds already in sweep address. I was also no longer using consolidation=1. When I did try consolidation=1 initially on latest commit, I was seeing consolidation operations happen and no sweeps, but may not have let it run long enough before changing config or too many inputs so it wasn't trying to sweep. I created new wallet.dat because z_sendmany kept failing and balances incorrect even after multiple reindexes and rescans.
On another test node, which I did not update to latest commit and isn't using consolidation=1, I am also running into the same issue where I end up with a decent amount of txs stuck in mempool that never confirm so balances remain low. I have multiple with hashes or txids of all 0's mixed with real txids that are locking funds and keeping balance low. I have not experienced core dumps on this one yet.
Not sure if it's just my wallet or VPS it's on, but I tried latest commit over the weekend and kept getting core dumps. I ended up creating new wallet.dat and was still getting core dumps without sending any transactions and just letting it sweep. I'll check logs later when I can, but I do notice multiple sweep operations that get cancelled before one ends up having a success response. This is with no funds that actually need to be swept and all funds already in sweep address. I was also no longer using consolidation=1. When I did try consolidation=1 initially on latest commit, I was seeing consolidation operations happen and no sweeps, but may not have let it run long enough before changing config or too many inputs so it wasn't trying to sweep. I created new wallet.dat because z_sendmany kept failing and balances incorrect even after multiple reindexes and rescans.
On another test node, which I did not update to latest commit and isn't using consolidation=1, I am also running into the same issue where I end up with a decent amount of txs stuck in mempool that never confirm so balances remain low. I have multiple with hashes or txids of all 0's mixed with real txids that are locking funds and keeping balance low. I have not experienced core dumps on this one yet.
Getting core dumps on two nodes now. One of them is basically a new wallet with new addresses and only 100 kb. This is a VPS with 4 GB of RAM and 2 CPU on latest commit. Not sure if helpful but these are last entries in log:
Last entries in other node, which has 100 MB wallet.dat and physical machine with 8 GB of RAM and 6-core CPU. This is not on latest commit:
2022-08-29 23:08:20 Build: Creating Sapling SpendDescriptions
2022-08-29 23:08:22 ShuffleOutputs: Shuffling 9 zouts
2022-08-29 23:08:23 Build: Created spendAuth and binding sigs
2022-08-29 23:08:23 sendrawtransaction: Submitting to mempool
2022-08-29 23:08:23 sendrawtransaction: Relaying raw tx to mempool
I am reindexing VPS again. Physical, I changed to send 1 tx every 3 minutes in case it was crashing from high load.
Getting core dumps on two nodes now. One of them is basically a new wallet with new addresses and only 100 kb. This is a VPS with 4 GB of RAM and 2 CPU on latest commit. Not sure if helpful but these are last entries in log:
```
2022-08-29 11:42:01 ThreadRPCServer method=z_sendmany
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: z_sendmany initialized (params={"fromaddress":"zs1addr1","amounts":[{"address":"zs1addr2","amount":0.0001}],"minconf":1,"fee":0.0001})
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: found unspent Sapling note (txid=4a88c789a8, vShieldedSpend=6, amount=4.9998, memo=0000000000)
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: spending 0.0002 to send 0.0001 with fee 0.0001
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: transparent input: 0.00 (to choose from)
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: private input: 4.9998 (to choose from)
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: transparent output: 0.00
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: private output: 0.0001
2022-08-29 11:42:01 opid-8793b11a-94c4-474a-b445-cf90da5c4a0a: fee: 0.0001
2022-08-29 11:42:01 Build: Creating Sapling SpendDescriptions
2022-08-29 11:42:05 connection to 139.99.189.228:18030 timeout
2022-08-29 11:42:05 ShuffleOutputs: Shuffling 8 zouts
2022-08-29 11:42:09 Build: Created spendAuth and binding sigs
2022-08-29 11:42:09 sendrawtransaction: Submitting to mempool
2022-08-29 11:42:09 trying connection 196.52.2.60:18030 lastseen=22742.3hrs
2022-08-29 11:42:09 Blockpolicy mempool tx 237987a9ec not adding
2022-08-29 11:42:09 sendrawtransaction: Relaying raw tx to mempool
```
Last entries in other node, which has 100 MB wallet.dat and physical machine with 8 GB of RAM and 6-core CPU. This is not on latest commit:
```
2022-08-29 23:08:20 Build: Creating Sapling SpendDescriptions
2022-08-29 23:08:22 ShuffleOutputs: Shuffling 9 zouts
2022-08-29 23:08:23 Build: Created spendAuth and binding sigs
2022-08-29 23:08:23 sendrawtransaction: Submitting to mempool
2022-08-29 23:08:23 sendrawtransaction: Relaying raw tx to mempool
```
I am reindexing VPS again. Physical, I changed to send 1 tx every 3 minutes in case it was crashing from high load.
Above coredump was fixed. zsweep functionality seems to mostly work (at least when not used with consolidate=1 or deletetx=1), we should open up new issues for specific issues that are found.
Above coredump was fixed. zsweep functionality seems to mostly work (at least when not used with consolidate=1 or deletetx=1), we should open up new issues for specific issues that are found.
This code is currently on the
zsweepbranch, checkout that branch to do testing.zsweep has various config file options, but the most basic usage just requires two:
By default a node will only sweep to a zaddr in the current wallet.dat. To sweep funds out of the current wallet set
zsweepexternal=1:By default
zsweepruns every 5 blocks. To change it:By default
zsweepmakes sure to not reduce the anonset in any tx by having a maximum number of inputs of 8. This should be fine for new wallets, but if you have an existing wallet with many zutxos it can be changed like this:Large values will make sweeping faster at the expense of reducing the anonset.
The default zsweep fee is 10000 puposhis or 0.0001 HUSH, the default for all transactions. To use fee=0 for zsweep transactions:
Things To Test
To see if zsweep tx's have happened on your node, you can do
grep -i sweep ~/.hush/HUSH3/debug.logI am still waiting for test node to finish syncing, but first 4 tests all passed for me as far as either the node giving meaningful error and stopping or starting correctly when zsweep=1 and zsweepaddress=zaddr in wallet. I'll test actual functionality when finished syncing.
Setting an invalid zsweepinterval (0 or negative) gives error and stops nodeI tested with 0 and negative. It gives this message and continues running node with default of 5. I think this is appropriate way to handle if everything else is valid unless we should stop node on error for anything invalid.
main_impl: Invalid sweep interval of -22, setting to default of 5Message is also output every 5 blocks.
Checking
z_getoperationstatus, I get output like this every 5 blocks. This is when there are no funds to sweep, so no txs created.Trying to sweep to external, I get this in debug.log.:
AppInit2: sweeping funds to a zaddr in an external walletEmpty result when I check
z_getoperationstatusand doesn't appear to work. Funds stay in address of local node. I addedconsolidation=1at same time as adding external config and may be related. Need to test withoutconsolidation=1as it seems it might make zsweep not work at all. I tested switching back to local address and removingzsweepexternal=1and zsweep was never running withconsolidation=1.Sweeping funds from one address that's already been swept to, to a new address seems to report incorrect total and double what was swept. Actual amount was 13.9987:
Setting a zsweepaddress outside wallet and zsweepexternal=1 works correctlyConfirmed this works correctly as long as not using consolidation=1. consolidation=1 seems to break zsweep whether using local or external address.
I had to reindex test node because it started showing incorrect low balance in sweep address. Tried rescan first, but still low balance after sweeping. I was trying to send tx every 2-3 minutes and setting zsweepinterval high to test zsweepmaxinputs.
Lots of txs might end up requiring frequent reindexing if something gets jacked up to prevent double spending. This isn't too helpful because I don't have exact message but it was saying something about tx not found during node startup for a bunch of txids and I have a bunch of sapling nullifier exists, prevent double spend in log. May have been calling z_sendmany too quickly or when in invalid state. I'll test more once reindexing finishes.
@fekt giving a warning and setting to a default value is more user-friendly behavior, I agree, so I changed the checklist item and checked that box. Thanks.
@fekt do you like the current behavior of it giving the warning every X blocks that the value was invalid (makes it more likely the user will see it) or should we update the value so it doesn't spam debug.log as much?
As for the amount swept being incorrect and exactly double, I think it's counting how much is swept out of any zaddr plus how much is swept in to the zsweepaddress, which is not that useful. It should either count how much is swept out of addresses or how much is swept into the zsweepaddress.
I have a hunch on why consolidation=1 and zsweep=1 together are not working. I made sweeping run every 5 blocks but there is logic in consolidation that says "if we are less than 15 blocks until the next sweep, don't run consolidation" and since we are always less than 15 blocks until the next sweep, consolidation never actually runs, it bails out early every time.
This is what I was getting on startup when balance incorrect. It seemed to run OK for awhile until balance got too low.
tx hash 791d2998b4584590823cde3dff3d20d95cdb4601643a36d5952437974ef842fb does not exist!A bunch of them with different hashes as well as
tx is unconfirmedlikely for all the related txs and why balance shows incorrect. Seems to think they are spent, but uncofirmed and not actually spent. Also, sometimes get a hash or txid of all 0's, but not sure if from zsweep or existing bug being highlighted by sending a bunch of txs on cron. I was sending 2 txs every 2 minutes.If I rescan, all those messages still show and balance still incorrect until reindexing. Happened again overnight where balance too low to continue sending txs on cron. It still runs zsweep regularly, but with 0 amount.
This is with no longer using consolidation=1. I am also using deletetx=1 and have zindex=1 if it makes any difference.
I am testing on another node that has been fine for over 12 hours so far.
I think it is fine to show it every interval so user is more likely to see it and change it. It is trade off with spamming log, but I don't think it's necessary to change it for them since it's using default value anyway.
@fekt if
zsweepexternal=1is set but thezsweepaddressis in the current wallet.dat, should we give a warning or error? This is something we can automatically detect and tell a user if they think they are sweeping to an external wallet, but they actually are not.Since it's advanced feature, I think a warning is fine every interval if it still sweeps to the address specified, regardless if external or not. Funds never leave their wallet. If it makes more sense with existing logic to error on start, that's fine too though.
Not sure if it's just my wallet or VPS it's on, but I tried latest commit over the weekend and kept getting core dumps. I ended up creating new wallet.dat and was still getting core dumps without sending any transactions and just letting it sweep. I'll check logs later when I can, but I do notice multiple sweep operations that get cancelled before one ends up having a success response. This is with no funds that actually need to be swept and all funds already in sweep address. I was also no longer using consolidation=1. When I did try consolidation=1 initially on latest commit, I was seeing consolidation operations happen and no sweeps, but may not have let it run long enough before changing config or too many inputs so it wasn't trying to sweep. I created new wallet.dat because z_sendmany kept failing and balances incorrect even after multiple reindexes and rescans.
On another test node, which I did not update to latest commit and isn't using consolidation=1, I am also running into the same issue where I end up with a decent amount of txs stuck in mempool that never confirm so balances remain low. I have multiple with hashes or txids of all 0's mixed with real txids that are locking funds and keeping balance low. I have not experienced core dumps on this one yet.
Getting core dumps on two nodes now. One of them is basically a new wallet with new addresses and only 100 kb. This is a VPS with 4 GB of RAM and 2 CPU on latest commit. Not sure if helpful but these are last entries in log:
Last entries in other node, which has 100 MB wallet.dat and physical machine with 8 GB of RAM and 6-core CPU. This is not on latest commit:
I am reindexing VPS again. Physical, I changed to send 1 tx every 3 minutes in case it was crashing from high load.
@duke This is backtrace from last core dump.
Above coredump was fixed. zsweep functionality seems to mostly work (at least when not used with consolidate=1 or deletetx=1), we should open up new issues for specific issues that are found.