19:06:11 <cdecker> #startmeeting
19:06:11 <lightningbot> Meeting started Mon Jan 20 19:06:11 2020 UTC.  The chair is cdecker. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:06:11 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:06:15 <lndbot> <johanth> t-bast: I haven’t heard that they will
19:07:26 <cdecker> So I wrote up a short agenda (~5 prs to ack/nack) followed by a bit more long-term outlooks to discuss so we can make these meeting a bit more constructive
19:07:49 <cdecker> #link https://paper.dropbox.com/doc/Lightning-Spec-Meeting-20200120--Asyn1LqwS5eymCtfthi~KR01Ag-SA160p27VepiVZcnbKcZE
19:08:18 <roasbeef> cdecker: so saw the paper thing, what're the advtanges of that over using the existing labeling system? given that everyone is already on github, or we could make an issue to aggregrate the labels perhaps that's used each week
19:08:31 <cdecker> Today we have 6 PRs, 1 Issue that t-bast has asked to discuss and finally two outlooks for long term
19:08:41 <t-bast> hey roasbeef!
19:09:01 <cdecker> roasbeef: the main upside is that we don't accidentally carry over things from the last meeting and end up clumping everything together
19:09:20 <cdecker> But we can certainly judge at the end whether it was the improvement I hoped for, or not
19:09:41 <cdecker> The major upside is that we can also add things that are not PRs or Issues and discuss things more longer term
19:10:00 <cdecker> Since we have a quorum with two people from LL, shall we get started with the PRs?
19:10:15 <t-bast> cdecker: SGTM
19:10:30 <cdecker> #topic Restrict data_loss_protect to init context #726
19:10:38 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/726
19:11:12 <cdecker> It seems we discovered a number of issues with the "just advertise everything everywhere" idea
19:11:42 <cdecker> For this specific issue we are only interested in `data_loss_protect` being limited to `init` or not
19:12:26 <t-bast> I think that what underpins this is: what should be the rationale for including a feature in `init`, `node_ann`, elsewhere
19:12:26 <roasbeef> cdecker: yeh if we don't wanna carry things over, can have a weekly master tracking issue perhaps
19:12:37 <cdecker> roasbeef brings up a good point that with the static channel backup it makes sense to prefer nodes that support `data_loss_protect`, and announcing it in the `node_announcement` would allow this preferential treatment
19:13:08 <rusty> cdecker: Agreed; I think this fix is wrong.  We really do want to broadcast this.  But perhaps that channel features that should gate whether you can route, not nf.
19:13:10 <cdecker> roasbeef: sure, we can replace the paper thing with issues, no problem, though then only the OP can edit
19:13:28 <roasbeef> i don't think we need very strong rules for certain classes, as there're still exceptions even though the unification made certain classes more explicit
19:13:53 <roasbeef> (re feature bit locations)
19:13:55 <t-bast> I really think of node_announcement feature as: "hey this is everything you need to know about me" so mostly all features should go in there
19:14:05 <rusty> t-bast: agreed.
19:14:07 <roasbeef> t-bast: yeh not like we're short on space either lol
19:14:15 <t-bast> :D
19:14:24 <ariard_> the issue if we come with new nodes features, non-upgraded nodes won't be able to dissociate between packet processing and peer connection ones
19:14:38 <ariard_> and so not use these peers to route
19:14:38 <roasbeef> seems like RL wants to implement some very strict rules for feature bit placement, while generally things can be mnore lax
19:14:40 <cdecker> Yep, though some things might be weird, i.e., mandatory flags in th node_announcement that we don't understand
19:15:19 <t-bast> ariard: in my opinion that's because we shouldn't be looking at node_announcement features (vertices in the graph) but rather channel_announcement/update features (edges)
19:15:23 <rusty> ariard_: indeed, whch is why we'd advertize routing features per-channel.  Of course, we have the problem that channel_announcements can't currently be replaced, so you can't "upgrade" featuers on a channel.
19:15:51 <roasbeef> yeh for anything routing related, the channels are the go to typically, for connection level, encryption or channel creation aspects lookin the node ann
19:16:07 <ariard_> rusty: hmm so the fix would be to context packet processing in channel_features and allow replacement of them?
19:16:56 <rusty> ariard_: well, we don't have any yet, so not sure when we'll need replacement.  It may be the first ones are completely static?
19:17:18 <cdecker> I think the issue at hand is mostly that we end up in strange situations if we announce even features (i.e., mandatory if you want to talk to the node), where really odd ones suffice
19:17:24 <t-bast> I agree with Rusty there, I don't see yet a case where we really need to upgrade a channel's features
19:17:40 <roasbeef> upgrade as in?
19:17:50 <cdecker> we might have different thresholds for various placements (required in init, optional in node_announcement)
19:18:00 <t-bast> cdecker: but if you only look at channel feature bits when you're choosing your route, nodes are free to do whatever they want in their node_announcement, right?
19:18:15 <rusty> roasbeef: some new channel magic causes us to want to upgrade channel features on the fly...
19:18:31 <ariard_> cdecker: yeah if we keep new features optional in node_announcement, that would work to let you find peers your want in the network
19:18:37 <cdecker> t-bast: if for example I no longer process legacy onion payloads that'd be an even bit in the node_announcement since otherwise we can't talk
19:18:57 <cdecker> That'd be an example of "if you don't understand this, don't talk to me"
19:19:32 <t-bast> cdecker: but then wouldn't you also update all your channels with that feature bit change (which would require feature bits in channel_update)?
19:20:14 <rusty> t-bast: worse, renewing would require negotiating with your peer who can't know your feature preferences  Yuck...
19:20:24 <roasbeef> t-bast: imo the node ann is sufficient in that case, during path finding we look at the node ann to see if a node can support w/e new features that my modify our payload or if we can traverse that node
19:20:26 <cdecker> That's a possibility, but weird: "I don't understand X, so if you talk to me through A, B, C, or D, you can't"
19:20:37 <cdecker> Seems semantically weird
19:20:54 <t-bast> yeah this ends up being very messy
19:21:06 <rusty> OK, I think we need to add N- and N+ to the table (i.e. advertize in node announcement, but always do so as odd).
19:21:22 <rusty> In init you would use the even bit.
19:21:33 <rusty> (If you didn't want to support backwards compat)
19:21:57 <cdecker> So we add two variants: N- and N+ for optional/mandatory possible in the node_announcement?
19:22:20 <rusty> Yes.  I foresaw this for channel announcements, not node announcements, sorry.
19:22:31 <t-bast> We can also embrace the fact that setting an even feature bit in your node_announcement may exclude you from legacy nodes' path-finding
19:22:39 <cdecker> Anyway, we can probably bike-shed this to death, let's look at the very restricted case at hand (data_loss_protect in init only)
19:22:43 <t-bast> And let you decide
19:23:11 <t-bast> For the current PR, I'd then say to keep the feature as `IN`
19:23:16 <cdecker> For me it's a NACK as long as data_loss_protect is flagged as optional
19:23:24 <rusty> (To some extent this is less critical than channel_announcement features bits, which *have* to match on both sides so signatures are valid).
19:23:50 <t-bast> `IN-`
19:23:50 <roasbeef> cdecker: agreed, should be in node_ann so nodes can seek our other nodes that have a better ability to let them recover their funds
19:23:56 <rusty> I will respond on PR, but I think this is an N-.
19:24:36 <ariard_> I'm fine with IN-, it solves the issue to seek preferential peers
19:24:41 <cdecker> Great, so everybody happy with nacking this one, and postpone the discussion on semantics for N-/N+ to GH?
19:24:49 <t-bast> SGTM
19:24:49 <cdecker> Great, thanks ariard_
19:25:00 <t-bast> thanks for the discussion this triggered ariard ;)
19:25:16 <cdecker> #agreed cdecker to close #726 with a brief explanation
19:25:24 <cdecker> Next one ^^
19:25:32 <cdecker> #topic 09+11: require transitive feature dependencies #719
19:25:40 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/719
19:26:23 <cdecker> It seems we have ACKs from ACINQ and LL, with agreement from the last time from c-lightning
19:27:00 <cdecker> We just had a minor rebase issue where lines got mixed up last time, so this should be ready now
19:27:23 <rusty> Like the idea, assume others have bikeshedded the details already :)
19:27:31 <cdecker> Are there any last minute comments regarding the requirement for transitive features?
19:28:07 <t-bast> nope, lgtm
19:28:08 <cdecker> rusty: yeah, it just makes a couple of dependencies among features more evident, no real changes to the behavior if I'm not mistaken
19:28:10 <ariard_> nope
19:28:13 <roasbeef> nope, we've implemented it already
19:28:19 <cdecker> Great ^^
19:28:20 <t-bast> already on our master too :D
19:28:32 <cdecker> #agreed cdecker to merge #719
19:28:43 <cdecker> #topic Specify that resolution of amount is msat #700
19:28:51 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/700
19:29:45 <cdecker> Just a minor clarification resulting from us having 11 decimal places, but SI modifiers being in increments in 3 orders of magnitude
19:30:17 <t-bast> Since the OP mentions libraries that didn't do this correctly, this clarification feels needed
19:30:30 <cdecker> We have acks from ACINQ and c-lightning, any objections to this clarification?
19:30:34 <rusty> Yep.  Wording is a bit weird: I would suggest "last digit must be zero".
19:30:48 <cdecker> Yes, libraries getting this wrong is kind of nasty
19:30:50 <rusty> (Matching the line above)
19:31:17 <cdecker> Ok, rusty would you like to rephrase that or shall I?
19:31:47 <rusty> Happy for you to... but agreed it should be specified.
19:32:24 <t-bast> I believe the OP has moved on to other projects, so maybe we'll need to take over the PR
19:32:51 <cdecker> I just spoke to sword_smith last week when Elizabeth was in town :-)
19:33:11 <cdecker> #agreed cdecker to rephrase #700 to match the previous line and merge after acks on Github
19:33:24 <cdecker> #topic Add bolt11 test vector with amount in `p` units #699
19:33:29 <t-bast> cdecker: oh great, perfect then
19:33:33 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/699
19:34:06 <cdecker> Now, this one feels a bit strange, since it adds an example of how it works, but doesn't showcase the non-working case which is the interesting thing here
19:34:46 <cdecker> imho this additional test-vector doesn't add anything new. More interesting would have been to show a 1 pico-bitcoin invoice failing
19:34:56 <t-bast> good point, we could have a test vector for in invalid invoice
19:35:07 <rusty> cdecker: Agreed.  But this should be applied, I should add some invalid invoice tests.
19:35:14 <rusty> (We had one library which didn't check signatures!)
19:35:37 <rusty> Actually, Imight as well fix this example too.
19:35:40 <roasbeef> there's also that weird bech32 quirk w/ the q's
19:35:43 <rusty> (Wrong key was used).
19:36:26 <t-bast> roasbeef: what do you mean? the extension attack?
19:36:33 <cdecker> rusty: would you like to adopt the PR and add some failing examples?
19:36:36 <rusty> #action rusty to clean up test vector (using correct privkey) and also add some negative tests in another PR.
19:36:36 * niftynei will brb
19:36:49 <cdecker> Great, thanks rusty
19:37:20 <cdecker> So it seems this PR needs some additional work, and we can move on to the next topic.
19:37:30 <cdecker> Unless there are some more comments related to this one?
19:37:40 <t-bast> Nope, that sounds good!
19:37:52 <cdecker> #topic BOLT 1: Define custom message type range #705
19:38:04 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/705
19:38:49 <cdecker> Given we already have a couple of experimental features being implemented using the TLVs it seems only logical to add a range that can be self-assigned by experimenters
19:39:06 <roasbeef> this is about messages and not the onion right?
19:39:12 <t-bast> roasbeef: yes
19:39:14 <roasbeef> iirc we already have a cut out range in teh onion
19:39:20 <t-bast> We already have the same mechanism for onion tlvs
19:39:21 <cdecker> Custom types are already used by WhatSat and Noise for example, and keysend
19:39:26 <t-bast> I really mimicked it for messages
19:39:42 <roasbeef> cool, should prob start a running wiki entry just so we can track all the experiemtns going on, and for ppl to glance at to see if they can avoid an early collision
19:39:42 <cdecker> Oh, I must have missed the onion one, sorry about that
19:39:52 <ariard_> t-bast: on bech32 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017443.html
19:40:00 <roasbeef> this sgtm though
19:40:10 <cdecker> roasbeef: that'd be really useful, I read through joost's code to figure out the types he was using
19:40:34 <cdecker> Ok, so I'm counting ACKs from t-bast, roasbeef, and mine
19:40:37 <t-bast> ariard: ok thx, are there concerns for our use of Bech32 for invoices? Since we have a signature on top do we need to do anything?
19:41:29 <cdecker> Sounds like we have quorum, unless there are more comments?
19:42:06 <cdecker> #action cdecker to merge #705
19:42:25 <cdecker> And finally the last PR for today: #697
19:42:32 <cdecker> #topic BOLT-04: modify Sphinx packet construction to use starting random bytes#697
19:42:40 <t-bast> And a good one for the finish line!
19:42:40 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/697#
19:43:02 <cdecker> I think we've all implemented some variant of this already
19:43:08 <roasbeef> so this'll ship in lnd 0.9 (dropping soon), confirmed that eclair+lnd match up
19:43:29 <roasbeef> mhmm, in the end we can all do w/e we want as long as they're ranodm, but nice to have the spec direct the impl with a single safe route and updated test vectors
19:43:41 * niftynei has returned
19:43:47 <t-bast> the updated test vector worked for both eclair and lnd, did someone c-lightning side had time to validate them?
19:43:50 <cdecker> Yeah, I have a variant implemented, not yet with the pad-key, but should be no problem
19:44:03 <t-bast> great
19:44:10 <ariard_> t-bast: don't think so, but need to verify, signature doesn't protect if invoices decodes to wrong data
19:44:21 <cdecker> I can implement and verify this week, would that work?
19:44:43 <t-bast> cdecker: sgtm
19:45:04 <cdecker> #action cdecker to implement updated padding and merge #697 if test-vectors pass
19:45:37 <cdecker> Excellent. That concludes the round of PRs, let's move on to discussing the open issue #728
19:45:46 <cdecker> #topic Stuck channels because of small fee increase#728
19:45:54 <cdecker> #link https://github.com/lightningnetwork/lightning-rfc/issues/728#
19:46:10 <t-bast> I'll let you read it, it's probably something you've already thought about
19:46:14 <cdecker> t-bast would you like to give a short introduction to the issue you have uncovered?
19:46:35 <t-bast> I think reading the issue should be the most accurate way of introducing it :)
19:46:46 <t-bast> I tried to make it not too long
19:47:57 <cdecker> It's very concise, and I think the issue is interesting. Thanks for including the fee-level changes scenario, otherwise I would have dismissed it as not being possible with us since we don't support push_msat
19:48:21 <roasbeef> iirc we do some upfront validation to avoid creating channels like this, but it is still the case that a channel can enter this particualr state post creation
19:49:06 <rusty> The original proposal was that fees get gouged out of Bob in this corner case, that being better than stuck channels.  But it was decided to make it illegal instead, resulting in this corner case.
19:49:08 <cdecker> Especially with feerates changing
19:49:08 <t-bast> yeah that's why it's painful, I've seen this happen to real-world channels
19:49:21 <roasbeef> there're also some related edge cases w.r.t the handling of the reserve and fees
19:49:57 <t-bast> I'm wondering if you think that it's really unsafe for Alice to allow a single HTLC through in that case?
19:50:01 <cdecker> Wouldn't it be possible to move out of this situation by doing sub-dust, i.e., pruned HTLCs?
19:50:13 <t-bast> cdecker: yes that's one solution
19:50:54 <roasbeef> btw the periods instead of commas in the issue kinda threw me off ;)
19:51:10 <cdecker> They'd be tiny transactions that go nowhere but you can unilaterally solve this by dropping tiny payments at Alice
19:51:18 <t-bast> roasbeef: xD
19:51:34 <rusty> t-bast: not sure what that code would look like "I'm going to let non-funder add 1 new htlc iff the resulting feerate is not insanely low"?
19:51:34 <roasbeef> to double check...it's a 150 sat channel not 150k sat? :p
19:51:54 <t-bast> roasbeef: 150k sat in the example
19:52:52 <t-bast> rusty: that would rather be: in the check where we currently reject, if unpruned htlcs.count <= 1 then I let this one go through
19:52:58 <niftynei> (cdecker: we do support push_msat as of https://github.com/ElementsProject/lightning/pull/3369)
19:52:58 <cdecker> 150 sat would mean the entire channel is dust xD
19:53:21 <roasbeef> lol yeh just making sure....
19:53:24 <cdecker> Oh no, why???
19:53:31 <t-bast> do I really need to check the feerate? Since the estimation is supposed to be very conservative, the feerate we chose should absorb the 20% weight increase without hitting the timeout before on-chain confirmation, shouldn't it?
19:53:31 <rusty> t-bast: ah, so *always* allow a single HTLC, even if fee cannot be paid?
19:54:01 <t-bast> rusty: exactly, because it's only a 20% weight increase (worst case)
19:54:36 * BlueMatt *waves* why are y'all here on a holiday, doesn't the world run on 'murican dates? :p
19:54:39 <t-bast> cdecker: I did a push_msat to c-lightning master to test the scenario, and it worked :)
19:54:45 * rusty is trying to remember if we let fees eat into reserve...
19:54:47 <niftynei> cdecker, so basically pushing alice enough msats to get the channel moving again
19:55:15 * BlueMatt notes that we can just remove update_fee and move on instead of trying to fix it :p
19:55:17 <cdecker> Yep, I don't see why Bob would do that, but it is a unilateral change
19:55:24 <t-bast> rusty: I don't think we currently do, but maybe we could there...or maybe it's a riskier change
19:55:46 <cdecker> BlueMatt: this is less about fees than it look like, we get the same issue if we're close to the reserve limit
19:56:29 <ariard_> assuming the conservative feerate would absorb the 20% weight just make confirmation riskier in case of rapid mempool min fee rate increases
19:56:34 <BlueMatt> cdecker: ah, maybe I'm missing the point. I cant say I dug into it enough...but we certainly dont have any cases where non-update_fee can break a channel, or my fuzzers would have found it
19:56:40 <roasbeef> it's less about update_fee and mroe about weirdness and edge cases w.r.t initiator paying and the interaction w/ the reserve
19:56:51 <BlueMatt> (but they dont cover update_fee cause I *know* that can break it)
19:57:09 <cdecker> Ok, seems to me like there's some more brainstorming and checking necessary before we get a good solution. Shall we let it cook for a while and revisit next week?
19:57:48 <t-bast> cdecker: SGTM, let's have people look at this when they have time and we can share thoughts next time or on github
19:58:02 <rusty> t-bast: So, modification would be BOLT 2 to modify " receiving an `amount_msat` that the sending node cannot afford at the current `feerate_per_kw` (while maintaining its channel reserve):
19:58:02 <rusty> - SHOULD fail the channel." to carve out the single-HLTC case.,  Same on sender requirements?
19:58:12 <rusty> t-bast: seems to need a feature bit :(
19:58:26 <cdecker> Great, as always: comments and discussions on GH are welcome and we can hash out the details in the next meeting
19:58:30 <cdecker> Sounds good?
19:59:07 <t-bast> rusty: in that case it's not really the sending node that can't afford it, it's the opposite (when sending node is fundee)
19:59:34 <t-bast> I'm not really sure this is well covered in Bolt 2, but I'll dig into it and share on the issue
19:59:43 <rusty> t-bast: there's a requirement that you don't send such a thing, and a requirement that you don't accept it.  Both need modification.
19:59:59 <t-bast> rusty: are you sure they're not for the case where sender is funder only?
20:00:04 <lndbot> <johanth> With MPP you can send multiple dust HTLCs to work around it :p
20:00:20 <rusty> t-bast: ah, though you're right, there's no requirement specified on non-funder.  There should be :(
20:00:54 <t-bast> rusty: that's what got me confused, I'll try to draft something
20:01:06 <ariard_> but using MPP to workaround mean you still have stuck capacity you can't use anymore
20:01:10 <t-bast> johanth: thinking outside the box ;)
20:01:34 <cdecker> #action everybody to brainstorm the issue on Github and come up with potential solutions for the next meeting
20:01:42 <t-bast> ACK
20:01:50 <rusty> Well, an implementation could refuse to allow any non-dust HTLCs and really simplify their code :)
20:02:09 <cdecker> ariard_: Alice can't send anything, so there's little point in unsticking her, but Bob can use MPP to unstuck the channel and route through Alice which works
20:02:33 <cdecker> #topic Current status of the dual funding proposal
20:02:56 <niftynei> ok so
20:03:12 <cdecker> So this is the part which I was really hoping to get to, a bit more long-term planning and status updates from people that have been working on parts of the spec that are really complicated
20:03:45 <cdecker> niftynei was so kind to volunteer to give us a quick update on her work on dual-funding and all the corner cases that that brings with it
20:04:12 <cdecker> Sorry for interrupting you niftynei :-)
20:04:16 <ariard_> cdecker: ah gotcha, you can route multiple MPP through same channel but tho you may hit the max_htlc limit
20:04:30 <niftynei> np cdecker!
20:04:55 <niftynei> here's my update on the dual funding. there's an active PR of an implementation of the dual-funding proposal up for c-lightning. one thing it's missing currently is the flow for RBF
20:05:36 <niftynei> which is to say that there might be changes to the proposed RFC draft for that section still
20:05:44 <niftynei> if you're curious at looking at the PR, it's here https://github.com/ElementsProject/lightning/pull/3418
20:06:12 <niftynei> one thing that i've been trying to design for, but haven't actually implemented yet, is the ability for nodes to batch opens together
20:06:31 <roasbeef> occured to me the other week that if channel closing is improved to support multi-channel close (more than one input), then a distinct dual f unding flow is less critical, assuming the impls support multiple channels to a node, but then even w/o that the only downside is more than 1 txn to close them
20:06:48 <niftynei> this helps increase the anonymity set for an open channel transaction, and reduces the certainty that any shared inputs to a funding tx are the node's that provides them
20:07:45 <cdecker> niftynei: that shared open is coordinated by one node that is in common to all channels or would that be some other group of nodes collaborating somehow differently?
20:07:51 <t-bast> +1 on batching
20:08:26 <t-bast> that may end up being very similar to coinjoin mechanisms, doesn't it?
20:08:27 <niftynei> roasbeef, do you have a link to the close channel proposal? i'm not really familiar with channel close considerations
20:08:31 <niftynei> t-bast, yes
20:08:31 <roasbeef> isn't batching already also possible as is today? given that you just send over an out point
20:08:34 <niftynei> to an extent
20:08:36 <cdecker> roasbeef: could we generalize it to have a BYOI (bring your own inputs) so we remove that limitation?
20:08:39 <roasbeef> niftynei: doesn't exist yet, just an half baked idea lol
20:08:46 <niftynei> right, gotcha
20:09:03 <roasbeef> cdecker: i think so, so then it would be just two nodes jointly crafting a transaction, which is independently useful for many other things
20:09:23 <cdecker> Yep, and it could work for funding and close the same way imho
20:09:57 <cdecker> Although it sounds like it'd get us into meta-protocol territory xD
20:10:35 <niftynei> right, so ideally either party in a dual funding transaction could include another party
20:10:44 <ariard_> and we could reuse same fee logic for splicing
20:10:55 <niftynei> i.e. either the opener or the 'accepter' (after the accept_channel message they respond with)
20:11:00 <niftynei> *named after
20:11:51 <niftynei> one big difference between a channel open and a coin-join is that coin-joins to some extent (afaict) have a central coordination server
20:11:54 <cdecker> Sounds interesting, though we probably want to limit the number of rounds you can propose more stuff to bolt onto a transaction :-)
20:12:20 <niftynei> the current proposal uses a limit to the number of inputs as a proxy for that
20:12:21 <roasbeef> idk seems difficult to coordinate all that without some elevated party, also stepping back seems liek we're trying to do everything in this current dual funding proposal which is making it progressively more complex
20:12:58 <ariard_> cdecker: we can also have a active/passive party, where only the active one can keep adding inputs/outputs from other peer to avoid dependencies
20:13:24 <niftynei> whereas a dual-funded tx doesn't have a central coordinator. this makes it harder/impossible to do the shielded inputs that recent coin-join protocols have proposed
20:13:39 <cdecker> That's a good point. niftynei is there a good way to make these changes incremental, i.e., is there a minimal set we can implement and test now, and then make more changes as needed later?
20:14:00 <niftynei> currently we avoid dependencies by failing/rejecting the open if a peer sends an input you've already seen
20:14:49 <niftynei> have you taken a look at the current proposal?
20:15:15 <cdecker> Not in detail, no :blushes:
20:15:57 <niftynei> i'm open to suggestions for simplification, i like to think we've hit the most simplified possible while still allowing for batched opens
20:16:28 <niftynei> having batched opens is very nice because it mitigates (minorly) the sharing of your current utxos
20:16:52 <cdecker> Ok, so I misunderstood, sorry. What you're saying is that the PR is the minimal possible change that still gives us the desired flexibility, gotcha
20:17:07 <t-bast> I agree, and having batched opens could pave the way for batched close as well, couldn't it?
20:17:25 <niftynei> yes, i took roasbeef's comment to be a desire to cut functionality, which would mean removing the batchedness
20:17:45 <niftynei> that'd definitely be the easiest way to simplify the proposal
20:17:47 <ariard_> I think so, you can reuse the same set of transaction construction message like funnding_add_input/output
20:17:51 <cdecker> I'll read up on the commits and be ready next time :-)
20:18:08 <t-bast> Do you think cutting batchedness for a first version still makes it easy to add later? Or is it much simpler if we do it from the start?
20:18:18 <niftynei> i don't think it's possible to add it later
20:18:21 <t-bast> ok
20:18:40 <t-bast> so even if it makes the proposal more complex, it's probably worth having
20:18:41 <roasbeef> well it was made from an outside perspective, I haven't been following it super closely but just from my PoV i've seen the scope expand over time
20:18:47 <ariard_> though if you do batchedness, we should also consider CPFP to avoid one party no-resigning and stucking everything
20:18:48 <roasbeef> could be wrong tho
20:19:15 <niftynei> anyway, one thing i could use some help with is dealing with fees in the batched open case
20:19:36 <niftynei> i wrote about it in this channel earlier, but it'll probably be easier to digest via a mailing list post
20:19:55 <cdecker> Hm, the batch funding seems a bit distinct though, would it be possible to treat that as a separate dependency for dual-funding?
20:20:12 <cdecker> I.e., merge batch funding first and then build dual funding on top?
20:20:41 <niftynei> part of the work i'm doing this week is updating the spec protocol tests framework rusty's been working on to include dual-funding tesets
20:21:16 <niftynei> you can do batch funding already with c-lightning
20:21:42 <cdecker> Great, I think we all need some more time with your PR to get more familiar with the changes.
20:22:01 <niftynei> the biggest change for dual-funding (and i'd assume a batched close) is socializing inputs/outputs for transaction construction
20:22:27 <niftynei> ok great. i think i'm way over time.
20:22:41 <cdecker> You mean how willing nodes are to share their inputs with peers?
20:23:04 <t-bast> Because there's a risk a node is faking a channel open to discover your inputs?
20:23:09 <cdecker> No problem niftynei, let's move the discussion to GH then ^^
20:23:28 <niftynei> yes exactly. though, i think i can make a case that your open utxo set isn't as precious for a lightning node as it is for a bitcoin wallet
20:23:59 <t-bast> That's true, as long as you want to use them to get into lightning channels, they'll end up mixed once inside LN
20:24:25 <t-bast> but that means wallet developers need to take this into account, and seggregate as much as possible from UTXO used for direct bitcoin txs
20:24:29 <roasbeef> the other consideration for light clients is that they can't easily verify the inputs
20:24:44 <niftynei> because they're not the sum of your total wallet -- there's also invisible funds already in channels
20:24:51 <roasbeef> full node backend nodes can just check their utxo set
20:24:53 <niftynei> 'invisible' of course depending on whether it's private or not
20:25:00 <cdecker> #action everyone to take a look at "dual-funding, the monster" ElementsProject/lightning#3418 :-)
20:25:09 <niftynei> roasbeef, yes. we need the sig changes that are proposed in taproot (i believe)
20:25:27 <cdecker> t-bast would it be ok if we move the trampoline discussion to the next meeting?
20:25:40 <t-bast> cdecker: sure, no problem, we've already done a lot!
20:25:49 <cdecker> (it's getting kinda late, and I'd like to give it enoough room to be discussed in full)
20:26:00 <cdecker> Great, thanks
20:26:11 <roasbeef> niftynei: signing all input values? i don't think that's sufficient, values may be right but an input is already spent making the entire transaction invalid
20:26:27 <roasbeef> lol "the monster"
20:26:29 <niftynei> to make it light-client compatible (ie including the output script's format as a member of the signed hash)
20:26:41 <t-bast> roasbeef: that sounds like a nightmare-ish FSM to build
20:27:20 <roasbeef> t-bast: yeh...
20:27:55 <cdecker> seems to me like we should take a hard look at the work being done in coinjoin land to get our coordinated tx building skills up to par
20:28:02 <niftynei> oh you're talking about a different case
20:30:11 <cdecker> I definitely need a diagram of all the pieces in flight :-)
20:31:01 <cdecker> Seems like we have reached a bit of a quite moment, shall we finish up and continue the discussion another time?
20:31:20 <niftynei> thanks for chairing cdecker
20:31:34 <t-bast> yes sounds good, thanks for chairing cdecker
20:31:53 <cdecker> Thank you niftynei for the update on dual-funding :-)
20:32:09 <t-bast> I really think having a clear agenda that we can agree on during the week before the meeting makes it more efficient
20:32:11 <cdecker> (sorry I was a bit unprepared, but I didn't make it through the monster in time)
20:32:20 <cdecker> #endmeeting