Taker instructs makers to delay sending offers after !orderbook so traffic not as bursty

[chris-belcher]

A new parameter added to !orderbook

!orderbook [T]

Which causes a receiving maker to generate a uniform random number between 0 and T, then wait that many seconds before sending their offers to the taker.

The taker can choose for themselves what value T is, in a tradeoff between speed and bursty bandwidth usage.

This could also be used in any new messaging channel after IRC as in #650

[AdamISZ]

Well, but one is incented to get one's offers to the Taker asap, right. Sometimes I think "oh, why doesn't someone just set up an IRC server themselves", but it's not just that it's a pain, it's that it has to support Tor and even without that, often hosting services explicitly ban IRC servers (mine does).

I'd set up a trivial, "lean" server for messaging myself, but Tor connections are a concern (at the very least, a complexity).

A P2P network is ideal, that's what almost everyone says when they look at our setup, the question of whether the disincentive to share offers makes it too problematic (that you pointed out) remains. I keep wondering why that isn't a problem for bitsquare; I presume it's realistically somewhat dependent on seed/bootstrap nodes.

[chris-belcher]

Well, but one is incented to get one's offers to the Taker asap, right.

Nope, the order of arrival doesn't affect which offers the taker chooses to do a coinjoin with. Needless to say the taker will wait at least T seconds before choosing offers so it won't miss any.

We could ask or read up on how bitsquare works in detail. Also I know lightning uses a p2p network meeting point (although it used IRC at one point)

[chris-belcher]

Setting difficulty to 'medium' because this involves some non-trivial sleeping stuff, maybe the easiest way is to open a Timer thread that sends the offers after a wait, or to use socket heartbeats, or use something from twister.

[AdamISZ]

Nope, the order of arrival doesn't affect which offers the taker chooses to do a coinjoin with. Needless to say the taker will wait at least T seconds before choosing offers so it won't miss any.

Well but in practice network delays (of various flavours) make it unpredictable. The exact way the IRC server handles the burst of privmsgs plays in too.

[chris-belcher]

Would that change the incentives to give a reason for the maker to not send offers immediately instead of waiting? If the taker waits 1.5*T+20 seconds they'd almost certainly get everything.

[AdamISZ]

I agree it could/should help if Makers followed the rules above, but if there's a certain probability than respecting the rule gives them a disadvantage, they probably wouldn't, I'm thinking. A bit reminiscent of xkcd's int getrandom(){ return 4;} , except this time it might be return 0.01 :)

[chris-belcher]

I don't see how such a disadvantage could appear.

[AdamISZ]

The Maker gets to choose his value in range 0..T right? so why wouldn't he just choose 0 (or near)? Seems no point in deliberately putting oneself at the back of the queue; I know that in theory, all will be received, but given one can never be sure of connection reliability, why risk it? I'm only arguing that this doesn't enforce the non-burstiness, it just asks for it.

[chris-belcher]

The TCP protocol guarantees reliability. So a maker's offers will always arrive regardless of which [0, T] they chose, no value puts them at the back of the queue because there is no queue. In the case where the connection isn't reliable then the tcp connection will close, so for example the IRC server detects flooding and kills all those connections. In that case no coinjoin will happen and the taker will probably reconnect and choose another T.

So I think there's no economic advantage to choosing an earlier time in [0, T]. And if someone was acting non-economically then they could do a flood today anyway.

[AdamISZ]

You've misunderstood my point. It's not that I was the under the erroneous assumption that there was a literal queue; it's that adding a wait before sending your offer can reduce the probability of arriving before the whatever the timeout is.

Even if that effect is slight, the incentive is not to wait.

[chris-belcher]

I see. On the other hand, the taker has an incentive to collect as many offers as possible because they benefit from a more competitive market. Which means they'll wait for an appropriate amount of time for the T they chose.
Even so maybe the best we can hope for is that the incentives are low enough that nobody bothers recoding their bot.

edit: when two overlapping inconsistent offers arrive in this scheme, the taker should discard one of them randomly instead of the second one. Discarding the second one gives an incentive for makers to send their offers quickly, defeating the point of this idea.

[chris-belcher]

I linked this code on IRC but not on github.

Here is code that uses socket timeouts to implement IRC pings without using a separate thread: https://gist.github.com/chris-belcher/39033530fe550506b833e71c6f19f82d

It creates the regular so-called "heartbeat" function calls, which could also be useful for this issue that needs small delays.

The same heartbeats idea is used in the p2p transaction broadcasting through tor:

joinmarket/joinmarket/peertopeer.py

Line 252 in f961e4d

self.sock.settimeout(self.heartbeat_interval)

The implementation needs to have a timeout in case the other peer already has your transaction, and also waits for a little bit in case the other peer sends "reject".

@AdamISZ I know your joinmarket-clientserver code actually uses twisted instead of these heartbeat things. I don't know much about it but I think twisted could also have regular timer calls which could be drop-in replacements for heartbeats. Do you think one day the twisted architecture could be merged into joinmarket's main code?