--- Day changed Mon Mar 14 2016
00:05 -!- mr_burdell_ [~mr_burdel@bounce.cryptolabs.net] has joined #lightning-dev
00:07 -!- pigeons_ [~pigeons@94.242.209.214] has joined #lightning-dev
00:07 -!- heath__ [~heath@unaffiliated/ybit] has joined #lightning-dev
00:15 -!- Netsplit *.net <-> *.split quits: heath, phantomcircuit, mr_burdell, gijensen, pepesza, pigeons
00:15 -!- mr_burdell_ is now known as mr_burdell
00:16 -!- Netsplit over, joins: pepesza
00:16 -!- Netsplit over, joins: gijensen
00:16 -!- mr_burdell is now known as Guest67852
00:17 -!- Netsplit over, joins: phantomcircuit
00:56 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
00:56 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
01:08 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nrjfexockfacksuq] has joined #lightning-dev
01:27 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev
01:31 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 248 seconds]
01:40 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev
01:42 -!- drwasho [~drwasho@58-6-207-90.dyn.iinet.net.au] has quit [Ping timeout: 276 seconds]
02:13 -!- jannes [~jannes@178.132.211.90] has joined #lightning-dev
02:52 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #lightning-dev
03:28 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
04:59 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
05:02 -!- Guest67852 is now known as mr_burdell
05:02 -!- mr_burdell [~mr_burdel@bounce.cryptolabs.net] has quit [Changing host]
05:02 -!- mr_burdell [~mr_burdel@unaffiliated/mr-burdell/x-7609603] has joined #lightning-dev
05:27 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #lightning-dev
05:28 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #lightning-dev
05:32 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]
06:00 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
06:13 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #lightning-dev
07:23 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: Leaving]
08:20 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Ping timeout: 240 seconds]
08:28 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
08:43 -!- wasi [~wasi@pub082136074119.dh-hfc.datazug.ch] has joined #lightning-dev
09:14 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
09:23 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
09:36 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #lightning-dev
10:10 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #lightning-dev
11:07 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
12:06 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #lightning-dev
13:50 -!- Anastasios [~Anastasio@h-239-4.a328.priv.bahnhof.se] has joined #lightning-dev
14:44 -!- pigeons_ is now known as pigeons
14:55 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
17:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:20 -!- belcher [~user@unaffiliated/belcher] has joined #lightning-dev
17:53 -!- wasi [~wasi@pub082136074119.dh-hfc.datazug.ch] has quit [Quit: Leaving]
17:58 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
18:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-nrjfexockfacksuq] has quit [Quit: Connection closed for inactivity]
18:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []
18:45 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
18:45 -!- mol11111 [~molly@unaffiliated/molly] has joined #lightning-dev
18:46 -!- mol11111 is now known as moli
18:59 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 240 seconds]
19:19 -!- Anastasios [~Anastasio@h-239-4.a328.priv.bahnhof.se] has quit []
19:24 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
21:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Excess Flood]
21:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
21:21 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #lightning-dev
21:52 < rusty> aj: I've been warming to the idea that we use the on-chain anchor txs as our map.  You still need to send the redeem script + signatures + metadata somehow, but on-chain means we have a nice shorthand for routing (blocknum + txindex).
21:53 < aj> (+vout)
21:54 < aj> rusty: i'm not sure how much that actually helps with everything being p2sh with segwit; you still have to transmit keys separately somehow since you can't derive them from the onchain tx
21:56 < rusty> aj: I havent' studied SW in detail, but I'm pretty sure you can go from tx's P2sh-style to prove what the redeemscript is (and hence the keys), and use those keys to sign the metadata.
21:57 < aj> rusty: yeah, you can prove what the redeemscript is, but that doesn't save you anything over the wire -- if you're transmitting the keys anyway, you don't need to know the txid
21:57 < aj> rusty: might be helpful when announcing updates to the channel parameters though?
21:58 < rusty> aj: sure.  I'm assuming everyone knows the static public route map, basically.  And then you can say "route is 402716/7/0 -> 40440/562/1 -> ... "
21:59 < rusty> (Oh, add fee rates in there, too).
22:01 < aj> ie, channel announce = 120 bytes (32 key, 32 key, 4-8 tx reference, 4 fee, 4 timeout, 4 current capacity, 4 bitfield supported optional features, 32B signature)
22:01 < aj> then channel update = 56 B dropping the two keys
22:02 < rusty> aj: You need two signatures, I think (unless Shnorr)
22:02 < aj> i was assuming either side could announce updates on their own, but schnorr works too
22:04 < aj> 402716/7/0 would be an edge, while each pubkey would be a node
22:05 < aj> oh, oops a sig is 64B not 32B
22:05 < rusty> aj: initial announce probably needs both sides.  Fee updates will probably be "base + per-satoshi-rate".  
22:06 < aj> fees are meant to be directional too
22:06 < rusty> aj: indeed.
22:07 < rusty> aj: and to tie a channel to a tx needs blocknum + txnum + merkle proof + tx + redeemscript.
22:09 < aj> rusty: merkle proof shouldn't be needed; just a blocknum+txnum+vout where the blocknum is buried far enough that everyone agrees on what the block is; that gets you a scriptsig, which you just need to fill out the two pubkeys to match "2 __ __ 2 CHECKMULTISIG" ?
22:10 < rusty> aj: sure, we can force them to query bitcoin network for it.
22:12 < aj> ah... well, if you provide a merkle path and tx you don't need the txnum
22:12 < rusty> aj: indeed.  Then I can then hand you a route from a landmark to me in about [blocknum][txnum][outnum][feebase][feeprop] per hop, which probably fits in 16 bytes or so.  I want as many routes as possible to fit in a QR code, so payee can provide numerous landmarks for payer to choose from.
22:12 < rusty> aj: well, txnum is part of merkle path, sure.
22:14 < rusty> You can probably compress far more if you assume they know the entire map (make them solve shortest path between the points you give), but that feels fragile.
22:16 < aj> if they have the map and can solve shortest paths, you just give them your address and you're done
22:16 < rusty> aj: they won't have the dynamic information.
22:16 < aj> can't solve shortest path without the dynamic information :)
22:17 < rusty> aj: hence you give them some points.  Worst case you spell them all out.
22:18 < rusty> aj: that's the real problem.  Even if we ratelimit dynamic updates, and add a time factor ("my fee will increase by 0.1 satoshi/byte for the next 20 seconds"), we can't do the entire world, we need landmarks.
22:18 < rusty> aj: not to mention the problem of someone without capacity offering negative fees and blackhole routing everyone.
22:19 < rusty> But one problem at a time...
22:21 < aj> yeah, get something obviously bad but functional up and running
22:24 < aj> rusty: https://v.etherpad.org/p/lightning_routing_messages
22:46 < aj> hmm, a 64B signature for a 10B update seems a lot of overhead. i guess it makes more sense to update both directions simultaneously anyway
23:03 < aj> rusty: so for the irc protocol, if you only broadcast each edge once a day, say, then a new node will take an entire day to see the graph and be able to route successfully (could probably do a good job with maybe half the edges, so maybe 12 hours...)
23:04 < rusty> aj: For IRC, I'd announce every hour.
23:07 < aj> rusty: every hour for the full info, up to every 5 minutes for the dynamic info?
23:07 < rusty> aj: makes sense.
23:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 276 seconds]