Morning Zeeman, > I proposed before to consider splicing as a form of merged closing plus funding, rather than a modification of channel state; in particular we might note that, for compatibility with our existing system, a spliced channel would have to change its short channel ID > and channel ID, so it is arguably a different channel already.
Yes but you may want alias to keep your channel routing-score across splicing, though how to do this is more LN-dev specific. > Emulating LN splices mildly makes ConJoinXT less desirable, however, as the mix takes longer and is more costly. Intuitively, a lot of Coinjoin traffic may be redirected in the future through LN when protocol matures, privacy properties may be better (though need careful analysis). Coinjoins would be only for high-amounts for which security/liquidity isn't offered by LN, and in this case time for increasing privacy is IMO an acceptable tradeoff. > Does not Electrum do RBF by default? Dunno, for more context on RBF and its controversies see https://bitcoincore.org/en/faq/optin_rbf/ (or Optech resources) > 1.5RTT with MuSig Yes right I meaned you don't need to assume latter interactivity if it's a multi-party tx construction you sign multiple RBF versions at same time. Still need to think about privacy-preserving fee bumping wrt to mempool observer > This can be mitigated if all participants contribute equal or nearly-equally to the fees, though that complicates single-funding, and may violate Initiator Pays Principle (the initiator of an action should pay all fees related 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). Yes, but also you want the acceptor to pay for its inputs announced to avoid pouring the spending burden on the initiator only, or doing any free-ride aggregation . > There may be other protocols interested in this as well --- for instance "submarine swaps" and "lightning loops", which are the same thing. Yes good point, specially batched submarine swaps are good candidates, also DLCs (will enquiry on tx pattern of more bitcoin protocol) Le lun. 24 févr. 2020 à 18:36, ZmnSCPxj <zmnsc...@protonmail.com> a écrit : > Good morning Antoine, > > > > > On mutual closes, we should probably set `nLockTime` to the current > blockheight + 1 as well. > > > This has greater benefit later in a Taproot world. > > > > I assume mutual closes would fall under the aforementioned tx > construction 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 > funding, rather than a modification of channel state; in particular we > might note that, for compatibility with our existing system, a spliced > channel would 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 + > close, but most Lightning channels will have a large number of blocks > (thousands 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 CoinJoin. > > > > That's a really acute point, utxo age and spending frequency may be > obvious 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 > somehow. > > > 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 > recognizable as a "submarine swap" or "lightning loop". > https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692.html > Perhaps the frequencies of those operations may hint as to how much > splicing 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 > adoption 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 > first dedicated to the splice-in, and *then* a separate transaction which > actually does the splice-in. > This has a drawback of requiring an extra transaction, which wins us the > facility to continue operation of the channel even while the splice-in > transactions are being confirmed while retaining only one state. > (the latest proposal, I believe, does *not* use this construction, and > instead requires both sides to maintain two sets of states, with one state > being 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 until blockchain load reduces.) > > As it happens, my alternate proposal for CoinJoinXT is similar in that > there are "entry transactions" that introduce coins into the PTG, which are > needed 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 > backouts 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 funds 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-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 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 > money, grumble grumble, flagged RBF is just a node relay policy, grumble > grumble, 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 > install 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 > broadcast them later to obfuscate mempool analysis). > > 1.5RTT with MuSig. > > An issue here is that if not all participants contribute to the fees > equally, then a participant who is paying lower fee or no fee has a mild > incentive 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 the mempool state so you do not have to do all those calculations or > even maintain a mempool, and so on. > This can be mitigated if all participants contribute equal or > nearly-equally to the fees, though that complicates single-funding, and may > violate Initiator Pays Principle (the initiator of an action should pay all > fees related 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 > of this format. > > > > Of course, just curious of people opinions right now but if it's a good > way to solve the described problem, will draft a spec. > > There may be other protocols interested in this as well --- for instance > "submarine swaps" and "lightning loops", which are the same thing. > > Regards, > ZmnSCPxj > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
