--- Log opened Mon Mar 29 00:00:10 2021
00:15 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
00:45 -!- molz_ [mol@gateway/vpn/protonvpn/molly] has joined #lightning-dev
00:48 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 268 seconds]
00:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
01:10 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:11 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
01:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
01:22 -!- laptop_ [~laptop@ppp-2-166.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
02:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
02:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
02:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
03:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
03:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
03:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
03:24 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
03:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
04:34 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection]
04:34 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #lightning-dev
04:34 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
04:34 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #lightning-dev
04:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
04:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
05:11 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 240 seconds]
05:14 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #lightning-dev
05:21 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]
05:22 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
05:35 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds]
05:41 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Read error: Connection reset by peer]
05:41 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
05:51 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Read error: Connection reset by peer]
05:51 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
05:53 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
05:57 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Read error: Connection reset by peer]
06:00 -!- deusexbeer [~deusexbee@080-250-076-051-dynamic-pool-adsl.wbt.ru] has quit [Quit: Konversation terminated!]
06:00 -!- deusexbeer [~deusexbee@080-250-076-051-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev
06:06 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
06:15 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
06:55 -!- Xaldafax [~Xaldafax@cpe-198-72-160-101.socal.res.rr.com] has joined #lightning-dev
06:59 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 240 seconds]
07:00 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #lightning-dev
07:24 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
07:30 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has quit [Quit: WeeChat 2.3]
07:36 -!- belcher_ is now known as belcher
07:38 -!- eugene-ff [~eugene_ff@2603-6080-8f06-6d01-b53c-eb41-4032-6312.res6.spectrum.com] has joined #lightning-dev
07:50 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has joined #lightning-dev
07:50 -!- eugene-ff [~eugene_ff@2603-6080-8f06-6d01-b53c-eb41-4032-6312.res6.spectrum.com] has quit []
08:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
08:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
08:52 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
08:53 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
08:55 -!- mrostecki [mrostecki@nat/suse/x-lzohfazdymmifmjr] has joined #lightning-dev
09:06 -!- laptop_ [~laptop@ppp-2-166.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
09:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
09:22 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev
09:22 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
09:22 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
09:25 -!- laptop_ [~laptop@ppp-2-166.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
09:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
09:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection]
09:49 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #lightning-dev
10:07 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 246 seconds]
10:21 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
10:33 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds]
11:03 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds]
11:19 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
11:49 -!- t-bast [~t-bast@2a01:cb19:706:cb00:cdc0:809c:a013:e5c0] has joined #lightning-dev
11:51 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 268 seconds]
11:51 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #lightning-dev
11:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
11:54 -!- vincenzopalazzo [~vincenzop@host-95-249-217-78.retail.telecomitalia.it] has joined #lightning-dev
11:55 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 240 seconds]
11:55 < niftynei> hello hello
11:55 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
11:55 < cdecker> Heya ^^
11:55 < t-bast> Hey everyone!
11:56 -!- Thomashuet [~thomas@78.196.22.221] has joined #lightning-dev
11:56 < niftynei> t-bast you've done it again :D https://github.com/lightningnetwork/lightning-rfc/issues/856
11:56 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #lightning-dev
11:57 < t-bast> I wasn't very inspired this time, it's mostly things that were already there in previous meeting but well xD
11:58 < t-bast> Note that I didn't mess up the meeting time even though we went to DST in France this sunday, I'm very proud
11:58 < niftynei> I'm definitely impressed
11:58 -!- valwal [~valwal@pool-96-239-17-242.nycmny.fios.verizon.net] has joined #lightning-dev
11:59 < t-bast> BTW should I rename "dual funding" to "interactive tx"? What's your preference there?
11:59 < niftynei> as you would expect, it's a two-for-one deal hehe
12:00 < niftynei> i think 'dual-funding' is fine!?
12:00 < ariard> hi
12:00 < niftynei> hello ariard 
12:00 < t-bast> niftynei: cool I'll keep it like that
12:00 < t-bast> hey ariard
12:01 < ariard> what do you feel talking about today :) ?
12:01 < niftynei> should we get started??
12:02 < vincenzopalazzo> hello guys :-D
12:02 < t-bast> I got a feeling niftynei would do a great chair today :)
12:02 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection]
12:02 < niftynei> would someone from RL want to run the meeting today? ariard? valwal ??
12:02 -!- sstone [~sstone@112.ip-51-68-199.eu] has joined #lightning-dev
12:02 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #lightning-dev
12:02  * niftynei waits for someone else to take the throne
12:02 < ariard> i'm good to do it, will learn on the way
12:03 < ariard> #startmeeting
12:03 < lndev-bot> ariard: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee'
12:03 < ariard> first bug damn
12:03 < ariard> #startmeeting Lightning March
12:03 < lndev-bot> Meeting started Mon Mar 29 19:03:27 2021 UTC and is due to finish in 60 minutes.  The chair is ariard. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:03 < lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:03 < lndev-bot> The meeting name has been set to 'lightning_march'
12:03 < t-bast> yep it's the 2021 edition of the bot that requires a meeting name, got me last time as well
12:03 < rusty> Hello everyone!  I am finally enjoying my "bitcoin-hit-50k" espresso machine... I will be awake in a moment.
12:03 < ariard> # topic  #847 closing fee requirement
12:03 < t-bast> hey vincenzopalazzo
12:04 < t-bast> rusty: nice!
12:04 < cdecker> rusty: a coffee machine for a full bitcoin? That must be a steam engine :-)
12:04 < ariard> who has done an implementation of #847, beyond eclair ? any feedback
12:05 < t-bast> re #847, the only thing I changed is adding a TLV to specify the fee range we're ok with paying
12:05 < ariard> with lower-upper bound ?
12:05 < t-bast> yes, it's a min-fee and a max-fee
12:06 < t-bast> it doesn't solve the case where you completely disagree with your peer's fee range though: but in that case negotiation would kind of fail anyway...
12:06 < ariard> would it make sense to express per wu ? in case we reuse this for splicing and closing may be far bigger
12:06 < t-bast> and it seems like the only option is to force-close (but there may be a game of chicken to get the other guy to force-close to avoid csv delays)
12:07 < niftynei> can the feerange change between `closing_signed` messages?
12:07 < niftynei> if not, it might make sense to add it to the `shutdown` request instead? or is that too far from the closing logic
12:07 < t-bast> I chose to stick to fee values instead of feerate to be consistent with the fee in the `closing_signed` message, but I can make that a feerate instead if we feel that's the direction we want to take in the spec
12:08 < t-bast> niftynei: it's a good point, I'm not sure it should change, but `shutdown` may be too early: if it takes a lot of time to settle pending HTLCs, on-chain fees may have changed drastically
12:09 < t-bast> but I don't know if we should require this range to be fixed: if your peer goes offline and comes back online an hour later, you'll want to resume negotiation but fees will have changes
12:09 < niftynei> so on clightning we've been musing about applying the interactive tx protocol to closing; a feerate would be more flexible in that case, as the size of the tx is variable. right now closing tx's are fixed format, no?
12:09 < t-bast> *changed
12:09 < niftynei> ah i see, good point
12:09 < ariard> closing tx are fixed format with either one or two outputs iirc
12:09 < t-bast> yes, that's because the closing tx is fixed that I left it a flat fee since you can instantly convert to feerate, but you're right that feerate may be more flexible long term
12:10 < niftynei> in the ideal case, you only ever exchange three closing_signed messages? the one setting the feerate range, your peer which picks out a feerate in that range and then your matching response? 
12:10 < rusty> AFAICT range is just for post-mortem purposes really?  If you don't agree, you can show the ranges...
12:10 < ariard> right, there is no fall-back to get back the negotiation with looser range
12:11 < t-bast> niftynei: yes exactly, but you're also free to continue negotiating inside the fee range to get closer to your "ideal" fee
12:11 < niftynei> why not set the range to exactly the ideal fee then?
12:11 < t-bast> rusty: what do you mean by post-mortem here?
12:11 < t-bast> niftynei: you mean sending a single value? That's already what we do now, isn't it?
12:12 < rusty> t-bast: you could continue using the existing protocol and ignore it, but at least print it out if negotiation fails so user can see what went wrong.  But I guess more optimal to do as niftynei says: pick something in this range immediately.
12:12 < vincenzopalazzo> Sorry for the stupid question, for me, it is the first time for me here. There is some secret door to enter in the meeting to hear only? :-)
12:13 < t-bast> rusty: gotcha, yes with older nodes who ignore this range entirely it would help users understand why things went sour
12:13 < t-bast> vincenzopalazzo: the meeting is IRC only, no voice/video call, you're already in ;)
12:13 < cdecker> vincenzopalazzo: you're already in it, we moved the discussion to IRC to include everyone
12:13 < vincenzopalazzo> ops :-D sorry
12:14 < ariard> vincenzopalazzo: welcome among us :)
12:14 < vincenzopalazzo> Thanks ariard :)
12:14 < t-bast> the ideal behavior (in my opinion) would be: I send you a feerange and my preferred fee, if you completely disagree with the fee-range just force-close or ignore, if you agree with the fee range choose something inside it and we close the negotiation
12:15 < t-bast> the risk is whether implementations/users will be aggressive and chose a narrow fee-range, resulting in a lot of disagreement / force-close
12:15 < rusty> t-bast: OK, this seems perfectly implementable.  For dual-funding we used a "min, preferred, max" and the other side simply chose.  This is pretty close to that.
12:16 < t-bast> rusty: I only added min and max since preferred is already in the closing_signed, but if we move to feerates I'll add preferred inside the TLV to make it more obvious
12:16 < niftynei> well that was in a draft but it's since been removed lol >.<
12:16 < t-bast> #action t-bast to use feerates instead of flat fees and add preferred in the fee_range tlv
12:16 < ariard> okay we're good next topic?
12:16 < rusty> t-bast: you're right, it's exactly analogous.  Leave it as is, I say.  It maps really well.
12:16 < t-bast> ACK
12:16  * rusty acks as is
12:17 < ariard> # topic Funding timeout recovery proposal #854
12:18 < cdecker> Yeah, so the idea is pretty simple, and I think well worth the extra couple of bytes to remember in order to have a gracious close
12:18 < ariard> cdecker: you want to explain for the ones for have not dig into this :) ?
12:19 < cdecker> The idea basically is that since we all derive the per-channel key in a secure way (HKDF) we can freely use it to sign anything that looks like a transaction once we're sure we're not going to make progress with that channel, i.e., we gave up waiting for it to confirm
12:19 < cdecker> One alternative would have been to just share the private key, but that feels wrong, but signing is fine
12:20 < cdecker> We sign a close transaction with a sighash_none so the funder can chose a feerate it feels comfortable with and could RBF bump as well
12:20 < ariard> sharing the private key sounds a restriction on your signer implementation
12:20 < t-bast> but if you're signing blindly, isn't it the same thing as giving away the private key?
12:20 < t-bast> because signing with sighash_none is really equivalent to signing blindly, isn't it?
12:21 < ariard> giving away a private key may reveal information about derivation scheme
12:21 < cdecker> We're not quite signing blindly, we're signing valid transactions spending the channel funding outpoint should it ever be confirmed
12:21 < ariard> after the timeout
12:21 < t-bast> true, it's more restrictive, I guess you've explored potential signature re-use?
12:22 < t-bast> there's probably none since we marked the channel as never being used
12:22 < cdecker> Per spec the bitcoin privkey should be derived in a hardened way from the channel parameters, so we automatically use different keys for different channels
12:22 < cdecker> So any issue is restricted to within that channel
12:22 < t-bast> ariard: how so? if you're using bip32 with non-hardened?
12:23 < cdecker> Inside the channel we already gave up and don't have a stake in anymore
12:23 < t-bast> right, so if the spec mandates using hardened derivation, is there a risk sharing the private key?
12:23 < cdecker> Unless we have a bug and decide to accept a confirmation as an open it can be dangerous, but then the implementation is pretyt broken anyway :-)
12:23 < ariard> t-bast: is the spec making mandatory to use bip32 ? our signer interface in RL doesn't make this assumption
12:24 < t-bast> because that would solve users mistakingly sending *more* money to the 2-of-2 by mistake when trying to CPFP/RBF the funding tx...
12:24 < cdecker> Uh, interesting use-case, thanks t-bast for pointint that out
12:25 < cdecker> As the second part says, we'd also like an automated recovery for the case the funding tx was malleated, which is a special case of what you mention
12:25 < rusty> Yeah, the private key solves all the problems the user can create (so they can create new oens!).
12:25 < t-bast> cdecker: that actually happened to one of our users, so we had to help them sign another tx to get their funds back...t
12:25 < rusty> t-bast: yech... we don't like our users as much as you like yours :)
12:25 < cdecker> Yep, that's how we discovered it as well ;-)
12:25 < t-bast> I'm not finding anywhere in the spec where we mandate or advise using hardened derivation though...
12:26 < t-bast> rusty: a pleasure to serve ;)
12:26 < cdecker> t-bast: I was absolutely convinced it'd be there, and didn't bother to check. Is anyone using non-hardened derivation anyway?
12:26 < rusty> t-bast: yeah, don't implement this if your keys aren't hardened!
12:27 < ariard> cdecker:  we have an abstract interface in RL, outside our scope to mandate hardened or non-hardened
12:27 -!- laptop [~laptop@ppp-1-45.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev
12:27 < niftynei> signing an 'arbitrary' tx with non-hardened keys is fine, no? it'd just be problematic if you exposed the privkey
12:28 < cdecker> Hm, so this complicates things a bit. Do you have signals on whether hardened or non-hardened derivation was used?
12:29 < ariard> cdecker: no though we could tweak our api
12:29 < t-bast> But is there a reason why you'd use non-hardened derivation? I'm not sure it makes sense anywhere to get the benefits of those compared to hardened derivation for channel keys, is there?
12:29 -!- laptop_ [~laptop@ppp-2-166.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
12:29 < cdecker> ariard: do the rust thing and add a new type? xD
12:29 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
12:29  * cdecker is learning rust ;-)
12:30 < t-bast> Or is there some clever thing for watchtowers or something where it's helpful to use non-hardened somehow?
12:30 < ariard> cdecker: but do we really want to share private key ?
12:30 < ariard> t-bast: well that's the thing, try to be flexible for things we're not smart enough to guess
12:30 < cdecker> Ah no, that'd be the alternative, in this draft we just sign with sighash_none
12:30 < ariard> i would need to ask devrandom opinion he has a sample signer
12:30 < t-bast> it feels to me that this is an area where we'd lock things down by default because it critical though
12:31 < cdecker> Not a cryptographer, but if someone convinces me that non-hardened + signing only valid txs is ok, then I'll happily accept that :-)
12:31 < ariard> what supplemental advantage do we get from using private key compare to sighash none?
12:31 < rusty> ariard: it's a better solution.  It lets them do whatever they want, has no onchain privacy issues....
12:31 < t-bast> but I can understand the reasoning to let users find use-cases, in that case we should forget about the option to dump the private key
12:31 < ariard> rusty: onchain privacy issue is a good point
12:32 < cdecker> Yep, wasn't it ariard that pointed out that sighash_none is a tracing capability?
12:32 < ariard> though the 2048 delay is a good enough fingerprint
12:32 < ariard> like utxo age
12:33 < rusty> ariard: but this solution works when we head to taproot, too, which is a minor consideration but kinda nice.
12:33 < cdecker> I mean we could counteract that and have the funder propose a close and the fundee signs it (without sighash_none), that could be iterated
12:33 -!- Egge_ [5482aca8@p5482aca8.dip0.t-ipconnect.de] has joined #lightning-dev
12:33 < ariard> i would consider this like an edge case, like unilateral closing we also loose privacy
12:33 < cdecker> But the sighash_none sig has the nice advantage of not requiring interaction if things don't work out (RBF bump, ...)
12:33 < BlueMatt> rusty: right, if we cant make it work with the private key, its not gonna work on taproot, so we should find a way to make it work, no?
12:33 < BlueMatt> ie, we're gonna wanna use the private key come taproot, anyway
12:33  * BlueMatt will figure his calendar out and show up on time one day...just not today
12:34 < ariard> sighash_none is great to avoid the non-interactivity agree
12:34 < cdecker> Interesting, I don't quite get the connection with taproot yet, BlueMatt can you help me?
12:35 < cdecker> Oh, I see, must've missed the msg you were referring to, sorry
12:35 < BlueMatt> cdecker: as in, once we have taproot funding outputs, we can't do sighash-none if you want to allow spends to be key-based and not reveal-script-based
12:35 < rusty> cdecker: if you have to use musig2 to co-create a signature, that would be a different post-close signing flow I think.
12:35 < t-bast> we could use that sighash_none on chain to detect people who have a buggy CPFP engine xD
12:35 < ariard> cdecker: because aggregated pubkey requiring signing interactivity
12:35 <+roasbeef> t-bast: re #847, havne't done it yet inlnd but I plan to get a PR up on the lnd side this week
12:35 < BlueMatt> in the non-taproot world I dont think its worth worrying too much about the privacy, but in taproot probably does
12:35  * cdecker ducks from all the explanations xD
12:36 < t-bast> roasbeef: nice, don't hesitate to ping me when you have a branch available, I can run some interop tests then
12:38 < niftynei> so it sounds like "requesting sig from peer" rather than "requesting privkey from peer" is going to forward compatible... and/or that we'll need to update/change the interaction once taproot is standard?
12:38 < niftynei> *is going to be forward compatible
12:38 < rusty> niftynei: no, getting privkey is ultimately fwd compatible.  IMHO it'd be the clear winner but for our instinct to NEVER EVER DO THAT.
12:38 < t-bast> IIUC we're saying that sighash_none will not work with taproot, isn't it?
12:39 < niftynei> ack, thanks!
12:39 < BlueMatt> t-bast: it would, it would just create a larger transaction and reveal the spending condition, which we'd ideally not do
12:39 < cdecker> Yeah, that's too bad
12:39 < t-bast> at least that sighash_none will not give us the non-interactivity if we want to use the keypath
12:39 < ariard> though you're back loosing privacy
12:39 < t-bast> BlueMatt: right, exactly
12:40 < cdecker> How about the iterated "ask peer for sig" approach, and we tell the fundee what sighash we'd like?
12:40 < BlueMatt> ariard: wrt rust-lightning's key interface, we'll probably have to, eg, take the private key the user gives us and hash it to create a new one or something trivial.
12:40 < rusty> I say let's leak the private key YOLO!
12:40 < ariard> BlueMatt: right hashing should break any information leak
12:41 < cdecker> If the node is responsive they can do without sighash_none, while if we don't think our peer will be around we can use sh_none
12:41 < niftynei> the problem with leaking the private key iiuc was that RL doesn't guarantee their keys are per-channel hardened, right?
12:41 < cdecker> KEYOLO: a key that only lives once xD
12:41 < BlueMatt> niftynei: we do, but hardened specifically is up to users how they want to derive keys. we can, however, force users to give us a hash preimage of the key instead, allowing us to "force" them to be "hardeneed" by hashing them
12:42 < t-bast> cdecker: love it, I want you on the marketing team for feature names xD
12:42 < BlueMatt> niftynei: oh, I misread your text, but, no, yea, we do *not* require them to be hardened per-channel (though obviously default implementations do)
12:42 < niftynei> ack 
12:42 < ariard> BlueMatt: not hardened but unique per-channel 
12:43 < BlueMatt> right, we (obviously) require unique-per-channel, but not hardneded
12:43 < BlueMatt> anyway, next topic?
12:43 < BlueMatt> sounds like everyone's in agreement?
12:43 < ariard> # Long Term Updates 
12:43 < t-bast> in agreement with dumping the priv key?
12:43 <+roasbeef> ah interesting, this would also be a way to just get rid of the half baked "fee neogitation" in the spec rn re rusty's comment on the spec 
12:43 < niftynei> sounds like there might be a TODO here to add a "must be hardened" note to the channel keys in the spec?
12:44 -!- Egge_ [5482aca8@p5482aca8.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
12:44 < cdecker> So my conclusions from #854 are: a) general agreement that this is a useful feature, b) we need to discuss whether to leak key or serve sigs, is this about correct?
12:44 < rusty> niftynei: yeah, don't support this option unless key is hardened.
12:44 < rusty> roasbeef: yeah, it seems to devolve down to it?
12:44 < BlueMatt> niftynei: no, no need, just a note that the keys should not reveal information about other keys - that can be accomplished in many ways with or without bip 32
12:44 < ariard> cdecker: i was dubious about the funding transaction alias
12:44 < BlueMatt> cdecker: oh, sorry, i thought we were largely all in agreement to reveal the secret key
12:45 < niftynei> i had reached the same conclusion as BlueMatt fwiw
12:45 < cdecker> Ok, sounds good to me, I can draft up the changes accordingly 👍
12:45 < ariard> cdecker: but not a concern anymore if you're giving the key away ahah
12:45 < cdecker> ariard: the funding tx alias is there for funding tx malleation, which happened to perfectly fit in this proposal
12:46 < niftynei> option SIGHASH_SEND_KEY
12:46 < rusty> - MUST print out "KEYOLO" in the logs when revealing the private key.
12:46 < cdecker> Right, that'd be the sledgehammer approach
12:46 < t-bast> YAY dump all the private keys!
12:46 < ariard> ultimate malleability delegation xD
12:46 < cdecker> See, no need for segwit if we can fix malleability this way xD
12:46 < cdecker> Anyway
12:46 < ariard> do you want to talk about a long-term updates ?
12:47 < niftynei> yes!
12:47 < ariard> which one ?
12:47 < cdecker> #action cdecker to draft up the proposal with KEYOLO
12:47 < niftynei> dual funding! #851
12:47 <+roasbeef> +1 for sighash_none vs sending keys over
12:47 < ariard> let's go for dual-funding :)
12:48 < ariard> roasbeef: hmmm are you for sighash_none or sending keys over?
12:48 < cdecker> #topic Long Term Update: Dual Funding
12:48 < cdecker> #link https://github.com/lightningnetwork/lightning-rfc/pull/851
12:48 < t-bast> how do you recommend we read the PR niftynei: is there a simple path for reviewers before diving into concrete requirements?
12:48 < niftynei> ok just a quick update! we've got an implementation i'm fairly happy with in c-lightning and are planning to ship it (flagged behind a runtime experimental flag) in our next release (coming.. this week?)
12:49 < niftynei> the PR for the spec change is listed (minus the feerate ranges that rusty mentioned, they were taken out later lol)
12:50 < niftynei> t-bast: do you mean like the "one sheet summary"?
12:50 < niftynei> i did a short infomercial on the spec changes late last thursday, i'll post it here as soon as it's up on youtube. that might be useful for approaching the spec 
12:50 < t-bast> niftynei: like the more digestable higher-level format (ideally with diagrams and flows) :)
12:51 < niftynei> there are diagrams and flows in the spec itself
12:51 < t-bast> right, I just reached them!
12:51 < rusty> (Side note: Damn, second espresso is really good...)
12:51 < ariard> the fee bumping model is single-party rbf ?
12:51 < niftynei> rusty you're bringing that coffee machine to the next in-person yeah??
12:51 < niftynei> ariard, what's a single-party rbf?
12:51 <+roasbeef> ariard: sighash_none, re the taproot thing we'd need a different co-op closing scheme all together in either case right? 
12:52 <+roasbeef> as that's more interactive 
12:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
12:52 < lnd-bot> [lightning-rfc] btcontract closed pull request #857: Add keysend invoice (master...master) https://github.com/lightningnetwork/lightning-rfc/pull/857
12:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
12:52 < BlueMatt> niftynei: if we can fit/convince/swing the chaincode office there's already a quite nice machine there :)
12:52 < rusty> niftynei: it's 30kg (40kg boxed), so might be cheaper to buy a second one and ship it from Italy...
12:52 < niftynei> the rbf is initiated by the opener, same as the open_channel2 is; it's basically a request to re-do the opening but with a higher feerate
12:52 < ariard> roasbeef: but we all conclude that private key was far more flexible and taproot-proof ? we might have closing scheme for taproot for sure
12:53 < ariard> niftynei: that's what i meant rbf is initiated on the burden of one-party
12:53 < niftynei> both parties pay fees on the funding tx, so re-doing the tx is kind of a must (or the other party can refuse to contribute funds on the RBF if they don't like the feerate)
12:53 < cdecker> Not exactly, we restart from the beginning and the feerate is shared by both parties
12:54 < ariard> we had this interesting discussion with dlc, which is dual-funded from beginning, if the fundee should compensate funder with a premium fee for mempool congestion aleas
12:54 < ariard> i don't propose to introduce such thing rn we might think about it in the future
12:54 <+roasbeef> so with funding rbf, impl wise both sides need to be ready to ensure they can act if any of the prior versions confirms right? 
12:55 < BlueMatt> side-note- what time{,zone} is this meeting, anwyway? my calendar entry *was* off...
12:55 <+roasbeef> BlueMatt: I think it's adelaide time 
12:55 < rusty> ariard: we have extra flexibility, since there's always the option of withdrawing your funds from channel....
12:55 < niftynei> roasbeef, yes that's correct. it's a lot like splicing in that way
12:55 < rusty> Indeed, which means NEXT MEETING will be 1 hour different in UTC BTW.
12:55 < BlueMatt> roasbeef: huh. what time adelaide? google and local cilents disagree :/
12:55 < ariard> rusty: right you might be more interested to keep going the confirmation attempt as you're economically interested by this channel attempt
12:56 <+roasbeef> gotcha cool, we we're looking to impl something similar on the context of pool to be able to implement batch cut-through (so compressing N unconfirmed batches into a single transaction) 
12:56 < rusty> BlueMatt: 5:30am Adelaide.
12:56 < ariard> though fee bumping doesn't have to as aggresive that for justice transaction
12:57 < t-bast> niftynei: zooming out a bit and going through the PR quickly, did you solve how that could be used as an oracle to discover someone's utxos?
12:57 < rusty> roasbeef: yeah, because it's (bascially) a complete renegotiation (with req that fees increase by at least 25%) you can mix and match existing ones.
12:57 < niftynei> no i punted based on the email discussion from lloyd fournier/rusty wrt to PoDLEs versus signed 'bond' txs
12:58 < rusty> t-bast: yes, Lloyd convinced me that it wasn't worth the trouble for the short term, given the number of other ways to identify channel UTXOs.  Mainly because it's easy to add later...
12:58 < niftynei> the general take away was that your onchain privacy isnt' very good anyway; we can implement PoDLEs later to mitigate
12:58 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Quit: Leaving]
12:59 < niftynei> it's very straightforward to add later on
12:59 < t-bast> ok, thanks, good to know
13:00 < cdecker> Sounds like we got some homework to go through the DF spec :-)
13:01 < niftynei> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-January/002938.html
13:01 < niftynei> lloyd's email ftr
13:01 < niftynei> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-January/002938.html
13:01 < ariard> yeah i'll try to finish my review soon, some small recommendations around standardness in mind
13:01 < t-bast> thanks for the link
13:01 < niftynei> np! it's a great thread
13:02 < niftynei> if there's nothing else, happy to cede the floor to the next topic :)
13:03 <+roasbeef> niftynei: so conclusion is that leaking balances or w/e via failed funding init attempts isn't that big of a deal in practice so no mitigations in current version?
13:03 < cdecker> One thing we should point out is that the funding tx malleation can no longer happen with the dual-funding proposal 👍
13:03 < ariard> rusty: wanna talk about offers :) ?
13:03 < rusty> ariard: always!
13:03 < cdecker> #topic Long Term Updates: Offers
13:03 < ariard> you have the mic!
13:03 <+roasbeef> cdecker: isn't that the case rn? since we require segwit inputs, err well it's in the best interest of the funder to do that 
13:04 < ariard> we might need to require disclosure of witnessScript to avoid standardness malleability
13:04 < cdecker> well in theory, but both eclair and c-lightning had users malleate their funding txs through RBF
13:04 <+roasbeef> ahhh yeh you can't rbf it, gotta cpfp it
13:05 <+roasbeef> we had ppl do that via electrum as well unfortunately when using psbt for funding 
13:05 < t-bast> that's exactly what happened to some of our users as well...that "bump fee" button in electrum was too tempting for them and we had no way of preventing them from doing it
13:05 <+roasbeef> ariard: if it confirms, it confirms tho right? assuming you're not doing zero conf
13:05 <+roasbeef> yeh we helped manually rescue a few instances of that in the past 
13:06 < niftynei> roasbeef, the conclusion is that you're already leaking your balances so having one other vector for it is something we can mitigate later
13:06 < ariard> roasbeef: yeah it's more someone not liking your big routing node and preventing transactions propagation for a while
13:06 < ariard> until you double-spend your own utxos
13:06 < rusty> So there are three parts to offers: 1. onion messages, which are pretty simple to implement, 2. parsing and converting offers to invoices, and 3. actually implementing creation of offers and producing invoices.
13:06 < ariard> that kind of risk should be considered if your dual-funded inputs aren't of equal value
13:07 < rusty> Turns out, if you just want to pay an offer you can pretty much do on top of any existing implementation: you just need to connect directly to the offering node and ask for the invoice.  That's pretty dumb (from a privacy POV unless Tor), but it "works".
13:08 < rusty> Ideally we get onion messages rolled out so this isn't required, but it'll be a fallback for a while.
13:08 <+roasbeef> so ln-url style basically? 
13:08 < rusty> roasbeef: yeah, except a lightning connection instead of https.
13:09 <+roasbeef> I guess that could be rendezvoused in theory lol
13:09 <+roasbeef> also called a "proxy" :p 
13:09 < rusty> roasbeef: yeah....
13:09 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Quit: jonatack]
13:09 < niftynei> ariard: more than one open in the same tx would mitigate it also
13:09 < rusty> There are two spec changes I'm considering though.  1. remove the reply from the onion message format.  At the moment you can put a reply path in there, but you can also just put it in the actual message payload.  THis would simplify the spec even further, but means if they can't parse the message your SOL.
13:09 < ariard> niftynei: can't parse ? can you explain further :)
13:10 < rusty> ariard: you can't get a reply for a malformed/unsupported onion_message payload.
13:10 < ariard> niftynei: let's talk about it on the pr
13:11 < BlueMatt> rusty: how did replies work before if you can't parse the message? presumably only if you can partially-parse it? or failed back via intermediate state?
13:11 < ariard> rusty: sorry we're blurring subjects was a reply to niftynei
13:11 < rusty> BlueMatt: layering.  The onion message itself has a TLV, one of which is the reply path.
13:12 < rusty> BlueMatt: but turns out many payloads want to include a reply path themselves for other reasons.
13:12 < BlueMatt> right, ok, so you'd have to have parsed the message message, just the message itself is bunk.
13:12 < rusty> BlueMatt: yeah,or unsupported.
13:13 < BlueMatt> right, ok. NAKs generally ~whatever for me, but, continue.
13:13 < rusty> The other change is that I use the (merkle) hash of the invoice as the payment_secret.  This is dumb: we are falling back on the idea that the invoice is kept secret, which is a hack.  
13:14 < rusty> For offers, we *have* a payer_key: ideally we'd have a new field in the onion which was the signature using that key of the onion's mu-key (or something else which is tied to this specific HTLC onion).
13:15 < t-bast> that's an interesting idea
13:16 < rusty> The final thing is bolt12-bolt11 invoice compat to convert (at least the simple cases!) between the two.  THis means defining a mapping and including the sigs for the other style (bolt11 sigs are v. v. tied to the format, bolt12 are much saner).
13:16 < BlueMatt> do we have to support mapping?
13:17 < BlueMatt> is that just to provide wrappers for old nodes to send to new ones?
13:17 < rusty> BlueMatt: no, it's just a bridge.
13:17 < rusty> BlueMatt: yeah, it would let you gateway for simple offers.
13:18 < BlueMatt> sounds like a lot of complexity we'd eventually remove, but, sure, making it optional, up to you
13:18 < rusty> Any questions?  Especially of the stlye "um, what are you talking about?"
13:18 <+roasbeef> what's the payer key thing exactly? and what's it achieve?
13:18 <+roasbeef> i also don't get why a new invoice format is needed if the existing on can be extended, tho I'm all for getting rid of the weird 5 word byte stuff and uncessary usage of bech32 in the existing one
13:19 < rusty> roasbeef: it's a transient key given by the payer as part of the req for the actual invoice.  Allows recurrence privacy, refunds, proof-of-payer....
13:19 <+roasbeef> which is then *included* in the final invoice?
13:19 < rusty> roasbeef: yeah, I originally started extending bolt11 but hit those same....
13:20 < rusty> roasbeef: yeah: by design, everything you need is in the final invoice so you don't actually need to keep the offer if you didn't want to.
13:20 <+roasbeef> is a bridge in the other direction possible? so just giving them a bolt 11 invoice yet still being able to complete the from the pov of the "offer", thinking about wallet that have slow uptake of new features here
13:21 <+roasbeef> guessing yeh if there're no new tlv records added in the onion payload? 
13:21 -!- smartineng [~Icedove@88.135.18.171] has quit [Quit: smartineng]
13:22 < rusty> roasbeef: yeah, but it's so much easier for them to parse bolt12 than bolt11.  Could do it though.
13:23 < t-bast> how much work do you estimate it takes to get a prototype running from scratch, if an implementation wanted to start from nothing and prototype it by going through the spec PR?
13:23 -!- t-bast [~t-bast@2a01:cb19:706:cb00:cdc0:809c:a013:e5c0] has quit [Remote host closed the connection]
13:23 < rusty> (Heh, I guess he didn't want to hear the answer!)
13:23 -!- t-bast [~t-bast@2a01:cb19:706:cb00:cdc0:809c:a013:e5c0] has joined #lightning-dev
13:24 < rusty> t-bast: ... and that's how simple it is!  Any questions?
13:24 <+roasbeef> lol
13:24 <+roasbeef> yeh seems feasible 
13:24 < t-bast> sorry I got dc-ed and missed that!
13:24 < ariard> Or maybe he just get started
13:24 <+roasbeef> actually I just finsihed it 
13:24 < t-bast> looks like even my IRC client doesn't want us to work on offers xD
13:24 < rusty> t-bast: was joking.  Parsing offers is trivial, it's a de-bech32 then it's lightning wire format.
13:25 < rusty> t-bast: handling bolt11 vs bolt12 invoices was simple too, they're very distinct.  The actual onion and HTLC is the same.
13:25 < t-bast> LOL just saw the logs from http://gnusha.org/lightning-dev/
13:27 < t-bast> I'm mostly thinking that understanding and implementation the tree construction may be the part where you scratch your head a bit, right?
13:27 <+roasbeef> what's the purpose of the tree thing? basically picking off where we left off re the "description hash" in bolt 11? 
13:28 < rusty> t-bast: actually issuing offers is a command to do so; that's a pretty big API.  The code to receive the onion message requesting an offer, and generating the invoice associated is straightforward, but there are also "send0me-money" offers, which have atomicity requirements: you only want to send them the payment once.
13:29 < rusty> roasbeef: it's mainly for signing (though we use it as an "id" as well); it's a bit more complex than a linear hash, but it allows much more neatly for omitting signature field(s).
13:29 < rusty> (i.e. merkle calc omits any TLVs 250-1000 incl).
13:30 < rusty> Has nice side effect that you can (handwave, future) provide proofs without revealing entire thing.
13:32 < rusty> TBH, most of the work was not implementing, but exploring the space and adding requirements.  Things like recurrence and offer -> invoice malleability (i.e. offer has a description, invoice returned had a different description, but also amounts, etc)
13:32 < rusty> Any other questions?
13:33 < ariard> *tagging this as a "good first issue" in RL
13:33 < t-bast> Nope, looks interesting, I'm hoping we'll get time to work on this soon :)
13:34 < rusty> Yeah, I'm excited to get other implementer feedback.  Both on text of spec, and all the random details where I just flipped a coin....
13:34 < rusty> ariard: you have the chair again :)
13:34 < ariard> rusty: thanks for the presentation :)
13:35 < ariard> folks wants to keep the meeting with another topic?
13:35 < cdecker> I think I'll have to drop off pretty soon
13:35 <+roasbeef> g2g on my end
13:35 < ariard> okay let's end there 
13:35 < t-bast> I'll drop off as well
13:36 < ariard> #endmeeting
13:36 < lndev-bot> Meeting ended Mon Mar 29 20:36:01 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:36 < lndev-bot> Minutes:        https://lightningd.github.io/meetings/lightning_march/2021/lightning_march.2021-03-29-19.03.html
13:36 < lndev-bot> Minutes (text): https://lightningd.github.io/meetings/lightning_march/2021/lightning_march.2021-03-29-19.03.txt
13:36 < lndev-bot> Log:            https://lightningd.github.io/meetings/lightning_march/2021/lightning_march.2021-03-29-19.03.log.html
13:36 <+roasbeef> on the lnd side we should have some concrete stuff to discuss on teh AMP side next time around 
13:36 < niftynei> tchau pessoal!
13:36 < t-bast> Thanks ariard for chairing! And thanks everyone for your time and discussions
13:36 < ariard> see you all on the repo :)
13:36 < t-bast> roasbeef: cool, it will be interesting to see what's new with AMP
13:36 < cdecker> Thanks ariard for chairing, good meeting everyone 👍
13:36 <+roasbeef> t-bast: most recent stuff is mkaing probing easier, and also possibly adding a payment level ACK that would work for mpp as well 
13:37 <+roasbeef> re probing you can send a final invalid share to force them to fail things back, so you can do a probe to fulfill a regular invoiced mpp payment 
13:37 <+roasbeef> then we can maybe extend that further by adding the ability to send say a 1 msat or min-flow-along-route "tracer" payment that's to be failed back once the real HTLC arrives at the toher side 
13:38 <+roasbeef> so senders can finally get feedback w.r.t end to end node processing latency, and know if a payment shard has arrived or is just stuck in limbo somewhere 
13:38 <+roasbeef> it's kiiinda hacky, but easier to deploy than a new msg that implements the payment level ACK, since only the sender+receiver need to know about it 
13:38 <+roasbeef> tradeoff ofc is that extra htlc slot it can consume w/ the current limits 
13:39 < vincenzopalazzo> Thanks you guys :-D
13:47 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
13:48 -!- Thomashuet [~thomas@78.196.22.221] has quit [Quit: leaving]
13:49 -!- laptop [~laptop@ppp-1-45.leed-a-2.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]
13:49 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
13:59 -!- joost [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Quit: Leaving]
14:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
14:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
14:08 <+roasbeef> re the "just send the priv key" thing above, what about situations where the wallet/daemon/user can't easily access the private key? 
14:09 <+roasbeef> like say they used ck bunker to jerry rig their cold card as an external signer 
14:19 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Ping timeout: 252 seconds]
14:20 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined #lightning-dev
14:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
14:46 -!- sstone [~sstone@112.ip-51-68-199.eu] has quit [Quit: Leaving]
15:01 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
15:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
15:02 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
15:02 -!- yzernik [~yzernik@107-194-14-24.lightspeed.miamfl.sbcglobal.net] has joined #lightning-dev
15:03 -!- pm7_ [pm7@gateway/shell/mydevil.net/x-konnipuiuhvlzfdx] has quit [Read error: Connection reset by peer]
15:03 -!- pm7 [pm7@gateway/shell/mydevil.net/x-xllnrojjgetcnaxl] has joined #lightning-dev
15:05 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
15:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
15:08 < ariard> roasbeef: that's a good point but it's not like L2 hardware signers are ready, we might be early enough to invite vendors to integrate SIGHASH_SEND_KEY in their APIs ?
15:21 <+roasbeef> ariard: aren't they? I mean if you just want to do dumb signing on a stick, that gets you isolation at the very least and can be rolled out 
15:21 <+roasbeef> lol @ SIGHASH_SEND_KEY 
15:22 -!- vincenzopalazzo [~vincenzop@host-95-249-217-78.retail.telecomitalia.it] has quit [Quit: Leaving]
15:22 -!- deusexbeer [~deusexbee@080-250-076-051-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 246 seconds]
15:23 -!- deusexbeer [~deusexbee@080-250-076-051-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev
15:23 <+roasbeef> like today someone could use AWS KMS to generate secp256k1 signatures if they really wanted to 
15:46 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
15:47 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
15:47 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:53 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
16:01 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev
16:04 -!- RonNa [~quassel@60-251-129-61.HINET-IP.hinet.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
16:04 -!- RonNa [~quassel@60-251-129-61.HINET-IP.hinet.net] has joined #lightning-dev
16:05 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
16:05 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
16:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
16:06 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
16:33 < ariard> right, i'm thinking something more semantic-aware, where they know they're signing transactions not random blobs of data
16:36 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
16:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
16:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
16:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
16:37 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
16:38 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
16:40 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Ping timeout: 240 seconds]
17:23 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
17:40 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined #lightning-dev
17:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:43 -!- molz_ [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 268 seconds]
17:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
17:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds]
18:13 -!- ddustin_ [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
18:14 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
18:15 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 245 seconds]
18:18 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #lightning-dev
18:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:34 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
18:34 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
18:34 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
18:35 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
18:40 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
18:42 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
18:44 -!- deusexbeer [~deusexbee@080-250-076-051-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 240 seconds]
18:57 -!- tim_ [~tim@64.187.172.91] has joined #lightning-dev
18:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
19:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
19:16 -!- tim_ [~tim@64.187.172.91] has left #lightning-dev []
19:43 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 250 seconds]
19:45 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #lightning-dev
20:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
20:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev
20:23 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]
20:45 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
20:46 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
20:46 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
20:47 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
20:47 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
20:47 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
20:47 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
20:48 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
20:50 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
21:17 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
21:17 < lnd-bot> [lightning-rfc] rustyrussell opened pull request #858: BOLT 4: remove space in formatting which prevented tools/extract-formats.py (master...bolt4-channel_disabled-field-formatting) https://github.com/lightningnetwork/lightning-rfc/pull/858
21:17 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
21:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
21:46 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
21:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 268 seconds]
21:55 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
22:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
23:08 -!- Xaldafax [~Xaldafax@cpe-198-72-160-101.socal.res.rr.com] has quit [Quit: Bye...]
23:33 -!- k1ltzman [~k1ltzman@195.189.99.96] has quit [Ping timeout: 240 seconds]
23:50 -!- t-bast [~t-bast@2a01:cb19:706:cb00:cdc0:809c:a013:e5c0] has quit [Quit: Leaving]
23:50 -!- t-bast [~t-bast@2a01:cb19:706:cb00:cdc0:809c:a013:e5c0] has joined #lightning-dev
23:51 -!- t-bast [~t-bast@2a01:cb19:706:cb00:cdc0:809c:a013:e5c0] has quit [Client Quit]
--- Log closed Tue Mar 30 00:00:10 2021