[bisq-network/proposals] Add delayed refund transactions (#303)

Steven Barclay notifications at github.com
Sat Feb 6 06:37:27 CET 2021


I share @MwithM's concern that a trader may be unable to publish the delayed payout tx, say due to losing all his trade data, and then the counterparty can just wait and send all the funds to himself. (There would likely be at least a little temptation to do so if it was a large amount of BTC, especially knowing that the victim would be reimbursed by the DAO.)

I like @sqrrm's idea of giving each trader a separate delayed payout tx that sends the locked funds to a half-way address, before sending them on either to oneself (after a 5 day time delay) or immediately by the counterparty to the donation address. This is vaguely reminiscent of the two prepared uncooperative channel closure txs for a lightning channel, where the 5 day timelocked payment to oneself is analogous to the final settlement payout of the lighting channel, and the immediate remedial payment by the counterparty to the donation address is analogous to the hashlocked remedial/punishment payout (following a fraudulent channel closure) by the counterparty to himself, but without the hashlock. Just like the lightning channel protocol, I would be inclined to use a P2WSH half-way address with a custom script using `OP_CHECKSEQUENCEVERIFY` to enforce a relative 5 day time delay, rather than using the absolute block height of a downstream prepared tx locktime. This has the advantage that there's no hurry to publish the initial delayed payout tx.

It should be possible to mostly solve the problem of a trader losing their trade data and being unable to publish the time sensitive remedial downstream payment tx to the donation address, by burying the data needed to reconstruct it in their own signatures (say one for the deposit tx and one for the initial delayed payout tx). Because each 512-bit ECDSA signature _(r, s)_ is derived from a 256-bit nonce _k_, where _r_ is the _x_-component of the elliptic curve point _R = kG_ and _s = (z - re)/k_, for a private key _e_ and message hash _z_, it is possible to recover _k_ from the private key, which is in turn derived from the wallet seed phrase. Thus 256 bits of arbitrary data may be buried in each published signature and recovered knowing only ones seed phrase. The remedial tx needs 512 bits of stored trade data to recover it, as it has to be signed by the counterparty, so that could be buried in the trader's deposit tx and initial delayed payout tx signatures. (The signatures can be malleated by the counterparty prior to publishing, but only to a very limited extent, so the 256 buried bits can still be easily recovered by brute force.) In this way, a trader who lost his trade data (and backups) should still be OK, provided he didn't lose his Bisq wallet seed phrase.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/proposals/issues/303#issuecomment-774404135
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20210205/cc3dff55/attachment-0001.htm>


More information about the bisq-github mailing list