Good morning again Chris,

I am uncertain if you are aware, but some years ago somebody claimed that 
2p-ECDSA could use Scriptless Script as well over on lightning-dev.

* 
https://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf
* 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001221.html

I cannot claim to follow the math enough to say it is actually secure, but the 
idea does exist.

If this is sufficiently secure, we can fold the Spilman backout into the 
scriptless script swap as well.

* Alice creates secret keypairs A[0] = a[0] * G, A[1] = a[1] * G
* Bob creates secret keypairs B[0] = b[0] * G, B[1] = b[1] * G
* Alice creates (but does not sign) funding from Alice -> A[0] && B[0]
* Bob provides partial signature for A[0] && B[0] -(nLockTime=locktime1)-> 
Alice to Alice and Alice completes this signature and stashes it.
* Bob creates (but does not sign) funding from Bob -> A[1] && B[1]
* Alice provides partial signature for A[1] && B[1] -(nLockTime=lockTime2)-> 
Bob to Bob and Bob completes this signature and stashes it.
* Alice and Bob sign and broadcast their funding transactions.
  * This can safely be done in any order; Bob will refuse to continue with the 
protocol until it sees Alice funding is confirmed, and will abort if locktime2 
is too near.
* Alice waits for Bob funding tx to confirm.
* Alice provides a 2p-ECDSA adaptor signature for A[1] && B[1] --> Alice; the 
adaptor signature, when completed, reveals the secret a[0] to Bob.
* Bob waits for Alice funding tx to confirm.
* Bob provides the partial signature for the given adaptor signature for A[1] 
&& B[1] --> Alice and  Alice completes this signature and stashes it.
* Alice gives a[0] outright to Bob.
* Bob gives b[1] outright to Alice.
* Alice spends the A[1] && B[1] output before locktime2.
* Bob spends the A[0] && B[0] output before locktime1.

I also pointed out the griefing problem in Lightning also applies to SwapMarket.
Bob can limit the griefing problem by requiring that locktime2 <= now + 12, and 
requiring that locktime1 >= now + 60.
This means that Alice has to lock its funds for 10 hours if it forces Bob to 
lock its funds for 2 hours, making it undesirable as an attack on competing 
makers.
This does prevent chaining (no maker is going to accept the outgoing), but if 
Alice wants chaining it can always use the private key handed over to 
immediately start a funding tx with another Bob.

(This is not a good solution for griefing in the Lightning Network since 
channels are intended to be reused there, whereas the Spilman channels in 
CoinSwap exist only to allow funding transactions to confirm in any order 
onchain, and are used only for the specific swap; in Lightning the forwarding 
node has an incentive to release the incoming HTLC immediately instead of 
imposing the incoming wait time since the funding can be reused for a different 
payment, but in CoinSwap it cannot be reused anyway, so it could just let the 
incoming timelock lapse instead of releasing that encumbrance as would be done 
in Lightning.)

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to