{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-06-13\n📝 Original message:Hi list,\n\nRecent discussions among LN devs have brought back on the surface concerns\nabout the security of multi-party funded transactions (coinjoins,\ndual-funded LN channels, on-chain DLCs, ...). It turns out there is a\nlow-fruit, naive DoS vector playable against the funding flow of any such\nconstruction due to the lack of existent full-rbf transaction-relay\ntopology on today's p2p network [0] [1]. While it does not consist in a\ndirect loss of funds, if exploited well I think it's annoying enough to\ninflict significant timevalue loss or fee-bumping waste\nto the future providers or distributed swarm of users doing multi-party\nfunded transactions. Of course, it can be fixed one layer above by\nintroducing either fidelity bonds or a reliable centralized coordinator,\nthough at the price of an overhead per-participant ressources cost and loss\nin system openness [1].\n\nFor that reason, I believe it would be beneficial to the flourishing of\nmulti-party funded transactions to fix the Dos vector by seeing a subset of\nthe network running full-rbf and enabling propagation of honest multi-party\ntransactions to the interested miners, replacing potential non-signaling\ndouble-spend from a malicious counterparty. Moving towards that direction,\nI've submitted a small patch against Bitcoin Core enabling it to turn on\nfull-rbf as a policy, still under review [3]. The default setting stays\n**false**, i.e keeping opt-in RBF as a default replacement policy. I've\nstarted to run the patch on a public node at 146.190.224.15.\n\nIf you're a node operator curious to play with full-rbf, feel free to\nconnect to this node or spawn up a toy, public node yourself. There is a\n##uafrbf libera chat if you would like information on the settings or\nlooking for full-rbf friends (though that step could be automated in the\nfuture by setting up a dedicated network bit and reserving a few outbound\nslots for them).\n\nIf you're a mining operator looking to increase your income, you might be\ninterested to experiment with full-rbf as a policy. Indeed, in the future I\nbelieve the multi-party transactions issuers who need full-rbf to secure\ntheir funding flow should connect by default to full-rbf peers. One can\nconjecture that their transactions are likely to be more compelling in\ntheir feerate as their liquidity needs are higher than the simple\ntransaction. For today, I think we have really few standards and bitcoin\nsoftwares relying on multi-party funded transactions [4].\n\nIf you're a Bitcoin user or business and you don't like full-rbf, please\nexpress an opinion on how it might affect your software/operations. I'm\nalways interested to learn more about mempool and transaction-relay\ninteractions with upper-layers and applications and to listen to feedback\nin those areas, and I guess a lot of other Bitcoin researchers/devs too. I\nknow there have been a lot of concerns about full-rbf in the past, however\nI believe the Bitcoin ecosystem has matured a lot since then.\n\nAny mistakes or missing context is my own.\n\nCheers,\nAntoine\n\n[0] For more info about replace-by-fee, see\nhttps://bitcoinops.org/en/topics/replace-by-fee/\n\n[1] For more details about the DoS vector, see\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\n[2] E.g I think it does not affect the Lightning Pool service, as there is\na preliminary step where the participant funds are locked first in a 2-of-2\nwith the coordinator before being committed in the multi-party batch\ntransaction.\n\n[3] https://github.com/bitcoin/bitcoin/pull/25353\n\n[4] E.g DLCs :\nhttps://github.com/discreetlogcontracts/dlcspecs/blob/master/Transactions.md\n; Lightning dual-funded channel :\nhttps://github.com/lightning/bolts/pull/851\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220613/1a047265/attachment.html\u003e"}