19:06:11 #startmeeting 19:06:11 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:06:15 t-bast: I haven’t heard that they will 19:07:26 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 #link https://paper.dropbox.com/doc/Lightning-Spec-Meeting-20200120--Asyn1LqwS5eymCtfthi~KR01Ag-SA160p27VepiVZcnbKcZE 19:08:18 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 Today we have 6 PRs, 1 Issue that t-bast has asked to discuss and finally two outlooks for long term 19:08:41 hey roasbeef! 19:09:01 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 But we can certainly judge at the end whether it was the improvement I hoped for, or not 19:09:41 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 Since we have a quorum with two people from LL, shall we get started with the PRs? 19:10:15 cdecker: SGTM 19:10:30 #topic Restrict data_loss_protect to init context #726 19:10:38 #link https://github.com/lightningnetwork/lightning-rfc/pull/726 19:11:12 It seems we discovered a number of issues with the "just advertise everything everywhere" idea 19:11:42 For this specific issue we are only interested in `data_loss_protect` being limited to `init` or not 19:12:26 I think that what underpins this is: what should be the rationale for including a feature in `init`, `node_ann`, elsewhere 19:12:26 cdecker: yeh if we don't wanna carry things over, can have a weekly master tracking issue perhaps 19:12:37 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 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 roasbeef: sure, we can replace the paper thing with issues, no problem, though then only the OP can edit 19:13:28 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 (re feature bit locations) 19:13:55 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 t-bast: agreed. 19:14:07 t-bast: yeh not like we're short on space either lol 19:14:15 :D 19:14:24 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 and so not use these peers to route 19:14:38 seems like RL wants to implement some very strict rules for feature bit placement, while generally things can be mnore lax 19:14:40 Yep, though some things might be weird, i.e., mandatory flags in th node_announcement that we don't understand 19:15:19 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 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 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 rusty: hmm so the fix would be to context packet processing in channel_features and allow replacement of them? 19:16:56 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 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 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 upgrade as in? 19:17:50 we might have different thresholds for various placements (required in init, optional in node_announcement) 19:18:00 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 roasbeef: some new channel magic causes us to want to upgrade channel features on the fly... 19:18:31 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 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 That'd be an example of "if you don't understand this, don't talk to me" 19:19:32 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 t-bast: worse, renewing would require negotiating with your peer who can't know your feature preferences Yuck... 19:20:24 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 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 Seems semantically weird 19:20:54 yeah this ends up being very messy 19:21:06 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 In init you would use the even bit. 19:21:33 (If you didn't want to support backwards compat) 19:21:57 So we add two variants: N- and N+ for optional/mandatory possible in the node_announcement? 19:22:20 Yes. I foresaw this for channel announcements, not node announcements, sorry. 19:22:31 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 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 And let you decide 19:23:11 For the current PR, I'd then say to keep the feature as `IN` 19:23:16 For me it's a NACK as long as data_loss_protect is flagged as optional 19:23:24 (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 `IN-` 19:23:50 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 I will respond on PR, but I think this is an N-. 19:24:36 I'm fine with IN-, it solves the issue to seek preferential peers 19:24:41 Great, so everybody happy with nacking this one, and postpone the discussion on semantics for N-/N+ to GH? 19:24:49 SGTM 19:24:49 Great, thanks ariard_ 19:25:00 thanks for the discussion this triggered ariard ;) 19:25:16 #agreed cdecker to close #726 with a brief explanation 19:25:24 Next one ^^ 19:25:32 #topic 09+11: require transitive feature dependencies #719 19:25:40 #link https://github.com/lightningnetwork/lightning-rfc/pull/719 19:26:23 It seems we have ACKs from ACINQ and LL, with agreement from the last time from c-lightning 19:27:00 We just had a minor rebase issue where lines got mixed up last time, so this should be ready now 19:27:23 Like the idea, assume others have bikeshedded the details already :) 19:27:31 Are there any last minute comments regarding the requirement for transitive features? 19:28:07 nope, lgtm 19:28:08 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 nope 19:28:13 nope, we've implemented it already 19:28:19 Great ^^ 19:28:20 already on our master too :D 19:28:32 #agreed cdecker to merge #719 19:28:43 #topic Specify that resolution of amount is msat #700 19:28:51 #link https://github.com/lightningnetwork/lightning-rfc/pull/700 19:29:45 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 Since the OP mentions libraries that didn't do this correctly, this clarification feels needed 19:30:30 We have acks from ACINQ and c-lightning, any objections to this clarification? 19:30:34 Yep. Wording is a bit weird: I would suggest "last digit must be zero". 19:30:48 Yes, libraries getting this wrong is kind of nasty 19:30:50 (Matching the line above) 19:31:17 Ok, rusty would you like to rephrase that or shall I? 19:31:47 Happy for you to... but agreed it should be specified. 19:32:24 I believe the OP has moved on to other projects, so maybe we'll need to take over the PR 19:32:51 I just spoke to sword_smith last week when Elizabeth was in town :-) 19:33:11 #agreed cdecker to rephrase #700 to match the previous line and merge after acks on Github 19:33:24 #topic Add bolt11 test vector with amount in `p` units #699 19:33:29 cdecker: oh great, perfect then 19:33:33 #link https://github.com/lightningnetwork/lightning-rfc/pull/699 19:34:06 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 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 good point, we could have a test vector for in invalid invoice 19:35:07 cdecker: Agreed. But this should be applied, I should add some invalid invoice tests. 19:35:14 (We had one library which didn't check signatures!) 19:35:37 Actually, Imight as well fix this example too. 19:35:40 there's also that weird bech32 quirk w/ the q's 19:35:43 (Wrong key was used). 19:36:26 roasbeef: what do you mean? the extension attack? 19:36:33 rusty: would you like to adopt the PR and add some failing examples? 19:36:36 #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 Great, thanks rusty 19:37:20 So it seems this PR needs some additional work, and we can move on to the next topic. 19:37:30 Unless there are some more comments related to this one? 19:37:40 Nope, that sounds good! 19:37:52 #topic BOLT 1: Define custom message type range #705 19:38:04 #link https://github.com/lightningnetwork/lightning-rfc/pull/705 19:38:49 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 this is about messages and not the onion right? 19:39:12 roasbeef: yes 19:39:14 iirc we already have a cut out range in teh onion 19:39:20 We already have the same mechanism for onion tlvs 19:39:21 Custom types are already used by WhatSat and Noise for example, and keysend 19:39:26 I really mimicked it for messages 19:39:42 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 Oh, I must have missed the onion one, sorry about that 19:39:52 t-bast: on bech32 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017443.html 19:40:00 this sgtm though 19:40:10 roasbeef: that'd be really useful, I read through joost's code to figure out the types he was using 19:40:34 Ok, so I'm counting ACKs from t-bast, roasbeef, and mine 19:40:37 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 Sounds like we have quorum, unless there are more comments? 19:42:06 #action cdecker to merge #705 19:42:25 And finally the last PR for today: #697 19:42:32 #topic BOLT-04: modify Sphinx packet construction to use starting random bytes#697 19:42:40 And a good one for the finish line! 19:42:40 #link https://github.com/lightningnetwork/lightning-rfc/pull/697# 19:43:02 I think we've all implemented some variant of this already 19:43:08 so this'll ship in lnd 0.9 (dropping soon), confirmed that eclair+lnd match up 19:43:29 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 the updated test vector worked for both eclair and lnd, did someone c-lightning side had time to validate them? 19:43:50 Yeah, I have a variant implemented, not yet with the pad-key, but should be no problem 19:44:03 great 19:44:10 t-bast: don't think so, but need to verify, signature doesn't protect if invoices decodes to wrong data 19:44:21 I can implement and verify this week, would that work? 19:44:43 cdecker: sgtm 19:45:04 #action cdecker to implement updated padding and merge #697 if test-vectors pass 19:45:37 Excellent. That concludes the round of PRs, let's move on to discussing the open issue #728 19:45:46 #topic Stuck channels because of small fee increase#728 19:45:54 #link https://github.com/lightningnetwork/lightning-rfc/issues/728# 19:46:10 I'll let you read it, it's probably something you've already thought about 19:46:14 t-bast would you like to give a short introduction to the issue you have uncovered? 19:46:35 I think reading the issue should be the most accurate way of introducing it :) 19:46:46 I tried to make it not too long 19:47:57 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 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 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 Especially with feerates changing 19:49:08 yeah that's why it's painful, I've seen this happen to real-world channels 19:49:21 there're also some related edge cases w.r.t the handling of the reserve and fees 19:49:57 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 Wouldn't it be possible to move out of this situation by doing sub-dust, i.e., pruned HTLCs? 19:50:13 cdecker: yes that's one solution 19:50:54 btw the periods instead of commas in the issue kinda threw me off ;) 19:51:10 They'd be tiny transactions that go nowhere but you can unilaterally solve this by dropping tiny payments at Alice 19:51:18 roasbeef: xD 19:51:34 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 to double check...it's a 150 sat channel not 150k sat? :p 19:51:54 roasbeef: 150k sat in the example 19:52:52 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 (cdecker: we do support push_msat as of https://github.com/ElementsProject/lightning/pull/3369) 19:52:58 150 sat would mean the entire channel is dust xD 19:53:21 lol yeh just making sure.... 19:53:24 Oh no, why??? 19:53:31 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 t-bast: ah, so *always* allow a single HTLC, even if fee cannot be paid? 19:54:01 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 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 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 Yep, I don't see why Bob would do that, but it is a unilateral change 19:55:24 rusty: I don't think we currently do, but maybe we could there...or maybe it's a riskier change 19:55:46 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 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 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 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 (but they dont cover update_fee cause I *know* that can break it) 19:57:09 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 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 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 - SHOULD fail the channel." to carve out the single-HLTC case., Same on sender requirements? 19:58:12 t-bast: seems to need a feature bit :( 19:58:26 Great, as always: comments and discussions on GH are welcome and we can hash out the details in the next meeting 19:58:30 Sounds good? 19:59:07 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 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 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 rusty: are you sure they're not for the case where sender is funder only? 20:00:04 With MPP you can send multiple dust HTLCs to work around it :p 20:00:20 t-bast: ah, though you're right, there's no requirement specified on non-funder. There should be :( 20:00:54 rusty: that's what got me confused, I'll try to draft something 20:01:06 but using MPP to workaround mean you still have stuck capacity you can't use anymore 20:01:10 johanth: thinking outside the box ;) 20:01:34 #action everybody to brainstorm the issue on Github and come up with potential solutions for the next meeting 20:01:42 ACK 20:01:50 Well, an implementation could refuse to allow any non-dust HTLCs and really simplify their code :) 20:02:09 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 #topic Current status of the dual funding proposal 20:02:56 ok so 20:03:12 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 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 Sorry for interrupting you niftynei :-) 20:04:16 cdecker: ah gotcha, you can route multiple MPP through same channel but tho you may hit the max_htlc limit 20:04:30 np cdecker! 20:04:55 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 which is to say that there might be changes to the proposed RFC draft for that section still 20:05:44 if you're curious at looking at the PR, it's here https://github.com/ElementsProject/lightning/pull/3418 20:06:12 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 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 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 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 +1 on batching 20:08:26 that may end up being very similar to coinjoin mechanisms, doesn't it? 20:08:27 roasbeef, do you have a link to the close channel proposal? i'm not really familiar with channel close considerations 20:08:31 t-bast, yes 20:08:31 isn't batching already also possible as is today? given that you just send over an out point 20:08:34 to an extent 20:08:36 roasbeef: could we generalize it to have a BYOI (bring your own inputs) so we remove that limitation? 20:08:39 niftynei: doesn't exist yet, just an half baked idea lol 20:08:46 right, gotcha 20:09:03 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 Yep, and it could work for funding and close the same way imho 20:09:57 Although it sounds like it'd get us into meta-protocol territory xD 20:10:35 right, so ideally either party in a dual funding transaction could include another party 20:10:44 and we could reuse same fee logic for splicing 20:10:55 i.e. either the opener or the 'accepter' (after the accept_channel message they respond with) 20:11:00 *named after 20:11:51 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 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 the current proposal uses a limit to the number of inputs as a proxy for that 20:12:21 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 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 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 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 currently we avoid dependencies by failing/rejecting the open if a peer sends an input you've already seen 20:14:49 have you taken a look at the current proposal? 20:15:15 Not in detail, no :blushes: 20:15:57 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 having batched opens is very nice because it mitigates (minorly) the sharing of your current utxos 20:16:52 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 I agree, and having batched opens could pave the way for batched close as well, couldn't it? 20:17:25 yes, i took roasbeef's comment to be a desire to cut functionality, which would mean removing the batchedness 20:17:45 that'd definitely be the easiest way to simplify the proposal 20:17:47 I think so, you can reuse the same set of transaction construction message like funnding_add_input/output 20:17:51 I'll read up on the commits and be ready next time :-) 20:18:08 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 i don't think it's possible to add it later 20:18:21 ok 20:18:40 so even if it makes the proposal more complex, it's probably worth having 20:18:41 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 though if you do batchedness, we should also consider CPFP to avoid one party no-resigning and stucking everything 20:18:48 could be wrong tho 20:19:15 anyway, one thing i could use some help with is dealing with fees in the batched open case 20:19:36 i wrote about it in this channel earlier, but it'll probably be easier to digest via a mailing list post 20:19:55 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 I.e., merge batch funding first and then build dual funding on top? 20:20:41 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 you can do batch funding already with c-lightning 20:21:42 Great, I think we all need some more time with your PR to get more familiar with the changes. 20:22:01 the biggest change for dual-funding (and i'd assume a batched close) is socializing inputs/outputs for transaction construction 20:22:27 ok great. i think i'm way over time. 20:22:41 You mean how willing nodes are to share their inputs with peers? 20:23:04 Because there's a risk a node is faking a channel open to discover your inputs? 20:23:09 No problem niftynei, let's move the discussion to GH then ^^ 20:23:28 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 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 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 the other consideration for light clients is that they can't easily verify the inputs 20:24:44 because they're not the sum of your total wallet -- there's also invisible funds already in channels 20:24:51 full node backend nodes can just check their utxo set 20:24:53 'invisible' of course depending on whether it's private or not 20:25:00 #action everyone to take a look at "dual-funding, the monster" ElementsProject/lightning#3418 :-) 20:25:09 roasbeef, yes. we need the sig changes that are proposed in taproot (i believe) 20:25:27 t-bast would it be ok if we move the trampoline discussion to the next meeting? 20:25:40 cdecker: sure, no problem, we've already done a lot! 20:25:49 (it's getting kinda late, and I'd like to give it enoough room to be discussed in full) 20:26:00 Great, thanks 20:26:11 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 lol "the monster" 20:26:29 to make it light-client compatible (ie including the output script's format as a member of the signed hash) 20:26:41 roasbeef: that sounds like a nightmare-ish FSM to build 20:27:20 t-bast: yeh... 20:27:55 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 oh you're talking about a different case 20:30:11 I definitely need a diagram of all the pieces in flight :-) 20:31:01 Seems like we have reached a bit of a quite moment, shall we finish up and continue the discussion another time? 20:31:20 thanks for chairing cdecker 20:31:34 yes sounds good, thanks for chairing cdecker 20:31:53 Thank you niftynei for the update on dual-funding :-) 20:32:09 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 (sorry I was a bit unprepared, but I didn't make it through the monster in time) 20:32:20 #endmeeting