From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for massively improving Bitcoin privacy and fungibility
Date: Sat, 06 Jun 2020 03:59:30 +0000 [thread overview]
Message-ID: <xNdzEDklg3DOAHpaOhPlacvkhr6Nfk6-oR6YAbqsMJiYc2QM837LAgwXpuIqyy6M6mZyk2zcZQqUWTlYky6MoAG_0ecupIygmSGDHuppa_4=@protonmail.com> (raw)
In-Reply-To: <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com>
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
next prev parent reply other threads:[~2020-06-06 3:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-25 13:21 Chris Belcher
2020-05-30 16:00 ` Ruben Somsen
2020-05-31 2:30 ` ZmnSCPxj
2020-05-31 21:19 ` Ruben Somsen
2020-06-01 2:34 ` ZmnSCPxj
2020-06-01 10:19 ` Ruben Somsen
2020-06-02 22:24 ` Chris Belcher
2020-06-03 4:53 ` ZmnSCPxj
2020-06-03 14:50 ` ZmnSCPxj
2020-06-04 16:37 ` ZmnSCPxj
2020-06-05 22:39 ` Chris Belcher
2020-06-06 1:40 ` ZmnSCPxj
2020-06-06 3:59 ` ZmnSCPxj [this message]
2020-06-06 4:25 ` ZmnSCPxj
2020-06-10 10:15 ` Chris Belcher
2020-06-10 10:58 ` ZmnSCPxj
2020-06-10 11:19 ` Chris Belcher
2020-06-10 0:43 ` Mr. Lee Chiffre
2020-06-10 0:46 ` Mr. Lee Chiffre
2020-06-10 7:09 ` ZmnSCPxj
2020-06-10 11:15 ` Chris Belcher
2020-06-19 15:33 ` Jonas Nick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='xNdzEDklg3DOAHpaOhPlacvkhr6Nfk6-oR6YAbqsMJiYc2QM837LAgwXpuIqyy6M6mZyk2zcZQqUWTlYky6MoAG_0ecupIygmSGDHuppa_4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox