--- Day changed Tue Aug 11 2015
00:10 -!- mjerr [~mjerr@p578EA5C9.dip0.t-ipconnect.de] has joined #lightning-dev
00:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
01:16 -!- CoinMuncher [~jannes@178.132.211.90] has joined #lightning-dev
01:19 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-fhhpjmswqtfqtwee] has joined #lightning-dev
03:10 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
04:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 246 seconds]
07:45 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
07:45 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev
08:07 < mjerr> Just published my work on a Lightning Network Payment Hub: https://www.reddit.com/r/Bitcoin/comments/3gldfn/alpha_thundernetwork_a_lightning_network/
08:22 < kanzure> mjerr: does this include p2p networking stuff like routing and fee negotiation of routes?
08:23 < mjerr> kanzure, it's currently single-hub unfortunately, due to being a low-trust and not a zero-trust solution. But it's not a problem to add the network layer on top, as soon as we have the needed bitcoin op-codes
08:24 < kanzure> i don't understand, does this mean it's single-hub and also incapable of low-trust hub hopping?
08:25 < mjerr> low-trust does fundamentally not allow multi-hub. the channels between the hubs are no different than the channels between users and hubs
08:25 < kanzure> so?
08:25 < kanzure> i don't understand. why can't the other hubs be trusted?
08:26 < kanzure> this is just a typical trusted setup problem of some kinda, ya?
08:26 < kanzure> where you don't add untrusted people into the network
08:26 < mjerr> it's not a can - we are trying to get around the complete trust issue. If we come to a point where we need trust, we can just use IOUs 
08:27 < mjerr> but I see your point, yea, we could add a trust network to have multiple hubs
08:27 < kanzure> ok, so my question then is, the implementation does not include that trust network?
08:28 < mjerr> no
08:28 < kanzure> do you mean yes?
08:29 < mjerr> umm - yes, it's not included. I don't like trust networks, as it would mean a high barrier of entry
08:29 < kanzure> alright cool
08:30 < mjerr> I think we have yet to determine the benefits and drawbacks of multi-hubs. With every additional hop, the locked-up funds increase
08:31 < mjerr> Of course it's nice to not have a single point of failure
08:32 < kanzure> hub network would have locked up funds but so would "every user has N channels open where N = number of hubs", heh
08:34 < mjerr> plus all the broadcasted transactions+blockchain fees
08:34 < kanzure> i'm also curious if there should really be a difference between clients and hubs. the client is really just a poorly-performing hub, but otherwise should be the same implementation i think?
08:34 < kanzure> other than the gui
08:35 < mjerr> yea, I used pretty much the same code on client and server, the database is the same aswell
08:37 < mjerr> but there are of course many obligations for the hub.. it's difficult and really depends on the implementation. I think the main goal should be to reduce the on-chain transactions, while providing a similar use-experience for uncritical payments
08:37 < kanzure> similar? similar to what?
08:38 < mjerr> if everybody does have dozens of channels to various people and hubs, this might not be helpful at all to the blocksize issue
08:38 < mjerr> similar to blockchain payments
08:40 < kanzure> right, you only need a handful of channels per person, as long as there is a hub network available
08:42 < mjerr> What I see coming is a network of hubs around the location, as it will optimize the work-load and fund-usage. people might get paid in the channel and they will use most of that money to pay other people connected to the same hub
08:42 < mjerr> which will then reduce hopping
08:46 < mjerr> but due to the fact that the payment hub can't really confiscate your funds, I don't see too much of a problem with just one really large hub. Of course downtime is an issue, but you can always have redundancy. everyone hates paypal, not because the user experience, but rather because what they (can) do with your money
09:28 -!- jlrubin_ [~jlrubin@biohazard-cafe.mit.edu] has joined #lightning-dev
09:29 < jlrubin_> Hey! The logging seems to be dead here.
09:44 < kanzure> then setup a logging bot
10:03 < jlrubin_> non-helpful; was looking to see prior logs
10:04 < jlrubin_> AnAnd I have, I'm notw keeping a log as my client is configured to do so
10:05 < jlrubin_> in any case, thoughts on the "thunder" network that was just put out?
10:20 < aj> thunder network?
10:20 < aj> oh, url was in scrollback
10:58 < jlrubin_> and it seems a python implementation as well.
11:05 < jlrubin_> Interesting that so many implementations are surfacing so quickly
11:10 < mjerr> interesting
11:10 < mjerr> haven't seen that
11:12 < mjerr> I wonder what his channel design is like, especially since he included p2p already
11:15 < aj> mjerr: i'm confused by your diagram; is the top half of the boxes meant to be inputs, or..?
11:15 < mjerr> yep
11:16 < aj> mjerr: then why do the refund txns only have ~0.2 btc in inputs, rather than 1.9998 ?
11:16 < aj> err, 1.0998 i mean
11:16 < mjerr> oh, a mistake, will fix that asap
11:17 < aj> the TX v0 ones have the same i think
11:17 < mjerr> yea, you are right
11:17 < mjerr> ah, the v0 in the 2. diagramm are right
11:20 < mjerr> the yellow transactions are signed and sent to the client aswell, such that he can claim these outputs, in case the server publishes his channel
11:20 -!- CoinMuncher [~jannes@178.132.211.90] has left #lightning-dev []
11:25 < aj> mjerr: (might be easier to follow if you just used whole numbers; like A deposits 1.0001 btc, B deposits 4.0001 bitcoin, result is 3 btc change for A, 2 btc in channel, 0.0002 btc in fees?
11:26 < aj> err, change for B
11:26 < mjerr> aj, yea, might be right. Yes, there is 0.0002 btc in every transactions, to show how it is deducted from the client's balance
11:28 < aj> mjerr: so maybe  A deposits 1.0004; balance is 1.0006 (after 0002 fees); then balance is 0004, 0002 and 0000 ?
11:28 < mjerr> you mean he deposits 1.0006 and the balance is 1.0004?
11:29 < kanzure> i was going to write the multi-hop implementation this weekend but if python dude has it already then i'm more than happy to forego it
11:30 < aj> mjerr: A deposits 1.0004, B deposits 3.0004, change is 2, balance is 2.0008
11:30 < aj> mjerr: (well, 2.0006 after 0002 fees)
11:44 < mjerr> aj, sorry, was busy replying
11:44 < mjerr> yea, the balance of both parties
11:45 < mjerr> the balance of A (client) is 1.0002 and the balance of B (hub) is 2.0004, considering a change of 1 btc for both
11:46 < mjerr> aj, do you mind trying to build the repository on your system? I'm pretty new to this whole deployment process, seems I might have done a mistake somewhere
12:01 -!- Guest57722 [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Ping timeout: 244 seconds]
12:02 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #lightning-dev
12:02 -!- maaku is now known as Guest45276
12:28 -!- jlrubin_ [~jlrubin@biohazard-cafe.mit.edu] has quit [Ping timeout: 250 seconds]
12:31 -!- jlrubin_ [~jlrubin@biohazard-cafe.mit.edu] has joined #lightning-dev
13:34 -!- go1111111 [~go1111111@162.244.138.37] has joined #lightning-dev
13:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
13:48 -!- mjerr [~mjerr@p578EA5C9.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds]
14:13 < kanzure> there might be a way to do a flooding network for transactions
14:13 < kanzure> where hubs only have payment channels with each other over tor? eh nevermind
14:13 < kanzure> ah right, yes that works as long as you only slowly ramp up the size of your channels
14:14 < kanzure> and as long as you shitdrop any connections that are misbehaving
14:18 < kanzure> er, the reason why this would be useful is because it may be beneficial to have everyone passing around transactions (at least until they find useful temporary routes)
14:19 < kanzure> e.g. so it is lightning network traffic routing in addition to actual payment channel routing
14:19 < kanzure> ((nodes that want higher performance for only channel-specific traffic could be configured to do so, but i'm not convinced that's a good default for the health of the network))
14:26 -!- fkhan [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 240 seconds]
14:26 < rusty> kanzure: routing is an open question, indeed.  Spray and pray works pretty well while the network is small, and is simple...
14:26 < kanzure> well, i was actually thinking for regulatory reasons, spray and pray might be an important default
14:27 < rusty> kanzure: one problem with onion routing is that it's hard to know which node is misbehaving.  The node you're getting it from might not know...
14:27 < kanzure> i don't think onion routing is going to work for this
14:27 < kanzure> unless you have a central directory
14:28 < rusty> kanzure: well, the anchor transactions form a rough map, themselves.
14:28 < kanzure> aren't they using unique addresses each time?
14:28 < rusty> kanzure: I assumed so, but they could still encode some data in the tx.
14:29 < kanzure> i wouldn't recommend that :-)
14:29 < kanzure> i think having nodes keep the routes private can work
14:30 < kanzure> both for network traffic and payment channel network
14:30 < kanzure> each node on the network would have a unique id for the route request, sends it out to its peers, returns the possible choices to the original requester
14:30 < rusty> kanzure: well, you need pricing information, which will be dynamic.  SO there needs to be some route advertisement protocol.
14:31 < kanzure> not sure it should be advertised.. just query your known peers, see what's up, see what fee estimates they give, then get them to commit.
14:31 < kanzure> do you have a .proto file ready to go for things like fee auctions and negotiations?
14:31 < rusty> kanzure: that's fatal for privacy.
14:31 < kanzure> the other day i was speculating that there is a tradeoff between transactional privacy and network graph privacy. hopefully i'm wrong.
14:33 < rusty> kanzure: here's a strawman, then.  We select 10 random "beacon" hubs based on blockhash when a new block is released.  Everyone figures out their optimal route to and from these nodes.  When A wants you to send a payment, they supply routes from 100 beacon nodes to them.
14:34 < kanzure> "We select" the client selects..?
14:34 < rusty> kanzure: closest-hash-wins.
14:34 < kanzure> anyway, i'm sure your method could work, seems to have high transactional privacy, but low network graph privacy
14:34 < kanzure> because someone can query for various routes to various beacon nodes
14:35 -!- Janaka-Steph [~Janaka-St@che77-1-82-238-24-26.fbx.proxad.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:37 < kanzure> also i agree with the approach of the merchant (or whoever) giving the sender some information out-of-band. it's a clever trick, we could pipe as much data as we like through that channel.
14:40 -!- Guest45276 is now known as maaku
14:41 < rusty> kanzure: yes, if you're a beacon node you want the traffic.  Sorry, high prio interrupt: kids waking up :)
14:41 -!- fkhan [weechat@gateway/vpn/mullvad/x-vixormhgemsdqfmb] has joined #lightning-dev
14:44 < kanzure> if you're okay iwth the network grpah being easily or trivially known, why bother with beacons? why not a central directory?
14:45 < aj> kanzure: centralisation is bad?
14:46 < kanzure> sure is, but so is knowing the graph
14:47 < aj> kanzure: how is knowing the graph bad, though? nodes are only identified by keys
14:47 < kanzure> huh? this was for network routing
14:48 < aj> kanzure: to route a txn you only need each node to do IP routing to its direct neighbours
14:48 < kanzure> my understanding of onion routing is that you must know the keys for each step in the path
14:49 < aj> kanzure: yeah
14:49 < kanzure> anyway, knowing the graph is bad because you can attack nodes off-network
14:49 < aj> kanzure: i want to route from K_Alice to K_Bob to K_Carol to K_Dave. I know K_Alice's IP, so I send it there. Alice know's K_Bob's IP, etc. I don't need to know anyone else's IP, Alice doesn't need to know Carol or Dave's
14:50 < kanzure> yes, and you know k_alice's ip and key.
14:50 < aj> yes, because i have a channel open with her
14:51 < aj> i don't necessarily have any idea of her name
14:51 < kanzure> ah so you are assuming the only relayed traffic is for payments over payment channels, no other p2p discovery and routing traffic?
14:52 < kanzure> i think you can open payment channels without knowing ip addresses, if you design the thing clever enough
14:52 < aj> i assume /something/ is necessary (otherwise you have a centralised routing service), but i don't know what it is
14:53 < aj> announcing IPs to everyone doesn't seem like a win
14:53 < kanzure> more broadly, it sounds like you guys disagree that network connectivity needs to be kept private? true/false/what?
14:53 < kanzure> and also, why should nodes need to keep static ip addresses? is that really important?
14:54 < kanzure> eh nevermind on the second part.
14:54 < aj> you need an IP address in order to communicate; doesn't need to be static
14:55 < aj> i was thinking the channel graph would be largely public, but IPs would be largely private
14:56 < aj> but if you have an identifier for a hub, maybe keeping its IP semi-secret doesn't do much good against a real world attacker
15:00 < kanzure> it would be good to postulate what the attack might be, and whether it's worth worrying about
15:00 < kanzure> i was expecting something like "oops everyone needs a money transmission license"
15:01 < kanzure> which might not be the end of the world
15:02 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
15:06 < aj> kanzure: "everyone needs a money transmission license, and only my bestest friends Mastercard and Visa can get them", "everyone needs to connect to the internet via NSA.ISP", "oh, you want to receive money, shame if I DoS your upstream hub until you pay me a billllion dollars"
15:08 < kanzure> well, for licensing, it's more like "if the network graph is known and someone can easily get all the ip addresses, then ISPs can be pressured into dropping those users or the ISP can be sanctioned" (but again, this might not be as bad if you can't get the ip addresses)
15:09 < kanzure> there are many options for anti-dos, so i'm not as worried about that, although hub operators will of course have to be aware of typical dos defense
15:09 < kanzure> as for nsa ip, i'm willing to consider that one out of scope :-)
15:09 < kanzure> *nsa isp
15:11 < aj> i was more thinking "IP is known, they can ask your ISP for your home address, and serve a subpoena"
15:12 < kanzure> also: i was expecting "randomly create new payment channels with minimum amounts (say 1 BTC) and then as their reliability increases, increase the reserved capital for that channel" would be a default behavior for most clients, but from what i'm hearing it sounds like the only connections will be for hubs with payment channels between each other and it would some manual trusted setup between hub operators?
15:12 < kanzure> (oh also i was assuming no difference between hubs/clients, except hubs are expected to have more uptime than things like hubs on phones)
15:14 < aj> revealing IPs of clients would be pretty bad
15:15 < kanzure> bitcoind ip addresses are revealed all the time on the network, you can connect to whatever
15:15 < aj> not sure how increasing the capital for a channel would actually work; maybe maintain dual commitments until the updated amount has confirmed
15:16 < aj> yeah but bitcoind ip addresses aren't strongly linked to unspent wallet addresses with hotkeys
15:17 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds]
15:17 < kanzure> heh good point
16:06 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds]
16:32 -!- Adlai [~Adlai@unaffiliated/adlai] has quit [Ping timeout: 246 seconds]
16:46 -!- Adlai [~Adlai@bzq-79-180-179-78.red.bezeqint.net] has joined #lightning-dev
17:13 -!- Adlai [~Adlai@bzq-79-180-179-78.red.bezeqint.net] has quit [Quit: Insufficient entropy for original quit message]
17:14 -!- Adlai [~Adlai@unaffiliated/adlai] has joined #lightning-dev
18:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
18:25 -!- cixx` [rob@2001:984:6466:0:d052:c2dc:952b:5b8a] has quit [Read error: Connection reset by peer]
21:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
21:45 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
22:42 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
23:17 -!- mjerr [~mjerr@p578EA5C9.dip0.t-ipconnect.de] has joined #lightning-dev
23:36 < mjerr> can anyone explain to me, why josephpoon thinks a multisig based revocation does not work? ( https://www.reddit.com/r/Bitcoin/comments/3gldfn/alpha_thundernetwork_a_lightning_network/ctzkv25 )
23:49 -!- CoinMuncher [~jannes@178.132.211.90] has joined #lightning-dev