From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id C5B71C0177 for ; Mon, 24 Feb 2020 23:36:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id AC89C864F6 for ; Mon, 24 Feb 2020 23:36:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8faYk3sTd1b for ; Mon, 24 Feb 2020 23:36:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by whitealder.osuosl.org (Postfix) with ESMTPS id 31B6885BCA for ; Mon, 24 Feb 2020 23:36:02 +0000 (UTC) Date: Mon, 24 Feb 2020 23:35:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1582587359; bh=ZEFQWpnbhM3Z4pTesudRsrk+1VrLGmc71J6Z/Vd4iz4=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=ZC+2u6ztN7hZpCpD5opC53/SLU91TTEh74PRrEzJ4l223oRDzFDINbOhSlReY1uKG BfLr97p0Evg+qckXpRye1Ee+L06mtGUH81/5gl9pL33K93qp7/vrU+Ulg/ChWd7uuR LjWjJbR/pHu/hB+eh+oDhIDGJ0kY/Ob8vCyzQoEY= To: Antoine Riard From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <2-MilNWxNU5sCVK81AtIN7LhLButGQNbxgkr50rzsCvd5FqrD3VHBKCWjlxeFXYbKzC1XX5jm8NpzQUR95TGyupYqL6ggL8rPObGYC0AYWE=@protonmail.com> In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] LN & Coinjoin, a Great Tx Format Wedding 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: Mon, 24 Feb 2020 23:36:04 -0000 Good morning Antoine, > > On mutual closes, we should probably set `nLockTime` to the current blo= ckheight + 1 as well. > > This has greater benefit later in a Taproot world. > > I assume mutual closes would fall under the aforementioned tx constructio= n proposal, so a closing may be a batch to fund other channels or > splice existent ones. Ah, that is indeed of great interest. I proposed before to consider splicing as a form of merged closing plus fun= ding, rather than a modification of channel state; in particular we might n= ote that, for compatibility with our existing system, a spliced channel wou= ld have to change its short channel ID and channel ID, so it is arguably a = different channel already. > > > A kind of non-equal-value CoinJoin could emulate a Lightning open + clo= se, but most Lightning channels will have a large number of blocks (thousan= ds or tens of thousands) between the open and the close; it seems unlikely = that a short-term channel will exist > that matches the non-equal-value Coi= nJoin. > > That's a really acute point, utxo age and spending frequency may be obvio= us protocol leaks. Yes; I am curious how JoinMarket reconciles how makers mix their coins vs. = how takers do; presumably the tumbler.py emulates the behavior of a maker s= omehow. > Splicing may help there because a LN node would do multiple chain writes = during channel lifecycle for liquidity reasons but it's > near-impossible to predict its frequency without deployment. Long ago, I proposed an alternative to splicing, which would today be recog= nizable as a "submarine swap" or "lightning loop". https://lists.linuxfound= ation.org/pipermail/lightning-dev/2017-May/000692.html Perhaps the frequencies of those operations may hint as to how much splicin= g would occur in practice in the future. > Even with this, I do fear an analysis gap between Coinjoin spending delta= and LN ones. A way to circumvent this would be for CoinjoinXT to timelock = its PTG > transactions to mimick actively-spliced LN channels. That's where adoptio= n of a common format by other onchain transactions than LN ones would help = a lot. Well, one way to implement splice-in would be to have an output that is fir= st dedicated to the splice-in, and *then* a separate transaction which actu= ally does the splice-in. This has a drawback of requiring an extra transaction, which wins us the fa= cility to continue operation of the channel even while the splice-in transa= ctions are being confirmed while retaining only one state. (the latest proposal, I believe, does *not* use this construction, and inst= ead requires both sides to maintain two sets of states, with one state bein= g a fallback in case the splice-in gets double spent; but in times of high = blockchain load this can lead to the channel having a two sets of states un= til blockchain load reduces.) As it happens, my alternate proposal for CoinJoinXT is similar in that ther= e are "entry transactions" that introduce coins into the PTG, which are nee= ded to prevent participants from double-spending while the mix is on-going.= https://zmnscpxj.github.io/bitcoin/coinjoinxt.html Note the proposal differs from the original by waxwing, which requires back= outs at each intermediate output, and the entry transactions are potential = watermarks on the CoinJoinXT protocol as well. A Chaumian CoinJoinXT cannot use backouts at each intermediate output since= no participant should have any knowledge of how much each participant has = contributed to each intermediate output, they only know they put so many fu= nds in and so should get so many funds out. Emulating LN splices mildly makes ConJoinXT less desirable, however, as the= mix takes longer and is more costly. > > > Should always be on, even if we do not (yet) have a facility to re-inte= ract to bump fees higher. > > While it is true that a surveillor can determine that a transaction has= in fact been replaced (by observing the mempool) and thus eliminate the se= t of transactions that arose from protocols that mark RBF but do not (yet) = have a facility to bump fees higher, this > information is not permanently = recorded on all fullnodes and at least we force surveillors to record this = information themselves. > > Yes but if you do this for Core and given some merchants are refusing RBF= transactions for onchain payments, people are going to complain... Grumble grumble, all unconfirmed transaction are RBF because miners like mo= ney, grumble grumble, flagged RBF is just a node relay policy, grumble grum= ble, some humans sometimes, grumble grumble.... Does not Electrum do RBF by default? Unless I have a lower-level agent that always enables RBF option when I ins= tall new Electrums, hmmm, maybe I should check first. > Also see footnote on spurious-RBF about not-having facility to bump fees = higher (you can sign multiple RBF transactions in 1-RTT and agree to broadc= ast them later to obfuscate mempool analysis). 1.5RTT with MuSig. An issue here is that if not all participants contribute to the fees equall= y, then a participant who is paying lower fee or no fee has a mild incentiv= e to just broadcast the highest-fee version and be done with it: forget the= other transactions and just aim for the highest fee immediately, ignore th= e mempool state so you do not have to do all those calculations or even mai= ntain a mempool, and so on. This can be mitigated if all participants contribute equal or nearly-equall= y to the fees, though that complicates single-funding, and may violate Init= iator Pays Principle (the initiator of an action should pay all fees relate= d to the action, as otherwise it may be possible to create a null operation= that the acceptor of the action ends up paying fees for, which can be used= as a financial attack to drain acceptors). > > However, it seems to me that we need to as well nail down the details o= f this format. > > Of course, just curious of people opinions right now but if it's a good w= ay to solve the described problem, will draft a spec. There may be other protocols interested in this as well --- for instance "s= ubmarine swaps" and "lightning loops", which are the same thing. Regards, ZmnSCPxj