Timeout fail in sendpayment.py for Taker with large tx.

[raedah]

Looks like everyone is responding fine. Didnt say anything about waiting for participant x or anything. Solution was to increase maker_timeout_sec from 30 to 100 sec. All participants respond fine without issue, but after the 30 seconds they are all on the non_respondent list, and 'choose new participants' has started. Lots of Throttling triggered, with: 3168 bytes in the last 10.0 seconds msgs.

"Mainly comes from the !tx on the taker side. must've had a lot of UTXOs"

Possible Solutions:

• optimize throttling
• show a better error then going back to choose more respondants
• dynamically adjust maker_timeout_sec per the takers tx size.
• or whether they're using tor or not
• flag if traffic is still being received, and make the maker_timeout_sec obey more like an actual timeout, rather then a timelimit because in this case everyone was responding just fine, but it turned into a non_responder error.

[DavidVorick]

Also, have you considered how people using Tor might be affected by the default timeout? 100 seconds seems prudent, or even 300 seconds (5 minutes).

While this has a negative effect on user experience, I think in general the mentality should be that Bitcoin operations take 10-30 minutes to complete. Even if you can build the unconfirmed transaction in 30 seconds, the operation is 'pending' for a while longer.

That said, the other 'possible solutions' you listed also seem like things that should be done. Even given those optimizations though, I'm sceptical that 30 seconds timeout is enough to handle all the communication that would need to happen with a party attempting to hide their IP address.

[chris-belcher]

One thing that @raedah writes is to increase the timeout if tor is used.

[AdamISZ]

W.r.t optimizing throttling: Although I'd love to be able to get accurate data on the 'right' level of throttling for our IRC server, in the absence of willingness of others to help me carry out big tests, or indeed any tests (I asked a few times), and in the absence of any response to questions about it on cyberguerrilla, I had no choice but to set what seemed to be a reasonably conservative rate limit. And I'm not sure that's something you want to be ultra-optimized anyway.

I believe it has actually helped - before that code was merged, we were getting complaints of inability to complete transactions with lots of utxos; since, we have not. (So in a way I'm trying to argue that this "Issue" is not an issue, but rather a celebration of success :) )

But I agree on the other suggestions in the bullet list: Where tweaking is definitely necessary is in somehow communicating to the user that they need to increase their maker wait, or even better, your suggestions around dynamically adjusting that wait based on factors like the tx size, or a more fine-grained measurement of whether the counterparty is actually slow, or whether it's just that we're throttling ourselves. Anyway, it's 100% true that it's far too obscure at the moment that you can fix this problem by bumping that variable.

[DavidVorick]

@chris-belcher You need to consider whether the other party is using Tor, it's not enough to know if you are using tor.

[chris-belcher]

Noted. Forgot about that.

[raedah]

set what seemed to be a reasonably conservative rate limit

Where can we find this to modify?

[AdamISZ]

https://github.com/JoinMarket-Org/joinmarket/blob/master/joinmarket/irc.py#L70-L72

If you 'optimize' it to a lower value, you have to know that cyberguerrilla doesn't kick large transactions with many counterparties. That used to happen a lot.

[AdamISZ]

#450 addressing the dynamic timeout part.