--- Log opened Fri Apr 29 00:00:05 2022 --- Day changed Fri Apr 29 2022 00:00 < realtbast[m]> So no-one can do anything once you broadcast the tx? 00:00 < realtbast[m]> The APO sigs are only for partial signatures IIRC 00:00 < realtbast[m]> Similar to what we do today for HTLCs with anchor outputs 00:00 < realtbast[m]> But I haven't looked at eltoo in a while, so I may be wrong 00:04 -!- remyers[m] [~richshind@2001:470:69fc:105::1:6f78] has joined #lightning-dev 00:07 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 00:07 < _aj_> jeremyrubin: add a chaperone signature if your concern is random third parties tweaking the tx. i think the pinning problem still exists if it's your counterparty pinning the tx though 00:10 < jeremyrubin> not nesc? 00:10 < jeremyrubin> I mean if you have an APO ratchet update for 2 parties, sighash_all, and 2 cpfp anchor outs 00:11 < jeremyrubin> the only source of pinning seems to be that you can add arbitrary inputs onto that 00:11 < _aj_> if you pin an eltoo state tx, then you can probably prevent your counterparty from claiming a [ph]tlc before it expires 00:11 < jeremyrubin> yes this sounds bad 00:12 < jeremyrubin> so it sounds like APO needs to be tweaked to e.g. commit to a feerate or something? 00:12 < yakshaver> as long as you can add feels at commit time, then your counter party can add a fat input to pin the tx 00:12 < yakshaver> s/feels/fees 00:13 < _aj_> oh, is that true? 00:13 < jeremyrubin> yes 00:13 < jeremyrubin> afaict 00:14 < _aj_> great, then pinning is a relay problem not an eltoo problem 00:14 < yakshaver> in LN-penalty its with fat CPFP to anchor outputs, but for eltoo it's via RBF of the commit tx with bring-your-own-fee inputs 00:15 < yakshaver> it does seem like relay policy will be needed here 00:15 < jeremyrubin> it still sounds like an eltoo issue? 00:15 < yakshaver> how so? 00:15 < jeremyrubin> just make it so that you can't add more inputs to these txns 00:15 * jeremyrubin and then add tx sponsors, he whispered 00:16 < yakshaver> you sign your commit tx with sighas signal so you can BYOF at commit time (signed with sighash all) 00:16 < yakshaver> sighash single that is 00:16 < yakshaver> you have to add inputs because the full output of the commit tx must be used otherwise there's fee siphoning 00:20 < jeremyrubin> but that creates pinning 00:20 < yakshaver> while we're on the topic of fees, I really like the idea of SIGHASH_GROUP for the settlement tx of eltoo - that would allow you to use the committed to_self output to pay fees 00:20 < jeremyrubin> you could do package relay + anchor outs + 0 fee outs 00:20 < jeremyrubin> *0 value 00:21 < yakshaver> anchor outputs create pinning via CPFP right? 00:22 < jeremyrubin> nope, not under LN carve out 00:24 < yakshaver> does the carve out apply to RBF of an eltoo commit tx with BYOF inputs? 00:25 < jeremyrubin> no idea 00:25 < jeremyrubin> what's BYOF 00:25 < jeremyrubin> oh 00:26 < jeremyrubin> if you have to dynamically resize them due to SIGHASH_ALL, then no i think since it only applies to txns with conf'd parents IIRC 00:26 < yakshaver> I'm using the short hand bring-your-own-fee to mean you add inputs/outputs to pay fees for a sighash_single APO tx 00:28 < jeremyrubin> gotcha.. that is always vulnerable to pinning 00:30 < yakshaver> so if your counter party submits a package with max package size that spends the eltoo state output, you can use the carve out to RBF with a different package with higher total+fee rate that spends the same state output right? 00:31 < _aj_> i think the existing carve out only allows you to add a CPFP child, to get the parent mined without being replaced? 00:31 < yakshaver> the carve out is for CPFP, but for RBF you just need to beat rule #3 total fee and rate, right? 00:34 < yakshaver> for ln penalty you can't rewrite the tx without your counterparty, so you need to use CPFP to add fees 00:35 < yakshaver> for eltoo, if my understand of RBF rules is correct, you can create a new tx that has different BYOF input/outputs and beats the pinned commit tx 00:38 < yakshaver> the 2nd stage of eltoo is similar to ln-penalty because there are settled outputs without a timelock for each party that you can use as built in anchor outputs 00:56 < vincenzopalazzo> realtbast: I added a timeline issue about bol2 https://github.com/lightning/bolts/issues/985 so we can avoid confusion at the next meeting! 00:56 < realtbast[m]> Thanks! I'll have a look at it before the next spec meeting ;) 00:58 < vincenzopalazzo> If any problem ping me when you want! 00:59 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 01:03 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Quit: Konversation terminated!] 01:04 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 256 seconds] 01:08 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has quit [Remote host closed the connection] 01:08 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has joined #lightning-dev 01:13 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has quit [Remote host closed the connection] 01:14 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has joined #lightning-dev 02:14 -!- Ghulie [~Ghulie@gateway/tor-sasl/ghulie] has quit [Ping timeout: 240 seconds] 02:27 -!- faceface [~faceface@user/faceface] has joined #lightning-dev 02:49 -!- greypw2546 [~greypw254@grey.pw] has quit [Quit: I'll be back!] 02:49 -!- greypw2546 [~greypw254@grey.pw] has joined #lightning-dev 02:52 -!- rusty [~rusty@210.185.125.71] has joined #lightning-dev 03:00 -!- rusty [~rusty@210.185.125.71] has quit [Quit: Leaving.] 03:00 -!- rusty [~rusty@210.185.125.71] has joined #lightning-dev 03:44 -!- An0rak [An0rak@user/an0rak] has joined #lightning-dev 04:08 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 04:39 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 05:03 < cdecker[m]> realtbast: looking to test my zeroconf implementation (possibly locally) against Eclair next week. Is your zeroconf impl merged into `master` and how do I configure it to get started? 05:05 < realtbast[m]> cdecker: we have a draft PR (https://github.com/ACINQ/eclair/pull/2224) but I don't think it's ready yet...you should probably test against ldk or lnd, I believe they have a more complete implementation than ours! 05:06 < cdecker[m]> Gotcha, just had most experience with eclair so I defaulted to that, will look into LDK then ^^ 05:08 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 05:15 < cdecker[m]> I see all other implementations chose to actually implement `option_scid_alias`, while I'm implementing `option_zeroconf` without that (aliases used in `channel_ready` and `invoices` until we have a real scid), so this should be interesting ^^ 05:17 < realtbast[m]> Perfect, that's a good way of testing that the two features should be somewhat independent! 05:18 < realtbast[m]> We'll ping you when we're ready to do some cross-compat tests with c-lightning (is your code merged on `master` or shall we use a branch?) 05:30 < jeremyrubin> I don't think the carve out works like that 05:31 < jeremyrubin> Because it primarily protects you from descendants not from the parent being pinned 05:31 < jeremyrubin> Pinned directly 05:37 < darosior> yakshaver: "you can create a new tx that has different BYOF input/outputs and beats the pinned commit tx" -> you need to meet the absolute fees, so you are screwed if your counterparty inflates the transaction size. Which they can always do if you allow them to BYOF without a limit on the number of inputs. (And if you allow them to add outputs it's 05:37 < darosior> even worse.) 05:37 < darosior> Anyways jeremyrubin it's true that as defined and by Bitcoin Core's relay policy Eltoo transactions can be pinned. I don't think it should have an influence on doing APO. 05:41 < remyers[m]> darosior: do you mean that for eltoo a malicious counter party can cause you to spend an arbitrarily amount of absolute fees to unpin a commitment tx? 05:42 < darosior> remyers[m]: yes, and if you do it costs them nothing 05:42 < remyers[m]> and for ln-penalty is the same true? 05:42 < darosior> For ln-penalty the signatures commit to all the inputs 05:42 < darosior> So, no 05:44 < remyers[m]> but to use CPFP via anchor outputs your child must pay enough fees to bump the pinned tx, which can require high fee to pump a large tree on your counter parties anchor output, if I understand this right 05:54 < remyers[m]> I'll take a stab at diagramming this out so we can make sure we're all on the same page 05:59 < darosior> Let's take ln-penalty and commitment transactions. The commitment transaction size can only be inflated up to your max htlcs limit. Nobody can unilaterally inflate it (as it's the case with BYOF). So here to CPFP the child has to pay for the size of the commitment transaction, but it's not insane (if you don't want it to be). Now, there was another 05:59 < darosior> pinning scenario here were your counterparty would pin the child transaction (that they control and therefore *can* inflate) whether with max size or max number of descendants. The carve out hack allows to always have an exception to these rules if you spend directly from the first tx in the chain (here the commit tx) and your tx isn't too large 05:59 < darosior> and doesn't add more dependencies. This is why the anchor outputs spec specifies an output always available to each party for time-sensitive transactions. (But not more! Otherwise one party can unilaterally exhaust the carve-out rule!) 06:14 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 06:15 < realtbast[m]> So the issue is that eltoo doesn't use anchor outputs, but instead lets each participant add inputs/outputs? So Alice cannot even know Bob's commitment txid and couldn't even "blindly" spend an anchor from Bob's commitment tx? 06:15 < realtbast[m]> And even if she was able to blindly CPFP Bob's commitment, since Bob can arbitrarily inflate the size of this tx, Bob is forcing Alice to pay a huge amount of fees 06:16 < realtbast[m]> I can see why that is an issue and is worse than LN-penalty. But can't Eltoo adapt its model to address that? 06:18 < realtbast[m]> It sounds like it's time to dive into the details of eltoo txs and what parts of the design are open to changes that could address this concern 06:20 < remyers[m]> I agree - this idea of adding inputs/outputs is not set in stone. what is important though is that each update tx does not take fees from the channel balance because there can be multiple intermediate updates before the final one. 06:22 < darosior> Yeah but BYOF is so much cleaner.. If only APO could somehow optionally commit to the number of inputs in advance to prevent that :/ *looks around* 06:23 < realtbast[m]> With something like SIGHASH_GROUP it would be nice, we would still offer some flexibility while restricting enough to prevent pinning 06:24 < instagibbs> darosior, sighash_double :P 06:24 < darosior> :) 06:24 < remyers[m]> with sighash_group there's also the possibility to pay for fees of the 2nd level settlement tx from already settled balances 06:24 < darosior> _aj_: wen sighash_group 06:24 < remyers[m]> with annex anything is possible right? 06:27 < remyers[m]> if each party had a fee paying input is signed with APOAS then perhaps you wouldn't have to pre-allocate fees.. 🤔 06:37 < instagibbs> anchor outputs of size 0 for each update, standardness rules require sweeping, handwave handwave, package relay 06:39 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 06:48 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 06:54 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Quit: ZNC - https://znc.in] 06:55 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 07:38 < _aj_> instagibbs: you don't need anchor outputs with sighash_group since you can add your own inputs/outputs already 07:39 < instagibbs> _aj_, I'm not assuming another consensus change 07:39 < instagibbs> but it's a bad idea :) 07:39 < _aj_> instagibbs: oh, i thought you were replying to "wen sighash_group" 07:40 < jeremyrubin> instagibbs that would help if we had a must spend 0 sat package relay rule 07:40 < instagibbs> jeremyrubin, yes h/t your email, but ?I think it doesn't work still for this application 07:40 < instagibbs> you'd have two anchors that would both have to be pre-swept(?) 07:41 < jeremyrubin> I think the best path, and sorry that it's my concept this isn't the motive here, is something like sponsors + eltoo 07:41 < jeremyrubin> Because then you can externally do a tx that cannot pin the main eltoo tx body 07:43 < _aj_> you're assuming adding sponsors doesn't introduce new pinning vectors, and i expect it would... 07:44 < jeremyrubin> Worth analyzing 07:44 < jeremyrubin> Do you think it's impossible to make a secure version of a sponsor like thing? 07:47 < instagibbs> seems like our non-spherical mempool may include some surprises for any proposal at this point 07:48 < _aj_> i don't think there's anything much fundamentally different between sponsors and sighash_group, except that one has a tx boundary and the other a block boundary 07:49 < jeremyrubin> The issue here is that the tx boundary is kinda important, since it means that the parent txn is fixed in the mempool and bumps are external to that 07:49 < jeremyrubin> Whereas with group you need to replace the parent 07:50 < _aj_> txs aren't fixed in the mempool any more than packages are fixed in the mempool 07:50 < jeremyrubin> Which maleates all other descendants, and also makes the logic of bundling rebundling something miners would need code to do 07:50 < jeremyrubin> Fixed maybe the wrong word. 07:51 < jeremyrubin> The same literal txn may stay in the mempool 07:51 < jeremyrubin> Whereas with group any time there's a bump it's now a diff txn 07:51 < jeremyrubin> So you trigger replacement rules too 07:51 < _aj_> sure, the same is true of rbf in general 07:52 < _aj_> so anytime you bump a tx that's been sponsored, you unsponsor all the other txs that were sponsored 07:52 < jeremyrubin> What? 07:53 < jeremyrubin> Ah are you assuming multi sponsors 07:53 < jeremyrubin> The proposal I put out for it is limited to single sponsor 07:54 < jeremyrubin> instagibbs make the mempool spherical plz 07:54 -!- preemz [~preemz@71.153.12.221] has joined #lightning-dev 07:54 < instagibbs> jeremyrubin, your lips to god's ears 07:55 < _aj_> single sponsor? tx Y can only sponsor a single tx X? 07:55 * jeremyrubin whispers I want a vacation and 2 more wishes 07:55 < jeremyrubin> _aj_: yep 👍 07:55 < instagibbs> I'd have to re-read yet another proposal, but I suspect we could rewrite BIP!25 to let through sighash_group related bumping shenanigans in some limited way too? 07:56 < _aj_> jeremyrubin: gross 07:56 < jeremyrubin> Not for consensus just policy 07:56 < jeremyrubin> If we figure out how to make the mempool work we can expand it 07:56 < _aj_> jeremyrubin: okay, i'll downgrade to lame 07:57 < instagibbs> step 1: fix mempool step 2: cash in 07:57 -!- yonson [~yonson@2600:8801:d900:0:529a:4cff:fe65:a337] has joined #lightning-dev 07:57 < jeremyrubin> As someone who has spent 3 years trying to get even vulns fixed in the mempool, good luck 😂 07:59 < jeremyrubin> My guess is the best way to do this would be to have >1 mempool, which is a big conceptual leap. 07:59 < jeremyrubin> And have the different mempool have very different rules, but have those rules be uniformly enforced. 07:59 < jeremyrubin> And let mining code do conflict resolution and optimization 08:01 < jeremyrubin> The current approach of 1 mempool with various carve outs and exceptions is sorta very bad, it should be one way in, two ways out. 08:02 < jeremyrubin> But maybe a separate discussion 08:02 < jeremyrubin> I'm very non bullish on us figuring out better mempool is all you need to know, we need more tactical SMEs ;) 08:03 < jeremyrubin> I was hoping the chaincode research was going to focus on this, but they went more in the profit angle 08:20 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 08:20 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 08:29 -!- jespada [~jespada@89.238.130.78] has quit [Ping timeout: 276 seconds] 08:30 -!- jespada [~jespada@cpc121022-nmal24-2-0-cust171.19-2.cable.virginm.net] has joined #lightning-dev 08:39 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:ec13:1a38:3dba:1cfa] has joined #lightning-dev 09:45 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 09:49 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 09:55 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:ec13:1a38:3dba:1cfa] has quit [Quit: Client closed] 10:07 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 10:08 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 10:29 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 10:31 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 10:35 -!- Guest23 [~Guest23@136.49.133.36] has joined #lightning-dev 10:35 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 10:37 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 10:38 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 10:41 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 10:41 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 10:41 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 10:42 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 10:48 -!- Guest23 [~Guest23@136.49.133.36] has quit [Quit: Client closed] 10:48 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 10:49 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 10:53 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 10:53 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 240 seconds] 11:00 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 11:21 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Quit: Konversation terminated!] 11:22 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 11:33 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Quit: Konversation terminated!] 11:33 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 11:39 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 11:45 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 240 seconds] 11:55 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 12:00 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 256 seconds] 12:22 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 12:42 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 12:49 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 13:06 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 250 seconds] 13:34 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection] 13:34 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 13:35 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 13:35 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 13:56 -!- preemz [~preemz@71.153.12.221] has quit [Ping timeout: 260 seconds] 13:59 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 14:29 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection] 14:29 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 14:30 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 14:37 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 14:44 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 14:50 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #lightning-dev 15:18 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...] 15:39 < ariard> re-eltoo + pinning, i still hope concerns go away if we move to replace-by-ancestor-score :) 15:53 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 16:27 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds] 16:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:18 < jeremyrubin> can't be build security on hope ;) 17:18 < jeremyrubin> ariard do you have a writeup on how rbas and malleable inputs works? 17:18 -!- rusty [~rusty@210.185.125.71] has quit [Read error: Connection reset by peer] 17:18 -!- rusty [~rusty@210.185.125.71] has joined #lightning-dev 17:21 -!- rusty [~rusty@210.185.125.71] has quit [Read error: Connection reset by peer] 17:21 -!- rusty [~rusty@210.185.125.71] has joined #lightning-dev 17:24 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev 17:27 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds] 17:30 -!- rusty [~rusty@210.185.125.71] has quit [Quit: Leaving.] 17:30 -!- rusty [~rusty@210.185.125.71] has joined #lightning-dev 17:33 -!- rusty2 [~rusty@210.185.125.71] has joined #lightning-dev 17:34 -!- rusty [~rusty@210.185.125.71] has quit [Ping timeout: 256 seconds] 17:40 -!- rusty2 [~rusty@210.185.125.71] has quit [Ping timeout: 272 seconds] 17:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 240 seconds] 17:43 -!- rusty [~rusty@210.185.125.71] has joined #lightning-dev 17:44 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 17:50 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 272 seconds] 18:00 -!- rusty [~rusty@210.185.125.71] has quit [Quit: Leaving.] 18:16 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 18:18 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 18:20 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 18:35 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 19:08 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 19:13 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 276 seconds] 19:37 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 19:43 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 256 seconds] 19:55 -!- preemz [~preemz@73.58.92.183] has joined #lightning-dev 20:36 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 20:42 -!- bucko [~bucko@136.49.133.36] has quit [Ping timeout: 272 seconds] 20:49 -!- bucko [~bucko@136.49.133.36] has joined #lightning-dev 21:04 -!- bucko [~bucko@136.49.133.36] has quit [Remote host closed the connection] 21:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Remote host closed the connection] 21:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 21:18 -!- preemz [~preemz@73.58.92.183] has quit [Ping timeout: 276 seconds] 21:35 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev 21:38 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Read error: Connection reset by peer] 22:26 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has joined #lightning-dev 22:35 -!- bucko [bucko@gateway/vpn/protonvpn/bucko] has quit [Ping timeout: 272 seconds] --- Log closed Sat Apr 30 00:00:09 2022