From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B032FC013E for ; Sun, 23 Feb 2020 01:29:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id A65F085507 for ; Sun, 23 Feb 2020 01:29:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUM0MNao0NM5 for ; Sun, 23 Feb 2020 01:29:23 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by fraxinus.osuosl.org (Postfix) with ESMTPS id CBC37852D5 for ; Sun, 23 Feb 2020 01:29:22 +0000 (UTC) Date: Sun, 23 Feb 2020 01:29:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1582421360; bh=O+FZwC2eb+eq8rLjq7g54DgUw9xpX+bHxOtl2rk3WUo=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=N974NoEOUXoeGwcgIcwy5edYwLOKc9UwkSEHhLFQ12xTKVZGfbg9MdoSObJOjnBQt 7BHe5a4voFzUX0LsPCPiRuubHZYh6ZkJMh7Q6hJw9HdfafHIV+sVqikb9Zt93PbV+9 F3n8t9Ecd82FHGPatmvZjSkZmxsKALAkdmqkzHIw= To: Antoine Riard , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: 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 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: Sun, 23 Feb 2020 01:29:24 -0000 Ggood morning Antoine, and list, > * nLocktime/nSequence > ... > * weird watermark (LN commitment tx obfuscated commitment number) > ... > LN (cooperative case): I notice your post puts little spotlight on unilateral cases. A thing to note, is that we only use `nSequence` and the weird watermark on= unilateral closes. Even HTLCs only exist on unilateral closes --- on mutual closes we wait for= HTLCs to settle one way or the other before doing the mutual close. If we assume that unilateral closes are rare, then it might be an acceptabl= e risk to lose privacy in that case. Of course, it takes two to tango, and it takes two to make a Lightning chan= nel, so --- In any case, I explored some of the difficulties with unilateral closes as = well: * https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00= 2421.html * https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/00= 2415.html On mutual closes, we should probably set `nLockTime` to the current blockhe= ight + 1 as well. This has greater benefit later in a Taproot world. > Questions: > * Are there any protocol-specific semantic wrt to onchain transactions in= compatibility > between Coinjoin and cooperative LN txn ? A kind of non-equal-value CoinJoin could emulate a Lightning open + close, = but most Lightning channels will have a large number of blocks (thousands o= r 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 CoinJoin. In particular, a LN cooperative close will, in general, have only one input= . A new form of CoinJoin could, instead of using a single transaction, use tw= o, with an entry transaction that spends into an n-of-n of the participants= , and the n-of-n being spent to split the coin back to their owners. But again: a Lightning network channel would have much time with the funds = in a single UTXO before later splitting the funds, This also starts edging closer to CoinJoinXT territory. > * What about RBF-by-default ? Should always be on, even if we do not (yet) have a facility to re-interact= 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 set 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 record= ed on all fullnodes and at least we force surveillors to record this inform= ation themselves. > * Core wallet or any other protocol or even batching algorithms could ado= pt > to this format ? It seems likely. However, it seems to me that we need to as well nail down the details of th= is format. > * Is artificially increasing the number of outputs to mimic Coinjoins txn > acceptable wrt to utxo bloat/fees ? That is indeed an issue. Regards, ZmnSCPxj