reduce tx cancel from 12h to 2h

[pokefan77]

thanks to improvements in the reliability of the client software and protocol atomic swaps work almost flawless in the current state

there is no valid reason to initiate a swap and then not stay online for 1 bitcoin confirmation + 10 monero confirmations to complete a swap

the current protocol for some reason allows for 12h to pass before tx_cancel is published
this not only allows for manipulation (betting on xmr price change) but also blocks xmr for the maker

a reduction to 2h in the next hardfork v4 would make funds for the maker available 10h faster and abolish the problem with the manipulation/betting from the taker site

i dont find any good arguments for a 12h window with the current state of the protocol.
a taker can simply start a new swap in case of failure

even if a taker is honest, the mere fact that he can go to sleep and then continue the trade and the maker has to live with the loss is crazy

if its unclear:
taker initiates swap for 6.000$ worth of xmr (10) for X btc
taker goes offline
11h later the taker finish the swap
taker has 10 xmr, maker 0.2 btc.
in the meantime xmr has risen 10%, btc price stayed the same.
maker takes his btc and now buys ~9.1 XMR with the btc he got from the taker
maker runs a service, exchanges money back and forth, and looses 1 xmr in the process.

this is imo unrelated to any spam deterence plans where takers can be punished and loose funds, because this seems to also be a opt-in function that even has to be manually executed because makers are expected to be online
my example is also with users that dont reach the spam deterence

[binarybaron]

We are going to reduce it to something between 4h and 6h.

[pokefan77]

i'm interested whats the argument for a higher number than 2h?

the timer starts after 1 confirm of btc blockchain anyway right?
and the worst case is a restart of the swap?
so why 6h?

[binarybaron]

i'm interested whats the argument for a higher number than 2h?

the timer starts after 1 confirm of btc blockchain anyway right? and the worst case is a restart of the swap? so why 6h?

The makers needs some amount of blocks of safety to ensure tx_redeem gets confirmed before the cancel timelock expires.

We also want to give some of leeway for technical issues as refunds can have negative impacts for takers in some cases.

[pokefan77]

i strongly vote for 4h because the chance for manipulation increases exponentially for every hour added

[pokefan77]

@binarybaron Einliterflasche refers in his newest diagram in spam deterence still to a 12h timelock until cancel.

I want to reiterate that one or more attackers misuse the current 12h timelock for manipulation/betting consistently on a daily basis
They start several swaps and then either let them cancel out or redeem them all at the same time when the monero price increased sufficiently for their needs.
Their attack comes at basically no cost (3x btc transaction fees worst case) and a bit of management.
They use their BTC, buy XMR, it pumps 5%, they proceed with the swap, they take the XMR minus the 2% fee from maker, throw it into some instant swapper for 0.5% and gained 2.5% on their btc portfolio. Then they start the next swaps. They have multiple btc worth to "attack" with. (at least 8 btc at any single time, yielding 0.2 btc in my above example!)

normal swaps all look much different: they just succeed within 1h no problem
i reiterate my statement that 6h timelock would still open much more manipulation/betting than 4h timelock

[binarybaron]

Its for the sake of visualization. We will reduce the timelock.

[pokefan77]

Its for the sake of visualization. We will reduce the timelock.

i presume reducing timelock has to be done with the hardfork?
is there a rough time estimate for the hardfork?
there is about 5-15btc "successful" in such betting activities per day depending on monero price movements, and at least double the amount of that in unsuccessful attempts, but still blocking the xmr while attempting