--- Log opened Mon Aug 02 00:00:26 2021
00:43 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 272 seconds]
00:59 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
02:54 -!- rusty [~rusty@103.93.169.121] has joined #lightning-dev
03:26 -!- AaronvanW [~AaronvanW@45.161.24.77] has joined #lightning-dev
03:31 -!- AaronvanW [~AaronvanW@45.161.24.77] has quit [Ping timeout: 272 seconds]
03:32 -!- livestradamus [~quassel@user/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
03:32 -!- livestradamus [~quassel@user/livestradamus] has joined #lightning-dev
03:43 -!- livestradamus [~quassel@user/livestradamus] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
03:43 -!- livestradamus [~quassel@user/livestradamus] has joined #lightning-dev
03:58 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection]
03:58 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev
04:47 -!- AaronvanW [~AaronvanW@45.161.24.66] has joined #lightning-dev
04:51 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:04 -!- Aaronvan_ [~AaronvanW@45.161.24.69] has joined #lightning-dev
05:04 -!- AaronvanW [~AaronvanW@45.161.24.66] has quit [Ping timeout: 265 seconds]
06:08 -!- Aaronvan_ [~AaronvanW@45.161.24.69] has quit [Remote host closed the connection]
06:34 -!- AaronvanW [~AaronvanW@45.161.24.66] has joined #lightning-dev
06:39 -!- AaronvanW [~AaronvanW@45.161.24.66] has quit [Ping timeout: 265 seconds]
06:58 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:9961:ea6b:a3cc:5490] has joined #lightning-dev
08:19 -!- AaronvanW [~AaronvanW@45.161.24.77] has joined #lightning-dev
08:34 -!- AaronvanW [~AaronvanW@45.161.24.77] has quit [Ping timeout: 272 seconds]
08:44 -!- jarthur [~jarthur@2603-8080-1540-002d-55f9-cce3-ab9e-b140.res6.spectrum.com] has joined #lightning-dev
08:48 -!- jarthur_ [~jarthur@2603-8080-1540-002d-e09d-5ac8-afbf-2237.res6.spectrum.com] has joined #lightning-dev
08:50 -!- jarthur [~jarthur@2603-8080-1540-002d-55f9-cce3-ab9e-b140.res6.spectrum.com] has quit [Ping timeout: 272 seconds]
08:55 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 272 seconds]
09:42 -!- jarthur_ is now known as jarthur
10:05 -!- AaronvanW [~AaronvanW@45.161.24.77] has joined #lightning-dev
10:11 -!- AaronvanW [~AaronvanW@45.161.24.77] has quit [Ping timeout: 272 seconds]
10:57 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection]
10:57 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev
11:05 -!- gene [~gene@gateway/tor-sasl/gene] has joined #lightning-dev
11:16 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:9961:ea6b:a3cc:5490] has quit [Quit: Client closed]
12:01 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
12:14 < BlueMatt> rusty: I'm happy to do interop testing whenever you want.
12:14 < BlueMatt> I have it running on a testnet node, if you prefer that, or mainnet.
12:14 < BlueMatt> rusty: https://1ml.com/testnet/node/0296e20fa99d2940b8b00117e65d27003f0d8f81a0c960f71a5466d1aadf5ea5ea if you want a testnet node
12:28 < BlueMatt> rusty (or t-bast) also I'd love to land https://github.com/lightningnetwork/lightning-rfc/pull/825 and have an implementation of that as well if either of y'all have one.
12:34  * BlueMatt is trying to make up for lost time and help get some bolt changes across the line :)
12:56 < rusty> BTW, I'm not going to be in the coming meeting: got a Twitter Space thing which clashes apparently.
12:59 < BlueMatt> is anyone else here?
12:59 < ariard> hey
12:59 < ariard> like not even sure we have an agenda
13:01 < BlueMatt> we do not. I think t-bast normally publishes one. I have several things I want to mention, but they're all "I've left comments on github, and want to push the author to rebase or address them so we can move forward"
13:02 < cdecker[m]> I'm here, but can't stay for long
13:03 < ariard> same here i don't have "hot" LN things to talk about
13:04 < BlueMatt> alright, well lets call it then, we barely have a quorum, and there's still tasks from last week's meeting to go over, but everyone has to review at least one spec pr as pennance for not showing up.
13:05 < BlueMatt> two if you actually didn't even show up :p
13:05 < cdecker[m]> Aye aye capt'n ^^
13:05 < cdecker[m]> But agreed, I'd love an early evening
13:06 < ariard> crypt-iq: happy to implement option_dusty_htlcs_uncounted if you have a proposal ready soon!
13:10 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Quit: Ctrl-C at console.]
13:17 < _niftynei> harding: regarding your question concerning 'sidecar channels', generally the flow for a liquidity ad is as follows 1) Bob advertises he has available liquidity 2) Carol requests to open a channel and buy XX liquidity from Bob 3) Bob would let Alice know that Carol has requested XX of liquidity 4) Alice would provide a PSBT that covers the liquidity request + associated fees 5) the open would proceed as normal, with Bob 
13:17 < _niftynei> forwarding the signature request to Alice for signatures when it's time to send those sigs to Carol
13:18 < _niftynei> (c-lightning provides hooks for openchannel requests that includes all the relevant information regarding who's requesting an ad purchase, amount, etc and the interface for communicating funding is in PSBTs)
13:19 < _niftynei> Alice, Bob, and Carol would need to coordinate ahead of time however, in that Bob would need to know to forward all/some node id's to Alice for funding, and Carol would need to know (from Alice) which node to open a channel with
13:21 < _niftynei> mmm interesting. you could generalize the Alice role to a "liquidity provider" that many Bob's could have a relationship with, as a way of deploying capital across the network from a centralized wallet
13:23 < _niftynei> probably need some assurances about getting paid back eventually though lolll
13:27 -!- gene [~gene@gateway/tor-sasl/gene] has quit [Quit: gene]
13:33 < harding> _niftynei: cool.  It sounds to me like Alice could give Carol a signature using her node key that says "2021-08-02 I'm willing to pay for <Carol's node id> liquidity".  Carol can give that signature to Bob when she starts the dual funding.  Bob has a plugin that verifies the signature and then handles the coordnation with Alice, returning to the normal dual funding workflow after Alice returned the updated signed PSBT.
13:35 < _niftynei> you'd have to add a TLV to the spec flow in the open for the signed message
13:35 < _niftynei> without the signed message, you could do it today, provided there's external coordination btw the parties
13:37 < _niftynei> the hard part with this is getting money *back* from Bob at the end of the channel lifetime
13:37 < _niftynei> (note: if Carol and Alice are the same person, you've re-invented push_msat)
13:38 < harding> Oh, is there an anti-abuse fidelity bond thing in current dual funding?
13:38 < _niftynei> not implemented, no. i'm assuming you're referring to PODLEs?
13:39 < _niftynei> i sent an explanation for their omission to the mailing list a few weeks back
13:39 < harding> I guess I don't understand why there's a problem with getting money back from Bob.
13:40 < _niftynei> let's say you, Alice, give bob .5btc to put into a channel pointing at Carol
13:41 < _niftynei> and that bob has one other channel with inbound capacity of .5btc
13:41 < harding> Thinking about the above workflow, it seems overly based on the LL Pool implementation, which uses onchain transactions.  Maybe the right way to do it is with HTLCs and offers.
13:42 < harding> (That's my fault for setting up the problem that way.)
13:42 < _niftynei> a payment of .5btc goes from Bob's inbound channel to Carol, via the channel Alice helped fund
13:42 < _niftynei> now in the Bob to Carol channel, Bob's balance is 0btc
13:43 < _niftynei> the .5btc balance has moved to his other (now outbound) channel of .5btc
13:43 < _niftynei> how does Alice guarantee that Bob will pay her back the .5btc that's now in another channel?
13:43 < harding> Oh, I don't think that's how Pool's sidecars work.  Alice pays Bob 0.001 BTC outright for Bob to put 0.5 BTC of *his* money in the channel to Alice.
13:43 < harding> (The 0.5 BTC stays on Bob's side, there's no direct push.)
13:44 < _niftynei> well it stays on Bob's side until a payment uses a portion of it
13:44 -!- ryanthegentry [~ryanthege@2600:1700:14d0:65e0:f515:f92c:6b94:51d2] has joined #lightning-dev
13:45 < harding> Sure, but that should be balanced by Bob receiving money on another channel, e.g. usual routing rules.
13:45 < _niftynei> If Alice isn't furnishing the funds for the open, then yeah you'd probably want to resolve that payment via a pre-existing channel btw Alice + Bob
13:46 < harding> Cool.  I think that's better than having to use onchain stuff with Pool, so that's a nice advantage.
13:46 < harding> advantage of dual funding / liquidity ads*
13:46 < _niftynei> mmm you could definitely use an offer to make that happen, where you pass Carol's node_id over via the invoice_request 
13:48 < _niftynei> mm no, the offer would need to be published by Bob... he'd want to send an invoice to Alice with carol's node_id included
13:50 < _niftynei> Bob could publish an offer for a channel open, carol could request an invoice with their node_id in it and forward the returned invoice to Alice who pays the invoice to Bob, Alice returns the PoP to Carol who then includes it in their channel open request to Bob
13:51 < _niftynei> that's basically an alternative method for paying for opens than liquidity ads tbh
13:52 < _niftynei> i'm not sure the offer has all the details you'd want in it to enforce the contract tho, so you'd probably want a combination of the two so the channel fee commitments+lease times are communicated
13:55 < _niftynei> "Alice returns the PoP to Carol who then includes it in their channel open request to Bob" -- or Bob just remembers that the invoice has been paid when Carol requests the channel open, but Alice would need to notify Carol that she's paid it
13:59 < harding> That seems reasonable.  With payments going over LN, that would also make it easier for Alice to pay Bob for ongoing costs to extend the lease.
14:07 -!- common [~common@user/common] has joined #lightning-dev
14:55 -!- AaronvanW [~AaronvanW@190.150.26.4] has joined #lightning-dev
15:58 -!- belcher [~belcher@user/belcher] has joined #lightning-dev
16:06 -!- Guest25 [~Guest25@171.192.142.88.rev.sfr.net] has joined #lightning-dev
16:08 -!- Guest25 [~Guest25@171.192.142.88.rev.sfr.net] has quit [Client Quit]
16:39 < roasbeef> harding: w/ the sidecar stuff, Alice also has the option of "crediting" Bob (the liquidity provider) w/ 0.5 BTC by "placing it" directly into his account in the batch execution transaciton, so this lets Carol (the party receiving the sidecar chan) start out w/ a sending balance
16:40 < roasbeef> the nice part about doing it all on-chain, is that the entire package will always succeed and it's all batched+atomic 
16:41 < roasbeef> there're ppl like Voltage that working on a sort of higher-level interface, to serve as a sort of meta provider, by accepting off-chain payments to use as credit to be pushed over 
16:42 < roasbeef> for that stuff to still be atomic (not reliant on the party actually doing the channel stuff after getting the payment), you'd want to embed the pre-image itself in the on-chain protocol
16:43 < roasbeef> in the context of Pool, that could mean something like Bob committing to pre-images (post taproot in this example), in his Pool account, with him revealing one embedded in the HTLC when he spends it (during the batch execution transaction), this way he'd lose money if he carried out the protocol w/o revealing the pre-image on chain 
16:44 -!- AaronvanW [~AaronvanW@190.150.26.4] has quit [Remote host closed the connection]
17:01 < harding> roasbeef: for your first line above, I think it's easy enough to turn a newly opened channel from Bob to Carol with {Bob: 0.5, Carol:0.0} into {Bob: 0.0, Carol: 5.0} (let's ignore reserve fee) by just having Alice send 0.5 to Carol over LN through Bob's node.  The disadvantage of doing it that way is that Carol can't release the preimage for the HTLC until the channel is full open, i.e. she needs to wait 6 confs (or whatever).  By comparison, in 
17:01 < harding> the Pool case, Pool would be co-signing the credit transaction so Bob can open the channel to Carol with a direct push_msat and Carol can begin spending those 0.5 BTC immediately.  In short, the main difference there is how long Carol would have to wait before being able to spend.
17:01 < harding> s/Carol: 5.0/Carol 0.5/
17:03 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
17:05 < harding> Really I think the advantage there is the co-signing by Pool, rather than it being onchain.  If Carol knew that Bob's signing key was a musig with an entity she trusted to never double spend the channel open, she'd be able to release her preimage immediately.
17:13 -!- belcher_ [~belcher@user/belcher] has joined #lightning-dev
17:15 -!- AaronvanW [~AaronvanW@190.150.26.4] has joined #lightning-dev
17:17 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 276 seconds]
17:32 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has quit [Read error: Connection reset by peer]
17:32 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has quit [Remote host closed the connection]
17:32 -!- Enki[m] [~enkimatri@2001:470:69fc:105::382c] has quit [Read error: Connection reset by peer]
17:32 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has quit [Write error: Connection reset by peer]
17:32 -!- cdecker[m] [~cdeckerma@2001:470:69fc:105::2e8e] has quit [Read error: Connection reset by peer]
17:32 -!- stick[m][m] [~stickmatr@2001:470:69fc:105::98c] has quit [Remote host closed the connection]
17:32 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has quit [Remote host closed the connection]
17:32 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has quit [Read error: Connection reset by peer]
17:32 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has quit [Remote host closed the connection]
17:33 -!- devrandom [~devrandom@2001:470:69fc:105::d4d] has joined #lightning-dev
17:42 -!- vincenzopalazzo [~vincenzop@2001:470:69fc:105::a67] has joined #lightning-dev
17:42 -!- merkle_noob[m] [~merklenoo@2001:470:69fc:105::bad0] has joined #lightning-dev
17:42 -!- mrjumper[m] [~mr-jumper@2001:470:69fc:105::7f1] has joined #lightning-dev
17:42 -!- cdecker[m] [~cdeckerma@2001:470:69fc:105::2e8e] has joined #lightning-dev
17:42 -!- stick[m] [~stickmatr@2001:470:69fc:105::98c] has joined #lightning-dev
17:42 -!- robertspigler [~robertspi@2001:470:69fc:105::2d53] has joined #lightning-dev
17:42 -!- ksedgwic [~ksedgwicm@2001:470:69fc:105::ce1] has joined #lightning-dev
17:42 -!- Enki[m] [~enkimatri@2001:470:69fc:105::382c] has joined #lightning-dev
17:49 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 276 seconds]
17:49 -!- AaronvanW [~AaronvanW@190.150.26.4] has quit [Ping timeout: 252 seconds]
17:52 -!- AaronvanW [~AaronvanW@190.150.26.4] has joined #lightning-dev
17:56 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has quit [Remote host closed the connection]
17:57 -!- yonson [~yonson@2600:8801:d900:7bb::d7c] has joined #lightning-dev
22:06 -!- Netsplit *.net <-> *.split quits: sword_smith, Nebraskka, stonefox, BlueMatt, scalability-junk, b42
22:06 -!- sword_sm1th [sword_smit@bitcoinfundamentals.org] has joined #lightning-dev
22:06 -!- Netsplit over, joins: BlueMatt
22:06 -!- AaronvanW [~AaronvanW@190.150.26.4] has quit [Remote host closed the connection]
22:06 -!- Netsplit over, joins: b42
22:07 -!- Netsplit over, joins: scalability-junk
22:08 -!- Nebraskka [~Nebraskka@user/nebraskka] has joined #lightning-dev
22:33 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has quit [Ping timeout: 244 seconds]
22:35 -!- hex17or [~hex17or@gateway/tor-sasl/hex17or] has joined #lightning-dev
23:12 -!- willcl_ark_ [~quassel@user/willcl-ark/x-8282106] has quit [Ping timeout: 258 seconds]
23:14 -!- willcl_ark [~quassel@user/willcl-ark/x-8282106] has joined #lightning-dev
23:25 -!- Guest3669 [~Guest36@183.83.46.68] has joined #lightning-dev
23:26 -!- Guest3669 [~Guest36@183.83.46.68] has quit [Client Quit]
23:26 -!- libera-dev [~libera-de@183.83.46.68] has joined #lightning-dev
23:38 -!- aechu [~major@gateway/tor-sasl/major] has quit [Remote host closed the connection]
23:39 -!- aechu [~major@gateway/tor-sasl/major] has joined #lightning-dev
--- Log closed Tue Aug 03 00:00:27 2021