1 2014-08-05 00:00:16 <jgarzik> gmaxwell, https://github.com/bitcoin/bitcoin/pull/4632
2 2014-08-05 00:00:17 <cfields> gmaxwell: #4632
3 2014-08-05 00:00:40 <cfields> jgarzik: to get to the point: why not prune in GetAddr_ ?
4 2014-08-05 00:00:41 <jgarzik> cfields, Also, if you are restarting a node after a long sleep (many days), you might suddenly decide your entire peer db was terrible
5 2014-08-05 00:01:34 <jgarzik> cfields, "terrible" is so... fluid. Your node shouldn't be so judgemental. ;p
6 2014-08-05 00:02:03 <jgarzik> cfields, broadly speaking, addrman is optimistic, and jealously guards addresses as a miser conserves pennies.
7 2014-08-05 00:02:04 <cfields> / Determine whether the statistics about this entry are bad enough so that it can just be deleted
8 2014-08-05 00:02:11 <cfields> just going by the comment :)
9 2014-08-05 00:02:24 <jgarzik> cfields, contect
10 2014-08-05 00:02:25 <cfields> ok
11 2014-08-05 00:02:27 <jgarzik> cfields, context
12 2014-08-05 00:02:37 <gmaxwell> cfields: there is never a reason to delete anything, it'll just get overwritten.
13 2014-08-05 00:02:38 <jgarzik> cfields, can be deleted.... when adding a better entry to the bucket
14 2014-08-05 00:03:08 <cfields> makes sense. thanks for clarifying
15 2014-08-05 00:03:24 <gmaxwell> Addrman is a fixed size database, it'll overwrite things as it learns new things. You're pretty much never off actually forgetting something... instead the approach is to make less good things higher priority for overwrite / lower priority for use. :)
16 2014-08-05 00:04:21 <jgarzik> In practice though, addrman today passes any old garbage back to requesting peers
17 2014-08-05 00:04:27 <gmaxwell> It's somewhat inspired by the fortuna-style random number generator functions... has a approach that even if an attacker controlls a lot of the input it'll still keep doing 'surprising' things from time to time.
18 2014-08-05 00:05:02 <jgarzik> if DNS seeds are not present, all this garbage slows down finding good connections
19 2014-08-05 00:05:50 <jgarzik> there is some pathological behavior at low address counts on testnet, and various minor problems at the edges on mainnet associated with long-lived garbage addresses
20 2014-08-05 00:06:01 <jgarzik> IMNSHO better addresses need to bubble up
21 2014-08-05 00:06:40 <gmaxwell> jgarzik: hm. well IIRC it will always give you some of its better ones, but they might not be obviously better to you... since the nLastSuccess data doesn't make it across the wire.
22 2014-08-05 00:11:19 <jgarzik> gmaxwell, GetAddr() pulls from vRandom[]. vRandom is a "randomly-ordered vector of all nIds" according code comment, which appears to match the code itself. Every CAddrInfo has an associated nid, and entry in mapInfo.
23 2014-08-05 00:11:39 <jgarzik> gmaxwell, thus "getaddr" P2P call gets any old garbage
24 2014-08-05 00:12:17 <jgarzik> each bucket is coded to trend towards replacing unhealthy with healthy, certainly.
25 2014-08-05 00:13:12 <gmaxwell> ah, okay, yea, I think we should perhaps make sure the result is dense in good ones, and perhaps set ntime back in time for bad ones.
26 2014-08-05 00:15:22 <gmaxwell> Once we add peer rotation we'll have much better databases about what nodes are reachable in general.
27 2014-08-05 00:18:10 <BlueMatt> controversial, or most controversial? https://github.com/bitcoin/bitcoin.org/pull/506
28 2014-08-05 00:23:05 <BlueMatt> satoshi no longer has push access to bitcoin/bitcoin, no?
29 2014-08-05 00:26:00 <gmaxwell> BlueMatt: he does not.
30 2014-08-05 00:29:20 <saivann_> Well I think that's up to you. The PGP key can remain on the website, even though it isn't linked from the page anymore, so...
31 2014-08-05 00:29:32 <BlueMatt> yes, I did that deliberately
32 2014-08-05 00:29:43 <BlueMatt> no reason for bitcoin.org/satoshi.asc to not exist if its not linked to anywhere
33 2014-08-05 01:27:13 <PRab> Would there be any object to adding {"client" : "bitcoind"} to the results of the getinfo rpc command?
34 2014-08-05 01:27:44 <PRab> It would be useful for bitcoind-ncurses.
35 2014-08-05 01:29:11 <gmaxwell> Nothing should be added to getinfo at all.
36 2014-08-05 01:29:34 <gmaxwell> Getinfo is deprecated.
37 2014-08-05 01:41:39 <BlueMatt> sorry again for the (very late) release, but 0.9.2.1 of bitcoin core is now up on the ppa
38 2014-08-05 01:42:20 <PRab> gmaxwell: Oh... https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list didn't mention it. Is there a new/better api to get that from?
39 2014-08-05 01:43:40 <iwilcox> BlueMatt: Was there anything to tweak? The .deb just built for me from git.
40 2014-08-05 01:43:56 <BlueMatt> iwilcox: nope
41 2014-08-05 01:44:01 <BlueMatt> oops, meant to close that bug, one sec
42 2014-08-05 01:44:20 <BlueMatt> done
43 2014-08-05 01:44:50 <cfields> BlueMatt: i meant to ping you a while back, i believe the build issues for ppa should be fixed now
44 2014-08-05 01:45:00 <BlueMatt> cfields: they are indeed
45 2014-08-05 01:45:09 <cfields> ok great
46 2014-08-05 01:45:54 <cfields> BlueMatt: we should probably sync up at some point as well re: dependency building
47 2014-08-05 01:46:04 <cfields> since the ppa can now use the same build process as pull-tester/gitian
48 2014-08-05 01:46:13 <BlueMatt> oh, yea, that'd be nice to do
49 2014-08-05 01:46:21 <cfields> can of worms i'm not interested in opening atm, just throwing it out there for the future :)
50 2014-08-05 01:46:24 <BlueMatt> ideally, the ppa wont actually build anything at all
51 2014-08-05 01:46:50 <BlueMatt> it should just ship a post-install script that fetches the bitcoin linux builds, checks their sigs, and copies them
52 2014-08-05 01:47:15 <BlueMatt> doesnt actually provide any additional security, but its cleaner that way and less chance of any issues cropping up
53 2014-08-05 01:47:54 <cfields> well, it'd be very simple to do now as soon as the deps are merged in, but it wouldn't match gitian sigs...
54 2014-08-05 01:48:01 <cfields> doing that would take a bit more effort
55 2014-08-05 01:49:06 <BlueMatt> I'd prefer it not even do any building to try to match or anything like that
56 2014-08-05 01:49:15 <BlueMatt> just a shell script that runs gitian-updater
57 2014-08-05 01:49:50 <cfields> mm, i suppose it could just pull the binaries straight from where they're published on the website
58 2014-08-05 01:50:01 <BlueMatt> it should
59 2014-08-05 01:50:11 <BlueMatt> though we need to ship the gitianized zip folders
60 2014-08-05 01:50:19 <BlueMatt> (which are just the direct gitian outputs and signatures)
61 2014-08-05 01:50:45 <cfields> shouldn't the .asc be enough to verify?
62 2014-08-05 01:51:17 <cfields> or output .yml or w/e it is
63 2014-08-05 01:53:04 <cfields> BlueMatt: also, pull-tester will be building other arch's, and gitian can use them as well
64 2014-08-05 01:53:37 <cfields> so it may be worth considering adding armhf or similar
65 2014-08-05 01:54:47 <BlueMatt> cfields: I dont remember, but there is a downloader script in gitian-builder that handles all the stuff automagically
66 2014-08-05 01:55:16 <BlueMatt> so easiest to just use that, though expects a zip with exact format of something like {output/[all the stuff], gitian/[all the sigs]}
67 2014-08-05 01:57:32 <cfields> ok
68 2014-08-05 03:08:30 <earlz> can someone help me with a bit of code history?
69 2014-08-05 03:08:55 <earlz> So, there are some altcoins forked from some point in bitcoin when chainparams.cpp existed, but it still used the old qmake system. Was there ever a release like that?
70 2014-08-05 03:45:07 <Doger_> hi, anyone have any experience with Coinbase API and refunds?
71 2014-08-05 05:52:10 <Luke-Jr> ACTION ponders if there'd be any generic use to the JSON-input-and-output RPC client he wrote that automatically translates to protobuf-over-ZMQ <.<
72 2014-08-05 06:02:49 <wumpus> Luke-Jr: well there is a whole 'enterprise' business of adapters between various service RPC mechanisms
73 2014-08-05 06:03:22 <Luke-Jr> wumpus: really? :o
74 2014-08-05 06:03:43 <Luke-Jr> unfortunately, I realised a minor issue with making this generic: protobuf likes code generation
75 2014-08-05 06:03:49 <Luke-Jr> so any schema needs to be compiled in :/
76 2014-08-05 06:04:31 <Luke-Jr> I guess one could dynamically make a .so and load it
77 2014-08-05 06:05:31 <wumpus> but personally i wouldn't know anything that this would be specifically useful for outside of bitcoin
78 2014-08-05 06:05:52 <Luke-Jr> wumpus: I actually wrote it for a home automation framework I've been working on
79 2014-08-05 06:06:06 <Luke-Jr> using protobuf-over-ZMQ for the interfaces, but needed a human-friendly way to interact
80 2014-08-05 06:09:12 <wumpus> protobuf over zmq makes a lot of sense for that, especially if you have parameters that can change with high frequency like light dimmers
81 2014-08-05 06:10:13 <wumpus> json would have a large encoding/decoding overhead especially on the embedded system side
82 2014-08-05 06:12:01 <Luke-Jr> right
83 2014-08-05 06:12:12 <Luke-Jr> I'm only using JSON for human interaction/debugging
84 2014-08-05 06:12:48 <wumpus> I hacked something like that together based on the dbus protocol once, it was a kind of bad choice in retrospect, it doesn't scale well to a larger network than say one server that controls everything :P
85 2014-08-05 06:13:56 <Luke-Jr> heh
86 2014-08-05 06:14:01 <Diablo-D3> wumpus: dbus is, largely, a mistake for everything
87 2014-08-05 06:14:02 <Luke-Jr> wumpus: https://github.com/luke-jr/freeabode if it interests you
88 2014-08-05 06:14:08 <wumpus> Luke-Jr: it's funny that json is still more useful for that, makes me think JSONRPC was a good choice for bitcoin
89 2014-08-05 06:14:10 <Diablo-D3> Luke-Jr: btw, why protobuf?
90 2014-08-05 06:14:15 <Luke-Jr> wumpus: for the moment, it is oriented around running on a rooted Nest thermostat
91 2014-08-05 06:14:22 <Luke-Jr> Diablo-D3: because I didn't see anything better
92 2014-08-05 06:14:38 <Diablo-D3> capn proto
93 2014-08-05 06:14:46 <wumpus> Luke-Jr: (apart from the small issue with the monetary amounts....)
94 2014-08-05 06:14:49 <Luke-Jr> Cap'n Proto was appealing, but I didn't feel like writing an ebuild
95 2014-08-05 06:15:03 <Luke-Jr> ironically, I ended up having to fix protobuf's ebuild to cross-compile x.x
96 2014-08-05 06:15:11 <Diablo-D3> lol.
97 2014-08-05 06:15:48 <wumpus> Diablo-D3: well at least you didn't suggest ASN.1, I'm happy :)
98 2014-08-05 06:15:58 <Luke-Jr> hah
99 2014-08-05 06:16:59 <Diablo-D3> wumpus: deargodwhy
100 2014-08-05 06:19:57 <wumpus> Diablo-D3: I played around a bit with the GSM protocol at some point, w/ nokia 3310 you could get at quite a low level, so I got exposed to ASN.1, I didn't ever fully recover my sanity
101 2014-08-05 06:20:10 <Diablo-D3> wumpus: explains much.
102 2014-08-05 06:20:37 <wumpus> hehehe
103 2014-08-05 06:21:10 <Luke-Jr> ACTION ponders how much trouble he's going to have using ZMQ on the real device considering how much it's having issues with his desktop's /dev/random flow
104 2014-08-05 06:21:35 <Diablo-D3> Luke-Jr: er
105 2014-08-05 06:21:37 <Diablo-D3> use urandom bro
106 2014-08-05 06:21:46 <Luke-Jr> Diablo-D3: I don't think that's an option for ZMQ?
107 2014-08-05 06:22:00 <Diablo-D3> wtf.
108 2014-08-05 06:22:00 <Diablo-D3> zmq _requires_ non-u random?
109 2014-08-05 06:22:05 <Diablo-D3> that is some broken ass software
110 2014-08-05 06:22:26 <wumpus> probably for strong cryptographic keys, so that other people won't start controlling his thermostats? :p
111 2014-08-05 06:22:36 <Diablo-D3> wumpus: nope
112 2014-08-05 06:22:37 <Luke-Jr> actually, it's libsodium
113 2014-08-05 06:22:42 <Luke-Jr> and Gentoo has a USE flag for urandom
114 2014-08-05 06:22:44 <Diablo-D3> urandom is only unsafe for that at boot time
115 2014-08-05 06:22:45 <Luke-Jr> maybe I should turn it on
116 2014-08-05 06:23:01 <Diablo-D3> a box that has been running awhile produces output just as random as random
117 2014-08-05 06:23:38 <Luke-Jr> ACTION makes the assumption urandom is only available where it's safe and flips it on
118 2014-08-05 06:24:05 <Luke-Jr> oh, I actually have it on for the cross target *shrug*
119 2014-08-05 06:24:25 <Diablo-D3> Luke-Jr: seriously, anyone who tries to use random and doesnt understand why shouldnt be allowed to program
120 2014-08-05 06:24:26 <wumpus> oh libsodium, I also compiled that a few days ago, I wanted to compile obelisk, needed to compile dependency after dependency from source because distribution packages either didn't exist or were not new enough
121 2014-08-05 06:24:38 <wumpus> compiling bitcoind isn't so bad.
122 2014-08-05 06:24:50 <Diablo-D3> Ive compiled bitcoind before
123 2014-08-05 06:24:56 <Diablo-D3> way back when
124 2014-08-05 06:25:01 <Diablo-D3> and its now like
125 2014-08-05 06:25:02 <Diablo-D3> why bother
126 2014-08-05 06:25:16 <Diablo-D3> I dont follow git upstream
127 2014-08-05 06:25:19 <Diablo-D3> I dont write patches for it
128 2014-08-05 06:50:28 <sipa> PRab: getmininginfo, getnetworkinfo, getpeerinfo, getwalletinfo, ...
129 2014-08-05 06:53:11 <wumpus> not sure how a client name would help though; I hope you already know what you're connecting to if you're provided the rpc user and password as well
130 2014-08-05 06:54:15 <sipa> getting the version string may be meaningful
131 2014-08-05 06:54:22 <wumpus> or is this for the case where you get a jumble of ports, username and password and have to figure out which is which?
132 2014-08-05 06:54:26 <wumpus> sure
133 2014-08-05 06:55:22 <sipa> wumpus: do you have access to a 32-bit ubuntu 12.x build env? someone reported that git head (since the unordered map for ccoinsviewcache) fails to sync testnet
134 2014-08-05 06:55:38 <wumpus> oh we don't even expose the subversion over RPC!
135 2014-08-05 06:55:58 <sipa> gmaxwell and i tested 32 bit and 64 bit, and work, but perhaps it is an os/boost issue
136 2014-08-05 06:56:17 <wumpus> let's see
137 2014-08-05 06:56:45 <sipa> which, if not a hardware issue, is scary
138 2014-08-05 06:58:19 <wumpus> yes I think I have one
139 2014-08-05 06:58:52 <wumpus> oh 11.10
140 2014-08-05 07:00:00 <wumpus> I'll try to upgrade it; do you know where in the sync process it fails?
141 2014-08-05 07:01:09 <sipa> block 381
142 2014-08-05 07:01:20 <sipa> consistently, which is even more scary
143 2014-08-05 07:02:29 <sipa> wumpus: oh, he's here: E-Rage
144 2014-08-05 07:02:34 <wumpus> that's indeed scary
145 2014-08-05 07:09:58 <dsnrk> wumpus: want me to give it a shot too?
146 2014-08-05 07:10:39 <wumpus> E-Rage: what's your boost version? ( grep "define BOOST_VERSION " /usr/include/boost/version.hpp )
147 2014-08-05 07:11:04 <ItsDom> does anyone know when wallet encryption was added to the default bitcoin client?
148 2014-08-05 07:11:14 <wumpus> dsnrk: sure, if you have that environment, I first have to wait for the upgrade to complete, and have to install dependencies, etc
149 2014-08-05 07:11:26 <sipa> ItsDom: 0.4, if you're talking about wallet encryption
150 2014-08-05 07:11:47 <ItsDom> sipa: yes I was. Thanks, really appreciated:)
151 2014-08-05 07:11:55 <dsnrk> wumpus: I have the environment, same deal though.
152 2014-08-05 07:12:19 <wumpus> it may be faster to just spin up a new VM
153 2014-08-05 07:12:29 <sipa> i'll copy paste all info in an issue
154 2014-08-05 07:12:53 <wumpus> "About 2 hours 15 minutes remaining" :*
155 2014-08-05 07:45:37 <wumpus> hmm ubuntu 12.04 offers the choice between boost 1.46 and boost 1.48
156 2014-08-05 07:46:01 <wumpus> 'libboost-all-dev' gives me 1.46 so I'll go with that
157 2014-08-05 07:54:44 <sipa> ;;later tell E-Rage see https://github.com/bitcoin/bitcoin/issues/4634
158 2014-08-05 07:54:45 <gribble> The operation succeeded.
159 2014-08-05 08:17:57 <cfields> sipa / wumpus: do you have a sample test-case? or is an actual testnet sync needed?
160 2014-08-05 08:18:11 <wumpus> I managed to reproduce it
161 2014-08-05 08:18:32 <wumpus> cfields: well only the first 381 blocks, I'd call that a 'simple test case'
162 2014-08-05 08:19:31 <cfields> wumpus: was asking because i can have the pull-tester try whatever version of boost is needed. but there'd need to be a failing test
163 2014-08-05 08:20:00 <wumpus> let's try that!
164 2014-08-05 08:20:19 <cfields> sure. which version?
165 2014-08-05 08:20:31 <wumpus> wow the tests fail... badly
166 2014-08-05 08:21:07 <wumpus> going to try with bc42503 reverted
167 2014-08-05 08:21:17 <cfields> oh, ok
168 2014-08-05 08:21:52 <wumpus> lots of errors with the CCoinsViewCache, as expected by the commit that is reported to trigger it
169 2014-08-05 08:22:03 <cfields> which boost version?
170 2014-08-05 08:25:31 <dsnrk> cfields: see the github issue.
171 2014-08-05 08:27:50 <wumpus> (or read a few lines back :p)
172 2014-08-05 08:28:27 <cfields> agh, i missed your 2nd line :\
173 2014-08-05 08:28:33 <cfields> and of course i picked 1.48 as a guess
174 2014-08-05 08:30:29 <wumpus> with bc42503 reverted, all tests pass
175 2014-08-05 08:31:18 <wumpus> I'm going to revert it for now
176 2014-08-05 08:31:19 <sipa> wumpus: what if you use your previous version, without the custom hasher class?
177 2014-08-05 08:31:55 <wumpus> sipa: worth a try
178 2014-08-05 08:32:17 <cfields> ugh, really seems like boost < 1.53 or so is pretty rough
179 2014-08-05 08:32:37 <cfields> 1.46 and 1.48 both fail to build here without patching
180 2014-08-05 08:32:52 <wumpus> cfields: build worked fine for me
181 2014-08-05 08:33:10 <cfields> wumpus: building boost itself?
182 2014-08-05 08:33:29 <wumpus> cfields: no
183 2014-08-05 08:33:34 <wumpus> just bitcoin
184 2014-08-05 08:36:14 <wumpus> but yes, compiling boost 1.46 on a newer system makes sense to see if it is really the culprit
185 2014-08-05 08:38:31 <sipa> so, if we can't pinpoint exactly what the problem is with boost (as in, for example a known bug "boost X through Y fail when used with a custom hasher class"), we should definitely revert
186 2014-08-05 08:39:45 <wumpus> agreed; if it fails with the trivial custom hasher too, we can conclude that boost::unordered_map is buggy
187 2014-08-05 08:39:49 <michagogo> huh.
188 2014-08-05 08:39:53 <michagogo> bitcoind was running, and now it's not.
189 2014-08-05 08:40:29 <michagogo> Last log line is a received version message at 2014-08-04 11:47:45...
190 2014-08-05 08:40:38 <sipa> OOM?
191 2014-08-05 08:40:44 <michagogo> Nothing in dmesg
192 2014-08-05 08:41:02 <michagogo> Anywhere else I should be looking?
193 2014-08-05 08:41:20 <michagogo> (this is Ubuntu 14.04, in an OpenVZ container)
194 2014-08-05 08:42:23 <wumpus> even segmentation faults get logged to dmesg on ubuntu
195 2014-08-05 08:44:25 <ThomasV> I get a syntax error in configure (git head)
196 2014-08-05 08:44:30 <wumpus> I suppose you don't log the stdout/stderr anywhere?
197 2014-08-05 08:44:43 <wumpus> or the exit status
198 2014-08-05 08:44:58 <ThomasV> ./configure: line 2748: `LT_INIT(disable-shared)'
199 2014-08-05 08:44:58 <ThomasV> ./configure: line 2748: syntax error near unexpected token `disable-shared'
200 2014-08-05 08:45:16 <wumpus> ThomasV: apt-get install libtool , re-do autogen.sh and configure
201 2014-08-05 08:45:19 <cfields> install libtool
202 2014-08-05 08:45:27 <ThomasV> thanks
203 2014-08-05 08:46:12 <wumpus> michagogo: it almost has to be an assertion failure
204 2014-08-05 08:46:31 <michagogo> wumpus: no, I just run with -daemon=1
205 2014-08-05 08:46:48 <michagogo> I don't log anything the system doesn't already
206 2014-08-05 08:47:06 <michagogo> I guess if I'm running master maybe I should run it in screen with daemon=0
207 2014-08-05 08:47:15 <wumpus> assertion errors don't get logged anywhere :(
208 2014-08-05 08:47:19 <wumpus> or run it in gdb ;)
209 2014-08-05 08:47:42 <cfields> wumpus: didn't you say the tests failed?
210 2014-08-05 08:47:54 <wumpus> cfields: yes they failed - horribly
211 2014-08-05 08:48:00 <cfields> ok
212 2014-08-05 08:48:06 <cfields> https://travis-ci.org/coryfields/bitcoin/jobs/31690399
213 2014-08-05 08:48:19 <cfields> that's x64, was easier to run a quick test
214 2014-08-05 08:48:21 <wumpus> I can't copy/paste from that VM so I don't have the exact errors
215 2014-08-05 08:48:44 <michagogo> One sec, I'll tweak my aliases to start in names screen sessions
216 2014-08-05 08:48:46 <cfields> if that fails, i'll do x32, but they take ~30min
217 2014-08-05 08:48:52 <wumpus> sipa: with the trivial custom hasher no problems
218 2014-08-05 08:49:26 <michagogo> it's `screen -dmS name command arguments`, right?
219 2014-08-05 08:49:30 <wumpus> already up to block 11637 and tests pass
220 2014-08-05 08:50:16 <sipa> wumpus: with a custom hasher class, or by just using std::size_t hash_value?
221 2014-08-05 08:50:49 <wumpus> sipa: I've used my old commit, so the second
222 2014-08-05 08:50:50 <sipa> wumpus: hmm, my hasher returns uint64_t, but perhaps the hasher is expected to produce a size_t?
223 2014-08-05 08:51:00 <sipa> which may make a difference on 32-bit
224 2014-08-05 08:51:05 <cfields> sipa: wait, i saw something like that in the changelog
225 2014-08-05 08:51:10 <wumpus> sipa: I'll try turning it into a real custom hasher
226 2014-08-05 08:51:19 <sipa> wumpus: can you try making my hasher return size_t?
227 2014-08-05 08:52:14 <wumpus> sipa: sure
228 2014-08-05 08:53:09 <cfields> fwiw, passed tests with 64bit boost 1.46.1
229 2014-08-05 08:55:20 <michagogo> er, actually, if it dies, the screen session will go away... can I make it not do that?
230 2014-08-05 08:55:30 <wumpus> michagogo: run it in gdb :D
231 2014-08-05 08:55:41 <michagogo> How do I do that?
232 2014-08-05 08:55:45 <sipa> gdb ./bitcoind
233 2014-08-05 08:55:46 <sipa> run
234 2014-08-05 08:55:54 <wumpus> screen gdb -run src/bitcoind -args blabla
235 2014-08-05 08:56:20 <michagogo> Does that take significantly more resources than running it normally?
236 2014-08-05 08:56:27 <wumpus> hardly
237 2014-08-05 08:56:31 <sipa> a bit more cpu
238 2014-08-05 08:56:56 <wumpus> unless you set breakpoints or, *shudder* data-watching breakpoints, then things start to get bad
239 2014-08-05 08:58:13 <wumpus> but just gdb attached to the process should have no effect on execution speed at all
240 2014-08-05 08:59:17 <michagogo> ACTION checks if he has gdb
241 2014-08-05 08:59:46 <michagogo> Nope. It's offering me either `gdb` or `gdb-minimal`... any idea what the difference is?
242 2014-08-05 08:59:54 <michagogo> ;;google ubuntu gdb vs gdb-minimal
243 2014-08-05 08:59:55 <gribble> Ubuntu â Details of package gdb-minimal in trusty: <http://packages.ubuntu.com/trusty/devel/gdb-minimal>; gdb-minimal - Ubuntu â Error: <http://packages.ubuntu.com/quantal/devel/gdb-minimal>; Ubuntu â Package Search Results -- gdb: <http://packages.ubuntu.com/src:gdb>
244 2014-08-05 09:00:55 <sipa> minimal is likely enough
245 2014-08-05 09:01:47 <wumpus> I suppose you don't get all the nice python scripting facilities with -minimal, then again, you don't need those right now
246 2014-08-05 09:04:59 <michagogo> Looks like minimal builds with --disable-tui --without-python
247 2014-08-05 09:05:25 <michagogo> Do I need the TUI?
248 2014-08-05 09:06:02 <cfields> ok, i'm headed to bed...
249 2014-08-05 09:06:09 <cfields> want me to fire off a build first?
250 2014-08-05 09:06:37 <cfields> i can start a boost 32bit 1.46 build if it'd help
251 2014-08-05 09:08:10 <wumpus> michagogo: no (although it's nice if you do single-stepping a lot)
252 2014-08-05 09:08:52 <michagogo> gdb: unrecognized option '-run'
253 2014-08-05 09:08:52 <wumpus> cfields: I guess it could help a bit by making sure the problem is with boost
254 2014-08-05 09:09:38 <wumpus> ok, just do gdb -args src/bitcoind (arguments) , then type run
255 2014-08-05 09:09:48 <wumpus> I don't know the command-line option to automatically run
256 2014-08-05 09:10:29 <michagogo> looks like maybe "-ex run"
257 2014-08-05 09:11:01 <cfields> https://api.travis-ci.org/jobs/31692164/log.txt?deansi=true
258 2014-08-05 09:11:04 <cfields> eta ~30min
259 2014-08-05 09:11:12 <cfields> (just refresh)
260 2014-08-05 09:11:14 <cfields> nnite
261 2014-08-05 09:11:15 <michagogo> looks like what I want might be: gdb -ex run --args bitcoind --datadir=/home/micha/.bitcoin_main
262 2014-08-05 09:11:44 <michagogo> Looks like that did it
263 2014-08-05 09:12:04 <michagogo> Where do stdout/err go, btw?
264 2014-08-05 09:12:26 <sipa> where they would normally go
265 2014-08-05 09:13:06 <michagogo> The "Bitcoin server starting" isn't printing
266 2014-08-05 09:13:13 <michagogo> at least, not to that term
267 2014-08-05 09:13:19 <wumpus> it doesn't print that if you don't provide -daemon
268 2014-08-05 09:13:23 <wumpus> (which you don't want to in this case)
269 2014-08-05 09:13:24 <michagogo> ah
270 2014-08-05 09:13:25 <michagogo> d'oh
271 2014-08-05 09:13:42 <michagogo> I don't think I've ever run bitcoind with daemon=0
272 2014-08-05 09:13:55 <michagogo> Okay, so the command it right
273 2014-08-05 09:13:57 <michagogo> is*
274 2014-08-05 09:14:26 <michagogo> (gdb)
275 2014-08-05 09:14:26 <michagogo> [Inferior 1 (process 22067) exited normally]
276 2014-08-05 09:15:02 <michagogo> Does it not exit with bitcoind?
277 2014-08-05 09:15:44 <wumpus> sipa: replacing the return argument of CCoinsKeyHasher::operator() with size_t seems to have solved it...
278 2014-08-05 09:16:52 <cfields> wumpus: https://travis-ci.org/theuni/bitcoin/builds/31692597
279 2014-08-05 09:17:02 <cfields> there's a build with s/uint64_t/size_t/
280 2014-08-05 09:17:39 <cfields> to make sure it plays nice with the others as well, stupid windows especially...
281 2014-08-05 09:17:59 <wumpus> ok thanks
282 2014-08-05 09:18:57 <wumpus> I wonder why this wasn't caught by the pulltester -- it uses 32 bit and an ancient boost
283 2014-08-05 09:22:47 <michagogo> hm
284 2014-08-05 09:24:06 <michagogo> this command is working: $ gdb -ex "set debug timestamp on" -ex run --args bitcoind --datadir=/home/micha/.bitcoin_main
285 2014-08-05 09:24:14 <wumpus> E-Rage: can you try the patch posted in https://github.com/bitcoin/bitcoin/issues/4634?
286 2014-08-05 09:24:31 <michagogo> so is this one: screen -dmS mbitcoind gdb -ex "set debug timestamp on" -ex run --args bitcoind --datadir=/home/micha/.bitcoin_main
287 2014-08-05 09:24:51 <michagogo> But this isn't:
288 2014-08-05 09:25:46 <michagogo> oh
289 2014-08-05 09:25:48 <michagogo> ignore me
290 2014-08-05 09:25:55 <michagogo> I forgot to `source` my aliases file -_-
291 2014-08-05 09:28:44 <michagogo> Okay, switched to running in gdb now
292 2014-08-05 09:30:36 <michagogo> erm
293 2014-08-05 09:31:06 <michagogo> wumpus: it won't hurt to be running with commit d97a58f883c57da0507dde6dce9b8431f88e739c on a machine that is one of the seeds listed, will it? :P
294 2014-08-05 09:31:06 <wumpus> in an ideal world this would have returned a compile-time error that a function returning size_t is missing, but nooo c++ likes to randomly shoot you in the foot by doing *something*
295 2014-08-05 09:31:53 <wumpus> sometimes I deeply hate programming
296 2014-08-05 09:32:06 <sipa> wumpus: i can't even imagine any code that would work incorrectly as a result of this, but compile
297 2014-08-05 09:32:41 <sipa> any assignment size_t hash = hasher(key) should get a valid result in hash
298 2014-08-05 09:32:57 <sipa> it can't take a pointer of the result as it's a temporary
299 2014-08-05 09:33:11 <wumpus> sipa: probably some far-fetched template hack to detect something
300 2014-08-05 09:34:00 <sipa> the only thing i can imagine is using some template hack to to write [return type of hasher()] = hasher(key); and then using a pointer to that return value
301 2014-08-05 09:34:06 <sipa> and doing pointer arithmetic on it
302 2014-08-05 09:34:50 <wumpus> or type traits went horribly wrong, generating no code in the case that it doesn't match a size_t
303 2014-08-05 09:35:03 <wumpus> michagogo: huh?
304 2014-08-05 09:35:41 <michagogo> wumpus: the machine I'm working on hosts thfsmmn2jbitcoin.onion
305 2014-08-05 09:36:04 <michagogo> About to update it
306 2014-08-05 09:36:08 <wumpus> michagogo: oh, right, no, bitcoin actually detects connecting to itself
307 2014-08-05 09:36:30 <michagogo> (taking the node up 8b4616b..8d0d512)
308 2014-08-05 09:37:33 <wumpus> and unless you start with a node without peers.dat, *and* fail the dns seeds, it won't use the seeds at all
309 2014-08-05 09:38:32 <michagogo> hm, else if (nLoadWalletRet == DB_TOO_NEW)
310 2014-08-05 09:38:45 <michagogo> Does that trigger on a too-old BDB, as the name suggests?
311 2014-08-05 09:39:22 <wumpus> no
312 2014-08-05 09:39:30 <michagogo> okay, good
313 2014-08-05 09:39:40 <michagogo> (what does it mean?)
314 2014-08-05 09:39:42 <wumpus> only when the wallet itself is too new
315 2014-08-05 09:39:56 <michagogo> Ah, as in the wallet version number?
316 2014-08-05 09:40:01 <wumpus> wallets are versioned
317 2014-08-05 09:40:05 <michagogo> Okay, good
318 2014-08-05 09:40:07 <wumpus> yes
319 2014-08-05 09:40:56 <wumpus> bdb doesn't have anything like that, it's very variable what bdb will do if you open a db from a 'future' version
320 2014-08-05 09:41:22 <sipa> bdb database files also have a version number
321 2014-08-05 09:41:35 <sipa> and log files too, iirc
322 2014-08-05 09:43:20 <michagogo> hmm, was commit 1045452fa5f3475337b4dcab69e81e73ea430597 PR'd?
323 2014-08-05 09:43:38 <michagogo> It's annoying when there are merges with no PR number :-/
324 2014-08-05 09:43:41 <michagogo> ACTION looks at jgarzik
325 2014-08-05 09:44:07 <michagogo> GH changed the PR list again?
326 2014-08-05 09:45:01 <wumpus> michagogo: I remarked that already, he'll add the PR number on future merges
327 2014-08-05 09:45:47 <wumpus> sipa: but they don't have a consistent error when the database is incompatible, I've tried a few times and had different behavior
328 2014-08-05 09:48:04 <michagogo> hm, if I replace a binary and then make it exit
329 2014-08-05 09:48:26 <michagogo> Will entering `run` into gdb, will that run the new binary?
330 2014-08-05 09:48:37 <michagogo> Or does it re-run the now-removed bin?
331 2014-08-05 09:48:54 <michagogo> (do I need to quit and re-run gdb to update bitcoind?)
332 2014-08-05 09:49:01 <wumpus> I *think* it will load the new binary
333 2014-08-05 09:49:13 <michagogo> I guess I'll watch the log and we'll know that way
334 2014-08-05 09:49:26 <wumpus> doing a new 'run' throws away all of gdb's state
335 2014-08-05 09:49:51 <sipa> loading the binary happens before you execute run
336 2014-08-05 09:50:02 <sipa> so i'm not sure
337 2014-08-05 09:50:23 <wumpus> it may also get competely confused
338 2014-08-05 09:51:13 <jgarzik> michagogo, you can "run" as often as you like inside gdb
339 2014-08-05 09:51:17 <jgarzik> it will restart execution
340 2014-08-05 09:51:30 <jgarzik> I do that all the time, to avoid re-pasting "set args ....."
341 2014-08-05 09:52:02 <jgarzik> all state is thrown away, as you expect
342 2014-08-05 09:52:10 <sipa> but does it reload the binary?
343 2014-08-05 09:52:36 <jgarzik> sipa, no, the "file" command reloads the binary
344 2014-08-05 09:52:55 <michagogo> uh, looks like it does
345 2014-08-05 09:52:57 <michagogo> `/usr/local/bin/bitcoind' has changed; re-reading symbols.
346 2014-08-05 09:53:24 <michagogo> and debug.log shows 8d0d512
347 2014-08-05 09:53:33 <michagogo> rather than 8b4616b
348 2014-08-05 09:55:54 <michagogo> hm, I wonder if I can tell screen to send gdb a command without reattaching
349 2014-08-05 10:01:45 <wumpus> AFAIK yes, you can tell screen to send some keystrokes, altough if you really need to control gdb remotely the way would be gdbserver
350 2014-08-05 10:02:04 <michagogo> It's just so I can tell it to run when I update the bin
351 2014-08-05 10:04:54 <wumpus> it's also possible to script gdb to auto-rerun the executable if it exits normally
352 2014-08-05 10:06:42 <wumpus> (you'd need to attach an exit_handler)
353 2014-08-05 10:36:41 <michagogo> heh... if (nTime > nNow + 10*60) // came in a flying DeLorean
354 2014-08-05 10:53:22 <michagogo> Hm, I wish there was a way to rewind the blockchain and index
355 2014-08-05 10:53:35 <sipa> -reindex :p
356 2014-08-05 10:53:52 <michagogo> So I could go back and perhaps reprocess the block that (maybe?) made it crash
357 2014-08-05 10:54:31 <michagogo> Erm, maybe I should go back and check if there was actually a block then...
358 2014-08-05 10:55:45 <michagogo> 2014-08-04 11:37:55 UpdateTip: new best=00000000000000001004f5fdaa079dd8ca2c95c077fb2d87494ffb9de234cff1 height=313938 log2_work=80.035635 tx=43819630 date=2014-08-04 11:37:39 progress=0.999999
359 2014-08-05 10:55:55 <michagogo> last block it saw
360 2014-08-05 10:57:14 <michagogo> The next block was 3 minutes after the last log message
361 2014-08-05 10:57:19 <michagogo> Probably not a block, them
362 2014-08-05 10:57:22 <michagogo> then*
363 2014-08-05 10:57:27 <michagogo> I wonder what it was.
364 2014-08-05 15:08:28 <sonical> good morning, I am trying to ensure that I am running safe code, i have found my binary and signed hashes but I have no assurance that key 1FC730C1 is actually gavin's key
365 2014-08-05 15:08:41 <sonical> so, how do I prove that to myself?
366 2014-08-05 15:10:37 <iwilcox> Drop by for a cup of tea?
367 2014-08-05 15:10:40 <gavinandresen> sonical: Good question, how would you expect to be able to do that?
368 2014-08-05 15:11:42 <gavinandresen> (I'm curious to hear your answer, maybe you have a great idea for how to securely distribute the key we haven't thought of)
369 2014-08-05 15:13:21 <sonical> ha not really the infrastructure is too lacking.
370 2014-08-05 15:13:24 <sonical> all that comes to mind:
371 2014-08-05 15:13:49 <sonical> - gavinandresen, you could auth with gribble using that key
372 2014-08-05 15:13:58 <dsnrk> gavinandresen: the developers should get shirts made for public showings that have your GPG key in them :)
373 2014-08-05 15:14:08 <iwilcox> Ask the foundation to fund constant round-the-world flights for Gavin so he can attend every keysigning anywhere.
374 2014-08-05 15:14:09 <sonical> - other devs I'm familiar with like nanotube or sgornick could tell me 'i trust that's actually gavin'
375 2014-08-05 15:14:25 <gavinandresen> Mr. Google knows all about the 1FC730C1 key, do a search and you'll get lots of posts in different spots talking about it. That's probably about as good as you'll get
376 2014-08-05 15:14:46 <dsnrk> Proof Of Shirt would be fun though.
377 2014-08-05 15:14:49 <gavinandresen> ⦠assuming you use https to access google and assume an attacker hasn't managed to MITM your web browser or root cert store....
378 2014-08-05 15:15:39 <gavinandresen> ⦠so if you were super paranoid you'd do the search on a different computer in a physically separate location and compare results.
379 2014-08-05 15:16:04 <dsnrk> well that's just it, you can't photoshop all the photos of developers in shirts on the interwebs.
380 2014-08-05 15:16:05 <sonical> exactly lol, there is no out of band to the NSA :)
381 2014-08-05 15:16:29 <gavinandresen> You could call me on the phone, but that's not scalable. So don't do that, please.
382 2014-08-05 15:17:26 <gavinandresen> Anyway, if you're really and truly paranoid you should be using a multisig wallet so even if you're copy of bitcoin core is unsafe your coins are still safe.
383 2014-08-05 15:17:51 <wumpus> if you check the git repository, the commits are signed by many of the same people that signed gavin's key
384 2014-08-05 15:18:25 <dsnrk> gavinandresen: eh, given the little mishap in copay.io I wouldn't suggest anybody runs off and uses a third party wallet.
385 2014-08-05 15:19:06 <wumpus> if you believe the commits in the git repository are fake too, well, it may be better to not trust anything important to computers in your life
386 2014-08-05 15:19:18 <sonical> ahh wumpus that sounds like a step i'm missing
387 2014-08-05 15:19:18 <wumpus> as everything could be a lie
388 2014-08-05 15:19:26 <iwilcox> If builds are fully deterministic, isn't a better approach to get people fewer trust hops away to reproduce the build?
389 2014-08-05 15:19:35 <sonical> how do I view the sigs on gavin's key, and where do I see the sigs on the git commits?
390 2014-08-05 15:19:47 <wumpus> iwilcox: that's what gitian does?
391 2014-08-05 15:20:04 <wumpus> sonical: gpg --list-sigs 1FC730C1
392 2014-08-05 15:20:07 <iwilcox> wumpus: RIght, but you don't see folks offering up their own signed copies.
393 2014-08-05 15:20:15 <sonical> thanks wumpus
394 2014-08-05 15:20:56 <wumpus> and "git log --show-signature"
395 2014-08-05 15:21:33 <wumpus> output of gitian has been signed by at least three people for every release, the signatures can be found here: https://github.com/bitcoin/gitian.sigs
396 2014-08-05 15:22:24 <wumpus> (note that the commits in that repository are not usually signed, as the information that is committed already consists of signatures)
397 2014-08-05 15:22:33 <iwilcox> Presumably those being folks who are one hop from Gavin?
398 2014-08-05 15:23:28 <wumpus> iwilcox: I suppose so?
399 2014-08-05 15:23:38 <wumpus> it's all a pretty small world
400 2014-08-05 15:27:35 <jintelletec> hi guys.. anyone looking or would work for an exchange in hong kong and/or know anyone with ruby experience?
401 2014-08-05 15:28:31 <Belxjander> jintelletec: axn?
402 2014-08-05 15:28:46 <iwilcox> wumpus: Just thinking along the lines of: if you can't get trust paths to the primary signers out into the world effectively enough, perhaps get the binary out and encourage more well-connected people to reproduce and sign themselves.
403 2014-08-05 15:39:18 <sonical> cool I am satisfied that my binary is legit. Do i need to rename bootstrap.dat or just put it in my directory next to my wallet.dat
404 2014-08-05 15:39:23 <sonical> and do I need to do that before first run
405 2014-08-05 15:43:04 <sonical> i actually can't find my "Bitcoin Core data directory" to put bootstrap.dat before first run. i think it's in appdata somewhere on windows?
406 2014-08-05 15:57:55 <sipa> sonical: https://en.bitcoin.it/wiki/Data_directory
407 2014-08-05 16:01:24 <sonical> yep, found it, created it manually before first run and it's reading the bootstrap.dat file successfully
408 2014-08-05 16:05:32 <cfields> wumpus: around?
409 2014-08-05 16:12:40 <sonical> thx for the help wumpus sipa gavinandresen
410 2014-08-05 16:12:53 <sonical> and the shirts with the signing key fingerprint are a great idea
411 2014-08-05 16:19:22 <dsnrk> (I agree)
412 2014-08-05 19:05:26 <rdbell> Does anyone have a refrence or examples for node-libcoin usage? Particularly for interfacing with bitcoind over RPC.
413 2014-08-05 19:26:12 <rdbell> @jgarzik Why is node-libcoin giving me RPC error "connect ECONNREFUSED" when I try to use RPC commands? node-bitcoin works fine. Same credentials & port. Any idea?
414 2014-08-05 19:27:18 <rdbell> I wanted to try out libcoin after seeing your comments in this Reddit thread: http://www.reddit.com/r/Bitcoin/comments/1jvzik/nodebitcoin/
415 2014-08-05 19:40:00 <jgarzik> rdbell, That morphed into http://blog.bitpay.com/2014/02/14/introducing-bitcore.html / https://github.com/bitpay/bitcore
416 2014-08-05 19:40:34 <rdbell> @jgarzik Thanks, I'll take a look.
417 2014-08-05 20:36:47 <michagogo> Good news!
418 2014-08-05 20:37:07 <michagogo> I think we might be about 1 week away from removing bitcoind from Ubuntu 12.04 LTS
419 2014-08-05 20:38:10 <michagogo> (it's still in 12.10, 13.04, and 13.10, but those versions are EOL and can't/won't be touched at this point :-( but the Ubuntu stance is that nobody should be using them anyway...)
420 2014-08-05 20:39:21 <michagogo> (and for the unaware, back in October last year (IIRC) it was removed from the still-unreleased (and now current) 14.04 LTS and blacklisted from being automatically pulled in from Debian going forward)
421 2014-08-05 20:40:31 <Luke-Jr> I guess that's better than nothing. :p
422 2014-08-05 20:40:58 <Luke-Jr> "good news" to me would be more like "Debian and Ubuntu have committed to keep their packages maintained properly for the distro lifetime"
423 2014-08-05 20:41:00 <Luke-Jr> :p
424 2014-08-05 20:41:08 <michagogo> Luke-Jr: well, it's in Debian unstable
425 2014-08-05 20:42:02 <michagogo> With maintainers that are aware of the unique challenges in packaging a full node, and so keep it only in unstable where it can be kept up-to-date
426 2014-08-05 20:42:56 <michagogo> Unfortunately, Ubuntu automatically pulls in packages from Debian unstable...
427 2014-08-05 20:43:36 <Luke-Jr> >_<
428 2014-08-05 20:43:54 <Luke-Jr> michagogo: are the packages at least bundling LevelDB now?
429 2014-08-05 20:44:05 <michagogo> Luke-Jr: idk
430 2014-08-05 20:44:11 <michagogo> ;;google debian bitcoin package
431 2014-08-05 20:44:12 <gribble> Debian -- Details of source package bitcoin in sid: <https://packages.debian.org/source/sid/bitcoin>; Debian Package Tracking System - bitcoin: <https://packages.qa.debian.org/b/bitcoin.html>; Debian -- Details of package bitcoin-qt in sid: <https://packages.debian.org/unstable/main/bitcoin-qt>
432 2014-08-05 20:44:13 <michagogo> Luke-Jr: ^
433 2014-08-05 20:44:40 <michagogo> Looks like it's not in the deps, so I guess so
434 2014-08-05 20:50:02 <sipa> pigeons: p2sh standardness rules were relaxed
435 2014-08-05 20:50:42 <pigeons> thats cool
436 2014-08-05 21:23:12 <the8thbit> hash that original miner found. This is made even more difficult as the block ages, as you would need to provide hashes like this not just for the target block, but for every block which comes after it
437 2014-08-05 21:23:12 <the8thbit> Hello, I'm writing an article about bitcoin, and I'd like to know if my understanding of blockchain security is correct. Basically, as I understand, even for a new block, the cost of double spending in one block is much larger than the cost of mining one block because the miner can solve for one of a set of hashes which produce a particular pattern (a substring of repeating zeros) while the attacker must now solve for the exact
438 2014-08-05 21:30:28 <the8thbit> hm, perhaps I should ask this in #bitcoin instead?
439 2014-08-05 22:04:42 <cfields> anyone around who uses bitcoin-qt set to non-english?
440 2014-08-05 22:05:26 <cfields> michagogo: ^^ maybe?
441 2014-08-05 22:06:01 <michagogo> evil-the8thbit: 1. Yes, #bitcoin is the right place, not here 2. "while the attacker must now solve for the exact hash that original miner found." <-- No, this is completely impossible. If you can solve for an exact hash before the universe dies, you've broken Bitcoin (and many other things!)
442 2014-08-05 22:06:05 <michagogo> cfields: nope, sorry
443 2014-08-05 22:06:09 <michagogo> Why?
444 2014-08-05 22:06:35 <cfields> michagogo: we grab qtbase translation files for packaging, for the base strings that we don't translate ourselves
445 2014-08-05 22:06:40 <cfields> they're a pain in the ass to deal with
446 2014-08-05 22:07:05 <cfields> i'm looking at it running now (in spanish) and everything seems to be translated, even without those base translations
447 2014-08-05 22:07:13 <cfields> i'm looking for an example of one that's missing
448 2014-08-05 22:07:56 <michagogo> (despite being Israeli, my parents are from NY and CA [technically I immigrated with them at the age of a few months], and we only speak English in the house [my cousins can't get a single sentence out in one language, it's a mix of English and Hebrew, and my parents swore I wouldn't turn out the same way], so I consider it my native (and preferred)
449 2014-08-05 22:07:56 <michagogo> language)
450 2014-08-05 22:08:26 <michagogo> cfields: how about you switch it to e.g. Hebrew and go through the UI looking for latin letters :P
451 2014-08-05 22:08:42 <michagogo> (if you mean what I think you mean?)
452 2014-08-05 22:09:00 <cfields> michagogo: heh, that's what i'm doing now in spanish. I expected things like ok/cancel to not be translated, but they are
453 2014-08-05 22:09:24 <cfields> was hoping someone familiar with the pains of running non-english software might give me an idea of something to look for
454 2014-08-05 22:09:38 <michagogo> cfields: characters in a differen charset :P
455 2014-08-05 22:09:42 <michagogo> different*
456 2014-08-05 22:09:57 <cfields> oh
457 2014-08-05 22:10:16 <cfields> mm, good thinking i guess
458 2014-08-05 22:10:20 <michagogo> Do we use the strings "ok" and "cancel" or do we tell Qt "put an OK button and a cancel button here"?
459 2014-08-05 22:10:40 <michagogo> If the latter, not too surprising that it's right
460 2014-08-05 22:10:48 <michagogo> Anyway, it's 1:10 AM here... goodnight.
461 2014-08-05 22:10:53 <cfields> unsure. i assumed in something like a modal, ok/cancel would be auto
462 2014-08-05 22:10:55 <cfields> nnite
463 2014-08-05 22:16:12 <michagogo> What's nice about using e.g. Hebrew or CJK is that it's easy to spot untranslated words or phrases
464 2014-08-05 22:16:40 <cfields> yea, finally did that
465 2014-08-05 22:16:42 <cfields> think i got one
466 2014-08-05 22:17:41 <cfields> encrypt-wallet's ok/cancel aren't translated
467 2014-08-05 22:41:03 <rdbell> What's the current testnet blockchain size?