1 2016-03-29 07:33:32	0|GitHub191|13bitcoin/06master 14fa3fafc 15MarcoFalke: [qa] wallet: Wait for reindex to catch up
  2 2016-03-29 07:33:32	0|GitHub191|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/84370d58ffc6...26794d4645e4
  3 2016-03-29 07:33:33	0|GitHub191|13bitcoin/06master 1426794d4 15Wladimir J. van der Laan: Merge #7757: [qa] wallet: Wait for reindex to catch up...
  4 2016-03-29 07:33:39	0|GitHub5|[13bitcoin] 15laanwj closed pull request #7757: [qa] wallet: Wait for reindex to catch up (06master...06Mf1603-qaWalletReindex) 02https://github.com/bitcoin/bitcoin/pull/7757
  5 2016-03-29 08:03:01	0|jonasschnelli|wumpus: awesome idea with the "bc-monitor"!
  6 2016-03-29 08:03:16	0|jonasschnelli|Would it only require to connect over ZMQ or also over RPC?
  7 2016-03-29 08:03:22	0|wumpus|thanks :)
  8 2016-03-29 08:03:29	0|jonasschnelli|The later would probably require two stunnels?
  9 2016-03-29 08:03:40	0|wumpus|it requires both, eventually I want to make zmq optional
 10 2016-03-29 08:04:03	0|jonasschnelli|With RPC long poll? Or how would you update the stat?
 11 2016-03-29 08:04:05	0|wumpus|but I'm most interested in the zmq stats myself so that's the priority for what I'm currently buildlng :)
 12 2016-03-29 08:04:19	0|wumpus|just poll, updates will be slower and some things will be missing (like the actiity log)
 13 2016-03-29 08:04:52	0|jonasschnelli|Hmm... the polling is kinda lame/hacky and also I don't like the JSON/http overhead...
 14 2016-03-29 08:04:53	0|wumpus|so the eventual plan is: zmq is *nice*, rpc is required to get the base info
 15 2016-03-29 08:05:14	0|jonasschnelli|I had similar ideas for a new GUI (monitor).
 16 2016-03-29 08:05:32	0|wumpus|JSON and http overhead doesn't matter for things that never change (say the name and version of the node)
 17 2016-03-29 08:05:45	0|jonasschnelli|right..
 18 2016-03-29 08:05:49	0|wumpus|as well as the max size of the mempool
 19 2016-03-29 08:05:50	0|wumpus|etc
 20 2016-03-29 08:06:28	0|wumpus|also things can be updated asynchronously, you don't have to hang the GUI while an RPC request is underway
 21 2016-03-29 08:06:31	0|jonasschnelli|I think we should definitively add a sequence number for each zmq notification.
 22 2016-03-29 08:07:07	0|jonasschnelli|This is at tiny cost...
 23 2016-03-29 08:07:13	0|wumpus|yes I'm not sure why that wasn't done in the first place
 24 2016-03-29 08:07:24	0|jonasschnelli|Right. It would be an API break now.
 25 2016-03-29 08:07:30	0|jonasschnelli|But we might risk that...
 26 2016-03-29 08:07:33	0|wumpus|would need to be a sequence number per notifier, not a global one, you can't expect people to be listening for everything
 27 2016-03-29 08:07:35	0|jonasschnelli|or optionally allow to enable it.
 28 2016-03-29 08:07:38	0|wumpus|right.
 29 2016-03-29 08:07:50	0|jonasschnelli|Right. It should be per message type.
 30 2016-03-29 08:07:59	0|jonasschnelli|A uint64 per message type.
 31 2016-03-29 08:08:27	0|wumpus|nah a uint64 is not necessary
 32 2016-03-29 08:08:35	0|wumpus|you just need to check that next packet is prevpacket+1
 33 2016-03-29 08:08:39	0|wumpus|even a byte woulddo :)
 34 2016-03-29 08:09:15	0|jonasschnelli|Indeed. A "skip" > 256 would be extremely rare.
 35 2016-03-29 08:09:27	0|wumpus|hm  you're right... well ok, 2 bytes then
 36 2016-03-29 08:09:49	0|wumpus|if you miss 65k packets, well, I'd say you're screwed anyway...
 37 2016-03-29 08:10:04	0|jonasschnelli|Hah. True.
 38 2016-03-29 08:10:08	0|jonasschnelli|Let me know when you have your bc-monitor ready for testing..
 39 2016-03-29 08:10:12	0|wumpus|sure!
 40 2016-03-29 08:17:42	0|wumpus|<jonasschnelli> Hmm... the polling is kinda lame/hacky and also I don't like the JSON/http overhead... <- what about encoding univalues as cbor (http://cbor.io/) instead  *ducks*
 41 2016-03-29 08:19:36	0|wumpus|not actualy convinced how much it would help, but for huge structures like the output of e.g. getrawmempool true it may save a few bytes
 42 2016-03-29 08:19:39	0|jonasschnelli|wumpus: hah! More hacky! But i like it. :)
 43 2016-03-29 08:19:57	0|jonasschnelli|The polling is just not in-sync with thread synchro.
 44 2016-03-29 08:20:11	0|jonasschnelli|The notification approach would scale better IMO
 45 2016-03-29 08:20:19	0|wumpus|I do think json parsing can be made very fast too
 46 2016-03-29 08:20:35	0|wumpus|(e.g. univalue is already plenty faster than the boost thing)
 47 2016-03-29 08:20:54	0|jonasschnelli|I kinda like zmq and I have also though about a channel into the other direction,.. but I'm also aware of the risks.
 48 2016-03-29 08:21:01	0|wumpus|sure, notification is good fo things that change, especially at high frequency
 49 2016-03-29 08:21:06	0|wumpus|it's not a replacement for a command/response system
 50 2016-03-29 08:21:57	0|jonasschnelli|What would speak against accepting requests over zmq (bitcoind listens) and process it async and response with some events (similar to p2p)? Bad design?
 51 2016-03-29 08:22:23	0|jonasschnelli|With requests I mean: "give me some informations about connected peers",... just some basic stuff.
 52 2016-03-29 08:22:29	0|jonasschnelli|Auth would be a problem.
 53 2016-03-29 08:22:35	0|wumpus|why not use rest instead?
 54 2016-03-29 08:22:53	0|wumpus|we already have an unauthenticated information interface
 55 2016-03-29 08:22:58	0|jonasschnelli|I just don't like having multiple port connected for one purpose (a monitor)
 56 2016-03-29 08:23:10	0|wumpus|(and rest doesn't need to be necessarily json)
 57 2016-03-29 08:23:45	0|jonasschnelli|It would be very difficult to connect a "monitor" app to your remove node.
 58 2016-03-29 08:23:52	0|jonasschnelli|*remote
 59 2016-03-29 08:24:03	0|wumpus|I'd like zmq events for some P2P events though
 60 2016-03-29 08:24:12	0|wumpus|like 'new node connected' 'node disconnected' etc
 61 2016-03-29 08:24:43	0|wumpus|jonasschnelli: I'm mostly aiming at local usage right now, that's why I use ncurses in the first place
 62 2016-03-29 08:25:27	0|wumpus|I could split it into two components, one that connects to a local RPC and ZMQ, the other that connects to the tool, and one TCP connection in between. But meh, that's not a priority :)
 63 2016-03-29 08:25:30	0|jonasschnelli|wumpus: Yes. This makes sense. I though about a GUI tool that is also process separated.
 64 2016-03-29 08:25:35	0|jonasschnelli|And this would require RPC and ZMQ.
 65 2016-03-29 08:26:02	0|wumpus|zmq is not very suitable for over-the-internet usage, if you're considering that
 66 2016-03-29 08:26:11	0|jonasschnelli|Maybe someone could write a proxy-python script that sits behind apache/ngix and bundles the channels, do the SSL, etc.
 67 2016-03-29 08:26:39	0|jonasschnelli|(bundles the channels = RPC & ZMQ)
 68 2016-03-29 08:26:39	0|wumpus|something like websocket notification would work better for that. Wouldn't be too difficult to roll a zmq-to-websocket adapter.
 69 2016-03-29 08:26:52	0|jonasschnelli|right.
 70 2016-03-29 08:27:17	0|wumpus|initialliy I'd have preferred using a streaming http socket for notifications, but zmq is more 'standard'
 71 2016-03-29 08:27:45	0|jonasschnelli|Yes.
 72 2016-03-29 08:28:43	0|jonasschnelli|I think if one likes to connect over the inet with a monitor app, a CGI python script would be sufficient. You could use SSL and http digest from apache/httpd
 73 2016-03-29 08:29:14	0|jonasschnelli|But lets first focus on the monitor locally connected!
 74 2016-03-29 08:29:31	0|wumpus|if it's for over the internet a whole new world of authentication, security, etc opens up... scope creep etc :)
 75 2016-03-29 08:30:08	0|wumpus|I do agree it'd be nice though
 76 2016-03-29 08:31:36	0|jonasschnelli|I really dream of re-usign an old computer as "monitor center" for a couple of nodes... mempool, peers, blocks
 77 2016-03-29 08:32:19	0|wumpus|what about snmp support? *sorry, troll mode today*
 78 2016-03-29 08:32:44	0|jonasschnelli|Is that still alive.. :)
 79 2016-03-29 08:33:01	0|jonasschnelli|But yes. Would allow to attach multiple tools.
 80 2016-03-29 08:33:07	0|btcdrak|OMG wumpus.
 81 2016-03-29 08:33:21	0|wumpus|I dont't actually know, I played around with it >10 years ago when I did something with *gasp* servers
 82 2016-03-29 08:33:31	0|jonasschnelli|haha...
 83 2016-03-29 08:34:07	0|btcdrak|mind you, it's probably not a bad idea...
 84 2016-03-29 08:34:15	0|wumpus|the protocol is terrible and the implementations are even worse, brittle and old (think: openssl but worse)
 85 2016-03-29 08:34:21	0|jonasschnelli|I still use it to create some stats from my servers though. I guess "munin" still uses snmp.
 86 2016-03-29 08:34:57	0|wumpus|you could make a snmp-to-RPC adapter though, if you come up with enough OIDs and learn to speak ASN.1
 87 2016-03-29 08:35:24	0|jonasschnelli|lol
 88 2016-03-29 08:36:03	0|wumpus|jonasschnelli: sure, lots of enterprise equipment still uses it, and the big monitor tools support it. It's just not very internet-ready, unless you use it over a secure monitoring VPN or such.
 89 2016-03-29 08:36:44	0|jonasschnelli|Agree.
 90 2016-03-29 08:53:09	0|GitHub110|[13bitcoin] 15laanwj closed pull request #7741: [0.12] Mark p2p alert system as deprecated (060.12...06alert0) 02https://github.com/bitcoin/bitcoin/pull/7741
 91 2016-03-29 08:53:09	0|GitHub151|13bitcoin/060.12 14c0fe2c9 15BtcDrak: Mark p2p alert system as deprecated....
 92 2016-03-29 08:53:09	0|GitHub151|[13bitcoin] 15laanwj pushed 2 new commits to 060.12: 02https://github.com/bitcoin/bitcoin/compare/597494f5a90c...a0cea89456f8
 93 2016-03-29 08:53:10	0|GitHub151|13bitcoin/060.12 14a0cea89 15Wladimir J. van der Laan: Merge #7741: [0.12] Mark p2p alert system as deprecated...
 94 2016-03-29 08:56:07	0|sipa|wumpus: if we need to fix the serialization for gettxoutsetinfo... maybe we can replace it with a merkleized version?
 95 2016-03-29 08:57:20	0|wumpus|sipa: you mean a 6-month masters project for someone? :) or isn't it that bad to do?
 96 2016-03-29 08:57:34	0|sipa|wumpus: i don't mean UTXO commitments
 97 2016-03-29 08:57:39	0|wumpus|ohh!
 98 2016-03-29 08:58:01	0|wumpus|sure, would be good to have a better format
 99 2016-03-29 08:58:31	0|wumpus|I'm everything but married to the current one, and apparently we already broke it once without anyone noticing, so (as long as we mention it in the release notes) I'm not against breaking it again
100 2016-03-29 08:58:51	0|sipa|but we can iterate over the utxo entries in order like now, but use an incremental merkle tree hasher (similar to the algorithm used by ComputeMerkleRoot and friends now)
101 2016-03-29 08:58:58	0|wumpus|cool
102 2016-03-29 08:59:34	0|sipa|the overhead would be the same, and you could make it answer queries for specific entries... and it could later just be converted to a commitment structure
103 2016-03-29 08:59:45	0|wumpus|yes, after  the memory improvement for the merkle tree hasher it doesn't have to store all the data in meory
104 2016-03-29 09:08:44	0|GitHub100|13bitcoin/06master 14f11c5a3 15Wladimir J. van der Laan: devtools: make github-merge.py use py3...
105 2016-03-29 09:08:44	0|GitHub100|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/26794d4645e4...aa0d2b263186
106 2016-03-29 09:08:45	0|GitHub100|13bitcoin/06master 14aa0d2b2 15Wladimir J. van der Laan: Merge #7737: devtools: make github-merge.py use py3...
107 2016-03-29 09:08:49	0|GitHub80|[13bitcoin] 15laanwj closed pull request #7737: devtools: make github-merge.py use py3 (06master...062016_03_python_3_github_merge) 02https://github.com/bitcoin/bitcoin/pull/7737
108 2016-03-29 09:11:29	0|GitHub88|13bitcoin/06master 14cef8bdf 15Jonas Schnelli: [Wallet][RPC] add missing abandon status documentation
109 2016-03-29 09:11:29	0|GitHub88|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/aa0d2b263186...2676e12016db
110 2016-03-29 09:11:30	0|GitHub88|13bitcoin/06master 142676e12 15Wladimir J. van der Laan: Merge #7742: [Wallet][RPC] add missing abandon status documentation...
111 2016-03-29 09:11:34	0|GitHub177|[13bitcoin] 15laanwj closed pull request #7742: [Wallet][RPC] add missing abandon status documentation (06master...062016/03/ab_doc) 02https://github.com/bitcoin/bitcoin/pull/7742
112 2016-03-29 09:15:52	0|GitHub34|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2676e12016db...b35a59179359
113 2016-03-29 09:15:53	0|GitHub34|13bitcoin/06master 147eb7029 15instagibbs: Add importprunedfunds rpc call
114 2016-03-29 09:15:53	0|GitHub34|13bitcoin/06master 14f1bb13c 15instagibbs: Added companion removeprunedfunds call.
115 2016-03-29 09:15:54	0|GitHub34|13bitcoin/06master 14b35a591 15Wladimir J. van der Laan: Merge #7558: [RPC] Add import/removeprunedfunds rpc call...