--- Day changed Wed Sep 02 2015
00:21 -!- richardkiss [~richardki@70-36-142-78.dsl.dynamic.fusionbroadband.com] has joined #lightning-dev
00:43 < rusty> aj: because it just finished :)
00:45 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev []
01:14 -!- richardkiss [~richardki@70-36-142-78.dsl.dynamic.fusionbroadband.com] has quit [Quit: richardkiss]
01:47 -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
01:53 -!- CodeShark [CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 264 seconds]
02:02 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.]
02:02 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #lightning-dev
02:03 -!- maaku is now known as Guest91763
03:40 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds]
03:54 -!- mjerr [~mjerr@p578EB313.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds]
05:24 -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has quit [Ping timeout: 250 seconds]
05:24 -!- jeremyrubin [~jeremyrub@biohazard-cafe.mit.edu] has joined #lightning-dev
06:11 -!- Guest91763 [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.]
06:12 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #lightning-dev
06:13 -!- maaku is now known as Guest93019
08:12 -!- mjerr [~mjerr@p578EB313.dip0.t-ipconnect.de] has joined #lightning-dev
08:24 -!- nullbyte [NSA@gateway/vpn/mullvad/x-aprqdfjpgdvjhibh] has quit [Ping timeout: 246 seconds]
08:26 -!- nullbyte [~NSA@193.138.219.233] has joined #lightning-dev
10:12 -!- richardkiss [~richardki@70-36-142-78.dsl.dynamic.fusionbroadband.com] has joined #lightning-dev
10:37 -!- bedeho [~bedeho@50-202-37-133-static.hfc.comcastbusiness.net] has joined #lightning-dev
10:48 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
11:23 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has joined #lightning-dev
12:37 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has joined #lightning-dev
12:55 -!- Guest93019 is now known as maaku
12:55 < CJP> Prototype 3 of Amiko Pay is nearing functionality break-even with the second prototype. Let's hope the re-write was worth it.
13:15 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has quit [Ping timeout: 250 seconds]
13:22 < mjerr> CJP, got any additional information/repo?
13:23 < CJP> https://github.com/cornwarecjp/amiko-pay
13:23 < CJP> The main advantage of the 3rd prototype is that the entire node state can (and is being) serialized and stored to disk.
13:25 < CJP> In the previous version, that was difficult, since there were all sorts of cross-references between objects. Now, it's more a tree-like structure.
13:28 < mjerr> CJP, how are microtransactions done currently? have you embedded htlc's?
13:29 < mjerr> looks very cool
13:30 < CJP> No, not yet. The new prototype still only has a "dummy" channel which only keeps balances and doesn't perform any Bitcoin transactions. The previous prototype has a simple type of microtransaction channel with many missing features (such as HTLCs).
13:31 < CJP> But in terms of channel features it should be really flexible: you should be able to define your own channel class, and plug it into Amiko Pay.
13:32 < mjerr> yea, I realized that these are really interchangable in implementation.. just a lot of data to store, depending on the design of the channel
13:32 < mjerr> how does the p2p work currently?
13:33 < CJP> p2p? What do you want to know?
13:33 < CJP> routing?
13:33 < mjerr> yea and peer discovery and all that framework stuff ^^
13:35 < CJP> Amiko Pay doesn't have anything like peer discovery. You manually find peers to make links with, and you give commands in Amiko Pay to connect to them and to create channels with them.
13:37 < mjerr> ah I see, convenient. just saw it in the main. do you have anything for extended routing in mind? these links are only single-hop, right?
13:37 < CJP> A link is a single hop, but since Amiko Pay does a primitive kind of routing, transactions can already cross multiple links = multiple hops.
13:50 < mjerr> CJP, what have you added in prototype 3? sounds like a lot of work, but I thought amiko pay was able to do those transactions before?
13:52 < CJP> Yes, in terms of features it hasn't improved anything yet. The most important change is that the entire node state is now easily retrieved, stored and restored. This would have been very difficult in the design of the previous version.
13:52 < CJP> This is really important for a couple of reasons:
13:53 < CJP> Node state stored on disk is much better protected against crashes, power failures etc., and
13:54 < CJP> whenever an error happens halfway during the processing of an event, a node can now easily revert back to the state before the event processing started. That will always keep the state consistent.
13:55 < CJP> Another change is that serialization of objects is now done in a very systematic, less ad-hoc way, with almost no code overhead per serializable class. This is especially important now that nearly every object needs to be serializable.
14:01 < mjerr> cool! I will take a deeper look into it tomorrow
14:02 < CJP> I've also taken the opportunity to change some terminology a bit in the code, and to implement some things correctly (e.g. before the Lightning paper was published, commit was done in the wrong direction in Amiko Pay).
14:08 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Ik ga weg]
14:33 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has joined #lightning-dev
14:50 -!- trippysalmon [rob@2001:984:6466:0:acb0:1d6:1cb1:2149] has quit [Ping timeout: 250 seconds]
15:02 -!- jtimon [~quassel@159.30.134.37.dynamic.jazztel.es] has joined #lightning-dev
15:03 -!- ftlio [~ftlio@ftlio.com] has quit [Remote host closed the connection]
15:06 -!- ftlio [~ftlio@ftlio.com] has joined #lightning-dev
16:00 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection]
16:01 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #lightning-dev
16:02 -!- maaku is now known as Guest82853
17:44 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:54 -!- richardkiss [~richardki@70-36-142-78.dsl.dynamic.fusionbroadband.com] has quit [Quit: richardkiss]
17:55 < aj> rusty: puuuuuuuuush
17:55 < rusty> aj: ha!
17:55 < rusty> I have 6 inputs which don't get sent.  But I can push a scratch if you want some light reading :)
17:56 < rusty> My turn to give a 10 minute talk here at Base64, preparing slides now.
17:56 < aj> rusty: yay!
17:56 < aj> rusty: so no epidural needed then?
18:03 -!- mjerr [~mjerr@p578EB313.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
18:04 -!- mjerr [~mjerr@p5B209723.dip0.t-ipconnect.de] has joined #lightning-dev
18:04 < rusty> aj: done
18:06 < rusty> aj: my state space exploded, since reorgs and malleability means that a naive model never terminates.  That'll be this afternoon's work.  Plus there's three empty patches in the queue after that: rename-CMD_SEND_HTLC_COMPLETE.patch allow-CMD_CLOSE-during-commands.patch dont-change-prio-on-decline.patch
18:25 -!- akrmn [~akrmn@55-215-250-178.ftth.cust.kwaoo.net] has quit [Quit: Leaving.]
18:32 < aj> rusty: you make empty patch files as a todo list?
18:32 < rusty> aj: yep...
18:41 < aj> rusty: does make state-diagrams take ages now too?
18:42 < rusty> aj: just about forever...
18:42 < rusty> aj: well, a few hours.
18:42 < aj> rusty: forever ~= a couple hours?
18:42 < aj> hh
18:42 < aj> heh even
18:45 < aj> rusty: oh, and i guess that's with make -j ?
18:45 < rusty> aj: ah, yeah, it's 2 hours per run, really.
18:46 < kanzure> you're doing some sort of lightning-negotiated reorg synchronization between hubs?
18:46 < kanzure> note that there can be multiple different reorgs occurring on the network at the same time :-)
18:55 < rusty> kanzure: yes, there's an infinite number, of course.  You have to handle that.  You can have mutual close transactions (malleable), your own unilateral close transaction, your spending of those outputs once timed-out, their unilateral close transactions (two possibilities, if done during HTLC negotiation) and all malleations, and of course, any number of previous revoked transactions and your attempt to steal those outputs.  Each of these m
18:59 < aj> rusty: cut off at "outputs.  Each of these m"
19:00 < rusty> ay have HTLC outputs which you need to monitor (for r value exposure).
19:00 < rusty> aj: weird, repasted.
19:00 < kanzure> right; you do want to look for htlc outputs on all blocks even if you are busy migrating to another reorg
19:12 < rusty> kanzure: exactly.  Fun...
19:12 < kanzure> that might actually require bitcoind features to be added- because by default you are supposedly throwing away that othe rdata
19:12 < kanzure> *that other data
19:13 < kanzure> and you want to keep that data as soon as it hits you
19:13 < kanzure> or really, if you are an archivist, you want to keep all transactions from all reorgs and orphan blocks or orphan chains, because they might have data that you can reuse later and sell to other hubs that come knocking, i think
19:14 < kanzure> i wonder if you should still broadcast your channel closing transactions if you detect that your counterparty tried to broadcast early during a reorg, but after the event you see that that chain is not included in the final blockchain. do you still treat that as a channel trust erosion event?
19:18 < aj> kanzure: if they broadcast early, you keep a copy of their transaction, keep the channel open, get them to do an update, post their early broadcast, and steal all the funds since they gave you revoke info
19:21 < kanzure> or start charging 'em really high fees :-)
19:22 < kanzure> for sake of prosperity, i mentioned in -wizards today, and yesterday, the idea of cross-chain hubs and how i don't know if the security properties can be preserved in that case for transactions that are migrating between chains through hubs
19:22 < kanzure> or er, transactions that involve recipients on other chains that the hub has access to and possibly channels open on already
19:23 < aj> kanzure: i think the security there just depends on the underlying chains being secure, and having some sort of value peg?
19:24 < kanzure> right, assume 2-way peg ala sidechains stuff
19:24 < kanzure> i think the hub needs to give the sender the set of transactions, to give to the merchant on the other chain, because otherwise the sender has little evidence that the funds will be correctly received?
19:26 < aj> kanzure: receiving the preimage is the evidence the funds were received
19:26 < aj> kanzure: (if too few funds arrive at the merchant after routing or hopping chains, just reject, don't reveal R)
19:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds]
20:32 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
20:33 < rusty> kanzure: ATM, any on-chain activity leads to unilateral close.
20:38 < kanzure> fine with me
20:41 < rusty> kanzure: yeah, I don't have to think very hard that way :)
20:42 < rusty> kanzure: so, atomic-exchange-to-X in LN is basically a routing problem.  Since protobufs allow field additions, it'd be easy to add a field later to distinguish LN addresses from some other domain.
20:43 < kanzure> yes i think that as long as it is the hub itself that is sitting on the two chains, then you don't lose any of the trustless properties
20:43 < rusty> kanzure: Aside: Joseph has been avoiding the term hub in favour of simply "nodes".  I've been following suit, since I think it directs thinking in the right non-centralized direction.
20:44 < kanzure> and you can also do n-chain octopus channeling where if you want a large amount of BTC on one chain then maybe it involves pushing BTC to some other intermediate chains (of course, you don't care- it's just how the routing happens or something)
20:44 < kanzure> but hub is more fun to pronounce
20:44 < kanzure> bah fine i'll use node then
20:44 < rusty> kanzure: One side-effect is an effect on timeouts.  At the moment I'm going with 20 seconds expected; we'd need to vary that parameter for others.
20:45 < rusty> kanzure: Me too.  I have a bub, he likes to say hub.  But I'll just have to teach him....
20:45 < aj> rusty: i feel like "just spending/receiving money with as little thought/effort as possible" and "being an active participant" needs different words... leaf node and node don't really work for me
20:45 < kanzure> "wallet"
20:45 < aj> wallets and nodes? hmm
20:45 < rusty> kanzure: Exactly.  Words have power...
20:46 < kanzure> anyway i think it might require a chain parameter in some of the messages, for routing reasons
20:47 < kanzure> (or it could be determined by address type, but then requires lookup tables for address types)
20:48 < kanzure> also please ping me whenever a bip70-style lightning payment protocol comes up...
20:49 < rusty> kanzure: sure... currently the plan of record is onion routing, so you get to decode the next hop.  A chain parameter there makes perfect sense.
20:49 < kanzure> it should be emphasized that nodes should do chain routing even if the chain doesn't match the chain that the node is using
20:50 < kanzure> maybe call it "targetchain" or something
20:50 < rusty> kanzure: onion routing, they won't even know.
20:51 < rusty> kanzure: the key is the next hop; that may be a lightning over a different chain, or even not be LN at the last hop at all (straight to blockchain?)
21:36 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 250 seconds]
21:37 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev
21:53 < aj> rusty: "quick = true;" -- must be a compiler bug, that line doesn't seem to work for me :-P
21:53 < rusty> aj: heh... without quick it takes longer than 2 hours.  But diving into that found a bug in the state machine, so all good.
21:54 < rusty> (was not unwatching an HTLC)
22:07 < aj> rusty: do you have a cooperative close path yet?
22:07 < rusty> aj: yep.
22:08 < aj> rusty: aha, start_closing