ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2020-06-06 📝 Original message:Good morning again Chris, ...
📅 Original date posted:2020-06-06
📝 Original message: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
📝 Original message: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