From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3BDF4C0051 for ; Fri, 21 Aug 2020 04:20:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 21ADA227A3 for ; Fri, 21 Aug 2020 04:20:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW9o0dZ2zlrd for ; Fri, 21 Aug 2020 04:20:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by silver.osuosl.org (Postfix) with ESMTPS id DF55820484 for ; Fri, 21 Aug 2020 04:20:35 +0000 (UTC) Date: Fri, 21 Aug 2020 04:20:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1597983632; bh=ot2n25cDby0OlHd8a9Kzrv0Ok140rITh8wRjrTUDm+0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=dZeoywuCiXiMoBAnvATIMByu4+WVNfH198D5rilMbDjUh56r7fqIgb1qw2yvIAULX XA2tpmppVWF4w9NnWqkuls/mJ65xBFISdGm1B1asD+/FlLbSDF8Oj7t7wkSDctVHbL ypfdwb+OSlawEnZXlg59P9YRklQtTL4y3XIICACA= To: Chris Belcher From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2020 04:20:40 -0000 Good morning, > Right, so if the taker uses only a single maker then they must have more > than one UTXO. Spending one UTXO is fine, it is generating a transaction that has one outp= ut that is problematic. What needs to happen is that this single UTXO is spent to two outputs: the = CoinSwap 2-of-2 and the change output. This is because intermediate makers will have very high likelihood of gener= ating such a pattern (it is unlikely they have an exact amount that a taker= would require of them), and the occassional maker might have a very large = UTXO that it can use for similar purposes. One thing a taker can do would be to multipath its CoinSwap, i.e. it spends= any number of UTXOs and creates two outputs, which are actually two separa= te CoinSwap 2-of-2s to different makers. As each maker is unaware of the other, this should be similar to the case w= here the maker is an intermediate hop and is getting its incoming HTLC from= another maker, which is unlikely to have a precise amount and will thus ha= ve a transaction that has two outputs, the 2-of-2 CoinSwap and the change. > > This leak in the case of a taker spending a single UTXO also happens > when the taker needs to create a branching route. I described this in my > original email "Design for a CoinSwap implementation for massively > improving Bitcoin privacy and fungibility" under the section "Combining > multi-transaction with routing" (the second diagram). > > I think this might be unavoidable. If the taker has just one UTXO they'd > be much better off using multiple makers for this reason. > > > - The makers can try timing the communications lag with the taker. > > The general assumption would be that more makers =3D=3D more delay = in taker responses. > > > > Sounds like adding random delays would fix this. The protocol already > involves waiting for a confirmation (average waiting time 10 minutes, at > best) and might involve more confirmations for extra security and > privacy. So adding a random delay of up to 0.5-1 minutes shouldnt cause > too many issues. > Also the Tor network can be pretty laggy so that might add enough noise > anyway. Indeed, this seems a bit of a long shot for the surveilling maker. > > > =3D=3D=3D Miner fees =3D=3D=3D > > > Makers have no incentive to pay any miner fees. They only do > > > transactions which earn them an income and are willing to wait a very > > > long time for that to happen. By contrast takers want to create > > > transactions far more urgently. In JoinMarket we coded a protocol whe= re > > > the maker could contribute to miner fees, but the market price offere= d > > > of that trended towards zero. So the reality is that takers will pay = all > > > the miner fees. Also because makers don't know the taker's time > > > preference they don't know how much they should pay in miner fees. > > > The taker will have to set limits on how large the maker's transactio= ns > > > are, otherwise makers could abuse this by having the taker consolidat= e > > > maker's UTXOs for free. > > > > Why not have the taker pay for the first maker-spent UTXO and have addi= tional maker-spent UTXOs paid for by the maker? > > i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 = BTC", and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs). > > Disagreements on feerate can be resolved by having the taker set the fe= erate, i.e. "the customer is always right". > > Thus if the maker has to spend two UTXOs to make up the 0.4 BTC bag, it= pays for the mining fees for that extra UTXO. > > The maker can always reject the swap attempt if it has to spend multipl= e UTXOs and would lose money doing so if the taker demands a too-high feera= te. > > Having the taker pay for just one UTXO will have an unfortunate side > effect of resulting in the maker's money being split up into a large > number of UTXOs, because every CoinSwap they take part in has an > incentive to increase their UTXO count by one. At the start of > JoinMarket this was an issue where then a taker wanting to CoinJoin a > large would come along and the result would be a huge CoinJoin > transaction with many many small inputs. Perhaps the taker could pay for > 2-3 UTXOs to counteract this. (Of course the exact number would be > configurable by the taker user, but defaults usually don't get changed). > > I'm still not convinced with having makers contribute to miner fees. In > JoinMarket we tried to get makers to contribute a little to miner fees > and simply they never did in any meaningful way. The market has spoken. > In terms of incentives makers are happy to wait a very long time, if we > assume they're just HODLers then even if they earn a few thousand > satoshis that's good. > > > > =3D=3D Contract transaction definitions =3D=3D > > > Contract transactions are those which may spend from the 2-of-2 multi= sig > > > outputs, they transfer the coins into a contract where the coins can = be > > > spent either by waiting for a timeout or providing a hash preimage > > > value. Ideally contract transactions will never be broadcast but thei= r > > > existence keeps all parties honest. > > > M~ is miner fees, which we treat as a random variable, and ultimately > > > set by whichever pre-signed RBF tx get mined. When we talk about the > > > contract tx, we actually mean perhaps 20-30 transactions which only > > > differ by the miner fee and have RBF enabled, so they can be broadcas= ted > > > in sequence to get the contract transaction mined regardless of the > > > demand for block space. > > > > The highest-fee version could have, in addition, CPFP-anchor outputs, l= ike those being proposed in Lightning, so even if onchain fees rise above t= he largest fee reservation, it is possible to add even more fees. > > Or not. > > Hmm. > > I think RBF transactions are better because they ultimately use less > block space than CPFP. > > There seems to be very little cost in signing many additional > precomputed RBF transactions. So the taker and makers could sign > transactions all the way up to 10000 sat/vbyte. I think this doesn't > apply to Lightning, because bandwidth seems to be more constrained > there: even a tiny micropayment for 1 satoshi would require 10x or 100x > more bandwidth if every lightning htlc used precomputed RBF. I was wondering if it would be a good idea actually if the **largest** fee = RBF transaction had additional CPFP anchor outputs, not saying to replace t= he entire group of RBF transactions entirely. This is just in case of a very sudden increase in feerates that goes beyond= the largest that was prepared beforehand. "You cannot predict the feerates future" is becoming something of a mantra = over in Lightning, though I guess a "big enough" spread of RBF transactions= would work in practice >99% of the time. > > Another thought: later you describe that miner fees are paid by Alice b= y forwarding those fees as well, how does that work when there are multiple= versions of the contract transaction? > > Alice only pays the miner fees for the funding transactions, not the > contract transaction. The miner fees for the contract transactions are > taken from the contract balance. The contract transactions are 1-input > 1-output, and whoever ends up with the money will be the one who paid > the miner fee. Okay, that is much clearer. > > > (Alice+timelock_A OR Bob+hash) =3D Is an output which can be spent > > > either with Alice's private key > > > after waiting for a relative > > > timelock_A, or by Bob's private key by > > > revealing a hash preimage value > > > > The rationale for relative timelocks is that it makes private key turno= ver slightly more useable by ensuring that, after private key turnover, it = is possible to wait indefinitely to spend the UTXO it received. > > This is in contrast with absolute timelocks, where after private key tu= rnover, it is required to spend received UTXO before the absolute timeout. > > The dangers are: > > > > - Until it receives the private key, if either of the incoming or out= going contract transactions are confirmed, every swap participant (taker or= maker) should also broadcast the other contract transaction, and resolve b= y onchain transactions (with loss of privacy). > > - After receiving the private key, if the incoming contract transacti= on is confirmed, it should spend the resulting contract output. > > - It is possible to steal from a participant if that participant goes= offline longer than the timeout. > > This may imply that there may have to be some minimum timeout that = makers indicate in their advertisements. > > - The taker can detect if the first maker is offline, then if it = is offline, try a contract transaction broadcast, if it confirms, the taker= can wait for the timeout; if it times out, the taker can clawback the tran= saction. > > - This appears to be riskless for the taker. > > - Against a similar attack, Lightning requires channel reserv= es, which means the first hop never gains control of the entire value, whic= h is a basic requirement for private key turnover. > > - On the other hand, the taker has the largest timeout before it = can clawback the funds, so it would wait for a long time, and at any time i= n between the first maker can come online and spend using the hashlock bran= ch. > > - But the taker can just try on the hope it works; it has not= hing to lose. > > - This attack seems to be possible only for the taker to mount. > > Other makers on the route cannot know who the other makers are,= without cooperation of the taker, who is the only one who knows all the ma= kers. > > - On the other hand, the last maker in the route has an outgo= ing HTLC with the smallest timelock, so it is the least-risk and therefore = a maker who notices its outgoing HTLC has a low timeout might want to just = do this anyway even if it is unsure if the taker is offline. > > Every off-chain protocol like this has the livelyness requirement. Each > party must always be watching the chain and be ready to broadcast > something in response. I'm not sure how any of this relates to the > choice of relative vs absolute time locks. Absolute timelocks mean that you can set a timer where you put your node to= sleep without risk of loss of funds (basically, once the absolute timelock= s have resolved, you can forget about CoinSwaps). But I think the ability to spend at any time would be better, and getting 1= 00% online 144 blocks a day, 2016 blocks a retargeting period is becoming m= ore and more feasible. > > You're right that attempting such an move by the taker is riskless, but > its not costless. The taker sets up the entire CoinSwap protocol because > they wanted more privacy; but if the taker broadcasts the Alice contract > transaction and waits for the timeout, then all they've achieved is > spent miner fees, got their own coin back and draw attention to it with > the unusual HTLC script. They've achieved no benefit from what I see, so > they won't do this. Any taker or maker who attempts anything like this > will be spending miner fees. They would be spending miner fees *from the funds being stolen*, thus still= costless. In particular, let us imagine a simple 1-maker swap. * The taker and the maker complete the swap. * The taker now has possession of: * The private key for its incoming HTLC. * The pre-signed contract transaction for its outgoing HTLC. * The taker spends from its incoming HTLC using the private key. * The maker ignores this, because this is just normal operation. * Fees paid for this is not an **additional** cost, because a taker that = wants to put its freshly-private funds into cold storage will do this anywa= y. * The taker gets a fresh, private coin from this incoming HTLC, so it get= s the privacy it paid for. * The taker waits for the incoming-HTLC-spend to confirm. * The taker broadcasts the pre-signed contract transaction, in the hope tha= t the maker is offline. * The fees paid for this are from the contract transaction that the taker= is trying to steal. Even if the theft attempt fails, the taker has already gotten its priva= te money out, and is thus not risking anything. * Semantically, the outgoing HTLC is already "owned" by the maker (the ma= ker has private key to it). * Thus, the taker commits an action that the maker pays fees for! * The maker cannot react except to spend via the hashlock branch. In particular, because the taker-incoming (maker-outgoing) UTXO is alre= ady spent, it cannot retaliate by also broadcasting the contract transactio= n of the taker-incoming (maker-outgoing) HTLC. * The theft succeeds (the timelock passes) because the maker happens to be = offline for that long. * This is "free money" to the taker, who has already gotten what it paid = for --- private money in cold storage --- from the CoinSwap. * Even if the stolen fund reveals the contract, the taker can re-acquire = privacy for the funds it stole for free, by paying for --- wait for it --- = another CoinSwap for its swag. Using an absolute timelock (implemented by a `nLockTime` tx directly off th= e 2-of-2, ***not*** `OP_CHECKLOCKTIMEVERIFY`), plus a Scriptless Script 2p-= ECDSA (again implemented by a tx directly off the 2-of-2) instead of a hash= lock, seems to avoid this, I think, at the cost of reducing the utility of = private key turnover by having a deadline where the private key *has to* be= used. This is because there is no contract transaction that is share-owned by bot= h participants in the swap. Instead there are two distinct transactions with separate ownerships: a tim= eout tx (that is owned by the participant paying for the HTLC/PTLC) and a c= laim tx (that is owned by the participant accepting the HTLC/PTLC). > > - Participants might want to spend from the UTXO to a new address aft= er private key turnover anyway. > > Makers could spend using a low-fee RBF-enabled tx, and when another= request comes in for another swap, try to build a new funding tx with a hi= gher-fee bump. > > > > I don't think this will happen very often. It's spending money on block > space for not much benefit. If the maker ever decides to shut down their > maker they can transfer all their coins in HTLCs to single-sig > transactions exclusively controlled by them, but in normal operation I > doubt it will happen. Accidents can happen (e.g. somebody trips over the power cord of the maker = hardware), so hedging this somewhat might give a useful safety net. > > The attack I describe works because Alice chooses both MA~ and MB~. The > attack is that Alice chooses MA~ to be a very low value (e.g. 1 sat/vb) > and chooses MB~ to be a very high value (e.g. 1000 sat/vb). Then Alice > intentionally sabotages the CoinSwap and forces it to go to the timeout > case, what happens is that Bob's wallet balance falls by much more than > Alice's, because MB~ > MA~. So this is a DOS attack: Alice can waste > Bob's resources without wasting much of her own. Ah, right, that is clearer. > > > =3D=3D EC tweak to reduce one round trip =3D=3D > > > When two parties are agreeing on a 2-of-2 multisig address, they need= to > > > agree on their public keys. We can avoid one round trip by using the = EC > > > tweak trick. > > > When Alice, the taker, downloads the entire offer book for the liquid= ity > > > market, the offers will also contain a EC public key. Alice can tweak > > > this to generate a brand new public key for which the maker knows the > > > private key. This public key will be one of the keys in the 2-of-2 > > > multisig. This feature removes one round trip from the protocol. > > > q =3D EC privkey generated by maker > > > Q =3D q.G =3D EC pubkey published by maker > > > p =3D nonce generated by taker > > > P =3D p.G =3D nonce point calculated by taker > > > R =3D Q + P =3D pubkey used in bitcoin transaction > > > =3D (q + p).G > > > > Whoa whoa whoa whoa. > > All this time I was thinking you were going to use 2p-ECDSA for all 2-o= f-2s. > > In which case, the private key generated by the taker would be sufficie= nt tweak to blind this. > > In 2p-ECDSA, for two participants M =3D m * G; T =3D t * G, the total k= ey is m * t * G =3D m * T =3D t * M. > > Are you going to use `2 2 OP_CHECKMULTISIG` instead of 2p-ECD= SA? > > Note that you cannot usefully hide among Lightning mutual closes, becau= se of the reserve; Lightning mutual closes are very very likely to be spent= in a 1-input (that spends from a 2-of-2 P2WSH), 2-output (that pays to two= P2WPKHs) tx. > > Yes, I intend for 2p-ECDSA to be used eventually, but for the first > version I'll only implement regular multisigs with OP_CHECKMULTISIG. > Once all the other details of this protocol are implemented correctly > and mostly-bug-free then 2p-ECDSA can be added. It can be added in the > protocol steps 0-1, 3-5 and 7-9. Okay, that is clearer. I think 2p-ECDSA should be first priority after getting a decent alpha vers= ion. > This document also doesn't talk about PayJoin-with-CoinSwap, but that > can be added later too. 2p-ECDSA with Scriptless Script potentially gives a lot more privacy than a= ny PayJoin IMO, due simply to the much larger anonymity set, and there are = enough chain-analysis-heuristic-breaking shenanigans we can implement with = plain CoinSwap, I think. Regards, ZmnSCPxj