1 2015-07-09 01:34:25 <gmaxwell> wangchun: I see you are still doing dust sweeping transactions-- I still think that should wait until so much other traffic isn't going on, and I don't understand what you're doing that now... But if you insist on doing it I can help you make your signatures _MUCH_ smaller.
2 2015-07-09 01:34:49 <gmaxwell> Since the private keys in this case are not secret, you can make signatures which are much smaller by using a special value for K in ecdsa.
3 2015-07-09 01:35:46 <gmaxwell> I can give you a K that will save 10 or 11 bytes off of every signature.
4 2015-07-09 01:40:58 <gmaxwell> If you are signing these transactions with signrawtransaction I can give you a patch to make the much smaller signatures, but you must not use it to sign anything else or it will give away your private keys. (so I won't just post the patch here, until you confirm for me that you understand)
5 2015-07-09 02:46:45 <denisx> does bitcoind use AES-NI?
6 2015-07-09 02:49:57 <Luke-Jr> it uses some kind of AES for the wallet encryption (only)
7 2015-07-09 02:51:19 <Diablo-D3> denisx: bitcoin itself has no use for AES iirc
8 2015-07-09 02:51:36 <Diablo-D3> denisx: a sha256 accelerator would be more useful hre
9 2015-07-09 04:43:47 <BlueMatt> someone want to fix the wiki?
10 2015-07-09 04:43:52 <BlueMatt> https://en.bitcoin.it/wiki/Protocol_documentation#block <-- version is signed
11 2015-07-09 04:44:49 <Luke-Jr> BlueMatt: why not just do it? <.<
12 2015-07-09 04:45:08 <BlueMatt> I never bought access
13 2015-07-09 04:45:10 <BlueMatt> and I'm too lazy now
14 2015-07-09 04:45:14 <Luke-Jr> what's your username?
15 2015-07-09 04:45:22 <BlueMatt> BlueMatt
16 2015-07-09 04:45:52 <Luke-Jr> all done
17 2015-07-09 04:46:02 <BlueMatt> thanks :)
18 2015-07-09 04:46:28 <Luke-Jr> np
19 2015-07-09 04:49:04 <venzen> Luke-Jr: ahem...
20 2015-07-09 04:49:32 <Luke-Jr> venzen: yes?
21 2015-07-09 04:49:37 <venzen> i can fix many things there... like typos...
22 2015-07-09 04:49:54 <venzen> username: venzen
23 2015-07-09 04:51:10 <Luke-Jr> venzen: nanotube approved you like a year ago O.o also, if anyone else wants access, please ask in #bitcoin-wiki :p
24 2015-07-09 04:52:00 <venzen> Luke-Jr: ok, i know he did, but then I had to pay, i remember, to have access
25 2015-07-09 04:52:11 <venzen> is that still the case?
26 2015-07-09 04:52:47 <Luke-Jr> venzen: no, the manual approval process bypasses the payment
27 2015-07-09 04:53:14 <venzen> thanks!
28 2015-07-09 04:53:57 <venzen> does anyone feel like explaining the pruning node?
29 2015-07-09 04:54:15 <venzen> i've set up a 0.11 Core node that prunes
30 2015-07-09 04:54:33 <venzen> but i don't know if it helps the network or what its good for
31 2015-07-09 04:55:07 <venzen> i want to add my bit, but there isn't much info on what exactly pruning does, other than in Wladimir's release notes
32 2015-07-09 04:55:26 <Luke-Jr> venzen: as far as I can tell, the 0.11 pruning is only practically useful for miners :/
33 2015-07-09 04:55:38 <venzen> :|
34 2015-07-09 04:55:50 <Luke-Jr> 0.12 pruning will probably support wallet
35 2015-07-09 04:56:20 <venzen> right, and does validate blocks and transactions?
36 2015-07-09 04:56:24 <venzen> in 0.11?
37 2015-07-09 04:56:34 <Luke-Jr> yes, there's just nothing you can do with it except mine
38 2015-07-09 04:56:59 <venzen> ok, i'm running a full testnet node, but i don't mine
39 2015-07-09 04:57:11 <venzen> i just thought i'd add another node to the network
40 2015-07-09 04:57:20 <venzen> vs the competition if you know what i mean
41 2015-07-09 04:57:46 <Luke-Jr> pruning nodes don't contribute much (if at all) unless they mine
42 2015-07-09 04:58:03 <venzen> sorry... iam running a testnet fullnode and a mainnet pruning node
43 2015-07-09 04:58:27 <venzen> but if that mainnet is no use to me or adding any useful decentralization...
44 2015-07-09 04:58:33 <venzen> might as well kick it then
45 2015-07-09 04:59:06 <Luke-Jr> yeah, I can't think of any use for it right now unfortunately; maybe someone else here knows something I'm missing
46 2015-07-09 04:59:30 <venzen> i'll ask around, but i semi-trust your opinion
47 2015-07-09 05:00:23 <venzen> btw - what's the size of the blockchain on disk these days?
48 2015-07-09 05:00:49 <Luke-Jr> 47 GB
49 2015-07-09 05:01:30 <venzen> ouch.. i thought I could buy some more GBs for my VPS, but no
50 2015-07-09 05:01:39 <venzen> thanks for the input Luke-Jr
51 2015-07-09 05:01:50 <Luke-Jr> well, a full node on a VPS isn't very useful regardless >_<
52 2015-07-09 05:02:25 <venzen> oh yes? damn, why so?
53 2015-07-09 05:02:43 <Luke-Jr> someone else (the host) has control of it
54 2015-07-09 05:03:00 <venzen> true
55 2015-07-09 05:03:33 <venzen> but then everyone's ISP has control of the datastream, eh?
56 2015-07-09 05:04:35 <Luke-Jr> venzen: not if you're using it ;)
57 2015-07-09 05:04:54 <Luke-Jr> the main benefit of a full node, comes from the user with physical control over it actually using it for their own transactions
58 2015-07-09 05:05:48 <venzen> right, so that's privacy and security for the user
59 2015-07-09 05:06:26 <venzen> the presence of extra fullnodes also strengthens decentralization (if they're secure), right
60 2015-07-09 05:07:11 <Luke-Jr> only if people are using them directly/securely
61 2015-07-09 05:13:17 <venzen> could a pruning node be used in conjunction with an electrum server? I guess not coz there's no txindex?
62 2015-07-09 05:14:32 <Luke-Jr> right, it can't.
63 2015-07-09 05:17:20 <venzen> ah well, at least i got to learn the ropes of putting a node on the tor network :)
64 2015-07-09 05:44:00 <venzen> btw, on testnet my logs are filling with:
65 2015-07-09 05:44:03 <venzen> SOCKS5 connecting testnet-seed.alexykot.me
66 2015-07-09 05:44:16 <venzen> ERROR: Proxy error: host unreachable
67 2015-07-09 05:44:40 <venzen> can it be remedied?
68 2015-07-09 05:46:07 <venzen> that's a .onion net only node I'm running, so not sure how regular DNS got in there
69 2015-07-09 05:46:58 <Luke-Jr> venzen: you probably don't want to remedy it then
70 2015-07-09 05:48:22 <venzen> its difficult to scroll back and |grep the logs with this seednode unreachable :(
71 2015-07-09 05:49:53 <Luke-Jr> -dnsseed=0 then
72 2015-07-09 05:53:21 <venzen> Luke-Jr: thanks, you're a veritable fountain of knowledge :)
73 2015-07-09 05:53:32 <Luke-Jr> np
74 2015-07-09 06:05:06 <jgarzik> Floating network relay fee increase, if memory pool grows too large. https://github.com/bitcoin/bitcoin/pull/6402
75 2015-07-09 06:05:15 <jgarzik> Remove TX priority and free transaction area from mempool, block creator. https://github.com/bitcoin/bitcoin/pull/6405
76 2015-07-09 06:10:04 <CodeShark> should we prioritize by coin age as well?
77 2015-07-09 06:10:43 <CodeShark> or nvm...
78 2015-07-09 06:10:46 <Luke-Jr> CodeShark: that's precisely what jgarzik is removing in 6405 :/
79 2015-07-09 06:17:46 <jgarzik> Luke-Jr, prioritisetransaction still works
80 2015-07-09 06:18:31 <Luke-Jr> jgarzik: that's beside the point
81 2015-07-09 06:19:09 <phantomcircuit> Luke-Jr, what change are you referring to in that pr?
82 2015-07-09 06:19:14 <jgarzik> no it's not. you can order the mempool however you like
83 2015-07-09 06:20:24 <phantomcircuit> the policy stuff can get stupid complicated
84 2015-07-09 06:20:28 <jgarzik> anyway, headed to bed
85 2015-07-09 06:20:35 <phantomcircuit> which is a problem since you cant be sure it's computational sane
86 2015-07-09 06:20:43 <phantomcircuit> which leads to weirdness in the api
87 2015-07-09 06:28:16 <phantomcircuit> Luke-Jr, it seems like the api should probably just be CPolicy::GetPriority(CTransaction, CBlockIndex);
88 2015-07-09 06:28:41 <Luke-Jr> phantomcircuit: the API I am using is a bool compare, like the rest of C++ :p
89 2015-07-09 06:28:47 <phantomcircuit> and only update the values when a block is found
90 2015-07-09 06:29:11 <phantomcircuit> Luke-Jr, eh...
91 2015-07-09 06:30:08 <CodeShark> as in std::sort?
92 2015-07-09 06:30:32 <Luke-Jr> phantomcircuit: here, not done yet: http://codepad.org/B9MyjFW9
93 2015-07-09 06:33:52 <phantomcircuit> Luke-Jr, iff?
94 2015-07-09 06:34:00 <phantomcircuit> if and only if?
95 2015-07-09 06:34:21 <CodeShark> that's how mathematicians use it
96 2015-07-09 06:34:41 <Luke-Jr> yes
97 2015-07-09 06:34:59 <phantomcircuit> this seems like it's probably the basis for a reasonable longer term solution
98 2015-07-09 06:35:05 <phantomcircuit> but doesn't look almost done :P
99 2015-07-09 06:36:01 <CodeShark> in conditionals, doesn't if always mean iff?
100 2015-07-09 06:38:25 <phantomcircuit> CodeShark, yes
101 2015-07-09 06:39:40 <phantomcircuit> Luke-Jr, probably we should all be coordinating this instead of just writing code...
102 2015-07-09 08:02:52 <drazisil> is there a why to enable logging on bitcoind so I can see what I'm getting a 500 on my api calls?
103 2015-07-09 08:03:00 <drazisil> why*
104 2015-07-09 08:04:40 <wumpus> cfields: https://bitcoincore.org/depends-sources/fontconfig-2.11.1.tar.bz2 is missing
105 2015-07-09 08:05:45 <wumpus> drazisil: -debug enables full debugging (noisy!)
106 2015-07-09 08:09:07 <drazisil> wumpus: does that log api calls too?
107 2015-07-09 08:16:00 <wumpus> cfields: travis is behaving strangely lately, it is spending a lot of time building e.g. qt and other deps in pull requests
108 2015-07-09 08:17:40 <wumpus> drazisil: yes, but not in much detail
109 2015-07-09 08:17:59 <drazisil> wumpus: ok, thanks
110 2015-07-09 08:19:21 <wumpus> do you get any message/body text with the 500 reply? that's more useful to know for debugging, I think
111 2015-07-09 08:21:19 <drazisil> wumpus: as far as I can tell I don't.
112 2015-07-09 08:22:45 <wumpus> drazisil: i'd check very carefully
113 2015-07-09 08:22:48 <killerstorm> hi. does regtest mode use different network magic from testnet?
114 2015-07-09 08:23:12 <killerstorm> so for example if I try using bitcore with it it won't work, right?
115 2015-07-09 08:23:36 <drazisil> wumpus: just tested to make sure with example.com...I can see body, but bitcoind is not returning one
116 2015-07-09 08:26:22 <wumpus> killerstorm: testnet uses 0b110907, regtest fabfb5da - so, yes. bitcore has no regtest mode? or way to set the message bytes manually?
117 2015-07-09 08:27:42 <drazisil> and this request isn't getting logged at all. drat
118 2015-07-09 08:28:02 <drazisil> wumpus: do you know python, mind taking a quick look?
119 2015-07-09 08:31:00 <killerstorm> wumpus: there is a way to set it manually, OK.
120 2015-07-09 08:33:10 <wumpus> drazisil: what you could do is look using wireshark what is different from when you use bitcoin-cli
121 2015-07-09 08:33:58 <drazisil> wumpus: ah, good idea, thanks
122 2015-07-09 09:49:13 <jmcn> um, having one of those mornings... can anyone confirm the testnet blockcount?
123 2015-07-09 09:49:53 <jmcn> local bitcoind says 498403, blockexplorer.com says 501158.
124 2015-07-09 09:51:23 <jouke> local bitcoind: "blocks" : 501160,
125 2015-07-09 09:51:38 <jmcn> and biteasy is showing now testnet blocks since Monday.
126 2015-07-09 09:51:46 <jouke> *old version node
127 2015-07-09 09:52:14 <jmcn> jouke> thanks.
128 2015-07-09 09:52:34 <jmcn> I mean no testnet blocks since Monday.
129 2015-07-09 09:56:26 <gmaxwell> jmcn: "blocks": 498403,
130 2015-07-09 09:58:06 <gmaxwell> 2015-07-09 09:54:42 UpdateTip: new best=000000000027f67a98c3cadec7bafdb61b7ef0fbf493094a92d7f8b022117cde height=498403 log2_work=66.130413 tx=4838454 date=2015-07-09 09:54:13 progress=1.000000 cache=1.6MiB(1553tx)
131 2015-07-09 09:59:15 <jmcn> gmaxwell> so which is correct?
132 2015-07-09 09:59:17 <gmaxwell> jmcn: make sure you mind the work, it's easy for testnet to have forks with more blocks but less work.
133 2015-07-09 10:04:14 <jmcn> gmaxwell: so the nodes reporting 501160... are they really on another fork that's now ~2750 blocks ahead?
134 2015-07-09 10:04:28 <jouke> jmcn: I think it is a fork with version 2 blocks.
135 2015-07-09 10:05:25 <jmcn> is that because they're using a pre 0.9.5 client?
136 2015-07-09 10:05:58 <jouke> yes. My node is also pre .9.5
137 2015-07-09 10:06:17 <jmcn> i.e one that didn't follow the BIP66 rules?
138 2015-07-09 10:06:35 <jouke> yes
139 2015-07-09 10:07:09 <jmcn> hmm... I was taking the output from blockexplorer as gospel
140 2015-07-09 10:07:29 <jmcn> well, not gospel, but a double check that our clients were up-to-date.
141 2015-07-09 10:07:48 <gmaxwell> jmcn: whats the log2_work on that fork?
142 2015-07-09 10:07:54 <gmaxwell> e.g. is it actually ahead?
143 2015-07-09 10:08:35 <jmcn> I don't know in the 500k blocks - I've only got access to 0.10.1 client which is:
144 2015-07-09 10:08:38 <jmcn> 2015-07-09 10:08:16 UpdateTip: new best=0000000000026846103caa5d770b096c887e3353b0966128ebf16f9ae345d60f height=498415 log2_work=66.130415 tx=4838620 date=2015-07-09 10:07:57 progress=1.000000 cache=434
145 2015-07-09 10:10:08 <jmcn> jouke: what does your client say for log2_work ?
146 2015-07-09 10:12:20 <jouke> UpdateTip: new best=0000000000080e51c0d7d1d5ddebbe8e8836b893eee48f04edffa8d3451c5b93 height=501179 log2_work=66.131168 tx=4841487 date=2015-07-09 10:10:59 progress=1.000000
147 2015-07-09 10:14:12 <gmaxwell> yea, indeed, its ahead. crazy. the v3 chain has over 1TH/s on it.
148 2015-07-09 10:14:23 <gmaxwell> oh well newer nodes will happily ignore the other chain.
149 2015-07-09 10:14:42 <gmaxwell> oh I think I know what happened. :(
150 2015-07-09 10:14:55 <jmcn> ?
151 2015-07-09 10:15:40 <gmaxwell> a big chunk of the testnet hashpower is hashpower at my office, and it was moved onto the mainnet the other day to aid with the BIP66 trouble there, I bet it didn't get moved back.
152 2015-07-09 10:16:13 <jouke> Oh lol, our wallet is creating quite a lot of testnetcoins on that chain :x
153 2015-07-09 10:16:35 <jouke> (some spare blockerupters doing their thing)
154 2015-07-09 10:16:44 <jouke> Nah, not that much.
155 2015-07-09 10:18:16 <gmaxwell> Get ready to enjoy a reorg. :P
156 2015-07-09 10:18:49 <jouke> gmaxwell: all my coins! :(
157 2015-07-09 10:18:56 <gmaxwell> hah
158 2015-07-09 10:19:01 <jmcn> :)
159 2015-07-09 10:19:47 <gmaxwell> it's gonna take a bit-- I'm not sure where the fork formed, but I think this has gone on for a little while and it'll take a bit to overtake, better sell 'em while you can. :P
160 2015-07-09 10:19:48 <jmcn> biteasy.com is also bust. :(
161 2015-07-09 10:20:35 <jouke> gmaxwell: ok, fine, I'll also switch to a new version and put some more hashingpower onto it.
162 2015-07-09 10:20:36 <jmcn> gmaxwell: so will clients on the wrong fork switch once the correct fork catches up?
163 2015-07-09 10:21:12 <gmaxwell> jmcn: yes, they'll accept both-- it's a soft fork so they'll take whichever is longer.
164 2015-07-09 10:21:40 <gmaxwell> yea, so I think it's going to take around 20k seconds to overtake with the 2.2TH/s I just moved onto it.
165 2015-07-09 10:23:02 <jmcn> hah, I know it's been 2011 since I mined, but that still seems like so much hash power for testnet. :)
166 2015-07-09 10:23:27 <gmaxwell> it's a lot for testnet, more than is normally on it by a fair bit; but this fork has been going on a little while.
167 2015-07-09 10:27:44 <jouke> Hmmm, I just switched to the new version, but I think there were no v3 blocks in the last 288 blocks?
168 2015-07-09 10:28:37 <jouke> It just happily accepts the old chain it was allready on
169 2015-07-09 10:29:02 <jmcn> jouke: reindex?
170 2015-07-09 10:29:13 <gmaxwell> jouke: yea if you're already on a fork it won't easily notice.. uh there is an easier way than reindexing.
171 2015-07-09 10:29:41 <gmaxwell> just need to figure out where the fork happened and invalidate the block and it'll reorg off of it.
172 2015-07-09 10:29:41 <jouke> checkblocks=0 right?
173 2015-07-09 10:29:58 <gmaxwell> nah that'll vomit if it notices.
174 2015-07-09 10:31:04 <gmaxwell> Can you getblockhash 498498 then 498398 then 497498 ?
175 2015-07-09 10:33:25 <jouke> 498498: 000000000012d1cb076833fb0bd43ff9a32630a636134fcf6e81e8f65b28d96f | 498398: 00000000000db3c8947d26df7c8274481b9fd582367708607e7f41f0b9557367 | 497498: 00000000002427bfac46bf4df5fff0c6b35fd256571a8dec6d44988b1791d4d9
176 2015-07-09 10:34:28 <gmaxwell> hah okay futher back 496498 ?
177 2015-07-09 10:34:47 <jouke> 000000000026830ba579e265b52c364ba93dcc9ed86a77ba3c7bea87d71d4fef
178 2015-07-09 10:35:03 <gmaxwell> 490498 ?
179 2015-07-09 10:35:11 <jouke> lol
180 2015-07-09 10:35:17 <jouke> 0000000016eb83fb24a069e61a8fe0c960acfc97c4d71827634ce3c02906a39b
181 2015-07-09 10:35:38 <gmaxwell> hurrah 493498
182 2015-07-09 10:35:53 <jouke> 00000000024ac71c53abc1fa1ff901b788a9a4dd2a0af858d5c84494a53e21ba
183 2015-07-09 10:36:00 <jouke> Meh, I once wrote a tool for this.
184 2015-07-09 10:36:05 <CodeShark> did you guys just do a manual binary search? :)
185 2015-07-09 10:36:14 <gmaxwell> 494998
186 2015-07-09 10:36:26 <jouke> 000000000163ce9aae6c5dfd12ca514990c693e9ac85b08794fe27264e786360
187 2015-07-09 10:36:49 <jouke> wait
188 2015-07-09 10:36:57 <jouke> 00000000007744dd64458e356202f5ade7c2a5bcfe9cb5faa382e40c192dc096
189 2015-07-09 10:37:18 <gmaxwell> 495748
190 2015-07-09 10:37:41 <jouke> 000000000023ca98ba2a660eba4fe3996e50147f3c0210702b22fbde2780e135
191 2015-07-09 10:39:08 <gmaxwell> 496123
192 2015-07-09 10:39:22 <jouke> 00000000000f44da5fd0653e1a4ff3eb9f9069896f3daa3b45bf703b4dfc4ab4
193 2015-07-09 10:39:38 <gmaxwell> 496310
194 2015-07-09 10:39:50 <jouke> 00000000003995694c4318dfa1967a027e78f3890a4543791cd46c613f504149
195 2015-07-09 10:40:00 <gmaxwell> 496404
196 2015-07-09 10:40:10 <jouke> 0000000000a304361d54ce821880a5347152775f59d99b570cb003874d41ffc4
197 2015-07-09 10:40:38 <gmaxwell> 496451
198 2015-07-09 10:40:50 <jouke> 0000000000a1cc51158556fee3925d1826a1cfc76791dea2dff6d311c9975dff
199 2015-07-09 10:41:03 <gmaxwell> 496474
200 2015-07-09 10:41:13 <jouke> 00000000004ce1ec6e8f3b3d7dcb6643da4d0de8c8c4bc1f2b96c0b6f0501436
201 2015-07-09 10:41:32 <gmaxwell> 496486
202 2015-07-09 10:41:41 <jouke> 00000000007f3e6e9cab9f5ec42f2709530f3dac24251a57fb5908ee089a5dce
203 2015-07-09 10:42:21 <gmaxwell> 496480
204 2015-07-09 10:42:22 <jouke> 00000000001c29dbb1c2620a1d9e06f0fe634567c3845ddb8ca7c4d5e82fc44a
205 2015-07-09 10:42:30 <jouke> :)
206 2015-07-09 10:42:33 <gmaxwell> hah
207 2015-07-09 10:42:49 <gmaxwell> okay what are the next 6?
208 2015-07-09 10:43:42 <gmaxwell> (e.g. 481 482 ... 486 )
209 2015-07-09 10:43:55 <gmaxwell> (just saving round trips instead of bisecting the last bit)
210 2015-07-09 10:44:35 <jouke> 496481: 00000000002bbfdc114c3652b032b59e341583b4934c0b91d9e0619a5721b70c | 496482: 00000000001e1eb5f64c6f7e155fa92fed4f4facdb1bc9fa3af50f5f4b070de4 | 496483: 00000000009c31668521e2d0dcb3e39aaa3995bb382f9ad83be0949819c313a8 | 496484: 0000000000696ae7a824a6ebbf1c8a3245174258bc91d96e222c39310e4fa188 | 496485: 00000000003758d041c62656498d7fc8afbc07240374427ae21a5f319aa42f03
211 2015-07-09 10:45:15 <gmaxwell> jouke: invalidateblock 00000000002bbfdc114c3652b032b59e341583b4934c0b91d9e0619a5721b70c
212 2015-07-09 10:45:20 <gmaxwell> and you should end up on the right chain.
213 2015-07-09 10:45:39 <gmaxwell> (just call that rpc)
214 2015-07-09 10:45:51 <gmaxwell> Enjoy watching it work backwards. :)
215 2015-07-09 10:47:00 <jouke> :D
216 2015-07-09 10:47:11 <jouke> cool :)
217 2015-07-09 10:47:52 <CodeShark> lol
218 2015-07-09 10:47:54 <gmaxwell> assuming you already have the right chain, it should walk back to 480 and then back up along the correct chain.
219 2015-07-09 10:48:55 <gmaxwell> technically invalidating at any point on the invalid chain that left it with less work than the valid one would have been enough to trigger the switch, assuming your node knew about the valid one already.
220 2015-07-09 10:49:16 <gmaxwell> but it's hard to predict how work on testnet is distributed due to the diff1 blocks.
221 2015-07-09 10:49:31 <jouke> Hmm.
222 2015-07-09 10:50:10 <jouke> I am not sure it's working.
223 2015-07-09 10:50:32 <jouke> Oh it is
224 2015-07-09 10:51:06 <jouke> And it is starting to ban old nodes :)
225 2015-07-09 10:52:34 <gmaxwell> jouke: whats your height right now and is it going up or down? :)
226 2015-07-09 10:53:29 <jouke> 498618 and going up
227 2015-07-09 10:53:37 <jouke> pretty fast actually
228 2015-07-09 10:53:42 <gmaxwell> well, testnet.
229 2015-07-09 10:55:19 <gmaxwell> jouke: heh: testnet has gained 128 blocks in the time we were doing that bisection.
230 2015-07-09 10:55:32 <gmaxwell> v3 testnet
231 2015-07-09 11:05:36 <jouke> Hmm, it does stay in safemode
232 2015-07-09 11:06:51 <gmaxwell> safemode?
233 2015-07-09 11:07:11 <jouke> listtransactions
234 2015-07-09 11:07:12 <jouke> error: {"code":-2,"message":"Safe mode: Warning: We do not appear to fully agree with our peers! You may need to upgrade, or other nodes may need to upgrade."}
235 2015-07-09 11:11:18 <jouke> Hmm, restart solved that.
236 2015-07-09 11:13:17 <wumpus> crazy fork detection. It shouldn't trigger again after restart.
237 2015-07-09 11:13:44 <jmcn> Delivery to the following recipient failed permanently: support@biteasy.com
238 2015-07-09 11:13:52 <jmcn> hmm, that's not encouraging. :(
239 2015-07-09 11:14:15 <jmcn> anyone know who runs biteasy?
240 2015-07-09 11:18:08 <gmaxwell> wumpus: he started in a weird state- he was on the invalid fork when he came up, because he upgraded.
241 2015-07-09 11:18:24 <gmaxwell> wumpus: then reorged down, but his node still would have known about the longer chain.
242 2015-07-09 11:20:36 <wumpus> gmaxwell: right
243 2015-07-09 11:35:19 <jouke> Hmm, since the restart it won't mine anymore with cgminer. (no solo support)
244 2015-07-09 11:39:43 <Luke-Jr> jouke: upgrade to BFGMiner 5.2?
245 2015-07-09 11:45:58 <jlrubin> hey, wondering if anyone had a chance to review the gist I shared the other day ( https://gist.github.com/JeremyRubin/1a3260431b3ee4afbaa0 ), curious to hear any thoughts about multiple phase commit in general.
246 2015-07-09 11:55:43 <CodeShark> nice effort, jlrubin - but on first glance, seems to complicate the logic considerably and doesn't address the issue of making it cheap for wallets to securely validate
247 2015-07-09 11:57:10 <CodeShark> if we could solve the problem of it being too expensive for wallets to cheaply do secure validation the miner latency issue wouldn't be a security threat to the network
248 2015-07-09 11:57:28 <CodeShark> although it would still produce a few stale blocks, which is a reduction in overall security
249 2015-07-09 11:57:35 <CodeShark> but not by very much
250 2015-07-09 11:58:39 <CodeShark> if we're after big protocol changes, we should prioritize making it cheap for smaller devices to perform reasonably secure validation
251 2015-07-09 12:02:50 <CodeShark> as for block size increases, I think that issue is so much further down the line, IMHO
252 2015-07-09 12:02:58 <CodeShark> it's so much NOT what the priority should be :p
253 2015-07-09 12:03:15 <CodeShark> but meh...
254 2015-07-09 12:06:58 <CodeShark> the network really should not be optimized to make mining cheaper - it should be optimized to make secure verification cheaper
255 2015-07-09 12:08:19 <CodeShark> anyhow, that's just my two cents
256 2015-07-09 12:13:31 <moa> add them to your next TX fee
257 2015-07-09 12:13:50 <CodeShark> that's too much ;)
258 2015-07-09 12:34:19 <jouke> Hmm, if I do getblocktemplate it'll just say: "Bitcoin is downloading blocks..."
259 2015-07-09 12:37:46 <jouke> the node still thinks I haven't catched up since the reorg?
260 2015-07-09 12:46:55 <wumpus> jouke: strange. what is the date/time of the last block? that's what IsInitialBlockdownload is based on
261 2015-07-09 12:48:21 <jouke> Sorry, just decided to do a reindex :x I was getting impatient.
262 2015-07-09 13:01:10 <ssa3512> anyone here that can help me troubleshoot gitian building?
263 2015-07-09 13:03:25 <wumpus> ssa3512: better to just report your problem, then someone that recognizes it can reply
264 2015-07-09 13:06:06 <ssa3512> ok :) I am getting an error running make-base-vm - see http://pastebin.com/fsR8QWSZ
265 2015-07-09 13:08:31 <wumpus> Strange. doesn't ring a bell here. I don't think I've ever seen problems with make-base-vm before
266 2015-07-09 13:09:01 <ssa3512> the best I could find was "Install Dialog"
267 2015-07-09 13:09:10 <ssa3512> well guess what, it's installed and that didn't work
268 2015-07-09 13:10:17 <ssa3512> someone suggested it could be a problem with lxc, but I don't think it is even to that point yet
269 2015-07-09 13:41:48 <someLord> anyone on?
270 2015-07-09 13:45:33 <leakypat> ssa3512: did you got the gitian-builder repository?
271 2015-07-09 13:45:42 <leakypat> *git
272 2015-07-09 13:47:00 <leakypat> git clone https://github.com/devrandom/gitian-builder.git
273 2015-07-09 13:47:48 <ssa3512> leakypat: yes that is the directory I am working out of
274 2015-07-09 13:48:05 <leakypat> What branch are you in?
275 2015-07-09 13:48:08 <ssa3512> I ran bin/make-base-vm --lxc --arch amd64 --suite precise from gitian-builder
276 2015-07-09 13:48:40 <leakypat> Do git branch
277 2015-07-09 13:48:54 <ssa3512> master
278 2015-07-09 13:48:59 <leakypat> And if you are in master, switch to a different one
279 2015-07-09 13:49:10 <leakypat> I can't remember off the top of my head which one it is
280 2015-07-09 13:49:13 <ssa3512> lxc?
281 2015-07-09 13:49:20 <leakypat> Possible yeah
282 2015-07-09 13:49:32 <leakypat> Are the tags there
283 2015-07-09 13:49:32 <ssa3512> I see git-archive, lxc, lxcbr, and updater
284 2015-07-09 13:49:38 <leakypat> Think it was 0.2 maybe
285 2015-07-09 13:49:43 <ssa3512> tags are 0.1 and 0.2
286 2015-07-09 13:49:55 <leakypat> Try 0.2
287 2015-07-09 13:50:06 <ssa3512> ok
288 2015-07-09 13:52:17 <someLord> hey, does anyone know why i gt a "method not found" while doing bitcoin-cli getnewaddress ? ... i'm using 0.10.2
289 2015-07-09 13:55:04 <ssa3512> leakypat: ok it's running now, I'll let you know
290 2015-07-09 13:58:30 <ssa3512> leakypat: same deal except it is trying to chroot to a directory in /tmp instead
291 2015-07-09 13:59:41 <ssa3512> going to try on a different server
292 2015-07-09 14:01:32 <leakypat> You are following the gitian-builder.md page for Debian?
293 2015-07-09 14:01:51 <ssa3512> https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md this one?
294 2015-07-09 14:01:56 <leakypat> Yep
295 2015-07-09 14:02:10 <ssa3512> mostly? not running it in virtualbox
296 2015-07-09 14:02:25 <leakypat> Ah ok
297 2015-07-09 14:02:35 <ssa3512> it's an ubuntu vps
298 2015-07-09 14:02:57 <ssa3512> oh crap I think my other box is 32 bit so that won't work at all
299 2015-07-09 14:03:40 <ssa3512> yeah it is
300 2015-07-09 14:03:53 <leakypat> I set this up a couple of weeks ago, with virtual box though
301 2015-07-09 14:04:32 <leakypat> It worked when I followed the instructions exactly and switched to the 0.2 tag
302 2015-07-09 14:05:06 <leakypat> Did you install Debian 64?
303 2015-07-09 14:05:16 <ssa3512> It's ubuntu 64 bit
304 2015-07-09 14:05:40 <ssa3512> midnightmagic said it works for him on ubuntu
305 2015-07-09 14:05:48 <leakypat> So you are installing it on a Ubuntu server running on a VM?
306 2015-07-09 14:05:57 <leakypat> Or is it a physical box?
307 2015-07-09 14:06:03 <ssa3512> It is a VM
308 2015-07-09 14:06:34 <leakypat> I tried running it on Ubuntu on virtual box and it was a disaster
309 2015-07-09 14:06:47 <ssa3512> interesting
310 2015-07-09 14:07:38 <ssa3512> I should just set up a debian vm
311 2015-07-09 14:14:06 <leakypat> I think so
312 2015-07-09 14:14:28 <leakypat> My experience was that any deviation from those instructions resulted in hours of frustration
313 2015-07-09 14:15:37 <ssa3512> sigh it would help if I gave the VM 40GB and not 40MB of hard drive space...
314 2015-07-09 14:15:44 <leakypat> Lol
315 2015-07-09 14:25:24 <wumpus> someLord: did you compile it without wallet support?
316 2015-07-09 14:36:50 <ssa3512> ok, running make-base-vm on the virtualbox host
317 2015-07-09 14:36:54 <ssa3512> will see what happens
318 2015-07-09 14:41:16 <ssa3512> erm
319 2015-07-09 14:41:21 <ssa3512> mkfs.ext4: not found
320 2015-07-09 14:41:26 <ssa3512> how does that even happen
321 2015-07-09 14:53:27 <ssa3512> there we go
322 2015-07-09 15:08:50 <ssa3512> sigh, more issues
323 2015-07-09 15:08:52 <ssa3512> http://pastebin.com/2xssS8yg
324 2015-07-09 15:09:02 <ssa3512> I ran ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-linux.yml
325 2015-07-09 15:28:28 <morcos> petertodd: here is a version of doubling the relay fee that doesn't mess around with the minRelayTxFee, https://github.com/morcos/bitcoin/commit/1ff50ca373d8684061b617d9183999e7f1b33251
326 2015-07-09 15:29:05 <morcos> I didn't make a PR yet b/c i need more time to think about where you care about the multiplier and where you don't and what to make configurable
327 2015-07-09 15:29:45 <morcos> jgarzik, this approach seems simpler perhaps?
328 2015-07-09 15:29:59 <morcos> ok, back later
329 2015-07-09 15:31:16 <nelisky> hope this isnât too noob for this channel, but having a scriptPubKey with type pubkey, asm: "asm" : "426974636f696e2c20c3a761206d61726368652e2e2e205175276f6e207365206c65206469736521 OP_CHECKSIGâ, how does one go from that (which is supposed to be a pubkey I guess) to an address?
330 2015-07-09 15:31:28 <nelisky> these 80 hex chars are puzzling me...
331 2015-07-09 15:36:40 <wumpus> EncodeBase58Check(0x00 || hash160(hash160(pubkey)))
332 2015-07-09 15:38:39 <esso> What's the best way to begin reading Bitcoin's code?
333 2015-07-09 15:39:09 <wumpus> there is no address type that maps to a pay-to-pubkey output, though: that address would map to a pay-to-pubkey-hash output that can be redeemed with the same key.
334 2015-07-09 16:20:19 <nelisky> wumpus: (sorry for asking a question and then leaving⦠family takes precedence) so there is no way to go from a pay-to-pubkey address to a bitcoin address?
335 2015-07-09 16:20:39 <nelisky> on this particular example, I see blockchain.info comes up with an address for it: https://blockchain.info/tx/90c236b3ccaf0d06a07714e78b83ebceaaf43cb704768ea100c92d7f3b8af729?show_adv=true
336 2015-07-09 16:21:35 <nelisky> but I canât reproduce it from the output details in the tx
337 2015-07-09 16:21:37 <wangchun> gmaxwell: how to make the signature much smaller?
338 2015-07-09 16:24:09 <wumpus> nelisky: right; there is no such thing as a pay-to-pubkey address, just a pay-to-pubkey output
339 2015-07-09 16:24:32 <wumpus> nelisky: yes, using the formula I gave
340 2015-07-09 16:25:29 <nelisky> wumpus: I did try your formula, guess Iâll have to try harder
341 2015-07-09 16:27:33 <wumpus> bitcoin addresses are pay-to-pubkey-hash or pay-to-script-hash
342 2015-07-09 16:29:01 <kanzure> is there a "get list of all blockhashes" rpc command?
343 2015-07-09 16:30:36 <wangchun> kanzure: for N in {0..`bitcoin getblockcount`}; do bitcoin getblockhash $N; done ?
344 2015-07-09 16:30:58 <kanzure> wangchun: that's pretty slow :-)
345 2015-07-09 16:31:28 <nelisky> wumpus: right, Iâm keeping track of all unspent outputs, and mapping them by bitcoin address so I can easily build transactions from arbitrary addresses. In this particular pay-to-pubkey the key is a text ("Bitcoin, \xc3\xa7a marche... Qu'on se le dise!â) that someone most likely created manualy, one that will never be mapped to a bitcoin address...
346 2015-07-09 16:32:25 <nelisky> wumpus: so it might be moot, this attempt to keep that particular output referenced, but what confused me was that the address I get is never the one bc.info advertises.
347 2015-07-09 16:34:48 <nelisky> wumpus: actually, I can get the same address as bc.info, but with a single hash160 iteration before the b58
348 2015-07-09 16:37:38 <wumpus> kanzure: see contrib/linearize/linearize_hashes.py, it does exactly that, but a lot faster as it uses RPC batching
349 2015-07-09 16:38:19 <wumpus> nelisky: oh right, probably that hash160() already does two iterations
350 2015-07-09 16:38:36 <nelisky> right, it likely has :)
351 2015-07-09 16:38:45 <nelisky> wumpus: thanks a lot!
352 2015-07-09 16:41:59 <kanzure> wumpus: thank you
353 2015-07-09 16:42:31 <kanzure> wumpus: it's - not _
354 2015-07-09 16:42:42 <kanzure> which makes importing a little weird, but w/e
355 2015-07-09 16:42:46 <kanzure> https://github.com/bitcoin/bitcoin/blob/7fc25c2e5d493f4ef46c9b5831d92886bcea17a8/contrib/linearize/linearize-hashes.py
356 2015-07-09 16:43:21 <kanzure> oh, batch requests work?
357 2015-07-09 16:44:47 <wumpus> yes, they've always worked AFAIK
358 2015-07-09 16:45:04 <kanzure> didn't know. will be abusing this immediately.
359 2015-07-09 17:23:51 <morcos> sipa: re: 6357, hmm, i think the loop in removeForBlock is going to process each transaction exactly once, this is really for looping through the vouts of the transactions that are confirmed. Each vout might map to an in mempool transaction that is dependent on it, which will have recalcPriority called.
360 2015-07-09 17:24:32 <morcos> So that transaction might have recalcPriority called once for each of its vin's that just got confirmed, but thats the desired behavior, b/c each just updates by the newlyInChainValue
361 2015-07-09 17:25:17 <morcos> and thats super fast
362 2015-07-09 17:25:45 <morcos> will implement a consistency check though (do you think that can have a delta?)
363 2015-07-09 18:07:11 <phantomcircuit> https://s3.amazonaws.com/archive.travis-ci.org/jobs/70102112/log.txt
364 2015-07-09 18:07:13 <phantomcircuit> we've got too many tests
365 2015-07-09 18:07:29 <phantomcircuit> we're on the edge of the maximum runtime for travis which is causing random build failures
366 2015-07-09 18:07:53 <phantomcircuit> or maybe that code is actually too slow
367 2015-07-09 18:44:41 <ThomasV> maybe this needs to be updated: http://bitcoin.stackexchange.com/questions/37152/what-is-the-maximum-size-of-the-memory-pool
368 2015-07-09 19:07:34 <bblue> Q: If a tx is included in a orphaned block, how do miners know to re-include that tx in a future block?
369 2015-07-09 19:09:41 <haakonn> when a block is orphaned, a miner dumps transactions in that block back into mempool, ready to be mined again
370 2015-07-09 19:18:34 <priidu> bblue: what haakonn said. also, it might be that the tx was already included in the rivaling block
371 2015-07-09 19:18:46 <priidu> hope I didn't repeat somebody's words now, got dc-ed for a sec :p
372 2015-07-09 19:23:30 <phantomcircuit> jgarzik, derp im testing this wrong
373 2015-07-09 19:24:20 <jgarzik> heh
374 2015-07-09 19:29:46 <ajweiss> phantomcircuit: i thought there was a caching system so that all the dependencies didn't have to be built on every run?
375 2015-07-09 19:31:12 <ajweiss> test runtimes pale in comparison to dependency tree build times
376 2015-07-09 19:31:49 <bendavenport> BitGo is now computing fees dynamically (using 0.11 estimates) https://blog.bitgo.com/bitcoin-surge-pricing-is-now-in-effect/
377 2015-07-09 19:32:21 <bendavenport> thanks morcos!
378 2015-07-09 19:37:53 <jlrubin> CodeShark: One thing I'm curious about is if multi-phase commit has any other applications as well. I think you're right that it doesn't solve the immediate problems, but it is more intended as an eventual mechanism for dynamic block size selection.
379 2015-07-09 19:52:34 <morcos> sipa: petertodd: I've noticed that there is a fair amount of duplicate transaction traffic on my node recently.
380 2015-07-09 19:53:02 <morcos> If a transaction is rejected for being a double spend, you'll request the same transaction from any of your peers that inv it to you
381 2015-07-09 19:53:32 <morcos> Also in RBF, I imagine if you replace a tx quickly, you could then end up rerequesting the orig (now to be rejected) tx over and over again as well
382 2015-07-09 19:54:07 <morcos> What do you tink about implementing a list of recently rejected transaction hashes, and then if you receive and inv for a transaction in that list, you dont' request it.
383 2015-07-09 19:54:29 <morcos> They could time out after 2 minutes or something to allow for rebroadcast in legitimate cases
384 2015-07-09 19:55:32 <jinglebells> hey guys, new to btc programming - trying to use bitcore to create a transaction and encountering some trouble
385 2015-07-09 19:56:12 <brand0> bitcore JS? or bitcoin core?
386 2015-07-09 19:56:36 <jinglebells> bitcore js
387 2015-07-09 19:56:46 <brand0> what's the difficult? I know bitcore pretty well
388 2015-07-09 19:56:47 <Luke-Jr> btcdrak: you said "One of the transaction "spammers" goal is specifically to drive bitcoin core to it's extremes until it breaks to force developers to tackle weaknesses." - do you know someone responsible?
389 2015-07-09 19:56:58 <btcdrak> Yes.
390 2015-07-09 19:57:06 <jinglebells> in creating the transaction, there are a couple fields that i don't know how to fill
391 2015-07-09 19:57:15 <jinglebells> for example, txid and script
392 2015-07-09 19:57:22 <jinglebells> the error i'm getting is a serialization error
393 2015-07-09 19:57:37 <jinglebells> "Some inputs have not been fully signed"
394 2015-07-09 19:57:40 <brand0> yeah
395 2015-07-09 19:57:46 <jinglebells> (thank you all in advance for your help!)
396 2015-07-09 19:57:55 <brand0> so that's if you provide a UTXO to which you don't have a corresponding privKey
397 2015-07-09 19:58:04 <brand0> (when trying to spend that output)
398 2015-07-09 20:01:35 <jinglebells> oh ok thank you
399 2015-07-09 20:02:04 <jinglebells> what is the output index field?
400 2015-07-09 20:02:16 <jinglebells> the example that bitcore provides is '0'
401 2015-07-09 20:03:14 <jinglebells> jk i got it haha thanks again
402 2015-07-09 20:03:24 <flyingkiwi> its an indey ;p
403 2015-07-09 20:04:39 <jinglebells> @brand0 jk it still doesn't work
404 2015-07-09 20:30:11 <brand0> jinglebells, output index corresponds to vout, or the position the corresponding output is found in the original tx
405 2015-07-09 20:30:28 <brand0> this is very basic bitcoin transaction stuff at this point though
406 2015-07-09 20:30:36 <brand0> I suggest you read the bitcoin developer guide
407 2015-07-09 20:42:30 <skyzer> hi there, is it possible to determine mining fee before sending out transaction? In my webwallet i want to exclude the transaction fee from total amount that is being sent out.
408 2015-07-09 20:43:36 <Luke-Jr> skyzer: that is not a good design
409 2015-07-09 20:44:02 <Luke-Jr> skyzer: transaction fee is influenced by many factors outside your users' control, so it should be somewhat spread across all users
410 2015-07-09 20:44:24 <jinglebells> thank you, brand0
411 2015-07-09 20:45:00 <skyzer> luke-jr, we have issue now we have lots of people sending out $1 worth of btc, and we are paying 10% miner fees.
412 2015-07-09 20:45:25 <Luke-Jr> skyzer: charge a flat fee similar to your average?
413 2015-07-09 20:45:26 <skyzer> And having some fixed amount of fees seems like robbing them, so would be great to know the miners fee upfront and adjust it to the amount user is sending out
414 2015-07-09 20:46:17 <Luke-Jr> there's a RPC to estimate a fee, but my bitcoind is broken right now so it won't give me the name
415 2015-07-09 20:46:33 <Luke-Jr> bitcoin-cli help | grep estimate
416 2015-07-09 20:47:04 <skyzer> luke-jr: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list nothing here
417 2015-07-09 20:47:07 <skyzer> only settxfee
418 2015-07-09 20:47:22 <Luke-Jr> skyzer: it's outdated
419 2015-07-09 20:47:27 <skyzer> nice
420 2015-07-09 20:47:32 <Luke-Jr> (please update it)
421 2015-07-09 20:47:32 <skyzer> yea, grep shows it
422 2015-07-09 20:47:54 <skyzer> so before sending out, im calling first estimate fee, and then adjust the amount?
423 2015-07-09 20:48:58 <Luke-Jr> I think there may also be a way to automatically subtract the fee from the sent amount
424 2015-07-09 20:49:34 <skyzer> want to show it in a nice way to user, but whole thing is more complicated, i don't know the size of transaction upfront
425 2015-07-09 20:49:42 <skyzer> estimatefee is saying 0.00157671 per kb
426 2015-07-09 20:49:51 <skyzer> for next block
427 2015-07-09 20:53:18 <Luke-Jr> skyzer: usually you don't want to target the next block
428 2015-07-09 21:00:07 <ruby32> fees are based on market conditions as well as some consensus code in miners' bitcoind, right?
429 2015-07-09 21:00:45 <gmaxwell> please move this discussion to #bitcoin
430 2015-07-09 21:01:53 <Luke-Jr> uh, LogPrintf doesn't throw warnings for invalid format? :/
431 2015-07-09 21:02:53 <jgarzik> Luke-Jr, really? that's odd
432 2015-07-09 21:04:08 <ssa3512> wow ECDSA is fairly CPU intensive isn't it?
433 2015-07-09 21:04:15 <Luke-Jr> jgarzik: apparently :|
434 2015-07-09 21:04:20 <brand0> ssa3512, compared to?
435 2015-07-09 21:04:28 <Luke-Jr> jgarzik: instead, I just get a runtime exception :|
436 2015-07-09 21:04:44 <ssa3512> brand0: well, I was reading about this brainwallet cracker that someone is apparently releasing at defcon
437 2015-07-09 21:05:10 <ssa3512> and so I wrote a dictionary combiner as a proof of concept and a coding challenge
438 2015-07-09 21:05:15 <gmaxwell> ssa3512: that has nothing to do with ECDSA... no signing is required to crack brainwallets.
439 2015-07-09 21:05:33 <ssa3512> gmaxwell: you have to use ECDSA to compute the private key doesn't it?
440 2015-07-09 21:05:37 <ssa3512> don't you?*
441 2015-07-09 21:05:44 <ssa3512> er the public key
442 2015-07-09 21:05:47 <ssa3512> jeez I need to go home
443 2015-07-09 21:06:03 <jgarzik> Luke-Jr, it is the whole point of tinyformat.h et. al.
444 2015-07-09 21:06:36 <ssa3512> anyway, my program is appending six dictionary words and then calculating public & private keys from them. It's about 25 per second which seems really slow
445 2015-07-09 21:06:58 <brand0> i bet your bottleneck isn't your ECDSA library
446 2015-07-09 21:06:58 <gmaxwell> yea, the runtime exceptions from tinyformat are obnoxious, it's really hard to find the guilty line of code.
447 2015-07-09 21:07:35 <ssa3512> brand0: I'm using bouncycastle
448 2015-07-09 21:08:15 <gmaxwell> ssa3512: My code can try 500 million brainwallets per second.
449 2015-07-09 21:08:30 <ssa3512> gmaxwell: wow
450 2015-07-09 21:08:37 <ssa3512> what the hell did I do wrong =/
451 2015-07-09 21:08:46 <gmaxwell> used bouncycastle?
452 2015-07-09 21:09:17 <BlueMatt> wrote it in java?
453 2015-07-09 21:09:22 <ssa3512> C#
454 2015-07-09 21:09:42 <BlueMatt> still a bad idea
455 2015-07-09 21:09:45 <gmaxwell> Aren't very expirenced in ellpitic curve cryptography, number theory, SIMD, etc? :)
456 2015-07-09 21:09:56 <ssa3512> yes, that would be a true statement
457 2015-07-09 21:10:37 <ssa3512> I am a very novice coder
458 2015-07-09 21:10:49 <ssa3512> but trying to learn more
459 2015-07-09 21:11:50 <ssa3512> hey, I am proud of the fact that I was able to take the words and get WIF key and bitcoin address from them
460 2015-07-09 21:18:28 <gmaxwell> ssa3512: sure, just don't expect it to be fast.
461 2015-07-09 21:30:09 <brand0> lol, the snoodiness in this room just blew through the roof
462 2015-07-09 21:43:17 <ajweiss> i threw together a basic one just using some C, libsecp256k1 and some bits of bitcoin core.. i never did characterize its speed...
463 2015-07-09 21:44:03 <ajweiss> i think i abandoned it when i realized that i was just building a slow version of vanitygen. : )
464 2015-07-09 21:46:33 <gmaxwell> gah, should have said 500 thousand/sec above. (my vanity gen numbers are in the millions)
465 2015-07-09 21:48:05 <brand0> you have a GPU cluster or something?
466 2015-07-09 21:48:42 <leakypat> ssa3512: it will likely be the bouncy castle ecmult is very slow, when deriving the public key
467 2015-07-09 21:49:45 <brand0> c# isn't known for its speed
468 2015-07-09 21:51:34 <leakypat> To do what you are doing as a prototype maybe c++ and OpenSSL libraries would be a step in the right direction
469 2015-07-09 22:32:14 <ssa3512> god Java is such an awful language
470 2015-07-09 22:32:33 <ssa3512> I will be so glad when this class is done
471 2015-07-09 22:32:54 <ST3R> I wish it dies at least once week!
472 2015-07-09 22:33:23 <ssa3512> yeah well Compsci 201 is Java Java Java
473 2015-07-09 22:33:24 <ssa3512> ugh
474 2015-07-09 23:42:24 <jcorgan> kids these days complain about everything. in my day we had to use Pascal, or even FORTRAN.
475 2015-07-09 23:43:01 <jcorgan> do you know how hard it was to implement bitcoin in FORTRAN?
476 2015-07-09 23:43:55 <ajweiss> vertically stacked transactions
477 2015-07-09 23:43:59 <ajweiss> *shudder*
478 2015-07-09 23:46:17 <someLord> 10 go to 20
479 2015-07-09 23:46:43 <someLord> if you typed a , instead of a . you were dead
480 2015-07-09 23:46:58 <someLord> i played games, first wrote them and ... if i didn't made a mistake played them
481 2015-07-09 23:48:07 <jcorgan> we would submit bitcoin transactions with a stack of punched cards and wouldn't even get 0-conf until the next day
482 2015-07-09 23:48:49 <someLord> that is not different from the 30-conf blockchain is demanding :))
483 2015-07-09 23:48:56 <jcorgan> LOL