1 2014-12-03 00:31:19 <blur3d> Iâm working on a draft update to doc/translation_process.md, to generally make it easier for new comers to get started. If anyone would like to quickly read the draft and give feedback. https://gist.github.com/blakejakopovic/8d2ead05fd3f79059d97 (the current is at https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md)
2 2014-12-03 01:54:04 <phantomcircuit> leveldb seems to spend a lot of time doing mmap stuff
3 2014-12-03 01:54:31 <phantomcircuit> i haven't actually looked too closely but i kind of suspect there are significant gains to be had with a custom db
4 2014-12-03 02:07:15 <phantomcircuit> oh wait nvm i have txindex=1
5 2014-12-03 03:13:58 <phantomcircuit> so this is kind of interesting
6 2014-12-03 03:14:10 <phantomcircuit> i modified this client with a very recent block as the last checkpoint
7 2014-12-03 03:14:31 <phantomcircuit> but reindex with txindex is still taking quite a bit for the last blocks
8 2014-12-03 04:16:53 <crmarsh> I'm interested in programmatically querying the blockchain on my local machine--can anyone give me some pointers to get started? Would be much appreciated.
9 2014-12-03 04:19:22 <Luke-Jr> crmarsh: the blockchain is not a database that can simply be queried
10 2014-12-03 04:20:14 <Luke-Jr> so be more specific
11 2014-12-03 04:22:52 <crmarsh> Luke-Jr: sorry, I mean that I want to get a local copy of the blockchain on my machine in an encoding that I can interact with programmatically... e.g., if I were to download the most recent bootstrap.dat file and try to read the $n$ most recent blocks from it with a Python script
12 2014-12-03 04:23:34 <Luke-Jr> crmarsh: that doesn't make sense. do what with it programmatically?
13 2014-12-03 04:23:44 <Luke-Jr> and why just the most recent blocks?
14 2014-12-03 04:27:02 <crmarsh> Luke-Jr: not necessarily the most recent blocks, just as an example use case. What I'm asking is probably trivial: I just want a local copy of the blockchain on my computer and some way to read it so that I could build, e.g., a block explorer.
15 2014-12-03 04:29:14 <Luke-Jr> crmarsh: then you need to create a database with the data and indexes for a block explorer.
16 2014-12-03 04:29:35 <Luke-Jr> which won't make anything else necessarily any easier
17 2014-12-03 04:30:11 <Luke-Jr> the database you need to build for a block explorer is usually something like 1 TB using traditional database engines IIRC
18 2014-12-03 04:30:19 <Luke-Jr> I think BitPay's Insight does that
19 2014-12-03 04:34:50 <crmarsh> Luke-Jr: okay, thanks for the tips
20 2014-12-03 04:46:30 <blur3d> Luke-Jr: From what I learned yesterday, I drafted an updated doc/translation_process.md. If you want to take a look and let me how it looks. https://gist.github.com/blakejakopovic/8d2ead05fd3f79059d97 (the current is at https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md). If itâs ok, Iâll submit a PR.
21 2014-12-03 04:51:36 <Luke-Jr> blur3d: just submit a PR; you can revise it later based on comments
22 2014-12-03 04:51:55 <blur3d> Luke-Jr: Ok.
23 2014-12-03 05:06:50 <kruug> what files are at https://bitcoincore.org/depends-sources/sdks ?
24 2014-12-03 06:01:07 <lechuga_> Luke-Jr: currently 320G for toshi
25 2014-12-03 06:01:23 <Luke-Jr> lechuga_: ?
26 2014-12-03 06:01:36 <lechuga_> <Luke-Jr> the database you need to build for a block explorer is usually something like 1 TB using traditional database engines IIRC
27 2014-12-03 06:01:57 <lechuga_> but it could be trimmed significantly
28 2014-12-03 06:02:00 <phantomcircuit> wat
29 2014-12-03 06:02:04 <lechuga_> w/sufficient effort
30 2014-12-03 06:02:18 <Luke-Jr> lechuga_: keyword traditional db engines :P
31 2014-12-03 06:02:25 <Luke-Jr> lechuga_: I have an index down to like 2 GB :p
32 2014-12-03 06:03:46 <lechuga_> postgres is pretty traditional no?
33 2014-12-03 06:14:00 <phantomcircuit> sigh
34 2014-12-03 06:14:11 <phantomcircuit> gotta love stuff that fails to pipeline remote requests
35 2014-12-03 07:06:42 <Luke-Jr> reminder to self: make -j is bad for bitcoin core
36 2014-12-03 07:06:57 <lewellyn> heh.
37 2014-12-03 07:08:00 <gmaxwell> you don't have 64 gigs of ram?
38 2014-12-03 07:08:45 <CodeShark> anyone here have much experience with code signing on OS X?
39 2014-12-03 07:08:53 <Luke-Jr> gmaxwell: no, my system maxes out at 16 GB. which is usually okay.
40 2014-12-03 07:09:05 <Luke-Jr> gmaxwell: limiting -jN to my core count never is an issue
41 2014-12-03 07:10:11 <Luke-Jr> I'm sure -j9 is faster regardless of RAM, anyway
42 2014-12-03 07:10:42 <Luke-Jr> ironically, the main benefit I get from -j<null> is having the "CC" prints done before any warnings/errors print :p
43 2014-12-03 07:10:43 <lewellyn> only if you have ~8 cores.
44 2014-12-03 07:11:02 <Luke-Jr> maybe there's a way to get make to silence those altogether
45 2014-12-03 07:11:15 <Luke-Jr> lewellyn: 4 cores with hyperthreading
46 2014-12-03 07:11:46 <lewellyn> 9 isn't going to be as useful as 7, for most codebases, in that scenario
47 2014-12-03 07:11:59 <lewellyn> i've learned this a few times with my i7.
48 2014-12-03 07:12:22 <Luke-Jr> ACTION ponders if there's a good way to default this
49 2014-12-03 07:12:34 <lewellyn> it seems fakeN-1 is slightly more effective than fakeN.
50 2014-12-03 07:12:58 <lewellyn> most build systems will choose -j appropriately :P
51 2014-12-03 07:13:15 <lewellyn> it's 2014. stop building by hand! ;)
52 2014-12-03 07:17:32 <paveljanik> lewellyn: but the build system can't guess the workload affordable on the host system.
53 2014-12-03 07:17:53 <paveljanik> it is nonsense to let allow the build system itself to choose the appropriate -j n.
54 2014-12-03 07:18:13 <paveljanik> But it should allow to specify any n an work with it.
55 2014-12-03 07:18:50 <paveljanik> some people prefer to build with nice make -j1...
56 2014-12-03 07:20:00 <paveljanik> of course you can argue that people should not build on such systems, but...
57 2014-12-03 07:20:05 <lewellyn> paveljanik: many build systems choose a "sane" default that's overridden.
58 2014-12-03 07:20:17 <lewellyn> er that's easily overridden
59 2014-12-03 07:23:34 <Luke-Jr> um
60 2014-12-03 07:24:01 <Luke-Jr> why does getrawmempool have "currentpriority" and such, that have zero apparant relationship with the actual tx priority? O.o
61 2014-12-03 07:24:33 <Luke-Jr> lewellyn: I've never seen any build system choose -j for you
62 2014-12-03 07:25:15 <lewellyn> Luke-Jr: i've used a number of them.
63 2014-12-03 07:26:13 <phantomcircuit> lots of them will select the number of cores you have
64 2014-12-03 07:26:17 <phantomcircuit> i've never seen one select -j
65 2014-12-03 07:53:42 <Luke-Jr> any discussion lately about moving the ML off SF, and where? somewhat annoying I can't send to it atm..
66 2014-12-03 07:57:21 <jonasschnelli> CodeShark still OSX codesigning questions? i might be able to help
67 2014-12-03 08:18:47 <sipa> phantomcircuit: re very recent checkpoint patched client: what version and how recent blocks?
68 2014-12-03 08:28:55 <phantomcircuit> sipa, head
69 2014-12-03 08:29:13 <phantomcircuit> blocks in the 300k range
70 2014-12-03 08:29:24 <phantomcircuit> realized i had txindex on and a patch that calls mlockall
71 2014-12-03 08:29:44 <phantomcircuit> im guessing txindex causes leveldb activity to increase substantially...
72 2014-12-03 08:32:57 <sipa> yes, all db writes are cached and batched somewhat now
73 2014-12-03 08:33:04 <sipa> except txindex
74 2014-12-03 08:42:20 <Luke-Jr> wumpus: prioritisetransaction test: https://github.com/bitcoin/bitcoin/pull/5414
75 2014-12-03 08:44:27 <wumpus> Luke-Jr: very nice!
76 2014-12-03 08:44:48 <Luke-Jr> wumpus: well, it came out uglier than I had hoped - needs a bunch of extensions
77 2014-12-03 08:45:26 <wumpus> I'll have a look, but in general ugliness isn't that relevant for tests, a test is always better than no test
78 2014-12-03 08:45:45 <Luke-Jr> wumpus: the ugliness is in having to extend CreateNewBlock and getblocktemplate for it
79 2014-12-03 08:46:15 <wumpus> eh if you have to change core code for an rpc test that's not really acceptable
80 2014-12-03 08:46:17 <Luke-Jr> right now, there's no way for RPC clients to see the priority or adjusted fee
81 2014-12-03 08:46:41 <Luke-Jr> and getblocktemplate caches its results
82 2014-12-03 08:46:50 <CodeShark> hi
83 2014-12-03 08:46:59 <CodeShark> argh - wrong window :p
84 2014-12-03 08:47:14 <Luke-Jr> could force GBT to ignore the cache by mining a new block.. but that changes the priorities :<
85 2014-12-03 08:47:30 <Luke-Jr> (and then we'd need a way to have a transaction in the mempool that isn't mined..)
86 2014-12-03 08:48:02 <wumpus> yes, we'll need to think about how to do this, but this makes it much harder to merge
87 2014-12-03 08:48:21 <wumpus> well, no hurry
88 2014-12-03 08:48:31 <Luke-Jr> right
89 2014-12-03 08:49:41 <CodeShark> wow - the whole directory structure of the project has changed!
90 2014-12-03 08:49:46 <Luke-Jr> lol
91 2014-12-03 08:50:09 <Luke-Jr> speaking of that, what's the core/ rename waiting on at this point?
92 2014-12-03 08:50:50 <wumpus> yes we've made big strides in that regard
93 2014-12-03 08:51:10 <wumpus> although the biggest offender hasn't changed, main.cpp, is still a monolithic mess
94 2014-12-03 08:51:18 <CodeShark> lol - it's starting to have a vague semblance of modularity...but just vague :)
95 2014-12-03 08:51:23 <wumpus> Luke-Jr: post-0.10 sanity
96 2014-12-03 08:51:37 <sipa> Luke-Jr: can't prioritisetx flush the gbt cache (haven't looked at the code yet, this may not be relevant)
97 2014-12-03 08:51:45 <wumpus> CodeShark: the consensus code is starting to look much nicer, which is what it's all about anyway
98 2014-12-03 08:51:56 <Luke-Jr> wumpus: err, I don't think we really should do a release with that? :/
99 2014-12-03 08:52:19 <Luke-Jr> sipa: hmm, that might be a good idea
100 2014-12-03 08:52:59 <wumpus> Luke-Jr: I'm just afraid of regressions - moving around things this close before the release may say break the build system on some obscure platforms
101 2014-12-03 08:53:07 <Luke-Jr> wumpus: IMO releasing with a file named 'core' is like releasing with a file named 'C:\'
102 2014-12-03 08:53:53 <CodeShark> heh
103 2014-12-03 08:53:56 <wumpus> ah yes, doesn't the linux kernel automatically generate that file on a crash?
104 2014-12-03 08:54:01 <Luke-Jr> right
105 2014-12-03 08:54:31 <CodeShark> core really means core structures
106 2014-12-03 08:54:46 <Luke-Jr> CodeShark: my PR renames it to 'primitives'
107 2014-12-03 08:55:36 <lewellyn> aww. core -> structs would have been a TOTALLY confusing-to-nobody rename! ;)
108 2014-12-03 08:56:02 <CodeShark> specifically it refers to the basic data structures comprising the blockchain
109 2014-12-03 08:56:38 <Luke-Jr> lewellyn: lots of good options we could shed paint over for days
110 2014-12-03 08:56:42 <CodeShark> lol
111 2014-12-03 08:56:58 <lewellyn> Luke-Jr: there was a hint of sarcasm there. i think it got stripped with the evil bit.
112 2014-12-03 08:57:07 <Luke-Jr> :P
113 2014-12-03 09:01:49 <kgk> quick question, because I think I'm doing it wrong
114 2014-12-03 09:01:54 <kgk> are hashes all sent as little-endian?
115 2014-12-03 09:02:35 <kgk> e.g. block hashes, transaction hashes, merkle root, etc.
116 2014-12-03 09:02:40 <CodeShark> both :p
117 2014-12-03 09:02:43 <CodeShark> it's really annoying
118 2014-12-03 09:02:52 <kgk> sigh lol. all my code is wrong *facepalm*
119 2014-12-03 09:03:20 <kgk> thx :)
120 2014-12-03 09:04:51 <CodeShark> I don't quite understand what the reasoning was behind flipping the byte order before checking PoW
121 2014-12-03 09:06:58 <kgk> sshhhh don't question. praise be satoshi
122 2014-12-03 09:07:03 <CodeShark> lol
123 2014-12-03 09:07:34 <wumpus> it doesn't matter that much what would be the reasoning, he had to choose something, and whatever he would have chosen people would be wondering forever afterward why :)
124 2014-12-03 09:07:55 <CodeShark> well, the problem isn't the choice - it's the lack of global consistency
125 2014-12-03 09:08:02 <CodeShark> it's the mixed endianness that's annoying
126 2014-12-03 09:08:55 <CodeShark> it's stored one way in one data structure but represented the other way on another data structure
127 2014-12-03 09:10:11 <Luke-Jr> kgk: hashes aren't numbers. but they're byteflipped :P
128 2014-12-03 09:10:30 <kgk> lol #justbecause
129 2014-12-03 09:10:39 <Luke-Jr> CodeShark: reasoning? "let's just as the bignum library to interpret this data as a number" :P
130 2014-12-03 09:10:43 <wumpus> maybe he just did it to give people some irregularitities to wonder and complain about <:
131 2014-12-03 09:10:51 <CodeShark> there is a slight issue with the choice, though, since OpenSSL uses most-significant-byte-first as do DER, etc...
132 2014-12-03 09:10:59 <kgk> if I could make a suggestion, it would be good to call that out in the bitcoin spec documentation. I just got bitten by that
133 2014-12-03 09:11:11 <Luke-Jr> wumpus: the obvious "choice" is to interpret it in big endian. or at least don't print it backward.
134 2014-12-03 09:11:27 <Luke-Jr> kgk: this is one of MANY instancesd
135 2014-12-03 09:11:33 <Luke-Jr> kgk: like 30% of the docs would be warnings
136 2014-12-03 09:11:39 <kgk> lol
137 2014-12-03 09:11:47 <Luke-Jr> it's also exceedingly difficult to explain many of them in a way people understand
138 2014-12-03 09:12:04 <Luke-Jr> for example, some cases require every 4 bytes to be byteswapped
139 2014-12-03 09:12:27 <wumpus> middle-endian?
140 2014-12-03 09:12:28 <kgk> ...oh gawd. what instance is that?
141 2014-12-03 09:12:31 <Luke-Jr> wumpus: pretty much
142 2014-12-03 09:12:35 <kgk> lol middle-endian
143 2014-12-03 09:12:40 <Luke-Jr> kgk: the PoW
144 2014-12-03 09:12:52 <iwilcox> Inside-outian
145 2014-12-03 09:13:06 <kgk> Luke-jr: the "compact bytes"?
146 2014-12-03 09:13:09 <Luke-Jr> kgk: no
147 2014-12-03 09:13:23 <Luke-Jr> kgk: every 4 bytes of the block header get swapped during the hashing
148 2014-12-03 09:13:31 <iwilcox> I think lots of hash papers quite deliberately leave byte order of the result out of it, not even hinting at a preference.
149 2014-12-03 09:13:49 <Luke-Jr> iwilcox: the result is always supposed to be a byte array
150 2014-12-03 09:13:52 <iwilcox> That's just from a bit of browsing of functions on WP a while back though, ICBW
151 2014-12-03 09:13:52 <kgk> I have no idea how my block hash comes out right. I think I'm just getting lucky lol
152 2014-12-03 09:14:03 <Luke-Jr> iwilcox: SHA2 explicitly defines that the output must be in big endian, and opaque to the user
153 2014-12-03 09:14:37 <Luke-Jr> iwilcox: although it doesn't *say* "big endian", it describes it
154 2014-12-03 09:15:05 <CodeShark> crypto primitives are generally treated as big endian in practically all major crypto libraries
155 2014-12-03 09:15:25 <CodeShark> and in the encoding standards
156 2014-12-03 09:16:26 <Luke-Jr> CodeShark: everything sane is big endian ;)
157 2014-12-03 09:16:32 <CodeShark> heh
158 2014-12-03 09:19:35 <gmaxwell> ACTION repeats the advice that if _byte order_ is your biggest problem in bitcoin, you're either doing really well; or your doomed and all your code is wrong, because there is so much more subtle and detailed than a totally common data handling issue that every systems programmer must deal with to the extent that compilers come with builtins for high(er) performance byteswapping.
159 2014-12-03 09:20:13 <CodeShark> it's certainly not my biggest problem with bitcoin - but it's a pretty unnecessary one and one that was easy to foresee up front
160 2014-12-03 09:21:20 <kgk> I'd still like to see a sentence in the bitcoin spec that says "hashes are little-endian". Maybe I just missed it?
161 2014-12-03 09:21:23 <CodeShark> as far as taking issue with Satoshi, my biggest problem (or perhaps opportunity) is that any substantial innovation on his ideas requires complete reimplementation of huge chunks of code or hideous patching :p
162 2014-12-03 09:22:19 <CodeShark> predictably, the vast majority of forks just tweak superficial crap
163 2014-12-03 09:22:22 <wumpus> kgk: feel free to add it then, isn't the document open source?
164 2014-12-03 09:22:37 <kgk> oh is it? I suppose it is a wiki. yeah I'd love to :)
165 2014-12-03 09:24:16 <wumpus> (I'm not sure what 'spec' you're talking about, there's https://bitcoin.org/en/developer-documentation but also a PDF floating around, which would be harder to patch up)
166 2014-12-03 09:24:40 <wumpus> thought the .tex for that is in github now I see https://github.com/minium/Bitcoin-Spec
167 2014-12-03 09:26:08 <kgk> I've been using this: https://en.bitcoin.it/wiki/Protocol_specification
168 2014-12-03 09:26:17 <blur3d> https://github.com/petertodd/python-bitcoinlib README has a note under âEndianness Gotchasâ. I havenât seen it in the bitcoin core docs.
169 2014-12-03 09:28:09 <kgk> hmm, how do I get permission to edit the wiki?
170 2014-12-03 09:28:52 <kgk> Under the "Common Structures" section, there is a sentence that says: "Almost all integers are encoded in little endian. Only IP or port number are encoded big endian."
171 2014-12-03 09:29:25 <kgk> I just want to change that to: "Almost all integers are encoded in little endian. Hashes are encoded little-endian as well. Only IP or port number are encoded big endian."
172 2014-12-03 09:29:32 <Luke-Jr> kgk: what username?
173 2014-12-03 09:29:36 <kgk> kgk
174 2014-12-03 09:29:58 <kgk> that sentence probably would have saved me this trouble :)
175 2014-12-03 09:30:15 <Luke-Jr> kgk: "hashes are little-endian" would be wrong, though ;)
176 2014-12-03 09:30:51 <kgk> I'll just add like 5 asterisks behind it
177 2014-12-03 09:30:55 <wumpus> "hashes are obfuscated by sending them in byte-reverse format" :p
178 2014-12-03 09:31:11 <Luke-Jr> kgk: you can edit now
179 2014-12-03 09:31:20 <kgk> thx!
180 2014-12-03 09:33:07 <kgk> How about "transaction and block hashes are encoded litle-endian as well". is that fair to say?
181 2014-12-03 09:33:16 <Luke-Jr> kgk: fwiw, I did make some attempt to explain it in the GBT specs, but I probably made the same mistake I just told you was wrong
182 2014-12-03 09:33:25 <Luke-Jr> kgk: no, they're not any endian
183 2014-12-03 09:33:35 <Luke-Jr> kgk: hashes are an array of 32 octets
184 2014-12-03 09:33:59 <Luke-Jr> kgk: in fact, there's nothing *to* say on the Protocol specification page
185 2014-12-03 09:34:07 <Luke-Jr> they're only reversed when being printed in hex
186 2014-12-03 09:34:29 <Luke-Jr> oh, and compared with the target
187 2014-12-03 09:35:28 <wumpus> and for comparison, specifying endian makes sense again
188 2014-12-03 09:35:47 <wumpus> as it is necessary to interpret the 'opaque binary' as number for that
189 2014-12-03 09:36:37 <kgk> all I know is that I have to reverse my hashes before writing them to the wire
190 2014-12-03 09:36:48 <kgk> and that appears to work
191 2014-12-03 09:38:25 <Luke-Jr> kgk: because "your hashes" are reversed from what they're really supposed to be
192 2014-12-03 09:38:55 <kgk> *OpenSSL's hashes
193 2014-12-03 09:40:59 <Luke-Jr> kgk: oh, you mean the SHA256d hash OpenSSL gives you needs to be reverse before going on the p2p?
194 2014-12-03 09:41:14 <kgk> yes
195 2014-12-03 09:42:06 <Luke-Jr> was it Bitcoin that reversed everything on p2p? or maybe it was Armagetron..
196 2014-12-03 09:42:37 <Luke-Jr> kgk: I'm not sure where that reversal is occurring
197 2014-12-03 09:42:54 <wumpus> it's in your wires reversing your bytes!
198 2014-12-03 09:43:11 <kgk> it's got to be when it's written to the wire.
199 2014-12-03 09:43:45 <kgk> if I just take all my hashes and flip them just before writing, it all works :)
200 2014-12-03 09:44:26 <kgk> and when reading too. I just flip it as soon as I read from the wire
201 2014-12-03 10:32:56 <wumpus> Luke-Jr: please rebase #5306
202 2014-12-03 10:34:09 <Luke-Jr> wumpus: in the middle of another branch atm, gimme maybe 30 min
203 2014-12-03 10:34:37 <wumpus> Luke-Jr: it's not *that* urgent, but just wanted to mention it here too in case you didnt notice github
204 2014-12-03 10:34:44 <Luke-Jr> ok
205 2014-12-03 10:40:23 <wumpus> Luke-Jr: you can't post to the mailing list?
206 2014-12-03 10:40:41 <Luke-Jr> wumpus: nope, SF is claiming I'm spam
207 2014-12-03 10:41:06 <Luke-Jr> https://sourceforge.net/p/forge/site-support/9062/
208 2014-12-03 10:41:56 <Luke-Jr> SF's server*
209 2014-12-03 10:42:19 <wumpus> I think it's due for some changes anyhow: split it into a mailing list for bitcoin-core spefic discussion and one for proposals that affect everyone (ie, such as bips)
210 2014-12-03 10:43:48 <wumpus> I'm also in favor of moving to another service if there is a better one; but discussions on where to move end up nowhere every time, ie, google groups would be an option but a lot of people don't like google
211 2014-12-03 10:45:02 <wumpus> Luke-Jr: I heard complaints about that before; yahoo users can't send to sourceforge lists either?
212 2014-12-03 10:47:47 <Luke-Jr> wumpus: dunno, I can't email Yahoo users either ironically
213 2014-12-03 10:48:28 <Luke-Jr> wumpus: I don't like Google either. :P Savannah/"non GNU" seems to work for BFGMiner, but it's much lower traffic
214 2014-12-03 10:50:04 <wumpus> anything that would require a lot of babysitting by me, such as hosting our own listserv, I'd rather not
215 2014-12-03 10:51:23 <Luke-Jr> Cons for Savannah: intensive review process required to get projects approved, and we only need MLs
216 2014-12-03 10:53:30 <Luke-Jr> wumpus: ok, rebase done
217 2014-12-03 11:03:19 <wumpus> I don't necessarily like google either but I trust them to get hosting a *public* mailing list right
218 2014-12-03 11:03:27 <wumpus> Luke-Jr: ok cool
219 2014-12-03 11:03:44 <Luke-Jr> wumpus: without forcing me to join Google+?
220 2014-12-03 11:04:05 <lewellyn> Luke-Jr: subscribe gmane to it. that's the usual approach :P
221 2014-12-03 11:04:07 <Luke-Jr> I seem to recall being unable to use Google Groups without Google+ lately
222 2014-12-03 11:04:15 <Luke-Jr> lewellyn: for posting?
223 2014-12-03 11:04:18 <lewellyn> mhm
224 2014-12-03 11:09:44 <Jouke> Luke-Jr: last time that happened to my own email, I had some slight misconfigurations of the mail server after I moved it to an other place.
225 2014-12-03 11:10:11 <Luke-Jr> Jouke: I haven't even upgraded mine in months, short of security patching
226 2014-12-03 11:19:02 <wumpus> 'abusing' another code hosting service like gnu savannah to provide mailinglists, I'm not sure. would be good to move away from that
227 2014-12-03 11:24:32 <Luke-Jr> kinlo runs mailing lists for GBT2 development, and pool operators; maybe he'd volunteer to run a few more
228 2014-12-03 11:25:51 <hearn> Luke-Jr: you need an account for any mailing list, the only question is how you admin it and what other stuff that account does
229 2014-12-03 11:26:09 <hearn> google groups is the only actively maintained mailing list software that doesn't suck, that i'm aware of
230 2014-12-03 11:26:25 <Luke-Jr> hearn: I don't need to join Google+ to use any other mailing list
231 2014-12-03 11:26:35 <hearn> seems mailing lists aren't really cool anymore. there's tons of web forums out there
232 2014-12-03 11:26:37 <sipa> you don't need Google+ for gmail groups
233 2014-12-03 11:26:55 <sipa> afaik an admin can even add any e-mail address to a google group
234 2014-12-03 11:27:25 <hearn> yeah anyone can subscribe without an account, i think
235 2014-12-03 11:27:28 <sipa> (though i'm not sure if/how you can sign up yourself without google account)
236 2014-12-03 11:27:29 <hearn> at least it seems to be this way for my own lists
237 2014-12-03 11:27:39 <hearn> https://groups.google.com/forum/?hl=en#!forum/lighthouse-users
238 2014-12-03 11:27:55 <hearn> if i open that in incognito window i see a link "subscribe to this group" that opens up a form with a captcha and email address input
239 2014-12-03 11:28:02 <hearn> so it does seem to be possible
240 2014-12-03 11:28:14 <hearn> also you can have google accounts without them being google+, i think. can't remember now.
241 2014-12-03 11:30:08 <Luke-Jr> hearn: hm, I can only apply to subscribe to that one - and perhaps more importantly, I'd need to agree to some long ToS I'd rather not spend time analyzing
242 2014-12-03 11:30:18 <Luke-Jr> seems like it has at least the same problem Google Code has
243 2014-12-03 11:31:14 <Luke-Jr> (granting Google a copyright license in a way that essentially makes them immune to GPL or similar requirements)
244 2014-12-03 11:32:12 <hearn> eh?
245 2014-12-03 11:32:34 <hearn> oops
246 2014-12-03 11:32:36 <Luke-Jr> hearn: the ToS requires you to basically give Google MIT-like terms to anything you submit
247 2014-12-03 11:32:38 <hearn> i sent you the wrong list :)
248 2014-12-03 11:32:41 <hearn> https://groups.google.com/forum/#!forum/lighthouse-discuss
249 2014-12-03 11:32:46 <hearn> can you subscribe to that one without approval?
250 2014-12-03 11:33:01 <hearn> Luke-Jr: to stop people sending emails and then claiming google owns them $$$ for copyright infringement
251 2014-12-03 11:33:04 <Luke-Jr> looks like it - though not without the ToS
252 2014-12-03 11:33:13 <lewellyn> hearn: that link you gave is useless.
253 2014-12-03 11:33:15 <lewellyn> To use Google Groups Discussions, please enable JavaScript in your
254 2014-12-03 11:33:18 <lewellyn> browser settings, and then refresh this page.
255 2014-12-03 11:33:18 <Luke-Jr> hearn: there are clauses for that which don't nullify GPL-like restrictions
256 2014-12-03 11:33:19 <hearn> when you run your own mailing list and have no money, this is something that can be ignored. but then your mailing list might not be so well run
257 2014-12-03 11:33:56 <Luke-Jr> hearn: in particular, Google doesn't need to make derived works or modify the post content
258 2014-12-03 11:34:30 <hearn> it's for things like auto linkification, etc. lawyers want boilerplate language that covers whatever the software needs to do and doesn't need to be constantly updated.
259 2014-12-03 11:34:52 <hearn> anyway, this is kind of silly. lots of people manage to use hosted mailing lists like this for decades with no problems ever reported.
260 2014-12-03 11:34:53 <Luke-Jr> maybe lawyers do, but users don't.
261 2014-12-03 11:34:58 <lewellyn> ACTION is against choosing a list interface which is designed to not be viewable in any user agent.
262 2014-12-03 11:35:34 <Luke-Jr> lawyers don't always have to get their way
263 2014-12-03 11:36:46 <hearn> i think the ToS is pretty readable, but whatever.
264 2014-12-03 11:38:53 <lewellyn> Luke-Jr: you might consider getting in touch with XtreamLab maybe?
265 2014-12-03 11:39:23 <Luke-Jr> lewellyn: ?
266 2014-12-03 11:39:33 <lewellyn> they do some hosting of mailing lists
267 2014-12-03 11:40:18 <Luke-Jr> hm, that's a point too - better to not rely on non-free software ;)
268 2014-12-03 11:40:33 <lewellyn> they use mailman, yes :)
269 2014-12-03 11:41:08 <lewellyn> as for the big names, only Launchpad is not totally unpalatable in my book for something like this. and that's a weird fit.
270 2014-12-03 11:41:30 <Luke-Jr> I didn't even realise Launchpad did mailing lists :o
271 2014-12-03 11:41:41 <lewellyn> i thought they did
272 2014-12-03 11:41:54 <lewellyn> sure enough
273 2014-12-03 11:42:02 <lewellyn> also using mailman
274 2014-12-03 11:42:38 <lewellyn> oh. nevermind. * Postings by people who are not Launchpad members are immediately discarded.
275 2014-12-03 11:42:46 <lewellyn> i knew there was a reason i had discounted them in the past.
276 2014-12-03 11:42:55 <lewellyn> it's pretty much the same as google in that regard.
277 2014-12-03 11:45:09 <lewellyn> but yeah. http://gmane.org/subscribe.php will probably help those who dislike random web interfaces for lists they don't sub to. :)
278 2014-12-03 11:45:25 <lewellyn> (they provide an nntp interface, which means you can do things like local searches)
279 2014-12-03 11:49:38 <lewellyn> but, basically, hosted mail lists is a sucky situation. period.
280 2014-12-03 12:54:53 <wumpus> unhosted mailing lists are even worse :)
281 2014-12-03 12:55:12 <sipa> hey let's just create a github repo that people can subscribe to, and post issues on
282 2014-12-03 12:55:15 <sipa> *ducks*
283 2014-12-03 12:55:21 <wumpus> just put everyone in the mailto list! :P it is the distributed way
284 2014-12-03 12:55:35 <sipa> we need mailcoin
285 2014-12-03 12:55:39 <wumpus> lol!
286 2014-12-03 12:55:59 <wumpus> the mailing list archive in a blockchain
287 2014-12-03 12:56:26 <JackH> since we are talking about this I have a number of suggestions
288 2014-12-03 12:56:34 <wumpus> 'mining' would add mails to the list, probably needs human intervention though against spam
289 2014-12-03 12:56:49 <JackH> I need chattting, templates and the obvious in-build-browser
290 2014-12-03 12:57:37 <wumpus> that sounds more like freenet, or retroshare
291 2014-12-03 12:57:38 <hearn> just use IRC for everything ;)
292 2014-12-03 12:57:59 <hearn> sipa: finally a legitimate use for OP_RETURN :)
293 2014-12-03 12:59:28 <wumpus> anyhow, this went exactly like the last five times someone brought up moving the mailing list :-)
294 2014-12-03 12:59:54 <wumpus> ACTION hugs sourceforge
295 2014-12-03 13:01:17 <Luke-Jr> [12:55:15] <sipa> hey let's just create a github repo that people can subscribe to, and post issues on <-- that's actually not a terrible idea IMO
296 2014-12-03 13:01:28 <paveljanik> +1
297 2014-12-03 13:01:45 <sipa> i wasn't being serious :(
298 2014-12-03 13:02:12 <Luke-Jr> sipa: it'd work though - threads are cleanly organised, and you can unsubscribe from them individually..
299 2014-12-03 13:02:16 <paveljanik> every good ideas comes from "I was not serious"...
300 2014-12-03 13:03:51 <wumpus> another option would be to use a git repository, and have each commit be a message :P
301 2014-12-03 13:04:29 <sipa> see, a blockchain
302 2014-12-03 13:05:04 <Luke-Jr> wumpus: that wouldn't email it
303 2014-12-03 13:05:04 <paveljanik> wumpus: this can't work. This way, people can't commit a complete history in a new commit ;-)
304 2014-12-03 13:05:20 <sipa> we just need a smtp git postcommit hook
305 2014-12-03 13:05:22 <wumpus> different discussions could happen on forks, and then later on they could be merged for a complete history
306 2014-12-03 13:05:43 <paveljanik> looks like new startup is going to happen 8)
307 2014-12-03 13:06:00 <sipa> well, every tool grows until it gains smtp support, right?
308 2014-12-03 13:06:10 <paveljanik> M-x smtp RET
309 2014-12-03 13:06:31 <wumpus> that used to be it, nowadays every tools grows until it has a fully programmable mini-os
310 2014-12-03 13:07:24 <paveljanik> or its own package manager for add-ons.
311 2014-12-03 13:07:28 <wumpus> yes, that
312 2014-12-03 13:07:33 <wumpus> and an app store
313 2014-12-03 13:08:25 <Luke-Jr> wumpus: is it intentional that larger numbers use the thin-space (to the left of the decimal point)?
314 2014-12-03 13:08:43 <wumpus> Luke-Jr: yes?
315 2014-12-03 13:08:55 <Luke-Jr> k
316 2014-12-03 13:08:56 <wumpus> Luke-Jr: hopefully only in the GUI though and not in RPC? :o
317 2014-12-03 13:09:01 <sipa> lol
318 2014-12-03 13:09:06 <Luke-Jr> wumpus: yes, only GUI afaik
319 2014-12-03 13:09:12 <Luke-Jr> I just thought it odd
320 2014-12-03 13:09:16 <sipa> please send me 0.012nbsp;34 BTC
321 2014-12-03 13:09:37 <paveljanik> ACTION can't work because of tears in his eyes...
322 2014-12-03 13:10:06 <wumpus> Luke-Jr: well unlike the locale-specific number formatting I had written people actually wanted this
323 2014-12-03 13:10:13 <Luke-Jr> sipa: to the right seems expected :p
324 2014-12-03 13:10:25 <Luke-Jr> wumpus: it's not a problem, I just wanted to check
325 2014-12-03 13:10:33 <sipa> i should try opening bitcoin-qt again
326 2014-12-03 13:10:48 <wumpus> Luke-Jr: I try not to make much sense of our user's preferences :)
327 2014-12-03 13:11:54 <Luke-Jr> are we no longer trimming excess zeros off the right side? O.o
328 2014-12-03 13:12:09 <wumpus> no
329 2014-12-03 13:12:30 <Luke-Jr> eww
330 2014-12-03 13:12:31 <Luke-Jr> can we at least have an option for that? :x
331 2014-12-03 13:12:35 <wumpus> this makes it clearer that bitcoins can be subdivided to 8 places
332 2014-12-03 13:12:40 <wumpus> no, we can't
333 2014-12-03 13:12:47 <Luke-Jr> :<
334 2014-12-03 13:14:54 <Luke-Jr> how about make them blend in with the background colour more? <.<
335 2014-12-03 13:15:21 <sipa> or have a glow effect around them when you hover over them? please?
336 2014-12-03 13:15:40 <wumpus> lol sipa
337 2014-12-03 13:15:50 <Luke-Jr> sipa: srsly? is it so unreasonable to want values readable?
338 2014-12-03 13:16:33 <sipa> no, but i don't have a strong opinion on ui issues
339 2014-12-03 13:16:41 <Luke-Jr> guess I can just have my TBC patch add the trim back in <.<
340 2014-12-03 13:16:54 <wumpus> having 8 fixed zeros makes it more readable, when you're used to it
341 2014-12-03 13:17:07 <wumpus> fixed decimal places*
342 2014-12-03 13:17:40 <sipa> or use mBTC/uBTC
343 2014-12-03 13:17:51 <wumpus> right
344 2014-12-03 13:18:17 <wumpus> uBTC has only two fixed decimal places
345 2014-12-03 13:19:42 <Luke-Jr> wumpus: makes it easier to miss that one of those zeros isn't a zero
346 2014-12-03 13:19:47 <wumpus> which matches most people's expectations; but *hiding* numbers isn't a good idea, it makes it seem like round numbers are somehow special
347 2014-12-03 13:20:21 <wumpus> and in practice most btc amounts look like 3.23421232 as it's as they're converted from a $ amount
348 2014-12-03 13:21:27 <wumpus> Luke-Jr: I'm fine with giving trailing zeros a different shade of color, but it may be non-trivial to do especially in the tables, requiring custom renderers and such
349 2014-12-03 13:21:40 <Luke-Jr> hm
350 2014-12-03 13:21:46 <wumpus> custom ItemDelegate
351 2014-12-03 13:21:47 <Luke-Jr> I thought CSS worked there
352 2014-12-03 13:22:07 <wumpus> no. CSS works in labels, not in tables
353 2014-12-03 13:24:19 <Luke-Jr> ACTION gives up
354 2014-12-03 13:24:30 <wumpus> so did we, you're just months later :)
355 2014-12-03 13:27:38 <Luke-Jr> lol XD
356 2014-12-03 13:33:01 <Luke-Jr> ACTION peers at using png images for text
357 2014-12-03 13:37:44 <wumpus> png? ugh :) there's a reason fonts use vector format these days
358 2014-12-03 13:47:56 <Luke-Jr> wumpus: yeah, I would have thought it was just right-aligned text :/
359 2014-12-03 13:53:35 <hearn> for gitian, are the instructions saying to use debian 7.4 still accurate? that's a pretty old release
360 2014-12-03 13:54:08 <sipa> i should go set up gitian again
361 2014-12-03 13:54:58 <hearn> i guess 7.7 will also work
362 2014-12-03 13:55:24 <Luke-Jr> yeah, 7.7 should be current
363 2014-12-03 13:55:36 <Luke-Jr> and just bugfixes on top of 7.4
364 2014-12-03 13:59:56 <Luke-Jr> ACTION ignores MillyBitcoin's trolling
365 2014-12-03 14:49:22 <hearn> i hate making decentralised apps
366 2014-12-03 15:11:41 <michagogo> sipa: haha
367 2014-12-03 15:12:32 <michagogo> BTW, wumpus, do you expect that we may have a new tag (0.10/0.9.4 rc?) within the next few days to a week?
368 2014-12-03 15:13:23 <michagogo> I need to wipe my HD and start over (restoring most things from a clone), and so won't have access to my VM for a bit
369 2014-12-03 15:13:34 <michagogo> Not sure how long it'll take me
370 2014-12-03 15:15:36 <wumpus> michagogo: next week probably
371 2014-12-03 15:15:46 <wumpus> (given that no serious problems come up)
372 2014-12-03 15:17:30 <michagogo> Okay, so I think I'll go ahead with it
373 2014-12-03 15:17:41 <michagogo> Worst case, my sigs will be a couple days late
374 2014-12-03 15:19:30 <gavinandresen> wumpus: I think https://github.com/bitcoin/bitcoin/pull/5368 is ready for merge, I canât think of any more ways of testing it.
375 2014-12-03 15:25:49 <chmod755> omg the facebook like button works via TOR
376 2014-12-03 15:32:59 <Eliel_> that facebook tor support gives me a feeling of a trojan horse. I mean, you can't use facebook without telling them who you are.
377 2014-12-03 15:33:18 <Diablo-D3> Eliel_: so turn abp on
378 2014-12-03 15:33:28 <Diablo-D3> and tell it to block facebook shit
379 2014-12-03 15:33:49 <wumpus> gavinandresen: ok, will take a look at it
380 2014-12-03 15:36:26 <Eliel_> Diablo-D3: Ghostery does that too.
381 2014-12-03 15:36:28 <wumpus> Eliel_: indeed - obviously don't log into facebook in a browser session where you intend to stay anonymous, doesn't matter whether that is over tor hidden service or not, facebook tracks you everywhere using cookies
382 2014-12-03 15:36:39 <hearn> haha
383 2014-12-03 15:36:53 <chmod755> Eliel_, I just found that 42 people liked a TOR blackmarket on FB
384 2014-12-03 15:36:53 <wumpus> Eliel_: same is true for every site where you identify yourself, of course
385 2014-12-03 15:37:00 <hearn> https://buyaccs.com/
386 2014-12-03 15:37:08 <hearn> or go buy some fresh fake facebook accounts
387 2014-12-03 15:37:19 <hearn> ready made! just add water and stolen pictures of cute girls
388 2014-12-03 15:37:47 <chmod755> i mean.... they really 'liked' the .onion address
389 2014-12-03 15:38:02 <wumpus> but for people that use tor to avoid their government's restrictive firewall it can make sense, it's obviously a different use case than internet black markets
390 2014-12-03 15:39:55 <michagogo> I ××××ש '×××קר ××' צ××× ×ש××פ×'קר ×× ×××× ××קצ ×× ×¢×§× ×××©× ×©××רק××
391 2014-12-03 15:39:56 <michagogo> erm
392 2014-12-03 15:40:14 <michagogo> I kinda wonder how much hashpower it took them to get that address
393 2014-12-03 15:40:41 <michagogo> (fun fact: if you accidentally use the wrong keyboard setting, just Google the string and it translates it for you)
394 2014-12-03 15:40:42 <wumpus> ie, all those british people that have or want to visit naughty sites >:
395 2014-12-03 15:41:01 <michagogo> wumpus: I think that's just for the creation of such content in the UK
396 2014-12-03 15:41:22 <michagogo> Not hosting or consumption
397 2014-12-03 15:42:44 <chmod755> michagogo, hah nice. didnt know about that
398 2014-12-03 16:23:33 <kruug> what files are at https://bitcoincore.org/depends-sources/sdks ? I was playing around with travis ci on a fork, but I can't get past that one step...
399 2014-12-03 16:27:20 <wumpus> kruug: necessary files for the travis build; eg the macosx sdk
400 2014-12-03 16:31:11 <kruug> wumpus: make files as well? That's what the error is that I'm seeing.
401 2014-12-03 16:49:04 <sipa> kruug: you shouldn't need any makefiles
402 2014-12-03 16:50:34 <kruug> sipa: this is the error from Travis CI: http://paste.debian.net/134755/
403 2014-12-03 16:51:41 <sipa> well there is a Makefile in that directory...
404 2014-12-03 16:52:39 <kruug> is that MakeFile from the website, or something that should be in git?
405 2014-12-03 16:52:54 <sipa> https://github.com/bitcoin/bitcoin/tree/master/depends
406 2014-12-03 16:53:00 <sipa> there's a Makefile there
407 2014-12-03 16:53:08 <sipa> so you're not running it against the right source tree
408 2014-12-03 16:54:22 <kruug> ah, so there's the issue. I think I borked it when I forked because it didn't pull all of the files. Thanks.
409 2014-12-03 18:21:50 <lechuga_> is the v3 supermajority check planned for 0.10?
410 2014-12-03 18:23:35 <lechuga_> wrt bip62
411 2014-12-03 18:27:00 <gmaxwell> lechuga_: No, BIP62 didn't make it into 0.10.0.
412 2014-12-03 18:27:07 <lechuga_> phew
413 2014-12-03 18:27:10 <lechuga_> thx
414 2014-12-03 18:27:17 <Luke-Jr> phew?
415 2014-12-03 18:27:27 <lechuga_> i can procrastinate a bit
416 2014-12-03 18:27:31 <Luke-Jr> if there are reservations about BIP 62, you should bring them up now
417 2014-12-03 18:27:39 <lechuga_> oh no, seems reasonable
418 2014-12-03 18:28:09 <lechuga_> im phewing at the lack of need for me to do anything about it right now codewise
419 2014-12-03 19:17:25 <z333andO_o> Eliel_: Keep in mind that you may want to protect _where_ you are without hiding _who_ you are.
420 2014-12-03 19:25:04 <mxlian> quit
421 2014-12-03 19:29:53 <Eliel_> z333andO_o: good point :)
422 2014-12-03 19:30:57 <Eliel_> still, facebook can probably figure that out unless you make sure they can't follow what you browse.
423 2014-12-03 20:43:53 <pylis> Hello, I am new to the dev community and bitcoin source. I am working on creating a non-monetary alternate chain (similar to how namecoin handles DNS). I am aware that altcoin discussion is off topic for this channel, but I am hoping to gain some insight into where to start poking around in the source. I have read the wiki page on alternative chains and know how I would like to structure transactions/blocks/etc but am unsure of the next steps.
424 2014-12-03 20:44:18 <pylis> any help on this, including where might be a better venue to ask, would be appreciated
425 2014-12-03 23:18:09 <dlax> Hi all, I am trying to create some new software that uses the block chain for consensus. I was hoping for some suggestions as to where to look in the source code of bitcoin to get started.
426 2014-12-03 23:19:49 <pylis> \msg dlax hey it's ben
427 2014-12-03 23:45:37 <lechuga_> dlax: main.cpp is a good start
428 2014-12-03 23:55:56 <programmarchy> evaluating bitcoinjs vs cryptocoinjs vs bitcore. anyone have an opinion?
429 2014-12-03 23:57:51 <lechuga_> my understanding is bitcore is best suited for use with node
430 2014-12-03 23:58:19 <lechuga_> and bitcoinjs might b a better fit for browser
431 2014-12-03 23:58:23 <lechuga_> but im parroting
432 2014-12-03 23:59:21 <kanzure> dlax: generally if you need to track blockchain data then look at walletnotify and blocknotify and alertnotify
433 2014-12-03 23:59:38 <programmarchy> lechuga_ that makes sense: bitcore has native bindings. although it also has js fallbacks so it's browserifyable i think.
434 2014-12-03 23:59:59 <kanzure> programmarchy: if you state your intentions then making good recommendations is easier