--- Log opened Sat Apr 06 00:00:14 2013
00:37 < nanotube> http://blockchain.info/address/871a40e5e61b96b6171f1b435788082edadda7a8 <- fun blockchain spam.
00:39 < gmaxwell> oh god.
00:39 < gmaxwell> 11MakeSureToVisitEtchABLockZAVq9D 0.00000001 BTC
00:39 < gmaxwell> 11DotComXXXXXXXXXXXXXXXXXXXadFTXV 0.00000001 BTC
00:40 < gmaxwell> right ... see how much we really need to lower fees? :-/
00:41 < nanotube> etchablock.com seems to be defunct though
00:41 < nanotube> latest transaction in 2011
00:42 < nanotube> they wouldn't spend those .0005s at today's prices. :)
00:43 < gmaxwell> ah, I'd missed the dates.
15:58 < HM> you know
15:58 < HM> if the RPC mechanism ever needed improving, the way Wayland does it is pretty slick
15:59 < HM> generates thin inline headers for each function call for both clients and servers, corresponding server and client libraries are ~40KB a piece
15:59 < HM> no extra dependencies
15:59 < HM> introspectable
16:02 < HM> oh actually has a dependency on libffi for dispatch (meh, tiny 30KB lib)
16:08 < gmaxwell> wayland needs to handle data at rates thousands of times greater than bitcoin... pretty different motivations and security considerations.
16:16 < HM> it doesn't really
16:17 < HM> the odd key press event, most of the time it just sits there idle
16:18 < HM> once you start adding payment notification events to bitcoin you're going to need a better IPC interface imo
16:18 < HM> s/when/if/
16:18 < gmaxwell> uh. we do have payment notifications.
16:20 < HM> where is that?
16:20 < gmaxwell> e.g. walletnotify.
16:21 < gmaxwell> (which I think is horrible and should die, but thats another matter)
16:21 < gmaxwell> I think the 0mq patch seemed reasonable.
16:21 < HM> 0mq is tricky for RPC
16:22 < HM> you will need separate sockets for notifications and REQ/REP
16:23 < HM> I haven't seen the patch however, where does it live?
16:24 < HM> ah found it
16:25 < HM> ah it's a python front end to the json rpc interface
16:25 < HM> or is that a test
16:25 < HM> hmm
16:26 < HM> it's SUB only anyway
16:26 < gmaxwell> HM: no, jesus, go look at pull requests and actually read it. It doesn't do much right now, but it seems like a reasonable way to do notifications.
16:28 < HM> I'm looking at pull 2415
16:29 < gmaxwell> Which is not at all a python front end to the json rpc interface.
16:30 < gmaxwell> It links bitcoin against the 0mq libraries and allows it to publish notifications for transactions and blocks.
16:31 < HM> yep, wrapping the existing json rpc code
16:31 < HM> it's not a bad idea
16:32 < gmaxwell> ... it rally has absolutely nothing to do with the json rpc code.
16:33 < HM> it does lol
16:33 < gmaxwell> Why are you saying that?
16:34 < HM> because it reads json right off the 0mq socket
16:34 < HM> passes calls to the existing json code
16:34 < HM> gets replies, and reps it back
16:34 < gmaxwell> Are you being a fool just to irritate me?
16:35 < HM> https://github.com/bitcoin/bitcoin/pull/2415/files
16:35 < HM> https://github.com/bitcoin/bitcoin/pull/2415/files#L5L944
16:35 < HM> notice it makes existing JSON RPC functions non-static
16:35 < HM> https://github.com/bitcoin/bitcoin/pull/2415/files#L3R322 <-- reads and writes json off the 0mq socket here
16:35 < HM> it's just an observation, i'm not being critical
16:36 < HM> it's the smart thing to do when you have an existing rpc implementation
16:37 < gmaxwell> okay, I see the source of the confusion here.
16:37 < gmaxwell> Since I commented on it the guy added a bunch of extra commits that do wrap the json rpc stuff.
16:37 < gmaxwell> You have my apology.
16:38 < gmaxwell> The original code did not do that.
16:38 < HM> tis ok, review a lot of stuff
16:38 < HM> you review*
16:38 < gmaxwell> I don't know that I like that.
16:38 < gmaxwell> will have to contemplate.
16:47 < HM> meh, I'm sure RPC isn't a priority
16:49 < HM> sipa mentioned splitting it up in to components, e.g. wallet stuff and transaction stuff
--- Log closed Sun Apr 07 00:00:15 2013