--- Day changed Thu Apr 26 2018
00:09 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has joined #lightning-dev     
00:22 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #lightning-dev     
00:24 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 265 seconds]     
00:36 -!- CubicEarths [~cubiceart@xdsl-188-155-63-9.adslplus.ch] has joined #lightning-dev     
00:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]     
00:54 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
01:06 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev     
01:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev     
01:09 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has joined #lightning-dev     
01:51 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-rdmkrgzihmehhwhk] has joined #lightning-dev     
02:15 -lightningrfc:#lightning-dev- [lightning-rfc] C-Otto opened pull request #419: BOLT2: Rephrase channel establishment introduction (master...master) https://git.io/vpCNi
02:22 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 255 seconds]     
02:29 -!- deusexbeer [~deusexbee@080-250-077-030-dynamic-pool-adsl.wbt.ru] has quit [Ping timeout: 255 seconds]     
02:29 -!- deusexbeer [~deusexbee@093-092-176-243-dynamic-pool-adsl.wbt.ru] has joined #lightning-dev     
02:39 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-rdmkrgzihmehhwhk] has quit [Ping timeout: 245 seconds]     
02:43 -!- laurentmt [~Thunderbi@95.215.61.163] has joined #lightning-dev     
02:44 -!- laurentmt [~Thunderbi@95.215.61.163] has quit [Client Quit]     
02:52 -!- DrFeelGood [~DrFeelGoo@unaffiliated/olufunmilayo] has joined #lightning-dev     
03:22 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-iedheykqkennbryy] has joined #lightning-dev     
03:40 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]     
03:50 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev     
04:02 -!- tiagotrs [~user@p5DC470C8.dip0.t-ipconnect.de] has joined #lightning-dev     
04:02 -!- tiagotrs [~user@p5DC470C8.dip0.t-ipconnect.de] has quit [Changing host]     
04:02 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #lightning-dev     
04:11 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]     
04:15 -!- kousakahonoka [kousakahon@gateway/shell/matrix.org/x-ytxdpntbhppeeeux] has joined #lightning-dev     
04:15 -!- pierce [x43matrixo@gateway/shell/matrix.org/x-wsjsyyhdgcsttuxm] has joined #lightning-dev     
04:15 -!- rrol[m] [rrolmatrix@gateway/shell/matrix.org/x-juwohicxrbmzucpn] has joined #lightning-dev     
04:15 -!- JoKe1 [jokesharek@gateway/shell/matrix.org/x-ashnzavjfhxqzqof] has joined #lightning-dev     
04:15 -!- shem[m] [shemmatrix@gateway/shell/matrix.org/x-lxuvmzasegfobxjf] has joined #lightning-dev     
04:15 -!- afdudley [afdudleyma@gateway/shell/matrix.org/x-nhqwutjnckjjxnaf] has joined #lightning-dev     
04:19 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-bbultnlfdgblsowd] has quit [Quit: Connection closed for inactivity]     
04:32 -!- tiagotrs [~user@p5DC470C8.dip0.t-ipconnect.de] has joined #lightning-dev     
04:32 -!- tiagotrs [~user@p5DC470C8.dip0.t-ipconnect.de] has quit [Changing host]     
04:32 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #lightning-dev     
04:35 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ivxedrdksvndxvcm] has joined #lightning-dev     
04:45 -!- shesek [~shesek@bzq-84-110-234-113.red.bezeqint.net] has joined #lightning-dev     
04:45 -!- shesek [~shesek@bzq-84-110-234-113.red.bezeqint.net] has quit [Changing host]     
04:45 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev     
04:51 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has joined #lightning-dev     
04:52 < ZmnSCPxj> Good morning orange_, let me clarify by giving concretions rather than abstractions
04:52 < ZmnSCPxj> Suppose A is payer and D is payee
04:52 < ZmnSCPxj> And there are two viable routes A->B->D and A->C->D
04:52 < ZmnSCPxj> A tries the route A->B->D
04:52 < ZmnSCPxj> A offer B an HTLC, and B offers C an HTLC
04:53 < ZmnSCPxj> A offers B an HTLC and B offers D an HTLC
04:53 < ZmnSCPxj> D offers the preimage to B and gets the actual payment. At this point, as far is D is concerned, the transaction is over
04:53 < ZmnSCPxj> B is preparing to send the preimage to A to claim the A->B HTLC when it is suddenly struck by a nuclear missile
04:54 < ZmnSCPxj> What do you want A and D to do now?
04:54 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has quit [Client Quit]     
04:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev     
05:00 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has joined #lightning-dev     
05:04 < bsm117532> Are channel factories currently usable with lnd?  (or any other lightning implementation?)
05:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]     
05:08 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has joined #lightning-dev     
05:09 < ZmnSCPxj> Good morning, bsm117532, simple answer is no, because it is not yet specced and actually designed
05:09 < bsm117532> darn
05:09 < bsm117532> What's the best way to connect over progress on that?
05:09 < ZmnSCPxj> See also this thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001178.html which points out a (relative) disadvantage of invalidation trees
05:09 < bsm117532> In our discussions in #braidpool (mining-into-payment-channels for a new p2pool) it seems like the best solution.  What's the best way to get connected with that development?
05:10 < ZmnSCPxj> Burchert-Decker-Wattenhofer channel factories use invalidation trees (which have relative locktime) and then multi-hop payments require a HTLC on top of that
05:10 < ZmnSCPxj> And HTLCs use an absolute locktime
05:10 < ZmnSCPxj> lightning-dev mailinglist, possibly.
05:11 < bsm117532> Yeah I'm reading that paper in another window...
05:11 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has quit [Client Quit]     
05:12 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has joined #lightning-dev     
05:13 < ZmnSCPxj> Compare this, with Poon-Dryja channels, where the relative-locktime revokable claim transaction comes after the absolute-locktime HTLC
05:13 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has quit [Client Quit]     
05:14 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has joined #lightning-dev     
05:15 < ZmnSCPxj> Good morning bsm117532, but the issue exists only if you need to support reorganization of channels dynamically
05:15 < bsm117532> I see.  We may be able to work around that, since a share-chain would have to commit to a set of mining payments.
05:16 < ZmnSCPxj> if you are willing to give up channel reorganization, you can indeed just use a simple intermediate transaction to back the individual channels
05:16 < ZmnSCPxj> I allude to this here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001184.html
05:17 < bsm117532> Channel reorganization, in the context of mining payouts, introduces a trusted counterparty...
05:17 < ZmnSCPxj> In this case, we have a funding txout (the factory funding txout), which is spent by a distribution transaction that has one output per payment channel.
05:17 < ZmnSCPxj> at any time, you can trigger the close of the entire factory by publishing the distrubtion transaction and your latest commitment transaction, if you lose trust
05:18 < bsm117532> Can you see any problems with having the channel factory opening being in a coinbase?
05:18 < ZmnSCPxj> or you could do a mutual close of the entire factory and spend directly from the factory funding txout to addresses each party controls
05:18 < ZmnSCPxj> no     
05:19 < ZmnSCPxj> So the structure goes this way: everyone pays -> factory funding txout, this transaction is confirmed onchain
05:19 < bsm117532> We'd have to wait 100 blocks before closing and track that is the only thing.
05:19 -!- ebx [~ebx@unaffiliated/ebex] has joined #lightning-dev     
05:19 < bsm117532> Due to the coinbase maturity rule
05:19 < ZmnSCPxj> Then te distribution transaction spends the factory funding txout, and pays out to individual 2-of-2 multisigs that are each channel
05:19 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]     
05:20 < ZmnSCPxj> each channel has a pair of commitment transactions on both sides
05:20 < ZmnSCPxj> anyone can close the entire factory by broadcasting the distribution and their own commitment transaction
05:20 < ZmnSCPxj> Alternately, you could contact everyone in the factory and collapse the distribution and the commitment transactions to a single factory close transaction
05:20 -!- Dev91 [~quassel@203.86.206.137] has quit [Ping timeout: 240 seconds]     
05:21 < bsm117532> We've been thinking about a tree structure for the mining payouts, to prevent channels with a huge number of co-signers.
05:21 < ZmnSCPxj> well, the coinbase maturity rule increases the number of moving parts, it seems to me you could just ignore the coinbase maturity rule
05:21 < ZmnSCPxj> it effectively means the factory needs to exist for 100 blocks at least
05:22 < bsm117532> Can you see any problem with "rolling up" channel closes...e.g. someone with a "leaf node" channel factory closes his channel, which cascades up the tree and causes a closing of the factory?
05:22 < ZmnSCPxj> Yes, you can do what I mentioned
05:22 < ZmnSCPxj> Yes, anyone can trigger that
05:22 < ZmnSCPxj> but that is really an effect of "I do not know any of you, and I am paranoid you are out to get me"
05:22 < bsm117532> Yes, factory has to exist for 100 blocks.  The mining pool would have to track both "matured" payouts and "unmatured" payouts separately, since the latter can't be closed yet.
05:23 < ZmnSCPxj> so your structure is deliberately made to reflect that
05:23 < ZmnSCPxj> no, it does not, because the Bitcoin rules ensure it on behalf of the mining pool
05:23 < ZmnSCPxj> the latter not being closable is not an issue
05:24 < ZmnSCPxj> it just prevents individual grinders from closing the factory
05:24 < ZmnSCPxj> I think
05:24 < ZmnSCPxj> cdecker may have spent more time thinking of th1is
05:24 < bsm117532> I'm worried about people using unmatured funds for payment.  Seems to me this is kind of a separate lightning network that becomes part of the main network once it matures.
05:25 < ZmnSCPxj> The funds are still claimable at some point in the future, then it does not matter whether you are using matured or unmatured funds
05:25 < ZmnSCPxj> it simply means the channel/channel factory is not closable in the meantime
05:25 < bsm117532> Not if the coinbase block gets orphaned
05:25 < bsm117532> (which is the point of the 100-block maturity rule)
05:26 < ZmnSCPxj> This is the same issue as the funding transaction getting confirmed in a block that gets orphaned
05:26 < ZmnSCPxj> and then not getting confirmed again
05:26 < bsm117532> What happens when that happens?
05:26 < ZmnSCPxj> Lightning requires that funding transactions are buried only 6-deep before they can be used publicly
05:26 < ZmnSCPxj> The assumption of most LN software is that 6-deep is deep enough that we can pretty much neglect reorgs for those
05:27 < ZmnSCPxj> funky things will happen, like nodes being unable to decide what the short channel ID is
05:27 < bsm117532> So Lightning assumes synchronicity and can't handle 6+-block reorgs?
05:27 < bsm117532> yikes
05:27 < ZmnSCPxj> There may be implementations that support better than that
05:28 < bsm117532> I mean you can always just check whether the funding transaction is in the main chain, even more than 6 blocks later
05:28 < ZmnSCPxj> but yes, the short channel ID will suddenly mutate from under you
05:28 < bsm117532> Oh I see
05:28 < bsm117532> So on a forked chain the channel id changes...
05:28 < ZmnSCPxj> and from what I remember of c-lightning, we assume the scid will not change
05:29 < ZmnSCPxj> well the short channel id is just blockheight + tx index + output index where the funding tx got confirmed
05:29 < ZmnSCPxj> so yes, if it gets reorged out
05:29 < ZmnSCPxj> the short channel id mutates
05:29 < ZmnSCPxj> the full channel ID (32 bytes) stays the same
05:29 < bsm117532> But I guess there's no problem with tracking multiple chain tips and making lightning payments on multiple forks simultaneously right?
05:29 < ZmnSCPxj> but consider the possibility where the funding tx is RBF
05:29 < ZmnSCPxj> One one branch, the funding tx confirms
05:30 < ZmnSCPxj> on another, we secretly replaced it with an RBF transaction that pays back to us
05:30 < ZmnSCPxj> so in another branch of the blockchain the channel might not exist at all!
05:30 < bsm117532> sure
05:31 < bsm117532> So maybe we should not use short channel ids, and use full channel ids instead?
05:31 < ZmnSCPxj> Then there is the claim of petertodd that a "significant minority" of miners are using a full-RBF and not an opt-in-RBF policy
05:31 < ZmnSCPxj> short channel IDs are 8 bytes
05:31 < ZmnSCPxj> easier to fit in node gossip and onion routes
05:31 < bsm117532> oh well that's not enough :-P
05:31 < ZmnSCPxj> but there was discussion about removing short-channel-id, yes
05:31 < bsm117532> Ok.  In terms of payment commitments we definitely don't want to use that then, we should use full channel ids
05:32 < ZmnSCPxj> yes, the full channel ID is basically the txid + outnum, and you need that to create the input of the commitment transaction, yes
05:32 < bsm117532> 8-byte collisions to convince a miner he's being paid when he's not would be too easy to generate
05:32 < ZmnSCPxj> the 8 bytes is verifiable
05:33 < ZmnSCPxj> again, it is 3 bytes of blockheight, 3 bytes of tx index in the block, and 2 bytes of output index
05:33 -!- laurentmt [~Thunderbi@95.215.61.163] has joined #lightning-dev     
05:33 < bsm117532> Ok but that's ambiguous WRT reorgs
05:33 < ZmnSCPxj> Yes, that is a definite problem
05:33 < ZmnSCPxj> in practice, scid is only used for routing
05:34 < ZmnSCPxj> so in your context, if you are using direct payments, not an issue
05:34 < ZmnSCPxj> in addition, if you are using direct payments, you do not need HTLC
05:34 < bsm117532> We will need to decide things like making payouts to a miner who successfully mined an orphan block.
05:34 < bsm117532> (the braid structure will no longer "punish" miners who create orphan blocks)
05:35 -!- Dev91 [~quassel@203.86.206.137] has joined #lightning-dev     
05:35 < bsm117532> And payments will be amortized over the DAG, including orphans.
05:35 < ZmnSCPxj> And without HTLC, the issue of relative locktimes in the invalidation tree conflicting with absolute locktimes of HTLCs disappears
05:35 < ZmnSCPxj> so you can just use the invalidation tree structure, which frees you from having to do justice txes
05:35 < bsm117532> Ok I need to understand this invalidation tree thing
05:35 < ZmnSCPxj> at the cost of much larger onchain blockspace spent
05:35 < ZmnSCPxj> Simple.
05:36 < ZmnSCPxj> Let us start with an invalidation-tree-based payment channel
05:36 < ZmnSCPxj> you have a funding transaction output, which is a 2-of-2 multisig that is otherwise unencumbered
05:36 < ZmnSCPxj> You have a kickoff/trigger transaction, which spends the 2-of-2 multisig, and outputs a 2-of-2 multisig again
05:37 < ZmnSCPxj> Then you have an invalidation tree transaction, which is relative time locked, which spends the kickoff/trigger outpoint, and outputs a 2-of-2 multisig again
05:37 < ZmnSCPxj> Finally you have the distribution transaction, which again is relative timelocked, which spends the invalidation tree transaction output, and pays out according to the payment channel balance
05:38 < ZmnSCPxj> to update that, you create a new distribution transaction with a shorter relative locktime to invalidate the previous distribution transaction
05:38 < ZmnSCPxj> and the new distribution transaction splits up the fund to the new balance of the channel
05:39 < ZmnSCPxj> What do we do when the latest distribution transaction has the minimum relative locktime, and we want to update the channel again?
05:39 < ZmnSCPxj> We update the invalidation tree transaction instead: we create a new invalidation tree transaction with a shorter locktime than currently
05:39 < ZmnSCPxj> AND THEN we set the distribution transaction to spend from the NEW invalidation tree transaction
05:39 < ZmnSCPxj> AND we give the new distribution transaction the MAXIMUM relative locktime
05:40 < ZmnSCPxj> this will still be "more valid" than the shortest locktime previously, because the NEW invalidation tree transaction has a shorter locktime than the previous invalidation tree transaction
05:40 < ZmnSCPxj> you can layer than with as many invalidation tree transactions as you want
05:40 < ZmnSCPxj> to extend the number of updates your channel supports to greater than 2^32 or more, which in practice will not happen
05:41 < ZmnSCPxj> did you understand?
05:41 < ZmnSCPxj> Think of it as a countdown timer, like with mm:ss
05:41 < ZmnSCPxj> you start out with 59:59
05:42 < ZmnSCPxj> You update this down to 59:58, 59:57...59:00
05:42 < ZmnSCPxj> then you update this to 58:59
05:42 < ZmnSCPxj> here, the "mm" is the relative locktime of the invalidation tree transaction
05:42 < ZmnSCPxj> while "ss" is the relative locktime of the distribution transaction
05:42 < ZmnSCPxj> you can add hh:mm:ss for even greater number of updates
05:42 < ZmnSCPxj> or dd:hh:mm:ss
05:42 < ZmnSCPxj> and so on
05:43 < ZmnSCPxj> is that intuitive enough?
05:43 -!- ZmnSCPxj [b4be2b90@gateway/web/freenode/ip.180.190.43.144] has quit [Quit: Page closed]     
05:44 -!- CubicEarths [~cubiceart@xdsl-188-155-63-9.adslplus.ch] has quit [Remote host closed the connection]     
05:45 < bsm117532> Yes, vaguely, need to read more...  Thanks ZmnSCPxj!
06:01 -!- emzy_ is now known as Emzy     
06:03 -!- Emzy [~quassel@raspberry.emzy.de] has quit [Changing host]     
06:03 -!- Emzy [~quassel@unaffiliated/emzy] has joined #lightning-dev     
06:04 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev     
06:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev     
06:16 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev     
06:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]     
06:25 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 264 seconds]     
06:26 -!- molz [~mol@unaffiliated/molly] has quit [Quit: ZNC 1.6.6 - http://znc.in]     
06:35 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev     
06:35 -!- laurentmt [~Thunderbi@95.215.61.163] has quit [Ping timeout: 268 seconds]     
06:38 -!- laurentmt [~Thunderbi@37.58.58.232] has joined #lightning-dev     
06:39 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-ivxedrdksvndxvcm] has quit [Quit: Connection closed for inactivity]     
06:47 -!- aawdwdw [~user@p5DC470C8.dip0.t-ipconnect.de] has joined #lightning-dev     
06:48 -!- CubicEarths [~cubiceart@178.197.231.156] has joined #lightning-dev     
06:49 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has joined #lightning-dev     
06:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds]     
06:56 -!- aawdwdw [~user@p5DC470C8.dip0.t-ipconnect.de] has quit [Quit: Leaving]     
06:56 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #lightning-dev     
07:05 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds]     
07:08 -!- instagibbs [~instagibb@pool-100-15-128-78.washdc.fios.verizon.net] has joined #lightning-dev     
07:13 -!- CubicEarths [~cubiceart@178.197.231.156] has quit [Remote host closed the connection]     
07:13 -!- CubicEarths [~cubiceart@178.197.231.156] has joined #lightning-dev     
07:15 -!- davout_ is now known as davout     
07:15 -!- davout [~david@fr.anco.is] has quit [Changing host]     
07:15 -!- davout [~david@unaffiliated/davout] has joined #lightning-dev     
07:20 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #lightning-dev     
07:21 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 268 seconds]     
07:23 -!- CubicEarths [~cubiceart@178.197.231.156] has quit [Remote host closed the connection]     
07:24 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #lightning-dev     
07:24 -!- CubicEarths [~cubiceart@178.197.231.156] has joined #lightning-dev     
07:29 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 248 seconds]     
07:53 -!- Aaronvan_ is now known as AaronvanW     
08:03 -!- inara [~inara@68.ip-149-56-14.net] has quit [Quit: Leaving]     
08:04 -!- CubicEarths [~cubiceart@178.197.231.156] has quit [Remote host closed the connection]     
08:14 -!- inara [~inara@68.ip-149-56-14.net] has joined #lightning-dev     
08:22 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
08:23 -!- mol [~molly@unaffiliated/molly] has joined #lightning-dev     
08:39 -!- laurentmt [~Thunderbi@37.58.58.232] has quit [Quit: laurentmt]     
08:59 -!- bitonic-cjp [~bitonic-c@92-111-70-106.static.v4.ziggozakelijk.nl] has quit [Quit: Leaving]     
09:08 -!- molz [~m@unaffiliated/molly] has joined #lightning-dev     
09:10 -!- mol [~molly@unaffiliated/molly] has quit [Quit: Leaving]     
09:18 -!- tiagotrs [~user@p5DC47FDE.dip0.t-ipconnect.de] has joined #lightning-dev     
09:18 -!- tiagotrs [~user@p5DC47FDE.dip0.t-ipconnect.de] has quit [Changing host]     
09:18 -!- tiagotrs [~user@unaffiliated/tiagotrs] has joined #lightning-dev     
09:37 -!- CubicEarths [~cubiceart@178.197.231.199] has joined #lightning-dev     
10:17 -!- CubicEarths [~cubiceart@178.197.231.199] has quit [Remote host closed the connection]     
10:20 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has joined #lightning-dev     
10:20 -!- spudowiar [~spudowiar@unaffiliated/saleemrashid] has quit [Client Quit]     
10:24 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
10:25 -!- riclas [~riclas@148.63.37.111] has joined #lightning-dev     
10:28 -!- n1bor [~n1bor@185.9.34.66] has joined #lightning-dev     
10:32 -!- DrFeelGood [~DrFeelGoo@unaffiliated/olufunmilayo] has quit [Ping timeout: 240 seconds]     
10:33 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev     
10:34 -!- contrapumpkin [~copumpkin@haskell/developer/copumpkin] has joined #lightning-dev     
10:34 -!- DrFeelGood [~DrFeelGoo@unaffiliated/olufunmilayo] has joined #lightning-dev     
10:51 -!- laurentmt [~Thunderbi@37.58.58.232] has joined #lightning-dev     
10:52 -!- laurentmt [~Thunderbi@37.58.58.232] has quit [Client Quit]     
11:10 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has joined #lightning-dev     
11:12 -!- CubicEarths [~cubiceart@178.197.231.81] has joined #lightning-dev     
11:13 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving]     
11:13 -!- TeaPanda [~TeaPanda@unaffiliated/teapanda] has joined #lightning-dev     
11:20 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev     
11:21 < CubicEarths> The sudden drop-off in the number of channels ... https://p2sh.info/dashboard/db/lightning-network?orgId=1&from=now-7d&to=now
11:21 < CubicEarths> I noticed a bunch of my own channels closing around that same time
11:22 < CubicEarths> Is it due to fee incompatibility between clients?
11:22 < CubicEarths> Triggered in mass by rapidly changing fee conditions on the blockchain / mempool?
11:27 < molz> CubicEarths, yes and yes!
11:29 < CubicEarths> thanks
11:41 -!- CubicEarths [~cubiceart@178.197.231.81] has quit [Remote host closed the connection]     
12:35 -!- CubicEarths [~cubiceart@xdsl-188-155-63-9.adslplus.ch] has joined #lightning-dev     
12:40 -!- laurentmt [~Thunderbi@37.58.58.232] has joined #lightning-dev     
12:50 -!- laurentmt [~Thunderbi@37.58.58.232] has quit [Quit: laurentmt]     
12:52 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
13:04 -!- Cogito_Ergo_Sum [~Myself@athedsl-244236.home.otenet.gr] has joined #lightning-dev     
13:04 -!- Cogito_Ergo_Sum [~Myself@athedsl-244236.home.otenet.gr] has quit [Changing host]     
13:04 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #lightning-dev     
13:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
13:14 <+roasbeef> bsm117532: they're a bit of a ways off, the implementation will also be rather complex 
13:15 <+roasbeef> bsm117532: the paper as it's defined also uses a very inefficeint protocol to adjust the main allocations, can end up with possibly hundreds of transactinos needing to land on the main chain in the case of a unilateral close 
13:15 -!- dougsland [~douglas@c-73-234-93-65.hsd1.nh.comcast.net] has quit [Ping timeout: 260 seconds]     
13:16 <+roasbeef> there're more efficient methods, presented one at my scaling bitcoin talk, avoids the whole tree on top of a tree thing 
13:17 <+roasbeef> bsm117532: short chan ids only exist atm due to needing to support light client verification, should be using full outpoints, but we'll need proper utxo set commitments before we can make that jump
13:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev     
13:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]     
13:29 -!- citylights [db641c97@gateway/web/freenode/ip.219.100.28.151] has joined #lightning-dev     
13:56 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
13:59 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev     
14:04 -!- citylights [db641c97@gateway/web/freenode/ip.219.100.28.151] has quit [Ping timeout: 260 seconds]     
14:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev     
14:32 -!- Chris_Stewart_5 [chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
14:39 -!- tralfaz [67fe9963@gateway/web/freenode/ip.103.254.153.99] has joined #lightning-dev     
14:53 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
15:13 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has quit [Ping timeout: 256 seconds]     
15:59 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has quit [Ping timeout: 248 seconds]     
16:39 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has quit [Ping timeout: 255 seconds]     
16:41 -!- tombusby [~tombusby@gateway/tor-sasl/tombusby] has joined #lightning-dev     
16:54 -!- tiagotrs [~user@unaffiliated/tiagotrs] has quit [Ping timeout: 256 seconds]     
17:45 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
17:48 -!- riclas [~riclas@148.63.37.111] has quit [Ping timeout: 260 seconds]     
18:49 -!- tralfaz [67fe9963@gateway/web/freenode/ip.103.254.153.99] has quit [Ping timeout: 260 seconds]     
20:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
20:23 -!- fusion44 [~fusion44@128.90.23.139] has joined #lightning-dev     
20:31 -!- ebx [~ebx@unaffiliated/ebex] has quit [Remote host closed the connection]     
20:37 -!- TeaPanda [~TeaPanda@unaffiliated/teapanda] has quit [Quit: Leaving]     
21:29 -!- melvster [~melvin@ip-86-49-18-198.net.upcbroadband.cz] has joined #lightning-dev     
22:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Read error: Connection reset by peer]     
22:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Read error: Connection reset by peer]     
22:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #lightning-dev     
22:01 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev     
22:34 -!- lxer [~lx@ip5f5bd657.dynamic.kabel-deutschland.de] has joined #lightning-dev     
22:36 -!- jtimon [~quassel@142.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]     
22:57 < bsm117532> Yes can we please get UTXO set commitments already... :-/
22:58 <+roasbeef> definitely, about time lol
23:03 < bsm117532> I nominate you to nominate someone to push them. ;-)  Even delayed commitments would be useful...and I really like sipa's rolling construction
23:06 <+roasbeef> lehdoit