1 2014-06-11 01:01:05 <maaku> Luke-Jr: is there an updated version of your namecoin_mmm branch?
2 2014-06-11 01:01:43 <maaku> (the merged-mine-proxy setworkaux changes to bitcoind)
3 2014-06-11 01:18:05 <Luke-Jr> maaku: nope, that branch is only for the merged-mine-proxy changes
4 2014-06-11 01:18:18 <Luke-Jr> maaku: I don't advise using Namecoin merged mining code
5 2014-06-11 01:25:07 <maaku> Luke-Jr: I'm helping someone merge-mine nmc under frc as the parent chain
6 2014-06-11 01:25:15 <maaku> that seemed like the shortest path
7 2014-06-11 01:25:26 <maaku> i can't seem to find any open-source stratum merged mining code
8 2014-06-11 01:25:36 <Luke-Jr> maaku: ah
9 2014-06-11 01:25:41 <Luke-Jr> maaku: Eloipool works :x
10 2014-06-11 01:25:56 <maaku> yeah i recommended that before
11 2014-06-11 01:26:02 <maaku> he's currently locked in to stratum though
12 2014-06-11 01:26:16 <Luke-Jr> Eloipool supports stratum
13 2014-06-11 01:26:59 <maaku> but if i understand it correctly, running merged-mine-proxy even with nothing connecting to it will still stuff the right strings in the coinbase for nmc merged mining
14 2014-06-11 01:27:13 <maaku> but i'll recommend eloipool again
15 2014-06-11 01:27:45 <Luke-Jr> original merged-mine-proxy is a proxy for getwork (only)
16 2014-06-11 01:27:56 <Luke-Jr> namecoin_mmm's version is a servant to Eloipool (only?)
17 2014-06-11 01:29:36 <maaku> well it calls setworkaux right? so GBT should be reporting the right coinbase strings
18 2014-06-11 01:39:49 <phantomcircuit> sipa,
19 2014-06-11 01:39:51 <phantomcircuit> 2014-06-11 01:38:46 UpdateTip: new best=000000000000000130e2511334192fde76160a7c3cd7b8e778998d3ccff66023 height=279260 log2_work=75.526096 tx=30633257 date=2014-01-08 06:52:26 progress=0.401639
20 2014-06-11 01:39:54 <phantomcircuit> 2014-06-11 01:40:13 UpdateTip: new best=000000000000000004aac0994b88098da28d334c571739347abe9209df027655 height=279261 log2_work=75.526258 tx=30633780 date=2014-01-08 07:10:43 progress=0.401677
21 2014-06-11 01:39:57 <phantomcircuit> lold
22 2014-06-11 01:39:59 <phantomcircuit> no wonder nobody does this
23 2014-06-11 01:40:03 <phantomcircuit> it's incredibly annoying
24 2014-06-11 02:04:20 <phantomcircuit> 2014-06-11 02:06:58 UpdateTip: new best=0000000000000001e639baadef26e23070faa456ac6f2e03ce522615a3b6a5aa height=279294 log2_work=75.531579 tx=30643793 date=2014-01-08 11:45:54 progress=0.402336
25 2014-06-11 02:04:21 <phantomcircuit> it
26 2014-06-11 02:04:25 <phantomcircuit> it's painful
27 2014-06-11 02:13:20 <Luke-Jr> phantomcircuit: aren't they running a stratum proxy too?
28 2014-06-11 02:13:29 <Luke-Jr> slush's proxy is a major CPU hog
29 2014-06-11 02:13:54 <phantomcircuit> Luke-Jr, the bitfury guys?
30 2014-06-11 02:14:16 <phantomcircuit> no they wrote a stratum proxy into their mining client
31 2014-06-11 02:14:27 <phantomcircuit> which is basically how cgminer/bfgminer work also
32 2014-06-11 02:14:42 <phantomcircuit> except that theirs feels a lot more hacked on
33 2014-06-11 05:17:17 <grunz> guys, how do I see how many blocks are left for synchonization in bitcoin-cli. what is the command?
34 2014-06-11 05:18:55 <gjs278> grunz: bitcoind getinfo
35 2014-06-11 05:19:01 <gjs278> "blocks" : 305204,
36 2014-06-11 05:19:05 <gjs278> subtract from that
37 2014-06-11 05:19:58 <grunz> i am in testnet
38 2014-06-11 05:20:07 <grunz> how do I know how many is max?
39 2014-06-11 05:20:17 <grunz> at this right moment
40 2014-06-11 05:20:51 <maaku> blockchain.info
41 2014-06-11 05:20:52 <kadoban> grunz: I think there's some peer info command isn't there? That should give you a good guess.
42 2014-06-11 05:21:10 <maaku> or tail -f $APPDIR/debug.log
43 2014-06-11 05:21:15 <gmaxwell> peers can and do return random crap. You haven't said why you want to know.
44 2014-06-11 05:21:25 <maaku> and grep for version messages
45 2014-06-11 05:22:41 <maaku> (current is 261921 btw)
46 2014-06-11 05:29:33 <grunz> does anyone has setup insight.is locally with testnet? do you know which db should I put in ~/.insight/testnet ? how do i generate/create it?
47 2014-06-11 06:40:16 <michagogo> Luke-Jr: :-/
48 2014-06-11 06:40:22 <michagogo> What's your gitian setup?
49 2014-06-11 06:40:34 <Luke-Jr> michagogo: KVM, old install
50 2014-06-11 06:40:35 <michagogo> And are you using clean VMs?
51 2014-06-11 06:40:54 <Luke-Jr> no
52 2014-06-11 06:40:59 <Luke-Jr> shouldn't need to?
53 2014-06-11 06:41:07 <michagogo> (As opposed to stuffing all kinds of extra packages in there like Gavin)
54 2014-06-11 06:41:19 <Luke-Jr> oh
55 2014-06-11 06:41:21 <Luke-Jr> yeah
56 2014-06-11 06:41:24 <michagogo> I mean for the gitian base vm
57 2014-06-11 06:41:29 <Luke-Jr> just old ;)
58 2014-06-11 06:41:48 <michagogo> Luke-Jr: what do the base manifests look like?
59 2014-06-11 06:41:57 <Luke-Jr> ?
60 2014-06-11 06:42:00 <michagogo> I mean, are they like ours?
61 2014-06-11 06:42:04 <Luke-Jr> what?
62 2014-06-11 06:42:14 <michagogo> (Are ours like each other, actually?)
63 2014-06-11 06:42:31 <michagogo> Luke-Jr: the gsigs include manifests of the VM
64 2014-06-11 06:42:39 <Luke-Jr> oh
65 2014-06-11 06:42:45 <michagogo> What packages are there, etc
66 2014-06-11 06:42:47 <Luke-Jr> hard to compare since you guys use some new YAML format
67 2014-06-11 06:42:49 <Luke-Jr> :x
68 2014-06-11 06:42:54 <michagogo> You guys?
69 2014-06-11 06:43:05 <michagogo> I know wumpus does, I don't think I do
70 2014-06-11 06:43:08 <Luke-Jr> oh
71 2014-06-11 06:43:12 <Luke-Jr> maybe I didn't see yours yet
72 2014-06-11 06:43:25 <michagogo> (Also, you could just read them in and rewrite them :-P )
73 2014-06-11 06:44:03 <michagogo> But yeah, I build with a precise host -- I think wumpus builds on something newer, and ruby changed their YAML writing or something likethat
74 2014-06-11 06:44:13 <wumpus> best is to read them in with a YAML parser than compare the outputs manifest in the data structure
75 2014-06-11 06:45:14 <Luke-Jr> not sure I have a YAML parser :o
76 2014-06-11 06:46:07 <michagogo> Of course you do
77 2014-06-11 06:46:21 <michagogo> Otherwise you couldn't run gitian :P
78 2014-06-11 06:46:27 <Luke-Jr> I mean human-usable :p
79 2014-06-11 06:46:37 <michagogo> Ruby is human-usable
80 2014-06-11 06:46:49 <michagogo> And I'm sure python etc can do it too
81 2014-06-11 06:46:51 <Luke-Jr> I would uninstall it if I could.
82 2014-06-11 06:49:49 <wumpus> well you can always use gverify that comes with gitian
83 2014-06-11 06:50:23 <wumpus> though it should be more verbose on MISMATCH (as in, what files mismatch...)
84 2014-06-11 06:51:11 <wumpus> bleh I'm getting michagogo and laanwj: OK and gavinandresen and luke-jr: MISMATCH
85 2014-06-11 06:51:26 <Luke-Jr> do Gavin and me match each other?
86 2014-06-11 06:51:40 <Luke-Jr> or not even that?
87 2014-06-11 06:52:05 <wumpus> not even that; curiously, the bitcoin-cli's match but not the rest
88 2014-06-11 06:53:26 <wumpus> ugh manually comparing gavin's and my assert file it looks like everything is the same
89 2014-06-11 06:53:37 <wumpus> gverify is bullshitting?
90 2014-06-11 06:54:07 <Belxjander> is it 100% the same on the byte level?
91 2014-06-11 06:54:17 <Belxjander> is it whitespaced differenced?
92 2014-06-11 06:54:23 <wumpus> luke-jr is the odd duck out
93 2014-06-11 06:54:29 <Luke-Jr> :<
94 2014-06-11 06:54:33 <wumpus> Belxjander: that shouldn't matter, it doesn't compare at the byte level
95 2014-06-11 06:54:43 <Luke-Jr> wumpus: can you SHA256 your deps inputs?
96 2014-06-11 06:54:45 <wumpus> ...at least it shouldn't
97 2014-06-11 06:54:47 <Luke-Jr> or are those not meant to match?
98 2014-06-11 06:54:57 <wumpus> Luke-Jr: they're in doc/release-notes.md
99 2014-06-11 06:56:18 <wumpus> anyhow, need to verify why gverify is this strange
100 2014-06-11 06:58:01 <wumpus> oh.. it compares against the previous manifest every time :-)
101 2014-06-11 06:58:22 <wumpus> so if one doesn't match, you get two mismatches
102 2014-06-11 07:01:01 <Luke-Jr> <.<
103 2014-06-11 07:04:06 <wumpus> I'm surprised every time how easy ruby is, I don't know anything about it but I tend to get changes right the first time just by guessing
104 2014-06-11 07:10:45 <Luke-Jr> wumpus: you mean release-process.md
105 2014-06-11 07:11:25 <Luke-Jr> linux deps mismatch
106 2014-06-11 07:11:40 <Luke-Jr> linux boost mismatch
107 2014-06-11 07:11:53 <Luke-Jr> linux qt mismatch
108 2014-06-11 07:12:19 <Luke-Jr> win boost mismatch
109 2014-06-11 07:12:53 <Luke-Jr> heck, they're ALL mismatched
110 2014-06-11 07:13:38 <wumpus> Luke-Jr: yes, it's weird, somehow only the bitcoin-cli matches, so all other deps are messed up? :)
111 2014-06-11 07:13:44 <Luke-Jr> yep
112 2014-06-11 07:14:53 <Luke-Jr> maybe that LANG thing affects it?
113 2014-06-11 07:15:09 <Luke-Jr> ACTION rebuilds deps-linux to find out
114 2014-06-11 07:15:12 <Luke-Jr> (with the new gitian)
115 2014-06-11 07:15:23 <wumpus> Luke-Jr: could be, though I didn't rebuild all deps after the LANG thing either
116 2014-06-11 07:15:33 <wumpus> Luke-Jr: but if you run with a non-default locale that'd may do it
117 2014-06-11 07:15:39 <Luke-Jr> define default :p
118 2014-06-11 07:15:49 <Luke-Jr> my OS tells me I must pick a locale
119 2014-06-11 07:15:58 <wumpus> one that sorts strings differently from american english :)
120 2014-06-11 07:16:29 <wumpus> anyhow it's worth a try
121 2014-06-11 07:16:46 <Luke-Jr> I have LANG=en_GB.utf8 LC_COLLATE=C
122 2014-06-11 07:17:00 <Luke-Jr> IMO it's a bad idea to be using LC_COLLATE=en_US.utf8 <.<
123 2014-06-11 07:17:12 <Luke-Jr> I think only "C" is well-defined
124 2014-06-11 07:17:34 <Luke-Jr> build logs have warnings now ../libtool: line 1124: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
125 2014-06-11 07:17:52 <Luke-Jr> whose idea was it to use an invalid locale? <.<
126 2014-06-11 07:18:02 <Luke-Jr> hm
127 2014-06-11 07:18:06 <Luke-Jr> or is mine invalid? :D
128 2014-06-11 07:18:52 <wumpus> WHOA
129 2014-06-11 07:19:02 <Luke-Jr> strange that eselect lists "utf8" forms instead of "UTF-8"
130 2014-06-11 07:19:10 <Luke-Jr> wumpus: ?
131 2014-06-11 07:19:21 <wumpus> no, it's valid, mine is at LANG=en_US.UTF-8
132 2014-06-11 07:19:36 <michagogo> Luke-Jr: inputs are also in the gsigs
133 2014-06-11 07:21:03 <Luke-Jr> no change, still the same as last run
134 2014-06-11 07:21:28 <wumpus> Luke-Jr: I don't understand how en_US.UTF-8 can be invalid, at least in the guest machine (you may not have installed it on your host ofc)
135 2014-06-11 07:21:29 <Luke-Jr> ACTION boots the base to see if he can add that locale
136 2014-06-11 07:21:55 <Luke-Jr> crap, what's the root pw? <.<
137 2014-06-11 07:22:06 <wumpus> so make-base-vm also can install with different locales installed *headache*
138 2014-06-11 07:22:21 <michagogo> Luke-Jr: sudo?
139 2014-06-11 07:22:30 <Luke-Jr> or user pw..
140 2014-06-11 07:22:30 <wumpus> and if so, what does it base it on :/
141 2014-06-11 07:22:34 <michagogo> Try ubuntu
142 2014-06-11 07:24:21 <michagogo> Luke-Jr: do you know about on-target?
143 2014-06-11 07:24:35 <Luke-Jr> yes
144 2014-06-11 07:24:43 <Luke-Jr> confirmed only en_GB.UTF-8 is installed
145 2014-06-11 07:24:45 <Luke-Jr> on VM
146 2014-06-11 07:24:54 <Luke-Jr> /etc/locale.gen does not exist tho :/
147 2014-06-11 07:24:54 <michagogo> Oh, right -- that uses pubkey
148 2014-06-11 07:25:09 <michagogo> And still need pw for sudo, unless it changed that
149 2014-06-11 07:25:28 <michagogo> Oh, though you can on-target as root I think
150 2014-06-11 07:26:00 <Luke-Jr> yeah
151 2014-06-11 07:26:04 <Luke-Jr> but this is easier
152 2014-06-11 07:26:26 <michagogo> Did you get the pw?
153 2014-06-11 07:26:40 <Luke-Jr> ubuntu :P
154 2014-06-11 07:26:46 <michagogo> Ah
155 2014-06-11 07:27:04 <Luke-Jr> argh
156 2014-06-11 07:27:11 <Luke-Jr> can't figure out how to build the en_US.UTF-8 locale
157 2014-06-11 07:27:55 <aschildbach> I have posted a teaser for the upcoming "sweep paper wallet" feature in Bitcoin Wallet: https://plus.google.com/101256420499771441772/posts/9kpmHY1QTu9 -- feel free to comment!
158 2014-06-11 07:28:14 <Luke-Jr> got it https://help.ubuntu.com/community/Locale
159 2014-06-11 07:28:22 <Luke-Jr> var/lib/locales/supported.d
160 2014-06-11 07:28:41 <Luke-Jr> aschildbach: a paper wallet is HD
161 2014-06-11 07:28:50 <Jouke> aschildbach: awesome :D
162 2014-06-11 07:29:29 <wumpus> Luke-Jr: maybe rebuild the images with LC_ALL/LANG set
163 2014-06-11 07:29:34 <aschildbach> Luke-Jr: How do you mean? None of those I've collected have more than one key.
164 2014-06-11 07:29:34 <Jouke> I wouldn't use it myself, but I know that a lot of people are asking for this feature :).
165 2014-06-11 07:29:42 <Luke-Jr> aschildbach: then they're not paper wallets
166 2014-06-11 07:30:23 <Luke-Jr> wumpus: hm, protobuf isn't seperate for linux/mac? :/
167 2014-06-11 07:30:38 <wumpus> Luke-Jr: no, just part of the deps
168 2014-06-11 07:31:07 <aschildbach> Who is defining the term "paper wallet"? A quick Google reveals "Paper wallets are generally created by printing a brand new public address and private key onto paper..."
169 2014-06-11 07:32:07 <Jouke> aschildbach: everyone knows what you mean by paper wallet :)
170 2014-06-11 07:32:11 <Luke-Jr> aschildbach: can't be a paper *wallet*, if it isn't usable as a wallet.
171 2014-06-11 07:32:19 <aschildbach> Jouke: Yes, indeed. Actually people are asking for importing keys, but I guess they will be ok with sweeping instead.
172 2014-06-11 07:32:41 <Luke-Jr> wumpus: match on deps-linux
173 2014-06-11 07:33:07 <Luke-Jr> wumpus: thoughts on moving the ymls to subdirectories per OS? <.<
174 2014-06-11 07:33:19 <aschildbach> Luke-Jr: Ok I understand the argument.
175 2014-06-11 07:33:48 <dsnrk> aschildbach: (it's also madness to let user manage keys)
176 2014-06-11 07:34:36 <wumpus> this makes gverify much more useful: https://github.com/devrandom/gitian-builder/pull/58
177 2014-06-11 07:38:38 <Luke-Jr> wumpus: does anything use non-precise anymore?
178 2014-06-11 07:38:51 <wumpus> Luke-Jr: no
179 2014-06-11 07:45:45 <wumpus> Luke-Jr: unless you plan on building old releases of course
180 2014-06-11 07:46:11 <Luke-Jr> well, old releases didn't have this problem anyway
181 2014-06-11 07:54:57 <Luke-Jr> wumpus: qt still mismatches
182 2014-06-11 07:55:10 <Luke-Jr> but let's see if it mattersâ¦
183 2014-06-11 07:59:17 <Luke-Jr> whee, it's the season of "hey, your PGP key expired" reports long after I update it <.<
184 2014-06-11 08:06:01 <Hasimir> Luke-Jr, such reports always come from those who never run: gpg --refresh-keys
185 2014-06-11 08:07:30 <Luke-Jr> hopefully posting about it to the BFGMiner thread will quench some
186 2014-06-11 08:10:53 <Luke-Jr> wumpus: match on linux!
187 2014-06-11 08:11:01 <wumpus> Luke-Jr: woohoo!
188 2014-06-11 08:11:31 <Luke-Jr> time to rebuild windows
189 2014-06-11 08:11:37 <Luke-Jr> then I'll maybe try mac
190 2014-06-11 08:18:50 <gdm85> Luke-Jr, wumpus: I saw the comment, it means that VMs generated before the patch have the issue or that make-base-vm needs to be patched too?
191 2014-06-11 08:19:34 <Luke-Jr> gdm85: both
192 2014-06-11 08:19:47 <wumpus> gdm85: I'm not sure what the solution is, I just signalled the problem :) I do think though that the same environment normalization has to be done at the beginning of make-base-vm, and that people that get 'wrong' outputs need to re-generate their images with that
193 2014-06-11 08:21:16 <Luke-Jr> easier to edit the images <.<
194 2014-06-11 08:21:35 <wumpus> not really easier
195 2014-06-11 08:21:40 <Hasimir> I assume this is some problem with virtualbox?
196 2014-06-11 08:21:54 <Luke-Jr> wumpus: faster*
197 2014-06-11 08:22:02 <Luke-Jr> Hasimir: I use KVM, not VBox
198 2014-06-11 08:22:11 <Hasimir> ok
199 2014-06-11 08:22:12 <wumpus> and easier to mess up, I prefer the 'nuke from orbit solution', but sure, if you know what you're doing :)
200 2014-06-11 08:22:15 <Luke-Jr> anyhow, I'm getting to bed.. sorry, tired and gotta be up soon x.x
201 2014-06-11 08:22:32 <Hasimir> 'night ...
202 2014-06-11 08:22:51 <Luke-Jr> (this morning I woke after ~2 hrs of sleep to my 6 year old with a big gash in his forehead, sigh)
203 2014-06-11 08:22:53 <wumpus> night
204 2014-06-11 08:42:13 <SomeoneWeird> Luke-Jr: you have a kid? hah
205 2014-06-11 09:01:40 <gdm85> wumpus: yeah, the necessity of changing also make-base-vm was part of my original request, but I forgot it along the way.. I will try to come up with a patch for make-base-vm too
206 2014-06-11 09:02:35 <gdm85> BlueMattBot contacts me with PMs about its bugs? :s
207 2014-06-11 09:09:32 <gdm85> Luke-Jr: can you confirm that the locale problem makes mismatching hashes? or it was due to other reasons?
208 2014-06-11 09:10:40 <Hasimir> gdm85, he's gone to bed, you'll have to leave a msg for him
209 2014-06-11 09:10:48 <gdm85> Hasimir: ah, ok. thanks
210 2014-06-11 09:11:23 <Hasimir> or email ...
211 2014-06-11 09:12:05 <gdm85> wumpus: the normalization is not done in make-base-vm, that would be changing host. in gbuild normalization is done in the VM-executed script. right now I first would need to verify that it's not a red herring e.g. the patch we merged is breaking stuff
212 2014-06-11 09:12:55 <wumpus> gdm85: well the thing is that luke-jr somehow has a guest vm with en_GB locale only, so *somehow* the host locale leaked into the installtion of the guest image
213 2014-06-11 09:13:07 <wumpus> gdm85: pretty sure that's not a red herring :)
214 2014-06-11 09:13:19 <gdm85> wumpus: what do you mean by host locale?
215 2014-06-11 09:13:32 <wumpus> the locale setting of the host
216 2014-06-11 09:13:49 <wumpus> ie, the environment that creates the image
217 2014-06-11 09:13:59 <gdm85> wumpus: en_US.UTF-8 is not coming from the host, it's injected in the VM environment on purpose
218 2014-06-11 09:14:21 <wumpus> gdm85: ... I know that, what i mean, is that the VM image he was using was invalid
219 2014-06-11 09:14:40 <wumpus> somehow if you have a different locale and do create-base-vm, you get a different base vm image
220 2014-06-11 09:14:45 <wumpus> that's wrong
221 2014-06-11 09:14:51 <gdm85> oh, I get it now
222 2014-06-11 09:15:15 <gdm85> some LC_* or LANG coming from its environment, but we have not mentioned what either here or on the github issues
223 2014-06-11 09:15:55 <gdm85> so the override when gbuild'ing seems like not enough if the VM was built with leaked locales
224 2014-06-11 09:16:20 <gdm85> I can test this scenario quite easily
225 2014-06-11 09:18:46 <wumpus> gdm85: exactly, because the en_US locale may not even be present
226 2014-06-11 09:19:19 <gdm85> wumpus: if it's not present it should pick 'C', that might by luck give out good builds
227 2014-06-11 09:19:34 <gdm85> I commented here: https://github.com/devrandom/gitian-builder/pull/57#issuecomment-45719439
228 2014-06-11 09:20:00 <wumpus> maybe... but I'd *still* make sure that the make-base-vm output doesn't depend on the host system's locale, it excludes a potential source of pain later
229 2014-06-11 09:20:07 <gdm85> sure
230 2014-06-11 09:20:24 <gdm85> perhaps we should go with en_GB.UTF-8?
231 2014-06-11 09:20:46 <wumpus> using the C locale makes sense though
232 2014-06-11 09:20:48 <wumpus> gdm85: why?
233 2014-06-11 09:21:02 <gdm85> wumpus: laziness, because it comes preinstalled and doesn't require locales changes
234 2014-06-11 09:21:26 <wumpus> gdm85: why would en_GB always come preinstalled?
235 2014-06-11 09:21:49 <gdm85> wumpus: because Luke-Jr confirmed it's there and I assume he didn't install it manually nor gitian-builder/vmbuilder do?
236 2014-06-11 09:22:12 <wumpus> sigh
237 2014-06-11 09:22:17 <gdm85> I am just thinking that it might be the one that ships by default on Trusty
238 2014-06-11 09:22:22 <wumpus> he uses en_GB on his host, that's why it leaked in
239 2014-06-11 09:22:46 <gdm85> ok, but I didn't read this anywhere..sorry
240 2014-06-11 09:22:52 <gdm85> <Luke-Jr> confirmed only en_GB.UTF-8 is installed
241 2014-06-11 09:23:02 <wumpus> if he used fa_IR, that'd be the only locale on the image
242 2014-06-11 09:23:27 <gdm85> sure, this snippet was misleading me: https://github.com/devrandom/gitian-builder/pull/57#issuecomment-45709910
243 2014-06-11 09:23:54 <gdm85> so for some reason the vmbuilder is installing the locale of host? weird
244 2014-06-11 09:23:54 <wumpus> he's only saying what is the case on his machine, that doesn't make it general law :P (he'd wish)
245 2014-06-11 09:24:27 <gdm85> anyway, the `LC_ALL=en_US.UTF-8 LANG=en_US.UTF-8 vmbuilder ...` will fix what he experienced
246 2014-06-11 09:24:39 <gdm85> e.g. installing the leaked locales on VM by default
247 2014-06-11 09:25:07 <wumpus> gdm85: yes I'm fairly sure that would fix it
248 2014-06-11 09:25:16 <gdm85> I am going to test what happens, possibly results this afternoon
249 2014-06-11 09:26:24 <wumpus> great!
250 2014-06-11 09:52:01 <gribble> I have not seen trevp.
251 2014-06-11 09:52:01 <ThomasV> !seen trevp
252 2014-06-11 09:53:15 <gdm85> wumpus: any advice for this issue? https://github.com/bitcoin/bitcoin/issues/4324
253 2014-06-11 11:13:37 <gdm85> guys, what is your md5 hash for libpng-1.6.8.tar.gz?
254 2014-06-11 11:14:30 <michagogo> wumpus: Farsi?
255 2014-06-11 12:00:31 <gdm85> wumpus: gitian.sigs repository doesn't contain a directory for 0.9.2rc2. have you put your signatures somewhere for reference?
256 2014-06-11 12:02:29 <wumpus> gdm85: https://github.com/bitcoin/gitian.sigs/tree/master/0.9.2rc2
257 2014-06-11 12:02:46 <gdm85> ACTION *facepalm*
258 2014-06-11 12:02:49 <gdm85> ok, thanks
259 2014-06-11 12:03:09 <wumpus> not sure why you couldn't find it, four people have built it already
260 2014-06-11 12:03:18 <gdm85> wumpus: because I was looking at my fork.. :\
261 2014-06-11 12:08:03 <PLM3> Yeah hi. I'm trying to send some coins by using bitcoin-cli, is there a way to know that the fee will be when I do "bitcoin-cli sendtoaddress ADDR AMOUNT" ?
262 2014-06-11 12:08:31 <sipa> no, it depends on the size of the transaction (in bytes), which isn't known before the transaction is created
263 2014-06-11 12:09:31 <PLM3> I see
264 2014-06-11 12:11:29 <PLM3> Let me rephrase myself a bit. I need to send some coins out by using bitcoin-cli, currently it tells me that I need to set tx fee to at least 0.0001, because of tx complexity
265 2014-06-11 12:11:39 <PLM3> I need to do this manually by using "settxfee" ?
266 2014-06-11 12:12:08 <sipa> no
267 2014-06-11 12:15:18 <PLM3> what you mean "no" ?
268 2014-06-11 12:18:12 <PLM3> sipa: you mean like 1) no, I don't need to manually set the fee, there's a option to make this tx go through with higher fee or 2)no, this transaction is not going anywhere, forget it ?
269 2014-06-11 12:20:32 <sipa> normally it will just add the fee automatically
270 2014-06-11 12:20:40 <sipa> if it fails, it is because it couldn't add the fee
271 2014-06-11 12:20:46 <sipa> perhaps because you don't have enough balance
272 2014-06-11 12:21:53 <PLM3> 0.0001BTC <- is this considered dust?
273 2014-06-11 12:22:10 <sipa> no
274 2014-06-11 12:22:20 <PLM3> I fail to move it out of a wallet
275 2014-06-11 12:22:37 <sipa> is that all your balance?
276 2014-06-11 12:22:40 <PLM3> yes
277 2014-06-11 12:23:05 <sipa> did you receive it in many small incoming transactions?
278 2014-06-11 12:23:24 <PLM3> one incoming transaction of 0.0001BTC
279 2014-06-11 12:23:39 <sipa> that should work fine
280 2014-06-11 12:23:45 <sipa> you may need a fee though
281 2014-06-11 12:24:07 <sipa> just sending the entire wallet balance somewhere won't work, as you'd have nothing left to pay the fee
282 2014-06-11 12:24:27 <PLM3> I've tried 0.00008BTC, failed too
283 2014-06-11 12:24:42 <sipa> what client version?
284 2014-06-11 12:24:52 <PLM3> 0.9.1
285 2014-06-11 12:26:35 <sipa> ah, yes, the fee will be 0.0001
286 2014-06-11 12:26:43 <sipa> in 09.1
287 2014-06-11 12:26:45 <sipa> in 0.9.1
288 2014-06-11 12:43:03 <hearn> 0.0001 is the old fee
289 2014-06-11 12:43:08 <hearn> the new fee is 0.00001, i think
290 2014-06-11 12:43:19 <hearn> although it takes a while for such transactions to get confirmed
291 2014-06-11 12:53:51 <PLM3> hearn: so if I "settxfee 0.00001", I should succeed in my tx ?
292 2014-06-11 12:54:24 <hearn> i think so, but try it. if you're trying to empty your wallet of course you have to subtract the actual required fee (which is calculated based on tx size so may be multiples of the min fee)
293 2014-06-11 12:54:32 <hearn> btw bitcoinj does all this automatically
294 2014-06-11 13:14:03 <gdm85> (gitian-builder) although make-base-vm (--lxc) is not parallel-safe, I think gbuild instead is? I'd need to make some tests but the script seems fine
295 2014-06-11 13:15:49 <wumpus> gdm85: what do you mean by parallel safe? you can't call gbuild multiples times at the same time, if you mean that
296 2014-06-11 13:16:19 <wumpus> gitian does not spin up multiple VMs
297 2014-06-11 13:16:27 <gdm85> wumpus: running 2 make-base-vm commands at same time won't work because of the way LXC is handled inside there. imagine 2 terminals on same host, and you run the command from both at same time
298 2014-06-11 13:16:44 <gdm85> wumpus: I thought it does, using qcow2-backed snapshots
299 2014-06-11 13:17:01 <wumpus> same will be true for gbuild, at least with KVM it first kills the previous VM
300 2014-06-11 13:17:15 <wumpus> I don't know about LXC, but I'm pretty sure it's not a officially supported thing :)
301 2014-06-11 13:17:48 <gdm85> if it identifies the VM by architecture, then perhaps the i386 and amd64 could be run in parallel?
302 2014-06-11 13:17:56 <wumpus> ...possibly
303 2014-06-11 13:18:40 <wumpus> one thing I do know for sure is that you can increase make parallelism within the gbuild
304 2014-06-11 13:18:59 <gdm85> that's something already
305 2014-06-11 13:19:32 <gdm85> I see num_procs=2 and memory=2000 by default
306 2014-06-11 13:19:48 <wumpus> does num_procs and memory affect LXC at all?
307 2014-06-11 13:19:58 <wumpus> I don't think so
308 2014-06-11 13:20:24 <gdm85> wumpus: num_procs it's basically the value passed in make -j, so that does
309 2014-06-11 13:21:01 <gdm85> the other one, I think it doesn't
310 2014-06-11 13:21:29 <wumpus> you can also provide it on the command line, gbuild -jX
311 2014-06-11 13:21:43 <gdm85> wumpus: yes that's how I'd use it
312 2014-06-11 13:22:45 <gdm85> it's not officially supported = by bitcoin project you mean?
313 2014-06-11 13:23:27 <wumpus> it's not officially supported as in "no one tested it before or made special preparations for it"
314 2014-06-11 13:23:53 <wumpus> gbuild in itself is very heavy here, I've never even considered running multiple at the same time
315 2014-06-11 13:24:44 <gdm85> it's officially supported by gitian-builder. the premise is that it is equivalent to KVM, programs running inside these VMs can't know the difference unless looking specifically for them
316 2014-06-11 13:25:07 <wumpus> ok whatever, do what you like
317 2014-06-11 13:27:14 <wumpus> you're very wrong: gbuild instances all use the same ouput directory, and it deletes the output directory at startup, I'm sure that can collide in various ways
318 2014-06-11 13:28:13 <gdm85> obviously. if there were no --lxc option in gitian-builder, I wouldn't have bothered at testing it in first place
319 2014-06-11 13:28:48 <gdm85> wumpus: I was asking if gbuild could be parallelized, I didn't say it could
320 2014-06-11 13:28:56 <wumpus> so how can you claim it is officially supported? heck, I don't even want to know, I'm tired of arguing this
321 2014-06-11 13:29:12 <gdm85> except that there is no argument here.
322 2014-06-11 13:29:34 <gdm85> I said LXC is officially supported by gitian-builder
323 2014-06-11 13:29:53 <wumpus> oh sure! I thought you meant parallelism with gbuild
324 2014-06-11 13:30:06 <wumpus> as in calling gbuild multiple times at once
325 2014-06-11 13:30:09 <gdm85> no no..that's the experiment part..and I already expected it to be impossible, was asking here if somebody tried
326 2014-06-11 13:31:39 <gdm85> btw, with the further patch for make-base-vm, boost hashes already match
327 2014-06-11 13:31:58 <wumpus> cool!
328 2014-06-11 13:33:30 <gdm85> however now I am thinking that becase Luke-Jr didn't provide the LC_*/LANG variables he uses, this test might be biased. in my env I have lots of LC_* but not LC_ALL and LANG. perhaps he had en_GB.UTF-8 there..
329 2014-06-11 13:33:39 <gdm85> I mean, it would have been best to try with exact env variables
330 2014-06-11 13:45:28 <wumpus> yes, that would have been the way to make sure
331 2014-06-11 14:24:23 <gdm85> wumpus: matching signatures. I will send another PR to devrandom about this
332 2014-06-11 14:40:24 <Luke-Jr> SomeoneWeird: 4, in fact.
333 2014-06-11 14:41:17 <Luke-Jr> [09:09:32] <gdm85> Luke-Jr: can you confirm that the locale problem makes mismatching hashes? or it was due to other reasons? <-- it was
334 2014-06-11 14:41:38 <gdm85> Luke-Jr: I am going to submit a patch for that problem
335 2014-06-11 14:43:26 <gavinandresen> wumpus: is pull-tester broken again? And whatâs up with 0.9.2rc2 ?
336 2014-06-11 14:43:32 <Luke-Jr> [09:21:49] <gdm85> wumpus: because Luke-Jr confirmed it's there and I assume he didn't install it manually nor gitian-builder/vmbuilder do? <-- en_GB.UTF-8 is what I use normally, as I mentioned earlier: LANG=en_GB.UTF-8 LC_COLLATE=C
337 2014-06-11 14:43:42 <Luke-Jr> (done with backlog here, gotta run)
338 2014-06-11 14:43:45 <wumpus> gavinandresen: yes, pulltester is broken, the disk is full
339 2014-06-11 14:44:08 <wumpus> gavinandresen: as for rc2 it's mainly because of the openssl upgrade
340 2014-06-11 14:44:13 <gdm85> Luke-Jr: ok, I will run another test with those 2, to further verify if patch holds
341 2014-06-11 14:44:56 <gavinandresen> wumpus: ok, I can fix the pulltester machine. I need to delete the old bitcoin.org-jekyll-vm so I was planning on doing some sysadmin work today
342 2014-06-11 14:45:00 <wumpus> gavinandresen: no problems have been reported with rc1 AFAIK
343 2014-06-11 14:45:45 <wumpus> gavinandresen: ok, I mailed BlueMatt about pulltester access, would be useful if cory and me could get at it as well
344 2014-06-11 14:46:06 <gavinandresen> wumpus: I think you do, you just donât know that you do :-)
345 2014-06-11 14:46:16 <gavinandresen> wumpus: Iâll email yâall details
346 2014-06-11 14:46:22 <wumpus> :-) okay that's very possible
347 2014-06-11 14:49:30 <phantomcircuit> 2014-06-11 14:53:20 UpdateTip: new best=0000000000000000047636c5c3583c19e4c529e53a4eef0c93a2df9658cfb502 height=280314 log2_work=75.690497 tx=30931118 date=2014-01-13 16:13:54 progress=0.420748
348 2014-06-11 14:49:33 <phantomcircuit> lold
349 2014-06-11 14:49:43 <phantomcircuit> this is gonna take forever
350 2014-06-11 14:49:48 <gavinandresen> BlueMatt: you here?
351 2014-06-11 14:50:42 <gavinandresen> phantomcircuit: what hardware are you syncâing on? SSD or spinning disk?
352 2014-06-11 14:50:57 <phantomcircuit> gavinandresen, valgrind
353 2014-06-11 14:51:03 <phantomcircuit> dat callgraph
354 2014-06-11 14:51:12 <gavinandresen> phantomcircuit: oh, valgrindâ¦â¦
355 2014-06-11 14:51:43 <gavinandresen> phantomcircuit: kudos to you for doing it.
356 2014-06-11 14:51:45 <phantomcircuit> im thinking it's going to take ~70 hours total
357 2014-06-11 14:52:05 <phantomcircuit> been posting progress updates every morning
358 2014-06-11 14:52:08 <helo> not as bad as i might have guessed
359 2014-06-11 14:52:31 <phantomcircuit> helo, that's with sipa's patch to avoid recalculating tx hashes
360 2014-06-11 14:52:47 <phantomcircuit> w/o that i think it would be more like 90-100 hours
361 2014-06-11 14:58:30 <gdm85> Luke-Jr: https://github.com/devrandom/gitian-builder/pull/59
362 2014-06-11 15:02:23 <tonikt> guys, the rule that mined coins cannot be spent before 120 confirmations - is it in block chain protocol, or is it only a limitation of the client?
363 2014-06-11 15:02:30 <hearn> it's 100
364 2014-06-11 15:02:50 <tonikt> oh, that's why I could not find it in the code
365 2014-06-11 15:03:03 <tonikt> cheers, man
366 2014-06-11 15:03:37 <tonikt> now I see it's in the block chain protocol
367 2014-06-11 15:05:19 <wumpus> there used to be an extra rule of 120 blocks in the bitcoin core wallet, but is was removed quite some time ago
368 2014-06-11 15:05:28 <wumpus> afaik other wallets never had that rule at all
369 2014-06-11 15:05:54 <andytoshi> tonikt: the relevant constant is COINBASE_MATURITY, which you can grep for, it's only used in a couple places
370 2014-06-11 15:06:38 <andytoshi> where you see COINBASE_MATURITY+1 used to be COINBASE_MATURITY+20, that was the 120-block rule
371 2014-06-11 15:06:55 <tonikt> andytoshi: yes - I found it, indeed. thanks.
372 2014-06-11 16:31:41 <gavinandresen> Any python coders here with an hour or two to spare? Iâm looking to outsource some code I need written: https://gist.github.com/gavinandresen/88f2f247f574fe16bd57
373 2014-06-11 16:43:40 <phantomcircuit> gavinandresen, delimiter?
374 2014-06-11 16:44:00 <gavinandresen> phantomcircuit: delimiter ????
375 2014-06-11 16:44:18 <phantomcircuit> json files or json filenames
376 2014-06-11 16:44:31 <gavinandresen> concatenated JSON objects on standard input.
377 2014-06-11 16:44:32 <phantomcircuit> newline delimiters?
378 2014-06-11 16:44:40 <phantomcircuit> lol nothx
379 2014-06-11 16:44:49 <gavinandresen> ⦠shouldnât matter, just read a JSON object until you hit EOF
380 2014-06-11 16:45:16 <phantomcircuit> wait is it one json object per execution?
381 2014-06-11 16:45:32 <phantomcircuit> or are you going to do something like echo "{}{}"|python program.py
382 2014-06-11 16:45:38 <gavinandresen> (because Iâll drive it with âcat 2014*.json | make_a_nice_graph.py > graph.htmlâ )
383 2014-06-11 16:47:02 <phantomcircuit> gavinandresen, python json tools are pretty much all or nothing
384 2014-06-11 16:47:14 <phantomcircuit> im not aware of a json decoder which operates on a stream like that
385 2014-06-11 16:47:24 <phantomcircuit> xml? sure json? ehhhh
386 2014-06-11 16:47:53 <gavinandresen> phantomcircuit: okey dokey, the point of outsourcing is to get somebody ELSE to figure all that out.....
387 2014-06-11 16:48:15 <phantomcircuit> right im saying that if you throw a delimiter into the spec it becomes trivial
388 2014-06-11 16:48:18 <phantomcircuit> without it....
389 2014-06-11 16:48:21 <gavinandresen> (e.g. splitting up stream at }whitespace{ would probably be fine)
390 2014-06-11 16:48:49 <phantomcircuit> ie your RFQ isn't completely defined
391 2014-06-11 16:48:52 <phantomcircuit> :P
392 2014-06-11 16:49:02 <michagogo> gavinandresen: well, that would mean requiring whitespace at the beginning or end of the json files
393 2014-06-11 16:49:05 <gavinandresen> phantomcircuit: meh. I give sample input....
394 2014-06-11 16:49:54 <jgarzik_> phantomcircuit, XML? Isn't use of XML classified as a war crime these days? Or at least cruel and unusual punishment.
395 2014-06-11 16:50:28 <phantomcircuit> jgarzik_, generally speaking yes, but afaik there isn't a streaming json decoder in python yet
396 2014-06-11 16:50:35 <phantomcircuit> an opportunity for you to write one!
397 2014-06-11 16:50:37 <gavinandresen> michagogo: ??? pythonâs re.split should do the right thing with }whitespace{
398 2014-06-11 16:50:48 <michagogo> Oh, you meant that literally
399 2014-06-11 16:51:03 <michagogo> ACTION doesn't know python
400 2014-06-11 16:51:03 <phantomcircuit> gavinandresen, only if you're sure that is actually the delimiter :P
401 2014-06-11 16:51:10 <michagogo> But what I said is still true
402 2014-06-11 16:51:18 <phantomcircuit> hmm actually that isn't valid inside a json object
403 2014-06-11 16:51:19 <phantomcircuit> so it should be
404 2014-06-11 16:51:28 <michagogo> You need to know that the json files will either begin or end with whitespace
405 2014-06-11 16:52:07 <gavinandresen> afk, lunch. Thereâs 0.2 BTC waiting if anybody wants to do a little coding....
406 2014-06-11 16:52:21 <michagogo> Too bad it's Python
407 2014-06-11 16:52:44 <michagogo> If Ruby worked, I might give it a try if the Google thing isn't too complicated
408 2014-06-11 16:52:49 <gavinandresen> michagogo: if you want to write it in bash thatâd be fine. But not ruby or php or anything else Iâd have to install on the server
409 2014-06-11 16:52:57 <michagogo> Right.
410 2014-06-11 16:53:58 <michagogo> Hm, I wonder if a ruby-to-python translator exists? :P
411 2014-06-11 16:54:43 <phantomcircuit> michagogo, yes but lol noooo
412 2014-06-11 16:55:57 <phantomcircuit> 2014-06-11 16:59:04 UpdateTip: new best=000000000000000052ac9fbddcd5b405f31245accb85ca1eed3d40b431650446 height=280456 log2_work=75.716095 tx=30979481 date=2014-01-14 13:22:39 progress=0.423863
413 2014-06-11 16:56:08 <michagogo> gavinandresen: does ruby compiled into a .pyc count?
414 2014-06-11 16:56:16 <phantomcircuit> anybody know if there's a way to get valgrind to write a valid callgraph before it exits?
415 2014-06-11 16:56:28 <michagogo> https://github.com/whymirror/unholy appears to do that
416 2014-06-11 16:56:34 <phantomcircuit> actually nvm
417 2014-06-11 16:56:50 <phantomcircuit> [ perf record: Captured and wrote 8667.109 MB perf.data (~378671768 samples) ]
418 2014-06-11 16:56:52 <michagogo> (though it looks like it hasn't been updated since 2008... maybe it doesn't work)
419 2014-06-11 16:56:54 <phantomcircuit> lol forgot i was running that
420 2014-06-11 17:01:30 <Luke-Jr> gdm85: wumpus: keep in mind that en_US.UTF-8 is subject to change as USA culture changes
421 2014-06-11 17:03:13 <BlueMatt> gavinandresen: for a minute or two
422 2014-06-11 17:03:28 <Luke-Jr> devrandom: see above
423 2014-06-11 17:10:07 <berndj-blackout> doing it in bash: challenge accepted
424 2014-06-11 17:12:21 <edcba> i thought usa culture doesn't exist
425 2014-06-11 17:12:49 <michagogo> berndj-blackout: if you actually do that, I'll throw in another 5%
426 2014-06-11 17:18:58 <michagogo> Does bitcoind take a SIGTERM and exit cleanly?
427 2014-06-11 17:21:28 <berndj-blackout> it does with ^C aka SIGINT, i can't imagine SIGTERM doing anything less clean
428 2014-06-11 17:54:20 <Luke-Jr> edcba: there are reasons I use en_GB instead of en_US ;)
429 2014-06-11 17:56:03 <dexX7> somewhat ot: looks like coinkite adopted counterparties "let's create a bunch of unspent outputs so they are available" policy x.x http://blog.coinkite.com/post/88396049981/new-feature-flex-liquidity-smart-utxo-management
430 2014-06-11 18:02:37 <wumpus> Luke-Jr: over a long time you're right, but over the time that one release matters I'd hope USA culture doesn't change enough for the locale to change enough to produce indeterministic output between builders :p
431 2014-06-11 18:03:50 <wumpus> Luke-Jr: if only there would be an additional requirement that a build in 200 years will still give the same output :)
432 2014-06-11 18:04:25 <Luke-Jr> wumpus: one of the goals of gitian is so we can reproduce the identical build years later
433 2014-06-11 18:06:49 <Luke-Jr> anyhow, in other news
434 2014-06-11 18:07:07 <Luke-Jr> my webserver ran about a week without any interruption of service, without bitcoin-seeder running
435 2014-06-11 18:07:17 <Luke-Jr> just started bitcoin-seeder <1 hr ago, and XO.net is DoSing me again
436 2014-06-11 18:07:25 <Luke-Jr> so, I'd say the connection is pretty much confirmed
437 2014-06-11 18:27:18 <phantomcircuit> Luke-Jr, dns seed?
438 2014-06-11 18:27:58 <Luke-Jr> phantomcircuit: yes
439 2014-06-11 18:28:56 <phantomcircuit> Luke-Jr, what's the DoS look like
440 2014-06-11 18:29:50 <cfields> wumpus: for the EC sanity check, i assume if libsecp256k1 is enabled, it should just return true?
441 2014-06-11 18:30:29 <Luke-Jr> phantomcircuit: they continue to advertise a route to my subnet, yet blackhole packets to my IP
442 2014-06-11 18:30:40 <Luke-Jr> to/from
443 2014-06-11 18:31:21 <wumpus> cfields: yes
444 2014-06-11 18:31:30 <wumpus> cfields: we're always sane in that case