1 2014-12-31 01:33:33 <Luke-Jr> firelegend: it's kindof enforced by scoped locks âº
2 2014-12-31 02:17:50 <firelegend> Luke-Jr:By the compiler or?
3 2014-12-31 02:20:20 <Luke-Jr> firelegend: by the design of the code
4 2014-12-31 02:20:53 <firelegend> I am exploring the code in net.cpp currently
5 2014-12-31 02:23:32 <firelegend> What I found odd, is that in ThreadSocketHandler which presumably is constantly working, is that when it's handling messages, it receives data and so far I understood the code, but then it also dispatches a reply via SocketSendData, but inside the function I don't see how the reply is constructed
6 2014-12-31 02:56:15 <Luke-Jr> sipa: any objections to making CCoinsViewCache(CCoinsViewCache) illegal?
7 2014-12-31 02:57:11 <Luke-Jr> (note: copy constructor, NOT the same as CCoinsViewCache(CCoinsViewCache*)
8 2014-12-31 03:10:17 <sipa> Luke-Jr: yeah, caches shouldn't br copyablr
9 2014-12-31 03:10:26 <Luke-Jr> k
10 2014-12-31 03:10:43 <sipa> Luke-Jr: i have an assumption why your test fails, but i won't have time for a few days
11 2014-12-31 03:10:50 <Luke-Jr> I was accidentally copying the cache instead of sub-caching it.. which meant Flush applied them to the real pcoinsTip >_<
12 2014-12-31 03:10:59 <Luke-Jr> ^ this is why
13 2014-12-31 03:11:34 <sipa> ah
14 2014-12-31 03:11:49 <sipa> then my assumption was wrong, but good :)
15 2014-12-31 03:12:47 <Luke-Jr> ACTION ponders if he should throw this in a separate PR for 0.10 candidacy, or just lump it in with CPFP
16 2014-12-31 05:20:22 <earlz> I've tried doing a from-scratch sync with bitcoin 0.9.3 and I'm stuck
17 2014-12-31 05:20:25 <earlz> http://pastebin.com/DVkccynH
18 2014-12-31 05:20:41 <earlz> specifically, stuck at block 212081
19 2014-12-31 05:21:13 <Luke-Jr> earlz: doesn't look stuck, just working
20 2014-12-31 05:21:16 <earlz> the orphan blocks are really confusing.. no idea why that's happening
21 2014-12-31 05:21:48 <earlz> it's been stuck on that for like 10 minutes at least
22 2014-12-31 05:22:27 <Luke-Jr> it's expected
23 2014-12-31 05:23:47 <Luke-Jr> (and fixed in 0.10)
24 2014-12-31 05:24:26 <earlz> mm.. I want 0.10 to be out already :(
25 2014-12-31 05:24:42 <Krellan_> Sorry lost my network connection = if RPC answer was given, I didn't hear it
26 2014-12-31 05:24:43 <earlz> that's including the headers-first and such right?
27 2014-12-31 05:25:03 <Krellan_> Curious if there's a RPC call to grab the contents of the address cache (used when making new outbound connections)
28 2014-12-31 05:25:20 <earlz> getmempool? or something like that?
29 2014-12-31 05:25:21 <Krellan_> and also the banned/unbanned status of them
30 2014-12-31 05:25:30 <earlz> er, not mempool
31 2014-12-31 05:25:49 <Krellan_> I'm looking for a RPC to ask that a particular peer be banned/unbanned
32 2014-12-31 05:25:52 <Krellan_> Does such already exist?
33 2014-12-31 05:25:58 <earlz> getpeerinfo maybe?
34 2014-12-31 05:26:08 <Krellan_> getpeerinfo = dumps info about all currently connected notdes
35 2014-12-31 05:26:09 <earlz> I don't think that lets you check banned/unbanned
36 2014-12-31 05:26:10 <Krellan_> nodes
37 2014-12-31 05:26:31 <earlz> what do you mean by "address cache" then?
38 2014-12-31 05:27:07 <Krellan_> peers.dat file
39 2014-12-31 05:28:57 <Luke-Jr> earlz: yes, headers-first is what fixes the orphan blocks
40 2014-12-31 05:30:36 <gmaxwell> earlz: they're harmless in any case, it just slows things down a bit. if you just ignore it and let it continue it will finish.
41 2014-12-31 05:31:14 <robbak> If a newly built bitcoin binary is dying on startup with "Initialization sanity check failed. Bitcoin Core is shutting down.", and debug.log just shows me "shutdown: In progress..." etc: How can I get some information on what part of the sanity check is failing, so I can debug it?
42 2014-12-31 05:53:06 <robbak> Further information - this is running on an empty directory. All it createes is the debug.log file.
43 2014-12-31 06:02:43 <gmaxwell> robbak: pastebin the debug.log
44 2014-12-31 06:04:01 <gmaxwell> there should be more entries before the "Initialization sanity check failed."
45 2014-12-31 06:04:59 <gmaxwell> robbak: what OS are you on?
46 2014-12-31 06:08:15 <gmaxwell> robbak: heelloo?
47 2014-12-31 06:08:20 <s1w> he ded
48 2014-12-31 06:08:59 <robbak> FreeBSD, gmaxwell. And it is three lines:
49 2014-12-31 06:09:01 <robbak> 2014-12-31 05:26:52 Shutdown: In progress...
50 2014-12-31 06:09:02 <robbak> 2014-12-31 05:26:52 StopNode()
51 2014-12-31 06:09:04 <robbak> 2014-12-31 05:26:52 Shutdown: done
52 2014-12-31 06:09:50 <Krellan_> Really dumb idea for making a PoW memory-hard: use nonce as an address into a large chunk of data (like the blockchain) then require a few bytes from there appear next to the nonce?
53 2014-12-31 06:10:32 <Krellan_> I like it, but know it must have a big hole that defeats it, but can't think of it offhand. Feel free to debunk it.
54 2014-12-31 06:10:38 <Luke-Jr> robbak: so this is with a non-GNU libc, correct?
55 2014-12-31 06:10:45 <Luke-Jr> Krellan_: not here
56 2014-12-31 06:11:28 <Krellan_> Doh wrong channel
57 2014-12-31 06:12:36 <robbak> Yes, I think. We probably use our own libc. I have been building v0.9.3 OK.
58 2014-12-31 06:12:57 <Luke-Jr> robbak: probably want to step through
59 2014-12-31 06:13:06 <Luke-Jr> set a breakpoint on InitSanityCheck
60 2014-12-31 06:17:37 <robbak> OK, Luke-Jr: after all the Qt stuff, we have BitcoinCore::initialize (), AppInit2 () and InitSanityCheck ()
61 2014-12-31 06:21:28 <gmaxwell> robbak: presumably you are failing the ECC sanity check which is quite bad.
62 2014-12-31 06:21:44 <gmaxwell> oh no actually that throws another error.
63 2014-12-31 06:22:00 <gmaxwell> so you're failing either glibc_sanity_test or glibcxx_sanity_test
64 2014-12-31 06:22:08 <robbak> I'm just doing a debug build to get something more.
65 2014-12-31 06:52:54 <cfields> robbak: osx?
66 2014-12-31 06:53:02 <robbak> reeBSD
67 2014-12-31 06:53:11 <robbak> cfields: FreeBSD
68 2014-12-31 06:53:20 <cfields> robbak: i'm battling that exact issue right now
69 2014-12-31 06:53:38 <cfields> in my case, it comes from a busted clang. you might see the same in FreeBSD
70 2014-12-31 06:54:07 <robbak> Ah, well we do share problems with OSx, so that is quite likely. Do you have a fix?
71 2014-12-31 06:54:20 <cfields> yes, don't use clang 3.4 :)
72 2014-12-31 06:55:35 <cfields> for my issue, 3.3 and 3.5 are fine, 3.4 has a bug that causes visibility/weak external issues
73 2014-12-31 06:56:00 <robbak> Thanks cfields.
74 2014-12-31 06:56:10 <cfields> i tried bisecting a while back, but llvm/clang proved to be too much to handle
75 2014-12-31 06:57:02 <gmaxwell> cfields: any idea how exactly its malfunctioning here?
76 2014-12-31 06:57:22 <cfields> robbak: if you'd like to confirm that we're seeing the same thing: nm -m bad/bitcoind | grep out_of_range
77 2014-12-31 06:58:36 <cfields> gmaxwell: vaguely, it's deeper into compiler jargon than i can really understand
78 2014-12-31 07:00:03 <cfields> gmaxwell: typeinfo for exceptions gets munged, so they aren't caught properly
79 2014-12-31 07:00:38 <robbak> cfields: lits of results to that command - what should I be looking for?
80 2014-12-31 07:03:21 <cfields> robbak: sorry, sec.
81 2014-12-31 07:06:27 <cfields> robbak: nm -m compat/libbitcoin_util_a-glibcxx_sanity.o | grep out_of_range | grep __datacoal_nt
82 2014-12-31 07:06:37 <cfields> if that shows "automatically exported" or so, you're gonna have a bad time
83 2014-12-31 07:06:48 <cfields> er.. automatically hidden
84 2014-12-31 07:08:54 <robbak> No results, cfields. By the way, whta does that -m argument do? our nm does not support it.
85 2014-12-31 07:10:00 <cfields> oh, heh, i suppose it wouldn't. it shows osx-specific symbol info
86 2014-12-31 07:11:26 <cfields> robbak: i suppose we should back up a bit. In glibxx_sanity, we intentionally cause an exception to be thrown, then catch it. My problem with clang3.4+osx is that the typeinfo for that exception is busted, so we fail to catch it.
87 2014-12-31 07:11:40 <cfields> it's worth taking a few secs to see if you're hitting the same thing
88 2014-12-31 07:13:18 <gmaxwell> cfields: super scarry that a catch(std::out_of_range) can just be silently busted; now I have an _new_ mental note on reasons to never use exceptions.
89 2014-12-31 07:14:04 <cfields> gmaxwell: well, something is going horribly wrong in the compiler. we catch it in the sanity check, but otherwise it surely wouldn't get very far anyway
90 2014-12-31 07:15:03 <robbak> OK, stepping through, it's in glibdxx_sanity_test().
91 2014-12-31 07:15:08 <cfields> robbak: sec
92 2014-12-31 07:15:53 <gmaxwell> cfields: you sure? I think in the codebase we don't explictly catch out_of_range anywhere.
93 2014-12-31 07:16:29 <cfields> robbak: http://pastebin.com/raw.php?i=Qxxri4Z1
94 2014-12-31 07:17:02 <cfields> gmaxwell: for this particular issue, all typeinfo info seems to be busted
95 2014-12-31 07:17:27 <cfields> gmaxwell: this is pretty exotic though, it's the linux->osx cross build. robbak's problem may be much simpler
96 2014-12-31 07:19:40 <cfields> gmaxwell: if you're interested, i'd be happy to share some info/dumps with you. debugging this one is far over my head. Also, it's fixed in clang 3.5, so it's hard to get motivated to pinpoint it :)
97 2014-12-31 07:21:19 <robbak> Still stepping, maybe for fun: confirmed that the fail is in sanity_test_range_fmt()
98 2014-12-31 07:22:21 <cfields> gmaxwell: also, if you're suspecting that i'm a flat-out idioit, i verified in the c++ spec that it must throw out_of_range in that case :)
99 2014-12-31 07:22:53 <cfields> sigh. the irony is thick in that typo.
100 2014-12-31 07:24:14 <gmaxwell> no, I already checked that. It's a screwed up scarry bug, but since it's fixed; I'm not sure what to do other than be thankful that we have some tests at startup.
101 2014-12-31 07:24:40 <gmaxwell> perhaps promote a test to compile time.
102 2014-12-31 07:25:50 <cfields> i assumed it was just an artifact of the wacky osx cross build. if it turns out that robbak is seeing something similar, it's scarier than i'd thought
103 2014-12-31 07:26:02 <cfields> yes, that makes sense
104 2014-12-31 07:28:49 <wumpus> if the compiler is broken *anything* can be broken, not just exceptions, it would be a better mental reason to never use software gmaxwell :)
105 2014-12-31 07:30:30 <s1w> let's just all start farming corn
106 2014-12-31 07:30:32 <wumpus> it could as well have been multiplication that was broken, do we detect that anywhere?
107 2014-12-31 07:30:40 <wumpus> yes :D
108 2014-12-31 07:31:07 <s1w> c
109 2014-12-31 07:31:07 <s1w> we can probably remove mtgox from topi
110 2014-12-31 07:31:08 <s1w> lol
111 2014-12-31 07:31:38 <gmaxwell> wumpus: fair I suppose, but otoh, you wouldn't see a compiler make it into production that miscompiled multiply. :P
112 2014-12-31 07:32:01 <s1w> bettah
113 2014-12-31 07:32:07 <michagogo> Hm, why single out those two services?
114 2014-12-31 07:32:21 <s1w> i'm too lazy to type the stuff i need to op up
115 2014-12-31 07:32:22 <michagogo> Can you help me with BitPay Insight?
116 2014-12-31 07:32:27 <cfields> wumpus: heh, if you remember correctly, you argued for adding those sanity checks. i just added the silly/senseless checks rather than arguing with you about how ridiculous it was :)
117 2014-12-31 07:32:33 <michagogo> How about GAit?
118 2014-12-31 07:32:34 <s1w> oh no michagogo beat the system
119 2014-12-31 07:32:41 <michagogo> s1w: /CS topic
120 2014-12-31 07:32:48 <gmaxwell> michagogo: singles out things that have been frequent nussances here.
121 2014-12-31 07:32:58 <cfields> wumpus: so you won that round :)
122 2014-12-31 07:33:04 <gmaxwell> GAit manages to support its own users adequately, I guess!
123 2014-12-31 07:33:05 <wumpus> cfields: yes, I know just how crazy things can go :-)
124 2014-12-31 07:33:09 <michagogo> gmaxwell: really? Never seen anyone here ask for help with bitstamp
125 2014-12-31 07:33:29 <michagogo> Not any time recently, at least
126 2014-12-31 07:34:12 <cfields> wumpus: getting ready to push up a new osx toolchain that brings us out of the dark ages there. fixes all kinds of things i've wanted fixed for a while. next up is the linux toolchains
127 2014-12-31 07:34:23 <wumpus> cfields: the sanity tests have already caught quite some problems, if only overheating CPUs were so easy to detect as (obviously) broken compilers
128 2014-12-31 07:34:37 <cfields> (though, due to the bug above, we have to stay on clang 3.3 until 3.5 is easy enough to come by)
129 2014-12-31 07:34:54 <michagogo> Don't overheating CPUs shut off?
130 2014-12-31 07:34:58 <gmaxwell> wumpus: that odroid has had 4 copies of secp256k1 ./tests running for 732 minutes now without throwing an error. :-/
131 2014-12-31 07:35:06 <gmaxwell> michagogo: one could be so lucky.
132 2014-12-31 07:35:10 <warren> which odroid?
133 2014-12-31 07:35:26 <michagogo> gmaxwell: what do you mean?
134 2014-12-31 07:35:49 <wumpus> michagogo: either that or they start randomly corrupting your data
135 2014-12-31 07:35:52 <gmaxwell> warren: one here which reliably bombs out during IBD with apparent memory corruption.
136 2014-12-31 07:36:04 <warren> which model I mean
137 2014-12-31 07:36:06 <warren> I have one
138 2014-12-31 07:36:18 <gmaxwell> michagogo: we've had lots of reports from users over the years which ultimately were overheating issues.
139 2014-12-31 07:36:20 <s1w> 732 minutes is quite a while
140 2014-12-31 07:36:25 <wumpus> michagogo: depends on how much they're overheated I suppose, if they're against the threshold they can still somewhat function, if they melt they obviously shut down
141 2014-12-31 07:36:26 <gmaxwell> warren: It's a U2.
142 2014-12-31 07:36:41 <michagogo> Really? Haven't seen that happen
143 2014-12-31 07:36:56 <warren> I have access to a U2 if you need to rule out bad hardware
144 2014-12-31 07:37:13 <robbak> cfields: Yes, finally got around to adding your patch, and it is exactly that. The exception isn't being caught.
145 2014-12-31 07:37:18 <michagogo> Isn't that what happens when the computer just turns off and then shows a thermal alarm/warning on boot?
146 2014-12-31 07:37:24 <wumpus> gmaxwell: I've had similar issues with a x86 CPU whose fan I had to replace, some usage patterns worked fine, others caused strange behavior like corruptions and cores hard-hanging
147 2014-12-31 07:37:43 <warren> michagogo: in Linux with modern processors it will often surpass a thermal threshold and throttle in an attempt to save itself. you can see those events and MCE's in the Linux dmesg.
148 2014-12-31 07:37:52 <cfields> robbak: clang 3.4 ?
149 2014-12-31 07:38:08 <warren> michagogo: to my surprise my i5 desktop CPU went months without apparent crashes with the CPU fan unplugged...
150 2014-12-31 07:38:10 <robbak> cfields: I don't know how to check!
151 2014-12-31 07:38:13 <gmaxwell> warren: if you could build 0.10rc1 and try syncing the chain that would be good, but bad hardware seems pretty likely: wumpus has another quad core arm which synced without issue, and I successfully synced on a novena (yet another quad core arm)
152 2014-12-31 07:38:23 <cfields> robbak: heh, clang -v
153 2014-12-31 07:38:24 <wumpus> gmaxwell: and 'heavy CPU usage' wasn't the only distinction there, seemingly there's other factors in play that make work patterns suspicible to corruption
154 2014-12-31 07:38:25 <michagogo> warren: wow
155 2014-12-31 07:38:51 <robbak> cfields: Yes, 3.4.1
156 2014-12-31 07:39:01 <michagogo> warren: and: Ah, maybe that's why I'm not familiar with it
157 2014-12-31 07:39:11 <michagogo> I don't use Linux on bare metal
158 2014-12-31 07:39:11 <warren> gmaxwell: you have the optional fan for the U2? It CAN'T survive without it.
159 2014-12-31 07:39:20 <gmaxwell> michagogo: we've had people show up bitching that bitcoin was crashy garbage and after much prodding got them to check the hardware and found things like (e.g. in one instance:) the heatsink fell off their cpu.
160 2014-12-31 07:39:23 <wumpus> I have two quad-core ARMs, and two single-core ARMs synced with the chain
161 2014-12-31 07:39:36 <michagogo> gmaxwell: wow
162 2014-12-31 07:40:00 <michagogo> I guess it must have landed fan-side up?
163 2014-12-31 07:40:04 <gmaxwell> warren: it's sitting in proximity to one now, perhaps its not enough.
164 2014-12-31 07:40:19 <gmaxwell> michagogo: or just on its side? dunno.
165 2014-12-31 07:40:23 <warren> the U2 fan is super high speed
166 2014-12-31 07:40:26 <michagogo> (Unless the fan is in some kind of tube)
167 2014-12-31 07:40:31 <michagogo> gmaxwell: or that
168 2014-12-31 07:40:32 <cfields> robbak: ok, thanks. that's really good to know. I'll have another look tomorrow with that knowledge
169 2014-12-31 07:40:57 <warren> FWIW I gave up on the U2 in part because it wasn't stable even with adequate cooling.
170 2014-12-31 07:41:27 <michagogo> warren: is your TZ very negative or very positive?
171 2014-12-31 07:41:34 <warren> huh?
172 2014-12-31 07:41:41 <michagogo> warren: your time zone
173 2014-12-31 07:41:45 <warren> UTC-10
174 2014-12-31 07:41:47 <gmaxwell> warren: it's 'nice' to know their new board has even the heatsink optional.
175 2014-12-31 07:41:48 <michagogo> Iirc you're at some extreme edge
176 2014-12-31 07:42:03 <robbak> cfields: Looking at a bit of info, I see that this caused another problem: I had to add #define __STDC_LIMIT_MACROS to src/leveldb/helpers/memenv/memenv.cc because it expected a c99 macro.
177 2014-12-31 07:42:14 <gmaxwell> warren: he was trying to figure out if it was time to wish you happy new year, I susspect.
178 2014-12-31 07:42:42 <michagogo> (I ask because if it were positive, I'd suggest that you come over to #freenode-newyears, since you'd be pretty close to celebrating)
179 2014-12-31 07:43:03 <michagogo> (Though of course you can still join in the fun)
180 2014-12-31 07:43:26 <michagogo> (And get in before it goes out in a wallops or global and gets flooded)
181 2014-12-31 07:47:01 <op_mul> wumpus: without the fan plugged in? I ran a pentium 4 without any heatsink at all for a short period. only reason I stopped was that it smelled awful.
182 2014-12-31 07:48:03 <wumpus> gmaxwell: another reasono always start the reindex from the genesis block and not a commited-to utxo, validating the chain prior to now is a good CPU sanity check
183 2014-12-31 07:50:22 <wumpus> op_mul: in my case it was just extremely dusty, and maybe a bit loose, it hadn't completely fallen off. Longest I've had a x86 system running without any fans at all would be ~10 seconds.
184 2014-12-31 07:55:09 <wumpus> in principle ARM boards shouldn't require active cooling, although it depends on the heat design of the enclosure, the quad core ones can get really hot.. I have e.g. a 'HDMI stick computer' one that can be made to overheat, too (and never even tried bitcoind on it). Oh and I remember the Guruplugs...
185 2014-12-31 07:56:05 <op_mul> I don't like the "thermal design" of the odroid u3. it has the first load bearing capacitor I've ever seen in a piece of computer hardware. one side of it's heatsink rests on it.
186 2014-12-31 07:56:35 <gmaxwell> erp actually it's a U3 I have not a U2.
187 2014-12-31 07:59:09 <cfields> wumpus: #5582 reads like the rantings of a mad-man. Sorry about that. There are lots of things at play, but most of it is osx-specific, and their toolchain changes are tough to keep up with, let alone explain. I'm happy to expand on anything you'd like
188 2014-12-31 07:59:13 <wumpus> the fun story there was that they shipped this super-duper server edition with wifi, bluetooth, sata, 2x ethernet in a very small box with bad thermal design and if you use any two of those intensively that just overheated...
189 2014-12-31 08:01:45 <op_mul> could be worse. you could be trying to run bitcoind on a raspberry pi like half of reddit.
190 2014-12-31 08:01:49 <wumpus> cfields: my browser box doesn't seem to be responding, hearing that, it's probably good?
191 2014-12-31 08:02:04 <gmaxwell> op_mul: :-/
192 2014-12-31 08:02:26 <gmaxwell> op_mul: "fortunately" most of those people give up and never try running bitcoin core again. :-/
193 2014-12-31 08:02:30 <cfields> wumpus: heh
194 2014-12-31 08:02:32 <wumpus> cfields: I suppose it's too cold outside to do madman's rants on a crate, so github is an excellent venue where you can rant inside
195 2014-12-31 08:03:03 <gmaxwell> cfields: time to make the dependency building stuff start building the toolchain? :)
196 2014-12-31 08:03:20 <cfields> wumpus: for sure. in fact, i'd be the 2nd mad-man ranting on a bitcoin PR today :)
197 2014-12-31 08:03:25 <cfields> or was that a comment?
198 2014-12-31 08:03:47 <wumpus> cfields: no, I'm just jesting :)
199 2014-12-31 08:03:48 <cfields> gmaxwell: ah, i forgot to mention. this one self-hosts, somewhat
200 2014-12-31 08:04:51 <cfields> gmaxwell: not sure if you were joking, but that's part of what i'm aiming at here. osx grabs a pre-built clang, and builds its own binutils, so it's a really good candidate for working on deterministic builds without gitian
201 2014-12-31 08:05:27 <cfields> wumpus: aww... it was taken down: https://github.com/bitcoin/bitcoin/issues/5577
202 2014-12-31 08:06:40 <warren> Were there issues with the cross compile toolchain used for 0.9.3?
203 2014-12-31 08:06:49 <cfields> by "somewhat" self-hosting, i mean that it now uses the same clang binaries to build its own native binutils
204 2014-12-31 08:07:01 <cfields> since clang is fancy, and can target multiple arches/os's in one binary
205 2014-12-31 08:08:03 <cfields> warren: no, but it was already outdated when it was added. this brings us back in line with apple's current sdk/linker/toolchain releases
206 2014-12-31 08:08:09 <wumpus> cfields: huh, the whole issue was removed?
207 2014-12-31 08:08:47 <cfields> wumpus: yea, it was a Russian censorship rant. Nuked from orbit as spam, I guess
208 2014-12-31 08:09:11 <midnightmagic> by the by, is there someone mirroring or at least backing up the github issues database?
209 2014-12-31 08:10:16 <cfields> wumpus: hah! is your "HDMI stick" amlogic-based?
210 2014-12-31 08:11:01 <wumpus> cfields: it's a GK802, IMx6 based. Same chip as the cubox-i and hummingboard (which do work very well) but they hugely messed up the thermal design
211 2014-12-31 08:11:17 <cfields> ah, ok
212 2014-12-31 08:11:34 <wumpus> midnightmagic: I'm working on that (but no, not at this moment)
213 2014-12-31 08:11:39 <warren> amlogic is am-azingly bad.
214 2014-12-31 08:11:43 <midnightmagic> wumpus: thank you.
215 2014-12-31 08:11:59 <midnightmagic> (like, for the answer I mean :)
216 2014-12-31 08:12:44 <wumpus> midnightmagic: IIRC you can dump everything through the API, doesn't require any special privileges on the project
217 2014-12-31 08:13:08 <midnightmagic> wumpus: I was looking into doing it privately Because Github.
218 2014-12-31 08:13:30 <wumpus> midnightmagic: but it's one of the many things I started working on, then some other issue came in between, and I never came back to it :)
219 2014-12-31 08:13:34 <op_mul> midnightmagic: I do some basic integrity checks on a bunch of bitcoin related repos.
220 2014-12-31 08:13:57 <midnightmagic> wiki is a git repo, repo is a git repo, and I guess the API for dumping the rest of it. where do the code comments go?
221 2014-12-31 08:14:13 <gmaxwell> op_mul: there is no way to get the issues and pullreq data if github blocks our access, goes down, etc.
222 2014-12-31 08:14:14 <cfields> nnite
223 2014-12-31 08:14:22 <wumpus> midnightmagic: we don't use the wiki. All the comments are metadata which you can query through the API, and not in git.
224 2014-12-31 08:14:30 <wumpus> cfields: nn!
225 2014-12-31 08:14:41 <op_mul> gmaxwell: unless someone archives them, that is.
226 2014-12-31 08:15:22 <op_mul> my git bitcoin and bitcointalk archives are getting stale, but I'll re-run them soon.
227 2014-12-31 08:16:28 <wumpus> an (incremental) backup of that stuff is very feasible, see https://github.com/joeyh/github-backup
228 2014-12-31 08:16:45 <op_mul> I recovered a lot of the original sourceforce stuff before it was shuffled around as well.
229 2014-12-31 08:17:26 <op_mul> one of their mirrors was stuck, which was handy.
230 2014-12-31 08:20:16 <op_mul> wumpus: postprocessing things without APIs is the hard part. bitcointalk is annoying because a lot of the threads get jumbled by deleted posts, so it's an almost constant job rebuilding the databases.
231 2014-12-31 08:21:22 <wumpus> op_mul: ugh
232 2014-12-31 08:24:00 <op_mul> wumpus: could be worse, could be trying to archive twitpic.com. oh wait. we are. http://tracker.archiveteam.org/twitpic2/
233 2014-12-31 08:29:44 <midnightmagic> op_mul: i think there's a backup archive of some sort you can get from bitcointalk..?
234 2014-12-31 08:30:18 <op_mul> midnightmagic: ಠ_ಠ,
235 2014-12-31 08:30:30 <op_mul> better not be. there's one of the bitcoin wiki.
236 2014-12-31 08:31:44 <wumpus> op_mul: they're building an archive of silly selfies and cat pictures?
237 2014-12-31 08:32:48 <op_mul> yup.
238 2014-12-31 08:33:08 <op_mul> 100+ TB of them.
239 2014-12-31 08:35:42 <op_mul> you could say the same about bitcointalk. it's mostly altcoins and idiots, but there's some gems in the filth.
240 2014-12-31 08:36:39 <wumpus> but at least that's text, that sounds more manageable
241 2014-12-31 08:36:50 <Luke-Jr> eh? the wiki has cat pictures and selfies? O.o
242 2014-12-31 08:37:09 <wumpus> Luke-Jr: not that I know of at least :-)
243 2014-12-31 08:37:39 <Luke-Jr> ACTION confused
244 2014-12-31 08:38:14 <op_mul> Luke-Jr: wumpus was talking about my link, a team archiving twitpic, not bitcoin wiki.
245 2014-12-31 08:38:22 <Luke-Jr> oh
246 2014-12-31 08:38:31 <Luke-Jr> haha, I totally missed that
247 2014-12-31 08:39:51 <Luke-Jr> wumpus: btw, in case you missed it in the noise, the suspected consensus issue was not one
248 2014-12-31 08:43:53 <wumpus> Luke-Jr: oh, good to know!
249 2014-12-31 08:44:36 <Luke-Jr> ended up being a default copy constructor rather than the expected constructor due to a lack of pointer type
250 2014-12-31 08:45:43 <wumpus> so still a bug in the code, but not consensus critical?
251 2014-12-31 08:45:54 <Luke-Jr> a bug in the pull request I was using to reproduce it
252 2014-12-31 08:46:41 <Luke-Jr> so I submitted a new pull request (#5580) to prevent accidentally using the default copy constructor in the future (compiler error)
253 2014-12-31 08:47:18 <wumpus> always good to avoid bugs before they happen
254 2014-12-31 08:48:14 <Luke-Jr> indeed. I should probably rebase Eligius so it can't hit the issue. <.<
255 2014-12-31 09:23:11 <shesek> anyone feels like taking a look over my ephemeral-static ecdh implementation? https://github.com/shesek/ecdh-es/blob/master/src/ecdh.coffee / https://github.com/shesek/ecdh-es/blob/master/lib/ecdh.js
256 2014-12-31 09:23:50 <shesek> I'm pretty confident about it, but still feel a bit irky implementing that stuff myself :/
257 2014-12-31 09:45:11 <wumpus> Luke-Jr: re: #5534, are you going to rebase it or was it already included in some other pull?
258 2014-12-31 09:48:47 <Luke-Jr> missed the needs rebase, sec
259 2014-12-31 09:52:29 <Luke-Jr> wumpus: k, done
260 2014-12-31 09:57:59 <gmaxwell> shesek: I'm unfamilar with the language so it makes it hard to review (e.g. exactly how these comparisons work, e.g. can you avoid the auth by truncating it, wouldn't be obvious to me. Or even what data it covers. Looks like you're only using the X coordinate, so there is a modified message that would also decrypt (one with r having the opposite sign). It not clear how errors are handled here, e.g. d
261 2014-12-31 09:58:05 <gmaxwell> oes your ECC code check if the point is on the curve? and if its not, what happens when that point,scalar multiply fails? You could avoid the overhead of seralizing an AES IV by using your ecdh-keyed KDF to also produce the AES IV (this is doubly easy to do if you use AES-128, ... AES-256 is certificationally weaker than AES-128 in any case).
262 2014-12-31 09:59:04 <gmaxwell> (see also https://www.schneier.com/blog/archives/2009/07/another_new_aes.html )
263 2014-12-31 10:00:03 <Luke-Jr> wumpus: leveldb was updated last minute? or just forgot the changelog entry?
264 2014-12-31 10:00:37 <wumpus> Luke-Jr: no, not exactly last minute
265 2014-12-31 10:00:53 <wumpus> Luke-Jr: it mentions the commit id so you can check when it was
266 2014-12-31 10:02:17 <Luke-Jr> ah, October
267 2014-12-31 10:04:19 <shesek> gmaxwell, I'm not sure which comparisons you're referring to
268 2014-12-31 10:05:16 <shesek> if I understand correctly, using the X coordinate is the standard way to do ecdh, isn't it?
269 2014-12-31 10:05:55 <shesek> and the message is being checksummed, so a modified message wouldn't be considered valid by the recipient
270 2014-12-31 10:06:22 <gmaxwell> shesek: the hmac comparison, e.g. buff_eq e.g. that would be not secure if it was strcmp.
271 2014-12-31 10:06:24 <shesek> the internal libraries (ecurve/ecdsa from cryptocoinjs) do handle out-of-curve points properly (by throwing an error early)
272 2014-12-31 10:06:50 <shesek> gmaxwell, buff_eq converts the buffers the an hex string and compares that
273 2014-12-31 10:07:09 <gmaxwell> shesek: there is no "standard" way to do "ecdh" as a whole. And what you're implementing here is ECIES, not just ECDH.
274 2014-12-31 10:07:54 <gmaxwell> shesek: in any case, as I said, the scheme there is somewhat malleable, because it's ignoring the sign. This may or may not be problematic for your application.
275 2014-12-31 10:08:36 <gmaxwell> alternatively, using the whole serialization of r in your KDF would remove the malleability.
276 2014-12-31 10:15:20 <Luke-Jr> aha, the reason I didn't encounter that not-consensus-issue problem before was because it didn't affect 0.9.x, and was introduced in rebasing :D
277 2014-12-31 10:15:46 <Luke-Jr> now I realise what the dummy argument to the constructor was for..
278 2014-12-31 10:16:14 <shesek> gmaxwell, wouldn't the checksum (which is HMAC'd with a shared secret), already prevent malleability?
279 2014-12-31 10:16:56 <Luke-Jr> wumpus: rc2 today, by chance?
280 2014-12-31 10:21:17 <gmaxwell> shesek: r does not appear to be under your HMAC.
281 2014-12-31 10:22:17 <shesek> and yes, I was thinking of creating the IV based on the shared secret at some point, but end up not doing that because my sha512 hmac didn't provide enough data (not that its a problem to use another kdf, was mainly just being lazy)
282 2014-12-31 10:22:25 <gdm85> michagogo: I think in the example mentioned on wiki, it should go like this: https://github.com/gdm85/tenku/blob/master/docker/gitian-bitcoin-host/bin/build-bitcoin.sh#L54
283 2014-12-31 10:22:43 <gmaxwell> shesek: well it does provide enough data if you use AES-128-CBC.
284 2014-12-31 10:23:11 <gmaxwell> (which has a stronger general security story than AES-256-CBC, and its faster to boot.)
285 2014-12-31 10:23:19 <shesek> switching to aes128 does make that easier... though I understand that aes-256 being unfavorable is not that much of a clear cut
286 2014-12-31 10:23:57 <shesek> though, to my understanding, it is pretty clear that aes-256 doesn't provide any additional security, even if it doesn't harm it much
287 2014-12-31 10:23:59 <midnightmagic> it is if you think break velocity is measurable. :)
288 2014-12-31 10:24:14 <shesek> I'll switch over to it as the default, there's no reason not to, really
289 2014-12-31 10:24:32 <shesek> btw - I could also create an IV based on H(ephemeral_pubkey)
290 2014-12-31 10:25:05 <shesek> after all, it just needs to be unique, not secret... no reason to derive it from the shared secret
291 2014-12-31 10:25:09 <gmaxwell> shesek: moreover the curve you're using only has 2^128 security, so it's kind of a wash. The only reason to use AES 256 is because you'd hope that it has additional security margin, but it seems that it may well not. (as there are stronger, though inapplicable, attacks against AES-256).
292 2014-12-31 10:25:25 <gmaxwell> shesek: indeed, you could do that as well.
293 2014-12-31 10:26:28 <gmaxwell> shesek: alas, what you're doing is incompatible with what electrum does, I believe. But I suppose you don't care about compatiblity.
294 2014-12-31 10:27:05 <shesek> what does electrum use it for?
295 2014-12-31 10:27:25 <gmaxwell> placating users who ask for features they probably ought not ever use? :)
296 2014-12-31 10:27:54 <wumpus> Luke-Jr: nah, I won't get much work done today or tomorrow, so I don't think releasing rc2 is a good idea
297 2014-12-31 10:28:06 <gmaxwell> There is some general 'encrypt message' function; their first attempt at it was so throughly broken ... well it stopped just sort of finding a way to leak the secret key, but was bad in every other way.
298 2014-12-31 10:28:21 <Luke-Jr> oh right, Gregorian calendar new year
299 2014-12-31 10:28:28 <gmaxwell> Their next retry was much better.
300 2014-12-31 10:29:02 <wumpus> Luke-Jr: asap after that is fine with me, though
301 2014-12-31 10:29:05 <gmaxwell> But the first one is fun if you want to cryptanalyize something. I especially liked that there were some messages which would always be silently corrupted on decryption.
302 2014-12-31 10:29:21 <shesek> huh, how did that happen?
303 2014-12-31 10:29:32 <gdm85> shesek: padding can do that :)
304 2014-12-31 10:29:47 <gdm85> but no idea specifically about the one gmaxwell was referring to
305 2014-12-31 10:30:03 <gmaxwell> shesek: It was like a opus of cryptographic failure.
306 2014-12-31 10:31:04 <gmaxwell> here is the code they used (after replacing the rng with a cryptographic one): https://github.com/jackjack-jj/jeeq/blob/master/jeeq.py
307 2014-12-31 10:33:21 <shesek> haha, "Don't even think about implementing that into a working project." (from that project's README)
308 2014-12-31 10:33:56 <shesek> why do people keep messing up using a proper CSPRNG?
309 2014-12-31 10:33:59 <gmaxwell> shesek: well they _did_ go and replace the totally insecure RNG one with a real one.
310 2014-12-31 10:34:34 <shesek> well, yes, eventually...
311 2014-12-31 10:34:40 <gmaxwell> oh also, the readme appears to have been modified in response to people using it and me showing it insecure.
312 2014-12-31 10:34:46 <shesek> if this was widely use for anything, this could've caused some real damage to someone
313 2014-12-31 10:35:03 <gmaxwell> (but without fixing the software!)
314 2014-12-31 10:35:04 <gmaxwell> https://github.com/jackjack-jj/jeeq/commit/2ae25087bbb2261ec1a1939e38147690b7d22cd1
315 2014-12-31 10:35:14 <michagogo> gdm85: not sure if I'm missing context, but you'll want to checkout the tag you're building in the repo
316 2014-12-31 10:35:25 <gmaxwell> shesek: yea, it was deployed in electrum. Though fortunately, only for about an hour.
317 2014-12-31 10:35:28 <michagogo> So you're using the right descriptor
318 2014-12-31 10:35:40 <Luke-Jr> lol
319 2014-12-31 10:36:04 <michagogo> For example, building 0.9 with master's descriptor won't turn out well
320 2014-12-31 10:36:10 <gmaxwell> shesek: http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/5325B5BC.3030501@gmx.de/
321 2014-12-31 10:36:30 <gdm85> michagogo: yes. however I am not referring to tag issues. the only thing I would change in the wiki is that one could directly clone in gitian-builder/inputs/bitcoin
322 2014-12-31 10:36:49 <gmaxwell> yea, so that readme update was months and months after that incident.
323 2014-12-31 10:37:04 <gdm85> michagogo: so that once you run download(-linux) in depends, the configure and build done by the gitian descriptor will be all fine
324 2014-12-31 10:37:08 <gmaxwell> god knows why it wasn't replaced with something working. :-/
325 2014-12-31 10:37:09 <shesek> gmaxwell, well, I somewhat doubt that electrum's message encryption is being used much, especially right after when it was released, but probably not today either
326 2014-12-31 10:37:48 <Polylith> A bit related, I took a look at this link about Rijndael: http://www.cryptosystem.net/aes/#IsAesOk - Butt-ugly website, though.
327 2014-12-31 10:37:55 <shesek> so it probably didn't make any real damage... but still, people should be more responsible about what they release
328 2014-12-31 10:38:08 <gdm85> btw, I have updated my scripts to do gitian builds through a few docker images and a docker container -> https://github.com/gdm85/tenku/tree/master/docker/gitian-bitcoin-host
329 2014-12-31 10:38:11 <gmaxwell> shesek: it's not really useful in general. It's much better that people use PGP.
330 2014-12-31 10:38:15 <michagogo> gdm85: not sure which wiki you mean, but whatever you do, wherever you clone the repo, you need to check out whatever you're building
331 2014-12-31 10:38:35 <gdm85> I will also push the images directly on the Docker hub, although I prefer/advise people to read the source and build the images themselves
332 2014-12-31 10:38:47 <Polylith> I've generally been wary of using AES for a lot of years. In every instance where I was forced to use it, I also opted for AES-128 instead of AES-256
333 2014-12-31 10:38:51 <gmaxwell> Polylith: I doubt the sanity of the author of that website.
334 2014-12-31 10:38:57 <gdm85> with images on that public server it becomes a one-liner to make a gitian build of the core
335 2014-12-31 10:39:14 <gdm85> michagogo: here, the part that says "Optional: seed the gitian sources cache"
336 2014-12-31 10:39:27 <shesek> gmaxwell, I'm actually wondering about that myself - whether I should implement PGP (openpgpjs looks pretty good) or just go with ecdh with the keys I already have
337 2014-12-31 10:39:31 <gmaxwell> Polylith: next version of it will look like http://www.timecube.com/
338 2014-12-31 10:39:54 <gdm85> michagogo: (I might be wrong), but I thought that it's a bit misleading to not tell user that s/he needs to seed the same repo that will be used by the gitian descriptor
339 2014-12-31 10:39:55 <shesek> it would take much less overhead, too
340 2014-12-31 10:40:06 <gdm85> michagogo: or maybe there's another way, but I wasn't smart enough to see it
341 2014-12-31 10:40:19 <gmaxwell> shesek: for a narrow domain application, something 'custom' _may_ be okay. In that you're already solving authenticating the parties with each other some other way, due to application constraints you'll never need to deal with a gigabyte message, et.c
342 2014-12-31 10:40:42 <gmaxwell> (otherwise I would have bludgeoned you.)
343 2014-12-31 10:40:56 <Polylith> gmaxwell: Yeah, I remember that. Another nonsense work in similar vein would be "The 10th Dimension"
344 2014-12-31 10:41:25 <gdm85> michagogo: the change I'd propose would be: ```make -C inputs/bitcoin/depends download SOURCES_PATH=`pwd`/cache/common``` (given that you previously cloned in inputs/bitcoin)
345 2014-12-31 10:41:38 <gdm85> notice how ".." -> "inputs"
346 2014-12-31 10:41:40 <shesek> some of it is very application-specific - encrypting some contract data end-to-end, passing around application-specific tokens, etc
347 2014-12-31 10:41:47 <Polylith> gmaxwell: But otherwise, I don't care much about the author himself, and rather examine the merits of his claims.
348 2014-12-31 10:42:15 <gmaxwell> in other news, I'm down one node... don't have enough space anymore on this 60GB ssd that this host has.
349 2014-12-31 10:42:16 <wumpus> gdm85: but you don't need to clone there; you could have cloned anywhere, to get ie the descriptors
350 2014-12-31 10:42:31 <shesek> but for messaging, which is also inside the application but more general-purpose, I think that going with something that's compatible with PGP probably makes sense
351 2014-12-31 10:42:43 <gdm85> wumpus: yes, that's how I was doing it before. first clone to get the descriptors, then let gitian clone inputs/bitcoin on its own
352 2014-12-31 10:42:49 <Polylith> Similarly, I'm usually not someone who jumps on bandwagons, because I usually look for the cause and origin of why they become widespread.
353 2014-12-31 10:42:50 <wumpus> gdm85: it doesn't matter what tree you use as long as it is at the same commit that you're building
354 2014-12-31 10:42:58 <shesek> e.g. to make it possible to validate signatures using external softwares
355 2014-12-31 10:43:15 <wumpus> gdm85: the depends fetch only fetches to the specified source dir, it doesn't store anything in the tree itself
356 2014-12-31 10:43:19 <Luke-Jr> gdm85: -u bitcoin=/path/to/your/local/clone <-- good idea
357 2014-12-31 10:43:53 <gdm85> wumpus: yes, also that was OK. but as far as I (mis)understand, once you run make download-linux in depends, it also prepares something for the later build steps of the repo root (..), namely where the cached files will be found
358 2014-12-31 10:43:54 <wumpus> gdm85: though it needs to be at the same commit (just like the descriptors) to make sure you're getting the right depedencies
359 2014-12-31 10:45:21 <gdm85> wumpus: yes that's not the problem. if I clone in ~/bitcoin and run make -C ~/bitcoin/depends download-linux SOURCES_PATH=~/gitian-builder/cache/common, then the bitcoin that will be cloned automatically (by gitian?) will not know about the cache
360 2014-12-31 10:45:44 <gdm85> well at least this is what I have seen, hence I clone into ~/gitian-builder/inputs/bitcoin directly and issue was gone
361 2014-12-31 10:45:53 <wumpus> gdm85: it always knows about the cache, through gitian
362 2014-12-31 10:46:05 <wumpus> gdm85: you shouldn't have to do anything special there, if you have that's a bug
363 2014-12-31 10:46:23 <wumpus> gdm85: gitian itself will clone into that directory, normally you don't touch it yourself
364 2014-12-31 10:46:48 <gdm85> wumpus: ok, but can we exclude that `make download-linux` in depends will change some file that is later needed by the build?
365 2014-12-31 10:47:38 <wumpus> it regards it as its own clone; so it could, for example, do a complete wipe of the tree at any point (not that it does, but it's not part of any user servicable parts)
366 2014-12-31 10:48:07 <wumpus> gdm85: make download should *not* change any files in the tree itself, as I mentioned above
367 2014-12-31 10:48:30 <gdm85> ok, then will double-check my steps again
368 2014-12-31 10:48:35 <wumpus> gdm85: at least if you specify an explicit download path (which according to the instructions, you should)
369 2014-12-31 10:56:31 <michagogo> Also iirc gitian's clone isn't actually a clone
370 2014-12-31 10:56:54 <michagogo> A full clone, rather
371 2014-12-31 10:57:22 <michagogo> It does something to fetch less than a full clone would or something
372 2014-12-31 10:57:34 <gdm85> --depth=1
373 2014-12-31 10:57:36 <michagogo> ;;lucky gitian-builder github
374 2014-12-31 10:57:37 <gribble> https://github.com/devrandom/gitian-builder
375 2014-12-31 10:58:27 <gdm85> it doesn't clone again if it finds an existing one in inputs/bitcoin, but I don't want to rely on this "feature"
376 2014-12-31 10:59:35 <gdm85> although in a way it is an optimization to not have to clone twice
377 2014-12-31 10:59:53 <gdm85> but meh..simplicity and reproducibility is more important
378 2014-12-31 11:00:50 <michagogo> Looks like no `git clone`
379 2014-12-31 11:01:11 <michagogo> It inits, then fetches heads and tags from the remote url
380 2014-12-31 11:01:24 <michagogo> Then checks out the commit/tag given
381 2014-12-31 11:01:42 <michagogo> I guess to allow you to easily specify different URLs?
382 2014-12-31 11:03:18 <gdm85> interesting.
383 2014-12-31 11:03:47 <gdm85> btw, it's working fine with two repos (one in ~/bitcoin and the one automatically created by gitian in inputs). so my bad, sorry :s
384 2014-12-31 11:04:20 <gdm85> I'll go for the two repos way (one for the descriptor, one managed by gitian-builder). more forward-compatible
385 2014-12-31 11:04:24 <Luke-Jr> gdm85: I just told you how to not clone twice..
386 2014-12-31 11:04:45 <gdm85> Luke-Jr: that is a parameter for gitian?
387 2014-12-31 11:04:48 <Luke-Jr> yes
388 2014-12-31 11:05:00 <gdm85> nice. thanks
389 2014-12-31 11:13:55 <gdm85> Luke-Jr: https://github.com/devrandom/gitian-builder/blob/master/bin/gbuild#L240 <-- it will still do a fetch
390 2014-12-31 11:14:01 <gdm85> while before I was piggy-backing on this: https://github.com/devrandom/gitian-builder/blob/master/bin/gbuild#L237
391 2014-12-31 11:14:18 <gdm85> but nvm, overengineering
392 2014-12-31 11:16:36 <Luke-Jr> gdm85: a fetch from local
393 2014-12-31 11:17:24 <gdm85> Luke-Jr: yes. I am not pedant with file writes, but there is a tool in docker which allows to diff a running container against the base image it was spawned from. when you have many files changed it looks a bit nasty, that's all
394 2014-12-31 11:17:54 <gdm85> (in this case duplicate files)
395 2014-12-31 11:19:35 <gdm85> yeah I will use -u as you suggested, works neat
396 2014-12-31 11:22:21 <Jouke> I use ./bitcoin -onion=xxx -externalip=xxx.onion -discover, but I don't have any ipv6 nodes connected. (174 connections)
397 2014-12-31 11:23:36 <Jouke> Oh, version 0.9.1 apparantly
398 2014-12-31 11:25:02 <michagogo> Jouke: check the log to see if you're binding to IPv6?
399 2014-12-31 11:25:24 <michagogo> And if the IPv6 address is being discovered?
400 2014-12-31 11:25:41 <michagogo> Er, wait, this is the wrong channel. #bitcoin
401 2014-12-31 11:33:36 <gdm85> ./bin/gbuild:25:in `sanitize': unsanitary string in /home/debian/bitcoin (RuntimeError) <-- strange
402 2014-12-31 11:36:47 <gdm85> Luke-Jr: for some reason doesn't like -u bitcoin=/home/debian/bitcoin (it fails sanitization test at https://github.com/devrandom/gitian-builder/blob/master/bin/gbuild#L236)
403 2014-12-31 11:36:50 <gdm85> it wants it to be an URL
404 2014-12-31 11:37:04 <gdm85> I might submit an issue to allow local paths as URIs
405 2014-12-31 11:37:09 <Luke-Jr> odd
406 2014-12-31 11:37:12 <Luke-Jr> it worked for me
407 2014-12-31 11:37:41 <Luke-Jr> "dir" isn't -u
408 2014-12-31 11:38:56 <gdm85> Luke-Jr: my mistake.. I was using --commit
409 2014-12-31 11:39:07 <Luke-Jr> âº
410 2014-12-31 11:40:19 <gdm85> ACTION casts "Coffee"
411 2014-12-31 11:54:40 <Luke-Jr> woo, happy 4 years of bitcoin anniversary for me :P
412 2014-12-31 11:56:05 <Polylith> Luke-Jr: Roughly the same here. :)
413 2014-12-31 12:27:15 <sipa> Luke-Jr: what do you count as your start date?
414 2014-12-31 12:28:57 <Luke-Jr> sipa: sometime around now
415 2014-12-31 12:29:10 <Luke-Jr> Bitcoin Core says Jan 2, but it also says I got faucet first
416 2014-12-31 12:29:15 <Luke-Jr> so I'm guessing it took a bit to sync
417 2014-12-31 12:29:20 <Luke-Jr> or something
418 2014-12-31 12:29:39 <Luke-Jr> (first tx should be the 1 BTC from #freenode-newyears)
419 2014-12-31 12:29:39 <michagogo> Luke-Jr: well, you can check the block timestamps
420 2014-12-31 12:29:59 <sipa> iirc i started mining around decmber 19
421 2014-12-31 12:30:20 <sipa> i participated in slush's 3rd block afaik
422 2014-12-31 12:30:25 <Luke-Jr> :o
423 2014-12-31 12:30:34 <Luke-Jr> Jan 4 was my first CPU mining payout
424 2014-12-31 12:31:09 <Luke-Jr> I was too busy trying to figure out how to make TBC at first
425 2014-12-31 12:31:24 <Luke-Jr> and people kept telling me BTC was all there was..
426 2014-12-31 12:32:08 <michagogo> Luke-Jr: haha
427 2014-12-31 12:33:33 <Luke-Jr> I think I never got a straight answer re satoshis until I dug into the code myself <.<
428 2014-12-31 12:36:14 <michagogo> What about them?
429 2014-12-31 12:36:56 <Luke-Jr> michagogo: back then, everyone in #bitcoin-dev denied there was an integer unit
430 2014-12-31 12:37:09 <Luke-Jr> everything was BTC with 2 decimal places
431 2014-12-31 12:39:31 <sipa> lol
432 2014-12-31 12:40:04 <michagogo> omg
433 2014-12-31 12:40:08 <michagogo> really?
434 2014-12-31 12:40:15 <Luke-Jr> yes
435 2014-12-31 12:40:26 <michagogo> #bitcoin is one thing
436 2014-12-31 12:40:36 <michagogo> But in -dev? o_O
437 2014-12-31 12:40:45 <Luke-Jr> it was a different bitcoin world back then
438 2014-12-31 12:41:11 <Luke-Jr> sipa: you remember that? :P
439 2014-12-31 12:41:35 <michagogo> How far back do the logs go?
440 2014-12-31 12:41:50 <Luke-Jr> michagogo: also, back then, #bitcoin was p2p discovery only
441 2014-12-31 12:42:26 <michagogo> What do you mean?
442 2014-12-31 12:42:26 <sipa> Luke-Jr: nope
443 2014-12-31 12:42:48 <sipa> the #bitcoin irc channel just had bitcoin nodes joining it
444 2014-12-31 12:42:52 <Luke-Jr> hmm, my logs only seem to go back to 2011 Jan 20 :/
445 2014-12-31 12:42:57 <michagogo> As in, IRC seeding? I thought those were 100 different channels on some other network
446 2014-12-31 12:43:06 <Luke-Jr> michagogo: that was later/in transition
447 2014-12-31 12:43:08 <sipa> the 100 different channels was much later
448 2014-12-31 12:43:13 <sipa> and on a different server
449 2014-12-31 12:45:57 <Luke-Jr> I think lfnet was in use by Jan 2011, but only in the most recent versions
450 2014-12-31 12:46:07 <Luke-Jr> and still just the 1 channel
451 2014-12-31 12:52:10 <sipa> yup
452 2014-12-31 12:52:31 <sipa> and #bitcoin on freenode was unused, because earlier versions were etill joining there for seeding
453 2014-12-31 12:52:41 <sipa> (and did until years later)
454 2014-12-31 12:56:18 <gmaxwell> they still show up sometimes.
455 2014-12-31 12:56:43 <Luke-Jr> no ban on them?
456 2014-12-31 12:57:13 <gmaxwell> why bother?
457 2014-12-31 12:57:27 <Luke-Jr> ACTION shrugs
458 2014-12-31 12:57:47 <michagogo> Does anyone have any clue why this still exists? http://imgur.com/a/BJ0VI
459 2014-12-31 12:57:50 <Luke-Jr> hide exploitable IPs?
460 2014-12-31 12:58:24 <Luke-Jr> michagogo: well, I can see cases where you might want an alphabetic list of where you sent - just not the address book button
461 2014-12-31 12:58:50 <michagogo> At the very least the label is misleading
462 2014-12-31 12:59:15 <michagogo> "your Bitcoin addresses for sending payment" is weird
463 2014-12-31 12:59:34 <michagogo> Makes it seem like addresses that are yours that you use for sending
464 2014-12-31 13:00:15 <Luke-Jr> it makes sense to me. barely. could be improved I'm sure
465 2014-12-31 14:53:33 <gdm85> http://pastebin.com/raw.php?i=duM4Ba0Q <-- is this an acceptable difference?
466 2014-12-31 14:53:39 <gdm85> if yes I will submit a PR with my sigs
467 2014-12-31 14:53:48 <gdm85> I have absolutely no idea why the source archive checksum differs
468 2014-12-31 14:54:44 <gdm85> oh well, maybe it's the release name
469 2014-12-31 15:37:13 <michagogo> gdm85: the release difference is a problem
470 2014-12-31 15:37:24 <michagogo> The src tarball is known to be broken
471 2014-12-31 15:37:50 <gdm85> michagogo: but they are unrelated?
472 2014-12-31 15:38:02 <michagogo> gdm85: see https://github.com/bitcoin/bitcoin/commit/b3d67e1c34aa65a6d4587e3aa1b533b333efaeb4
473 2014-12-31 15:38:04 <michagogo> Yes, unrelated
474 2014-12-31 15:38:14 <michagogo> Release is because you gave gsign the wrong argument
475 2014-12-31 15:38:26 <gdm85> yes, I am going to fix that on next iteration
476 2014-12-31 15:38:31 <michagogo> Make sure you're following the release-process.md of the tag you're building
477 2014-12-31 15:38:48 <gdm85> I think I am pretty much there, if the source is known to be non-matching
478 2014-12-31 15:38:55 <michagogo> And the tarball seems to be a difference between those building in KVM and those building in LXC
479 2014-12-31 15:38:58 <michagogo> A permissions issue
480 2014-12-31 15:39:16 <michagogo> Which are you using?
481 2014-12-31 15:39:42 <michagogo> Actually, no need to tell me
482 2014-12-31 15:39:46 <michagogo> I see you're using lc
483 2014-12-31 15:39:48 <michagogo> lxc*
484 2014-12-31 15:39:58 <gdm85> actually it's LXC + vmbuilder
485 2014-12-31 15:40:02 <michagogo> (you match my source tarball)
486 2014-12-31 15:40:10 <michagogo> Hm? What do you mean?
487 2014-12-31 15:40:16 <gdm85> see https://github.com/gdm85/tenku/tree/master/docker/gitian-host and https://github.com/gdm85/tenku/tree/master/docker/gitian-bitcoin-host
488 2014-12-31 15:40:24 <gdm85> the former depicts how it works internally
489 2014-12-31 15:40:41 <gdm85> yeah, it's LXC - sorry
490 2014-12-31 15:40:54 <gdm85> I mean it's twice LXC (first layer docker, second gitian-builder's LXC)
491 2014-12-31 15:41:04 <gdm85> but doesn't matter for end result
492 2014-12-31 15:41:33 <michagogo> (Also, you don't need a precise i386 VM for Bitcoin Core anymore)
493 2014-12-31 15:41:59 <gdm85> because of ccache I guess?
494 2014-12-31 15:42:34 <gdm85> s/ccache/cross-arch building tool/
495 2014-12-31 15:42:59 <gdm85> well, good to know - that part can be skipped. although it still makes sense for a generic gitian building tool
496 2014-12-31 15:43:04 <gdm85> (a bit less for bitcoin project)
497 2014-12-31 15:43:45 <gdm85> the idea was to use generic gitian-host for other software as well, and the bitcoin-specific one to create signatures for each release
498 2014-12-31 15:45:06 <michagogo> gdm85: because of the depends system
499 2014-12-31 15:45:42 <gdm85> right. ubuntu is already multiarch-capable
500 2014-12-31 16:01:52 <gdm85> michagogo: re https://github.com/bitcoin/bitcoin/commit/b3d67e1c34aa65a6d4587e3aa1b533b333efaeb4 is it just an issue of permissions? has it been excluded that it's due to file order?
501 2014-12-31 16:02:13 <gdm85> I remember playing a bit with that e.g. put a canonically sorted list of files in a newlines-separated list, then use --files-from
502 2014-12-31 16:04:29 <gdm85> although in that case I was troubleshooting locale issues (locale influences default tar sorting order)
503 2014-12-31 16:11:38 <michagogo> gdm85: pretty sure cfields compared the two tarballs
504 2014-12-31 16:11:42 <michagogo> So, yeah
505 2014-12-31 16:11:49 <gdm85> k
506 2014-12-31 16:11:57 <michagogo> (you'll notice that we do sort the files)
507 2014-12-31 16:12:50 <gdm85> mmh..but that's not using --stable
508 2014-12-31 16:17:33 <gdm85> that doesn't matter anyways, can't have that issue
509 2014-12-31 16:21:18 <gdm85> the locale issue was addressed here: https://github.com/devrandom/gitian-builder/pull/57
510 2014-12-31 17:00:21 <tigershark> I'm trying to build Bitcoin using gitian and running into an error. I followed the tutorial, built the images successfully, then when running gbuild I get this "/home/ubuntu/build/bitcoin/depends: No such file or directory." Any ideas?
511 2014-12-31 17:04:47 <StephenM347> Does anyone understand the motivation behind Sergio Lerner's suggestion in the Bitcoin Development mailing list to allow the Coinbase TX to spend UTXOs and remove the restriction that it only have one input? My guess is it's a way to reward specific miners for their work, but I don't understand why you wouldn't just pay them AFTER their block was solved.
512 2014-12-31 17:17:16 <michagogo> tigershark: are you using the descriptors from the version that you're building?
513 2014-12-31 17:17:23 <michagogo> I'm guessing not
514 2014-12-31 17:17:48 <tigershark> michagogo, I believe so, I'll check it out to make sure
515 2014-12-31 17:18:17 <michagogo> tigershark: pastebin the build.log
516 2014-12-31 17:18:29 <michagogo> gitian-builder/var/build.log
517 2014-12-31 17:18:36 <michagogo> brb
518 2014-12-31 17:19:58 <tigershark> http://pastebin.com/AUjMCZ75
519 2014-12-31 17:29:22 <michagogo> tigershark: looks to me like you used the 0.10 (or master?) descriptors
520 2014-12-31 17:30:07 <michagogo> But the branch (or tag, or commit, or whatever) that you told it to build doesn't include the depends sysem
521 2014-12-31 17:30:08 <michagogo> system*
522 2014-12-31 17:30:18 <michagogo> So, either outdated master or 0.9
523 2014-12-31 17:30:28 <michagogo> tigershark: What's the gbuild command you used?
524 2014-12-31 17:32:10 <tigershark> ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
525 2014-12-31 17:32:41 <tigershark> I might have been building with 2 different versions, looks like the building process is different between the 2
526 2014-12-31 17:38:08 <michagogo> tigershark: what's VERSION?
527 2014-12-31 17:38:30 <michagogo> (I mean, what are its contents?)
528 2014-12-31 17:39:48 <tigershark> 0.9.3rc2
529 2014-12-31 17:40:30 <michagogo> tigershark: there's your problem
530 2014-12-31 17:40:52 <michagogo> You're using the 0.10 descriptors (=build script, etc)
531 2014-12-31 17:40:57 <michagogo> tigershark: Also, why 0.9.3rc2? o_O
532 2014-12-31 17:41:15 <michagogo> Anyway, to fix it you'll want to do this:
533 2014-12-31 17:41:32 <michagogo> pushd ../bitcoin && git checkout v$VERSION && popd
534 2014-12-31 17:42:40 <tigershark> ah thanks, I'll try that
535 2014-12-31 17:43:03 <michagogo> tigershark: but why are you building v0.9.3rc2?
536 2014-12-31 17:43:15 <tigershark> not sure why I'm building on 2 versions, been a long morning :D
537 2014-12-31 17:43:28 <tigershark> I wanted to build v10 but didn't see it
538 2014-12-31 17:43:33 <michagogo> tigershark: but why are you building v0.9.3rc2?
539 2014-12-31 17:43:37 <michagogo> er
540 2014-12-31 17:43:40 <michagogo> that's v0.10.0rc1
541 2014-12-31 17:43:48 <michagogo> the latest *release* is v0.9.3
542 2014-12-31 17:43:53 <tigershark> yeah, I'm trying that right now
543 2014-12-31 17:43:56 <michagogo> And what do you mean "didn't see it"?
544 2014-12-31 17:44:09 <tigershark> I did a git fetch and didn't see any tags for v10
545 2014-12-31 17:44:26 <tigershark> so I went with the "newest" one, which was obviously wrong
546 2014-12-31 17:44:30 <michagogo> And whatever you do, you should be following release-process.md as of whichever tag you're building, with that tag checked out
547 2014-12-31 17:44:37 <michagogo> tigershark: v0.9.3rc2 isn't the newest one
548 2014-12-31 17:44:42 <tigershark> gotcha
549 2014-12-31 17:44:58 <michagogo> The newest is v0.10.0rc1, the most recent release tag is v0.9.3
550 2014-12-31 17:47:37 <StephenM347> Does anyone understand the motivation behind Sergio Lerner's suggestion in the Bitcoin Development mailing list to allow the Coinbase TX to spend UTXOs and remove the restriction that it only have one input? My guess is it's a way to reward specific miners for their work, but I don't understand why you wouldn't just pay them AFTER their block was solved.
551 2014-12-31 17:48:24 <jcarter9753> BIP-70 Question: The response has no way of saying it has already been paid. For example if someone clicks the button twice.
552 2014-12-31 17:48:49 <jcarter9753> I have tried setting the amount to zero, however the wallet complains it is 'dust' and presents an error.
553 2014-12-31 17:49:11 <jcarter9753> I do not want to return a 404 for example as the payment does exist. and I dont think the wallet understands that
554 2014-12-31 17:49:31 <jcarter9753> I was considering setting the expires time to 'already expired' so that it appears invalid. Does this sound like a sensible approach?
555 2014-12-31 17:51:51 <jcarter9753> Yeah that sounds like the best approach, implemented :)
556 2014-12-31 17:56:59 <michagogo> StephenM347: no idea
557 2014-12-31 17:57:39 <michagogo> Only think I could think of was maybe to soft-fork in at some point in the future a rule that says that those inputs aren't released unless something happens
558 2014-12-31 18:00:21 <cfields> gdm85: yes, if the sort is busted because the locale doesn't match, better to fix the locale
559 2014-12-31 18:00:34 <cfields> since that's bound to cause other issues as well