ABORT:Failed to get a change address

[verlib]

I funded my JM wallet with 1 UTXO (despite the advice "Fund your wallet with multiple utxos" here, because I wanted to see how it works before putting more funds) and started a tumbler with the schedule as following:

3,0,6,INTERNAL,54.02,16,1 2,0,9,INTERNAL,28.19,16,1 3,0.29149491505576597,9,INTERNAL,28.17,3,1 3,0,7,INTERNAL,13.41,16,1 4,0.2907406427821413,9,INTERNAL,74.56,16,1 4,0.4804782197934313,8,INTERNAL,35.67,16,1 4,0,7,bc1qA,85.36,16,1 5,0.0010128094944049648,9,INTERNAL,121.47,16,0 5,0,10,bc1qB,0.59,16,0 6,0,8,bc1qC,3.52,16,0

After successfully sending to the first destination address (bc1aA), it keeps failing and doesn't complete the 5th and the 6th step of the schedule.

Also I don't get the INFO: Coinjoin amount too low, bringing up to: 0.00100000 BTC I have now two utxos in mixdepth0 which are greater that 0.001 :face_with_head_bandage:

Here is the log: 2022-08-14 11:24:30,542 [INFO] JM daemon setup complete 2022-08-14 11:25:30,556 [INFO] INFO:Received offers from joinmarket pit 2022-08-14 11:25:30,557 [INFO] Coinjoin amount too low, bringing up to: 0.00100000 BTC (100000 sat) 2022-08-14 11:25:30,558 [INFO] Choosing a destination from mixdepth: 1 2022-08-14 11:25:30,581 [INFO] Chose destination address: bc1qXXXXXXXXXXXX 2022-08-14 11:25:30,802 [INFO] rel/abs average fee = 5.222222222222222e-05 / 5.222222222222222 2022-08-14 11:25:30,802 [INFO] INFO:Preparing bitcoin data.. 2022-08-14 11:25:30,802 [INFO] ABORT:Failed to get a change address 2022-08-14 11:25:30,802 [INFO] Taker not continuing after receipt of orderbook

The error is intermittent (every 20 min or so) and it keeps choosing a new destination address from m1 every time it runs.
What should I do? Shall I just wait? It's been more than 6 hours that I get the same error.

PS: Just for the context, probably it doesn't matter at all. I started a first tumbler from mixdepth 0 with default parameters which coinjoined a few times until m2 and m3. Then I accidentally interrupted it (Ctrl+C) and restarted it with the schedule above.

[verlib]

after 10h of waiting and getting the same result, I did sweep everything from m0 to a final destination address, but I am still wondering what went wrong with the tumbler. Could it be due to the fact that I funded the wallet with just one utxo?

[AdamISZ]

@verlib after the change in 0.9.7 can you still reproduce this error? (or indeed, can you reproduce it at all?).

Looking at the relevant portion of the code:

https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/fed508d6b87b014391da8437c903ca6b9fab69b2/jmclient/jmclient/taker.py#L316-L324

... I can't see an obvious way this can get triggered, unless the mixdepth being used is one that doesn't exist in the wallet (this could happen pre-0.9.7, where there was for sure a bug related to using more than the default number of mixdepths in the tumbler; it's briefly described in the release notes). However I don't really see how that would work in this case; since you are choosing a destination in mixdepth 1, that means the source mixdepth is 0, which definitely always exists, in any Joinmarket wallet.

Drilling down into the calls in that function, about the only place I can see where an exception can be thrown, is here:

https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/fed508d6b87b014391da8437c903ca6b9fab69b2/jmclient/jmclient/wallet.py#L2184-L2188

... but that seems pretty unlikely; it'd only happen if you were running in no-history mode (this is set in the config file: POLICY section, blockchain_source, value bitcoin-rpc-no-history).

So I'm stuck even at trying to reproduce the error (I don't think I've ever seen it myself in testing).

[verlib]

after the change in 0.9.7 can you still reproduce this error?

nope. I wasn't able to reproduce it anymore after the update.

where there was for sure a bug related to using more than the default number of mixdepths in the tumbler

I did use the default number of mixdepths, so we can safely exclude it, i guess.

but that seems pretty unlikely; it'd only happen if you were running in no-history mode

i definitely didn't use it in no-history mode.

I think we can safely close the issue for now, but I will not hesitate to open it should I experience it again. Thanks.