--- Log opened Thu Oct 08 00:00:40 2020
00:23 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver]
00:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
00:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
00:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
00:33 -!- Netsplit *.net <-> *.split quits: jonatack
01:04 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
01:09 -!- jonatack [~jon@213.152.161.239] has joined #c-lightning
01:34 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
01:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
02:05 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
02:09 < jasan> What about putting backup of channel state on ipfs:// ?
02:15 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
02:24 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning
02:27 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
02:28 -!- belcher [~belcher@unaffiliated/belcher] has quit [Client Quit]
02:42 -!- HelloShitty [~narayan@bl20-171-222.dsl.telepac.pt] has quit [Ping timeout: 265 seconds]
02:42 -!- HelloShitty [~narayan@bl20-171-222.dsl.telepac.pt] has joined #c-lightning
02:45 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
02:55 < darosior> jasan: could be a backend for https://github.com/lightningd/plugins/tree/master/backup
02:55 < darosior> (I guess, don't know much about it)
02:55 -!- jonatack [~jon@213.152.161.239] has quit [Quit: jonatack]
02:58 < zmnscpxj> ark: channels with both incoming and outgoing capacity can be done trustlessly using onchain/offchain swaps like boltz.exchange
02:59 < zmnscpxj> 1 Open a channel at any random point on the network with good connectivity.
02:59 < zmnscpxj> 2 Send out half to an offchain->onchain swap on boltz.exchange
02:59 < zmnscpxj> 3 repeat using the onchain funds to open another channel until you run out of patience
03:00 < zmnscpxj> thus, there is no real need for multiple channels per peer.
03:00 < zmnscpxj> for some definition of "no", anyway :P
03:06 < zmnscpxj> darosior, jasan: One way of implementing that would be to upload your current db file, then at each `db_write` hook, create a tiny file containing the content-address of the previous thing (db file or db_write file)
03:06 < zmnscpxj> plus the db_write content
03:06 -!- belcher [~belcher@unaffiliated/belcher] has joined #c-lightning
03:06 < zmnscpxj> but when you squint, it starts looking like a little private blockchain of your own
03:06 < darosior> My Own Little Git Repo
03:06 < zmnscpxj> so..... how exactly does it help in avoiding onchain bloat? it seems to me that if enough people do that, IPFS will collapse
03:09 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
03:09 < zmnscpxj> worse, even if you occassionally "roll up" the archive by executing some of the queries on the old db file and make a new db file that you start a new chain of db_writes, the old db file will still be saved by the IPFS network (as I understand it)
03:09 < zmnscpxj> immutability and all taht
03:10 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
03:11 < zmnscpxj> the immutability implied by content-addressability implies it is better used for permanent records, not dynamic data like channel state.
03:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
03:17 -!- vincenzopalazzo [~vincent@mob-109-119-44-160.net.vodafone.it] has joined #c-lightning
03:23 < darosior> Didn't argue in favor of it :)
03:23 < zmnscpxj> haha
03:23 < zmnscpxj> I had been thinking about something like it earlier this year
03:23 < zmnscpxj> then smacked my head when I realized it would look like a blockchain, which is precisely what we wanted to avoid by going offchain
03:38 < jasan> zmnscpxj: that's not helping in avoiding onchain bloat, it's about distributed backup of a channel state; BTW no one will really download it to their ipfs node until they pin it, it would be floating in cache and really only on the two ipfs nodes (one for each channel side). IPFS can not collapse. It is like torrent. Just a bit more fancy with one way to access it. The old file will be
03:38 < jasan> forgotten sooner or later. Though it may stay in the cache of other nodes for a while.
03:43 < jasan> By the way the channel state backups can even be distributed via torrent. That would just be a bit more low-level. As the p2p network goes, it gets only faster and faster when there are more participants (from my own meandering experience).
03:55 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
03:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
03:58 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
03:58 < jasan> The pointer to the current channel state could be stored (and pinned, named) in ipfs, and it would point to data that would go through torrent. Pointer would just be an infohash. Anyone can do that already now. If there is no such plugin yet, it may not take long.
04:10 < zmnscpxj> Do you save the database file at each update? or just the individual `db_write`?
04:11 < jasan> the whole database file in what I am thinking of
04:11 < jasan> no blockchain
04:11 < jasan> just two signatures of both sides of the channel
04:12 < zmnscpxj> my database file is 29M now, and it is for a deliberately-crippled node with 3 channels right now.
04:13 < jasan> After saving the file, change pointer and seed only the new state now. Both sides of the channel will seed it (as they have the same state first-hand). There can be a market for REST API to seed foreign.
04:13 < zmnscpxj> so if an update happens, and *then* one of the hardware is destroyed, will it be possible to recover the state?
04:14 < zmnscpxj> remember, old states of even a few milliseconds ago will still risk financial loss if you mistakenly use it
04:14 < zmnscpxj> so you have to ensure, before C-lightning continues processing and releasing the revocation key, that the data is recoverable elsewhere
04:15 < zmnscpxj> even if your particular hardware suddenly fails
04:15 < zmnscpxj> which is why `db_write` is a strongly synchronous hook
04:15 < jasan> I see.
04:16 < zmnscpxj> it will stop C-Lightning processing until the hooked plugin can tell us "yes, it will now be recoverable even if our hardware is burned right at this moment"
04:16 < jasan> Is the HW failure hapening before or after the HW failing side signs?
04:16 < zmnscpxj> signing is hand over hand
04:16 < zmnscpxj> meaning that when moving to the next state, there are two valid commitment txes
04:16 < zmnscpxj> then you hand over the revocation key of the older commitment tx
04:17 < zmnscpxj> the `db_write` hook delays that handover
04:17 < zmnscpxj> so it is not about signing, it is about the revocation key handover
04:17 < jasan> OK
04:18 < zmnscpxj> when recovering, you assume that if there are two commitment txes in your latest channel state, the revocation key for the older one might already have been given
04:18 < zmnscpxj> and just use the later state
04:18 < zmnscpxj> and when you reconnect, you hand over the revocation key for the older state again, if my memory of the lightning-rfc is correct
04:18 < zmnscpxj> (rusty might be more familiar with the state machine)
04:18 < jasan> Off-topic: Is there a way to scan one particular blk?????.dat file and tell what block numbers are in it? Is block number part of the block or just computed from the previous ones?
04:19 < zmnscpxj> completely no idea, I just use the RPC interface
04:21 < jasan> zmnscpxj: Thank you for your feedback. I am going back to offline thinking mode now.
04:21 < zmnscpxj> np
04:34 -!- jasan [~jasan@2001:470:6f:200:c2f6:bf7c:c6c:bf6b] has quit [Quit: jasan]
04:34 -!- jasan [~jasan@just.do.nothing.bublina.eu.org] has joined #c-lightning
04:36 -!- jasan [~jasan@just.do.nothing.bublina.eu.org] has quit [Client Quit]
04:43 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
04:43 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver]
04:44 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
04:54 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
04:54 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Client Quit]
05:23 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
05:23 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #c-lightning
05:54 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
05:54 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has joined #c-lightning
06:18 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
06:43 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
06:54 -!- kexkey [~kexkey@37.120.205.214] has joined #c-lightning
06:57 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Ping timeout: 240 seconds]
07:09 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Ping timeout: 240 seconds]
07:11 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 240 seconds]
07:44 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Ping timeout: 240 seconds]
07:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
07:46 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #c-lightning
08:35 < ark> rusty, could you look at the log?
08:35 < ark> rusty:
08:37 < vincenzopalazzo> jasan: bitcoin-iterate (https://github.com/rustyrussell/bitcoin-iterate) by rusty or SpyCblock(https://github.com/vincenzopalazzo/SpyCblock) by me
08:39 < vincenzopalazzo> related at the question > "Is there a way to scan one particular blk?????.dat"
08:50 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Read error: Connection reset by peer]
08:50 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #c-lightning
08:51 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
08:51 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
08:52 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
09:00 -!- vincenzopalazzo [~vincent@mob-109-119-44-160.net.vodafone.it] has quit [Ping timeout: 272 seconds]
09:01 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
09:09 -!- vincenzopalazzo [~vincent@37.162.86.245] has joined #c-lightning
09:11 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Ping timeout: 240 seconds]
09:25 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
09:48 -!- jasan [~jasan@just.do.nothing.bublina.eu.org] has joined #c-lightning
10:09 -!- jasan [~jasan@just.do.nothing.bublina.eu.org] has quit [Quit: Bye!]
11:22 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
11:45 -!- vincenzopalazzo [~vincent@37.162.86.245] has quit [Quit: Leaving]
11:59 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #c-lightning
12:03 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
12:10 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has quit [Quit: liberliver]
12:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
12:11 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
12:11 -!- vasild_ is now known as vasild
12:20 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:2fc:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 272 seconds]
12:25 -!- fiatjaf [~fiatjaf@179.180.231.131] has joined #c-lightning
12:32 -!- fiatjaf [~fiatjaf@179.180.231.131] has quit [Ping timeout: 240 seconds]
12:58 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
13:56 -!- fiatjaf [~fiatjaf@179.180.231.131] has joined #c-lightning
14:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
14:27 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
14:28 -!- rh0nj [~rh0nj@88.99.167.175] has joined #c-lightning
14:44 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
15:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
15:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
16:01 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Quit: Leaving]
16:10 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
16:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
16:34 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
16:36 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
17:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
17:01 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
17:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
17:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
17:46 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
17:49 -!- polydin [~george@136.49.254.169] has joined #c-lightning
17:50 < polydin> would it be extremely difficult to change the codebase so that it allows for channels back and forth between two nodes as well as more than one channel from node to node?
17:50 < zmnscpxj> yes
17:50 < polydin> argh!
17:51 < polydin> thank you zmnscpxj 
17:51 < zmnscpxj> I have a sketch for how some years ago, on the c-lightning mailinglist
17:51 < zmnscpxj> lemme dig
17:51 < polydin> omg that would be so helpful
17:53 < polydin> i'd like to make those changes simply because i don't believe lightning should be used as a user-user payments network, though i know that was the original intention for keeping it to one channel per peer
17:55 < zmnscpxj> https://lists.ozlabs.org/pipermail/c-lightning/2018-July/000058.html
17:55 < zmnscpxj> it is a fairly extensive rewrite of most of c-lightning though
17:56 < polydin> yeah i'm trying to just understand the codebase and it's pretty daunting
17:57 < zmnscpxj> well, the thing is that most of the peer-talking code is off in their own little subdaemons: openingd, channeld, closingd
17:57 < polydin> i really do believe that the lightning network is an incredible protocol but that it's not being used properly
17:57 < zmnscpxj> those daemons recognize gossip messages and forward those to the gossipd, and forward messages from gossipd to the peer
17:57 < zmnscpxj> the openingd and closingd daemons are written mostly "synchronously" i.e. "I send this message to peer, I wait for this message from peer"
17:58 < zmnscpxj> which normally would be impossible in C if you wanted a single daemon handling multiple peers
17:58 < polydin> with you so far
17:58 < zmnscpxj> but since that daemon handles only a single peer, we can write it synchronously
17:59 < polydin> does this affect the ability to have multiple channels per peer?
18:00 < zmnscpxj> because if you are say using `closingd` with a peer to close your current channel, your peer cannot suddenly say "oh I want to make a new channel with you" because that code is over there in `openingd`
18:00 < zmnscpxj> similarly, if you have an ongoing live channel now, `channeld` is running, and if the peer suddenly goes "hey let us make a new channel", similar problem: `channeld` knows only how to maintain the channel, it does not know how to open a new one
18:01 < zmnscpxj> what my `peerd` proposal does is to have demultiplexing of channels in a new per-peer `peerd`, which assigns a channel to one of either `openingd`/`channeld`/`closingd`
18:01 < polydin> i see, that is quite a rewrite lol
18:03 < zmnscpxj> well, in principle it still keeps the simplicity of the `openingd` and `closingd` daemons
18:03 < zmnscpxj> which only know about one channel and one peer
18:03 < zmnscpxj> the complexity is moved off to the `peerd`, which *has to* know about all the messages known by all the peer-level daemons
18:03 < zmnscpxj> in particular, how to extract the channel identifier
18:04 < zmnscpxj> so it can forward the correct message to the correct channel-daemon
18:04 < zmnscpxj> so a lot of the existing architecture is retained
18:04 < zmnscpxj> but you still have this big pile of code in the `peerd`.
18:05 < zmnscpxj> Re: " it's not being used properly", elaborate please?
18:06 < polydin> i'm all for it, what i want to build requires the ability to open up more channels back and forth as well as top off or reduce liquidity in the channels
18:06 < zmnscpxj> the assumption of "one channel per peer" is also pretty strongly baked into the rest of the codebase, and some *other* things might break as well
18:06 < polydin> i'm just not a very good programmer, trying to go through the codebase, but find it difficult
18:06 < zmnscpxj> why cannot it use splice-in?
18:07 < polydin> yeah i started to get that impression that a lot of things wpould break as i read the code
18:07 < zmnscpxj> (other than splice-in not being implemented yet)
18:07 < polydin> that could work, definitely
18:07 < polydin> as long as both parties could open channels directionally torwards each other
18:07 < zmnscpxj> well, it might be better to work on splice-in
18:07 < zmnscpxj> niftynei has that after dual-funding
18:07 < zmnscpxj> if you want simultaneous funding, it is already being worked on
18:08 < zmnscpxj> and a sort-of working implementation is already in master
18:08 < zmnscpxj> i.e. dual-funding
18:08 < polydin> yeah i suppose dual-funding with splice-in would solve all my problems
18:08 < zmnscpxj> yes, that is the direction we want to go with
18:09 < zmnscpxj> maybe nify can come later and describe dual-funding
18:09 < zmnscpxj> my understanding is that it is currently at beta-level, so expect bugs now haha
18:09 < polydin> lol yeah no worries maybe i'll just read the dual funding stuff in the mean time
18:10 < polydin> allowing for multiple channels just seemed like a quick workaround but i guess not!
18:10 < zmnscpxj> it is in the `openingd` directory but with a new `dualfundingd.c`
18:10 < zmnscpxj> errr `dualopend.c` I mean
18:10 < polydin> got it, yeah i'm good at the high level stuff but the codebase is intimidating 
18:10 < zmnscpxj> (that is how you know I am completely unfamiliar with the new dual-funding stuff)
18:10 < polydin> hahaha
18:11 < polydin> to elaborate on what i said earlier about how it's used, i just meant that i don't think it's plausible to scale the entire Bitcoin network on a user-user basis
18:12 < polydin> even using the lightning network
18:12 < zmnscpxj> what do you mean?
18:12 < polydin> i'm not saying lightning isn't amazing, because it's fucking amazing
18:13 < zmnscpxj> I am not understanding the "user-user basis"
18:13 < polydin> i mean that the current vision for lightning seems to be that users will send funds to other users directly through channels, and as long as there are enough channels and users this will work out
18:13 < zmnscpxj> Uh, no
18:13 < zmnscpxj> that is why it is a network
18:14 < zmnscpxj> so you connect to some existing random node on the network
18:14 < zmnscpxj> and hope that it has enough liquidity to reach your payee
18:14 < polydin> yes absolutely
18:14 < zmnscpxj> and by connecting, you also improve the liquidity of the network, yourself
18:14 < polydin> sorry i explained it poorly but that is what i meant
18:14 < zmnscpxj> okay
18:14 < polydin> that is also true
18:15 < zmnscpxj> you might want to check out my clboss project, which is at alpha level: https://github.com/ZmnSCPxj/clboss.git
18:15 < polydin> but when i think of, how do you scale this currency to billions of users, the complexity of such a graph would be unmanagable by end users
18:15 < zmnscpxj> I hope to make some kind of decent announcement some time this month
18:15 < zmnscpxj> yes, hence clboss
18:15 < zmnscpxj> to manage your node for you
18:16 < polydin> oh shit i'll definitely read this!
18:16 < zmnscpxj> it is still at very alpha level, I literally started writing it last month
18:16 < polydin> but this liquidity is the real problem imo
18:16 < zmnscpxj> so do not get your hopes up yet
18:16 < polydin> lol ok
18:17 < polydin> i have a different direction for what i think can scale
18:17 < polydin> but many will probably not like it
18:17 < zmnscpxj> but I hope it is at least useful to let people "just have" a Lightning node without having to be specialized node managers
18:17 < polydin> because it's based on banking
18:17 < polydin> yeah that would be nice to get exposure
18:17 < zmnscpxj> centralized hubs, yes, that is the current way that LN is being used
18:18 < zmnscpxj> which is why there are so many mobile nodes that just connect to a small handful of nodes
18:18 < polydin> no i think not even this is enough
18:18 < zmnscpxj> I agree
18:18 < polydin> to scale to billions
18:18 < polydin> it is not enough
18:18 < zmnscpxj> you might also want to look at the more blue-sky research like Channel Factories
18:19 < polydin> i've looked at channel factories, again, not enough
18:19 < zmnscpxj> okay, how so?
18:19 < polydin> from what i've read and learned, the only way is to decouple the lightning network from end users entirely
18:19 < polydin> and use it as an interbanking protocol
18:19 < polydin> nobody talks about this
18:19 < zmnscpxj> ah, custodial, you mean?
18:20 < polydin> yes
18:20 < polydin> that is why it's hard to sell
18:20 < zmnscpxj> I personally do not think it as an interesting solution, because custodial solutions are trivial to develop
18:20 < polydin> but to me it's the only way
18:20 < zmnscpxj> BlueWallet released a custodial LN fairly early, for example
18:21 < polydin> custodial in what way?
18:21 < zmnscpxj> (unless I mixed up the wallet names again haha)
18:22 < zmnscpxj> I remember seeing a custodial LN wallet released for mobile phones, a little after the Blockstream Store debuted
18:22 < zmnscpxj> I might not remember the name so well, because I am personally not interested in custodial solutions, haha
18:22 < polydin> haha yeah i get it, just doesn't have the same allure
18:22 < zmnscpxj> the interesting bit is "how far can we scale without having to invoke custodians?"
18:23 < zmnscpxj> and I think we still have runway left for that, e.g. multifundchannel, channel factories
18:23 < zmnscpxj> I mean we cannot onboard billions **now**
18:23 < zmnscpxj> but with those, we might be able to onboard several hundred thousand, non-custodially
18:24 < zmnscpxj> and later, we might be able to figure out how to scale even further, still non-custodially
18:24 < polydin> but what for?
18:24 < zmnscpxj> for the current demand
18:24 < polydin> you could possibly get to hundreds of millions with the lightning network IMO
18:24 < polydin> but it would be shaky
18:25 < zmnscpxj> but there is no demand *yet*, and we still have bits we can implement that are still non-custodial
18:25 < zmnscpxj> so that is what I think is worth working on
18:25 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
18:25 < polydin> yeah i get that, i guess i just wanna race towards the future lol
18:26 -!- sr_gi [~sr_gi@static-128-69-224-77.ipcom.comunitel.net] has joined #c-lightning
18:26 < polydin> i envision Bitcoin as the foundation of an internet native banking network
18:26 < zmnscpxj> I get that too, but sometimes it helps to be more prepared and to strive not to give up on non-custodiality (or any other principles) as much as you an
18:26 < zmnscpxj> maybe later, when push comes to shove
18:27 < zmnscpxj> laziness and all that
18:27 < polydin> lol!
18:27 < polydin> i don't know if it's laziness
18:27 < polydin> i'm writing an article about it now because i jsut wanna get it out there, i'll share with you
18:27 < zmnscpxj> anytime you make an effort just to avoid making effort, that is the true form of laziness
18:27 < zmnscpxj> !!
18:27 < polydin> yeah you're definitely a programmer
18:27 < polydin> lol
18:28 < polydin> i just think that banking is the natural evolution of a currency
18:28 < zmnscpxj> just look at Haskell, implementations have to keep track of whether an object is already evaluated or not, just to avoid having to expand expressions early!!!
18:29 < zmnscpxj> you could also check out my ruminations on bitcoin-dev re: aggregated investment, which I think is the true function of banks anyway
18:29 < polydin> what is aggregated investment
18:30 < zmnscpxj> a bank "just" aggregates investors
18:30 < zmnscpxj> they offer you a tiny interest to entice you to save your money with them
18:30 < zmnscpxj> then they take your money, and the money of several other savers, and invest it into various businesses
18:30 < zmnscpxj> which in aggregate gives them a return on investment
18:31 < zmnscpxj> which is what funds the interest on your savings accout
18:31 < zmnscpxj> that is investment aggregation
18:31 < polydin> got it
18:31 < zmnscpxj> however, investment aggregation done this way is custodial
18:31 < polydin> what you say is true, but it's not the full picture
18:32 < zmnscpxj> I have some ruminations where it may be possible to remove the custodiality of banks, though of course you still have to release custody to the business(es) being invested in
18:32 < zmnscpxj> but at least removes custodial risk from banks
18:32 < polydin> i would argue you could never remove custodial risk from banks
18:32 < zmnscpxj> you just have default risk from borrowers
18:33 < polydin> you cannot remove trust from an investment, aggregated or non-aggregated
18:33 < polydin> all investments require trust
18:34 < zmnscpxj> true, but you can reduce the trust to just "trust in the borrower", not "trust in the borrower AND the bank"
18:35 < zmnscpxj> that which cannot be eliminated can sometimes be reduced, and reduction can still be beneficial
18:35 < polydin> for me, all of this has to do with complexity theory
18:35 < polydin> what you're describing is basically what the blockchain was supposed to be for sending money
18:36 < polydin> and ethereum pretends to be with "decentralized loans"
18:36 < polydin> the idea that you could remove the middleman
18:36 < polydin> but i think this is untrue
18:36 < polydin> at scale, there will always be middlemen
18:37 < zmnscpxj> again: that which cannot be eliminated can sometimes be reduced, and reduction can still be beneficial
18:37 < zmnscpxj> so we reduce the power of the middlemen
18:37 < polydin> i think the reduction pales in comparison to other benefits
18:37 < zmnscpxj> make sure it is easy to set up middlemen
18:37 < zmnscpxj> so there is strong competition between possible middlemen
18:37 < zmnscpxj> and so on
18:37 < polydin> i don't think one can make it easy to set up a middlemen, because the middleman requires liquidity
18:38 < polydin> the competition part i agree with though
18:38 < polydin> regardless to me this is not the most important thing about bitcoin
18:38 < zmnscpxj> anyone who has usefully worked for a while will have a pool of liquidity
18:38 < zmnscpxj> and that is what clboss targets
18:38 < polydin> agreed
18:38 < polydin> but in the end there will always be middlemen
18:38 < zmnscpxj> true, but their power can be reduced
18:39 < polydin> i don't think it will be, only that they will be have to take on the risk that comes from those positions
18:39 < polydin> that to me is the real power of bitcoin as a worldwide phenomenon
18:39 < zmnscpxj> well, human beings specialize, that is precisely how gains from trade come about
18:39 < polydin> so there will be banks, built on bitcoin and connected by the lightning network
18:40 < polydin> and those banks will be fractionally reserved, in bitcoin
18:40 < zmnscpxj> but still the basic free market mechanism must exist, and it should be easy for anyone to (1) save and (2) after saving, start up a business, including a bank
18:40 < polydin> but the reserve ratios will be enforced by participation in a worldwide banking network
18:40 < polydin> oh yeah 100% but that has always been true
18:40 < polydin> or at least bitcoin doesn't change that whatsoever
18:41 < zmnscpxj> Bitcoin does change that, because most jurisdictions make it difficult to start a bank
18:41 < polydin> yeah i'll give you that
18:41 < zmnscpxj> but if we can make bank-like constructions that do not get custody of funds
18:41 < zmnscpxj> then that can reduce the difficulty of creating a new bank
18:41 < polydin> agreed
18:41 < zmnscpxj> which makes free market assumptions work out more accurately
18:41 < polydin> i just don't think it can be done
18:41 < polydin> not at scale
18:42 < zmnscpxj> well, that is what we want to strive to do
18:42 < zmnscpxj> instead of giving up now, without even trying, right?
18:42 < polydin> i'm not talking about giving up
18:42 < polydin> i'm saying that's not what's important about bitcoin
18:43 < zmnscpxj> I think it is important about bitcoin, as it is the first time we can actually immanentize a true leviathan, no one made up of fallible humans
18:43 < polydin> what's important is that bankers who build banks on top of bitcoin cannot be bailed out by the government because nobody controls the money supply
18:44 < zmnscpxj> well yes, because the Bitcoin leviathan enforces the rules
18:44 < polydin> agreed, but in order to scale there will have to be banks
18:44 < zmnscpxj> I mean "Leviathan" in the political-science way, i.e. a government
18:44 < polydin> this is already happening
18:44 < polydin> i know what you mean
18:44 < polydin> regardless, there will be banks
18:44 < zmnscpxj> yes
18:44 < polydin> custodial banks
18:44 < zmnscpxj> yes,
18:45 < polydin> and they will be connected by lightning
18:45 < zmnscpxj> I just want to make it much, much easier to create a custodial bank
18:45 < polydin> and users will simply have accounts
18:45 < polydin> so do i
18:45 < zmnscpxj> so for example a clan might have their own personal custodial bank
18:45 < zmnscpxj> that sort of thing
18:45 < polydin> like basically if you have the capital you can do it
18:45 < zmnscpxj> or a new family
18:45 < polydin> yeah i get you, i'm for it
18:45 < zmnscpxj> and in practice, that is what we expect
18:45 < polydin> but again, those custodial banks will be subject to regulation
18:46 < zmnscpxj> even within families, humans specialize
18:46 < zmnscpxj> ideally, the regulation would be fully automated, as part of the Bitcoin Leviathan
18:46 < polydin> no i'm not talking about that at all
18:46 < zmnscpxj> admittedly, there will be gaps
18:46 < zmnscpxj> but we still want to move as much as possible into automation
18:46 < polydin> what the base layer of bitcoin does has nothing to do with whatever regulations occur between bitcoin banks and governments
18:46 < zmnscpxj> that is my primary focus
18:47 < zmnscpxj> but it does, because the government ideally should only impose those rules that the Bitcoin network itself cannot
18:47 < zmnscpxj> and the Bitcoin network may be more powerful than we might think now
18:47 < polydin> governments are going to impose whatever laws they can through the use of violence, period
18:47 < zmnscpxj> (or weaker, for that matter)
18:47 < polydin> what they should do is irrelevant
18:48 < polydin> it will most definitley be more powerful
18:48 < polydin> how it all plays out no one knows
18:48 < zmnscpxj> governments are made up of squishy humans. all you need is to outgun them or outrun them
18:48 < zmnscpxj> or outthink them
18:49 < zmnscpxj> anyway, I have to go for now
18:49 < zmnscpxj> have fun!
18:49 < polydin> ok bye bye
18:51 -!- polydin [~george@136.49.254.169] has quit [Quit: Leaving]
19:49 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
20:37 < rusty> zmnscpxj: to be fair, connectd could do the demuxing.  In some ways, this would be simpler, since it would handle the directing of msgs to gossipd so subds wouldn't have to handle them.  OTOH, it'd be a potential CPU bottleneck doing all the crypto.
20:38 < zmnscpxj> indeed, that is why I proposed `peerd`
21:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:18 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
21:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
21:49 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
23:02 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds]
23:21 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:24 -!- liberliver [~Thunderbi@144.49.211.130.bc.googleusercontent.com] has joined #c-lightning
23:38 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
23:39 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
23:40 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
23:59 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds]
--- Log closed Fri Oct 09 00:00:41 2020