1 2013-12-08 00:07:58 <Denim-jdev> Reading page 8 on the recent paper on BTC scalability. There is an inequality stated to be true due to beta's monotonicity. Shouldn't the order be reversed though?
2 2013-12-08 00:08:05 <Ziantos> Any electrum devs on here?
3 2013-12-08 00:08:17 <Denim-jdev> ie as hash rate increases, the rate of block additions to the main tree should increase, not decrease
4 2013-12-08 00:10:36 <sipa> Ziantos: ping ThomasV
5 2013-12-08 00:10:54 <sipa> ThomasZ: are you ThomasV?
6 2013-12-08 00:12:10 <Ziantos> Anyways, I have a createrawtransaction that works in bitcoind but not in electrum.
7 2013-12-08 00:12:36 <Ziantos> And I know why but idk if it's a bug or not. :p
8 2013-12-08 00:13:32 <justanotheruser> bitcoin isn't being man in the middled again is it?
9 2013-12-08 00:14:32 <Apocalyptic> justanotheruser, that claim doesn't even make sense
10 2013-12-08 00:14:49 <justanotheruser> Apocalyptic: sorry, I meant bitcointalk
11 2013-12-08 00:15:00 <Apocalyptic> oh, possibly
12 2013-12-08 00:15:08 <ThomasZ> sipa: no
13 2013-12-08 00:15:22 <justanotheruser> Afraid to log in
14 2013-12-08 00:15:46 <Denim-jdev> bitcointalk has a valid certificate
15 2013-12-08 00:15:53 <Denim-jdev> so I'm going to guess...no
16 2013-12-08 00:44:34 <andytoshi> Denim-jdev: iirc beta is monotonically decreasing, that's why the inequality looks wrong
17 2013-12-08 00:44:36 <andytoshi> i noticed that too
18 2013-12-08 00:44:47 <andytoshi> because beta is 1/E
19 2013-12-08 00:56:04 <Denim-jdev> I didn't understand that bit either, because E is the set of all edges
20 2013-12-08 00:56:07 <Denim-jdev>
21 2013-12-08 00:56:07 <Denim-jdev> block tree.
22 2013-12-08 00:56:17 <Denim-jdev> but right after it said: ^
23 2013-12-08 00:56:42 <Denim-jdev> "beta is the rate of block addition to the main chain"
24 2013-12-08 00:57:33 <Denim-jdev> since lambda is the rate of block addition to the block tree, it seems like they should have the same monotonic order
25 2013-12-08 00:57:53 <Denim-jdev> anyway, off to sleep, thanks for pointing that out. I'll try and look into it / understand it when I wake
26 2013-12-08 01:03:31 <andytoshi> Denim-jdev: if you get this, I meant E as the expected value of tau, not the edgeset..
27 2013-12-08 01:27:33 <nanotube> andytoshi: might want to leave a message with memoserv or gribble. probably he won't check chanlogs.
28 2013-12-08 01:29:44 <andytoshi> oh, good call
29 2013-12-08 01:31:00 <andytoshi> ;;later tell Denim-jdev when i said beta is 1/E, i meant E as the expectation of the block time, not a set of edges
30 2013-12-08 01:31:01 <gribble> The operation succeeded.
31 2013-12-08 01:31:42 <m7a> any web devs who understand how to do bitcoin transaction protocol looking for a project?
32 2013-12-08 01:50:27 <Emcy> Increase the default -maxblocksize to 350,000 bytes. Increase the default space for high-priority transactions to 30,000 bytes.
33 2013-12-08 01:50:28 <Emcy> nice guys
34 2013-12-08 03:12:53 <treeprogram> how do I launch the bitcoin client from terminal?
35 2013-12-08 03:55:49 <shesek> Can I setup bitcoind to only allow using sendrawtransaction, and do nothing besides that?
36 2013-12-08 03:56:28 <kjj> wrapper
37 2013-12-08 03:57:00 <shesek> that would be helpful If I wanted to limit what 3rd parties could do with it
38 2013-12-08 03:57:19 <shesek> but I don't want it to relay transactions or store the blockchain at all; just connect to nodes and send them transactions
39 2013-12-08 03:57:30 <kjj> oh, then no
40 2013-12-08 03:57:40 <shesek> I just want it a pushtx service that does nothing else
41 2013-12-08 03:58:16 <kjj> you can piggyback on someone else's pushtx
42 2013-12-08 03:59:01 <shesek> yeah, that's what I was doing, but I just noticed that bc.i doesn't handle multisig transactions well :-\
43 2013-12-08 03:59:21 <shesek> (I was sure I tested this, dunno how it went live like that)
44 2013-12-08 03:59:37 <kjj> what's wrong with running your own node?
45 2013-12-08 04:00:21 <shesek> nothing wrong about it, but currently I'm on a server with an SSD that don't have enough space to hold the blockchain
46 2013-12-08 04:01:39 <shesek> so I'll either have to upgrade it (SSDs with lots of space are quite expensive) or get a separate server for that
47 2013-12-08 04:02:35 <kjj> spinning disks are rather cheap. actually, SSDs are pretty damn cheap too. Unless you have to buy a specific brand to fit your server
48 2013-12-08 04:03:39 <Apocalyptic> it would be nice to have a disablewallet modifier
49 2013-12-08 04:04:05 <Apocalyptic> would save some RAM space at least for a send-only node
50 2013-12-08 04:04:27 <kjj> less than you'd think
51 2013-12-08 04:04:59 <Apocalyptic> I estimate it at a couple of hundreds Mb, as litecoind does
52 2013-12-08 04:05:17 <kjj> last I checked, maxconnections was the dominant memory user
53 2013-12-08 04:05:27 <Apocalyptic> obviously
54 2013-12-08 04:06:07 <kjj> heh. it wasn't obvious to me. I still can't fathom what that memory is being used for
55 2013-12-08 04:07:12 <Apocalyptic> maintaining all the data structures relative to the peers, the state of their blockchain, the internal socket/connection data (should be minimal though) I guess
56 2013-12-08 04:08:05 <kjj> yeah, still don't see how that can be more than a couple dozen K per connection, hundreds with buffering
57 2013-12-08 04:11:32 <lechuga> is there a suggested web wallet library to use with node.js?
58 2013-12-08 04:11:48 <shesek> lechuga, bitcoinjs-lib, vbuterin's fork
59 2013-12-08 04:12:02 <lechuga> i dont need to run bitcoinjs-server as well?
60 2013-12-08 04:13:01 <shesek> depends on what you need, bitcoinjs-lib is not a server, but it can handle keys/address and constructing/signing transactions
61 2013-12-08 04:13:27 <shesek> bitcoinjs-server wasn't working very well for me when I tried that, but you can talk with bitcoind's api instead
62 2013-12-08 04:14:22 <lechuga> thx, have u looked at coinpunk?
63 2013-12-08 04:16:45 <shesek> nope, I haven't heard of it until now
64 2013-12-08 04:16:51 <lechuga> looks interesting
65 2013-12-08 04:17:45 <shesek> seems like its mostly an UI on top of bitcoind's api
66 2013-12-08 04:19:39 <lechuga> so people making stuff like satoshibet or whatever
67 2013-12-08 04:19:46 <lechuga> ar ethye most likely just running bitcoind
68 2013-12-08 04:19:54 <lechuga> and sending it rpc commands
69 2013-12-08 04:19:57 <lechuga> are they*
70 2013-12-08 04:22:58 <shesek> I don't know, but probably, yes
71 2013-12-08 04:23:26 <shesek> if that's all you really need, there's a "bitcoin" package on npm that can communicate with bitcoin'd jsonrpc api
72 2013-12-08 04:25:33 <lechuga> cool
73 2013-12-08 04:25:43 <lechuga> seems like thats my move, thx
74 2013-12-08 04:27:47 <sunspotbtc> can anyone tell me who signed the latest 0.8.6 test release http://downloads.sourceforge.net/project/bitcoin/Bitcoin/bitcoin-0.8.6/test/SHA256SUMS.asc
75 2013-12-08 04:27:57 <sunspotbtc> 7BF6E212
76 2013-12-08 04:28:52 <sunspotbtc> I'm trying to document bitcoind crashes on ubuntu but want to make sure I'm validating the source
77 2013-12-08 04:29:06 <sunspotbtc> and that shasum wasn't signed by gavin's sig that I can tell
78 2013-12-08 04:29:29 <Apocalyptic> sunspotbtc, it's Gavin
79 2013-12-08 04:29:37 <Apocalyptic> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x7BF6E212
80 2013-12-08 04:30:04 <sunspotbtc> oh!
81 2013-12-08 04:30:19 <sunspotbtc> http://bitcoin.org/gavinandresen.asc is outdated
82 2013-12-08 04:30:26 <sunspotbtc> Apocalyptic++ thanks
83 2013-12-08 04:30:41 <Apocalyptic> yeah, it seems he has a new one since November, 1st
84 2013-12-08 04:58:31 <lechuga> whats the memory usage expectations for bitcoind
85 2013-12-08 04:58:38 <lechuga> what are the*
86 2013-12-08 04:59:18 <lechuga> 1GB? 4GB?
87 2013-12-08 04:59:30 <lechuga> im thru late november and its already taking 36% of 1gb
88 2013-12-08 04:59:39 <lechuga> late november 2010*
89 2013-12-08 05:05:12 <andytoshi> you mean disk usage?
90 2013-12-08 05:05:26 <andytoshi> my .bitcoin is a little over 15Gb
91 2013-12-08 05:09:18 <lechuga> no i mean ram
92 2013-12-08 05:09:51 <lechuga> 15205 andy 20 0 1256m 519m 9004 S 5.7 50.7 1:50.39 bitcoind
93 2013-12-08 05:09:55 <lechuga> 50.7% of 1gb
94 2013-12-08 05:10:19 <lechuga> its on june 2011
95 2013-12-08 05:11:00 <lechuga> i assume its not too heavy on ram in steadystate when im all synced
96 2013-12-08 05:22:12 <Luke-Jr> lechuga: semi-random during IBD for now
97 2013-12-08 05:28:52 <lechuga> y random
98 2013-12-08 05:42:04 <lechuga> whats the deal with the testnet
99 2013-12-08 05:42:10 <lechuga> is it just a big parallel blockchain or wat
100 2013-12-08 06:10:03 <lechuga> looks like yes
101 2013-12-08 06:18:17 <shesek> yes, its a parallel blockchain with some different magic bytes and worthless coins used for testing
102 2013-12-08 06:19:51 <lechuga> are transactions allowed to have outputs > inputs or something?
103 2013-12-08 06:20:41 <shesek> no, all the rules are exactly the same as the regular main blockchain
104 2013-12-08 06:20:57 <lechuga> so how do i get coins to work with on testnet?
105 2013-12-08 06:20:59 <shesek> (except for the difficulty that drops to 1 after 20 minutes without a block)
106 2013-12-08 06:21:15 <shesek> you either mine some, which is very easy on testnet
107 2013-12-08 06:21:19 <shesek> or use a faucet
108 2013-12-08 06:21:27 <shesek> like http://testnet.mojocoin.com/
109 2013-12-08 06:21:28 <lechuga> faucet eh
110 2013-12-08 06:21:44 <lechuga> ah cool
111 2013-12-08 06:22:19 <shesek> you can run bitcoin-qt/bitcoind with -testnet to get it working on testnet
112 2013-12-08 06:22:31 <lechuga> yeah saw that part
113 2013-12-08 06:22:42 <lechuga> is the parallel blockchain the same size as production? :)
114 2013-12-08 06:22:54 <shesek> nah, its much smalle
115 2013-12-08 06:22:54 <shesek> r
116 2013-12-08 06:23:11 <lechuga> can it coexist with prod blockchain
117 2013-12-08 06:23:20 <lechuga> like can atoggle -testnet and have sane things happen
118 2013-12-08 06:23:24 <lechuga> can i*
119 2013-12-08 06:23:29 <shesek> <500mb
120 2013-12-08 06:23:54 <shesek> yes, all the data is saved separately
121 2013-12-08 06:24:05 <shesek> in a "testnet3" directory inside your bitcoin directory
122 2013-12-08 06:24:06 <lechuga> nice
123 2013-12-08 06:24:29 <shesek> and the "production blockchain" is usually referred to as mainnet
124 2013-12-08 06:24:34 <lechuga> ic
125 2013-12-08 06:25:41 <lechuga> i think im going to write a gambling portal just to get a good understanding for operating a mktplace
126 2013-12-08 06:25:45 <lechuga> then get more interesting
127 2013-12-08 06:27:46 <lechuga> took me half a day to figure out how to use node.js and get user account mgmt setup with express + mongo + passport
128 2013-12-08 06:27:56 <lechuga> last time i did webdev tomcat+jsp was the hotness
129 2013-12-08 08:35:58 <HaltingState> waht is a non-portable wallet?
130 2013-12-08 08:36:16 <HaltingState> configure: WARNING: Found Berkeley DB other than 4.8; wallets opened by this build will not be portable!
131 2013-12-08 08:44:57 <ThomasZ> HaltingState: I think its a bit of a misguided warning; it is meant to warn you that if the client is build with another version of the DB layer it may not be possibe to open your wallet.
132 2013-12-08 08:45:50 <ThomasZ> naturally, its pratically impossible to get berkley db 4.8, its way too old. And I think they are more compatible that the warning states.
133 2013-12-08 08:45:55 <HaltingState> so if i use later version of bitcoin
134 2013-12-08 08:46:01 <HaltingState> i might be doomed or have painful experiences
135 2013-12-08 08:47:01 <ThomasZ> If you use the same version of the DB software it will work.
136 2013-12-08 08:49:20 <ThomasZ> HaltingState: also, there is a 'backup wallet'. I haven't tried it, but I surely hope that avoids the versioning problem.
137 2013-12-08 08:50:29 <gmaxwell> ThomasZ: you're giving bad advice there.
138 2013-12-08 08:50:58 <ThomasZ> gmaxwell: please correct me
139 2013-12-08 08:51:02 <gmaxwell> it you use bdb >4.8 you will not be able to open the wallet again with the published binaries, they're incompatible.
140 2013-12-08 08:51:56 <gmaxwell> it's not impossible to use the 4.8 bdb, there is a ppa for ubuntu with it (though I can't walk you through it, not being an unbuntu user myself.)
141 2013-12-08 08:52:25 <gmaxwell> and no, the backup wallet doesn't avoid the versioning issue.
142 2013-12-08 08:52:50 <ThomasZ> for someone building the binary himself, thats not too big a deal, though. I think its Ok to use a newer version since its already hard to use 4.8 now...
143 2013-12-08 08:53:17 <ThomasZ> hmm, not being able to do a backup sounds like a problem that should be solved, no?
144 2013-12-08 08:53:34 <gmaxwell> limitation of BDB, and part of why all the official binaries are 4.8 (was also the case that the never version was a fair bit slower, but thats no longer relevant)
145 2013-12-08 08:53:53 <gmaxwell> ThomasZ: you can do a backup fine, it can't be read with an older version of bdb than wrote it.
146 2013-12-08 08:54:12 <gmaxwell> which, again, means you can't go back to the published binaries.
147 2013-12-08 08:54:16 <ThomasZ> if you can't restore it, its not really a backup.
148 2013-12-08 08:55:01 <ThomasZ> for reference, debian ships 5.1
149 2013-12-08 08:55:13 <gmaxwell> ThomasZ: I'm struggling to figure out what you're misreading in my comment there.
150 2013-12-08 08:55:48 <ThomasZ> I think its not a mis-read. I understand your point.
151 2013-12-08 08:56:18 <gmaxwell> ThomasZ: you can restore it fine, you cannot restore it using an older version of bdb than your software is linked against. Bitcoin-qt is standardized on 4.8 and our binaries ship against 4.8 (and, considering the compatibility problems and licensing snafu, will likely continue to link against 4.8 until we no longer use bdb at all)
152 2013-12-08 08:56:49 <gmaxwell> If you're using a non-standard build of bitcoin built against an incompatible bdb, "you get to keep the pieces"
153 2013-12-08 08:57:35 <gmaxwell> and sure, if you're always building your own binaries, then you're good to go.
154 2013-12-08 08:58:14 <gmaxwell> (though bitcoin likely a bit under-tested with bdb 5.x)
155 2013-12-08 08:59:48 <ThomasZ> I understand this.
156 2013-12-08 09:00:28 <gmaxwell> K.
157 2013-12-08 09:07:24 <ThomasZ> The point I was trying to make is that because 4.8 is marked obsolete by even the most slow moving linux distro (debian) years ago, I think the strategy you outline is tricky. Having your 'backup' only work on the many years old unmaintained software makes it not really a backup in the traditional sense.
158 2013-12-08 09:07:44 <ThomasZ> What about exporting it to a different format? Be it xml based or whatever.
159 2013-12-08 09:08:03 <ThomasZ> which can be imported by any future bitcoin client, irregardless of DB version
160 2013-12-08 09:08:55 <ThomasZ> also when the client might switch to another DB layer.
161 2013-12-08 09:16:28 <gmaxwell> No BDB we are willing to use is maintained anymore: the licensing in the latest versions were changed to a license we're not willing to use in the software. At some point when we change wallet formats we'll ship a migration tool. Bitcoin git also has the dumpwallet export which writes out ascii.
162 2013-12-08 09:17:54 <ThomasZ> ah, that dumbwallet export sounds like a fantastic solution to the problem indeed.
163 2013-12-08 09:28:01 <ThomasZ> gmaxwell: since the removal of the qmake buildsystem, how do people build bitcoin on Windows?
164 2013-12-08 10:02:48 <sturles> gmaxwell: Does dumpwallet keep transactions between accounts?
165 2013-12-08 10:03:19 <sturles> gmaxwell: Last time I checked it only dumped private keys.
166 2013-12-08 10:03:43 <sturles> And some meta information (account, time, etc).
167 2013-12-08 10:06:07 <sipa> dumpwallet does not dump tx information at all, only key information
168 2013-12-08 10:06:38 <sipa> so it doesn't retain "from account" or comments
169 2013-12-08 10:06:51 <sipa> and requires a rescan
170 2013-12-08 10:34:19 <ThomasZ> Maybe worth writing a task on the tasktracker about the Backup feature needing some tender loving care to avoid not being able to do an import later.
171 2013-12-08 10:34:36 <ThomasZ> ?
172 2013-12-08 12:42:23 <Plarkplark_> hi
173 2013-12-08 12:42:43 <Plarkplark_> does running a bitcoind node on a public addr. space address without mining help the network?
174 2013-12-08 12:42:57 <sipa> yes
175 2013-12-08 12:43:08 <sipa> you verify and relay blocks and transactions
176 2013-12-08 12:43:29 <Plarkplark_> ok. I have 48GB memory in a xen box available and a lot of storage, then ill spool up 5 nodes. ItÅ spare capacity anyway. :)
177 2013-12-08 12:43:29 <sipa> and can help lightweight clients find their transactions
178 2013-12-08 12:43:47 <sipa> better run one, and increase its max number of connections
179 2013-12-08 12:43:56 <Luke-Jr> ^
180 2013-12-08 12:44:05 <Luke-Jr> don't think there's much benefit to multiple nodes at the same place
181 2013-12-08 12:44:17 <Plarkplark_> different ip addresses though.
182 2013-12-08 12:44:24 <jaakkos> what is the default maximum?
183 2013-12-08 12:44:27 <Luke-Jr> Plarkplark_: still
184 2013-12-08 12:44:28 <Plarkplark_> But whatever is the best :) ill do that then
185 2013-12-08 12:44:32 <sipa> by default 125 i think
186 2013-12-08 12:44:39 <sipa> you can increase it to ~1000
187 2013-12-08 12:44:48 <Plarkplark_> ok with 48Gb mem and 8 cores what would you advise
188 2013-12-08 12:44:56 <jaakkos> i've been running for a few weeks, got around 40-70 connections
189 2013-12-08 12:45:23 <sipa> keeping it running for a long time helps, as it means seeders will notice you're reliable
190 2013-12-08 12:45:27 <Luke-Jr> you can go higher if you hack the code to set FD_SETSIZE :P
191 2013-12-08 12:46:10 <Plarkplark_> normale non-mining nodes do validate the nonce+hash right?
192 2013-12-08 12:46:17 <Plarkplark_> this is the "verifications" you see
193 2013-12-08 12:46:19 <Luke-Jr> of course
194 2013-12-08 12:46:20 <sipa> they validate *everything*
195 2013-12-08 12:46:24 <Luke-Jr> also the ECDSA signatures
196 2013-12-08 12:46:24 <Plarkplark_> ok good
197 2013-12-08 12:46:25 <Luke-Jr> etc
198 2013-12-08 12:46:25 <sipa> much much more than that
199 2013-12-08 12:46:39 <sipa> also, set your -dbcache higher than the default
200 2013-12-08 12:46:47 <sipa> it takes a number in MiB
201 2013-12-08 12:46:59 <Plarkplark_> what is default, and what would you recommend?
202 2013-12-08 12:47:07 <Plarkplark_> its 500mb up/down network.
203 2013-12-08 12:47:10 <Plarkplark_> 1tb traffic limit
204 2013-12-08 12:47:29 <sipa> dbcache just makes the node validate things faster, it doesn't affect bandwidth
205 2013-12-08 12:47:47 <sipa> -dbcache=2000 or so if you can spare 2 GB
206 2013-12-08 12:47:55 <sipa> higher doesn't make much difference
207 2013-12-08 12:48:49 <Plarkplark_> kk thx
208 2013-12-08 13:05:32 <diki> As much as I do not like gmaxwell, his idea of a POW based on ECDSA was interesting. Is it possible to use ECDSA as a POW algorithm?
209 2013-12-08 13:06:13 <sipa> yes
210 2013-12-08 13:11:08 <diki> And what would for instance be the use of the private key in such a POW?
211 2013-12-08 13:16:30 <nsh> which idea, diki?
212 2013-12-08 13:16:53 <diki> nsh:You just joined, how on earth did you read my previous message?
213 2013-12-08 13:17:09 <diki> the log?
214 2013-12-08 13:17:31 <nsh> services fakes a quit/join when you identify
215 2013-12-08 13:17:36 <nsh> i was always here :)
216 2013-12-08 13:17:53 <nsh> (well, when it sets cloaks)
217 2013-12-08 13:18:21 <diki> gmaxwell was well...commenting on the altcoin forum when he suggested we should try something like ECDSA for a proof of work algorithm
218 2013-12-08 13:19:01 <nsh> can you link to the thread?
219 2013-12-08 13:19:15 <diki> Sorry, I don't remember which thread it was, and I recently cleared my history.
220 2013-12-08 13:19:32 <diki> nsh:You want to pursue the idea?
221 2013-12-08 13:20:01 <nsh> ACTION is just curious :)
222 2013-12-08 13:24:17 <sipa> diki: there would be no private key
223 2013-12-08 13:24:34 <sipa> it's just the same algorithm as verification, but it's not a real signature or a real key that is involved
224 2013-12-08 13:24:36 <edulix> diki: but what is the advantage of using ECDSA for PoW?
225 2013-12-08 13:24:48 <diki> edulix:I have no idea. Not my idea.
226 2013-12-08 13:24:56 <diki> However it interested me enough to write here.
227 2013-12-08 13:25:02 <sipa> making the world spend resources to research fast ECDSA verification, of course :p
228 2013-12-08 13:25:03 <ThomasV> does bitcoind 0.8.5 work with txindex=1?
229 2013-12-08 13:25:09 <sipa> ThomasV: yes
230 2013-12-08 13:25:43 <diki> Fast verification using the CPU, sure. GPU verification? I am not sure many would like that.
231 2013-12-08 13:25:55 <sipa> ?
232 2013-12-08 13:26:17 <edulix> ThomasV: what does txindex=1 mean? :P
233 2013-12-08 13:26:28 <sipa> let it maintain a transaction index
234 2013-12-08 13:26:29 <diki> Well a lot of GPUs don't raise the fan speed automatically when there is load. I personally have to do it manually for any OpenCL business.
235 2013-12-08 13:26:56 <sipa> diki: it's not just about you :)
236 2013-12-08 13:27:06 <diki> Imagine somebody frying the card just from running Bitcoin-qt
237 2013-12-08 13:27:13 <sipa> just having people spend time to research improvement verification speed would be a good thing
238 2013-12-08 13:28:49 <edulix> diki: well, if you can fry the card by using it, then it's a hardware problem, right?
239 2013-12-08 13:29:03 <sipa> also, we're talking about a very hypothetical thing
240 2013-12-08 13:29:14 <sipa> in that hypothetical world there may not be a bitcoin-qt :)
241 2013-12-08 13:29:21 <diki> sipa:lol
242 2013-12-08 13:29:26 <sipa> i'm quite serious
243 2013-12-08 13:29:58 <sipa> it's just an interesting idea - i don't think it will ever happen for bitcoin
244 2013-12-08 13:30:02 <diki> Are you implying something about -Qt?
245 2013-12-08 13:30:26 <sipa> well for starters, i think bitcoin-qt should evolve into just a wallet application
246 2013-12-08 13:30:35 <sipa> that optionally supports running a full node too
247 2013-12-08 13:30:49 <wumpus> I'd like it to evolve into a full node application
248 2013-12-08 13:31:04 <diki> sipa:Sounds ok.
249 2013-12-08 13:31:07 <sipa> wumpus: hmm?
250 2013-12-08 13:31:16 <diki> I imagine the opposite should be true, just a node.
251 2013-12-08 13:31:26 <wumpus> there's so many wallets now
252 2013-12-08 13:31:47 <wumpus> any of them could be combined with a full wallet
253 2013-12-08 13:31:53 <wumpus> full node*
254 2013-12-08 13:32:02 <sipa> bundling the wallet with the node means we get some incentive for people to run a full node
255 2013-12-08 13:32:11 <sipa> but it comes at the cost of a rather bad user experience
256 2013-12-08 13:32:25 <sipa> yeah, i'd just like to see them being able to run independently
257 2013-12-08 13:32:30 <sipa> you run either, or both
258 2013-12-08 13:32:33 <wumpus> so, why not ship multibit with a bitcoind daemon that optionally runs onthe background?
259 2013-12-08 13:32:42 <sipa> right
260 2013-12-08 13:32:56 <sipa> or armory... oh, wait
261 2013-12-08 13:33:18 <wumpus> right
262 2013-12-08 13:34:27 <wumpus> so I really see bitcoin-qt as a full node application, with optional wallet, mostly for power users
263 2013-12-08 13:36:45 <diki> I wanted to use alternative wallets, however they should have supported the wallet file format used by Bitcoind/-Qt
264 2013-12-08 13:37:05 <diki> I didn't want to have to export private keys and import elsewhere, just plug the wallet.dat file and go.
265 2013-12-08 13:37:21 <sipa> i'm very glad nobody bothered to do that
266 2013-12-08 13:37:24 <wumpus> so just use a transaction to send the coins to the new wallet
267 2013-12-08 13:37:26 <sipa> wallet.dat should die
268 2013-12-08 13:37:29 <wumpus> yep
269 2013-12-08 13:37:45 <diki> sipa:Something else in mind?
270 2013-12-08 13:38:01 <sipa> yes, though not the time to make it happen
271 2013-12-08 13:38:08 <wumpus> many people mess around with exporting individual private keys in bitcoin-qt and mess up badly, it rarely ends well
272 2013-12-08 13:38:21 <wumpus> really people: don't be cheap and just use a transaction
273 2013-12-08 13:38:33 <diki> A wallet format that is supported by all current and future wallets would be nice.
274 2013-12-08 13:38:38 <diki> so it can be cross-application
275 2013-12-08 13:38:54 <sipa> i don't think we've even come to an agreement what a wallet is
276 2013-12-08 13:39:02 <wumpus> right sipa
277 2013-12-08 13:39:18 <sipa> and we certainly don't have established best practices for dealing with one
278 2013-12-08 13:39:48 <sipa> until that time, i'm much more in favor of a common wallet interchange format (which you export/import to), than an actual common wallet database format
279 2013-12-08 13:39:56 <ThomasV> sipa: getrawtransaction returns an error with the genesis block's coinbase
280 2013-12-08 13:40:02 <sipa> ThomasV: working as intended
281 2013-12-08 13:40:15 <sipa> ThomasV: the genesis block doesn't exist from the point of the network rules
282 2013-12-08 13:40:20 <sipa> (it can't be spent, for example)
283 2013-12-08 13:40:28 <ThomasV> oh
284 2013-12-08 13:40:35 <ThomasV> didn't know that
285 2013-12-08 13:40:37 <wumpus> the genesis block's coin base is ignored in all practical matters, so it is consistent
286 2013-12-08 13:40:59 <diki> In the wiki it says that is because of a quirk
287 2013-12-08 13:41:04 <diki> it doesnt go into detail why
288 2013-12-08 13:41:04 <sipa> maybe
289 2013-12-08 13:41:09 <sipa> maybe it was intentional
290 2013-12-08 13:41:12 <sipa> nobody knows
291 2013-12-08 13:41:36 <sipa> but changing it would be equal to giving satoshi a red button "FORK THE NETWORK"
292 2013-12-08 13:41:49 <diki> how so?
293 2013-12-08 13:41:55 <wumpus> there's no point in changing it
294 2013-12-08 13:42:01 <sipa> (if he tried to spend the genesis block's coinbase, new nodes would accept it and old nodes wouldn't)
295 2013-12-08 13:42:22 <wumpus> a lot of risk and no gain, except for satoshi who would be 50BTC richer :p
296 2013-12-08 13:42:46 <sipa> i think the risk is minimal
297 2013-12-08 13:42:54 <diki> I am pretty sure if it ever came to that, all would have upgraded
298 2013-12-08 13:43:15 <sipa> though i now envision satoshi waiting for that moment somewhere in a basement, ready to unleash his anger onto the network
299 2013-12-08 13:43:18 <diki> But I agree, he has X bitcoins, waay more than 50, he would not become richer or poorer with them
300 2013-12-08 13:43:28 <wumpus> yes, I think the risk of satoshi actuallly spending those coins would be minimal but there is just no point
301 2013-12-08 13:44:50 <diki> I have a feeling we might see satoshi signing a message with the privkey of at least the first address(1AZ1)
302 2013-12-08 13:44:57 <diki> sometime in the future
303 2013-12-08 13:45:18 <diki> Just to let us know he is there and is watching
304 2013-12-08 13:45:45 <sipa> wumpus: btw, when --disable-wallet (at compile time) makes it into head, i think we could move libsecp256k1 into the bitcoin repo (like leveldb), and enable it with some experimental flag that disables wallet and mining
305 2013-12-08 13:46:30 <edulix> diki: or maybe the FBI killed satoshi! :-P
306 2013-12-08 13:46:45 <diki> My "hunches" are rarely wrong.
307 2013-12-08 13:47:23 <wumpus> sipa: I've just merged disable-wallet
308 2013-12-08 13:47:25 <diki> To give you an example, when I one day thought I'd find a block with 100% certainty, it so happened that I found two
309 2013-12-08 13:47:56 <sipa> though a autotools build system for libsecp256k1 would be nice
310 2013-12-08 13:48:00 <wumpus> sipa: and that sounds like a good idea
311 2013-12-08 13:48:44 <wumpus> disable-wallet also implies disable mining right now, as the current mining code always wants to send the reward to an own address
312 2013-12-08 13:49:00 <sipa> wumpus: even getblocktemplate?
313 2013-12-08 13:49:02 <Luke-Jr> wumpus: it shouldn't
314 2013-12-08 13:49:24 <sipa> cfields said he'd do that (he wrote a prototype at some point), but he seems not to have found time recently
315 2013-12-08 13:49:25 <wumpus> sec256k1 would be a nice performance improvement
316 2013-12-08 13:49:54 <wumpus> and relying less on openssl by having that code in our own repo is good too
317 2013-12-08 13:50:03 <Luke-Jr> wumpus: mining hasn't used "send the reward to an own address" for years now
318 2013-12-08 13:50:09 <Luke-Jr> in bitcoind
319 2013-12-08 13:50:15 <wumpus> Luke-Jr: are you sure?
320 2013-12-08 13:50:29 <Luke-Jr> wumpus: internally, it used code for it, but the actual exposed functionality hasn't
321 2013-12-08 13:50:30 <sipa> getwork and the internal miner need an address to send to
322 2013-12-08 13:50:31 <wumpus> to me it looked like the code relies on the wallet, but I didn't look very deeply
323 2013-12-08 13:50:36 <sipa> but getblocktemplate doesn't, i hope?
324 2013-12-08 13:50:39 <Luke-Jr> getwork and internal-miner are obsolet
325 2013-12-08 13:51:03 <diki> sad to see them go
326 2013-12-08 13:51:06 <Luke-Jr> AFAIK jgarzik rerouted the code for GBT to not use it internally, when he did no-wallet
327 2013-12-08 13:51:16 <wumpus> hm you're right
328 2013-12-08 13:51:36 <edulix> is there any plan to port the client to qt5?
329 2013-12-08 13:51:38 <wumpus> I thought getblocktemplate used the pMinigKey as wel
330 2013-12-08 13:51:53 <Luke-Jr> edulix: it's essentially done, just needs build system work
331 2013-12-08 13:52:01 <wumpus> edulix: that's been done a long long time ago
332 2013-12-08 13:52:02 <edulix> Luke-Jr: nice
333 2013-12-08 13:52:13 <diki> Was the GUI revamped?
334 2013-12-08 13:52:17 <Arnavion> If only you didn't switch to autotools...
335 2013-12-08 13:52:27 <Luke-Jr> Arnavion: autotools is more important than Qt5 right now..
336 2013-12-08 13:52:30 <wumpus> getblocktemplate could be moved out of the libbitcoin_wallet.a then
337 2013-12-08 13:52:32 <Arnavion> Heh
338 2013-12-08 13:52:32 <sipa> the new build system will soon support qt5 too
339 2013-12-08 13:52:34 <Luke-Jr> nobody actually uses Qt5 in practice
340 2013-12-08 13:52:52 <wumpus> yes there is a pull to support qt5: https://github.com/bitcoin/bitcoin/pull/3346
341 2013-12-08 13:52:54 <wumpus> test it please
342 2013-12-08 13:52:56 <Luke-Jr> ACTION should test that qt5 PR since he's apparently one of few people to have a Qt4+Qt5 system
343 2013-12-08 13:53:08 <wumpus> I've done that and it worked great for me
344 2013-12-08 13:53:10 <sipa> ACTION hasn't built the Qt client in months...
345 2013-12-08 13:53:16 <Luke-Jr> wumpus: how does it decide which to build against?
346 2013-12-08 13:53:22 <wumpus> Luke-Jr: read the PR :p
347 2013-12-08 13:53:41 <Luke-Jr> wumpus: looks like it conflicts with my cleanups :<
348 2013-12-08 13:53:44 <wumpus> it chooses qt4 by default afaik
349 2013-12-08 13:54:10 <edulix> before autotools, what was the build system bitcoin-qt used, cmake?
350 2013-12-08 13:54:11 <Arnavion> Oh nobody told me there was a pullreq
351 2013-12-08 13:54:12 <wumpus> I'd rather have it the other way around, use the highest qt version available by default, but this is more compatible
352 2013-12-08 13:54:14 <Luke-Jr> edulix: none
353 2013-12-08 13:54:15 <Arnavion> Time to test
354 2013-12-08 13:54:28 <wumpus> qmake
355 2013-12-08 13:54:45 <Luke-Jr> well, -qt used qmake right, but bitcoind was just bare Makefiles
356 2013-12-08 13:55:03 <sipa> there were 4 separate build systems, really :)
357 2013-12-08 13:55:13 <Luke-Jr> 2 more? :o
358 2013-12-08 13:55:14 <wumpus> yes :)
359 2013-12-08 13:55:18 <edulix> ACTION would have suggested cmake but no system is perfect
360 2013-12-08 13:55:22 <sipa> 3 makefiles and qmake
361 2013-12-08 13:55:29 <sipa> they were maintained independently
362 2013-12-08 13:56:49 <wumpus> Luke-Jr: newer ubuntus come with qt5 by default
363 2013-12-08 13:57:07 <Luke-Jr> weird, does something actually use it?
364 2013-12-08 13:58:32 <wumpus> I have no clue
365 2013-12-08 13:59:12 <Luke-Jr> it's sad how long the Qt3Support module has survived
366 2013-12-08 14:00:14 <wumpus> but Qt3 had a much larger difference to Qt4 than Qt4 to Qt5
367 2013-12-08 14:00:52 <Luke-Jr> wumpus: not if you cvnsider Qt3Support to be part of Qt4 ;)
368 2013-12-08 14:01:02 <wumpus> hehe
369 2013-12-08 14:01:07 <Luke-Jr> Qt5 removed the module; problem is most software still uses it :/
370 2013-12-08 14:01:20 <sipa> in that regard, Qt4 was just a superset of Qt3? :p
371 2013-12-08 14:01:37 <Luke-Jr> sipa: well, you still had to do some regex to get Qt3 code to build
372 2013-12-08 14:01:47 <Luke-Jr> IIRC
373 2013-12-08 14:03:26 <wumpus> ah, a way of postponing having to do the real porting work
374 2013-12-08 14:05:10 <edulix> Luke-Jr: but.. did bitcoin-qt use qt3support?
375 2013-12-08 14:05:42 <sipa> bitcoin-qt was always qt4, no?
376 2013-12-08 14:05:47 <wumpus> no edulix
377 2013-12-08 14:06:18 <wumpus> qt3 is a long time ago, cryptocurrencies were still science fiction then
378 2013-12-08 14:06:35 <sipa> they no longer are? :o
379 2013-12-08 14:06:43 <sipa> we're just living in the future now!
380 2013-12-08 14:06:57 <wumpus> yes it does feel like that sometimes
381 2013-12-08 14:07:08 <Arnavion> Looks like you guys are using CFLAGS and CXXFLAGS internally in the build somewhere...
382 2013-12-08 14:07:30 <Arnavion> If I override them -O gets unset
383 2013-12-08 14:07:38 <wumpus> are you sure? I use CXXFLAGS="-Dsomething" ./configure all the time
384 2013-12-08 14:07:51 <diki> wait
385 2013-12-08 14:07:57 <Arnavion> I got a bajillion warnings about https://www.youtube.com/watch?v=1Lei4NPVUws
386 2013-12-08 14:07:58 <diki> wasnt Bitcoin using wxwidgets before?
387 2013-12-08 14:08:00 <Arnavion> Uhh
388 2013-12-08 14:08:08 <diki> And only afterwards used Qt4?
389 2013-12-08 14:08:17 <AtashiCon> wumpus: I got a bajillion warnings about warning _FORTIFY_SOURCE requires compiling with optimization (-O)
390 2013-12-08 14:08:23 <AtashiCon> (copy-paste over VNC didn't work)
391 2013-12-08 14:08:25 <sipa> diki: bitcoin used wx, bitcoin-qt uses qt, bitcoind uses neither
392 2013-12-08 14:08:47 <sipa> diki: bitcoin-qt replaced bitcoin since 0.5.0
393 2013-12-08 14:08:58 <diki> Yes, I remember.
394 2013-12-08 14:09:06 <diki> I was around when 0.3.24 got released
395 2013-12-08 14:09:17 <sipa> i remember 0.3.19
396 2013-12-08 14:09:20 <Luke-Jr> Arnavion: it's expected behaviour to override defaults with user-provided CXXFLAGS
397 2013-12-08 14:09:41 <Arnavion> Luke-Jr: But it seems to unset the opt flag if I do that
398 2013-12-08 14:09:47 <Arnavion> Might have only been in the leveldb subtree
399 2013-12-08 14:09:49 <Arnavion> Let me check
400 2013-12-08 14:10:04 <Luke-Jr> Arnavion: the "opt flag" is just a CXXFLAGS default
401 2013-12-08 14:10:40 <Arnavion> I think I wasn't clear
402 2013-12-08 14:10:58 <Luke-Jr> btw, the correct way to override vars for configure is after the ./configure: ./configure CXXFLAGS='blah'
403 2013-12-08 14:11:13 <sipa> orly?
404 2013-12-08 14:11:20 <Arnavion> First tiem I heard that
405 2013-12-08 14:12:24 <Luke-Jr> at least according to --help's Usage :p
406 2013-12-08 14:12:47 <Arnavion> Makes no difference
407 2013-12-08 14:12:50 <Arnavion> What I was saying was
408 2013-12-08 14:13:02 <Arnavion> Usually the build system (Makefile) doesn't use CXXFLAGS internally
409 2013-12-08 14:13:12 <Arnavion> Instead it just appends it to the flags it defines by default
410 2013-12-08 14:13:18 <Arnavion> such as -O
411 2013-12-08 14:13:25 <diki> Luke-Jr:Has worked for me without issuing ./configure
412 2013-12-08 14:13:33 <Luke-Jr> Arnavion: that's not how any autotools works
413 2013-12-08 14:13:56 <Luke-Jr> Arnavion: autotools just defaults CXXFLAGS to -O2 -g, and lets you override/replace that
414 2013-12-08 14:14:16 <Arnavion> https://github.com/bitcoin/bitcoin/commit/8986a1369f572e2d4f50da91ddb172dc37e83abf For example
415 2013-12-08 14:14:35 <Arnavion> This way user's CXXFLAGS can be appended to the existing commandline
416 2013-12-08 14:14:42 <sipa> leveldb is separate
417 2013-12-08 14:14:51 <Arnavion> I'm illustrating the concept
418 2013-12-08 14:14:51 <Luke-Jr> Arnavion: that's for special build stuff, not for optimisations/debug/etc
419 2013-12-08 14:15:01 <Arnavion> I see
420 2013-12-08 14:15:01 <Luke-Jr> -D* would be appended in all cases, certainly
421 2013-12-08 14:15:04 <sipa> we're trying to not touch leveldb's code as much as possible
422 2013-12-08 14:15:18 <Luke-Jr> and -l -I etc
423 2013-12-08 14:15:25 <Arnavion> So you're saying if I override C(XX)FLAGS I should always give -O ?
424 2013-12-08 14:15:27 <Luke-Jr> but user preference things like -O and -g are overridden
425 2013-12-08 14:15:31 <Luke-Jr> if you want -O
426 2013-12-08 14:15:50 <Arnavion> So if I don't want to change the default -O, then?
427 2013-12-08 14:15:55 <Luke-Jr> sure
428 2013-12-08 14:15:58 <Luke-Jr> personally I build with -O0 -ggdb :D
429 2013-12-08 14:16:11 <Arnavion> Then what? I should pass it in or shouldn't?
430 2013-12-08 14:16:21 <sipa> you should
431 2013-12-08 14:16:23 <Luke-Jr> if you want it, pass it in
432 2013-12-08 14:16:52 <Arnavion> Right, okay
433 2013-12-08 14:17:05 <Arnavion> Well, build succeeded with --qith-qt=qt5
434 2013-12-08 14:17:13 <Arnavion> --with-qt*
435 2013-12-08 14:17:15 <Arnavion> So there's that
436 2013-12-08 14:17:17 <Luke-Jr> Arnavion: did you need custom CXXFLAGS?
437 2013-12-08 14:17:24 <Arnavion> I compiled without
438 2013-12-08 14:17:31 <Arnavion> I did override a bnch of other stuff
439 2013-12-08 14:17:32 <Arnavion> Sec
440 2013-12-08 14:17:41 <AtashiCon> ./configure --with-qt=qt5 USE_DBUS=1 USE_IPV6=0 USE_QRCODE=0 USE_UPNP=- DEBUGFLAGS=
441 2013-12-08 14:17:51 <Arnavion> Although I'm not sure how much of that still works
442 2013-12-08 14:18:03 <Arnavion> I used to use those with qmake back when it was there
443 2013-12-08 14:18:08 <Luke-Jr> AtashiCon: those other vars will be ignored..
444 2013-12-08 14:18:13 <Arnavion> k
445 2013-12-08 14:20:11 <Arnavion> Seems to work
446 2013-12-08 14:20:43 <sipa> Arnavion == AtashiCon?
447 2013-12-08 14:20:47 <Arnavion> Yeah
448 2013-12-08 14:20:52 <Arnavion> AtashiCon is the machine I'm testing on
449 2013-12-08 14:20:59 <Arnavion> openSUSE 13.1
450 2013-12-08 14:21:58 <Arnavion> It made peer connections and is syncing
451 2013-12-08 14:22:21 <Arnavion> Is there anything I should test?
452 2013-12-08 14:30:12 <wumpus> Luke-Jr, sipa: https://github.com/bitcoin/bitcoin/pull/3368
453 2013-12-08 15:19:36 <K1773R> sipa: i hope you wont merge this https://github.com/sipa/bitcoin-seeder/pull/15
454 2013-12-08 15:21:51 <upb> wtf, 'pseudocoders'
455 2013-12-08 15:39:01 <sipa> K1773R: hadn't tried it yet
456 2013-12-08 16:24:43 <diki> upb:pseudocoders??
457 2013-12-08 16:38:56 <upb> diki: people who create cosmetic changes pull requests
458 2013-12-08 16:39:32 <diki> Oh, I thought you meant coders with half-assed knowledge
459 2013-12-08 16:41:48 <upb> there is aconnection :)
460 2013-12-08 16:47:50 <diki> upb:It is nothing to be proud of, but I fall within that category, I was categorized by a person who claimed to know people like me, who either take days to find a single bug, or never do. Or launch a service and get hacked soonish.
461 2013-12-08 16:49:41 <diki> That was the first time someone told me I can't code. Perhaps he was right, but I program as a hobby.
462 2013-12-08 17:02:19 <sunspotbtc> is it normal for bitcoind getinfo to hang while the initial download/verification is in process?
463 2013-12-08 17:03:04 <gmaxwell> hang? no.. it is sometimes slow to respond (e.g. a couple seconds) while processing a batch of blocks.
464 2013-12-08 17:03:40 <sunspotbtc> I'm seeing no response for several minutes
465 2013-12-08 17:03:53 <sunspotbtc> 0.8.6 on ubuntu 12.04
466 2013-12-08 17:04:03 <sunspotbtc> and I can confirm debug.log has activity
467 2013-12-08 17:04:22 <sunspotbtc> OK, yea, it finally did respond
468 2013-12-08 17:04:28 <sunspotbtc> but took about 3minutes LOL
469 2013-12-08 17:04:53 <sunspotbtc> and now it's responding quickly
470 2013-12-08 17:04:56 <sunspotbtc> *shrug*
471 2013-12-08 17:05:13 <sunspotbtc> at least it isn't crashing like the last tests I did with 0.8.5
472 2013-12-08 17:05:19 <nsh> i wonder what it would look like if an octopus shrugged...
473 2013-12-08 17:05:53 <gmaxwell> sunspotbtc: nothing has changed wrt that.
474 2013-12-08 17:06:07 <gmaxwell> sunspotbtc: Did you report your crashes?
475 2013-12-08 17:06:43 <diki> sunspotbtc:I guess it is. I've experienced it a lot of times.
476 2013-12-08 17:06:59 <sunspotbtc> gmaxwell: I had planned to but wanted to get a repeatable test case with the latest version but it's not crashing this time LOL
477 2013-12-08 17:07:58 <sunspotbtc> gmaxwell: last time it took my machine down, couldn't even reach it via SSH
478 2013-12-08 17:09:05 <lechuga> u sure its not badbios?
479 2013-12-08 17:09:07 <gmaxwell> sunspotbtc: sounds like it was running you out of memory during the initial block download. This is a known issue, though 0.8.5 is no different, it won't happen every timeâ only if it recieves a new block from the network while downloading.
480 2013-12-08 17:09:12 <gmaxwell> lechuga: Please don't be unhelpful.
481 2013-12-08 17:09:22 <lechuga> :)
482 2013-12-08 17:09:32 <sunspotbtc> lechuga: who could be? ;)
483 2013-12-08 17:11:58 <sunspotbtc> gmaxwell: makes sense, I added a swapfile this time so that might explain why it's not running out of mem
484 2013-12-08 17:15:01 <sipa> it also explains why getinfo takes minutes :)
485 2013-12-08 17:16:44 <sunspotbtc> sipa: good point
486 2013-12-08 17:20:40 <sunspotbtc> what's the diff between SHA256SUMS.asc and SHASUMS.asc, why are there two (sorry if that's naive)
487 2013-12-08 17:21:55 <sipa> not every tool supports sha256, i guess
488 2013-12-08 17:22:00 <sipa> mostly a historic reason
489 2013-12-08 17:22:53 <michagogo> cloud|(also, I guess you'd need both sha256 and sha1 to be broken in order to compromise the signatures?)
490 2013-12-08 17:23:13 <sipa> yeah
491 2013-12-08 17:23:18 <sunspotbtc> I thought sha1 was broken
492 2013-12-08 17:23:32 <lechuga> not routinely
493 2013-12-08 17:23:50 <michagogo> cloud|sunspotbtc: no, but it's been estimated that it can be broken with a few million dollars
494 2013-12-08 17:23:53 <michagogo> cloud|FSVO broken
495 2013-12-08 17:25:30 <sipa> a collision, yes
496 2013-12-08 17:25:36 <sipa> not a preimage, afaik
497 2013-12-08 17:25:57 <nsh> michagogo|cloud, FSVO?
498 2013-12-08 17:26:06 <sipa> for some value of
499 2013-12-08 17:26:13 <michagogo> cloud|;;google --lucky --snippet FSVO
500 2013-12-08 17:26:14 <gribble> http://www.urbandictionary.com/define.php?term=FSVO | Internet Slang adapted from Programming. Literally. For Some Value Of.
501 2013-12-08 17:26:15 <nsh> oh, right
502 2013-12-08 17:26:22 <nsh> ty
503 2013-12-08 17:27:01 <lechuga> dont most people say 'for some definition of...'
504 2013-12-08 17:27:23 <gribble> http://www.faa.gov/about/office_org/field_offices/fsdo/ | Dec 19, 2011 ... Contact a FSDO for. Low-flying aircraft; Accident Reporting; Air carrier certification and operations; Aircraft maintenance; Aircraft operational ...
505 2013-12-08 17:27:23 <lechuga> ;;google --lucky --snippet FSDO
506 2013-12-08 17:27:28 <lechuga> guess not
507 2013-12-08 17:27:31 <sunspotbtc> ACTION adds the double verify to his build notes
508 2013-12-08 17:28:21 <sunspotbtc> one more thing, the developer keys on bitcoin.org are out of date
509 2013-12-08 17:28:30 <michagogo> cloud|Are they?
510 2013-12-08 17:29:29 <sunspotbtc> http://bitcoin.org/gavinandresen.asc
511 2013-12-08 17:29:40 <sunspotbtc> doesn't include 7BF6E212
512 2013-12-08 17:30:09 <sunspotbtc> which I had to find from pgpkeys.mit.edu
513 2013-12-08 17:31:30 <michagogo> cloud|Oh, interesting
514 2013-12-08 17:31:40 <michagogo> cloud|So that includes his key, and one subkey of his code-signing key
515 2013-12-08 17:32:05 <michagogo> cloud|odd.
516 2013-12-08 17:52:29 <lechuga> any1 have any issues connecting to the testnet with multibit?
517 2013-12-08 17:59:57 <lechuga> hmm
518 2013-12-08 18:00:02 <lechuga> doesnt seem able to connect to any peers
519 2013-12-08 18:07:52 <hmsimha> Hi, I'm wondering if anyone could help me with a cryptographic question regarding building on top of the address generation algorithms
520 2013-12-08 18:08:23 <sipa> don't ask to ask
521 2013-12-08 18:09:28 <gmaxwell> just ask
522 2013-12-08 18:12:21 <hmsimha> gotcha, so I was wondering if you could encrypt messages with someone's public bitcoin address they could encrypt with their private key, and that would be secure
523 2013-12-08 18:12:42 <hmsimha> sorry, *that they could decrypt with their private key
524 2013-12-08 18:13:49 <hmsimha> i've searched and found something along those lines being asked before, but with unclear (at least to me) answers
525 2013-12-08 18:14:39 <andytoshi> well, the main problem is that the address is not a public key, but a hash of the public key
526 2013-12-08 18:14:48 <andytoshi> so you can't get a public key just by knowing an address
527 2013-12-08 18:15:18 <andytoshi> otoh, whenever a key is actually used to spend money, the public key is exposed
528 2013-12-08 18:16:10 <andytoshi> the inverse operation, digitally signing messages, is supported directly by bitcoind
529 2013-12-08 18:16:30 <hmsimha> hmm.. interesting, i thought it was a base58check encoding of the public key... so that would be reversible
530 2013-12-08 18:17:24 <hmsimha> right, i know about signing messages.. and that's pretty rad, but it would be nice to have messages that could be sent from one bitcoin account to another, even if the two account-holders don't know each other and haven't established a means of communication
531 2013-12-08 18:18:28 <lechuga> any1 know why id fail to connect to the rpc server in bitcoind using bitcoind from the cmdline?
532 2013-12-08 18:18:37 <lechuga> i verified with telnet its listening on 1833
533 2013-12-08 18:18:49 <lechuga> 18333*
534 2013-12-08 18:18:50 <andytoshi> hmsimha: as a general rule it is unwise to use a same key for encryption and signatures, and bitcoin uses these keys for signatures
535 2013-12-08 18:19:02 <andytoshi> i'm not sure what the exact situation is with ECDSA
536 2013-12-08 18:19:44 <andytoshi> but if you wanted to do this, you'd have to publish the public key separate from the address
537 2013-12-08 18:19:56 <andytoshi> and so anyone you're sending secret messages to would have to be cooperating with the scheme
538 2013-12-08 18:19:58 <hmsimha> andytoshi, the key used for signing would be the sender's private key, but the key used for encryption, in theory, should be the recipient's public key
539 2013-12-08 18:20:01 <hmsimha> much like pgp
540 2013-12-08 18:20:20 <nsh> signing messages with your bitcoin private keys could be pretty dangerous
541 2013-12-08 18:20:38 <andytoshi> hmsimha: understood
542 2013-12-08 18:20:43 <andytoshi> see for example, http://crypto.stackexchange.com/questions/12090/using-the-same-rsa-keypair-to-sign-and-encrypt
543 2013-12-08 18:20:50 <nsh> if you have weak entropy, it could compromise your key
544 2013-12-08 18:20:58 <nsh> (under DSA at least)
545 2013-12-08 18:20:59 <andytoshi> this is for RSA, but the first answer is "Depends on tricky details of the padding scheme you use and your implementation. It'd generally discouraged to reuse keys like that."
546 2013-12-08 18:22:02 <nsh> it would be wiser to create a new address, then authenticate the address with a token transaction from an actual currency-holding address
547 2013-12-08 18:22:32 <hmsimha> I'm a little bit over my depth with the terminology, but it sounds like your saying it could be done, but because the scheme for generating addresses uses less entropy than RSA, there's the risk that an attacker could determine your private key form an encrypted message?
548 2013-12-08 18:22:34 <sipa> or a message signature
549 2013-12-08 18:22:56 <sipa> you can use EC-IES using bitcoin keys
550 2013-12-08 18:23:00 <sipa> for encryption
551 2013-12-08 18:23:05 <sipa> though you need the full public key
552 2013-12-08 18:23:13 <sipa> and as said, key reuse isn't wise
553 2013-12-08 18:23:18 <gmaxwell> as nsh says
554 2013-12-08 18:35:33 <melvster> hmsimha: FWIW satoshi wanted the keys to be used for both signing and encryption but RSA keys would just have taken up far too much space (and there may be other reasons) so ECDSA was selected
555 2013-12-08 18:36:08 <sipa> ... encryption?
556 2013-12-08 18:36:10 <sipa> where?
557 2013-12-08 18:36:37 <melvster> there's an old forum post about it ... ive read through the archives a few times :)
558 2013-12-08 18:37:05 <sipa> bitcoin doesn't use encryption anywhere, so that would surprise me
559 2013-12-08 18:37:57 <melvster> i should perhaps say 'usable' rather than 'used'
560 2013-12-08 18:38:14 <melvster> let me see if i can dig out the post
561 2013-12-08 18:38:23 <sipa> yes, RSA can be used for both, and is quite an exception in that
562 2013-12-08 18:38:43 <sipa> but i don't see the relevance in the context of bitcoin
563 2013-12-08 18:40:18 <melvster> here you go:
564 2013-12-08 18:40:23 <melvster> satoshi: 'Bitcoin uses EC-DSA, which can only do digital signing, not encryption. RSA can do both, but I didn't use it because it's an order of magnitude bigger and would have been impractical.'
565 2013-12-08 18:40:41 <sipa> yes, sure
566 2013-12-08 18:41:00 <melvster> https://bitcointalk.org/index.php?topic=30.msg1169#msg1169
567 2013-12-08 18:41:29 <melvster> there may of course be other reasons
568 2013-12-08 18:41:34 <hmsimha> melvster, that definitely helps answer my question, thank you!
569 2013-12-08 18:41:50 <melvster> np :)
570 2013-12-08 18:42:05 <sipa> yes, not objecting at all - i only reacted because you said satoshi wanted keys that did both encryption and signing, which seems very strange as bitcoin doesn't use encryption at all
571 2013-12-08 18:42:28 <melvster> sure ... i could have been clearer ... :)
572 2013-12-08 18:42:38 <sipa> also, he was not entirely right; EC-DSA is only for signing, but there are other EC algorithms which use the same keys which can do encryption (EC-IES, in particular)
573 2013-12-08 18:43:01 <melvster> oh cool ... i didnt know that
574 2013-12-08 18:43:15 <sipa> 19:22:44 < sipa> you can use EC-IES using bitcoin keys
575 2013-12-08 18:43:15 <sipa> 19:22:48 < sipa> for encryption
576 2013-12-08 18:43:41 <melvster> yes i saw ... tho didnt know it was another algorithm ... was about to search it :)
577 2013-12-08 18:45:04 <bitanarchy> are browsers suitable for generating private keys... like bitaddress or brainwallet? Because the paper wallet page on bitcoin.it says that they are not!
578 2013-12-08 18:45:35 <sipa> if you trust the site and all infrastructure surrounding it
579 2013-12-08 18:45:42 <sipa> (or use a locally-stored and validated copy)
580 2013-12-08 18:48:01 <melvster> the code is on github ... I run an older mirror at ... ive not noticed any issues with it ... but it's always best to check yourself : http://virtualwallet.org/