--- 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