1 2014-05-25 00:51:35 <Peezr> Any ideas on where I could find the stylizing/color of the InitMessage from the splash image on QT startup?
2 2014-05-25 00:51:49 <Peezr> "Loading block index..." text/stylizing.
3 2014-05-25 03:26:56 <andytoshi> gmaxwell: in PR 4226 you suggested i add the priority to the output of explainrawtransaction, is there a standard notion of priority?
4 2014-05-25 03:29:01 <gmaxwell> andytoshi: the floating point code used by the node itself. (dPriority)
5 2014-05-25 03:29:18 <andytoshi> cool, thx
6 2014-05-25 05:32:48 <Genitrus_> hmm, anyone here use the latest Armory wallet for OSX?
7 2014-05-25 05:32:52 <Genitrus_> http://pastie.org/9208308
8 2014-05-25 05:33:07 <Genitrus_> Am I doing something wrong, or is the OSX download, well, not matching the hash given by Alan?
9 2014-05-25 05:46:20 <arubi> Genitrus_, the sha256sum is OK for me, try re-downloading
10 2014-05-25 06:04:03 <Genitrus_> arubi: you did a sha256sum on OSX the same way i did? (shasum -a 256)
11 2014-05-25 06:04:41 <arubi> I'm using linux, so `sha256sum <file>`
12 2014-05-25 06:05:23 <Genitrus_> ok cool, tar.gz fine..ty for info!
13 2014-05-25 06:05:40 <arubi> np
14 2014-05-25 07:51:54 <nugget_bram> Does anyone have any experience compiling qt wallets (specifically 0.8.6) on mac?
15 2014-05-25 07:52:58 <nugget_bram> I've compiled an altcoin wallet successfully (No errors, command used was make
16 2014-05-25 07:53:22 <nugget_bram> Yet when I launch it, I get an error stating that it is "corrupted and damaged"
17 2014-05-25 07:53:35 <nugget_bram> If I navigate to the file withing contents, it works.
18 2014-05-25 07:53:38 <nugget_bram> Any ideas?
19 2014-05-25 07:55:40 <nugget_bram> You can't open the application "Altcoin-Qt" because it may be damaged or incomplete
20 2014-05-25 08:10:40 <wumpus> you should look for support for altwallets from your respective altwallet devs, not here
21 2014-05-25 08:11:56 <ThomasV> wumpus: huh?
22 2014-05-25 08:12:14 <wumpus> ThomasV: sorry, altcoin*
23 2014-05-25 08:12:22 <nugget_bram> This is my own wallet, and I wasn't sure where else to look
24 2014-05-25 08:12:31 <ThomasV> oh, you're answering to someone I guess
25 2014-05-25 08:13:52 <ThomasV> gosh, btc price is rallying
26 2014-05-25 08:16:07 <ThomasV> mr_burdell: still here?
27 2014-05-25 10:35:26 <chichov> how big are the currently supported multisig transactions in terms of #pubkeys?
28 2014-05-25 10:36:54 <shesek> chichov, up to 3 total public keys if you're using the multisig script in the output
29 2014-05-25 10:37:04 <shesek> and up to 15 (assuming compressed public keys) if you're using p2sh
30 2014-05-25 10:37:32 <chichov> shesek: I heard the first somewhere, but not of the latter
31 2014-05-25 10:37:38 <chichov> interesting to know though, thanks
32 2014-05-25 10:37:45 <shesek> chichov, the latter is somewhat of an oversight
33 2014-05-25 10:37:53 <shesek> it should be limited to 3, but that check doesn't apply when using p2sh
34 2014-05-25 10:38:11 <shesek> so you're basically only limited by the size of the script, which ends up as up to 15 public keys
35 2014-05-25 10:38:12 <chichov> it will be accepted by the node though?
36 2014-05-25 10:38:26 <shesek> it is accepted by the reference implementation
37 2014-05-25 10:38:43 <chichov> hm, what's the script size limitation?
38 2014-05-25 10:39:32 <shesek> hmm, I don't remember exactly
39 2014-05-25 10:40:03 <chichov> I only know of 10.000 bytes for scripts and 520 bytes for a data push
40 2014-05-25 10:40:26 <chichov> do you by any chance have a reference to those 15 pubkeys in P2SH?
41 2014-05-25 10:42:29 <chichov> maybe those 520 bytes come into play there somewhere, I'll take a look into that
42 2014-05-25 10:44:48 <chichov> I think I have it: https://bitcointalk.org/index.php?topic=559776.msg6464345#msg6464345
43 2014-05-25 13:46:00 <chichov> which JSON-RPC version does bitcoind use now?
44 2014-05-25 13:53:05 <edcba> hi !
45 2014-05-25 13:53:36 <Luke-Jr> chichov: I think it's *supposed* to be compatible with either 1 or 2
46 2014-05-25 13:54:04 <chichov> Luke-Jr: I'm just having some strange errors when using libjson-rpc-cpp, that's why
47 2014-05-25 13:54:49 <edcba> was reading about https://github.com/bitcoin/bitcoin/pull/4183 why not removing *all* unused code ? It's not like it is lost forever.
48 2014-05-25 13:55:34 <Luke-Jr> edcba: well, if you remove it, the history is lost/obscured even if readded
49 2014-05-25 13:55:43 <Luke-Jr> so it makes sense to only remove code that we don't *expect* to use
50 2014-05-25 13:57:06 <edcba> i prefer yagni but i see
51 2014-05-25 13:57:45 <Luke-Jr> edcba: my point is we have unused code that is there because we *know we will need it*
52 2014-05-25 13:57:53 <Luke-Jr> edcba: for example, HD wallet primitives
53 2014-05-25 14:00:03 <edcba> you can't predict future ! :)
54 2014-05-25 14:00:36 <edcba> anyway the history argumentation is enough for me
55 2014-05-25 14:03:03 <wumpus> edcba: do you think I do not provide clear enough arguments for the functions I want to keep?
56 2014-05-25 14:04:33 <wumpus> for one, if you define a certain api with Add/Remove/Edit primitives it makes no sense to remove one of them if it currently happens to be unused.. you can be fairly sure it's needed later and it just feels 'incomplete' otherwise
57 2014-05-25 14:06:23 <edcba> are all unused methods API ?
58 2014-05-25 14:06:23 <wumpus> (or we would have this CService object which allows getting and setting the host, but not setting the port!)
59 2014-05-25 14:06:34 <wumpus> have you read my post at all?
60 2014-05-25 14:07:06 <buZz> "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
61 2014-05-25 14:07:08 <wumpus> I provide rationale for *every single function* that he mentions that I don't want to see go
62 2014-05-25 14:07:09 <buZz> gaw
63 2014-05-25 14:07:13 <buZz> i just pulled current git >_<
64 2014-05-25 14:07:23 <buZz> i guess it should be fine
65 2014-05-25 14:07:32 <buZz> but shouldnt current git just be a stable version?
66 2014-05-25 14:07:43 <wumpus> buZz: no
67 2014-05-25 14:07:46 <gmaxwell> buZz: no, wtf. git is a source code repository for development.
68 2014-05-25 14:07:56 <buZz> heh ok
69 2014-05-25 14:07:56 <gmaxwell> If you want a release, download a release! :)
70 2014-05-25 14:08:00 <wumpus> check out a release tag if you want a stable version, for example v0.9.1
71 2014-05-25 14:08:26 <buZz> i just use tags for development
72 2014-05-25 14:08:31 <buZz> and master as stable
73 2014-05-25 14:08:37 <wumpus> the in-development version cannot be stable
74 2014-05-25 14:08:38 <buZz> but i guess taste is a personal matter
75 2014-05-25 14:08:54 <wumpus> well that's up to you isn't it
76 2014-05-25 14:09:10 <wumpus> i don't want to decide what you do in your own projects :P
77 2014-05-25 14:09:12 <buZz> yeah taste is up to me :P
78 2014-05-25 14:11:36 <Luke-Jr> wtf, tags *can't* be used for developmetn
79 2014-05-25 14:12:15 <buZz> branches*
80 2014-05-25 14:12:35 <wumpus> master is a branch like any other
81 2014-05-25 14:12:53 <wumpus> we use branches too, actually, for example there is the 0.9.2 branch where also active development happens
82 2014-05-25 14:13:00 <CodeShark> the only thing that makes master special is that it is automatically created when you init the repo
83 2014-05-25 14:13:44 <CodeShark> also, it is the default branch on github
84 2014-05-25 14:13:57 <wumpus> it's the default default branch (you can set it to something else)
85 2014-05-25 14:14:28 <CodeShark> wumpus: where were you hiding in Amsterdam? :p
86 2014-05-25 14:14:52 <CodeShark> I kept asking people to introduce me to you but nobody could ever find you
87 2014-05-25 14:17:49 <wumpus> oh :/
88 2014-05-25 14:18:15 <CodeShark> will you be in Vienna?
89 2014-05-25 14:19:24 <wumpus> whoa that's end of this month already, no, not planning to
90 2014-05-25 14:20:50 <Luke-Jr> ACTION really doesn't get why we have conferences so often
91 2014-05-25 14:21:00 <Luke-Jr> really, once or twice a year should be plenty..
92 2014-05-25 14:21:12 <CodeShark> geography is the only real justification
93 2014-05-25 14:21:14 <wumpus> I think we should have a development-focused bitcoin conference
94 2014-05-25 14:21:21 <CodeShark> but
95 2014-05-25 14:21:32 <CodeShark> yeah, agreed
96 2014-05-25 14:22:24 <Luke-Jr> can we lock CodeShark up and force him to finish multiwallet on B-Qt? :P
97 2014-05-25 14:22:26 <wumpus> yes geography is the largest issue, bitcoin 2014 was nice because it was really close to here
98 2014-05-25 14:22:44 <CodeShark> lol, Luke-Jr
99 2014-05-25 14:22:45 <wumpus> Luke-Jr: nah at this point I'd rather have him work on a good alternative wallet seperate of bitcoind
100 2014-05-25 14:23:02 <CodeShark> if you want multiwallet, I recommend https://ciphrex.com :)
101 2014-05-25 14:23:08 <Luke-Jr> wumpus: oh, are we modularising by abandoning B-Qt? XD
102 2014-05-25 14:23:27 <wumpus> Luke-Jr: it's not my preferable path, but it's the most realistic option at this point :p
103 2014-05-25 14:24:10 <CodeShark> full hierarchical account management, full multisig support, support for offline signing and watch-only accounts, websockets interface for inbound transaction processing
104 2014-05-25 14:24:28 <CodeShark> SPV
105 2014-05-25 14:24:29 <wumpus> Luke-Jr: there is just so much that has to be done for the bitcoin-qt wallet to even stay on par with other wallets
106 2014-05-25 14:25:50 <wumpus> for one: get rid of/sanitise the account system, implement SPV, implement HD wallets, improve scalability, etc etc etc
107 2014-05-25 14:26:02 <Luke-Jr> :/
108 2014-05-25 14:26:09 <wumpus> but experimentation is much better done in external projects
109 2014-05-25 14:26:26 <Luke-Jr> ACTION should try out CodeShark's wallet (again?) sometime
110 2014-05-25 14:26:41 <wumpus> and we're seeing that no one really dares to touch the Bitcoin Core wallet code :p
111 2014-05-25 14:27:03 <CodeShark> I'm glad to see bitcoind taking the direction of becoming a validation engine first and foremost
112 2014-05-25 14:27:20 <CodeShark> a validation/relay engine
113 2014-05-25 14:27:21 <wumpus> at this point improving the infrastructure is most important for bitcoin core
114 2014-05-25 14:27:46 <wumpus> and usability of the full node (making it easier to use/install/configure/monitor/etc)
115 2014-05-25 14:27:47 <CodeShark> mining software was rightly pulled out early on - and wallet software should also be separate
116 2014-05-25 14:28:19 <wumpus> CodeShark: I agree, but the problem is that currently none of the external wallets has a good RPC interface
117 2014-05-25 14:28:49 <CodeShark> wumpus: I'll give you a sneak peek at CoinSocket (the RPC/websocket daemon for the CoinVault project) soon :)
118 2014-05-25 14:29:48 <wumpus> see for example the questions/replies here, no one knows about your wallet CodeShark :p https://github.com/bitcoin/bitcoin/issues/4093
119 2014-05-25 14:30:30 <wumpus> armory has a preliminary json-rpc interface as well, but up until now was GUI only
120 2014-05-25 14:31:04 <wumpus> there is a lot of focus on wallets with a smooth user interface, but not so much with a nice API
121 2014-05-25 14:31:37 <wumpus> so you could certainly bridge a gap there
122 2014-05-25 14:33:00 <CodeShark> ok, just added a comment :)
123 2014-05-25 14:34:56 <CodeShark> btw, I'm currently looking for code reviewers and QA engineers - if anyone's interested, please PM me
124 2014-05-25 14:35:24 <wumpus> those are always hardest to find
125 2014-05-25 14:40:39 <CodeShark> the hard part is finding good ones that aren't already super busy with other projects
126 2014-05-25 14:40:42 <Luke-Jr> otoh, they're also easier jobs than new code, in theory
127 2014-05-25 14:41:08 <Luke-Jr> it's the ideal new-developer learning method
128 2014-05-25 14:41:15 <Luke-Jr> if only we had aspiring new developers regularly..
129 2014-05-25 14:41:50 <CodeShark> sipa had linked me an article a while ago about how writing code is actually easier than reading code
130 2014-05-25 14:41:53 <wumpus> well it's hard to find people that can do deep code reviews, not that code reviews from newcomers aren't welcome, as long as they don't only focus on coding style and such
131 2014-05-25 14:41:56 <Luke-Jr> there's at least a handful I've suggested to start on unit tests and review, but I don't think I've seen any of them actually do it :|
132 2014-05-25 14:41:58 <CodeShark> I forgot the link
133 2014-05-25 14:42:14 <wumpus> writing unit tests can be easy *and* very useful
134 2014-05-25 14:43:08 <wumpus> yes, reading code is difficult, or at least unpleasant to a lot of people
135 2014-05-25 14:43:45 <CodeShark> it's a skill that many developers don't fully develop
136 2014-05-25 14:44:25 <CodeShark> I'd venture to say most :)
137 2014-05-25 14:44:49 <wumpus> you'd expect it to be more common in open source though, where in many cases there is not much documentation beyond the code :)
138 2014-05-25 14:45:20 <CodeShark> absolutely - I've gotten better at it as a result of working on open source projects
139 2014-05-25 14:51:00 <CodeShark> http://theworldchanging.com/content/reading-code-harder-writing-code
140 2014-05-25 14:52:07 <CodeShark> I think it was that Joel Spolsky article
141 2014-05-25 14:53:25 <CodeShark> which is actually about why rewriting code from scratch is often a mistake
142 2014-05-25 15:00:33 <CodeShark> I don't necessarily completely agree with the article
143 2014-05-25 15:01:04 <CodeShark> old code doesn't rust - but you do run into other problems, such as scalability and maintainability
144 2014-05-25 15:01:52 <CodeShark> and cost of adding new features
145 2014-05-25 15:03:59 <CodeShark> also, it is often possible to use the experience in implementing the first version to much more quickly reimplement it without making the same mistakes
146 2014-05-25 15:04:58 <CodeShark> the second time around you're probably a better programmer anyhow, with better skills, techniques, and tools
147 2014-05-25 15:05:59 <CodeShark> but there's certainly a place for incremental refactoring
148 2014-05-25 15:06:13 <CodeShark> especially in projects involving a large number of developers
149 2014-05-25 15:09:03 <CodeShark> or in situations where you no longer have the same developers who wrote the original code
150 2014-05-25 15:26:31 <Luke-Jr> it's helpful when code is modular enough that a given function is obviously right or wrong
151 2014-05-25 16:04:49 <jcorgan> ^^
152 2014-05-25 16:05:09 <jcorgan> I still find it hard to navigate bitcoind source
153 2014-05-25 16:25:46 <wumpus> especially main.cpp/h is too much of a hodge-podge, the rest of the files pretty straightforwardly contain what is on the tin
154 2014-05-25 16:41:18 <sipa> ;;diff
155 2014-05-25 16:41:19 <gribble> 1.0455720138484837E10
156 2014-05-25 16:42:08 <Luke-Jr> ACTION quietly hacks E10 off the end
157 2014-05-25 16:42:51 <Luke-Jr> any ideas on debugging stack corruption that -fstack-protector -fstack-protector-all fails to catch? :/
158 2014-05-25 18:05:35 <justanotheruser> guard f40ph
159 2014-05-25 18:06:08 <justanotheruser> sorry
160 2014-05-25 19:12:29 <ryan-c> is there any any public documentation on how bitcoin is going to encrypt the blockchain on disk?
161 2014-05-25 19:16:11 <ryan-c> sipa: could you answer some questions for me on what constraints leveldb places on efforts to encrypt the blockchain?
162 2014-05-25 19:17:02 <ryan-c> is it feasible to do it without a modified version of leveldb?
163 2014-05-25 19:19:05 <sipa> i know of no plans to encrypt the blockchain data
164 2014-05-25 19:19:35 <sipa> there is some idea for obfuscating the chainstate database, whivh i assume is what you are talking about
165 2014-05-25 19:19:50 <sipa> the blockchain data isn't even stored in leveldb
166 2014-05-25 19:42:16 <ryan-c> sipa: Yeah, I was asking about obfuscation. What's stored in leveldb?
167 2014-05-25 19:42:49 <sipa> block/blk*.dat is the raw block data
168 2014-05-25 19:43:04 <sipa> block/index/* is a LevelDB database with a block index (information about individual blocks)
169 2014-05-25 19:43:26 <sipa> chainstate/* is a LevelDB database with all information about unspent transaction outputs at the currently best known block
170 2014-05-25 19:43:36 <sipa> it's the last one that would be obfuscated
171 2014-05-25 19:45:20 <ryan-c> sipa: Thanks. What changes when txindex=1, and why no obfuscation of the raw block data?
172 2014-05-25 19:46:02 <sipa> with txindex=1, the database in blocks/index/* also contains information about all historical transactions (instead of just historical blocks)
173 2014-05-25 21:12:36 <justanotheruser> y check f40ph
174 2014-05-25 21:12:44 <justanotheruser> sorry
175 2014-05-25 21:27:36 <devthink_> question for you EC heads: if pG + qG = (p+q)G, is pG + qG + rG = (p+q+r)G ???
176 2014-05-25 21:35:51 <sipa> devthink_: yes
177 2014-05-25 22:00:25 <devthink_> sipa: trying to add public keys, not getting valid results
178 2014-05-25 22:12:37 <scottansan> where can I read the latest on tree chains?
179 2014-05-25 22:13:04 <sipa> one pings petertodd