1 2016-05-27 02:46:44	0|GitHub117|[13bitcoin] 15yurizhykin opened pull request #8107: bench: Added base58 encoding/decoding benchmarks (06master...06benchmarks) 02https://github.com/bitcoin/bitcoin/pull/8107
  2 2016-05-27 05:50:31	0|GitHub166|[13bitcoin] 15paveljanik opened pull request #8108: Trivial: Remove unused local variable shadowing upper local (06master...0620160527_trivial_sighash_tests) 02https://github.com/bitcoin/bitcoin/pull/8108
  3 2016-05-27 06:04:06	0|GitHub57|[13bitcoin] 15paveljanik opened pull request #8109: Do not shadow member variables (06master...0620160527_shadow_httpserver) 02https://github.com/bitcoin/bitcoin/pull/8109
  4 2016-05-27 06:22:31	0|GitHub90|13bitcoin/06master 14fa57b0c 15MarcoFalke: [qa] test_framework: Append portseed to tmpdir...
  5 2016-05-27 06:22:31	0|GitHub90|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/425278d17bd0...06bd4f637f15
  6 2016-05-27 06:22:32	0|GitHub90|13bitcoin/06master 1406bd4f6 15MarcoFalke: Merge #8098: [qa] test_framework: Append portseed to tmpdir...
  7 2016-05-27 06:22:41	0|GitHub20|[13bitcoin] 15MarcoFalke closed pull request #8098: [qa] test_framework: Append portseed to tmpdir (06master...06Mf1605-qatmpdir) 02https://github.com/bitcoin/bitcoin/pull/8098
  8 2016-05-27 06:49:20	0|GitHub193|13bitcoin/06master 1413c4558 15Pavel Janík: Remove unused local variable shadowing upper local
  9 2016-05-27 06:49:20	0|GitHub193|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/06bd4f637f15...a80de1511316
 10 2016-05-27 06:49:21	0|GitHub193|13bitcoin/06master 14a80de15 15MarcoFalke: Merge #8108: Trivial: Remove unused local variable shadowing upper local...
 11 2016-05-27 06:49:32	0|GitHub95|[13bitcoin] 15MarcoFalke closed pull request #8108: Trivial: Remove unused local variable shadowing upper local (06master...0620160527_trivial_sighash_tests) 02https://github.com/bitcoin/bitcoin/pull/8108
 12 2016-05-27 08:03:47	0|GitHub4|[13bitcoin] 15fanquake opened pull request #8110: [Doc] Add benchmarking notes (06master...06mention_bench) 02https://github.com/bitcoin/bitcoin/pull/8110
 13 2016-05-27 09:26:55	0|paveljanik|kanzure, how many parallel discussion are you able to type? Thanks for the Zurich log! I'll read it all weekend ;-)
 14 2016-05-27 09:45:12	0|sipa|paveljanik: on tuesday we were separated into groups, and kanzure was only in one at a time
 15 2016-05-27 09:45:24	0|sipa|eh, on saturday
 16 2016-05-27 09:45:39	0|sipa|otherwise, i think he transcribed most
 17 2016-05-27 09:46:28	0|paveljanik|anyway, unbelievable :-)
 18 2016-05-27 09:46:44	0|sipa|and he types faster than most people can speak
 19 2016-05-27 09:47:01	0|sipa|happy that the transcript is useful
 20 2016-05-27 09:47:15	0|sipa|i've wanted to go through it and annotate with context and clarifications
 21 2016-05-27 09:47:20	0|sipa|but it's so huge...
 22 2016-05-27 09:47:48	0|paveljanik|13 printed pages of 4 A4 on 1 A4...
 23 2016-05-27 09:50:41	0|sipa|feel free to ask questions though
 24 2016-05-27 09:50:46	0|sipa|it's sometimes hard to follow
 25 2016-05-27 09:51:00	0|sipa|spoken word is not always very consistent :)
 26 2016-05-27 09:51:40	0|paveljanik|thanks. I'll read it in the silent evening, in the wild, without connectivity 8)
 27 2016-05-27 13:32:03	0|cfields_|jonasschnelli: ping
 28 2016-05-27 13:32:10	0|jonasschnelli|cfields_: pong
 29 2016-05-27 13:32:19	0|cfields_|jonasschnelli: ooh, that was quick :)
 30 2016-05-27 13:32:24	0|jonasschnelli|latency?
 31 2016-05-27 13:32:25	0|jonasschnelli|:-)
 32 2016-05-27 13:33:00	0|cfields_|jonasschnelli: i'd be grateful if i could get a quick opinion on the qt part of the net refactor, when you have a few min to spare
 33 2016-05-27 13:33:20	0|jonasschnelli|cfields_: sure... is there a PR or a branch I can look at?
 34 2016-05-27 13:33:32	0|cfields_|jonasschnelli: for now, qt is using one global everywhere. That works for now, but it's not ideal. I'm not sure where to start with passing it around properly
 35 2016-05-27 13:33:48	0|sipa|cfields_: clientmodel ?
 36 2016-05-27 13:34:02	0|sipa|and perhaps walletmodel
 37 2016-05-27 13:34:04	0|cfields_|sipa: that seemed too easy, i was hoping that'd be the answer :)
 38 2016-05-27 13:34:27	0|cfields_|jonasschnelli: https://github.com/theuni/bitcoin/commits/net-refactor13
 39 2016-05-27 13:34:49	0|cfields_|jonasschnelli: https://github.com/theuni/bitcoin/commit/52b8c0758f0be0f0163b7f8c773f3fa5990e0ac5 as an example of how it was done for the wallet code
 40 2016-05-27 13:35:35	0|cfields_|(that's no ideal, i discussed some potential future work with wumpus. I think you've previously discussed more of a pull model for broadcasting txs, this would fit in nicely with that)
 41 2016-05-27 13:36:02	0|jonasschnelli|cfields_: So, CConnman is the p2p abstraction from the wallet perspective?
 42 2016-05-27 13:36:17	0|jonasschnelli|Ideally I'd like to see a node abstraction from the wallet perspective.
 43 2016-05-27 13:36:21	0|cfields_|jonasschnelli: yes
 44 2016-05-27 13:36:33	0|jonasschnelli|like node->estimatefee, node->broadcastsomething, etc.
 45 2016-05-27 13:36:43	0|jonasschnelli|but your step seems right.
 46 2016-05-27 13:37:14	0|cfields_|jonasschnelli: well, this takes care of the 2nd, but not the first. For ex, you may be running without networking, but still want to commit a tx for later broadcasting
 47 2016-05-27 13:37:27	0|cfields_|jonasschnelli: sec for an example there
 48 2016-05-27 13:38:26	0|cfields_|sipa: btw, I know I owe you some reviews/acks/PRs. Not forgotten.
 49 2016-05-27 13:38:49	0|jonasschnelli|cfields_: the GUI also uses wallet->CommitTransaction directly
 50 2016-05-27 13:38:57	0|jonasschnelli|walletmodel.cpp
 51 2016-05-27 13:39:03	0|cfields_|jonasschnelli: https://github.com/theuni/bitcoin/commit/1a39dd2c4c054bab1aa5fcfce4b2d0ef13d5a69f#diff-b2fd932827da713e319b8f797b7b3795
 52 2016-05-27 13:39:08	0|sipa|it should not!
 53 2016-05-27 13:39:12	0|cfields_|there's a good simple example
 54 2016-05-27 13:40:15	0|cfields_|jonasschnelli: for now, I'm just using a global there because I'm not sure how to pass the instance properly. Should it be as sipa suggested, in clientmodel?
 55 2016-05-27 13:40:15	0|jonasschnelli|cfields_: looks good!
 56 2016-05-27 13:40:52	0|sipa|cfields_: none of the gui code should know anything core related, ideally
 57 2016-05-27 13:40:58	0|sipa|so certainly not about connman
 58 2016-05-27 13:41:11	0|jonasschnelli|I think walletmodel is fine...
 59 2016-05-27 13:41:26	0|gmaxwell|"developers adding conman to bitcoin core"
 60 2016-05-27 13:41:33	0|sipa|i think the connman connnnman
 61 2016-05-27 13:42:04	0|gmaxwell|:P
 62 2016-05-27 13:42:27	0|cfields_|sipa: hmm, why not? It's cleanly separated from the rest of bitcoin, and knows nothing of transactions/blocks/etc. Seems abstract enough for the gui to deal with directly?
 63 2016-05-27 13:42:43	0|jonasschnelli|cfields_: so right? the wallet does not keep track of the conman?
 64 2016-05-27 13:42:57	0|cfields_|sipa: or do you have in mind an abstraction layer on top of that?
 65 2016-05-27 13:43:26	0|jonasschnelli|the wallet object itself is not capable of broadcasting a transaction?
 66 2016-05-27 13:44:26	0|cfields_|jonasschnelli: for now, the wallet is passed an instance of connman. Ideally in the next refactor round, we'd switch to a pull model, where the application layer requests tx's to be broadcast, and sends them to its connman instance
 67 2016-05-27 13:44:30	0|jonasschnelli|What about having some glue-code that abstracts the "node". Chain could be <core>-<connman>-<node-api>-<GUI/clientmodel>-<GUI/gui>?
 68 2016-05-27 13:45:09	0|cfields_|cfields_: maybe the pull model ^^ is what you had in mind?
 69 2016-05-27 13:46:06	0|jonasschnelli|cfields_: g_connman is a global singleton?
 70 2016-05-27 13:46:47	0|cfields_|jonasschnelli: by node, you mean a remote peer like CNode? I'm not sure what you mean by that chain, really
 71 2016-05-27 13:47:02	0|gmaxwell|ConnmanWrapperFactorySingleton.
 72 2016-05-27 13:47:24	0|cfields_|jonasschnelli: It's a global now simply for convenience. The global needs to go away though, that's the part I'm working on
 73 2016-05-27 13:47:52	0|jonasschnelli|cfields_: Sorry. Confusing. With "node glue code" I was not thinking of a CNode object,... with "node glue code" I was more thinking of a full-node abstraction that could expose "boardcast", "estimatefee", "syncblocks", etc.
 74 2016-05-27 13:48:23	0|jonasschnelli|cfields_: maybe for now you access g_connman from clientmodel.cpp and broadcast from there?
 75 2016-05-27 13:48:33	0|cfields_|jonasschnelli: the global is used only in the qt code and rpc, simply because I haven't done the work yet to pass the instance properly. It's a temporary hack.
 76 2016-05-27 13:48:39	0|jonasschnelli|Or an alternative solution would be to use g_connman from walletmodel.cpp
 77 2016-05-27 13:49:18	0|jonasschnelli|Ideally the wallet should only share base classes and only talk to the core code over a single api (node-glue-code).
 78 2016-05-27 13:49:28	0|cfields_|ok, thanks. I'll have a look at that.
 79 2016-05-27 13:49:38	0|jonasschnelli|the api/glue-code could then once be replaced with RPC/ZMQ or similar.
 80 2016-05-27 13:49:39	0|cfields_|jonasschnelli: yes, I see what you're getting at
 81 2016-05-27 13:50:07	0|jonasschnelli|[15:47:01]  <gmaxwell>	ConnmanWrapperFactorySingleton.
 82 2016-05-27 13:50:07	0|sipa|cfields_: why does the gui itself need to know anything about connman?
 83 2016-05-27 13:50:08	0|jonasschnelli|lol
 84 2016-05-27 13:50:22	0|sipa|cfields_: all interactions with it should already be going through clientmodel
 85 2016-05-27 13:50:31	0|jonasschnelli|sipa: because there is no glue-code. :)
 86 2016-05-27 13:50:51	0|cfields_|sipa: i'm pretty sure the problem is simply that I have no idea how the gui code is structured
 87 2016-05-27 13:51:11	0|jonasschnelli|cfields_: the idea is that clientmodel "talks" to the core objects.
 88 2016-05-27 13:51:43	0|jonasschnelli|But IIRC there are many places where the GUI talks directly with a core object/instance.
 89 2016-05-27 13:51:44	0|cfields_|i see. So rather than using g_connman to ban a peer, it should be requesting that the clientmodel bans on its behalf?
 90 2016-05-27 13:51:52	0|jonasschnelli|cfields_: Yes!
 91 2016-05-27 13:52:31	0|cfields_|jonasschnelli: light bulb! That makes perfect sense. I should just be extending that, then.
 92 2016-05-27 13:52:33	0|sipa|cfields_: yes!
 93 2016-05-27 13:53:15	0|jonasschnelli|If all core interaction goes over clientmodel.cpp, we have great readability and good base for detaching possibilities.
 94 2016-05-27 13:54:03	0|cfields_|sipa: when you said "clientmodel", i agreed because my plan was just to stuff a connman instance in there and call it as needed. I see now what you really meant.
 95 2016-05-27 13:54:24	0|cfields_|jonasschnelli: roger.
 96 2016-05-27 13:54:26	0|cfields_|sipa / jonasschnelli: thanks a bunch, that was very helpful.
 97 2016-05-27 13:54:40	0|jonasschnelli|np, thanks for asking
 98 2016-05-27 13:55:42	0|cfields_|jonasschnelli: could I convince you to allow the g_connman hack for now, with a plan to fix it up in a follow-up PR? I'm afraid it'll never get merged if I try to get it all in the first go.
 99 2016-05-27 13:55:55	0|cfields_|(rpc needs to be dealt with similarly, and that will be less fun)
100 2016-05-27 13:57:13	0|sipa|i think keeping a global initially is fine
101 2016-05-27 13:58:35	0|jonasschnelli|Yes. IMO there are no multiple connman's possible for now? If so, then I don't see a reason to make it _not_ global.
102 2016-05-27 13:59:10	0|cfields_|jonasschnelli: yes, it was written with the intention of using multiple connmans in the future
103 2016-05-27 13:59:21	0|cfields_|though obviously we only have 1 now
104 2016-05-27 13:59:29	0|cfields_|s/using/being able to use/
105 2016-05-27 13:59:33	0|jonasschnelli|cfields_: maybe later with have a global conmanMan. :)
106 2016-05-27 13:59:46	0|cfields_|haha
107 2016-05-27 14:00:32	0|sipa|abstractconmanfactory
108 2016-05-27 14:02:36	0|gmaxwell|BBC, is that you?
109 2016-05-27 14:16:06	0|sipa|?
110 2016-05-27 14:16:38	0|instagibbs|sipa doesn't catch anything but pure tech puns, sorry
111 2016-05-27 14:17:43	0|luke-jr|ugh @ calling part of Core by a well-known OS component?
112 2016-05-27 14:34:48	0|GitHub122|[13bitcoin] 15CodeShark closed pull request #8101: Disable mining on nonrelease branches. (06master...06disable_mining_on_nonrelease_branches) 02https://github.com/bitcoin/bitcoin/pull/8101
113 2016-05-27 14:38:09	0|sipa|luke-jr: ?
114 2016-05-27 14:38:23	0|luke-jr|sipa: connman
115 2016-05-27 14:38:41	0|luke-jr|https://01.org/connman
116 2016-05-27 14:46:28	0|cfields_|luke-jr: it's CConnman :)
117 2016-05-27 14:47:14	0|luke-jr|>_<
118 2016-05-27 14:48:11	0|luke-jr|more importantly: I can still build without glib, right? <.<
119 2016-05-27 14:48:40	0|cfields_|heh, yes
120 2016-05-27 15:01:36	0|ebfull|sipa: at the moment we're stuck with old libsecp256k1 code (from before 0.12 where it was updated from upstream and enabled for verification)
121 2016-05-27 15:01:42	0|ebfull|did that code support verification of compact signatures?
122 2016-05-27 15:01:56	0|jonasschnelli|ebfull: yes. it does
123 2016-05-27 15:02:39	0|jonasschnelli|ebfull: use secp256k1_ecdsa_verify
124 2016-05-27 15:02:53	0|jonasschnelli|ebfull: the signatures are in a struct called secp256k1_ecdsa_signature
125 2016-05-27 15:03:09	0|jonasschnelli|you can "fill it up" with a compact signature over secp256k1_ecdsa_signature_parse_compact
126 2016-05-27 15:03:13	0|ebfull|this was before `secp256k1_ecdsa_signature` was introduced
127 2016-05-27 15:03:18	0|ebfull|as far as i can tell
128 2016-05-27 15:03:18	0|jonasschnelli|or with a def: secp256k1_ecdsa_signature_parse_der
129 2016-05-27 15:03:28	0|ebfull|at least in the exposed api
130 2016-05-27 15:03:31	0|jonasschnelli|s/def/DER
131 2016-05-27 15:04:11	0|jonasschnelli|Not sure what version you use... but it is like this since ~6month.
132 2016-05-27 15:04:25	0|ebfull|yeah, from before that :)
133 2016-05-27 15:04:56	0|ebfull|secp256k1_ecdsa_verify doesn't appear to parse the compact signatures unless my code is wrong
134 2016-05-27 15:07:16	0|ebfull|or maybe it requires a version byte at the beginning :)
135 2016-05-27 15:12:52	0|sipa|ebfull: of course it does support it
136 2016-05-27 15:13:02	0|sipa|ebfull: it's used for signature verification
137 2016-05-27 15:23:45	0|ebfull|sipa: maybe i'm using the wrong terminology. in the old code, secp256k1_ecdsa_sign_compact produces a 64-byte (r, s), which secp256k1_ecdsa_sig_parse (as used by secp256k1_ecdsa_verify) does not appear to parse
138 2016-05-27 15:24:09	0|ebfull|i can see how to use the new api to do it, but not the old api
139 2016-05-27 15:26:13	0|sipa|ebfull: 0.12 used libsecp for message signature validation, which used compact format
140 2016-05-27 15:26:22	0|sipa|so just look up how that worked
141 2016-05-27 15:26:34	0|ebfull|we're using the libsecp from before that :(
142 2016-05-27 15:26:36	0|sipa|oh
143 2016-05-27 15:26:41	0|sipa|well, update it
144 2016-05-27 15:26:46	0|sipa|we fixed bugs
145 2016-05-27 15:27:20	0|ebfull|i'll have to explore the feasibility of that
146 2016-05-27 15:29:09	0|ebfull|last time i looked into it i had a rough time following the trail of github UI bugs in the pull requests involved
147 2016-05-27 15:42:54	0|Chris_Stewart_5|sipa: After generating script_tests.json.gen do you need to manually copy it over to data/script_tests.json?
148 2016-05-27 15:52:58	0|sipa|yup
149 2016-05-27 15:53:17	0|sipa|ebfull: meh, just copy it over
150 2016-05-27 15:56:05	0|ebfull|at that point i think it's probably way easier for us to use ed25519 for what we're implementing anyway
151 2016-05-27 18:51:55	0|BlueMatt|lol bitcoin core under valgrind is an absolute shitshow now
152 2016-05-27 18:52:19	0|BlueMatt|I turn around and two minutes later valgrind is all like "More than 1000 different errors detected. Go fix your program!"
153 2016-05-27 18:52:25	0|sipa|ouch :(
154 2016-05-27 18:52:35	0|sipa|i haven't run valgrind in a while
155 2016-05-27 18:52:55	0|Lightsword|memory leaks everywhere?
156 2016-05-27 18:53:19	0|BlueMatt|uninitialized values everywhere
157 2016-05-27 18:53:29	0|BlueMatt|its actually probably just C++11 confusing valgrind
158 2016-05-27 18:53:55	0|MarcoFalke|I tried pre-cpp11 and had a similar number of complaints
159 2016-05-27 18:54:02	0|BlueMatt|ouch
160 2016-05-27 18:54:14	0|BlueMatt|sipa: also lots from secp
161 2016-05-27 19:29:23	0|BlueMatt|lolnvm
162 2016-05-27 19:29:38	0|BlueMatt|just make random not use openssl and literally every single warning goes away
163 2016-05-27 19:30:55	0|cfields_|BlueMatt: there's a build-switch for openssl
164 2016-05-27 19:31:07	0|cfields_|BlueMatt: it seeds with uninit data by default
165 2016-05-27 19:31:18	0|BlueMatt|cfields_: yes, I would have to rebuild openssl for that
166 2016-05-27 19:31:43	0|BlueMatt|cfields_: its impressive how far some of the errors go, though....everything anywhere that is seeded with random values, so you get lots of shit in ccoins/mempool/bloom/etc
167 2016-05-27 19:32:21	0|cfields_|heh
168 2016-05-27 19:32:59	0|cfields_|boost tends to piss off sanitizing tools as well
169 2016-05-27 19:33:18	0|BlueMatt|havent seen anything blow up except on shutdown yet
170 2016-05-27 21:00:35	0|kanzure|"Multi-party channels" https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-May/000543.html