1 2015-01-14 02:07:29 <earlz> So, other than transaction size concerns, are there any disadvantages if you only ever spent 1 input per transaction?
2 2015-01-14 02:07:54 <earlz> well wait, you wouldn't be able to condense funds.. you'd end up with smaller and smaller inputs as time goes on
3 2015-01-14 02:07:57 <earlz> nvm
4 2015-01-14 02:08:17 <earlz> I was thinking it'd be a lot more privacy maintaining if you didn't spend more than 1 input at a time, but that's not really feasible
5 2015-01-14 02:19:07 <gmaxwell> earlz: if you don't reuse addresses, however, the merging does not reveal much.
6 2015-01-14 02:19:36 <gmaxwell> (it links those seperate payments but the domain of linkage stops there; with address reuse it snowballs and includes almost all your transactions)
7 2015-01-14 02:21:16 <earlz> does the bitcoin core wallet ever reuse addresses without using coin control?
8 2015-01-14 02:26:03 <gmaxwell> earlz: not itself; but users can remember an address it gave them and send to it multiple times.
9 2015-01-14 02:26:49 <earlz> yea, of course.
10 2015-01-14 04:15:50 <phantomcircuit> does bitcoind remember that it was reindexing if it's killed?
11 2015-01-14 04:16:21 <gmaxwell> phantomcircuit: yes
12 2015-01-14 05:56:37 <yinyang> is there any good book for bitcoin developers? With examples how transaction is working? Any bit-coinn cookbook for developer?
13 2015-01-14 06:00:57 <fanquake> yinyang Have you looked at https://bitcoin.org/en/developer-documentation
14 2015-01-14 06:03:28 <yinyang> ok I know for this doc. on this offical bitcoin page. But Is there any book(s) with more examples and explenationn what is the bast way to manage transaction. Bitstamp have some problems with their transaction. What shoul be aware?
15 2015-01-14 06:07:57 <yinyang> Can anybody descripe the bast and secure transaction procedure steps?
16 2015-01-14 07:13:17 <petertodd> sipa: "i feel like this "use bits from nVersion" change begins to be a change of sufficient size that it may warrant proposing it separately, independent of an actual proposed change" <- very strongly agree here; how to do soft-forks should be a BIP in its own right
17 2015-01-14 07:27:22 <mircea_popescu> gavinandresen you ready to apologize and get lost already ?
18 2015-01-14 07:27:31 <mircea_popescu> use your key.
19 2015-01-14 07:36:41 <michagogo> ACTION wonders wtf mircea_popescu was talking about
20 2015-01-14 07:45:11 <cfields> michagogo: as a guess, check the exchanges right now
21 2015-01-14 07:45:53 <michagogo> Eh?
22 2015-01-14 07:46:04 <michagogo> ;;ticker --market all
23 2015-01-14 07:46:17 <gribble> Bitstamp BTCUSD last: 160.0, vol: 69233.57687358 | BTC-E BTCUSD last: 180.049, vol: 42249.28149 | Bitfinex BTCUSD last: 179.32, vol: 163193.43712903 | CampBX BTCUSD last: 170.0, vol: 74.14318171 | BTCChina BTCUSD last: 161.5614, vol: 320494.52200000 | Kraken BTCUSD last: 180.00056, vol: 189.61473824 | Bitcoin-Central BTCUSD last: 171.1725, vol: 438.56902261 | Volume-weighted last average: (1 more message)
24 2015-01-14 07:46:23 <michagogo> ;;more
25 2015-01-14 07:46:24 <gribble> 167.568401066
26 2015-01-14 07:46:27 <michagogo> ...wow.
27 2015-01-14 07:46:47 <michagogo> But... What "key"?
28 2015-01-14 07:46:59 <michagogo> Gavin only has the code signing and alert keys, AFAIK
29 2015-01-14 07:48:50 <cryptonaut420> he probably meant sign an apology with his pgp key or something
30 2015-01-14 07:48:56 <cryptonaut420> mircea is a moron
31 2015-01-14 07:49:49 <wumpus> Luke-Jr: eh remember our discussion yesterday - using QChar in #5651 turns out to be a one-line change https://github.com/laanwj/bitcoin/commit/29296893e846bbdf98585d23dca5989c3bcde096
32 2015-01-14 07:59:08 <sbeta> anyone here knows the detail of the conflict with the new openssl update?
33 2015-01-14 08:00:49 <gmaxwell> Everone here does.
34 2015-01-14 08:01:05 <wumpus> sbeta: http://sourceforge.net/p/bitcoin/mailman/message/33222029/
35 2015-01-14 08:06:53 <sbeta> wumpus: thanks
36 2015-01-14 08:09:22 <jonasschnelli> wumpus, https://github.com/bitcoin/bitcoin/pull/5656 is a trivial and should get merged
37 2015-01-14 08:11:03 <wumpus> cfields: re:trivial, should it go into your tree or mainline?
38 2015-01-14 08:12:22 <wumpus> I don't think it is 'trivial', as it changes the mac build process and not just the text on a superficial level, so I'm just going to merge it
39 2015-01-14 08:14:00 <gmaxwell> wumpus: hm does batching actually cover the performance concerns wrt having to make lots of connections?
40 2015-01-14 08:14:17 <gmaxwell> How does batching work?
41 2015-01-14 08:14:19 <wumpus> gmaxwell: yes. you can submit about 1000 commands in one go
42 2015-01-14 08:14:33 <wumpus> gmaxwell: then you get 1000 results
43 2015-01-14 08:14:41 <wumpus> very handy for say getblockhash
44 2015-01-14 08:14:46 <gmaxwell> But you can't get their results and make a new request without a reconnect, right?
45 2015-01-14 08:14:50 <wumpus> no
46 2015-01-14 08:15:05 <wumpus> but RPC is a local mechanism anyhow, so connect overhead should be minimal compared to other factors
47 2015-01-14 08:15:21 <gmaxwell> so for sequential operations it's potentiall worse. The overhead on all this stuff is just hideous.
48 2015-01-14 08:15:26 <wumpus> IMO if something is broken it should be disabled
49 2015-01-14 08:15:32 <wumpus> keepalive is seemingly broken
50 2015-01-14 08:15:38 <gmaxwell> In any case, I could invert m patch: make keepalive off by default, with a switch to reenable.
51 2015-01-14 08:15:51 <gmaxwell> I think if you really want keep alive you know it.
52 2015-01-14 08:15:55 <gmaxwell> And yes, it's busted.
53 2015-01-14 08:16:12 <wumpus> exactly. It's a microoptimization probably.
54 2015-01-14 08:16:23 <wumpus> funroll loops people may like to enable it :)
55 2015-01-14 08:16:55 <fanquake> jonasschnelli We can probably pull out the bit about installing git. Or just note that it will be installed with xcode.
56 2015-01-14 08:16:56 <gmaxwell> well I've wanted it before; but then it was easier to just move my code into bitcoin core; and enormously faster because the json stuff is super slow.
57 2015-01-14 08:17:08 <gmaxwell> okay. I'll invert the pullreq to disable it by default.
58 2015-01-14 08:17:54 <wumpus> note that I'm not against it
59 2015-01-14 08:18:01 <gmaxwell> I was really surprised to find out we hadn't fixed its known screwyness for so long. :( I'd forgotten about it.
60 2015-01-14 08:18:18 <gmaxwell> I would prefer to turn it off by default; I didn't think anyone would go for that.
61 2015-01-14 08:18:20 <wumpus> if we'd e.g. replace the RPC server with something that implements keep-alive correctly, we should definitely enable it by default as the HTTP 1.1 spec says
62 2015-01-14 08:18:59 <wumpus> but right now it's too easy to blow it up with a lot of connections, and keep-alive invites a lot of connections :)
63 2015-01-14 08:19:02 <gmaxwell> I think it had been previously proposed we remove it when we first realized it was problematic and IIRC that didn't fly well. And yes, I'd prefer to have it right, but we're not doing that for 0.10.
64 2015-01-14 08:19:02 <wumpus> right
65 2015-01-14 08:19:38 <gmaxwell> and debugging anything with the rpc networking is a pain.
66 2015-01-14 08:19:39 <jonasschnelli> cfields, i had a look at the 0.10.0rc3 osx dmg. Code signing and app structure is okay: http://paste.ubuntu.com/9743050/
67 2015-01-14 08:19:48 <jonasschnelli> cfields, but encountered https://github.com/bitcoin/bitcoin/issues/5657
68 2015-01-14 08:20:49 <midnightmagic> I don't suppose someone posted their OSX build up somewhere I could download it and compare it with mine to try to track down a likely cause of my deviation?
69 2015-01-14 08:20:52 <wumpus> gmaxwell: I don't know the details about HTTP 1.1 - wonder if the server should return a Connection: Close header if it doesn't support keepalive, so that the client knows
70 2015-01-14 08:21:46 <fanquake> midnightmagic rc3 is up at https://bitcoin.org/bin/0.10.0/test/ now. Is that what your after?
71 2015-01-14 08:21:52 <gmaxwell> I don't think there is anything to know? you're allowed to close the connection at any point. I don't think, "I closed it because I don't keepalive" is distinguishable from "I was tired of you."
72 2015-01-14 08:22:41 <midnightmagic> fanquake: probably.
73 2015-01-14 08:23:35 <wumpus> gmaxwell: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html "That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server. " but http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.10 doesn't say anything about the server sending that header. So I think it's fine.
74 2015-01-14 08:23:42 <wumpus> gmaxwell: indeed
75 2015-01-14 08:23:59 <wumpus> gmaxwell: ah it does "in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete. "
76 2015-01-14 08:24:13 <wumpus> gmaxwell: so it's also specified in the response header
77 2015-01-14 08:25:09 <wumpus> gmaxwell: well at least theoretically a client may make some assumptions about e.g. resource allocation based on it, not that I think its more than a nitpicking issue
78 2015-01-14 08:25:25 <midnightmagic> Binary files bitcoin-0.10.0-pristine/bin/test_bitcoin and bitcoin-0.10.0/bin/test_bitcoin differ <-- that was unexpected to me.
79 2015-01-14 08:25:59 <gmaxwell> wumpus: with this off, IIRC we'll actually send close in the response. I'll check.
80 2015-01-14 08:26:41 <midnightmagic> bitcoind, bitcoin-cli, and bitcoin-tx, and, surprisingly, test_bitcoin-qt are all identical (as are the dylib files)
81 2015-01-14 08:26:43 <wumpus> gmaxwell: ok - in that case the implementation is better than I expected :)
82 2015-01-14 08:27:54 <wumpus> midnightmagic: what are the differences between the binaries? are they the same size with e.g. just a string difference, or deeper?
83 2015-01-14 08:28:08 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/issues/5657 and maybe Prio Medium or even High
84 2015-01-14 08:28:17 <midnightmagic> wumpus: just looking now, half a mo
85 2015-01-14 08:28:57 <wumpus> jonasschnelli: goddamnit, text again broken on osx?
86 2015-01-14 08:30:03 <wumpus> jonasschnelli: please don't tell me that we need to do a rc respin again?
87 2015-01-14 08:30:28 <wumpus> IIRC we didn't change anything in that regard compared to rc1
88 2015-01-14 08:30:47 <gmaxwell> wumpus: yea HTTPReplyHeader takes a keep-alive argument and emits Connection: close
89 2015-01-14 08:30:56 <jonasschnelli> wumpus, yes. Don't happen when i build locally. I assume cfield should get a closer look maybe with my help... i assume it's a qt issue. could not track it down...
90 2015-01-14 08:30:57 <wumpus> gmaxwell: nice!
91 2015-01-14 08:31:13 <wumpus> jonasschnelli: :(
92 2015-01-14 08:31:39 <jonasschnelli> wumpus, any yes. this is a blocker and will probably trigger a rc4 :(
93 2015-01-14 08:32:03 <jonasschnelli> wumpus, depends on your aimed quality of the osx gui. :)
94 2015-01-14 08:32:08 <wumpus> jonasschnelli: why didn't no one notice?
95 2015-01-14 08:32:26 <wumpus> Nothing4You: I mean at least cfields *and* gavin checked the executable
96 2015-01-14 08:32:34 <wumpus> Nothing4You: sorry wrong person
97 2015-01-14 08:32:56 <jonasschnelli> because it only pops up when building determ. and my gitian is just up since 3 days.
98 2015-01-14 08:33:13 <wumpus> jonasschnelli: yes, but they checked gitian the result, I suppose
99 2015-01-14 08:33:23 <cfields> wumpus: no problem with text here
100 2015-01-14 08:33:24 <wumpus> jonasschnelli: how can this have changed since rc1? there's no font-related UI changes
101 2015-01-14 08:33:27 <wumpus> I don't even...
102 2015-01-14 08:33:34 <cfields> jonasschnelli: what osx version are you running?
103 2015-01-14 08:33:34 <wumpus> rm -rf src/qt :p
104 2015-01-14 08:33:47 <jonasschnelli> cfields, 10.10
105 2015-01-14 08:34:16 <cfields> jonasschnelli: do you see the problem with rc1?
106 2015-01-14 08:34:16 <jonasschnelli> but have 10.9 and 10.7 vm. Will test there soon (afk for some mins, sry)
107 2015-01-14 08:34:33 <jonasschnelli> cfields, will test also with rc1 soon.
108 2015-01-14 08:35:58 <cfields> wumpus: fwiw, i checked OSX rc3 binary for this issue in particular. I'm paranoid about the stupid fonts now.
109 2015-01-14 08:36:19 <wumpus> ok, looking at it in more detail, it looks like this is not a general font issue but specifically the UTF-8 thin spaces
110 2015-01-14 08:37:21 <cfields> grr, i thought i complained about those until they got nixed
111 2015-01-14 08:37:32 <wumpus> let's replace them with normal spaces
112 2015-01-14 08:37:41 <cfields> ACTION reads to remind himself
113 2015-01-14 08:38:05 <cfields> yes, please. Same with the new ~ symbol. Anything non-trivial in utf is bound to break for someone somehow.
114 2015-01-14 08:38:26 <wumpus> cfields: it's almost like we're in 1995 again
115 2015-01-14 08:39:17 <cfields> the weird thing is.. i would think i'd hit this one. afaik the font breakage happened with 10.9.x
116 2015-01-14 08:39:27 <cfields> maybe they threw another one in just for fun with 10.10 :\
117 2015-01-14 08:39:44 <wumpus> utf8 is supported well on windows and ilnux IIRC
118 2015-01-14 08:40:57 <cfields> the issue is that qt ships with hard-coded font names for fallbacks. When the current font can't load a crazy symbol, it looks for it in the fallback. In 10.9 (and i guess again in 10.10), osx changed the name of that default font when they rolled out retina
119 2015-01-14 08:41:26 <wumpus> cfields: sure! it's not our fault, it's a qt-macosx interoperability issue
120 2015-01-14 08:41:50 <cfields> all that is osx-centric, no clue if the same flow pertains to linux/win as well
121 2015-01-14 08:43:01 <midnightmagic> wumpus: there's an 8-byte size difference which initially throws some things off, but then much of the symbol table stuff is completely different locations.
122 2015-01-14 08:43:22 <cfields> wumpus: heh, wasn't being defensive, just re-hashing what we've already seen to refresh myself :)
123 2015-01-14 08:44:47 <cfields> midnightmagic: yes, gavin's test_bitcoin differed also
124 2015-01-14 08:45:10 <wumpus> cfields: you'd expect macosx with their unhealthy obsession for fonts to get this part right
125 2015-01-14 08:46:26 <cfields> wumpus: yea, at least leave a pointer from old->new font somehow for back-compat... something
126 2015-01-14 08:47:12 <wumpus> cfields: yep. I've heard more complaints that devs are going crazy from macosx changing everything wildly every every release.
127 2015-01-14 08:48:02 <midnightmagic> i don't suppose someone would be willing to do a digest if every file in their MacOSX SDK and dumping it somewhere for me to download? like: find . -type f -print0 | xargs -0 -P 2 md5sum > for_mm sort of deal?
128 2015-01-14 08:49:01 <cfields> midnightmagic: i can tomorrow, but i've got to hit the bed now
129 2015-01-14 08:49:07 <wumpus> cfields: nn
130 2015-01-14 08:49:14 <midnightmagic> cfields: okay I'll ping you if someone else helps me before then
131 2015-01-14 08:49:26 <cfields> midnightmagic: sounds good
132 2015-01-14 09:00:50 <michagogo> midnightmagic: if you look back at the logs from yesterday, I pastebinned an ls -l, I think
133 2015-01-14 09:01:05 <jonasschnelli> cfields, wumpus: 10.7 and 10.9 is not affected (10.8 will be the same).
134 2015-01-14 09:01:09 <michagogo> So not hashes, but at least timestamps and bytesizes
135 2015-01-14 09:01:27 <wumpus> jonasschnelli: ok so another 10.10 issue
136 2015-01-14 09:01:53 <michagogo> midnightmagic: actually, it was a tar tvf or whatever the command is that shows tarball contents
137 2015-01-14 09:02:01 <midnightmagic> michagogo: ok
138 2015-01-14 09:02:02 <midnightmagic> ACTION looks
139 2015-01-14 09:02:49 <jonasschnelli> wumpus, cfields could be only on my system because of some side effects, but very likely that this is a 10.10 issue or a retina issue
140 2015-01-14 09:04:10 <michagogo> jonasschnelli wumpus cfields: I might be able to get access to a non-retina MBP that I *think* has 10.10 on it, if you need testing from another system
141 2015-01-14 09:04:30 <jonasschnelli> cfields, could it be a wrong encoding in the Ressource/*.pm files?
142 2015-01-14 09:04:30 <jonasschnelli> s/pm/qm/
143 2015-01-14 09:04:32 <jonasschnelli> michagogo, would be a good test.
144 2015-01-14 09:04:42 <michagogo> jonasschnelli: what's the question exactly?
145 2015-01-14 09:04:50 <wumpus> jonasschnelli: no, this has nothing to do with translation files
146 2015-01-14 09:04:53 <michagogo> (i.e. what am I looking at?)
147 2015-01-14 09:05:07 <wumpus> or encodings for that matter
148 2015-01-14 09:05:27 <cfields> jonasschnelli: 90% if it's a 10.10 problem, you'll need to look at system font paths and defaults
149 2015-01-14 09:05:27 <wumpus> jonasschnelli: this is the issue: <cfields> the issue is that qt ships with hard-coded font names for fallbacks. When the current font can't load a crazy symbol, it looks for it in the fallback. In 10.9 (and i guess again in 10.10), osx changed the name of that default font when they rolled out retina
150 2015-01-14 09:05:32 <jonasschnelli> will also test on my girlfriends osx 10.10 retina as soon as she clear my credit card in those very expensive interior online shops.
151 2015-01-14 09:07:08 <michagogo> jonasschnelli: if I do get a chance to test, what should I be looking at?
152 2015-01-14 09:07:44 <jonasschnelli> michagogo, have a quick look at https://github.com/bitcoin/bitcoin/issues/5657 ... the balance value fields is a good thing to look at
153 2015-01-14 09:08:32 <michagogo> jonasschnelli: ah, so switch to a small denomination and send it a bunch so it's 1000+?
154 2015-01-14 09:09:22 <michagogo> jonasschnelli: I don't see any thin spaces in https://cloud.githubusercontent.com/assets/178464/5736282/5a35abf0-9bd4-11e4-8506-3f11be4c15a8.png
155 2015-01-14 09:09:28 <michagogo> (Broken or otherwise)
156 2015-01-14 09:09:38 <jonasschnelli> michagogo, i would recommend to start it from the cmd line with '/Volumes/Bitcoin-Qt/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt --regtest'
157 2015-01-14 09:09:38 <jonasschnelli> michagogo, open debug console and enter 'setgenerate true 101'
158 2015-01-14 09:09:39 <jonasschnelli> then you should have some coins
159 2015-01-14 09:09:42 <cfields> jonasschnelli: i assume you don't usually see this issue?
160 2015-01-14 09:10:04 <cfields> jonasschnelli: meaning: you work in 10.10 all the time with no problems?
161 2015-01-14 09:10:13 <michagogo> jonasschnelli: ah, I guess that's easier than using testnet
162 2015-01-14 09:10:20 <cfields> or you just happen to be testing it on this machine now?
163 2015-01-14 09:10:34 <jonasschnelli> michagogo, yes. this screen is from 10.9 (where the problem does not appear)
164 2015-01-14 09:10:44 <jonasschnelli> cfields, working since month with 10.10 (started with beta) never had this issue in other apps
165 2015-01-14 09:10:58 <michagogo> jonasschnelli: I mean, that screenshot doesn't demonstrate that the problem isn't appearing there
166 2015-01-14 09:11:01 <cfields> jonasschnelli: ok. do you build from brew's qt?
167 2015-01-14 09:11:18 <jonasschnelli> michagogo, depends on the length of your testnet chain (which might lead to some waiting minutes at startup)
168 2015-01-14 09:11:35 <jonasschnelli> michagogo, have a look at the screenshot at the very top of the issue
169 2015-01-14 09:11:48 <michagogo> jonasschnelli: I know
170 2015-01-14 09:11:57 <michagogo> I saw that, and know what the problem is
171 2015-01-14 09:11:58 <jonasschnelli> cfields, yes. Brews qt.
172 2015-01-14 09:12:06 <jonasschnelli> cfields, i could try build localy with the qt from gitian if this helps
173 2015-01-14 09:12:08 <cfields> jonasschnelli: if it works for you on that machine when you self-build, then the issue is either our qt, or the 10.7 sdk
174 2015-01-14 09:12:32 <michagogo> Just that the screenshot you posted saying 10.9 is fine doesn't actually show it being fine
175 2015-01-14 09:12:50 <jonasschnelli> cfields, very likely qt
176 2015-01-14 09:13:15 <cfields> jonasschnelli: i can build you one with our qt against 10.10 sdk to rule that out
177 2015-01-14 09:13:31 <cfields> the changes for that are in master, not backported
178 2015-01-14 09:13:50 <jonasschnelli> cfields, if you can do that easy you can msg me a dmg and i will test. probably faster than my gitian build.
179 2015-01-14 09:14:10 <cfields> jonasschnelli: well it'll be tomorrow. i'm still trying to get away from here :)
180 2015-01-14 09:14:21 <jonasschnelli> if you need a 10.10 sdk tell me because i have one on my desktop
181 2015-01-14 09:15:00 <cfields> thanks
182 2015-01-14 09:15:06 <jonasschnelli> cfields, come on! day just stared. :) clear, have your rest.
183 2015-01-14 09:15:30 <jonasschnelli> cfields, maybe i manage to do a sdk 10.10 build on my gitian box
184 2015-01-14 09:16:03 <cfields> jonasschnelli: you'll have to build master
185 2015-01-14 09:16:17 <jonasschnelli> cfields, if i try i will use master. thanks
186 2015-01-14 09:16:26 <cfields> best you can do there is 10.9 though, clang isn't new enough to build against 10.10
187 2015-01-14 09:16:47 <michagogo> cfields: (do we know that master has this same issue, if built in the same environment as rc3?
188 2015-01-14 09:16:49 <michagogo> )
189 2015-01-14 09:17:06 <jonasschnelli> cfields, couldn't i do the opposite: build on my 10.10 with the qt from gitian depends?
190 2015-01-14 09:17:20 <jonasschnelli> (and see if i encounter the issue)?
191 2015-01-14 09:18:15 <cfields> jonasschnelli: that'd be simpler, yes. adds lots more variables, but probably not important ones
192 2015-01-14 09:18:55 <jonasschnelli> cfields, maybe i'll find the time to do that. Now have your rest... thanks.
193 2015-01-14 09:18:56 <cfields> michagogo: don't know that, no. but i can almost guarantee the the issue is the sdk or qt version, or a combination of both. neither of those have changed yet in master.
194 2015-01-14 09:19:27 <cfields> master just lifts the limits so we can bump them when ready
195 2015-01-14 09:21:00 <gdm85> any idea what could be causing this mkdir error? http://pastebin.com/raw.php?i=P5Py9r1q
196 2015-01-14 09:21:30 <midnightmagic> michagogo: identical filenames and sizes, except mine have a bunch of underscore files that are uniformly 120 bytes long in it. so. functionally identical i think.
197 2015-01-14 09:22:08 <gdm85> mmh..I think I'll just patch that line to be mkdir_p https://github.com/devrandom/gitian-builder/blob/master/bin/gbuild#L186
198 2015-01-14 09:22:24 <michagogo> midnightmagic: very odd.
199 2015-01-14 09:22:38 <michagogo> Has someone diffed the bins?
200 2015-01-14 09:23:19 <midnightmagic> michagogo: not yet. I am on Yosemite, but I'm not building on it, so don't think that should make a difference.
201 2015-01-14 09:23:36 <michagogo> midnightmagic: nah, shouldn't.
202 2015-01-14 09:23:55 <michagogo> midnightmagic: you said you're using LXC in an Ubuntu VM, right?
203 2015-01-14 09:24:17 <michagogo> ACTION wonders if the hypervisor might somehow possibly matter
204 2015-01-14 09:24:41 <michagogo> Are you using vbox, VMware, parallels, or something else?
205 2015-01-14 09:26:03 <midnightmagic> michagogo: correct. LXC. I am not using vbox, vmware, nor parallels. I have an overpowered 32-cpu 128GB machine running ubuntu 12.04 on it which hosts a pile of things, these builds included.
206 2015-01-14 09:26:11 <michagogo> Oh
207 2015-01-14 09:26:16 <michagogo> Why not kvm, though?
208 2015-01-14 09:26:19 <michagogo> Wait, nvm
209 2015-01-14 09:26:24 <michagogo> You already answered that iirc
210 2015-01-14 09:26:27 <midnightmagic> there *is* a kvm guest running on it but it's unrelated.
211 2015-01-14 09:26:58 <michagogo> midnightmagic: I meant kvm for gitian, but I think I already asked that
212 2015-01-14 09:27:12 <midnightmagic> yes i know, I'm just trying to be thorough
213 2015-01-14 09:27:21 <michagogo> Wait, what? 32 cpu, 128GB? O_o
214 2015-01-14 09:28:04 <michagogo> That's...
215 2015-01-14 09:28:08 <michagogo> wow.
216 2015-01-14 09:29:17 <midnightmagic> yes. 32 cores, only two sockets.
217 2015-01-14 09:29:21 <midnightmagic> yay $1200/btc
218 2015-01-14 09:29:26 <michagogo> The first time I read that as 32-bit, and thought "how can that build at all?"... then I reread
219 2015-01-14 10:18:38 <gdm85> is there package pinning in gitian-builder yet?
220 2015-01-14 10:20:06 <michagogo> gdm85: no
221 2015-01-14 10:20:09 <wumpus> I don't think so
222 2015-01-14 10:20:50 <michagogo> I don't think there's an apt-get upgrade, so you'll be using whatever was current when you created the base image
223 2015-01-14 10:21:05 <michagogo> And the latest version of whatever the descriptor calls for
224 2015-01-14 10:21:10 <wumpus> michagogo: apart from what gets installed as part of the descriptor
225 2015-01-14 10:21:11 <wumpus> right
226 2015-01-14 10:21:34 <gdm85> I entered a feature request for this, I think it would be a nice to have
227 2015-01-14 10:21:34 <wumpus> in any case - we want to move away from requiring VMs for deterministic builds, so a bit of package variability is a good litmus test
228 2015-01-14 10:22:02 <wumpus> (although pinning the toolchain, e.g. gcc and binutils would make a lot of sense)
229 2015-01-14 10:22:14 <gdm85> wumpus: schroot deterministic builds?
230 2015-01-14 10:22:40 <wumpus> gdm85: a chroot shouldn't even be necesarry, just our own toolchain
231 2015-01-14 10:22:58 <wumpus> e.g. the only thing that should still affect determinism in depends builds is gcc+binutils
232 2015-01-14 10:23:12 <wumpus> the rest is built from source already
233 2015-01-14 10:23:34 <michagogo> Clang too, right?
234 2015-01-14 10:23:43 <michagogo> (For os x)
235 2015-01-14 10:24:06 <gdm85> wumpus: that would mean no gitian-builder, right?
236 2015-01-14 10:24:07 <wumpus> michagogo: clang is already a 'golden toolchain' fetched from somewhere, not used as ditro package
237 2015-01-14 10:24:11 <wumpus> gdm85: right
238 2015-01-14 10:24:17 <michagogo> Ah. Right.
239 2015-01-14 10:24:38 <gdm85> makes sense
240 2015-01-14 10:24:43 <gdm85> ACTION dreams of cmake deterministic builds
241 2015-01-14 10:25:20 <wumpus> I don't think adding cmake to the mix will improve it one bit
242 2015-01-14 10:26:08 <wumpus> it doesn't have any determinism features on top of make does it?
243 2015-01-14 10:26:16 <gdm85> it has none
244 2015-01-14 10:26:52 <gdm85> I'd like to have both determinism as a feature of building systems and OOB portability support as cmake tries to frame. but they are separate features indeed
245 2015-01-14 10:27:11 <sipa> out of band?
246 2015-01-14 10:27:22 <gdm85> out of the box, picked wrong acronym? :P
247 2015-01-14 10:27:35 <sipa> ah, ootb
248 2015-01-14 10:27:39 <gdm85> yep, sorry
249 2015-01-14 10:28:05 <sipa> damn you ambiguity resulting from reducing information
250 2015-01-14 10:28:25 <gdm85> acronyms are evil anyway! I hate acronyms of acronyms in particular
251 2015-01-14 10:28:29 <wumpus> the base requirement will always be *some kind of* unixish environment
252 2015-01-14 10:30:10 <wumpus> would be nice if the deterministic build worked on odd ducks like cygwin, msys, solaris, but primarily we're trying to get rid of the inner VM spawned by gitian first, widening the platform choices for the outer environment is a latter concern
253 2015-01-14 10:30:14 <michagogo> It'd be cool if we can get it working in Cygwin
254 2015-01-14 10:30:30 <gdm85> is ARM architecture not officially supported?
255 2015-01-14 10:30:46 <wumpus> gdm85: I'm not sure what you mean with 'official', but all of my full-time bitcoin nodes are ARM
256 2015-01-14 10:30:57 <gdm85> ideally one could cross-build also for that (at least v7+)
257 2015-01-14 10:31:06 <wumpus> gdm85: you can. it's easy
258 2015-01-14 10:31:35 <wumpus> gdm85: cd depends; make HOST=my-arm-host-tuple; cd ..; ./configure --prefix=$PWD/depends/my-arm-host-tuple; make;
259 2015-01-14 10:32:07 <gdm85> wumpus: yes but we don't have gitian.sigs for them, right?
260 2015-01-14 10:32:53 <wumpus> works for ARM, MIPS, AARCH64 at least. Though BE requires #5510 which is still somehwat experimental.
261 2015-01-14 10:33:47 <wumpus> gdm85: right, we don't bother with that
262 2015-01-14 10:34:00 <wumpus> (would be easy to add if there's really demand)
263 2015-01-14 10:34:53 <sipa> gdm85: gitian sigs are really just useful for verifying that binaries are built from the source they claim to be built from
264 2015-01-14 10:34:54 <wumpus> and as soon as depends can make toolchains as well it becomes really simple
265 2015-01-14 10:35:07 <sipa> if you build them yourself... who cares?
266 2015-01-14 10:35:46 <sipa> though i guess they are useful as a consistency check too
267 2015-01-14 10:36:04 <wumpus> you could just parametrize the top-level script by host tuple, and ideally it'd generate deterministic bitcoind executables for that host tuple
268 2015-01-14 10:36:17 <gdm85> sipa: I see it as a feature that I can check that most people on planet are running a binary with same hash as mine :)
269 2015-01-14 10:36:40 <gdm85> in this light, would be nice to have signatures also for libconsensus, in case it ever lands bundled on some android app (but I am stretching this now.. :P)
270 2015-01-14 10:37:39 <wumpus> gdm85: libbitcoinconsensus is part of the .zip/.tar.gz distributions on bitcoin.org (but yes, only x86)
271 2015-01-14 10:37:53 <gdm85> ACTION nods
272 2015-01-14 10:38:59 <gdm85> 75840d962cdbfe210b817c91b8662c889420e54350cbcd19225eec8dae974ab2 bitcoin-0.10.0-linux32.tar.gz
273 2015-01-14 10:38:59 <gdm85> ffa520e1980e979f77fe528b293338c8ecea94b8905f3dd8e6081ecd0552a054 bitcoin-0.10.0-linux64.tar.gz
274 2015-01-14 10:39:11 <gdm85> ok, I will build also for windows and Mac OS X and then submit my sigs
275 2015-01-14 10:40:23 <wumpus> but it is early to encourage running bitcoind on ARM. It works, but can need some extra babysitting here and there, pre-made executables implies it works in any supporting board out of the box.... and there's tons of lousy boards like rpi that aren't really up to it right now, both re :CPU speed and memory
276 2015-01-14 10:41:27 <gdm85> i would avoid those without hardfloat support
277 2015-01-14 10:41:30 <wumpus> (although the same could be said for PCs, bitcoind doesn't really work that well on my 2004 laptop either :-)
278 2015-01-14 10:41:41 <wumpus> gdm85: if only rpi didn't have hf support it'd be a better world :P
279 2015-01-14 10:41:44 <maaku> wumpus: well underpowered boards isn't really our problem...
280 2015-01-14 10:42:00 <maaku> though i agree that at minimum it needs some more testing berfore there were an official ARM release
281 2015-01-14 10:42:09 <wumpus> maaku: well unformtunately it is, people get bad experiences and blame it on it, increasing the amount of concern trolls we have to deal with
282 2015-01-14 10:42:26 <maaku> wumpus: a large disclaimer is the fix for that
283 2015-01-14 10:42:33 <gdm85> eheh
284 2015-01-14 10:42:52 <gdm85> the MacOSX10.7.sdk goes in gitian-builder/inputs and not in cache/common ? do I understand right?
285 2015-01-14 10:43:06 <wumpus> supporting macosx is a challenge enough for now.
286 2015-01-14 10:43:36 <wumpus> if anyone wants to be official 'arm maintainer' and test on series of boards that'd be very welcome of course
287 2015-01-14 10:45:23 <gdm85> wumpus: also android phones? (they classify as ARM devices too)
288 2015-01-14 10:45:32 <wumpus> gdm85: if that holds your interest, sure
289 2015-01-14 10:46:10 <gdm85> mh :\ can't say I had a nice experience last time I tried to target it for builds, but heaps better than Mac OS X ;)
290 2015-01-14 10:46:32 <gdm85> Jouke: maybe some automated builds on U2/U3s? can be automated now with that script I made
291 2015-01-14 10:46:48 <wumpus> gdm85: in principle you can build bitcoin core for android, people (at least cfield) have done that
292 2015-01-14 10:47:32 <wumpus> gdm85: and yes macosx10.7.sdk.tar.gz is part of the fixed inputs, not of the cached inputs
293 2015-01-14 10:48:02 <wumpus> (if only it would be trivially fetchable from the internet...)
294 2015-01-14 10:48:09 <gdm85> and legal
295 2015-01-14 10:49:41 <maaku> iirc it is trivially fetchable, just not legal
296 2015-01-14 10:50:07 <wumpus> yes, thanks, but we don't really want to integrate a torrent client into depends download :p
297 2015-01-14 10:50:14 <Jouke> wumpus: what tests are you referring to?
298 2015-01-14 10:50:19 <Jouke> gdm85: we alse have a rpi
299 2015-01-14 10:50:21 <maaku> you need a login to find the link, but last time I checked (2 years ago, admittedly) they don't check the cookie for the actual download
300 2015-01-14 10:50:39 <maaku> but yeah, we want to comply
301 2015-01-14 10:51:01 <wumpus> maaku: also that downloads the big-ass file, we only need a smaallll subsection
302 2015-01-14 10:51:57 <wumpus> Jouke: well, first of course the tests of bitcoin core itself. Apart from that, more subjective tests wether it works good enough on a certain board to be able to recommend it to others.
303 2015-01-14 10:52:29 <wumpus> e.g. if your odroid3 overheats and corrupts every time you get to block 238721, you don't want to recommend it
304 2015-01-14 10:52:38 <Jouke> wumpus: yeah, ok, so some general tests as well.
305 2015-01-14 10:53:20 <gdm85> Jouke: yeah but I'd skip that at all
306 2015-01-14 10:53:23 <maaku> really we need someone willing to host (and oversee) a rack of arm boards able to do automated comprehensive build tests ...
307 2015-01-14 10:53:39 <wumpus> well the build is easy.
308 2015-01-14 10:53:47 <wumpus> it works, it's the running that has to be tested
309 2015-01-14 10:53:57 <Jouke> "a rack" of arm boards :D
310 2015-01-14 10:54:08 <wumpus> I have a box of ARM boards, just no time
311 2015-01-14 10:54:11 <Jouke> how many viable arm boards are there? :)
312 2015-01-14 10:54:14 <gdm85> maaku: there are already (paid) rpi online providers AFAIK
313 2015-01-14 10:54:33 <sipa> "that's no shoebox! that's a beowolf cluster of arm boards!"
314 2015-01-14 10:55:08 <wumpus> Jouke: a lot are older single-core ones, e.g. marvell orion and such, so no chance of bitcoind :)
315 2015-01-14 10:55:09 <gdm85> wumpus: generally they behave well (U2/U3s) with their fan mounted, it's the microSD/eMMC that holds most of the (un)reliability
316 2015-01-14 10:55:37 <wumpus> sipa: lol
317 2015-01-14 11:03:45 <wumpus> Jouke: well at least imx6dl/q-based boards, odroid (seemingly given proper cooling), apart from that I don't know. That's why we'd need someone to inventarise that...
318 2015-01-14 11:04:19 <Jouke> even without proper cooling the odroid is doing ok with bitcoind.
319 2015-01-14 11:04:41 <wumpus> well ask gmaxwell for the other side of the story, he's using an odroid without fan to do fuzz testing :P
320 2015-01-14 11:04:43 <Jouke> uhm, that means it has proper cooling by definition :P
321 2015-01-14 11:05:11 <wumpus> maybe in the cold netherlands :)
322 2015-01-14 11:07:01 <michagogo> 12:50:33 <maaku> you need a login to find the link, but last time I checked (2 years ago, admittedly) they don't check the cookie for the actual download
323 2015-01-14 11:07:11 <gdm85> wumpus: I had a few fs corruptions, but faulty PSU was the issue (insufficient voltage)
324 2015-01-14 11:07:13 <michagogo> The other day I clicked the direct link
325 2015-01-14 11:07:23 <michagogo> It redirected me to a login page
326 2015-01-14 11:07:25 <wumpus> gdm85: ah, okay
327 2015-01-14 11:07:28 <maaku> michagogo: :(
328 2015-01-14 11:07:47 <gdm85> a bad PSU can really screw up these small devices
329 2015-01-14 11:07:56 <michagogo> But yeah, as mentioned, that's also 1.6 GB
330 2015-01-14 11:08:16 <michagogo> The part we use is what, 40MB gzipped?
331 2015-01-14 11:08:19 <wumpus> gdm85: yup, but it's the same, I've had lots of trouble with semi-broken PSUs on PCs
332 2015-01-14 11:08:49 <wumpus> michagogo: yes.
333 2015-01-14 11:09:33 <michagogo> 12:49:53 <maaku> iirc it is trivially fetchable, just not legal <-- Erm, well, it *is* just a file
334 2015-01-14 11:09:58 <michagogo> You could say that about just about any file that someone can give you
335 2015-01-14 11:10:04 <wumpus> let's not get into legality discussion here
336 2015-01-14 11:11:37 <michagogo> wumpus: I'm not. Just saying, it's not like it's on a public server anywhere afaik -- so it's not "trivially fetchable" unless someone puts it up somewhere
337 2015-01-14 11:11:46 <cfields> don't nearly all of those arm boards support android in some form?
338 2015-01-14 11:11:52 <cfields> all of mine have, anyway
339 2015-01-14 11:11:59 <wumpus> that is a variable per country - Apple makes it difficult for us to get the file and extract the part that we want, end of story
340 2015-01-14 11:12:04 <wumpus> michagogo: sure
341 2015-01-14 11:12:59 <wumpus> cfields: android is usually one of the first things that gets ported, because of its application in consumer devices, sure
342 2015-01-14 11:14:25 <cfields> wumpus: maybe worth looking into again. android+arm is trivial compared to linux+arm in my experience.
343 2015-01-14 11:14:39 <wumpus> cfields: although some are aimed at embedded usage (e.g. NAS, router) where bare bones linux or bsd is more popular
344 2015-01-14 11:16:46 <wumpus> cfields: yes it'd be nice, although on the other hand the android OS itself also gives quite a lot of overhead, so you may require more powerful devices to run bitcoind on that
345 2015-01-14 11:17:36 <gdm85> cfields: that's because most times you get all the necessary drivers for android, but 0 for the linux end.
346 2015-01-14 11:18:31 <gdm85> ODROID devices notably have good support for multimedia on Linux </ad>, but not all features are there (it's still a proprietary binary blob you need to run, can get outdated etc)
347 2015-01-14 11:18:44 <wumpus> gdm85: mostly if you care about multimedia
348 2015-01-14 11:19:13 <gdm85> wumpus: yes, not our case. but affects ease to find them on the wild with an installed Linux
349 2015-01-14 11:19:26 <gdm85> e.g. some people will use them as mini-servers, so it's fine. others try to run XBMC etc
350 2015-01-14 11:20:13 <wumpus> it's always gpu and vpu drivers that are problematic, getting the SoC support can be a drag too, but if you have an android kernel you effectively have a Linux kernel. Mainline Linux support is a wholly other story.
351 2015-01-14 11:20:32 <cfields> gdm85: you work with/for odroid?
352 2015-01-14 11:20:49 <gdm85> cfields: nope, just used the devices since their early times
353 2015-01-14 11:21:07 <wumpus> e.g. if you have some funny Chinese board you're probably stuck without mainline support forever. On the other hand, imx6 and such are well-supported in mainline now, and even part of debian distro for ARM.
354 2015-01-14 11:21:15 <cfields> gdm85: oh. your nick sounded familiar. thought i might've worked with you in another life :)
355 2015-01-14 11:22:02 <gdm85> eheh. in another life likely I had another nick ;)
356 2015-01-14 11:22:10 <gdm85> cfields: you helped me out with some gitian-builder issues, last year
357 2015-01-14 11:22:48 <cfields> gdm85: ah, i guess that's it. i was an xbmc dev, thought we might've crossed paths
358 2015-01-14 11:23:29 <cfields> wumpus: the main benefit of android (imo) is that you take userspace out of the equation. Don't have to worry about libc, packages, kernel, etc. Just slap together an apk and you're off.
359 2015-01-14 11:23:49 <cfields> (assuming you're not messing with low-level video, audio, etc)
360 2015-01-14 11:23:54 <wumpus> cfields: that's the same for our statically-built ARM executable :)
361 2015-01-14 11:24:34 <cfields> wumpus: heh, thanks for not pointing out the fact that i used the kernel as an example of user-space compatibility :)
362 2015-01-14 11:25:50 <wumpus> cfields: hehe
363 2015-01-14 11:25:51 <cfields> wumpus: still, that binary likely wouldn't move well between openwrt and odroid ubuntu
364 2015-01-14 11:26:01 <wumpus> cfields: the kernel version for which the toolchain was built matters, but if you pick a reasonably old/stable kernel version, it's unlikely to be a big issue
365 2015-01-14 11:27:18 <wumpus> cfields: sure, you can always come with counterexampels
366 2015-01-14 11:28:01 <wumpus> cfields: APKs that use binary compilation also have some constraints
367 2015-01-14 11:28:13 <cfields> wumpus: not trying to be pessimistic about linux in this case, only pointing out the merits of android...
368 2015-01-14 11:28:22 <cfields> there are likely just as many down-sides there :)
369 2015-01-14 11:28:54 <wumpus> cfields: I'm all for doing android too, just trying to say it's not the end-everything for other linux support :)
370 2015-01-14 11:29:22 <cfields> yep, agreed
371 2015-01-14 11:30:15 <cfields> i hacked on it a week or two ago and had it building fairly easily. If you're up for a WIP, i can PR what i've got
372 2015-01-14 11:32:29 <cfields> blah, back to bed
373 2015-01-14 11:32:31 <wumpus> cfields: cool
374 2015-01-14 11:32:35 <wumpus> cfields: hah, nn
375 2015-01-14 11:32:42 <wumpus> get some sleep!
376 2015-01-14 12:39:07 <dabura667> Interesting consult meeting: I was explaining why xyz should implement RFC 6979 when suddenly one of the younger programmers from across the room screams "Someone just sold 20,000 bitcoins on bitstamp!" and everyone ran back to their desks mid-discussion (and I followed)
377 2015-01-14 12:39:49 <dabura667> RFC 6979 > the price of bitcoins imho
378 2015-01-14 12:40:22 <dabura667> but it was amazing to see the vertical-ness of the chart. </ anecdote>
379 2015-01-14 12:40:56 <sinetek> lol
380 2015-01-14 12:41:55 <sinetek> why would you implement RFC 6979 though? Too many things to get wrong
381 2015-01-14 12:45:01 <dabura667> not rly
382 2015-01-14 12:45:11 <dabura667> it's a lot more straight forward that most things.
383 2015-01-14 12:45:31 <dabura667> have you ever had any trouble with it?
384 2015-01-14 12:46:09 <sinetek> ..
385 2015-01-14 12:46:20 <sinetek> what exchange you work for?
386 2015-01-14 12:46:31 <dabura667> not an exchange
387 2015-01-14 12:46:57 <dabura667> also not western country nor China.
388 2015-01-14 12:47:04 <wumpus> more things to get wrong? maybe. But because the output is deterministic it's much easier to test than randomized signatures
389 2015-01-14 12:47:37 <sinetek> yes
390 2015-01-14 12:50:13 <dabura667> although one thing that is correct is that if you don't use test vectors to test your implementation... just because signing twice gives you the same output... if you didn't know better, the coder could just make it like Hash(tx) x 369
391 2015-01-14 12:50:33 <dabura667> and then steal your funds afterward by looking on the blockchain.
392 2015-01-14 12:51:09 <dabura667> so yeah, test vectors are always a must.
393 2015-01-14 12:52:19 <wumpus> yes, test against other implementations
394 2015-01-14 12:52:30 <wumpus> (or test vectors generated by other implementations)
395 2015-01-14 12:53:17 <dabura667> https://github.com/bitpay/bitcore/blob/master/test/data/ecdsa.json#L158
396 2015-01-14 12:54:10 <dabura667> Here's some to get started. These were generated and tested against ecdsa-python. Bitcore uses a counter in the event of a bad r or s, and you can manually set the counter when testing.
397 2015-01-14 12:55:04 <op_mul> RFC6979 is nice but it's not the magic bullet a lot of people seem to think it is. if your RNG sucks enough that you're doubling up on nonces your private keys are going to stink as well.
398 2015-01-14 12:55:20 <dabura667> Very true.
399 2015-01-14 12:56:10 <wumpus> sure, if you also use BIP32 you reduce necessity for secure randomness even more
400 2015-01-14 12:56:19 <dabura667> I am thinking that too.
401 2015-01-14 12:56:37 <wumpus> then again, it makes it worse if you root key was generated with a sucky RNG
402 2015-01-14 12:56:41 <op_mul> I think it heightens your need for a secure RNG, actually.
403 2015-01-14 12:56:58 <wumpus> but only once
404 2015-01-14 12:57:03 <dabura667> yes.
405 2015-01-14 12:57:24 <op_mul> if your developers can't manage using an RNG properly I doubt the rest of their code will stand the heat either.
406 2015-01-14 12:58:01 <wumpus> also there it removes the need for non-determinism in the code, so it makes things easier to test and less dependent on external circumstances
407 2015-01-14 12:58:47 <wumpus> but sure if your developer suck your product is going to suck, no argument there...
408 2015-01-14 12:59:47 <op_mul> I've lost my desire for BIP32 anything really. I prefer that non-deterministic wallets over time add some forward security to old backups.
409 2015-01-14 13:02:32 <dabura667> One thing I can say though: devs in some countries have 0 interest in open source...
410 2015-01-14 13:04:21 <dabura667> like, when I tell them how I went through a bunch of repositories to check and do some pull requests to clean up / correct people's implementations of various things... one of them said "were you paid?" and I remembered that open source is very uncommon in my country.
411 2015-01-14 13:04:40 <dabura667> (while I was chatting with some of the devs)
412 2015-01-14 13:05:11 <dabura667> Maybe I'm just generalizing, tho.
413 2015-01-14 13:05:13 <op_mul> I'm going to go with india or china.
414 2015-01-14 13:05:30 <op_mul> but slipping into OT with this.
415 2015-01-14 13:05:46 <sinetek> ugh java
416 2015-01-14 13:05:50 <sinetek> javascript*
417 2015-01-14 13:05:53 <dabura667> Japan
418 2015-01-14 13:06:52 <sinetek> whatever happened to typed languages
419 2015-01-14 13:08:39 <sinetek> it's hard to pay the bills with open source :/
420 2015-01-14 13:08:48 <sinetek> it's immensely helpful though for humanity
421 2015-01-14 13:09:50 <op_mul> if you're trying to do cryptography in javascript.. yeah that's asking for trouble.
422 2015-01-14 13:11:40 <dhill> so you're not a fan of cryptocat?
423 2015-01-14 13:11:40 <sinetek> so many have failed at it, that's the thing
424 2015-01-14 13:13:45 <wumpus> cryptography is hard in the best of times, in the safest language. I'm afraid doing it in javascript is a challenge no human can best :)
425 2015-01-14 13:14:44 <op_mul> pity most of the bitcoin that exists is in the hands of a company who does all of their cryptography in javascript.
426 2015-01-14 13:56:34 <dhill> op_mul: what company?
427 2015-01-14 13:56:49 <op_mul> blockchain.info.
428 2015-01-14 13:58:22 <Kloeey> Bitcoin to 100$ look at this graph from China,Russia omg.. 100$ coming... http://www.bitcoinwisdomapp.com/#BitcoinGraphToday
429 2015-01-14 13:58:50 <op_mul> Kloeey: super off topic. #bitcoin
430 2015-01-14 13:58:55 <op_mul> er
431 2015-01-14 13:59:00 <op_mul> that's probably a malware link
432 2015-01-14 14:05:06 <Luke-Jr> wumpus: eh, I tried that and it definitely did NOT work..
433 2015-01-14 14:05:50 <wumpus> Luke-Jr: strange. it worked for me
434 2015-01-14 14:07:14 <Luke-Jr> wumpus: l5->setText(((nBytes > 0) ? ASYMP_UTF8 : "") + QString::number(nBytes)); // Bytes
435 2015-01-14 14:07:23 <Luke-Jr> wumpus: this would be invalid with a QChar
436 2015-01-14 14:07:45 <wumpus> Luke-Jr: somehow my compiler was smart enougn to substitute qstring there
437 2015-01-14 14:08:07 <wumpus> Luke-Jr: I'm not saying it is the best solution, just that using QChar is not as difficult as you'd make it seem :)
438 2015-01-14 14:08:49 <wumpus> Luke-Jr: anyhow with the macosx issues I expect more pushback for using more of UTF in general :(
439 2015-01-14 14:08:54 <Luke-Jr> wumpus: my compiler refused to build ;p
440 2015-01-14 14:11:04 <wumpus> Luke-Jr: stupid qt+macosx 10.10 seem to return the state of UTF back to that of say, 1994, where every somewhat-rare character causes a fallback to a placeholder
441 2015-01-14 14:13:05 <wumpus> well this is karma, earlier today I was mentioning solaris as a joke, now someone is actually trying to compile bitcoin for it https://github.com/bitcoin/bitcoin/issues/5659
442 2015-01-14 14:13:34 <wumpus> (well a derivative, but still)
443 2015-01-14 14:13:42 <Luke-Jr> sigh
444 2015-01-14 14:14:44 <rubensayshi> is there any convention on how to sort pubkeys before generating a redeemscript? and any reason why it's not part of a BIP :( ?
445 2015-01-14 14:16:28 <wumpus> you can use any order you like
446 2015-01-14 14:17:38 <rubensayshi> yea, but I want to use an order other people will expect to be used if they ever want to recreate the same redeemscript from the pubkeys
447 2015-01-14 14:17:55 <wumpus> ideally you'd just send the redeemscript
448 2015-01-14 14:18:35 <rubensayshi> it's to be able to 'recover' a wallet that was created with our API without the use of our API (from a backup, when we would be offline etc)
449 2015-01-14 14:18:45 <rubensayshi> I guess I'll just specify it
450 2015-01-14 14:19:29 <rubensayshi> and follow bitcore and do lexical order of the hex
451 2015-01-14 14:19:42 <Luke-Jr> rubensayshi: redeemscripts don't need to be simple multisig
452 2015-01-14 14:19:52 <rubensayshi> true
453 2015-01-14 14:20:20 <rubensayshi> but it would be nice for compatibility if everyone would sort pubkeys the same way for multisig
454 2015-01-14 14:20:55 <wumpus> feel free to create a BIP with a suggested order
455 2015-01-14 14:21:41 <wumpus> there's no reason to enforce it, but if you think it is useful to suggest one as a standard, then you can do that
456 2015-01-14 14:22:23 <rubensayshi> ok :)
457 2015-01-14 14:22:37 <sinetek> need to try HP-unix :p
458 2015-01-14 14:23:16 <teward> there're no plans to reset testnet any time soon are there
459 2015-01-14 14:23:19 <teward> diff is so high it now requires ASICs to mine it
460 2015-01-14 14:23:51 <helo> there are still some diff-1 blocks, aren't there?
461 2015-01-14 14:24:01 <teward> helo: if and only if no block in 20 minutes
462 2015-01-14 14:24:08 <wumpus> teward: no plans that I know of
463 2015-01-14 14:24:13 <teward> i had my small ASICs on for three hours - no 1 diff blocks
464 2015-01-14 14:24:15 <teward> helo: ^
465 2015-01-14 14:24:19 <helo> hmmm :/
466 2015-01-14 14:24:22 <teward> wumpus: okay, that... is disconcerting.
467 2015-01-14 14:24:39 <rubensayshi> teward, afaik the block interval is most of the time 20min because of that ;-)
468 2015-01-14 14:24:41 <teward> wumpus: that effectively prevents users from testing things on testnet without being dependent on other asics
469 2015-01-14 14:24:41 <wumpus> teward: you can always start your own testnet-in-a-box or use regtest
470 2015-01-14 14:25:01 <teward> wumpus: i had to use regtest - but i can't even get testnet-in-a-box up again >.>
471 2015-01-14 14:25:04 <wumpus> restarting testnet would have no effect on the difficulty
472 2015-01-14 14:25:05 <teward> (never binds to RPC port)
473 2015-01-14 14:25:14 <rubensayshi> https://www.blocktrail.com/tBTC/block-all/1 bleh doesn't show minutes, but average of 5 blocks per hour
474 2015-01-14 14:25:32 <rubensayshi> because of the diff-1 block rule
475 2015-01-14 14:25:47 <rubensayshi> doesn't seem like many people manage to find a block at the 'real' diff
476 2015-01-14 14:25:56 <wumpus> teward: shouldn't be hard to get testnet coins if you want some
477 2015-01-14 14:26:04 <op_mul> you can abuse the testnet rules if you feel like it.
478 2015-01-14 14:26:11 <op_mul> roll your clock 20 minutes, mine a diff 1 block.
479 2015-01-14 14:26:13 <wumpus> if people start attaching value to them, it's time to restart it
480 2015-01-14 14:26:15 <teward> op_mul: heh
481 2015-01-14 14:26:26 <teward> wumpus: i coulda sworn someone tried to do that on bitcointalk a while ago
482 2015-01-14 14:26:35 <teward> but the testnet wasn't wiped and restarted
483 2015-01-14 14:26:47 <wumpus> teward: well some people are stupid
484 2015-01-14 14:27:02 <teward> wumpus: no argument from me - IT 101: 99% of users are stupid
485 2015-01-14 14:27:19 <teward> of the remaining 1%, 50% are smart, the remainder don't listen.
486 2015-01-14 14:27:47 <wumpus> teward: I mean, one idiot trying to scam some other idiot by selling testcoins doesn't make it a disconcerting pattern yet
487 2015-01-14 14:27:58 <wumpus> heh
488 2015-01-14 14:59:49 <PANIC_SELL_NOW> now is the time to change to PoS. ASIC-based PoW has lead to unsustainable difficulty increases... I know personally about 25% of mining pools shutting off. We're going to see 20-30 minute blocks over the next few weeks. SHA256 needs to be removed. We have to switch to an asic-resistant PoW, Like dagger hashimoto (ethereum), or just switch to PoS.,,,Things will be even worse when side-chains come out and Austin Hill
489 2015-01-14 14:59:50 <gribble> Error: ",Things" is not a valid command.
490 2015-01-14 15:01:21 <op_mul> ACTION rolls eyes
491 2015-01-14 15:01:47 <Apocalyptic> ACTION sigh
492 2015-01-14 15:01:47 <op_mul> you know proof of stake isn't a method of maintaining a distributed consensus, right?
493 2015-01-14 15:02:07 <op_mul> there's a reason proof of stake based altcoins all have checkpoints :)
494 2015-01-14 15:02:34 <kanzure> op_mul: perhaps we should convince them of a "proof of centralization" :)
495 2015-01-14 15:03:19 <teward> probably would help if they were unquieted so they could voice an opinion :)
496 2015-01-14 15:03:35 <PANIC_SELL_NOW> read vitalik's bueterins post on the matter
497 2015-01-14 15:03:39 <PANIC_SELL_NOW> 'weak subjectivity'
498 2015-01-14 15:03:53 <sipa> can you 1) discuss elsewhere 2) change your nick?
499 2015-01-14 15:04:03 <sinetek> it still works pretty well in practice
500 2015-01-14 15:04:21 <teward> ACTION voices the opinion that *panic*sell* should be a banned nick pattern
501 2015-01-14 15:04:38 <wumpus> proof of IRC trolling
502 2015-01-14 15:04:49 <Apocalyptic> changed_my_nick, vitalik is clueless, fortunately people here won't fall for your trolling
503 2015-01-14 15:05:17 <teward> trolls are bad.
504 2015-01-14 15:05:24 <btcdrak> ouch
505 2015-01-14 15:05:30 <earlz> lol
506 2015-01-14 15:06:06 <Anduck> well
507 2015-01-14 15:06:52 <akstunt600> Hey all
508 2015-01-14 15:06:58 <Anduck> just to be clear: PoS doesn't work as well as PoW.
509 2015-01-14 15:07:16 <Anduck> as PoS is "centralized"
510 2015-01-14 15:07:18 <akstunt600> Was just wondering what the opinions on this increased block size are
511 2015-01-14 15:07:19 <earlz> PoS has glaring security holes compared to PoW
512 2015-01-14 15:07:26 <sipa> please, not here
513 2015-01-14 15:07:30 <akstunt600> I mean wont this cause fees to increase?
514 2015-01-14 15:07:36 <akstunt600> please sipa
515 2015-01-14 15:07:42 <sipa> akstunt600: sorry, wasn't talking to you
516 2015-01-14 15:07:48 <akstunt600> Merkel cals will increase no?
517 2015-01-14 15:07:52 <akstunt600> ah thanks
518 2015-01-14 15:07:58 <akstunt600> calcs*
519 2015-01-14 15:08:00 <earlz> yea, is there still plans to try to have a dynamic block size somehow?
520 2015-01-14 15:08:24 <sipa> Anduck, earlz: whatever PoS's worth, it's not bitcoin, and it is a such a wildly different design that i don't think anyone would even consider it an option for bitcoin; hence, offtopic here
521 2015-01-14 15:08:26 <akstunt600> I mean I honestly think splitting reward and cutting bloxk time in half is better
522 2015-01-14 15:08:40 <akstunt600> as an interim to long term solution
523 2015-01-14 15:08:44 <sipa> akstunt600: why do you think there is a time between blocks?
524 2015-01-14 15:08:51 <sinetek> PoW is flawed too.. there is no incentive to run a full node, and mining economics are all screwed
525 2015-01-14 15:09:16 <akstunt600> Yeah it effect transaction speed too
526 2015-01-14 15:09:17 <akstunt600> i know
527 2015-01-14 15:09:17 <earlz> akstunt600: that'd be a hard fork, not a soft fork
528 2015-01-14 15:09:26 <akstunt600> ohhh duh
529 2015-01-14 15:09:31 <akstunt600> DOH!
530 2015-01-14 15:09:36 <sipa> akstunt600: you haven't answered my question
531 2015-01-14 15:09:46 <akstunt600> I realy reall so wish we were on 5min block times
532 2015-01-14 15:09:48 <akstunt600> want to cry
533 2015-01-14 15:09:49 <helo> obvious is obvious
534 2015-01-14 15:09:49 <sipa> and no, ;larger blocks most likely means lower fees, and lower security
535 2015-01-14 15:09:56 <sipa> akstunt600: why?
536 2015-01-14 15:10:38 <akstunt600> But if im a pool and i have less transactions in my block my time to calc is fater right? I can get my block submitted first?
537 2015-01-14 15:10:43 <wumpus> please move all this to #bitcoin
538 2015-01-14 15:10:45 <op_mul> no.
539 2015-01-14 15:11:27 <earlz> No one talks about anything but the market in #bitcoin :(
540 2015-01-14 15:11:29 <akstunt600> hmm so selfishmining thing is not an issue here?
541 2015-01-14 15:11:39 <op_mul> akstunt600: I've answered you in #bitcoin.
542 2015-01-14 15:11:43 <akstunt600> Ah thanks
543 2015-01-14 15:11:52 <wumpus> earlz: tell them to go to -pricetalk
544 2015-01-14 15:12:44 <anddam> hello, has anyone stumbled on https://bugreports.qt.io/browse/QTBUG-22829 while building bitcoin-Qt?
545 2015-01-14 15:13:17 <earlz> I've never seen it
546 2015-01-14 15:13:29 <earlz> on Arch Linux
547 2015-01-14 15:13:31 <wumpus> me neither
548 2015-01-14 15:13:54 <wumpus> what OS? what qt?
549 2015-01-14 15:14:25 <sinetek> why such old boost
550 2015-01-14 15:15:40 <anddam> I'm on OS X, getting the info about libs versions
551 2015-01-14 15:16:08 <anddam> Qt 4.8.6, boost 1.57.0
552 2015-01-14 15:16:26 <akstunt600> Ughh i have been there before
553 2015-01-14 15:16:35 <akstunt600> I bet you get bdb problems too
554 2015-01-14 15:16:36 <anddam> I was looking at the workaround suggested at https://bitbucket.org/osrf/sdformat/pull-request/14/fix-for-qt-bug-22829/diff
555 2015-01-14 15:16:38 <akstunt600> :-/
556 2015-01-14 15:16:50 <anddam> but I don't know how boost headers are related
557 2015-01-14 15:16:51 <wumpus> OK re: OSX I can't really help, although the current recommedation is to use qt5 not qt4, although not because of build issues
558 2015-01-14 15:17:09 <akstunt600> i think there are few easy ways to just point to the right boost libs by setting env variables
559 2015-01-14 15:17:15 <akstunt600> anf then just recompile
560 2015-01-14 15:17:28 <akstunt600> You can also just install boost from scratch
561 2015-01-14 15:17:36 <akstunt600> and then make install
562 2015-01-14 15:17:49 <anddam> I only see boost/filesystem.hpp boost/filesystem/detail/utf8_codecvt_facet.hpp boost/filesystem/fstream.hpp boost/filesystem/operations.hpp in src/qt