1 2012-12-17 00:36:52 <cosurgi> wjere's Artforz?
2 2012-12-17 00:36:57 <cosurgi> where's Artforz?
3 2012-12-17 00:37:05 <cosurgi> ;;seen Artforz
4 2012-12-17 00:37:06 <gribble> Artforz was last seen in #bitcoin-dev 1 year, 26 weeks, 4 days, 3 hours, 21 minutes, and 1 second ago: <ArtForz> eternal beta. hah, satoshi is secretly a google employee!
5 2012-12-17 00:37:35 <cosurgi> huh? did I lose contact for so long?
6 2012-12-17 00:37:49 <cosurgi> omg
7 2012-12-17 00:38:18 <cosurgi> do you guys think any of those ASIC companies being credible?
8 2012-12-17 00:47:27 <gmaxwell> they're credible, competent remains to be seen... but this is offtopic for dev really. Should probably move it to -mining or just #bitcoin. :P
9 2012-12-17 04:17:09 <stam3> YOU ARE A PIECE OF SHIT GMAXWELL
10 2012-12-17 04:17:27 <weex> lol
11 2012-12-17 04:17:43 <stam3> what's funny?
12 2012-12-17 04:17:57 <stam3> isn't he a piece of shit?
13 2012-12-17 05:50:41 <stam3> and i also wanted to say, SUCK MY COCK GMAXWELL
14 2012-12-17 08:59:59 <SupaDupa> wsup skanky bitches?
15 2012-12-17 09:05:10 <SupaDupa> hey RainbowDash
16 2012-12-17 09:05:15 <SupaDupa> why are you such a fuckin cunt?
17 2012-12-17 09:08:36 <AssWobbles> hey fags
18 2012-12-17 09:08:38 <AssWobbles> hi again
19 2012-12-17 09:08:39 <AssWobbles> wsup
20 2012-12-17 09:08:40 <AssWobbles> ?
21 2012-12-17 09:08:41 <AssWobbles> :D
22 2012-12-17 09:08:42 <AssWobbles> :D
23 2012-12-17 09:08:43 <AssWobbles> :D
24 2012-12-17 09:08:44 <AssWobbles> :D
25 2012-12-17 09:08:45 <AssWobbles> :)
26 2012-12-17 09:08:46 <AssWobbles> :)
27 2012-12-17 09:08:51 <AssWobbles> la la la ala la la la al al ala la
28 2012-12-17 09:09:00 <AssWobbles> ban me bitch
29 2012-12-17 09:17:20 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
30 2012-12-17 09:17:21 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
31 2012-12-17 09:17:22 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
32 2012-12-17 09:17:23 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
33 2012-12-17 09:17:24 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
34 2012-12-17 09:17:25 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
35 2012-12-17 09:17:26 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
36 2012-12-17 09:17:27 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
37 2012-12-17 09:17:30 <AssWobbles> Wobble Baby Wobble Baby Wobble Baby YAAAAAAAAAA!
38 2012-12-17 09:17:53 <gmaxwell> Kind of him to show himself out.
39 2012-12-17 09:18:04 <AssWobbles> wobble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble
40 2012-12-17 09:18:07 <AssWobbles> obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble obble
41 2012-12-17 09:18:08 <AssWobbles> obble obble obble obble obble obble obble obble obble obble obble obble obble
42 2012-12-17 09:18:09 <AssWobbles> obble obble obble obble obble obble obble obble
43 2012-12-17 09:29:01 <sturles> He asked me to remove the negative rating I gave him on #bitcoin-otc. I think not..
44 2012-12-17 10:06:32 <forgot> why rpcminer-cuda.cuda_in.m_merkle is defined as an unsigned int? http://bpaste.net/show/w6flLBjEZNZXRM8hOT2h/
45 2012-12-17 11:49:32 <stam5> (got the harry potter joke btw)
46 2012-12-17 11:49:55 <stam5> (and it's a joke)
47 2012-12-17 11:50:35 <_dr> forgot: well, what should it be?
48 2012-12-17 11:50:41 <denisx> .d
49 2012-12-17 11:51:12 <kinlo> which joke?
50 2012-12-17 11:54:40 <forgot> merkle root should be 256 bit
51 2012-12-17 13:13:55 <jamalaka> MagicalTux: the ssl-cert of bitcoin.it has expired on 16.12.2012 and needs to be renewed.
52 2012-12-17 13:28:53 <jgarzik> jamalaka: he knows, but thanks!
53 2012-12-17 13:30:46 <jamalaka> well.. I don't know any way to detect if he knows about that.
54 2012-12-17 13:31:04 <jamalaka> is there a way?
55 2012-12-17 13:31:13 <sipa> jamalaka: yes, you query the jgarzik :p
56 2012-12-17 13:31:23 <jamalaka> :D
57 2012-12-17 13:32:03 <jamalaka> I will next time ^^
58 2012-12-17 13:47:46 <forgot> is m_AH the hash of first 64byte chunk of the 80bytes block header?
59 2012-12-17 13:51:37 <forgot> am I spamming?
60 2012-12-17 14:01:37 <jgarzik> forgot: no idea what m_AH is
61 2012-12-17 14:02:02 <sipa> mille ampere hash?
62 2012-12-17 14:02:07 <sipa> *milli
63 2012-12-17 14:02:13 <forgot> jgarzik, it's defined in rpcminer-cudaminer
64 2012-12-17 14:02:33 <forgot> http://bpaste.net/show/w6flLBjEZNZXRM8hOT2h/
65 2012-12-17 14:02:47 <jgarzik> forgot: #bitcoin-mining is more appropriate, but I dunno if that author is still around :(
66 2012-12-17 14:03:27 <forgot> thx for the hint
67 2012-12-17 14:04:15 <forgot> this is the cuda kernel source http://bpaste.net/show/UwTIg0fD1ATyMUNDzxcx/
68 2012-12-17 14:08:46 <etotheipi_> sipa: can you remind me how Bitcoin-Qt does message signing?
69 2012-12-17 14:08:58 <etotheipi_> just, what algorithm, etc
70 2012-12-17 14:09:02 <etotheipi_> (or gmaxwell )
71 2012-12-17 14:09:31 <sipa> ecdsa with pubkey recovery in a custom signature encoding
72 2012-12-17 14:10:04 <etotheipi_> oh, I didn't realize it was based on pubkey recovery... I still need to implement that
73 2012-12-17 14:10:17 <etotheipi_> well, I wanted to make Armory's signatures compatible
74 2012-12-17 14:13:23 <etotheipi_> so what is the sig encoding?
75 2012-12-17 14:13:48 <sipa> one byte + 32-byte R + 32-byte S
76 2012-12-17 14:14:18 <sipa> the one byte is 27 (not 0x27) + flags, where flags consists of 3 bits
77 2012-12-17 14:14:36 <etotheipi_> gah, maybe there should be a BIP for this, or something
78 2012-12-17 14:14:41 <sipa> yeah
79 2012-12-17 14:15:52 <forgot> did I just got kicked? sorry for flooding
80 2012-12-17 14:15:58 <etotheipi_> If bitcoin-qt is going to continue to support message signing, isn't there some way we can all use "signature blocks"?
81 2012-12-17 14:16:06 <etotheipi_> it doesn't have to be the way armory does it
82 2012-12-17 14:16:27 <etotheipi_> I just want a non-ambiguous way to transmit message&signature in one copy
83 2012-12-17 14:17:22 <etotheipi_> something that will preserve whitespace, and preferably be copy&paste-able via email
84 2012-12-17 14:17:30 <sipa> mhmm
85 2012-12-17 14:18:38 <sipa> easiest is probably to add the encoded message inside a base64 encoded structure or so, but that loses human readability
86 2012-12-17 14:18:40 <etotheipi_> even if it's just hex encoding the raw the raw ASCII codes and bundling them into an opaque block of base64 or base58, etc
87 2012-12-17 14:19:00 <etotheipi_> well, I'd prefer human readability, but it's not a requirement
88 2012-12-17 14:19:12 <etotheipi_> the verifying system can display the decoded message
89 2012-12-17 14:19:57 <etotheipi_> but yes, I'd prefer human readability in the block... but I think it *must* be encoded some way that can be transmitted via email
90 2012-12-17 14:20:15 <etotheipi_> regardless of the readability
91 2012-12-17 14:20:26 <upb> what would be the point of base64(hexencode(data))
92 2012-12-17 14:20:40 <etotheipi_> upb: there isn't one, I mistyped
93 2012-12-17 14:26:42 <gmaxwell> etotheipi_: readable is a requirement.
94 2012-12-17 14:27:08 <gmaxwell> etotheipi_: "Here, sign this opaque blob" ... nothing could go wrong. :P
95 2012-12-17 14:27:23 <etotheipi_> gmaxwell: I'm talking about the already signed blob
96 2012-12-17 14:27:32 <stam6> why are you still here?
97 2012-12-17 14:28:11 <gmaxwell> etotheipi_: there are a lot of applications where the signature doesn't need to include the message at all?????I think the most frequent use of our signing is for authentication.
98 2012-12-17 14:29:42 <etotheipi_> gmaxwell: that's fine.... I'm not talking so much about authentication as the ability for a user to use their known identity (address they just paid for something with), to sign instructions/confirmation messages
99 2012-12-17 14:30:01 <Matt_von_Mises> For the new "ultrprune", are there these "undo" files for every single block? I'm guessing they contain references to the transactions for prevOut data, so that unspent output data can be restored. If these are for every single block, I'm struggling to see how this saves much more space than an entire transaction index?
100 2012-12-17 14:31:07 <gmaxwell> Matt_von_Mises: where did you get the idea that the point is to save space??
101 2012-12-17 14:31:20 <Matt_von_Mises> "prune"?
102 2012-12-17 14:31:37 <Matt_von_Mises> What does "prune" mean in this context?
103 2012-12-17 14:31:53 <etotheipi_> sipa: gmaxwell: I assume you've seen what Armory does already? https://bitcointalk.org/index.php?topic=70911.msg813815#msg813815
104 2012-12-17 14:31:54 <gmaxwell> The coins database has nothing but the current unspent transactions in t.
105 2012-12-17 14:32:25 <etotheipi_> I want to improve that in two ways: better format for the signature blocks that's more versatile, and a way for someone to request a signature
106 2012-12-17 14:33:01 <Matt_von_Mises> gmaxwell: yes but you still need the references to transactions for reorganisation, which is what the undo files are all about I'm assuming.
107 2012-12-17 14:33:09 <gmaxwell> etotheipi_: two of the three cases you list there don't need the message coming back in the signature.
108 2012-12-17 14:33:34 <gmaxwell> Matt_von_Mises: Yes? and?
109 2012-12-17 14:34:00 <etotheipi_> gmaxwell: okay... so does that mean that bundling the message shouldn't be part of the spec and we just neglect the 1/3 cases that benefit from it?
110 2012-12-17 14:34:06 <Matt_von_Mises> gmaxwell: I just wanted to make sure I looked at that right. The word "prune" is misleading to me.
111 2012-12-17 14:34:09 <gmaxwell> etotheipi_: I'm not saying that.
112 2012-12-17 14:35:50 <etotheipi_> gmaxwell: sorry, I don't mean to be corrosive, you're just pointing out it's frequently not needed, and I'm pointing out there's no reason not to include it
113 2012-12-17 14:35:54 <sipa> Matt_von_Mises: the reason for the name is that ultraprune originally started as an experiment to see how small the UTXO set could be encoded
114 2012-12-17 14:35:55 <gmaxwell> Matt_von_Mises: It's not??? the txoutset is maximally pruned and self sufficient for validation. This means that you can throw away block data before the point you expect to directly handle a reorg, assuming you don't need to serve those blocks to other nodes.
115 2012-12-17 14:36:08 <gmaxwell> Matt_von_Mises: though ultraprune doesn't do this.
116 2012-12-17 14:36:26 <sipa> Matt_von_Mises: and grew into a new database/validation engine based on a very compactly represented utxo set
117 2012-12-17 14:36:30 <gmaxwell> Matt_von_Mises: the primary pratical improvement it provides today is that it enormously reduces the working set size.
118 2012-12-17 14:36:56 <Matt_von_Mises> gmaxwell, sipa: What would the risks of using undo files backwards only for so many blocks instead of for the entire chain? In that case if there was a larger reorganisation than there was undo information then the entire block-chain would need to be rescanned.
119 2012-12-17 14:37:10 <gmaxwell> (The design of bitcoin makes pruning and reorg generally incompatible)
120 2012-12-17 14:37:42 <sipa> Matt_von_Mises: that would work; you can generally delete old block files and old undo files if you're ready for the risk of larger reorgs or rescans of older data
121 2012-12-17 14:38:04 <sipa> Matt_von_Mises: but that's not implemented now, because of the potential risks for the network as a whole if everyone would start pruning
122 2012-12-17 14:38:48 <gmaxwell> Matt_von_Mises: thats fine, but the undo data is small, only about 12% of the block data size.. and only accessed in reorgs.
123 2012-12-17 14:39:50 <gmaxwell> continuing what sipa said, especially since the p2p protocol currently has no mechenism to handle figuring out what nodes are able to serve which blocks other than the big node network switch.
124 2012-12-17 14:39:56 <Matt_von_Mises> gmaxwell: Yes, 12% is small. It's not much of a saving.
125 2012-12-17 14:40:19 <sipa> but there is certainly no use in keeping more undo data than you keep block data, for example
126 2012-12-17 14:40:46 <sipa> and one of the advantages of the ultraprune design is that you don't need all block data in the first place, on a regular basis
127 2012-12-17 14:42:28 <Matt_von_Mises> sipa, gmaxwell: OK, thanks for clarifying.
128 2012-12-17 14:42:32 <sipa> Matt_von_Mises: anyway, i agree the name is confusing now; i've generally started using "the 0.8 engine" or "the 0.8 database layout" instead of ultraprune
129 2012-12-17 14:42:44 <gmaxwell> there is also the possibility of 'compressing' the undo data, so that you could get it from someone else for a reorg.
130 2012-12-17 14:43:04 <etotheipi_> sipa: when do you think 0.8 will become official?
131 2012-12-17 14:43:11 <sipa> when it's ready
132 2012-12-17 14:43:14 <etotheipi_> I have to change around a bit of Armory's loops under the hood
133 2012-12-17 14:43:19 <sipa> not too soon
134 2012-12-17 14:43:21 <etotheipi_> and I decided I just need to create a new Armory version to handle it
135 2012-12-17 14:43:55 <etotheipi_> is it safe to say I can procrastinate on it for a month?
136 2012-12-17 14:44:26 <gmaxwell> etotheipi_: what do you need to change beyond the path name?
137 2012-12-17 14:44:44 <sipa> gmaxwell: dealing with prealloc
138 2012-12-17 14:44:46 <etotheipi_> gmaxwell: the pre-allocation of the block files is really screwing me up
139 2012-12-17 14:44:53 <etotheipi_> armory detects new blocks based on file size
140 2012-12-17 14:45:04 <gmaxwell> ah.
141 2012-12-17 14:46:20 <etotheipi_> so yeah, I have to change around some core loops, and I don't feel like trying to branch the logic there...
142 2012-12-17 14:47:06 <gmaxwell> etotheipi_: will you change to using the rpc for block detection?
143 2012-12-17 14:47:47 <etotheipi_> gmaxwell: no
144 2012-12-17 14:47:53 <etotheipi_> unless I have a very compelling reason
145 2012-12-17 14:47:59 <denisx> I use -blocknotify="killall -USR1 pushpoold"
146 2012-12-17 14:48:32 <jgarzik> etotheipi_: nod -- why not use -blocknotify?
147 2012-12-17 14:48:36 <etotheipi_> there's two good reasons for the way I do it: (1) Armory doesn't store any block data. It only stores file pointers to the blk*.dat files, so I gotta find it in the blkfile eventually
148 2012-12-17 14:48:42 <gmaxwell> etotheipi_: well, it also lets you do things like detect when the node has no connections, or when it has detected that the network is broken or unsafe.
149 2012-12-17 14:49:25 <etotheipi_> (2) It allows for some super-minimal armoryengine scripts... since I can effectively run a blockchain-watching loop without any of the networking
150 2012-12-17 14:50:17 <etotheipi_> while(True): numNewBlk = readBlkFileUpdate(); if numNewBlk>0: doSomethingUseful()
151 2012-12-17 14:51:13 <jgarzik> the file mod time shouldn't change outside of block updates
152 2012-12-17 14:51:27 <jgarzik> 0.7 or 0.8
153 2012-12-17 14:51:31 <etotheipi_> true...
154 2012-12-17 14:52:17 <etotheipi_> I actually already know how to handle it, I just don't want to try to have a dual-purpose core loop... I'd rather just make a new version specifically for 0.8+ and make it avialable with 0.8 is available
155 2012-12-17 14:52:38 <gmaxwell> jgarzik: hopefully you don't miss an update that came too fast.
156 2012-12-17 14:53:19 <jgarzik> I don't see why a 0.8-specific version is needed
157 2012-12-17 14:53:30 <jgarzik> should be perfectly possible to code for both 0.7 and 0.8
158 2012-12-17 14:53:34 <etotheipi_> jgarzik: it is *possible* to do it
159 2012-12-17 14:53:48 <jgarzik> without any "if (ver=foo)" checks
160 2012-12-17 14:53:50 <etotheipi_> and when I thought it was just blk file names changing
161 2012-12-17 14:54:19 <gmaxwell> Your new code for detection should still work on 0.7, so it's just the names to make 0.7 work with your 0.8 code; no?
162 2012-12-17 14:55:14 <etotheipi_> gmaxwell: oh, now I get it.... I was thinking about branching code based on version
163 2012-12-17 14:55:28 <etotheipi_> but you're saying it should be easy to modify them to work with 0.8 that also works with 0.7
164 2012-12-17 14:55:34 <etotheipi_> that's probably true
165 2012-12-17 14:57:09 <etotheipi_> sorry jgarzik, I get it now
166 2012-12-17 14:57:29 <etotheipi_> thanks
167 2012-12-17 14:58:55 <jgarzik> Boy, that was easy. "Click checkbox to indicate that you still agree and comply with the Corporate Code of Conduct, and have reviewed the attached ethics materials."
168 2012-12-17 14:59:11 <jgarzik> no 50-page JavaScript wizard with 10-question course at the end. <whew>
169 2012-12-17 14:59:49 <gavinandresen> ooh, good idea. We need a Bitcoin Core Developer Code Of Conduct. Otherwise, who knows what we'll do?
170 2012-12-17 15:00:48 <jgarzik> boy, that would melt the collective trollbrain
171 2012-12-17 15:02:07 <sipa> "I hereby declare ...
172 2012-12-17 15:02:12 <sipa> all variables."
173 2012-12-17 15:02:55 <gavinandresen> "I pledge my honor to do my best, to test my pull requests, to fix bugs quickly..."
174 2012-12-17 15:03:26 <jgarzik> For the curious, we are required to page through 50-100 page online courses, followed by a 10-question [easy] quiz, on: Avoiding Bribery and Corruption: A Global Overview, Corporate Compliance and Ethics Training, Preventing Workplace Harassment.
175 2012-12-17 15:03:47 <jgarzik> The Code of Conduct Certification, a fourth, is thankfully the easy checkbox.
176 2012-12-17 15:04:17 <jgarzik> sipa: guess we have to remove python from the tree then ;p
177 2012-12-17 15:08:05 <stam7> jgarzik: who is requiring that from you?
178 2012-12-17 15:08:56 <stam7> because for everything that is "required", there has to be someone who does the requiring
179 2012-12-17 15:09:56 <stam7> oh right, i am not supposed to be answered to
180 2012-12-17 15:10:22 <stam7> being a known troll and all - totally deserving it, of course
181 2012-12-17 15:12:02 <sipa> gmaxwell, etotheipi_: humam readable signed messages has the risk that people don't validate it at all, like people somehow trust data that is gpg signed by some unknown key
182 2012-12-17 15:13:06 <gmaxwell> sipa: indeed. "I was expecting you to sign X, you gave me a valid signature, I'll assume its of X"
183 2012-12-17 15:13:44 <etotheipi_> or really lazy people who just see the correct message in the sig block and assume the sig is probably valid and just accept it anyway...?
184 2012-12-17 15:14:02 <sipa> i meamt what etotheipi_ sai
185 2012-12-17 15:14:04 <sipa> d
186 2012-12-17 15:14:44 <stam7> and suppose, jgarzik, that you don't do as "required", what happens in that case?
187 2012-12-17 15:23:31 <etotheipi_> sipa: I am fine without human readability (though I still prefer it)
188 2012-12-17 15:23:58 <etotheipi_> I just want something that has all the necessary data bundled and easy to copy via email
189 2012-12-17 15:24:57 <etotheipi_> just like a URL... whatever is used to request signatures, would of course request confirmation from the user before signing, and the app would have someway to signal that strange characters are part of what they are signing
190 2012-12-17 15:30:17 <forgot> it seems the mysterious m_AH i talked about is sha256 midstate :3
191 2012-12-17 15:58:22 <EdmundF> hellp!
192 2012-12-17 15:58:37 <EdmundF> how do i compile ufasoft cpu miner?
193 2012-12-17 16:00:15 <EdmundF> i got the last one from http://darkgamex.ch/ufasoft/
194 2012-12-17 16:01:31 <sipa> why do you want a cpu miner in the first place?
195 2012-12-17 16:03:05 <EdmundF> it's on a server with no GPU
196 2012-12-17 16:04:09 <sipa> that's far from a reason to run a CPU miner on it
197 2012-12-17 16:04:30 <EdmundF> ._.
198 2012-12-17 16:05:23 <EdmundF> it should be straightforward to compile something...
199 2012-12-17 16:05:51 <sipa> agree, but i don't know anything about ufasoft, and i still wonder why you need a CPU miner :)
200 2012-12-17 16:06:30 <EdmundF> even if i get under 1 mhash/s it's still something i guess
201 2012-12-17 16:06:56 <sipa> that will gain you less than just the *extra* power your server uses because of the miner running
202 2012-12-17 16:11:34 <EdmundF> argh and now i can't install libpcre3
203 2012-12-17 16:11:51 <EdmundF> i hate linux when it dosn't work...
204 2012-12-17 16:45:31 <phantomcircuit> sipa, im guessing he doesn't pay for power
205 2012-12-17 16:46:08 <phantomcircuit> i have a cpu miner running on a dedicated box at a certain uk dc that i was trying out
206 2012-12-17 16:46:31 <phantomcircuit> but they kept cutting off network access so im just burning through power until the subscription expires
207 2012-12-17 16:52:32 <MC1984> the harry potter depicted in this fanfic is an aspie sociopath
208 2012-12-17 16:54:05 <sipa> which? HPMoR?
209 2012-12-17 16:55:51 <MC1984> ye
210 2012-12-17 17:01:52 <MC1984> the adventures of harry potter starring derren brown as harry potter
211 2012-12-17 17:48:41 <jgarzik> phantomcircuit: These days, if I have an available core or so, I'll run the internal CPU miner on bitcoin/bitcoin.git HEAD
212 2012-12-17 17:49:11 <jgarzik> phantomcircuit: Rationale being it is more valuable to test the block building code on HEAD, than earning $0.000001/day from a pool
213 2012-12-17 17:49:15 <phantomcircuit> jgarzik, it's cold enough that it's basically a space heater that pays for itself
214 2012-12-17 17:49:26 <phantomcircuit> that's actually a good idea
215 2012-12-17 17:49:32 <phantomcircuit> i'll do that instead
216 2012-12-17 17:49:35 <jgarzik> cool
217 2012-12-17 17:49:50 <jgarzik> ultraprune definitely needs as much testing, especially mining-testing, as possible
218 2012-12-17 17:50:10 <jgarzik> ACTION has one core mining testnet3, and one core mining mainnet
219 2012-12-17 17:58:38 <jgarzik> Oh man, this Android /dev/mem thing is just too funny. https://plus.google.com/105018605612129308043/posts/5PgtN4HgxFX
220 2012-12-17 18:16:49 <BlueMatt> jgarzik: wait...that was the critical security flaw in samsung phones...wow...you are fucking kidding me
221 2012-12-17 18:17:46 <sipa> "too hard to find exactly which address range ought to be accessible... meh just make it r/w for everyone, everywhere"
222 2012-12-17 18:18:10 <jgarzik> BlueMatt: Software is hard, let's go shopping
223 2012-12-17 18:18:23 <BlueMatt> jgarzik: yea...
224 2012-12-17 18:18:37 <BlueMatt> sipa: some people should be liable for criminal negligence...
225 2012-12-17 18:19:05 <phantomcircuit> lol
226 2012-12-17 18:19:12 <phantomcircuit> install cm
227 2012-12-17 18:19:17 <phantomcircuit> laugh at people being exploited
228 2012-12-17 18:20:41 <jgarzik> BlueMatt: Arjan (seasoned kernel dev) makes that very point... https://plus.google.com/u/0/114657443111661859546/posts/cd5e2ZBhUGK
229 2012-12-17 18:21:57 <sipa> BlueMatt: that's not criminal negligence - it's criminal stupidity
230 2012-12-17 18:22:09 <BlueMatt> sipa: heh, ok, fair point
231 2012-12-17 18:23:34 <jgarzik> ;p
232 2012-12-17 18:24:50 <sipa> "nobody will guess a name like '/dev/exynos-mem', right?"
233 2012-12-17 18:25:39 <BlueMatt> the best part is...there is *some* code which the camera uses to determine which mem to access, but there is no way for them to move said code into kernel space and magically make the thing (somewhat) secure...
234 2012-12-17 18:27:06 <sipa> BlueMatt: you don't just move code to the kernel layer, think of all the security risks of running with supervisor permissions!!!
235 2012-12-17 18:27:08 <gmaxwell> BlueMatt: then they might be obligated to release that code; god knows how much business they could lose with such important competative secrets made public. :P
236 2012-12-17 18:27:45 <BlueMatt> sipa: oh, good point...you know, they should really consider switching to a microkernel!
237 2012-12-17 18:28:59 <BlueMatt> gmaxwell: god, what if htc got a hold of this...it would save them literally minutes of development time, the horror!
238 2012-12-17 18:29:35 <sipa> it would push the entire industry forward to the DOS age!
239 2012-12-17 18:29:41 <gmaxwell> to be fair, there are a billion things they could have done wrong??? most of them embarassingly stupid. Even if the are super competent the odds of doing something embarassingly stupid are pretty good.
240 2012-12-17 18:30:06 <BlueMatt> sipa: omg!
241 2012-12-17 18:30:10 <sipa> well, we didn't notice our output randomizer was broken either :S
242 2012-12-17 18:30:46 <jgarzik> "I don't always randomize my bitcoin outputs... but when I do, I do it in a predictable fashion"
243 2012-12-17 18:30:51 <BlueMatt> gmaxwell: embarrassingly stupid mistake != deliberate design decision.
244 2012-12-17 18:30:58 <jgarzik> or maybe just "I don't always randomize my bitcoin outputs..."
245 2012-12-17 18:31:05 <gmaxwell> BlueMatt: bad decisions are just a kind of mistake.
246 2012-12-17 18:31:22 <gmaxwell> (or even??? hiring people who made those kinds of design decisions)
247 2012-12-17 18:31:36 <gmaxwell> (or failing to give them proper review/supervision)
248 2012-12-17 18:32:20 <BlueMatt> gmaxwell: ok, fair enough, but it does seem to indicate a failure to have proper code reviews there
249 2012-12-17 18:34:35 <gmaxwell> I mean, fedora shipped stuff that let any user on the system install packages or change the system time, and they introduced these changes without a release note even indicating it (AFAIK). They got bludgeoned somewhat for this but no one was yelling about negligence. (Both of which probably translate into full root elevation at least in some configurations)
250 2012-12-17 18:36:32 <phantomcircuit> negligence this negligence that
251 2012-12-17 18:36:41 <kuzetsa> =o.O=
252 2012-12-17 18:36:46 <BlueMatt> gmaxwell: fair enough, though in any case it indicates some failure of the review/hiring/individuals system
253 2012-12-17 18:37:01 <phantomcircuit> good luck getting around the huge warning that they assume no liability and the even bigger warning that their software is not fit for purpose
254 2012-12-17 18:37:03 <phantomcircuit> *any purpose*
255 2012-12-17 18:38:02 <BlueMatt> yea, suing them would be fruitless, still...
256 2012-12-17 18:38:28 <jgarzik> gmaxwell: "Fedora" is just another word for "open beta test" ;p
257 2012-12-17 18:38:41 <jgarzik> not exactly a consumer OS
258 2012-12-17 18:38:45 <phantomcircuit> it would be like trying to sue the devs in here if an exploit in bitcoin was found
259 2012-12-17 18:38:49 <phantomcircuit> youd just lose
260 2012-12-17 18:39:01 <gmaxwell> jgarzik: so is everthing android. :P
261 2012-12-17 18:39:03 <sipa> ACTION hides in a corner
262 2012-12-17 18:39:22 <BlueMatt> gmaxwell: so is pretty much everything...
263 2012-12-17 18:39:46 <gribble> ArtForz was last seen in #bitcoin-dev 1 year, 26 weeks, 4 days, 21 hours, 23 minutes, and 43 seconds ago: <ArtForz> eternal beta. hah, satoshi is secretly a google employee!
264 2012-12-17 18:39:46 <sipa> ;;seen ArtForz
265 2012-12-17 18:39:50 <sipa> ^
266 2012-12-17 18:40:40 <jgarzik> phantomcircuit: Almost. The patent lawyers have figured out you can sue bundlers (the entity that marries hardware and software, then ships it to consumers)
267 2012-12-17 18:40:54 <jgarzik> a lot of patent extortion going on in that area
268 2012-12-17 18:41:09 <jgarzik> liability lawyers will attack there first
269 2012-12-17 18:41:27 <BlueMatt> sipa: nice that you know what the last thing Art said was...
270 2012-12-17 18:41:53 <sipa> BlueMatt: someone typed ;;seen ArtForz here less than a day ago :)
271 2012-12-17 18:42:14 <kuzetsa> is this the only bugtracker issue thingy (closed or otherwise) for UPnP? ---> https://github.com/bitcoin/bitcoin/pull/114
272 2012-12-17 18:42:22 <BlueMatt> sipa: ah, ok
273 2012-12-17 18:42:52 <sipa> kuzetsa: is there need for another?
274 2012-12-17 18:43:29 <kuzetsa> sipa: well, there's this --> (quote) Currently the Windows makefile doesn't support any UPnP (some have suggested using Window's native UPnP library instead on Windows)
275 2012-12-17 18:44:04 <sipa> the wibdows makefile is provably outdated in several ways
276 2012-12-17 18:44:10 <sipa> *probably
277 2012-12-17 18:44:20 <phantomcircuit> jgarzik, eh
278 2012-12-17 18:44:27 <BlueMatt> sipa: Id actually go with provably there
279 2012-12-17 18:44:31 <sipa> ha!
280 2012-12-17 18:45:09 <kuzetsa> even on recent versions, enabling UPnP via the bitcoin-qt gui on windows, it is totally a placebo and serves no purpose to enable or disable it.
281 2012-12-17 18:45:18 <BlueMatt> thats not true
282 2012-12-17 18:45:21 <BlueMatt> it should work
283 2012-12-17 18:45:22 <kuzetsa> manually forwarding the ports is the only way to accept inbound cnonnections behind nnat
284 2012-12-17 18:45:25 <kuzetsa> *nat
285 2012-12-17 18:45:41 <BlueMatt> upnp support is absolutely included in bitcoin-qt.exe
286 2012-12-17 18:45:42 <kuzetsa> BlueMatt: I tested it last week
287 2012-12-17 18:45:47 <sipa> if the option is there, it means uono support is compiled in
288 2012-12-17 18:45:55 <BlueMatt> can you provide more info on your setup?
289 2012-12-17 18:46:01 <sipa> that doesn't mean it will work necessarily in your setup
290 2012-12-17 18:46:15 <kuzetsa> on a windows 7 machine on a router that works with other upnp-enabled software
291 2012-12-17 18:46:23 <kuzetsa> ...
292 2012-12-17 18:46:24 <BlueMatt> router model?
293 2012-12-17 18:46:48 <kuzetsa> Netgear WNDR3700 (N600)
294 2012-12-17 18:49:22 <BlueMatt> can you try testing directly via upnpc?
295 2012-12-17 18:49:25 <BlueMatt> from http://miniupnp.free.fr/files/
296 2012-12-17 18:49:48 <BlueMatt> (we may just need to update miniupnpc in bitcoin)
297 2012-12-17 18:52:32 <BlueMatt> (and, no, I dont actually know how to use upnpc on windows, probably need to use command prompt)
298 2012-12-17 18:53:37 <phantomcircuit> you need a visual basic gui
299 2012-12-17 18:57:18 <t7> backtrace?
300 2012-12-17 19:01:08 <kuzetsa> hmm... actually, UPnP support on my WNDR3700 (N600) seems to be working today (I switched over to dd-wrt last week)
301 2012-12-17 19:01:18 <kuzetsa> like for bitcoin-qt I mean
302 2012-12-17 19:01:26 <kuzetsa> yay aftermarket firmware :)
303 2012-12-17 19:18:48 <BlueMatt> kuzetsa: if you have some free time, Im sure the miniupnpc guys would appreciate a test on the stock firmware that didnt work
304 2012-12-17 19:24:28 <gjs278> kuzetsa what firmware did you install
305 2012-12-17 19:24:35 <gjs278> I have that same router and have been wondering on an alternative
306 2012-12-17 19:24:40 <gjs278> oh
307 2012-12-17 19:24:42 <gjs278> dd-wrt
308 2012-12-17 19:24:43 <gjs278> nvm
309 2012-12-17 19:24:48 <gjs278> have you come across any problems with it?
310 2012-12-17 19:25:49 <MC1984> but upnp is generally awful i heard
311 2012-12-17 19:56:48 <BlueMatt> gavinandresen, sipa, gmaxwell, jgarzik, TD[gone], others: ok, I think I addressed every protocol-level complaint in bloom filters and updated the pull/bip, now time to troll for acks :)
312 2012-12-17 19:58:10 <BlueMatt> https://github.com/bitcoin/bitcoin/pull/1795 and https://en.bitcoin.it/wiki/BIP_0037
313 2012-12-17 20:00:05 <sipa> BIP 0037 still doesn't mention the tweak
314 2012-12-17 20:00:20 <BlueMatt> shit, sorry
315 2012-12-17 20:00:28 <sipa> :p
316 2012-12-17 20:01:22 <sipa> i think i've read some rationale for the 36000 bytes limit, but can't find it in the BIP
317 2012-12-17 20:02:10 <BlueMatt> it may be in comments only, Ill copy those comments
318 2012-12-17 20:02:35 <sipa> also, the N in the merkleblock structure isn't explained
319 2012-12-17 20:02:45 <gavinandresen> sipa: I'm working on testing the leveldb/Windows issue. I spent a bunch of time today figuring out how to recompile dependencies on plain mingw (as opposed to cross-compiled mingw)... but eventually got stuck trying to get Makefile.mingw to compile leveldb/
320 2012-12-17 20:02:47 <BlueMatt> it is "20,000 items with fp rate < 0.1% or 10,000 items and <0.0001%"
321 2012-12-17 20:03:40 <sipa> gavinandresen: thanks for spending time on that; i'm afraid i won't have too much time before christmas
322 2012-12-17 20:04:05 <darkip> I'm trying to calculate network hashrate, but I keep getting incorrect values
323 2012-12-17 20:04:15 <gavinandresen> sipa: ok. Where/who did you get the latest windows/leveldb stuff from?
324 2012-12-17 20:04:18 <darkip> I'm calculating the hashrate for the blocks in a window for the last day
325 2012-12-17 20:04:24 <sipa> gavinandresen: it's in the commit message
326 2012-12-17 20:04:27 <darkip> then averaging them
327 2012-12-17 20:04:32 <gavinandresen> sipa: cool, thanks
328 2012-12-17 20:04:59 <darkip> can anyone suggest where I might have gone wrong
329 2012-12-17 20:05:48 <sipa> BlueMatt: if you mention anything about the size guarantees, probably best to only do that in the partial merkle tree format section, and have some reference in the messages section for the flags/hashes field saying "See further for details" or so
330 2012-12-17 20:06:02 <darkip> Here's the code I've got: http://pastebin.com/UY80jTRk
331 2012-12-17 20:06:35 <sipa> darkip: sum the difficulties of the blocks found in a period of time, divide by the length of the time window in seconds, multiply by 2^48/65535
332 2012-12-17 20:07:31 <sipa> because a difficulty 1 blocks corresponds to 2^48/65536 hashes
333 2012-12-17 20:07:40 <darkip> or 2^32 :)
334 2012-12-17 20:07:57 <darkip> I understand that's an alternative approach, I'm just curious as to why there way I'm doing it doesn't work
335 2012-12-17 20:07:57 <sipa> eh, /65535
336 2012-12-17 20:08:26 <darkip> 2^48 / 2^16 = 2^32 no?
337 2012-12-17 20:08:57 <sipa> yes, but a difficulty one block corresponds to 2^48/65535 hashes, not to 2^48/65536=2^32 hashes
338 2012-12-17 20:09:25 <sipa> so 4295032833 and not 4294967296
339 2012-12-17 20:09:35 <sipa> unlikely to make a noticeable difference though
340 2012-12-17 20:10:13 <sipa> darkip: and timediff may be negative, while you take the absolute value
341 2012-12-17 20:11:03 <darkip> doesn't that make sense?
342 2012-12-17 20:11:12 <sipa> so if you have blocks A-B-C, with B after C
343 2012-12-17 20:11:32 <sipa> so the actual interval is A-B with 3 blocks in it
344 2012-12-17 20:11:37 <BlueMatt> sipa: ok, removed mentions of the serialization size limit (its not particularly relevant), added nTweak and rationalized the 36k limit
345 2012-12-17 20:12:15 <sipa> darkip: but you calculate it as |A-B| for one block, plus |C-B| for the second, so you have effectively counted the duration of a certain interval twice
346 2012-12-17 20:12:26 <sipa> darkip: plus, if you average per block you get the wrong weights
347 2012-12-17 20:12:43 <darkip> is even weighting not acceptable?
348 2012-12-17 20:12:46 <sipa> you need to count hashes per time, not an average of hashes per time per block
349 2012-12-17 20:13:01 <sipa> so you count very short blocks as too important
350 2012-12-17 20:13:13 <sipa> as they count as much as long blocks in your calculation
351 2012-12-17 20:13:14 <darkip> makes sense
352 2012-12-17 20:13:32 <darkip> I did it a similar way, but I didn't account for the difficulty in the way you said, so the calculation was off
353 2012-12-17 20:16:32 <sipa> BlueMatt: BIP looks generally good to me; probably needs more explanation at some points (like examples of a PMT, and examples of things that would and wouldn't match), but i think in actually specified behaviour it is ready
354 2012-12-17 20:17:30 <sipa> i'll try to elaborate the PMT section a bit
355 2012-12-17 20:18:47 <BlueMatt> sipa: thanks, Ill gonna go back and try to get the bitcoinj implementation finished up then
356 2012-12-17 21:03:56 <phantomcircuit> sipa, i feel like performance improvements in the wallet code that would allow for a much larger keypool would do a lot of good for people
357 2012-12-17 21:04:13 <phantomcircuit> being able to have a huge key pool really does make backups oh so much easier to handle
358 2012-12-17 21:05:32 <sipa> phantomcircuit: it's mostly lots of transactions tha tis a problem
359 2012-12-17 21:05:56 <phantomcircuit> sipa, well when you start the client loading a ton of keys from the wallet takes ages
360 2012-12-17 21:06:12 <sipa> yeah, that's just BDB slowness
361 2012-12-17 21:06:46 <sipa> but i don't think there much O(n) code in the number of keys
362 2012-12-17 21:07:06 <sipa> loading them is one
363 2012-12-17 21:10:47 <phantomcircuit> hmm
364 2012-12-17 21:10:58 <phantomcircuit> possibly the default for keypool should be increased to 1000...
365 2012-12-17 21:11:10 <phantomcircuit> 100 is pretty high but is certainly within the realm of people hitting
366 2012-12-17 21:11:19 <phantomcircuit> 1000 is less likely to be an issue
367 2012-12-17 21:12:50 <sipa> we just need deterministic wallets :)
368 2012-12-17 21:14:05 <flatfly> sipa: how far are they on the roadmap?
369 2012-12-17 21:22:19 <Scrat> getting all transactions for an address (not in the wallet), how easy is that to impement?
370 2012-12-17 21:22:26 <Scrat> sequencial scan would suck, maybe an index?
371 2012-12-17 21:23:08 <sipa> Scrat: if there was an index, it would be easy, but as you don't need that for normal operation, no such index is kept
372 2012-12-17 21:23:24 <sipa> at least not by the reference client
373 2012-12-17 21:23:31 <sipa> flatfly: whenever someone implements them :)
374 2012-12-17 21:24:56 <Scrat> I wonder what blockchain's setup is
375 2012-12-17 21:25:07 <Scrat> probably a relational db
376 2012-12-17 21:25:16 <Scrat> blockchain.info that is
377 2012-12-17 21:26:20 <sipa> i suppose, yes
378 2012-12-17 21:27:49 <Scrat> can I use listtransactions to traverse the entire chain?
379 2012-12-17 21:28:14 <Scrat> in order to dump it to a mongodb or something
380 2012-12-17 21:32:36 <gavinandresen> sipa: cross-compiled bitcoind.exe with your leveldb17 branch is still crashing in LogAppendVA / Windows msvcrt.dll vsnprintf... I'll dig in more again tomorrow
381 2012-12-17 21:33:34 <sipa> Scrat: getrawtransaction and getblock provide access to the raw blockchain
382 2012-12-17 21:33:53 <sipa> Scrat: listtransactions and gettransaction just access your wallet
383 2012-12-17 21:34:32 <Scrat> sipa: ok
384 2012-12-17 21:36:42 <sipa> gavinandresen: still in the same place?
385 2012-12-17 21:39:34 <darkip> sipa: still having issues even with your approach, spot any silly mistakes? http://pastebin.com/XaJcpFnU
386 2012-12-17 21:40:50 <sipa> darkip: math.pow(2,48)/65535, not 32
387 2012-12-17 21:40:58 <darkip> ah
388 2012-12-17 21:41:01 <darkip> *facepalm*
389 2012-12-17 21:41:24 <darkip> been programming all day at work, and now after getting home
390 2012-12-17 21:41:45 <sipa> gavinandresen: i'm inclined to just disable logging altogether, but i'd rather find out why it fails
391 2012-12-17 21:42:50 <darkip> sipa: thanks! looks much more reasonable now :)
392 2012-12-17 21:56:31 <etotheipi_> sipa: is there a way to count the number of entries in a leveldb DB?
393 2012-12-17 22:05:22 <sipa> etotheipi_: check the API, i dunno
394 2012-12-17 22:05:46 <gavinandresen> sipa: yes, same place, but I still don't have a good debugging environment
395 2012-12-17 22:07:20 <etotheipi_> sipa: I've looked, that's why I'm asking you
396 2012-12-17 22:07:36 <etotheipi_> the "detailed" documentation on the leveldb site is pretty basic
397 2012-12-17 22:07:51 <etotheipi_> do you have a better reference?
398 2012-12-17 22:14:42 <sipa> etotheipi_: the .h files :)
399 2012-12-17 22:16:58 <etotheipi_> gah!
400 2012-12-17 22:17:38 <sipa> they're well documented, and do not contain implementation details
401 2012-12-17 22:55:09 <gmaxwell> jgarzik: it's hard for me to imagine that someone who enjoyed daemon wouldn't enjoy this hard sci-fi AI novella: http://www.fimfiction.net/story/62074/friendship-is-optimal
402 2012-12-17 23:18:00 <midnightmagic> ... lol, no idea why, but the gitian builder refuses to work for me. when it's building the sha256sum of the installed package manifests, for some reason apt-cacher-ng starts refusing connections and the process fails during the dpkg-query -W -f '${Package}\\n' | xargs -n 50 apt-get install --reinstall -y -d step.
403 2012-12-17 23:18:15 <midnightmagic> i've already upped the apt-cacher-ng maximum limits.
404 2012-12-17 23:19:08 <midnightmagic> (put a no-maximum limit of -1 in there, and upped the var: MaxStandbyConThreads: 12
405 2012-12-17 23:19:18 <midnightmagic> so MaxConThreads: -1
406 2012-12-17 23:23:36 <midnightmagic> of course there are no obvious errors in apt-cacher-ng grrr