--- Day changed Sat Aug 01 2015 00:06 -!- go1111111 [~go1111111@104.200.154.40] has quit [Ping timeout: 255 seconds] 00:24 -!- go1111111 [~go1111111@162.244.138.37] has joined #lightning-dev 00:26 -!- jtimon [~quassel@200.Red-79-148-174.dynamicIP.rima-tde.net] has joined #lightning-dev 01:34 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has joined #lightning-dev 01:52 -!- mjerr [~mjerr@p578EAF05.dip0.t-ipconnect.de] has quit [Ping timeout: 255 seconds] 03:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 04:11 < CodeShark> rusty, should we set up a separate forum for discussing potential lightning apps? 04:11 < CodeShark> that way this chat and the mailing list can focus on the most fundamental aspects of lightning 04:11 < rusty> CodeShark: Heh, "lightning-speculate"? 04:12 < rusty> CodeShark: I'm not sure... I figure we'll eventually have a user list etc. I guess it depends how much there is to discuss? 04:12 < CJP> Apps as in "pieces of software" or as in "use cases"? 04:14 < CodeShark> well, right now probably mostly use cases...but later on as we have testnets, sidechains, and what not perhaps also demo apps 04:14 < CodeShark> it would make it much easier to make the case for the project if we could demo its potential 04:15 < CJP> Exactly. That's what I try to accomplish with Amiko Pay. 04:19 < rusty> CodeShark, CJP: good points. My vague current plan: add HTLC support, implement stupid primitive routing, create & document giant protocol state machine, produce prototype. 04:20 < rusty> Then people can run and crash prototype nodes, and we can iterate from there in whatever direction people want. 04:21 < CJP> My vague current plan: implement stupid primitive routing, implement stupid primitive transaction channel, produce reasonably reliable prototype, add HTLC support. 04:21 < CJP> Oh, and then improve routing. 04:22 < CodeShark> nice - I'll keep an eye on it :) 04:22 < Guest4710> CJP: How does Amiko relate to LN? 04:22 < rusty> Guest4710: Cooler name. 04:22 < CJP> Lightning network is a pretty cool name. 04:23 < rusty> CJP: So, you're mainly a python coder? 04:23 < CJP> Amiko Pay is older than LN, and had a slightly different design, but its design evolved towards LN's design. 04:23 < Guest4710> Lightning network sounds like a technology while Amiko Pay sounds like a company name, so I prefer lightning. No offence CJP :) 04:24 < Guest4710> What made Amiko different from LN before? 04:24 < rusty> CJP: how interoperable are we going to be? I'd love to get another code whacking on the protobuf protocol.... 04:24 < CJP> Current idea of Amiko Pay is to first build something like LN that works without changes to Bitcoin, and then change it into a full LN client once the technology becomes available. 04:25 < rusty> CJP: ah, yeah, I'm counting on CLTV, CSV and malleability fixes. Makes life a bit easier, but if I'm wrong about the timing it'll be painful... 04:26 < CJP> I code in all sorts of languages. Originally I started Amiko Pay in C++, but it wasn't flexible enough to allow for fast experimentation. And I really like Python. 04:27 < aj> rusty: "lightning-ideas" or "lightning-spitball"? hmm, you should join a union just so you could go on a "lightning strike" one day 04:27 < rusty> CJP: yeah, I'm deeply suspicious of any network facing code in C. OK for a prototype... 04:28 < sipa> i'm deeply suspicious of code not having well-predictable memory usage for network facing systems :) 04:29 < CJP> I really want LN and Amiko Pay to become interoperable. The most important things to agree on are network-wide standards; standards that are local to a certain link (or to payer/payee communication) are important too, but they can be changed more easily. 04:29 < aj> rusty: what do you prefer for network facing code? python has safer string handling, but there's so many layers and interactions where things could go wrong 04:30 < rusty> aj: I prefer other people to write the code so I don't have to deal with the CVEs :) 04:30 < sipa> haha 04:32 < CJP> The good thing about C (and C++ to some degree) is that you have a reasonably good view of what is going on under the hood. That's why I originally started Amiko Pay in C++. 04:33 < aj> rusty: heh. clearly it just needs to be formally verified via theorem provers and running on a trusted platform 04:34 < CJP> The switch to Python is really just to be able to come up with a prototype "quickly". 04:34 < sipa> aj: sounds trivial! 04:35 < rusty> aj: I'll buy three! 04:35 < CJP> I'm already in the third major re-write of the code, so it's really about figuring out HOW to make the software. As soon as that is done, re-writing in other languages should be much simpler. 04:35 < CJP> I think we'll need a Java implementation anyway, for Android apps. 04:36 < aj> no doubt there'll be a javascript implementation, despite any efforts to avoid it 04:37 < CJP> LOL I won't be the one who makes the javascript version. Or you'll have to pay me A LOT. 04:37 < aj> CJP: well, the existance of a javascript version might make it easy to obtain lots of bitcoins, so maybe... ;) 04:42 < CJP> I like the idea of a "formally verified" version (long term project of course), but it shifts the problem to having no bugs in the specs that must be proven, and in having no bugs in the theorem prover. 04:46 < rusty> CJP I think if we get to the point where we have a state machine for the protocol, we can get serious about verification. Maybe not *that* serious.... 04:48 < aj> might be more realistic if /bitcoin/ had state machine docs that allowed other implementations... 04:50 < CJP> Description as a state machine is only easy for the lowest layers of the protocol. A node as a whole has an infinite(*) number of states; how do you deal with that? 04:50 < CJP> (*)Strictly speaking limited by memory size, and of course by artificial limits imposed by the software, but it's still huge. 04:51 < rusty> CJP: by limiting the problem to communication between two nodes, I think it's managable. 04:52 < rusty> CJP: ie. routing etc is not in the state machine :) 04:53 < aj> rusty: i think routing has to be in the state machine, but that can still be limited to <= 3 nodes at any one time? 04:53 < aj> rusty: ie fwd a payment from to C, only if i've already got the payment from A 04:53 < rusty> aj: the state machine already gets pretty complicated. There's re-transmissions, on-blockchain events, timeouts.... 04:54 < rusty> I won't know until I've written it (or died trying...) 04:55 < CJP> And you may want to deal with multiple unfinished transactions simultaneously, even on a single channel. 04:55 < aj> i bet using threads would help 04:55 < CJP> So you have a state "no locked transactions", a state "tx1 locked", a state "tx1 locked, tx2 locked", a state "tx1 locked, tx2 locked, tx3 locked" and so on. 04:56 < rusty> aj: I welcome your attempt to educate me on the powers of chanop, but I shall resist kicking you anyway. 04:56 < CJP> No, I tried using threads first. It makes things more complicated. 04:56 < aj> CJP: omg, i'm so sorry :( 04:57 < CJP> It wasn't your fault that I used theads first :) 04:57 < aj> CJP: threading is a stain on the soul of all humanity, we all share the guilt ;) 04:58 < rusty> CJP: indeed, there's a state machine per HTLC. That gets a little furry.... 04:58 < CJP> Threading is really useful, it just doesn't work well for handling things inside an Amiko / Lightning node. 04:59 < CJP> I actually still use multi-threading to separate node operation from user interface operation, but inside a node it's all single-threaded. 05:01 < aj> hmm, i guess these days i think in terms of multiprocess services with no meaningful shared data between instances except what's in a real database (sqlite, psql, nosqlwhatever) 05:04 < CJP> In an Amiko/Lightning node, basically all data is potentially affected by all transactions, so (nearly) all data is "shared". And you need to keep the overall state consistent. 05:06 < CJP> The easiest way to accomplish that is to NOT process multiple messages simultaneously, but process them one by one, and make sure each message leaves the node in a consistent state. 05:06 < aj> yeah; for most things i care about, that's what the database layer is for, and it already has fancy locking and (when not done with sqlite) multithreading handled by someone other than me 05:07 < CJP> I've been thinking about implementing Amiko Pay on top of an SQL database, but I think the SQL statements would be HUGE, and probably hard to debug. 05:09 < aj> could be; and you still have to think about simultaneous sql statements (assuming you're not using sqlite ;) 05:09 -!- sipa [~pw@unaffiliated/sipa1024] has left #lightning-dev [] 05:10 < aj> CJP: btw, are you working with OP_CSV and OP_CLTV, or doing the chains of txns and extra keys to avoid that dep? 05:11 < CJP> Yes, you need database transactions to be "atomic" (with locks or other measures), so they don't become truly simultenaous. 05:12 < CJP> Currently, Amiko Pay has no HTLC or other special scripting yet. 05:13 < CJP> Amiko Pay has a sort of a plug-in architecture for multiple channel types, so special types of channels can be added easily in the future. 05:15 < CJP> The simplest "channel type" is actually not a transaction channel at all: it's Ripple-style IOU book-keeping between nodes that trust each other. On closing the "channel", the net amount is transferred. 05:17 < CJP> The next level of complexity is a conventional micro-transaction channel without special HTLC scripts. So, funds are protected as long as they are not involved in a micro-transaction. 05:18 < CJP> After that, the next target for me is "HTLC emulation using escrow services", as I described in a paper. That does not require any new op-codes. 05:20 < CJP> That would make Amiko Pay already good enough for real-world usage. After that, switching to real Lightning HTLCs, using new op-codes and other new Bitcoin features is on the roadmap. 05:21 < rusty> CJP: interesting! Yep, I hope you get some real-world data from that. 05:21 < rusty> CJP: I think the IOU basis could be very interesting, if only because it may allow large hubs to do offline keys for transfers between each other. 05:24 < rusty> OK, well enough of this wild Saturday night on IRC, I'd best be going :) Thanks for the discussion everyone! 05:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev [] 05:28 -!- CodeShark_ [~androirc@cpe-76-167-237-202.san.res.rr.com] has joined #lightning-dev 06:39 -!- CJP [~CJP@a83-163-77-195.adsl.xs4all.nl] has quit [Quit: Ik ga weg] 06:48 -!- mjerr [~mjerr@p578EAF05.dip0.t-ipconnect.de] has joined #lightning-dev 07:25 -!- cixx [~rob@temphost.xs4all.nl] has joined #lightning-dev 08:26 -!- Guest98795 is now known as maaku 10:31 -!- jtimon [~quassel@200.Red-79-148-174.dynamicIP.rima-tde.net] has quit [Ping timeout: 265 seconds] 11:21 -!- mjerr [~mjerr@p578EAF05.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 11:35 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Ping timeout: 255 seconds] 11:47 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #lightning-dev 11:47 -!- maaku is now known as Guest70241 12:31 -!- Guest70241 [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Quit: No Ping reply in 180 seconds.] 12:31 -!- maaku_ [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #lightning-dev 15:04 -!- so [~so@unaffiliated/so] has joined #lightning-dev 18:28 -!- btcdrak [uid52049@gateway/web/irccloud.com/x-vnwilanjhnujjgcc] has quit [Quit: Connection closed for inactivity] 21:09 -!- maaku_ [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has quit [Remote host closed the connection] 21:14 -!- maaku [~quassel@50-0-37-37.dsl.static.fusionbroadband.com] has joined #lightning-dev 21:14 -!- maaku is now known as Guest9865