--- Day changed Tue Aug 18 2015
00:16 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 260 seconds]
00:30 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 260 seconds]
02:25 -!- Janaka-Steph [~Janaka-St@che77-1-82-238-24-26.fbx.proxad.net] has joined #lightning-dev
04:00 -!- CoinMuncher [~jannes@178.132.211.90] has joined #lightning-dev
04:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
04:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds]
04:36 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-pcfntjouqoxuybjg] has quit [Ping timeout: 256 seconds]
05:28 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-jruqsutmcwdkdzrn] has joined #lightning-dev
05:44 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-jruqsutmcwdkdzrn] has quit [Ping timeout: 240 seconds]
06:37 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-egqykafxppeelelc] has joined #lightning-dev
06:54 -!- StephenM347 [~stephenm3@50-195-53-73-static.hfc.comcastbusiness.net] has joined #lightning-dev
07:52 -!- Madars_ [~null@unaffiliated/madars] has joined #lightning-dev
07:56 -!- Netsplit *.net <-> *.split quits: Madars, ftlio, heath_
07:57 -!- heath [~heath@unaffiliated/ybit] has joined #lightning-dev
08:02 -!- ftlio [~ftlio@46.166.188.251] has joined #lightning-dev
08:12 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
08:33 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-egqykafxppeelelc] has quit [Remote host closed the connection]
08:48 -!- jlyndon [sid10913@gateway/web/irccloud.com/x-xxubgqwrcnljxhlt] has joined #lightning-dev
09:19 -!- pm_ [5398c8b2@gateway/web/freenode/ip.83.152.200.178] has joined #lightning-dev
09:22 -!- pm_ [5398c8b2@gateway/web/freenode/ip.83.152.200.178] has quit [Client Quit]
10:08 -!- CoinMuncher [~jannes@178.132.211.90] has quit [Quit: Leaving.]
11:16 -!- Janaka-Steph [~Janaka-St@che77-1-82-238-24-26.fbx.proxad.net] has quit [Quit: My Mac Pro has gone to sleep. ZZZzzz…]
11:16 -!- ftlio_ [64208d9a@gateway/web/freenode/ip.100.32.141.154] has joined #lightning-dev
11:29 -!- Janaka-Steph [~Janaka-St@che77-1-82-238-24-26.fbx.proxad.net] has joined #lightning-dev
11:34 -!- MickyRartin [~MickyRart@c-71-198-25-11.hsd1.ca.comcast.net] has joined #lightning-dev
11:35 < MickyRartin> Hello
11:35 -!- Squidicuz [~squid@pool-72-74-133-29.bstnma.fios.verizon.net] has joined #lightning-dev
11:35 < MickyRartin> I have a question
11:36 < MickyRartin> What is required to send a LN transaction from a wallet ?
11:36 < MickyRartin> Currently, you have to have a bitcoind/SPV wallet running to send a transaction onto the bitcoin network.    How is LN different ?
11:37 < MickyRartin> **bitcoind/SPV node
11:37 < aj> MickyRartin: does http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010116.html and http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010113.html help?
13:25 -!- Janaka-Steph [~Janaka-St@che77-1-82-238-24-26.fbx.proxad.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
14:22 < MickyRartin> Yes it does.  thank you.  Seems like usability of LN is even worse than bitcoin.
14:24 < MickyRartin> So  0.1 "Choose a hub to connect to"
14:24 < MickyRartin> your LN wallet would query some server to get a list of LN providers..
14:26 < MickyRartin> Once you're selected a few LN providers, you need to lock in funds with them for spending later...  Then you go to some place to spend your coins and hopefully there is a route between their LN and your LN provider.
14:27 < MickyRartin> Sounds beautiful, in theory.  Question is, how do you bootstrap this?
14:27 < gwillen> The usability of LN depends on the existence of routes between most LN providers, but I would expect there would be, since it's their business model to be able to route transactions.
14:27 < gwillen> From the user perspective, once you're on an LN provider, I feel like the UX is smoother for small, fast payments since you don't have to pay individual TX fees or wait for confirms
14:28 < MickyRartin> How are LN provider relationship built?
14:29 < kanzure> randomly
14:30 < kanzure> they an also be built manually, but i don't care about this method
14:30 < MickyRartin> Does is make sense to form a complete mesh of relationships?   How can relationships be accepted and revoked?
14:30 < gwillen> I don't think 'randomly' is accurate
14:30 < kanzure> (so i am less likely to elaborate about the manual method)
14:30 < kanzure> i think randomly can work
14:30 < gwillen> hmm
14:30 < gwillen> each link has to have some funds locked up
14:30 < kanzure> you can open payment channels with rnadom hubs as you please, send some small amount of capital, once a channel has been used a bit you can increase the cpaital in the channel
14:30 < gwillen> so I would expect channels to be opened based on business relationships rather than randomly
14:30 < kanzure> e.g. you can use short-term locktimes
14:30  * gwillen nods
14:31 < MickyRartin> Ah, so you would choose each channel, because there is a real cost associated with each connection
14:31 < kanzure> for the sake of the health of the network we should encourage some % randomness by default so that links are developed anonymously and such
14:31 < gwillen> well as kanzure noted, you can start small and grow
14:31  * gwillen nods
14:31 < kanzure> there's a way to ramp up a channel as you continue to see that that the remote hub operator is not a mad clown
14:32 < ftlio_> you'd still want to make sure you couldn't find a cheaper route though over time?
14:32 < kanzure> MickyRartin: your software would do fee negotiation for routing through different possible routes of hubs, because doing that manually would be ugh
14:32 < kanzure> ftlio_: yes, and that's another good reason for doing random connections- you might find a much cheaper route for a lot of your payment traffic
14:32 < MickyRartin> The odd thing is that whatever the current money velocity is, more that than is required to be tied up in the channels.
14:33 < ftlio_> right now there are a lot more bitcoin than being transacted in a day though?
14:33 < MickyRartin> How random selection of many LN ensure that there is solid links to popular sources and destinations ? 
14:33 < MickyRartin> They seem like higher cost low volume channels
14:34 < ftlio_> it won't be purely random in the long term
14:34 < MickyRartin> *How does random....
14:34 < MickyRartin> So large channels will naturally develop 
14:34 < kanzure> payment to a merchant will probably happen with a system similar to BIP70, so the merchant can include information about his hubs
14:35 < kanzure> if the unfortunate user is the first lightning user that is using a completely different lightning network that has never been connected, then the BIP70-equivalent protocol is going to need a way to encourage some hubs to make some new connections- and payments will be delayed. however, this is strong incentive to not have isolated lightning networks in the first place.
14:35 < MickyRartin> what's the ETA of this system gaining traction ?
14:35 < ftlio_> a while lol
14:35 < ftlio_> but not that long
14:36 < MickyRartin> Every wallet and service needs to be updated
14:36 < ftlio_> plus it depends on greater blockchain economics 
14:37 < MickyRartin> there's no way you can use blockchain economics to push this adoption..... Unless we went with 50k blocks
14:37 < ftlio_> no no
14:37 < ftlio_> just saying, it depends on the whole ecosystem
14:37 < ftlio_> not trying to start that argument here
14:37 < MickyRartin> aah, true.  What are the immediate advantages for LN ?    
14:38 < ftlio_> off-chain microtransactions 
14:38 < ftlio_> say you're Digital Ocean or AWS, you can collect fees immediately for each hour of usage
14:38 < MickyRartin> What is going to drive Blockchain.info to write 5 bad implemenations of it first, get hacked, before other wallets decide to do it better?
14:39 < ftlio_> so there's an instance where you don't need a fully developed network to start using it
14:39 < ftlio_> lol, i dunno.  there are a few implementations running on top of bitcoind being developed right now
14:40 < MickyRartin> I see, that's if AWS builds out truly open and on demand computing instances
14:40 < MickyRartin> It sounds wonderful, but at the same time it's like bootstrapping bitcoin in 2009 again
14:40 < ftlio_> and it also depends on bitcoin
14:41 < ftlio_> it's still going to be useful though
14:41 < MickyRartin> Are their a lot of resources being devoted to it yet?   There's like 30 people in this channel
14:41 < ftlio_> i don't know, i'm just some guy
14:42 < ftlio_> i know i've picked it up in my spare time and i'm trying to do useful stuff
14:42 < ftlio_> i got hung up on looking into name addressable networking
14:42 < MickyRartin> lol, ok,  maybe some one else can chime in.
14:45 < MickyRartin> ftlio_ thanks for your input,   I hope LN is adopted soon.
14:47 < MickyRartin> Another thought.., having connections to Localbitcoins will be obvious, so will connections to the DM.   Doesn't that mean Coinbase will have even great leverage at controlling where your funds can and can't be spent.
14:56 < ftlio_> It's limited by the destination, no?  If you want to pay me, it depends on who I have channels open with.
15:02 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 272 seconds]
15:05 < MickyRartin> So somewhere on your site, you have to provide me a destination address and a list of open channels 
15:06 < MickyRartin> then my wallet would have to see if any of my channels can reach yours
15:07 < MickyRartin> is that an easy mathematical calculation?  or is a small test payment required?
15:13 -!- StephenM347 [~stephenm3@50-195-53-73-static.hfc.comcastbusiness.net] has quit []
15:18 < ftlio_> https://en.wikipedia.org/wiki/Scalable_Source_Routing
15:19 < ftlio_> if we imagine the smaller scale network starting out as fairly gossipy, it probably wouldn't be hard to get a route to your destination
15:19 < ftlio_> plus you can do onion routing / encryption to further obfuscate things
15:20 < ftlio_> there are just a lot of use cases to handle
15:20 < MickyRartin> Are LN able to be ran behind TOR ?
15:21 < ftlio_> I think the plan is to bake onion routing into it
15:23 < ftlio_> you'll still be able to get a decent picture of the network topology from the blockchain, since channels are initiated with timelocked (or sequence locked) transactions 
15:23 < ftlio_> but that won't necessarily tell you who paid who
16:33 -!- Guest34456 is now known as maaku
16:46 -!- Madars_ is now known as Madars
16:49 -!- Pilot8 [~MickyRart@c-71-198-25-11.hsd1.ca.comcast.net] has joined #lightning-dev
16:51 -!- MickyRartin [~MickyRart@c-71-198-25-11.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
17:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
18:05 -!- Pilot8 [~MickyRart@c-71-198-25-11.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
20:07 -!- Squidicuz [~squid@pool-72-74-133-29.bstnma.fios.verizon.net] has quit [Ping timeout: 252 seconds]
21:42 -!- KFl6WxEUI1Zbp2 [~konichiwa@50.141.29.32] has joined #lightning-dev
23:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []