1 2014-12-27 01:36:00 <gmaxwell> apparently the tor controller port can now create hidden services: https://stem.torproject.org/tutorials/over_the_river.html
2 2014-12-27 01:57:20 <phantomcircuit> gmaxwell, horray
3 2014-12-27 01:58:08 <phantomcircuit> gmaxwell, actually that just looks like it's modifying torrc and then SIGHUP
4 2014-12-27 03:03:18 <wumpus> yes that's possible, see also e.g. https://jordan-wright.github.io/blog/2014/10/06/creating-tor-hidden-services-with-python/
5 2014-12-27 03:07:36 <midnightmagic> ACTION prods gmaxwell
6 2014-12-27 03:07:48 <midnightmagic> who was the bankrupt(ed?) turkey who spammed the blockchain?
7 2014-12-27 03:11:55 <phantomcircuit> midnightmagic, you mean sd?
8 2014-12-27 03:13:15 <gmaxwell> midnightmagic: There have been a number of "add your messages" services what went down because they were losing money, I'd have to go scraping browsing logs to find their names. Not memorable.
9 2014-12-27 03:13:45 <gmaxwell> part of the reason people keep doing the same bad/useless things of and over again is that we forget the ones that fail and they think their attempt is novel.
10 2014-12-27 03:15:06 <gmaxwell> phantomcircuit: bummer sounded like it used the control port.. Not so useful. In standard gnu/linux installs the user running bitcoin can't write to the torrc.
11 2014-12-27 03:17:46 <phantomcircuit> gmaxwell, i cant actually tell what their codes doing, but it looks like it
12 2014-12-27 03:18:20 <phantomcircuit> lots of abstraction...
13 2014-12-27 03:18:47 <phantomcircuit> yeah
14 2014-12-27 03:18:48 <phantomcircuit> However, this directory is only readable by the tor user, so if unavailable
15 2014-12-27 03:18:48 <phantomcircuit> Our *.onion address is fetched by reading the hidden service directory.
16 2014-12-27 03:18:52 <phantomcircuit> oh well :(
17 2014-12-27 03:18:54 <brand0> don't they know that namecoin is for spamming onto?
18 2014-12-27 04:44:22 <wumpus> https://github.com/bitcoin/bitcoin/pull/5532 could use some ACKs
19 2014-12-27 04:45:28 <wumpus> phantomcircuit: oh, that's too bad, I thought too it went through the control port
20 2014-12-27 04:47:55 <wumpus> IIRC their control port interface does allow arbitrary setting changes so why not the hidden service config
21 2014-12-27 04:51:52 <phantomcircuit> wumpus, i suspect you can configure a hidden service through the control port
22 2014-12-27 04:51:58 <phantomcircuit> but you cant then figure out what it is
23 2014-12-27 04:52:09 <phantomcircuit> you cant get the onion address
24 2014-12-27 04:52:24 <gmaxwell> you also can't provide a key.
25 2014-12-27 04:52:39 <wumpus> pointless, then
26 2014-12-27 04:53:08 <gmaxwell> see also: https://trac.torproject.org/projects/tor/ticket/1949#comment:12
27 2014-12-27 04:53:25 <wumpus> I wonder why tor resists being usefully embeddable, or even usefully interacting with other software so much
28 2014-12-27 04:53:37 <brand0> unrelated: is signing data with a bitcoin key recommended against?
29 2014-12-27 04:53:55 <gmaxwell> wumpus: does it resist or i sit just development resources?
30 2014-12-27 04:54:12 <wumpus> gmaxwell: I vaguely remember it resists
31 2014-12-27 04:54:44 <gmaxwell> brand0: it's not generally useful... it's inadvisable in some cases. Bitcoin is not a general purpose data cryptography tool and misses many important features. Bitcoin keys generally should be completely ephemerial (used only once).
32 2014-12-27 04:54:50 <wumpus> gmaxwell: ie, there have been efforts to turn it into a library, but they want it to ship and be configured separately
33 2014-12-27 04:54:56 <gmaxwell> brand0: pgp (gpg) is a much better for "sign data".
34 2014-12-27 04:55:59 <brand0> yeah, that's what I thought ... I thought it was strange that coinbase does it
35 2014-12-27 04:56:06 <phantomcircuit> gmaxwell, when i've asked i was always told it had to do with the hidden services stuff being multiple lines
36 2014-12-27 04:56:10 <wumpus> using the same keys for multiple purposes is also usally not recommended
37 2014-12-27 04:57:28 <wumpus> although you could of course use unrelated secp256k1 keys, but then why use bitcoin keys at all
38 2014-12-27 04:58:14 <brand0> but, generally, i don't see a reason why not to (unless you believe ECC isn't to be trusted), and obviously coinbase doesn't either ...
39 2014-12-27 05:01:17 <brand0> but if you don't trust ecc, then you shouldn't use bitcoin, right?
40 2014-12-27 05:01:52 <phantomcircuit> brand0, it's just bad engineering to reuse keys
41 2014-12-27 05:02:07 <gmaxwell> brand0: uh there is absolutely no promise in "ECC" that you won't hose your security that way.
42 2014-12-27 05:02:35 <gmaxwell> I can very easily construct a signature system that would easily compromise your security.
43 2014-12-27 05:03:22 <gmaxwell> We dodged several easy traps in bitcoin signmessage in the design, but that doesn't mean more remain... and with no PKI infrastructure, and no sane handling of large messages... well it has some uses but not many.
44 2014-12-27 05:04:44 <brand0> so it's a little crazy that coinbase supports this as a feature, no?
45 2014-12-27 05:06:26 <wumpus> I'm not distrusting ecc, well at least not that much.
46 2014-12-27 05:07:24 <Luke-Jr> brand0: no, it's a standard Bitcoin feature, for better or worse
47 2014-12-27 05:07:29 <wumpus> but there are tons of other reason not to reuse keys apart from not trusting the signing, e.g. the privacy risk
48 2014-12-27 05:07:50 <Luke-Jr> afaik the topic is the signmessage?
49 2014-12-27 05:11:12 <brand0> Luke-Jr, correct
50 2014-12-27 05:11:42 <brand0> I've heard people say to only use the address (privkey) once, but then there's the ability to sign, which directly conflicts with that
51 2014-12-27 05:11:45 <gmaxwell> brand0: in any case, it's not known bad. It's a fine feature to support. I don't know that I'd expect people to do be doing much with it.
52 2014-12-27 05:11:51 <brand0> so I was just wondering what general consensus was here
53 2014-12-27 05:12:35 <gmaxwell> brand0: it's useful for some things like providing evidence that you know keys on old transactions. Or providing settings to mining pools which use addresses purely for authentication.
54 2014-12-27 05:12:51 <gmaxwell> Then again, its currently completely incompatible with multisig.
55 2014-12-27 05:14:09 <Luke-Jr> gmaxwell: it doesn't prove you know keys!
56 2014-12-27 05:14:45 <Luke-Jr> his example being one such case the signer doesn't know the key..
57 2014-12-27 05:15:22 <brand0> with Schneier saying don't use ecc, I'm trying to screw my head back on straight, thanks for the input all
58 2014-12-27 05:19:50 <maaku> brand0: ignore Schneier
59 2014-12-27 05:20:31 <gmaxwell> he's also talking about unrelated things.
60 2014-12-27 05:20:41 <gmaxwell> (NIST curves with NSA provided 'random' parameters)
61 2014-12-27 05:21:32 <brand0> jthat is true
62 2014-12-27 05:21:55 <brand0> but he does raise issues about the relative "newness" of discrete log, etc etc
63 2014-12-27 05:22:21 <maaku> it's not that new...
64 2014-12-27 05:22:39 <brand0> compared to prime factorization which is like, what, 2000 years old?
65 2014-12-27 05:23:44 <maaku> brand0: hardness of prime factorization wasn't even on the radar for nearly all of that time
66 2014-12-27 05:24:26 <maaku> i would rate the liklihood of screwing up an RSA implementation (there are so many ways to do that) as much higher than a break of discrete log
67 2014-12-27 05:24:54 <gmaxwell> uh discrete log is also a very old problem. Also, if you can compute discrete logs in an arbritary finite field that directly gives you factoring.
68 2014-12-27 05:25:04 <brand0> that's true, implementation trumps all most times
69 2014-12-27 05:25:11 <gmaxwell> (very old problem, e.g. also worked on by gauss)
70 2014-12-27 05:25:50 <brand0> do people ever come in here asking when bitcoin is going to implement latice crypto? (lulz)
71 2014-12-27 05:26:18 <maaku> brand0: anyway ECC parameters can be chosen such that the person who created the parameters has a back door to recover any private key
72 2014-12-27 05:26:31 <brand0> I'm aware
73 2014-12-27 05:26:44 <maaku> combine that with the fact that the 'recommended' NIST curves were generated by the NSA, that's probably what Schneier was talking about
74 2014-12-27 05:26:57 <maaku> it's got nothing to do with secp256k1 though
75 2014-12-27 05:27:01 <gmaxwell> maaku: uh thats not true as far as anyone knows, not for curves meeting particular safty criteria.
76 2014-12-27 05:27:18 <maaku> gmaxwell: if you choose the generator you can do that, no?
77 2014-12-27 05:27:38 <gmaxwell> maaku: no, if you choose the generator you can know the discrete log of a single additional point.
78 2014-12-27 05:28:05 <gmaxwell> which is interesting, perhaps. But only in the context of protocols that need nothing up my sleeve points.
79 2014-12-27 05:28:11 <maaku> ah, my misunderstanding. that's significantly less interesting.
80 2014-12-27 05:28:43 <maaku> then what could Schneier be concerned over?
81 2014-12-27 05:28:57 <maaku> probably off-topic, sorry
82 2014-12-27 05:28:59 <brand0> he also pointed to two recent papers on the discrete log problem
83 2014-12-27 05:29:13 <brand0> and said that important progress is still being made in that area
84 2014-12-27 05:29:18 <gmaxwell> that there is some novel mathmatical weakness that no one (but the nsa knows anything about), and they carefully ground their random numbers to pick a one in a billion curve where the weakness applies.
85 2014-12-27 05:29:38 <brand0> and that cryptographic breakthroughs happen suddenly and can be devastating
86 2014-12-27 06:02:12 <gmaxwell> I'm looking for getpeerinfo output from long running ipv4 reachable nodes, ideally a week of uptime or more, just making some quick measurements about hosts that agressively connect to everyone. I have four observations so far, but I'd really perfer to have eight. 0bining and PMing me the url is fine. email works too.
87 2014-12-27 06:03:59 <wumpus> brand0: that doesn't exactly apply to ECC only :-)
88 2014-12-27 06:06:54 <gmaxwell> sipa: how does 0.0.0.0:8333 have a 82.94% 30d uptime in your seeds data? :P
89 2014-12-27 06:07:28 <brand0> wumpus, that's true but the point was that since discrete log is ~10x newer than factorization that it's more likely for a major breakthrough
90 2014-12-27 06:08:00 <wumpus> brand0: that sounds like very inexact science
91 2014-12-27 06:08:34 <brand0> maybe, but it is kind of how crypto works in an abstract sense, the longer something been around the more people think of it as "proven"
92 2014-12-27 06:08:41 <wumpus> if you want to put it in economical terms it's not so much about newer but how many resources have been focused on it
93 2014-12-27 06:09:12 <gmaxwell> brand0: you seem to have helpfully ignored the point I made earlier that you can factor by solving discrete logs if you really have a generic improvement in solving discrete logs. (it's a subset)
94 2014-12-27 06:10:02 <brand0> gmaxwell, that's a good point
95 2014-12-27 06:10:07 <wumpus> oh, #bitcoin-dev
96 2014-12-27 06:10:20 <brand0> sorry, I musta missed where you said that, gmaxwell
97 2014-12-27 06:11:30 <wumpus> this is too philosophical for this channel, please move it to #bitcoin-wizards or #bitcoin
98 2014-12-27 06:11:34 <brand0> I think that we can all at least agree that the math isn't really at risk right now despite what people like Schneier say
99 2014-12-27 06:11:49 <brand0> lelz @ bitcoin-*
100 2014-12-27 06:11:58 <brand0> ACTION signing out
101 2014-12-27 06:12:13 <brand0> thanks for the discussion, gmaxwell, wumpus
102 2014-12-27 06:22:54 <Luke-Jr> gmaxwell: the guy with 0.0.0.0 has some nice uptime. I worry he never upgrades his kernel though
103 2014-12-27 07:32:02 <midnightmagic> gmaxwell: ah, I thought you meant mastercoin or something more notable. right-o, got it.
104 2014-12-27 07:44:01 <midnightmagic> gmaxwell: if you want some long-term reachable measurements I can provide such. . or.. maybe not. my servers are dead. sorry.
105 2014-12-27 07:45:27 <gmaxwell> oops.
106 2014-12-27 07:45:39 <Diablo-D3> midnightmagic: lolwtf?
107 2014-12-27 07:47:26 <midnightmagic> Diablo-D3: posted in public for notification purposes.
108 2014-12-27 07:47:35 <midnightmagic> apologies channel who have no idea wtf i'm talking about :)
109 2014-12-27 08:43:37 <midnightmagic> sweet, the PPC machine running bitcoin seems to have died!
110 2014-12-27 09:00:15 <midnightmagic> nope, PPC machine is not dead. IP address reverted to DHCP due to (slightly) misconfigured /etc/network/interfaces -- and it's at approximately my DHCP lease renewal period beginning from the machine's uptime that bitcoind segfaulted in. (4 days)
111 2014-12-27 09:00:25 <midnightmagic> I have a coredump.
112 2014-12-27 09:01:05 <Diablo-D3> speaking of dns
113 2014-12-27 09:01:11 <Diablo-D3> ACTION just rebuilt how his network does dns
114 2014-12-27 09:02:52 <gmaxwell> midnightmagic: sweet.
115 2014-12-27 09:03:09 <gmaxwell> can you attach a debugger and get backtraces?
116 2014-12-27 09:03:20 <midnightmagic> yep, just about to 0bin one sec.
117 2014-12-27 09:04:05 <midnightmagic> http://0bin.net/paste/EKKrVn2970CIZeyL#nK0rHsWaIPqrJGSGjrrS6UI6ZnME6dYG0LfkJafz94S
118 2014-12-27 09:04:24 <midnightmagic> just peeking into thread 1 a bit more now.
119 2014-12-27 09:05:10 <gmaxwell> could it have run out of space? it seems to have crashed while in Shutdown()
120 2014-12-27 09:06:06 <midnightmagic> /dev/mapper/cryo 78011876 29486384 48525492 38% /home
121 2014-12-27 09:06:10 <midnightmagic> no, plenty of room.
122 2014-12-27 09:06:52 <jonasschnelli> michagogo, yes. the speech-bubble for the debug-window is probably not the best. What about that one: http://jonasschnelli.ch/device-desktop.png
123 2014-12-27 09:07:08 <gmaxwell> /join ##metricscrews
124 2014-12-27 09:07:20 <gmaxwell> ignore, mistpaste
125 2014-12-27 09:07:44 <midnightmagic> the underlying volume is a luks volume.
126 2014-12-27 09:07:45 <jonasschnelli> im asking myself if "debug-window" is the right word for the "info-/rpc-console/network-traffic/peer-table"-window
127 2014-12-27 09:08:14 <jonasschnelli> Luke-Jr, you probably had a question regarding the CC BY-SA license?
128 2014-12-27 09:08:35 <midnightmagic> gmaxwell: speculation: short-read of block data in the middle of sync?
129 2014-12-27 09:08:46 <Luke-Jr> jonasschnelli: ?
130 2014-12-27 09:10:32 <gmaxwell> midnightmagic: whats the debug log show? anything?
131 2014-12-27 09:11:34 <midnightmagic> yep one sec.
132 2014-12-27 09:11:39 <jonasschnelli> Luke-Jr, in the channel-log i saw that you had analyzed CC-BY-3.0? The icons we use ate CC-SA 3.0. I think this goes well even with the color transform.
133 2014-12-27 09:11:50 <midnightmagic> http://0bin.net/paste/gvmGTsSGm161h1cd#d7c+C3jvjL2uuU69X7JiX9-YArHtEjovKm44hSBwiIp
134 2014-12-27 09:12:43 <midnightmagic> i'll save the core and the debug.log file (this time) and restart it in a moment.
135 2014-12-27 09:12:51 <Luke-Jr> jonasschnelli: it came up re the network-toggle icon
136 2014-12-27 09:13:14 <jonasschnelli> Luke-Jr, ah yes. That's probably a different license.
137 2014-12-27 09:13:42 <jonasschnelli> Will create one from the scratch with no license (PD).
138 2014-12-27 09:13:54 <Luke-Jr> jonasschnelli: MIT license like the rest is preferable IMO
139 2014-12-27 09:14:08 <jonasschnelli> But i'm not sure if the network-switch makes it into the master
140 2014-12-27 09:14:21 <Luke-Jr> ?
141 2014-12-27 09:14:33 <midnightmagic> do I care about the leveldb corruption complaint? is it smart enough to recover itself?
142 2014-12-27 09:14:47 <gmaxwell> midnightmagic: no it's probably actually corrupted now.
143 2014-12-27 09:14:52 <midnightmagic> don't really want to wait another 6-9 days for it to sync.
144 2014-12-27 09:15:01 <midnightmagic> :-/
145 2014-12-27 09:15:08 <gmaxwell> reindex should fix it, and will be at least somewhat faster than that.
146 2014-12-27 09:18:36 <midnightmagic> huh. that's annoying. leveldb doesn't appear to be in the debian wheezy ppc repo
147 2014-12-27 09:25:53 <cool_asian> Anyone there ?
148 2014-12-27 09:35:04 <gmaxwell> midnightmagic: it's not normally distributed freestanding.
149 2014-12-27 09:36:06 <midnightmagic> .. and now I've discovered for the first time that there are no easily-located leveldb check/repair utilities..?
150 2014-12-27 09:39:13 <wumpus> Luke-Jr: that's a continuing source of problems; you can hardly find MIT licensed graphics, most artists prefer the CC-something licenses
151 2014-12-27 09:43:22 <Luke-Jr> wumpus: not saying we can't use others at all, just that if someone's making them specifically for Bitcoin Core, they should use MIT
152 2014-12-27 09:44:21 <gmaxwell> by-4.0 is a much better license than the 3.0 stuff and not arguably gratitiously incompatible; but yea, for our own stuff they should be licensed as MIT.
153 2014-12-27 11:02:15 <midnightmagic> bleh, helpful hint: don't experimentally run RepairDB on a pre-existing uncompressed leveldb, with a leveldb that has compression enabled. :-D
154 2014-12-27 11:04:49 <wumpus> yes, I made that mistake also once, even just opening the database is enough to make it unusable in bitcoin's leveldb which has no compression
155 2014-12-27 11:05:16 <wumpus> ie, was using some variant of python-leveldb which builds its own leveldb... oops
156 2014-12-27 11:05:37 <gmaxwell> hm with headers first breaking block reading tools in 0.10 perhaps we should have done the block obfscuation thing. Oh well.
157 2014-12-27 11:06:18 <wumpus> 'should have', bah, we can't fix the world in one release
158 2014-12-27 11:08:09 <gmaxwell> well it had sort of fallen off the radar, seems everyone on windows has given up running bitcoin. :) I always felt a little mixed on it just because I don't want deal with someone misconstruing the change as being intended to break some tool or another.
159 2014-12-27 11:08:19 <wumpus> well maybe one release that is infinitely far away
160 2014-12-27 11:08:52 <wumpus> sure, but there's been so many different issues like that :)
161 2014-12-27 11:09:18 <wumpus> we can still do it for 0.11, and then only for new installs (or maybe when the user provides some conversion flags)
162 2014-12-27 11:10:10 <gmaxwell> well for blocks we should probably just have a flag in the index that says if the block is obfscuated or not. then it can apply to new blocks going forward. hm but you're right in terms of breaking things.
163 2014-12-27 11:10:37 <gmaxwell> chainstate is a bit more complex since there isn't really room to store a flag.
164 2014-12-27 11:11:02 <wumpus> sure, and the reindex tool and linearize could detect an alternative magic value and regard it as obfuscated block
165 2014-12-27 11:11:12 <Luke-Jr> would upstream LevelDB accept an obfuscation patch, or would that be forking LevelDB for good?
166 2014-12-27 11:11:30 <gmaxwell> Luke-Jr: I don't think we'd want to change leveldb, just mask the keys/values going into it.
167 2014-12-27 11:11:44 <Luke-Jr> will that be sufficient?
168 2014-12-27 11:11:54 <wumpus> gmaxwell: plenty space for a global flag though, I'd really like the chainstate to be either obfuscated or not obfuscated, nothing in between
169 2014-12-27 11:12:03 <wumpus> gmaxwell: too many complexity and scope for error there
170 2014-12-27 11:12:54 <wumpus> Luke-Jr: yes, the point is just to obfuscate signatures and such that people put in it and can be detected by e.g. virus scanners
171 2014-12-27 11:13:07 <wumpus> Luke-Jr: to avoid the 'whoops, it deleted one of the database files' problem on windows
172 2014-12-27 11:13:29 <Luke-Jr> wumpus: right, I just wasn't sure if it was possible to prevent that by only obfuscating keys/values
173 2014-12-27 11:13:30 <gmaxwell> Luke-Jr: I don't know how it couldn't be sufficient. There is also the question of the stronger form where you replace the txid with H(txid) and encrypt the coins with H(2||txid) so that the user doesn't even have access to the data themselves.
174 2014-12-27 11:13:49 <gmaxwell> Luke-Jr: It should be, no third party provided data should show up elsewhere.
175 2014-12-27 11:14:03 <gmaxwell> (obviously ignoring things like peers.dat)
176 2014-12-27 11:14:50 <wumpus> well if you can encode virus signatures into your IPv6 address+port+nServices :-)
177 2014-12-27 11:16:07 <gmaxwell> I did find some stupid signature that was only 16 bytes long.
178 2014-12-27 11:16:17 <wumpus> gmaxwell: and it should be possible to disable it w/ a flag, on slower/embedded systems the extra database query overhead could be a problem, especially if the obfuscation is more involved
179 2014-12-27 11:16:48 <Luke-Jr> enabled by default on Windows only? :P
180 2014-12-27 11:16:48 <wumpus> if it's just some Xor pattern I'm not worried
181 2014-12-27 11:17:23 <gmaxwell> It should be cheap enough to not worry about regardless.
182 2014-12-27 11:17:28 <wumpus> for the blocks it's less of an issue
183 2014-12-27 11:19:24 <wumpus> btw the fee estimate file is also still incomatible between 32 and 64 bit, probably should be fixed before 0.10 as well now that I think about it
184 2014-12-27 11:21:17 <wumpus> (just a matter of changing a data type, ie https://github.com/laanwj/bitcoin/commit/c32fbeb50ea8748cf07c5fcf2c5281843ccfbd4b )
185 2014-12-27 11:22:38 <Luke-Jr> does that code otherwise produce portable files?
186 2014-12-27 11:23:49 <wumpus> yes, I think so. my checks of the serialization code didn't find any other instances of architecture-dependent types being serialized
187 2014-12-27 11:25:01 <wumpus> (well, bare char, but that's a story in itself, we don't appear to use it anywhere to do arithmetic with)
188 2014-12-27 11:25:38 <wumpus> of course, 'int' is also differently sized on some architectures, I didn't check for that
189 2014-12-27 11:26:27 <wumpus> ideally all the typed used in serialization would be uint32_t int32_t uint16_t etc, my bigendian changes make a little progress toward that
190 2014-12-27 12:16:58 <bedeho> does bitcoinqt use one wallet file for both test and mainnet?
191 2014-12-27 12:17:25 <jonasschnelli> bedeho no
192 2014-12-27 12:17:45 <jonasschnelli> testnet files lies within the testnet folder in the current <datadir>
193 2014-12-27 12:18:22 <bedeho> thanks
194 2014-12-27 12:22:22 <jonasschnelli> is there a significant reason why there are variables like "pwalletMain" in global scope instead of a singleton pattern like a potential possible walletManager::getInstance()->getWalletId(<id>)?
195 2014-12-27 12:50:10 <sipa> jonasschnelli: no, apart from the fact that nobody changed it
196 2014-12-27 12:50:28 <jonasschnelli> sipa, okay. thanks.
197 2014-12-27 12:50:31 <sipa> also, we don't actually want a singleton... we want multiple wallets
198 2014-12-27 12:51:24 <jonasschnelli> Yes. But maybe a CWalletManager as singleton?
199 2014-12-27 12:51:47 <jonasschnelli> Like CWalletManager::getInstance()->getWalletWithID(<id>)
200 2014-12-27 12:52:05 <sipa> whatever :)
201 2014-12-27 12:52:12 <jonasschnelli> hehe
202 2014-12-27 12:54:09 <sipa> i'm not convinced that a ::getInstance() has any benefit over just a global, apart from helping against a "oooo! globals are bad!" mentality
203 2014-12-27 12:55:18 <jonasschnelli> sipa, we could probably add logic to a CWalletManager like getting pub keys from all wallets, etc.
204 2014-12-27 12:56:05 <jonasschnelli> of course you could also implement this with static functions... but IMO code is better readable with clear singleton patterns
205 2014-12-27 12:56:30 <jonasschnelli> and never know when somebody once instantiate another walletManager object
206 2014-12-27 13:03:31 <bedeho> jonasschnelli : why would calling RPC "getbalance 1" not include balance from transactions with way more than 1 confirmation?
207 2014-12-27 13:06:28 <bedeho> never mind, figured it out, bitcoin-cli interprets 1 as the account
208 2014-12-27 13:06:30 <jonasschnelli> bedeho, first param is "account". Check "help getbalance" and do "getbalance "*" 1"
209 2014-12-27 13:06:38 <jonasschnelli> bedeho, right
210 2014-12-27 13:06:40 <bedeho> yeah, thanks though!
211 2014-12-27 13:24:56 <sipa> jonasschnelli: not arguing against a wallet manager at all; i'm arguing that having a getInstance method is really not better than having a global
212 2014-12-27 14:22:23 <wumpus> oh please no CWidgetManagers in bitcoin
213 2014-12-27 14:23:22 <sipa> wumpus: wallet
214 2014-12-27 14:23:35 <wumpus> adding too many layers of abstraction, java style, doesn't make the code more readable
215 2014-12-27 14:23:51 <wumpus> CWalletManagerSupervisorFactoryScriptSourceInstanceManager
216 2014-12-27 14:24:02 <jcorgan> ...Factory
217 2014-12-27 14:24:02 <sipa> needs a Visitor and an Adapter
218 2014-12-27 14:24:14 <wumpus> heh
219 2014-12-27 14:24:27 <sipa> oh, and a Factory or Manager must be Singleton
220 2014-12-27 14:24:45 <wumpus> oh course, and dependency injection configured with xml files
221 2014-12-27 14:25:00 <sipa> yes, overriding all type safety the language provides
222 2014-12-27 14:25:01 <jeremias> dependancy injection saves the world economy
223 2014-12-27 14:25:07 <jeremias> by creating lots of jobs
224 2014-12-27 14:25:30 <jeremias> only for programmers, though
225 2014-12-27 14:25:35 <wumpus> it also helps the pharma industry by creating lots of headaches
226 2014-12-27 14:26:53 <wumpus> anyhow, if you don't really need a manager class, don't create one
227 2014-12-27 14:27:19 <jcorgan> could be worse: http://cube-drone.com/2014_11_16-99_Ingenuity.html
228 2014-12-27 14:28:43 <sipa> https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
229 2014-12-27 14:30:03 <wumpus> LOOOL
230 2014-12-27 14:35:27 <xenog> sipa: very good one!
231 2014-12-27 14:38:37 <jcorgan> lol, just sent this off to my brother, who is a java-based middleware developer for internal "enterprise" IT software
232 2014-12-27 14:41:44 <dgenr8> lol "motherf..."
233 2014-12-27 14:50:15 <gmaxwell> wumpus: you'd not seen that? yea. well it would be funnier if it weren't true.
234 2014-12-27 14:50:35 <gmaxwell> I think it didn't quite have enough crazy autogenerated boilerplate produced by people who only know how to click ide buttons.
235 2014-12-27 14:54:21 <wumpus> no, hadn't seen that one yet :-) seen enough code like it though, mostly java, although some C++ projects tried to copy it especially when OOP was the buzzword of the day
236 2014-12-27 15:01:56 <wumpus> many of it just gives a veneer of flexibility but serves to obfuscate what happens, e.g. singletons are a wooly abstraction of globals, if you don't like global state, you shouldn't like singletons
237 2014-12-27 15:03:12 <gmaxwell> or a veneer of respectability.
238 2014-12-27 15:03:25 <wumpus> yes
239 2014-12-27 15:03:29 <gmaxwell> "Goto is bad; fill your code with returns"
240 2014-12-27 15:03:49 <wumpus> *seeming* to make to code better
241 2014-12-27 15:04:02 <sipa> yeah, people learn that globals are bad, but forgot why they are bad
242 2014-12-27 15:04:12 <sipa> then find patterns to avoid the symptom, but not the problem
243 2014-12-27 15:04:57 <wumpus> just make a few extra objects and interfaces around it
244 2014-12-27 15:16:27 <maaku> sipa: god I wish all managers were singletons
245 2014-12-27 15:16:51 <Diablo-D3> Your wish has been granted.
246 2014-12-27 15:17:07 <maaku> Diablo-D3: thanks god!
247 2014-12-27 15:33:45 <jonasschnelli> Okay. I slowly come into the coding style of bitcoin...
248 2014-12-27 15:34:35 <sipa> :)
249 2014-12-27 15:38:06 <wumpus> jonasschnelli: let's not make anything global at all when we get rid of pwalletmain, e.g. just pass the container or manager of wallets to the RPC server and the GUI
250 2014-12-27 15:46:58 <jonasschnelli> wumpus, Okay. But either we have a global wallet-container (array) in the global scope or we pass around a instance of a manager (would be more my thing).
251 2014-12-27 15:47:26 <sipa> jonasschnelli: please have a look at codeshark's earlier multiwallet patch
252 2014-12-27 15:48:33 <wumpus> jonasschnelli: yes, just pass the objects around, as in the UI. Although I see three instances of pwalletMain usage snuck into it.
253 2014-12-27 15:48:36 <jonasschnelli> sipa, okay, will do
254 2014-12-27 15:49:07 <sipa> jonasschnelli: it's very outdated, but it did indeed introduce a walletmanager (i think it should rather be called walletcollection, though), which handles loading/finding/unloading wallets
255 2014-12-27 15:50:03 <jonasschnelli> wumpus, yes. I think this is fine if we init the manager in AppInit and pass it around. But the singleton idea was more to prevent to pass around the instance to every sub-object-of-sub-objects. But didn't have a look at pwalletMain consumers.
256 2014-12-27 15:50:12 <wumpus> that's fine, I realized the problem is not having a walletcollection/manager class, but having it global in scope e.g. a singleton
257 2014-12-27 15:51:08 <jonasschnelli> I see the point that a singleton is more or less the same thing like keeping something in the global scope and having some static functions (like getWalletWithID()).
258 2014-12-27 15:51:20 <wumpus> BTW there is a LoadWallet signal, but currently it's global
259 2014-12-27 15:51:24 <jonasschnelli> But i once heard that the bitcoin source-code should be hard to read... :)
260 2014-12-27 15:51:43 <sipa> *should* be? what?
261 2014-12-27 15:52:29 <jonasschnelli> sorry. wrong english. I've read that bitcoins source-code is hard to read.
262 2014-12-27 15:52:40 <sipa> try reading 0.3.17 :)
263 2014-12-27 15:52:59 <sipa> (not saying it's that much easier now, but it's also doing a lot more...)
264 2014-12-27 15:53:04 <wumpus> yes, but if the goal is to reduce global state, which I wholeheartily agree with because it makes for harder-to-understand and debug side effects, we certainly don't want to introduce singletons which just wrap it in a layer of respectability
265 2014-12-27 15:53:43 <jonasschnelli> wumpus, okay. Let me try to not produce a oo overdose and still keep it snappy and readable.
266 2014-12-27 15:53:56 <wumpus> jonasschnelli: thanks :)
267 2014-12-27 15:57:19 <jonasschnelli> what was the issue of CodeShark 's multiwallet patch (https://github.com/bitcoin/bitcoin/pull/2184)? Lack of reviewing/testing?
268 2014-12-27 15:58:11 <wumpus> IIRC it was pretty close before a release so we didn't want to merge it immediately, and then it went out of sync and wasn't rebased
269 2014-12-27 15:58:30 <wumpus> but yes, lack of reviewing/testing was, and still is a big issue for wallet patches
270 2014-12-27 15:58:45 <jonasschnelli> he introduced CWalletManager(); :-)
271 2014-12-27 15:59:05 <sipa> yes
272 2014-12-27 15:59:34 <wumpus> codeshark stopped maintaining his patches at some point and went off to his own wallet project
273 2014-12-27 15:59:59 <jonasschnelli> Okay. At first sight it looks pretty good.
274 2014-12-27 16:00:18 <wumpus> (coinvault or such)
275 2014-12-27 16:00:40 <sipa> did we ever merge that patch to get rid of the rpctable locking, and push the locking down?
276 2014-12-27 16:02:00 <jonasschnelli> but yes. It looks like that it takes a lot of energy to bring in such a patch into the master...
277 2014-12-27 16:02:16 <sipa> now is the time :)
278 2014-12-27 16:02:19 <jonasschnelli> Is there no tester recruiting effort? bitcointalk or some?
279 2014-12-27 16:02:36 <wumpus> I don't remember re: RPC locking patch
280 2014-12-27 16:02:49 <wumpus> I don't think so though
281 2014-12-27 16:03:02 <wumpus> too many pulls open
282 2014-12-27 16:04:40 <wumpus> https://github.com/bitcoin/bitcoin/pull/5107
283 2014-12-27 16:07:42 <wumpus> damnit I checked it in detail, acked it, and so did sipa, but lost track of it
284 2014-12-27 16:10:03 <gmaxwell> I think I whined on IRC along the general lines of #include <generic_vague_concern_about_peppering_the_code_with_avoidable_locks.h>
285 2014-12-27 16:13:43 <wumpus> ok doesn't look to bad to rebase
286 2014-12-27 16:14:33 <wumpus> well it doesn't introduce new (avoidable) locks, it just makes them explicit
287 2014-12-27 16:26:02 <legendary> wumpus:How does the rebasing actually work?
288 2014-12-27 16:55:40 <phantomcircuit> sipa, can you sort the list of seed nodes? https://github.com/bitcoin/bitcoin/pull/5532
289 2014-12-27 16:55:58 <sipa> yes, will do
290 2014-12-27 16:58:38 <gmaxwell> sipa: thoughts on the filter script I sent you?
291 2014-12-27 17:04:37 <sipa> did not see it?
292 2014-12-27 17:05:41 <gmaxwell> sipa: https://people.xiph.org/~greg/seed_filter.py
293 2014-12-27 17:06:49 <wumpus> firelegend: it works by applying the diff between commits A end B, where A is the parent of the commit B that your want to rebase to another commit C
294 2014-12-27 17:06:50 <gmaxwell> Basically past some initial sanity checks it limits the output to two highest uptime nodes per ASN to avoid the case now were we get a dozen strange nodes on the same VPS, having more network diversity is good (e.g. if the internet is partitiond you're more likely to find a surviving chunk)
295 2014-12-27 17:07:16 <wumpus> firelegend: see also man git-rebase
296 2014-12-27 17:44:53 <michagogo> jonasschnelli: heh, the client on my phone shows images on a black background, so that (I assume black-on-transparent) image doesn't show at all
297 2014-12-27 17:54:08 <wumpus> michagogo: luke-jr's patch recolors the icons according to your theme
298 2014-12-27 18:10:01 <michagogo> 8:02:35 <gmaxwell> I'm looking for getpeerinfo output from long running ipv4 reachable nodes, ideally a week of uptime or more, just making some quick measurements about hosts that agressively connect to everyone. I have four observations so far, but I'd really perfer to have eight. 0bining and PMing me the url is fine. email works too.
299 2014-12-27 18:10:23 <michagogo> gmaxwell: sorry, if you'd asked me a week ago I would have had one to give you
300 2014-12-27 18:11:08 <michagogo> I was running master, mainnet and testnet, IPv4/IPv6/onion
301 2014-12-27 18:12:12 <michagogo> On a VPS that someone was providing for free (#fuslvz), but she decided that the host node was too expensive to keep running
302 2014-12-27 18:12:28 <michagogo> 13:08:33 <gmaxwell> well it had sort of fallen off the radar, seems everyone on windows has given up running bitcoin. :) I always felt a little mixed on it just because I don't want deal with someone misconstruing the change as being intended to break some tool or another.
303 2014-12-27 18:12:39 <michagogo> ACTION runs the GUI on Windows
304 2014-12-27 18:13:14 <michagogo> wumpus: Ah, that's nice. I was referring to the link he pinged me in here with
305 2014-12-27 18:13:52 <michagogo> wumpus: btw, I saw gavinandresen pushed sigs -- is the detached OS X sig posted somewhere?
306 2014-12-27 18:14:19 <wumpus> michagogo: no, he didn't use that, just did manual signing, we'll have to see about that next time
307 2014-12-27 18:14:39 <michagogo> Ah, okay
308 2014-12-27 18:14:50 <michagogo> (Any specific reason?)