To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
 <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
 <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
 <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
 <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com>
 <e724b4c5-9efd-66c4-163b-492f17cafd7d@riseup.net>
 <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com>
From: Chris Belcher <belcher@riseup.net>
Autocrypt: addr=belcher@riseup.net; prefer-encrypt=mutual; keydata=
 xsFNBFPk74oBEACzBLjd+Z5z7eimqPuObFTaJCTXP7fgZjgVwt+q94VQ2wM0ctk/Ft9w2A92
 f14T7PiHaVDjHxrcW+6sw2VI2f60T8Tjf+b4701hIybluWL8DntG9BW19bZLmjAj7zkgektl
 YNDUrlYcQq2OEHm/MGk6Ajt2RA56aRKqoz22e+4ZA89gDgamxUAadul7AETSsgqOEUDI0FKR
 FODzoH65w1ien/DLkG1f76jd0XA6AxrESJVO0JzvkTnJGElBcA37rYaMmDi4DhG2MY4u63VE
 8h6DyUXcRhmTZIAj+r+Ht+KMDiuiyQcKywCzzF/7Ui7YxqeAgjm5aPDU2E8X9Qd7cqHQzFM7
 ZCqc9P6ENAk5a0JjHw0d0knApboSvkIJUB0j1xDIS0HaRlfHM4TPdOoDgnaXb7BvDfE+0zSz
 WkvAns9oJV6uWdnz5kllVCjgB/FXO4plyFCHhXikXjm1XuQyL8xV88OqgDFXwVhKrDL9Pknu
 sTchYm3BS2b5Xq1HQqToT3I2gRGTtDzZVZV0izCefJaDp1mf49k2cokDEfw9MroEj4A0Wfht
 0J64pzlBYn/9zor5cZp/EAblLRDK6HKhSZArIiDR1RC7a6s7oTzmfn0suhKDdTzkbTAnDsPi
 Dokl58xoxz+JdYKjzVh98lpcvMPlbZ+LwIsgbdH4KZj7mVOsJwARAQABzR9DaHJpcyBCZWxj
 aGVyIDxmYWxzZUBlbWFpbC5jb20+wsF+BBMBAgAoBQJT5O+KAhsDBQkSzAMABgsJCAcDAgYV
 CAIJCgsEFgIDAQIeAQIXgAAKCRDvc06md/MRKS8jD/9P9fSYSIVjltL9brAMfIu7wJn0H0lX
 TbcuCM2uQitJ3BNxI3c7aq5dEby27u5Ud54otncDJuRPQVDKs6H7t1rInitgJ1MTQ9/aQGFA
 btKcgtVIMFbeClzTTfWr4W7fE45NI7E9EANgk5JfmWh3U+KINYLF5RtqynYocrsP6zOV+G9A
 HCpBemd9TN60CoMLMyMzTHEW1oQffaVAXY8DgthEYO/odWYIod7VTmEm0zU1aSysPqMwPWNm
 8XIl0f8SfKQyZlAU8e1eCFVCenkE44FKC5qQNYc2UxexEYtfCWChTGc4oHKxIyYmTCCefsQF
 LvgwtvlNHRXHSDKSPSNcRcpl8DFpNEKrmMlkJ8Mx+YR05CydlTQ0bI3FBohJC+UHrjD5I3hA
 wJUC1o+yVSOEd+zN3cG1EECIwkEQSmBgG5t/le2RdzfXOdpf9ku2/zoBpq00R54JxUKlfRM7
 OPTv7X+1AKHkxOySdCZwGgvdh2Whuqs4kTvtco00gCFM9fBd5oi1RJuHtxHsj8+/XU15UItb
 jeo96CIlM5YUeoRLPT5mxZYWgYAARFeSFReNq/Tuwq9d8EokUrtAyrPayznliy53UJfWDVzl
 925c0Cz0HWaP2fWj+uFcj/8K0bhptuWJQy0Poht1z3aJC1UjEgr1Xz8I7jeSJmIlA9plcJw2
 k4dhWc7BTQRT5O+KARAAyFxAM28EQwLctr0CrQhYWZfMKzAhCw+EyrUJ+/e4uiAQ4OyXifRr
 ZV6kLRul3WbTB1kpA6wgCShO0N3vw8fFG2Cs6QphVagEH8yfQUroaVxgADYOTLHMOb7INS8r
 KI/uRNmE6bXTX27oaqCEXLMycqYlufad7hr42S/T8zNh5m2vl6T/1Poj2/ormViKwAxM+8qf
 xd8FNI4UKmq2zZE9mZ5PiSIX0qRgM0yCvxV39ex/nhxzouTBvv4Lb1ntplR/bMLrHxsCzhyM
 KDgcX7ApGm+y6YEsOvzw9rRCRuJpE4lth8ShgjTtNTHfklBD6Ztymc7q7bdPWpKOEvO5lDQ6
 q8+KfENv862cOLlWLk7YR2+mHZ1PXGhWC7ggwEkfGJoXo0x8X+zgUKe2+9Jj4yEhfL0IbFYC
 z2J5d+cWVIBktI3xqkwLUZWuAbE3vgYA4h8ztR6l18NTPkiAvpNQEaL4ZRnAx22WdsQ8GlEW
 dyKZBWbLUdNcMmPfGi5FCw2nNvCyN6ktv5mTZE12EqgvpzYcuUGQPIMV9KTlSPum3NLDq8QI
 6grbG8iNNpEBxmCQOKz2/BuYApU2hwt2E44fL8e6CRK3ridcRdqpueg75my6KkOqm8nSiMEc
 /pVIHwdJ9/quiuRaeC/tZWlYPIwDWgb8ZE/g66z35WAguMQ+EwfvgAUAEQEAAcLBZQQYAQIA
 DwUCU+TvigIbDAUJEswDAAAKCRDvc06md/MRKaZwD/9OI3o3gVmst/mGx6hVQry++ht8dFWN
 IiASPBvD3E5EWbqWi6mmqSIOS6CxjU0PncxTBPCXtzxo/WzuHGQg/xtNeQ0T8b2lBScZAw93
 qm1IcHXLUe5w/Tap6YaDmSYCIZAdtbHzYfPW4JK7cmvcjvF8jhTFOBEOFVQkTi19G7caVot0
 +wL1e2DRHDXAe5CinEpaLBlwHeEu/5j6wc3erohUZlK9IbAclj4iZTQbaq3EyqUXl59dBOON
 xmL5edJxzVishIYQGIyA9WP1SylXt+kO82NEqZG2OxdXAlzjuJ8C2pAG+nbLtDo4hcsiN/MA
 aX9/JB7MXclT5ioerF4yNgKEdfq7LmynsTUd8w/Ilyp7AD+BWoujyO94i8h9eKvjf9PvSwxQ
 uAjRpxne7ZJD8vCsMNXBHSbeEK2LiwStHL/w473viXpDD53J6OLxX6a5RummR+rixbMH7dgK
 MJQ7FlyDphm3or6CSkGEir1KA0y1vqQNFtHhguFapAWMDKaJjQQNgvZUmOo6hbZqmvUF1OWc
 d6GA6j3WOUe3fDJXfbq6P9Jmxq64op887dYKsg7xjQq/7KM7wyRcqXXcbBdgvNtVDP+EnzBN
 HyYY/3ms4YIHE5JHxQ9LV4yPcWkYTvb1XpNIFVbrSXAeyGHVNT+SO6olFovbWIC3Az9yesaM
 1aSoTg==
Message-ID: <27f05cf1-08b2-a281-75b7-5c035317d030@riseup.net>
Date: Wed, 10 Jun 2020 11:15:36 +0100
MIME-Version: 1.0
In-Reply-To: <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
 massively improving Bitcoin privacy and fungibility
Precedence: list

Good morning ZmnSCPxj,

On 06/06/2020 02:40, ZmnSCPxj wrote:
> Good morning Chris,
> 
>> I think I'm having trouble understanding this, does it work like this:
>>
>> Say we're in the 2-party coinswap case (Alice and Bob)
>>
>> We have Alice's funding transaction:
>> Alice UTXO ---> 2of2 multisig (Alice+Bob)
>>
>> And we have the regular contract transaction
>> 2of2 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock
>>
>> And you propose a second pre-signed transaction?
>> 2of2 multisig (Alice+Bob) ---> Bob+timelock2
> 
> No, it is:
> 
> 2of2 multisig (Alice+Bob) --(nLockTime=locktime1)-> Alice
> 
> The timelock is  imposed as a `nLockTime`, not as an `OP_CLTV` (so not in the output of the tx, but part of the tx), and the backout returns the funds to Alice, not sends it to Bob.
> This transaction is created *before* the contract transaction.
> 
> The order is:
> 
> * Create (but not sign) Alice funding tx (Alice --> Alice+Bob).
> * Create and sign Alice backout transaction (Alice+Bob -(nLockTime=locktime1)-> Alice).
> * Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret).
> * Create and sign Bob backout transaction (Alice+Bob+sharedSecret -(nLocktime=locktime2)-> Bob) where timelock2 < timelock1.
> * Sign and broadcast funding txes.
>   * At this point, even if Bob funding tx is confirmed but Alice funding tx is not, Bob can recover funds with the backout, but Alice cannot steal the funds (since there is no hashlock branch at this point).
> * When Alice funding tx is confirmed, create and sign contract transaction (Alice+Bob --> Alice+timelock1 OR Bob+hashlock).
> * When Bob funding tx is confirmed and Bob has received the Alice contract transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecret --> Bob+timelock2 OR Alice+hashlock).
> * Continue as normal.
> 
> In effect, the backout transaction creates a temporary Spilman unidirectional time-bound channel.
> We just reuse the same timelock on the HTLC we expect to instantiate, as the time bound of the Spilman channel; the timelock exists anyway, we might as well reuse it for the Spilman.
> 
> Creation of the contract tx invalidates the backout tx (the backout tx is `nLockTime`d, the contract tx has no such encumbrance), but the backout allows Alice and Bob to fund their txes simultaneously without risk of race loss.
> However, they do still have to wait for (deep) confirmation before signing contract transactions, and Bob has to wait for the incoming contract transaction as well before it signs its outgoing contract transaction.
> 
> The protocol is trivially extendable with more than one Bob.
> 
> The insight basically is that we can split CoinSwap into a "channel establishment" phase and "HTLC forwarding" phase followed by "HTLC resolution" and "private key handover".
> HTLC forwarding and HTLC resolution are "done offchain" in the channels, and channel establishment can be done in any order, including reverse.
> 
> Indeed, the Spilman channel need not have the same timelock as the HTLC it will eventually host: it could have a shorter timelock, since the contract transaction has no `nLockTime` it can be instantiated (with loss of privacy due to the nonstandard script) before the Spilman timeout.
> 
> Regards,
> ZmnSCPxj
> 

Thanks for the explanation. I understand now, and I understand how this
makes it possible for all funding transactions in a coinswap route to be
confirmed in the same block.

However, I think this also breaks private key handover. Here's why:

Recall that in a Alice/Bob coinswap we have two funding transactions
(Alice --> multisig(Alice, Bob) and Bob --> multisig(Bob,Alice)), and
two contract transactions (multisig(Alice, Bob) -->
Alice+OP_CSV_timelock OR Bob+hashlock and multisig(Bob,Alice -->
Bob+OP_CSV_timelock OR Alice+hashlock). After the hashlock preimage
becomes known to all then Alice and Bob give their multisig privkey to
the other party.

Bob now has both privkeys in the multisig(Alice,Bob) so he can sign any
transaction he wants spending from it, but the contract transaction
still exists. So until Bob actually spends from the multisig he must
always be watching the blockchain, and if Alice broadcasts the contract
transaction then Bob must immediately spend from it using the hash
preimage branch. If Bob waits too long and the OP_CSV timelock value
passes then Alice can steal Bob's money by spending with that path. The
OP_CSV timelock only starts ticking when the contract transaction
actually confirms, and this is crucial for making privkey handover
practical because it means the coins in the multisig can stay unspent
indefinitely.

However, I think this does not apply to the scheme you described which
uses nLockTime, because after the privkeys are handed over Alice's
backout transaction (Alice+Bob -(nLockTime=locktime1)-> Alice) still
exists, and Alice could broadcast it. Once locktime1 passes then Alice
can steal Bob's coins by broadcasting even though Bob holds both
privkeys to that multisig. And using relative nLockTime doesn't help
either because its timelock will start ticking down from when the
funding transaction is confirmed, not when the contract transaction is
confirmed, and so the coins in the multisig cant remain unspent
indefinitely.

So fundamentally I think privkey handover gets broken here because it
requires relative timelocks. And those the relative timelocks need to
start ticking down only after a contract transaction is confirmed.


> 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.

I was aware. In such a scheme we'd still require the other building
blocks like fidelity bonds, multi-transaction and routing. So I was
thinking to code the project using the simplest hash-time-locked
contracts and once it all works we can add things like ECDSA-2P
scriptless scripts or schnorr signatures when they get added. Making the
Spilman channel scheme work with that is an interesting idea, thanks for
the thought.

> Let me propose an alternative: swap-on-receive+swap-on-change.

That's an interesting point, thanks for the thought. This scheme might
not be appropriate for every threat model and use case.
For example, if someone wants to use bitcoin just as a foreign currency
for its privacy and censorship-resistant properties. So for example if
they want to pay for a VPN anonymously, so they buy bitcoins and
immediately send all of them to the VPN merchant. The swap-on-receive
wouldn't be appropriate for them because they'll be doing a coinswap
straight away to the VPN merchant. So perhaps this plan could be an
optional mode of operation (which may or may not be the default). The
scheme obviously is useful when bitcoin is being used more as a
day-to-day money.


Regards
CB