{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-07-04\n📝 Original message:\nMatt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e Thanks!\n\u003e\n\u003e On 6/29/21 01:34, Rusty Russell wrote:\n\u003e\u003e Hi all!\n\u003e\u003e \n\u003e\u003e          John Carvalo recently pointed out that not every implementation\n\u003e\u003e accepts zero-conf channels, but they are useful.  Roasbeef also recently\n\u003e\u003e noted that they're not spec'd.\n\u003e\u003e \n\u003e\u003e How do you all do it?  Here's a strawman proposal:\n\u003e\u003e \n\u003e\u003e 1. Assign a new feature bit \"I accept zeroconf channels\".\n\u003e\u003e 2. If both negotiate this, you can send update_add_htlc (etc) *before*\n\u003e\u003e     funding_locked without the peer getting upset.\n\u003e\n\u003e Does it make sense to negotiate this per-direction in the channel init message(s)? There's a pretty different threat \n\u003e model between someone spending a dual-funded or push_msat balance vs someone spending a classic channel-funding balance.\n\nchannel_types fixes this :)\n\nUntil then, I'd say keep it simple.  I would think that c-lightning will\nimplement the \"don't route from non-locked-in channels\" and always\nadvertize this option.  That means we're always offering zero-conf\nchannels, but that seems harmless:\n\n- Risks for funder is that channel never confirms, but it probably ignores\n  the risk because it can close onchain (annoying, and fee-heavy, but not\n  loss of funds caused by peer).\n\n- Risks for fundee (or DF channels where peer contributes any funds) is\n  that funder doublespends, so HTLCs must not be routed out to others\n  (unless you have other reason to trust peer).\n\nCheers,\nRusty."}