1 2013-08-11 00:29:55 <gmaxwell> ::sigh:: https://bitcointalk.org/index.php?topic=271486.msg2907971;boardseen#new
2 2013-08-11 00:30:48 <gmaxwell> Of course, if all these wallet apps didn't constantly reuse addresses the exposure here??? whatever the root cause??? would be much lower.
3 2013-08-11 00:31:16 <phantomcircuit> gmaxwell, we were discussing that before
4 2013-08-11 00:31:24 <phantomcircuit> im not sure how that could be screwed up
5 2013-08-11 00:31:33 <phantomcircuit> SecureRandom is by default initalized from /dev/urandom
6 2013-08-11 00:31:49 <phantomcircuit> you can call setSeed which overrides the initial value
7 2013-08-11 00:31:58 <phantomcircuit> but bitcoinj which they're both based on doesn't do that
8 2013-08-11 00:32:16 <gwillen> that is ... very interesting
9 2013-08-11 00:32:21 <phantomcircuit> so possibly there is something really broken with /dev/urandom on some android phones?
10 2013-08-11 00:32:38 <phantomcircuit> samsung has a history of pretty hilarious patches
11 2013-08-11 00:32:39 <gmaxwell> phantomcircuit: possibly, or some crazy bitflips in crappy hardware.
12 2013-08-11 00:32:53 <gwillen> phantomcircuit: completely batshit insane patches, you mean
13 2013-08-11 00:33:03 <gmaxwell> or some crazy libc or java IO race condition that causes some read to get read twice.
14 2013-08-11 00:33:09 <gwillen> what if it was a first-random-after-boot issue
15 2013-08-11 00:33:17 <phantomcircuit> gwillen, well i found them hilarious cause i broke into my friends phone and made it do weird stuff
16 2013-08-11 00:33:18 <phantomcircuit> heh
17 2013-08-11 00:33:21 <gwillen> if the phones in question always produce the same first random number at boot
18 2013-08-11 00:33:29 <gwillen> that could produce this an arbitrary amount of time apart
19 2013-08-11 00:33:38 <gwillen> and it's the same thing that caused the crackable ssl keys on routers
20 2013-08-11 00:33:59 <Cusipzzz> ugly
21 2013-08-11 00:34:02 <gwillen> it would be incredibly stupid for them not to save the seed.......... unless the phone crashed
22 2013-08-11 00:34:06 <gwillen> and saves the seed on shutdown
23 2013-08-11 00:34:10 <gwillen> so it came up again with the same seed
24 2013-08-11 00:34:28 <phantomcircuit> gwillen, it's not like a phone has any lack of high quality entropy
25 2013-08-11 00:34:36 <phantomcircuit> but that doesn't mean it's being captured
26 2013-08-11 00:34:39 <gwillen> yeah
27 2013-08-11 00:34:47 <gwillen> and like, if you just booted, and you don't have a net connection yet...
28 2013-08-11 00:34:51 <gwillen> you have a fucking realtime clock though
29 2013-08-11 00:34:53 <gwillen> which you should be using
30 2013-08-11 00:35:04 <gwillen> but that ought to 100% prevent the whole thing, so.
31 2013-08-11 00:35:10 <phantomcircuit> i guess the android apps should start collecting randomness from users and combining with /dev/random and calling setSeed
32 2013-08-11 00:35:12 <gmaxwell> gwillen: a recommended practice is to generate the nonce for signing through something like SHA256(message being signed || privkey || random), so even if your random is bad you won't reuse the same value.
33 2013-08-11 00:35:20 <gwillen> ACTION nods
34 2013-08-11 00:35:28 <gmaxwell> gwillen: the reference client signing does something like that.
35 2013-08-11 00:35:28 <gwillen> does bitcoinj follow the recommended practice?
36 2013-08-11 00:35:28 <Luke-Jr> gwillen: even if you don't have a net connection, just dump random crap from the radio..
37 2013-08-11 00:35:31 <gwillen> or does it use random directly?
38 2013-08-11 00:35:38 <gwillen> (since you say they are both based on bitcoinj)
39 2013-08-11 00:35:42 <gmaxwell> I don't know what bitcoinj/bouncycastle does.
40 2013-08-11 00:35:44 <gwillen> (or IIRC someone said that)
41 2013-08-11 00:35:51 <phantomcircuit> gmaxwell, they just call SecureRandom
42 2013-08-11 00:35:54 <phantomcircuit> iirc
43 2013-08-11 00:35:57 <gwillen> ding.
44 2013-08-11 00:35:59 <phantomcircuit> let me check
45 2013-08-11 00:36:20 <gwillen> how many of these signatures have we seen?
46 2013-08-11 00:36:40 <Luke-Jr> on the bright side, now we have a real example of address reuse resulting in coin loss
47 2013-08-11 00:37:17 <gwillen> Luke-Jr: because without address reuse, the vulnerable keys would not have been in the chain to crack?
48 2013-08-11 00:37:24 <SomeoneWeird> what, really?
49 2013-08-11 00:37:47 <gwillen> SomeoneWeird: non-reuse of addresses would not have prevented the generation of bad keys
50 2013-08-11 00:38:00 <SomeoneWeird> i mean what Luke-Jr said, i'm just chiming in
51 2013-08-11 00:38:01 <gwillen> but it would prevent the bad keys from just sitting there in the blockchain waiting to be cracked
52 2013-08-11 00:38:07 <gwillen> only their hashes would be in the chain
53 2013-08-11 00:38:10 <gwillen> if I'm understanding right
54 2013-08-11 00:38:36 <gwillen> although all it really does is reduce the race window, since a transaction to _spend_ from an address does reveal its private key
55 2013-08-11 00:38:46 <gwillen> so if you see such a transaction cross the wire you can start cracking at that point, if you want
56 2013-08-11 00:38:49 <Luke-Jr> gwillen: isn't this only a problem because the same key was used in 2 signatures with the same k?
57 2013-08-11 00:38:53 <gmaxwell> gwillen: no, if there were no address reuse here they'd be fine.
58 2013-08-11 00:39:09 <gwillen> oh, because the same key would never be used in two signatures
59 2013-08-11 00:39:10 <gwillen> I see
60 2013-08-11 00:39:16 <gmaxwell> Right.
61 2013-08-11 00:39:25 <gwillen> yeah, fair enough
62 2013-08-11 00:39:29 <gmaxwell> though whatever the root cause here would probably also cause weak keys too.
63 2013-08-11 00:39:35 <gwillen> yeah.
64 2013-08-11 00:39:40 <gwillen> I was assuming these _were_ weak keys.
65 2013-08-11 00:39:51 <gmaxwell> gwillen: nah, the reports appear to be nonce reuse.
66 2013-08-11 00:40:02 <SomeoneWeird> who'd this happen to?
67 2013-08-11 00:40:10 <Cusipzzz> this happened before with the original android wallet
68 2013-08-11 00:40:11 <gwillen> SomeoneWeird: users of two android wallet clients
69 2013-08-11 00:40:15 <gwillen> Cusipzzz: !!!
70 2013-08-11 00:40:23 <gmaxwell> worse, I think we knew months ago that there was evidence of nonce reuse in android wallet.
71 2013-08-11 00:40:25 <gwillen> ok, that seems to _strongly_ implicate android's RNG
72 2013-08-11 00:40:46 <Cusipzzz> gmaxwell: yes, saw this months ago, thought a new version of the app was pushed
73 2013-08-11 00:41:21 <gmaxwell> We identified a whole bunch of nonce-reuse transactions and tracked down their sources. Some were custom mining software, some were a particular "hardware wallet", some looked like android wallet.
74 2013-08-11 00:41:35 <SomeoneWeird> interesting
75 2013-08-11 00:41:45 <Cusipzzz> gmaxwell: right, that bitcoin card wallet too
76 2013-08-11 00:41:51 <gwillen> I will bet a decent amount that this issue is something like this: the phone crashes and fails to save the seed
77 2013-08-11 00:41:56 <gwillen> so it comes back up with the same seed as last boot
78 2013-08-11 00:42:03 <gwillen> and someone happened to do a transaction just after coming up last boot
79 2013-08-11 00:42:06 <gwillen> and another just after coming up this boot
80 2013-08-11 00:42:23 <CodeShark> so the moral of the story is write your own RNG seeder if you're implementing an android wallet? :)
81 2013-08-11 00:42:27 <gwillen> ok, let me downgrade that from 'a decent amount' to 'a small amount' because it does require a lot of coincidence
82 2013-08-11 00:42:33 <gwillen> and I don't know how often this actually happened
83 2013-08-11 00:42:38 <gwillen> but it sounds like more frequently than that would suggest
84 2013-08-11 00:43:36 <gmaxwell> gwillen: seems somewhat unlike to me though... because the kernel stirs in randomness from the timer interupt... it would mean that it came up before no randomness was added, and that there had been no other reads...
85 2013-08-11 00:43:50 <gmaxwell> er unlikely
86 2013-08-11 00:44:27 <gmaxwell> so unless there is also a urandom weakness added by vendor patches to the kernel, I would still rate faulty hardware corrupting memory above that.
87 2013-08-11 00:44:39 <gwillen> ACTION nods
88 2013-08-11 00:44:44 <gwillen> OTOH if it's a samsung device
89 2013-08-11 00:44:54 <gwillen> then you can bet money on security holes being added by vendor patches
90 2013-08-11 00:44:58 <gwillen> probably hundreds of them
91 2013-08-11 00:45:02 <gwillen> one in the RNG would not shock me
92 2013-08-11 00:45:23 <gwillen> my device has a world-writable /dev/mem
93 2013-08-11 00:45:28 <gwillen> so my expectations are low
94 2013-08-11 00:45:38 <Luke-Jr> lol
95 2013-08-11 00:46:09 <Cusipzzz> they need to switch to Ubuntu<r>Phone, clearly
96 2013-08-11 00:46:17 <gwillen> didn't that fail to get enough funding
97 2013-08-11 00:46:28 <Cusipzzz> i thought they are going ahead with it
98 2013-08-11 00:46:37 <gmaxwell> (I do note, that RNG weaknesses are one of the reasons that determinstic wallets are a little more concerning than they might otherwise be...)
99 2013-08-11 00:46:48 <Luke-Jr> I'd have invested in that if they 1) added a keyboard and 2) guaranteed it was GPL compliant including kernel modules
100 2013-08-11 00:46:53 <gwillen> gmaxwell: because you might generate a bad root key?
101 2013-08-11 00:46:58 <gwillen> and you keep dying?
102 2013-08-11 00:47:14 <gwillen> Luke-Jr: well it probably supports bluetooth/USB keyboards
103 2013-08-11 00:47:19 <gwillen> since that's all in stock android now
104 2013-08-11 00:47:20 <Luke-Jr> gmaxwell: eh, wouldn't HD wallets be *more* secure, provided the original seed was good?
105 2013-08-11 00:47:28 <Luke-Jr> gwillen: not the same!
106 2013-08-11 00:47:31 <gmaxwell> gwillen: yea, vs perhaps only getting some fraction of your keys vulnerable.
107 2013-08-11 00:47:31 <gwillen> ACTION nod
108 2013-08-11 00:47:43 <gwillen> gmaxwell: but like, standard wallets are mostly _just_ as brittle
109 2013-08-11 00:47:53 <gwillen> because you frequently, by the change mechanism, send LOTS of coins aroind for no reason
110 2013-08-11 00:47:58 <gwillen> in otherwise-trivial transactions
111 2013-08-11 00:48:16 <gwillen> I have very carefully made sure that my coins are not all in one txout, because of this sort of thing
112 2013-08-11 00:48:24 <gwillen> they are in txouts of no more than 50 BTC, IIRC, which may still be too much
113 2013-08-11 00:48:48 <gmaxwell> gwillen: hm? typical users have a LOT of txouts, so change is seldom bigger than the actual output.
114 2013-08-11 00:48:48 <Luke-Jr> a reasonably diverse wallet should do that on its own
115 2013-08-11 00:49:00 <gwillen> sure, but you can easily get unlucky
116 2013-08-11 00:49:04 <gwillen> like, if you switched wallets
117 2013-08-11 00:49:13 <gwillen> you just sent youself one big txout of 1000 coins or whatever
118 2013-08-11 00:49:16 <Luke-Jr> ACTION intentionally uses coin control for every tx
119 2013-08-11 00:49:21 <gmaxwell> you could, indeed, but it is a reason that determinstic can be a little more brittle.
120 2013-08-11 00:49:21 <gwillen> (which is what I very carefully did not do)
121 2013-08-11 00:49:24 <gwillen> ACTION nods
122 2013-08-11 00:49:25 <gwillen> agreed
123 2013-08-11 00:49:48 <gwillen> Luke-Jr: does -qt have coin control?
124 2013-08-11 00:49:53 <Luke-Jr> gwillen: next-test does
125 2013-08-11 00:50:06 <gmaxwell> gwillen: you can use raw transactions to do the same thing. Thats how I transact.
126 2013-08-11 00:50:15 <gwillen> eugh.
127 2013-08-11 00:50:18 <Luke-Jr> using raw txs would be ugly
128 2013-08-11 00:50:22 <gwillen> I fear raw transactions more than I fear large txouts
129 2013-08-11 00:50:26 <gmaxwell> well, I'm not recommending it for everyone. :P
130 2013-08-11 00:50:27 <BFXBOT> gwillen is on the rise! (Karma: 1)
131 2013-08-11 00:50:27 <Cusipzzz> gwillen: ++
132 2013-08-11 00:50:32 <gwillen> hehe
133 2013-08-11 00:50:33 <Luke-Jr> ???
134 2013-08-11 00:51:36 <Luke-Jr> gwillen: FWIW, the latest next-test has some annoying (but bearable) bugs, but the one before that is pretty stable
135 2013-08-11 00:51:45 <gmaxwell> gwillen: only particular risk with raw transactions is sending all your pretty coins to change... pretty easy to avoid that. I have script that prints the change amount.
136 2013-08-11 00:53:28 <Luke-Jr> gmaxwell: petertodd has memorized transaction format well enough to hand-write them now <.<
137 2013-08-11 00:53:57 <gmaxwell> Luke-Jr: yea, I can hand write them too, I think I mentioned this the other day. though converting addresses to hash 160 isn't something I can do in my head. :P
138 2013-08-11 00:54:10 <gmaxwell> s/the other day/like four months ago/
139 2013-08-11 00:54:15 <phantomcircuit> gmaxwell, with a piece of paper though...
140 2013-08-11 00:54:25 <Cusipzzz> there is a user-friendly interface for raw-txns in .9 ?
141 2013-08-11 00:54:32 <gmaxwell> the base conversion is a pita. I wouldn't be willing to do that on paper.
142 2013-08-11 00:54:32 <Luke-Jr> Cusipzzz: no
143 2013-08-11 00:54:46 <Luke-Jr> is it even possible to have a user-friendly interface for raw txns? O.o
144 2013-08-11 00:54:47 <gmaxwell> Cusipzzz: I'm not sure what "user-friend" even could be there, it's sort of fundimentally not user friendly.
145 2013-08-11 00:54:54 <gmaxwell> hah what luke said.
146 2013-08-11 00:54:58 <Luke-Jr> XD
147 2013-08-11 00:55:25 <Luke-Jr> Klik & Play transactions?
148 2013-08-11 00:55:36 <Cusipzzz> well, i imagine a list of 'coins'/amounts that can be selected, a little click n drag with a visual showing of where everything goes :)
149 2013-08-11 00:55:50 <Luke-Jr> Cusipzzz: that's just coin control
150 2013-08-11 00:55:57 <Luke-Jr> I don't know why it isn't merged yet.
151 2013-08-11 00:56:09 <Cusipzzz> yes, that. not fully raw
152 2013-08-11 00:56:45 <gmaxwell> Luke-Jr: because so far the implementations have been kinda crappy.
153 2013-08-11 00:57:04 <Luke-Jr> gmaxwell: the current one has been working great
154 2013-08-11 00:57:14 <gmaxwell> like abusing jgarzik's txout masking stuff for that is awful.
155 2013-08-11 00:57:41 <gmaxwell> having no interactive display of fees/priority stinks, etc.
156 2013-08-11 00:58:08 <Luke-Jr> gmaxwell: that's all there..
157 2013-08-11 00:58:47 <gmaxwell> hm. it must have gained all that since I tried it out.
158 2013-08-11 00:59:04 <gmaxwell> Luke-Jr: does it compute the sizes without signing in order to compute the priority/fee?
159 2013-08-11 00:59:18 <Luke-Jr> gmaxwell: it computes some size at least
160 2013-08-11 01:00:04 <gmaxwell> hm. Yea, it's not hard to check if the key in question is compressed and then compute the conservative upper bound on the signature size, but it didn't do that originally. Cool if it does now. Pointer to the patch?
161 2013-08-11 01:00:24 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/2343
162 2013-08-11 01:02:32 <Luke-Jr> http://luke.dashjr.org/tmp/code/screenshots/snapshot107.png
163 2013-08-11 01:02:33 <Luke-Jr> err
164 2013-08-11 01:02:35 <Luke-Jr> http://luke.dashjr.org/tmp/screenshots/snapshot107.png
165 2013-08-11 01:04:36 <gmaxwell> #@$@ stupid qt qmake stuff can't seem to handle manually setting BDB_LIB_PATH
166 2013-08-11 01:05:27 <gmaxwell> oh there it goes.
167 2013-08-11 01:07:52 <gmaxwell> <3
168 2013-08-11 01:07:57 <gmaxwell> this is much better than the old stuff.
169 2013-08-11 01:08:06 <Luke-Jr> it's been sitting like this for months :P
170 2013-08-11 01:08:50 <gmaxwell> + nBytesInputs += 148; // in all error cases, simply assume 148 here
171 2013-08-11 01:09:02 <gmaxwell> that should probably assume much larger if it can't figure it out... but thats a minor nit.
172 2013-08-11 01:09:17 <Luke-Jr> if it can't figure it out, it should do something so we're aware of a bug <.<
173 2013-08-11 01:09:27 <Luke-Jr> but what exactly, not sure
174 2013-08-11 01:10:23 <gmaxwell> We need to make a pass through the code and remove every case where the string "ERROR" gets logged where we don't want people showing up on IRC telling us about it.
175 2013-08-11 01:10:57 <gmaxwell> then we need to copy off all the remaining errors into a seperate ERROR log, and when it has things in it, tell users to send the error log to the developers.
176 2013-08-11 01:11:09 <gmaxwell> (maybe even have a button to review the content and submit it)
177 2013-08-11 01:11:30 <gmaxwell> then stuff like that could just log something.
178 2013-08-11 01:12:04 <Luke-Jr> maybe the size should just read "ERROR" in red for this
179 2013-08-11 01:13:05 <gmaxwell> yea or "Unknown" in red.
180 2013-08-11 01:18:57 <gmaxwell> Luke-Jr: I think it's kinda weird that the coin control stuff is above the outputs. Don't you want to put the outputs in first?
181 2013-08-11 01:19:21 <Luke-Jr> gmaxwell: maybe.
182 2013-08-11 01:20:04 <gmaxwell> kinda tempted to make this have a red (previously used) if you tell it a custom change address that you already have outputs to. Or a red (not in this wallet) if you don't know it at all.
183 2013-08-11 01:20:45 <gmaxwell> Probably a fee/priority change that encourages sweeping should be merged in the same release as this, I'd hate to see more people being encouraged to not sweep by the red size when it goes over 10k.
184 2013-08-11 01:21:30 <Luke-Jr> that sounds like a good improvement - although not necessarily for this pullreq
185 2013-08-11 01:22:04 <gmaxwell> yea, sure sure.
186 2013-08-11 01:22:17 <Luke-Jr> keep in mind people *can't* really sweep right now
187 2013-08-11 01:22:27 <Luke-Jr> at least being able to is an improvement
188 2013-08-11 03:44:38 <Luke-Jr> btw, in case anyone was wondering, git fails almost as bad as bitcoin when its repositories get corrupt, and after a few GB that seems to happen pretty often :\\
189 2013-08-11 05:49:26 <random_cat> what os/distro, luke-jr?
190 2013-08-11 05:49:44 <Luke-Jr> random_cat: Gentoo
191 2013-08-11 05:49:58 <Luke-Jr> not that it matters O.o
192 2013-08-11 05:52:10 <random_cat> amd64?
193 2013-08-11 05:52:25 <Luke-Jr> x86
194 2013-08-11 05:53:30 <Luke-Jr> my shell script that runs git fsck in a loop and scp-s corrupt/missing objects has been running for like a week, because git fsck is sloooooooow
195 2013-08-11 05:53:53 <sipa> heh
196 2013-08-11 05:54:36 <Luke-Jr> I should probably set up a cron job to do it :/
197 2013-08-11 05:54:46 <Luke-Jr> it's got a year's worth of corruption to deal with
198 2013-08-11 05:55:05 <Luke-Jr> since that's how long since I last gc'd
199 2013-08-11 05:55:10 <sipa> wow
200 2013-08-11 05:56:49 <petertodd> Luke-Jr: you ever run memtest86 on that machine?
201 2013-08-11 05:59:18 <Luke-Jr> petertodd: probably
202 2013-08-11 05:59:39 <Luke-Jr> it crashes occasionally, I'd hope it's related to those times
203 2013-08-11 05:59:47 <Luke-Jr> and the git repo receives a push about every minute
204 2013-08-11 06:00:04 <petertodd> sounds about right - I've never seen git get corrupted on working hardware
205 2013-08-11 06:00:23 <petertodd> had to replace some ram sticks on my box recently because they were bad
206 2013-08-11 06:00:36 <petertodd> noticed the same corruption issues with git
207 2013-08-11 06:01:57 <Luke-Jr> hmm
208 2013-08-11 06:02:03 <Luke-Jr> that's odd. the git repo is only 6.7 GB now
209 2013-08-11 06:02:08 <Luke-Jr> I was sure it was bigger
210 2013-08-11 06:02:41 <petertodd> heh, what's the repo for?
211 2013-08-11 06:03:03 <Luke-Jr> my maildir
212 2013-08-11 06:03:10 <Luke-Jr> yeah, it was 65 GB when I started trying to fix it
213 2013-08-11 06:03:18 <Luke-Jr> maybe it's packing as it fscks O.o
214 2013-08-11 06:03:32 <petertodd> ah, maybe you screwed that up somewhere...
215 2013-08-11 06:03:48 <Luke-Jr> nah, 6.7 GB sounds about normal for the post-gc size
216 2013-08-11 06:03:57 <Luke-Jr> it's crazy how much compression helps git
217 2013-08-11 06:04:06 <petertodd> heh, git annex is even better
218 2013-08-11 06:05:26 <Luke-Jr> petertodd: new?
219 2013-08-11 06:05:47 <petertodd> ?
220 2013-08-11 06:07:49 <Luke-Jr> hmm, separate from git
221 2013-08-11 06:07:59 <petertodd> kinda, built into git
222 2013-08-11 06:08:08 <petertodd> http://git-annex.branchable.com/
223 2013-08-11 06:08:13 <gmaxwell> I wish git had xz compression, alas.
224 2013-08-11 06:08:16 <petertodd> but yeah, it's an addon
225 2013-08-11 06:12:00 <warren> phantomcircuit: how small are the txo's in the problematic wallet? If you apply litecoin's mininput patch then rescan, it will just ignore the useless dust and make the wallet usable again.
226 2013-08-11 06:13:02 <warren> phantomcircuit: https://github.com/litecoin-project/litecoin/commit/2db43142bc9d4febd7946488489fd3fa0e1590f2 that might even work as-is
227 2013-08-11 06:13:26 <warren> phantomcircuit: set the threshold to just above the size of the dust
228 2013-08-11 06:14:45 <sipa> that sounds like a sure way to blow up the UTXO set...
229 2013-08-11 06:15:09 <warren> sipa: no, it only ignores them from input selection
230 2013-08-11 06:15:14 <warren> they're still spendable
231 2013-08-11 06:15:57 <gmaxwell> not pratically so.
232 2013-08-11 06:16:25 <gmaxwell> you should at least couple that with a patch to broadcast out ANYONE_CAN_PAY|NONE transactions with those dust bits so other people can collect them in big grooming transactions.
233 2013-08-11 06:18:00 <Luke-Jr> petertodd: something tells me this won't work as a rootfs thing, let alone as a maildir store :\\
234 2013-08-11 06:18:28 <warren> -minput parameter lets users set it smaller all the way to 1 satoshi if they want to combine inputs, but we have very few coins that small due to the multiplicative per-dust fee
235 2013-08-11 06:19:11 <petertodd> Luke-Jr: ? what exactly are you doing there? I use git annex on my mail myself.
236 2013-08-11 06:19:23 <warren> only a few wallets hold the ~10M 1-satoshi attacks, and we plan on just declaring that unspendable in a future 95% miner vote fork in order to shrink the UTXO set to almost nothing.
237 2013-08-11 06:19:34 <Luke-Jr> petertodd: on a mail server?
238 2013-08-11 06:19:42 <petertodd> Luke-Jr: yup
239 2013-08-11 06:19:56 <Luke-Jr> petertodd: if git annex makes everything into symlinks, won't that confuse procmail and/or courier-imapd?
240 2013-08-11 06:20:13 <petertodd> Luke-Jr: doesn't seem to bother it, and there is a non-symlink mode in newer git-annex anyway
241 2013-08-11 06:20:36 <Luke-Jr> oh
242 2013-08-11 06:21:36 <warren> gmaxwell: coblee did consider the ANYONE_CAN_PAY solution, but I think sipa/petertodd came up with the miner vote unspendable solution
243 2013-08-11 06:22:06 <gmaxwell> that doesn't help you on going. and uh... is .. miners taking away people's outputs politically viable?
244 2013-08-11 06:22:22 <warren> Yes. Almost nobody has these outputs.
245 2013-08-11 06:22:24 <petertodd> warren: ...and for the record then I pointed out that the UTXO set isn't in memory, so it could be a lot of fuss over nothing.
246 2013-08-11 06:22:34 <warren> petertodd: that's fine.
247 2013-08-11 06:24:09 <warren> gmaxwell: the ANYONE_CAN_PAY solution would mean several hundred megabytes of blockchain growth in order to reincorporate 0.1 LTC of value back into circulation. Probably most of those wallets were discarded, or owned by coblee and others who don't care about it anyway.
248 2013-08-11 06:24:44 <gmaxwell> warren: okay, still doesn't help you going forward.
249 2013-08-11 06:24:53 <warren> shrug, doesn't harm either.
250 2013-08-11 06:25:14 <petertodd> Sets a precident that you will consider destroying outputs - I'd call that rather harmful.
251 2013-08-11 06:25:39 <warren> It's a proposal in the public right now. Not a priority proposal.
252 2013-08-11 06:26:18 <petertodd> Keep it in mind anyway... I mean, sure I'd love to see an alt-coin try it out, just to see what the process looked like, but I wouldn't want to see a coin I was heavily invested in do it.
253 2013-08-11 06:26:22 <gmaxwell> Just saying, regardless of what you do there, having stuff to do ANYONE_CAN_PAY|NONE would probably be good to go along with the non-spendable dust.
254 2013-08-11 06:28:11 <warren> If you care, respond to the proposal and suggest that. Nobody in the public seems to care.
255 2013-08-11 06:28:20 <petertodd> gmaxwell: It's interesting how with OP_RETURN/anyone-can-spend outputs as standard you could have a mechanism where you just broadcast such tx's and people have code watching for them and grabbing them.
256 2013-08-11 06:28:37 <petertodd> gmaxwell: Useful against deanonymization dust,.
257 2013-08-11 06:28:49 <Luke-Jr> petertodd: it's too bad ext4 didn't add a copy-on-write hardlink
258 2013-08-11 06:29:29 <petertodd> Luke-Jr: heh, everyone says such things, but they have ugly security/quotat accounting problems in some cases
259 2013-08-11 06:30:23 <Luke-Jr> meh, problems with obvious solutions
260 2013-08-11 06:30:48 <gmaxwell> petertodd: right thats why I was talking about this the other day, using it to give away deanonymization dust.
261 2013-08-11 06:31:04 <gmaxwell> which would hopefully end the deanonmization attacks.
262 2013-08-11 06:31:09 <gmaxwell> (well dust based ones)
263 2013-08-11 06:31:32 <petertodd> gmaxwell: Oh, another fun one would be to have a threshold where any change less than a certain amount would be sent to a random address you pick from a recently observed tx that wasn't yours.
264 2013-08-11 06:31:43 <gmaxwell> just have some setting ("give away all payments less than [0.00001] BTC") and it produces a ANYONE_CAN_PAY|NONE signature for any of those and broadcasts it.
265 2013-08-11 06:31:54 <warren> Would that require child pays for 0-conf parent?
266 2013-08-11 06:32:20 <gmaxwell> warren: why would it? for ANYONE_CAN_PAY|NONE you'd teach miners to automatically merge and steal those outputs.
267 2013-08-11 06:32:41 <gmaxwell> e.g. you'c collect up all the ANYONE_CAN_PAY|NONEs you see and make a single OP_RETURN transaction and take them all as fees.
268 2013-08-11 06:32:47 <petertodd> warren: Make the scriptSig have zero value and be an empty OP_RETURN
269 2013-08-11 06:33:09 <warren> oh... that's quite nice.
270 2013-08-11 06:33:34 <gmaxwell> with some not very complicated code you'd order the ANYONE_CAN_PAY|NONE by size, and the mining code would tell you how much room is left in the block.. and you'd just produce the largest sweeping txn you have room for.
271 2013-08-11 06:34:12 <warren> miners would need to decide if that's worth the extra orphan risk?
272 2013-08-11 06:34:18 <warren> bigger block
273 2013-08-11 06:34:28 <gmaxwell> yea, thats up to them, indeed.
274 2013-08-11 06:34:43 <petertodd> warren: mining code already isn't written well with regard to that: you really should be computing orphan risk on a per Tx bases based on fees
275 2013-08-11 06:34:49 <petertodd> fees+subsidy in the block already
276 2013-08-11 06:35:01 <warren> indeed
277 2013-08-11 06:35:09 <warren> I wonder if some pools already did that.
278 2013-08-11 06:35:18 <petertodd> warren: I set my p2pool node to do no free tx's at all and with a minfee of 0.001/kb myself along those lines.
279 2013-08-11 06:35:36 <petertodd> warren: ASICminer is kinda like that apparently - they output fairly small blocks.
280 2013-08-11 06:36:14 <warren> petertodd: isn't orphan risk not a huge concern with p2pool due to the tx pre-forwarding?
281 2013-08-11 06:36:36 <warren> If other pools were smart, they'd have their own huge network of pre-forwarding nodes everywhere to do the same.
282 2013-08-11 06:36:38 <petertodd> warren: less of a concern, but it's still not zero
283 2013-08-11 06:36:52 <gmaxwell> more of a concern for p2pool is that big mempools make getblocktemplate slow.
284 2013-08-11 06:36:58 <warren> ahh
285 2013-08-11 06:37:10 <gmaxwell> p2pool has basically zero orphans. There was one a week ago, I think it was the first one in three months.
286 2013-08-11 06:37:12 <petertodd> gmaxwell: although with the 30s share time that's not as much of an issue
287 2013-08-11 06:37:51 <petertodd> gmaxwell: I also accept non-std tx's, which pose an orphan risk again to the pool, so the high minfee helps mitigate that
288 2013-08-11 09:10:05 <JyZyXEL> if you changed the blockchain from 10 minute targets to 5 minute targets, would that mean you would now need to wait for 12 confirmations instead of 6 to get the same security?
289 2013-08-11 09:11:08 <gmaxwell> JyZyXEL: against some threat patterns yes, potentally more depending on network characteristics, against some threat patterns somewhat less though also highly subject to network characteristics.
290 2013-08-11 09:15:39 <michagogo> Will a node relay a block that it gets that's an orphan from a couple blocks back, or will it only relay what it considers the best change?
291 2013-08-11 09:15:54 <michagogo> (erm, not sure "orphan" is the right word here)
292 2013-08-11 09:16:02 <gmaxwell> michagogo: it will only relay what it considers the best chain.
293 2013-08-11 09:16:29 <michagogo> Hmm.
294 2013-08-11 09:17:27 <JyZyXEL> the whitepaper says if the attacker trying to generate an alternate blockchain is 6 blocks behind the probability of him succeeding is 0.0002428, would that hold true for both 10 minute and 5 minute targeting difficulty?
295 2013-08-11 09:17:31 <gmaxwell> JyZyXEL: basically, against attacks that deal with pure computation bulk (like someone buying a large burst of computing power to finny or reorg a bit), what matters is sheer computation (and its costs) and not block times.
296 2013-08-11 09:18:39 <gmaxwell> For attacks which instead redirect existing hashpower and hope to get ahead by chance, then count matters more, but it's offset by convergence dillution, which generally works in the favor of large attackers.
297 2013-08-11 09:20:03 <gmaxwell> JyZyXEL: for a simple thought expirement, imagine the network with one nanosecond block times. Blocks would happen far far faster than they could be communicated between nodes, and all the nodes would spilt off into their own networks mining in isolation, every once in a while you'd finally see a peer a bit ahead and have a huge reorg.
298 2013-08-11 09:20:27 <gmaxwell> An attacker which isn't split into a bunch of isolated pieces would have an easy time getting ahead of a non-convergent network.
299 2013-08-11 09:21:30 <gmaxwell> So, e.g. against attacks that purchase a concentration of computing power (e.g. outpacing the network but only for a brief moment), you'd want more blocks maybe??? 13 or 14. because of additional dillution.
300 2013-08-11 09:21:48 <gmaxwell> Vs redirecting the existing network, where you might only want 7 or 8.
301 2013-08-11 09:23:17 <gmaxwell> though even 6 seems pretty suspect. There are _single_ mining points of control today with 30-40% of the hashpower. they could reorg 6 with fair probablity.
302 2013-08-11 09:39:03 <JyZyXEL> according to the white paper if your probability of finding the next block is 0.3 and you are 20 blocks behind, the probability of catching up would be 0.0024804, so if you had a 10 second blockchain, you would achieve very good security very fast?
303 2013-08-11 09:40:09 <JyZyXEL> if the only two things that matter are your hashing power versus the networks and the amount of blocks the longest blockchain is ahead of you
304 2013-08-11 09:41:44 <MoALTz> don't forget distribution time. if someone finds a block then that block has to spread through the p2p network
305 2013-08-11 09:46:31 <JyZyXEL> how big is the data that needs to be distributed?
306 2013-08-11 09:47:29 <gmaxwell> JyZyXEL: do you have me on ignore?
307 2013-08-11 09:47:37 <JyZyXEL> no
308 2013-08-11 09:47:44 <gmaxwell> Then why did you ignore everything I just said to you?
309 2013-08-11 09:48:19 <JyZyXEL> im just not getting it
310 2013-08-11 09:48:21 <gmaxwell> The "only two things that matter are your hashing power versus the networks and the amount of blocks the longest blockchain is ahead of you" is only the case when the time between block is very large compared to the network and validation latency.
311 2013-08-11 09:48:56 <gmaxwell> And only the case when the attack model can't purchase small bursts of very large amounts of hashpower at basically operating cost.
312 2013-08-11 10:00:03 <michagogo> Hmm, just thought of something... If you create a transaction, then if you sign it twice the signatures will be different because there's a random number involved, right?
313 2013-08-11 10:00:32 <CodeShark> if that's not the case then you're doing something very wrong :)
314 2013-08-11 10:00:34 <michagogo> If the txid is just the hash of the transaction, signing the same transaction twice will result in two different txids for the same tx.
315 2013-08-11 10:00:42 <CodeShark> correct
316 2013-08-11 10:00:54 <michagogo> Interesting.
317 2013-08-11 10:05:48 <gmaxwell> CodeShark: well, it could be determinstic without being insecure in some implementations.
318 2013-08-11 10:06:19 <CodeShark> gmaxwell: it could - but none that I'm aware of do that
319 2013-08-11 10:06:42 <Vinnie_win> What's up folks
320 2013-08-11 10:08:30 <CodeShark> hi vinnie
321 2013-08-11 10:08:44 <Vinnie_win> I'm working on inlining boost into beast using git-subtree
322 2013-08-11 10:09:07 <Vinnie_win> any bitcoin devs here?
323 2013-08-11 10:09:24 <michagogo> Vinnie_win: Some, yes.
324 2013-08-11 10:09:29 <Vinnie_win> hi
325 2013-08-11 10:09:30 <CodeShark> nah, it's a coincidence this channel is called bitcoin-dev
326 2013-08-11 10:09:35 <Vinnie_win> I mean awake
327 2013-08-11 10:09:58 <CodeShark> do you have a specific question?
328 2013-08-11 10:10:21 <Vinnie_win> Not really
329 2013-08-11 10:13:22 <CodeShark> gmaxwell: by a deterministic implementation I would imagine something like using an HMAC of the transaction hash as the random input
330 2013-08-11 10:15:01 <CodeShark> k = HMAC(secret, hash to sign)
331 2013-08-11 10:21:52 <Vinnie_win> https://gist.github.com/vinniefalco/6204632 uint24
332 2013-08-11 10:22:16 <CodeShark> lol - so much code to represent three bytes :p
333 2013-08-11 10:22:21 <Vinnie_win> haha
334 2013-08-11 10:25:19 <CodeShark> wouldn't a simple typecast and copy be faster for from3RawBytes, with a possible bswap?
335 2013-08-11 10:25:28 <CodeShark> just nitpicking :p
336 2013-08-11 10:25:37 <CodeShark> it's not likely to make any noticeable difference
337 2013-08-11 10:25:37 <Vinnie_win> read my bio on http://opencoin.com
338 2013-08-11 10:25:46 <Vinnie_win> Just hover over my photo, its the last one.
339 2013-08-11 10:51:12 <iddo> CodeShark: yes basically k=hash(privkey,message) is secure, you must hash the privkey because if k is known the the privkey can easily be computed
340 2013-08-11 10:52:19 <iddo> was there ever a discussion on switching to deterministic k in the satoshi client?
341 2013-08-11 10:53:23 <CodeShark> if it's truly secure, why isn't it just part of the ECDSA specification?
342 2013-08-11 10:53:29 <iddo> s/the the/then the
343 2013-08-11 10:54:26 <CodeShark> key generation would still require sufficient entropy for security - but by making k deterministic it would get rid of one more potential implementation security hole
344 2013-08-11 10:54:39 <iddo> it's not related just to ECDSA but to DSA is general, the generic DSA scheme tried to be as generalized as possible i guess
345 2013-08-11 10:55:33 <iddo> even if you use a scheme with deterministic k, the verification will pass if someone else created a signature with a random k
346 2013-08-11 10:55:36 <CodeShark> yeah
347 2013-08-11 10:55:39 <CodeShark> I was just going to say
348 2013-08-11 10:55:42 <CodeShark> there's no way to verify
349 2013-08-11 10:55:59 <CodeShark> so it cannot really be enforced on the receiving end
350 2013-08-11 10:56:09 <Vinnie_win> I'm tired as hell
351 2013-08-11 10:56:27 <CodeShark> go to sleep :)
352 2013-08-11 10:56:52 <iddo> in fact i trying to look for use cases where randomized signatures are helpful
353 2013-08-11 10:57:06 <iddo> couldn't find any...
354 2013-08-11 10:57:46 <iddo> (unlike randomized encryption, where semantic security is crucial)
355 2013-08-11 10:58:00 <CodeShark> right - in this case the message is plaintext
356 2013-08-11 10:58:13 <CodeShark> so even if the signature differs, anyone can tell it's the same thing being signed
357 2013-08-11 10:59:00 <iddo> but i still wonder if randomized signatures can be useful for something
358 2013-08-11 11:01:43 <iddo> gmaxwell: sipa: was there ever a discussion on switching to deterministic k in the satoshi client?
359 2013-08-11 11:01:49 <iddo> maybe they will answer later:)
360 2013-08-11 11:12:18 <gmaxwell> iddo: no, though there is no particular need to. Our K selection is currently busted RNG proof in any case.
361 2013-08-11 11:15:09 <michagogo> Hmm. In hindsight, I should have included a fee in https://blockchain.info/tx/e9d64a4737fa2070649e240f7c26185b0907011a20f843ae16239c6353d8ec70
362 2013-08-11 11:15:19 <michagogo> Well, at least it got relayed
363 2013-08-11 11:16:02 <iddo> gmaxwell: what happens if someone tries to run the satoshi client on a device that doesn't have enough entropy?
364 2013-08-11 11:18:10 <michagogo> The question is, whether it'll actually get mined at some point :-;
365 2013-08-11 11:18:11 <michagogo> :-/
366 2013-08-11 11:21:40 <iddo> gmaxwell: out of curiosity, do you know what randomized signatures could be useful for?
367 2013-08-11 11:23:34 <gmaxwell> iddo: nothing happens. our K values are something like H(message||privkey||random)
368 2013-08-11 11:23:53 <gmaxwell> (I don't recal the exact behavior of openssl but I recall that its something like that)
369 2013-08-11 11:24:49 <iddo> ahh good, so in the saotshi client it's secure even if no randomness is available
370 2013-08-11 11:25:16 <gmaxwell> iddo: I don't have any good argument against making them determinstic either, other than some psycho break in the hash function which would also render everything else insecure too)
371 2013-08-11 11:26:47 <CodeShark> we still would have to assume that signatures from other nodes could be random
372 2013-08-11 11:26:59 <iddo> yes in terms of security the most conservative option is indeed H(message||privkey||random)
373 2013-08-11 11:27:20 <sipa> gmaxwell: nah, it's just random()
374 2013-08-11 11:27:32 <iddo> oh
375 2013-08-11 11:27:35 <sipa> gmaxwell: openssl very recently got a patch that allows H(message||privkey||random)
376 2013-08-11 11:27:39 <michagogo> Hmm. Has transaction e9d64a4737fa2070649e240f7c26185b0907011a20f843ae16239c6353d8ec70 reached the nodes over by you guys?
377 2013-08-11 11:27:44 <sipa> but i don't think it's even in any released version
378 2013-08-11 11:28:06 <michagogo> (and specifically, those of you who don't connect to 173.242.112.53?)
379 2013-08-11 11:28:36 <iddo> i'm still interested to know if anyone can think of use cases where randomized signatures are actually helpful... i couldn't come up with anything
380 2013-08-11 11:29:46 <iddo> i think that other famous software use deterministic k, for example PGP
381 2013-08-11 11:30:18 <gmaxwell> sipa: hm! I know I looked at this, because it contributed to the openbsd security advisory I commented on. But perhaps I was just looking at a non-released version.
382 2013-08-11 11:31:06 <Diablo-D3> >openbsd security advisory
383 2013-08-11 11:31:09 <Diablo-D3> notthisshitagain.jpg
384 2013-08-11 11:31:22 <gmaxwell> michagogo: I have it here on a tor-only node.
385 2013-08-11 11:31:31 <michagogo> Okay, that's a good sign at least.
386 2013-08-11 11:31:34 <michagogo> Thanks, gmaxwell
387 2013-08-11 11:31:40 <michagogo> ACTION hopes it gets mined
388 2013-08-11 11:32:20 <michagogo> I made it with createrawtransaction to consume 4 dust outputs, but forgot to factor in a fee
389 2013-08-11 11:32:48 <michagogo> (I guess there are nodes that connect both to tor and to mainnet?)
390 2013-08-11 11:33:09 <gmaxwell> 4 dust outputs shouldn't have been a problem.
391 2013-08-11 11:33:15 <nsh> gmaxwell, what obsd advisory was this? on openssl on a bad entropy?
392 2013-08-11 11:33:22 <iddo> i asked a person who wrote a paper breaking the privkey of routers that use supposedly random k without enough entropy, etc.
393 2013-08-11 11:33:23 <michagogo> s/mainnet/ipv4net/
394 2013-08-11 11:33:43 <gmaxwell> nsh: yep.
395 2013-08-11 11:33:47 <nsh> k
396 2013-08-11 11:33:57 <michagogo> gmaxwell: I thought a transaction isn't standard if it uses too much dust or something?
397 2013-08-11 11:34:06 <gmaxwell> michagogo: no, using dust isn't a problem.
398 2013-08-11 11:34:10 <michagogo> Oh, wait
399 2013-08-11 11:34:14 <michagogo> ACTION facepalms
400 2013-08-11 11:34:17 <sipa> using dust should be encouraged!
401 2013-08-11 11:34:25 <michagogo> Of course it's not a problem, it's a *good* thing
402 2013-08-11 11:34:27 <gmaxwell> yep. Using dust is good!
403 2013-08-11 11:34:28 <michagogo> Right.
404 2013-08-11 11:34:30 <michagogo> lol
405 2013-08-11 11:34:35 <iddo> the advice was to use deterministic k, no one appears to know how random k can be useful
406 2013-08-11 11:34:41 <gmaxwell> yep. don't worry in the discussions a lot of people kept confusing it.
407 2013-08-11 11:34:48 <michagogo> I guess it's just a matter of waiting up to a day or two :-/
408 2013-08-11 11:36:05 <gmaxwell> michagogo: are you going to starve waiting for that 0.01 btc to go through? :P
409 2013-08-11 11:36:11 <michagogo> Nah, lol
410 2013-08-11 15:50:58 <Goonie> Important update of Bitcoin Wallet available: https://bitcointalk.org/index.php?topic=271846.msg2911506#msg2911506
411 2013-08-11 15:53:41 <michagogo> Clarification: This is the Android app.
412 2013-08-11 15:54:17 <Goonie> Ah yes, sorry. Bitcoin Wallet for Android.
413 2013-08-11 15:55:04 <michagogo> Goonie: Hmm, maybe backups *should* include the old keys, marked for sweeping
414 2013-08-11 15:56:28 <Tril> Goonie: I had a 0 balance but showing an internal tx anyways
415 2013-08-11 15:56:37 <Tril> while rescanning blocks..
416 2013-08-11 15:56:40 <Goonie> michagogo: I thought about something like this, but it will need much more time. The backup format is kind of locked.
417 2013-08-11 15:57:17 <Goonie> Tril: what's your precision? Can you set it to 8 for now?
418 2013-08-11 15:57:20 <michagogo> Goonie: Well, why not tweak it, while maintaining backwards compatibility?
419 2013-08-11 15:57:39 <Goonie> michagogo: possible, but needs time
420 2013-08-11 15:57:40 <Tril> Goonie: yes, 8
421 2013-08-11 15:57:42 <michagogo> (assuming that anything from an old backup should be flagged for sweeping)
422 2013-08-11 15:58:03 <Goonie> michagogo: currently there are no flags like this, it would need to be added to bitcoinj
423 2013-08-11 15:58:15 <Tril> Goonie: I think it's trying to send internal tx for coins I already spent since it's not caught up
424 2013-08-11 15:58:17 <michagogo> Ah, the backup format comes from the backend?
425 2013-08-11 15:58:33 <sipa> the wallet format does
426 2013-08-11 15:58:36 <TD> no. bitcoinj doesn't have any kind of backup format separate from the wallet
427 2013-08-11 15:58:38 <Goonie> Tril: did you replay manually?
428 2013-08-11 15:58:38 <sipa> the backup format doesn't
429 2013-08-11 15:58:46 <TD> i think it'd just be better to backup wallet files themselves, tbh
430 2013-08-11 15:58:47 <Tril> Goonie: yup. testing your beta.
431 2013-08-11 15:58:50 <TD> then we wouldn't have these issues
432 2013-08-11 15:59:12 <sipa> well, wallets aren't compatible between software
433 2013-08-11 15:59:17 <sipa> backup formats ideally are
434 2013-08-11 15:59:24 <Goonie> TD: the internal automatic backups would better be wallet files, yes. I files tickets for this long ago.
435 2013-08-11 15:59:45 <TD> you mean against yourself? there's no action on my part required, afaict
436 2013-08-11 15:59:47 <Goonie> TD: the manual backups are better left like they are, with some extension perhaps
437 2013-08-11 15:59:53 <TD> why left ?
438 2013-08-11 16:00:12 <sipa> i like having human-readable backups with a trivial format
439 2013-08-11 16:00:29 <Goonie> Tril: The app should detect that you're replaying and not try to create rotate txns.
440 2013-08-11 16:01:01 <TD> backups are never human readable. they're binary data by definition. all stuffing them into a text file does is limit your expansion options, as we are now finding out
441 2013-08-11 16:01:18 <TD> bcj wallets are protocol buffers, so they're ideal for adding extra data as we have done now.
442 2013-08-11 16:01:41 <gwillen> http://bitcoin.org/en/alert/2013-08-11-android
443 2013-08-11 16:01:47 <gwillen> ^ does this mean we now know for sure it's android's fault?
444 2013-08-11 16:01:50 <Goonie> TD: its theoretical. Currently bitcoinj is not handling backups. Lets concentrate on real world problems for now.
445 2013-08-11 16:02:01 <Tril> Goonie: well it's showing internal TX in the history intermittently but they're turning red and then disappearing. No idea if it is really sending
446 2013-08-11 16:02:05 <TD> gwillen: yeah
447 2013-08-11 16:02:07 <michagogo> gwillen: If that message is correct, yes.
448 2013-08-11 16:02:48 <gwillen> TD: do we know under what circumstances it happens? (I was conjecturing yesterday that it might be after a crash which fails to write out a new seed, followed by a reboot)
449 2013-08-11 16:02:50 <Tril> Goonie: PM me if you want
450 2013-08-11 16:03:03 <TD> i know some details which are not public at the moment. sorry.
451 2013-08-11 16:03:07 <gwillen> k
452 2013-08-11 16:03:33 <michagogo> What changed now to fix the problem?
453 2013-08-11 16:04:28 <TD> the apps read directly from /dev/urandom
454 2013-08-11 16:04:35 <Goonie> Tril: I think I know what happens. The rotate is not disabled fast enough if you initiate the replay (race). Damn, should have tested this more.
455 2013-08-11 16:05:10 <Goonie> Tril: It will create a spend that will be overridden by a tx coming from a block during the replay.
456 2013-08-11 16:05:28 <michagogo> TD: What did they do before?
457 2013-08-11 16:05:36 <Goonie> Tril: But aside the double spend, it should still work like expected.
458 2013-08-11 16:05:46 <TD> used the java SecureRandom class
459 2013-08-11 16:05:57 <TD> which is how you're meant to obtain cryptographic key material in java-land
460 2013-08-11 16:06:14 <Tril> Goonie: is this version supposed to sweep all inbound TX to insecure addresses?
461 2013-08-11 16:06:42 <Goonie> Tril: yes, as soon as they're confirmed
462 2013-08-11 16:06:53 <TD> Goonie: oops. should be an easy fix though i guess?
463 2013-08-11 16:07:51 <Tril> Goonie: ok. It's not sweeping mined coins. (again, already spent but just FYI)
464 2013-08-11 16:08:09 <Tril> probably fine.
465 2013-08-11 16:08:15 <sipa> if they're already spent, how can they be sweeped?
466 2013-08-11 16:08:51 <Tril> sipa: I did did a manual blockchain replay so it's trying to sweep them.
467 2013-08-11 16:08:56 <Goonie> Tril: I think you won't see a sweep until your replay is finished. And even then it does not trigger the sweep instantly.
468 2013-08-11 16:09:11 <Goonie> TD: already fixed (-:
469 2013-08-11 16:09:22 <Tril> nope, one sweep per TX shortly after it is confirmed.
470 2013-08-11 16:09:56 <Goonie> Tril: How did you trigger the replay? Has your wallet been up to date before the replay?
471 2013-08-11 16:10:24 <Tril> Goonie: preferences, clicked reset blockchain. not sure if it was up-to-date
472 2013-08-11 16:10:35 <Goonie> Tril: Coins mined to your insecure pubkeys should also be swept of course
473 2013-08-11 16:11:46 <Goonie> Tril: If it wasn't up to date before, it cannot detect that you're replaying. This can only happen if you restore your wallet from a backup. Is that the case?
474 2013-08-11 16:12:30 <Tril> Goonie: might've been days/weeks out of date
475 2013-08-11 16:12:41 <Tril> I didn't restore
476 2013-08-11 16:12:51 <Tril> just didn't run the app for a while
477 2013-08-11 16:13:27 <TD> Goonie: you could check the chain head block timestamp before doing the replay
478 2013-08-11 16:13:47 <Goonie> Tril: Yeah but that should not matter, because during that time you could not have created txns. Anyway, I will do some testing on my devices and see if I can reproduce your issue.
479 2013-08-11 16:14:46 <Goonie> TD: In the restore case, the app is empty (e.g. just installed). So there is nothing I can check against. I'd need to save the "high water mark" to the backup, that would help.
480 2013-08-11 16:16:01 <TD> the phones current clock
481 2013-08-11 16:17:46 <Goonie> Hmm ok that might be an idea for the restore case. Will investigate into it later.
482 2013-08-11 16:19:25 <Tril> Goonies I have another issue now with this app, may I PM you?
483 2013-08-11 16:20:02 <Goonie> Tril: ok I can reproduce your issue, even with the fix I just wrote
484 2013-08-11 16:20:08 <Goonie> Tril: sure you can PM me
485 2013-08-11 16:29:13 <Zoop_> http://www.theregister.co.uk/2013/08/09/snowden_nsa_to_sack_90_per_cent_sysadmins_keith_alexander/
486 2013-08-11 16:29:25 <Zoop_> nsa just went full paranoid
487 2013-08-11 16:30:10 <TD> i'm not even sure snowden was really a "sysadmin" as they claim. i saw a post that argued quite persuasively he was almost certainly an offensive hacker
488 2013-08-11 16:30:42 <TD> but then if they're gonna fire sysadmins - perhaps he really was
489 2013-08-11 16:32:03 <sipa> TD: you mean he was hired as a hacker?
490 2013-08-11 16:32:56 <iwilcox> Whatever the problem over the Snowden leaks was, if you're the NSA and you *know* you're doing it for the best, it wasn't what you were doing that was the problem. Therefore blame must fall somewhere else.
491 2013-08-11 16:33:04 <TD> mybe
492 2013-08-11 16:33:11 <TD> he used to work for the CIA remember
493 2013-08-11 16:33:22 <TD> and he was capable of pulling in 200k per yea
494 2013-08-11 16:33:30 <TD> that's a hell of a big salary for a sysadmin
495 2013-08-11 16:33:47 <TD> but it's complicated because he moved jobs once he began planning to leak, specifically to get access to certain material
496 2013-08-11 17:27:32 <Zoop_> http://bitcoin.org/en/alert/2013-08-11-android
497 2013-08-11 17:27:35 <Zoop_> hmm
498 2013-08-11 17:28:32 <michagogo> Zoop_: If you use Android Wallet, see https://bitcointalk.org/index.php?topic=271846.msg2911506
499 2013-08-11 17:28:49 <Zoop_> i don't
500 2013-08-11 18:02:15 <DBordello> Is there a list of comprimised addresses somewhere?
501 2013-08-11 18:02:44 <iwilcox> https://gist.github.com/anonymous/6204930
502 2013-08-11 18:03:07 <DBordello> Perfect, thanks
503 2013-08-11 18:03:08 <iwilcox> No guarantees that it's exhaustive.
504 2013-08-11 18:03:59 <DBordello> hmmm, that makes it less useful
505 2013-08-11 18:06:52 <iwilcox> I mean I'm not saying it is, and the anonymous author doesn't say.
506 2013-08-11 18:10:06 <iwilcox> My understanding, not a recommendation, is that sending coins from your Android wallet to an address generated by a desktop wallet should probably be safe enough. That's what I did anyway, in case my app address has a reversible key and isn't listed.
507 2013-08-11 18:10:36 <iwilcox> s/sending coins/sending all coins/
508 2013-08-11 18:10:46 <gwillen> yes, the 'all' is important
509 2013-08-11 18:10:54 <gwillen> if you send only some coins, the others can be made vulnerable
510 2013-08-11 18:13:22 <michagogo> Right -- or, if you use Android Wallet, install the fixed version
511 2013-08-11 18:13:53 <michagogo> The fixed version will also automatically sweep to a new address
512 2013-08-11 18:13:55 <michagogo> [2013-08-11 20:45:17] <Goonie> Important update of Bitcoin Wallet available: https://bitcointalk.org/index.php?topic=271846.msg2911506#msg2911506
513 2013-08-11 18:14:46 <iwilcox> Yeah, I didn't go that route simply because I don't know Goonie ;)
514 2013-08-11 18:15:21 <Goonie> iwilcox: I'm Andreas Schildbach, the main author of Bitcoin Wallet for Android.
515 2013-08-11 18:16:35 <iwilcox> Ah, not a handle I knew. No offence intended.
516 2013-08-11 18:21:15 <sipa> but anyone can say that!
517 2013-08-11 18:25:30 <iwilcox> I didn't rush off to install the app the moment he said it. :) I'll just keep coins off the wallet til an update comes through the normal channels.
518 2013-08-11 18:25:47 <sipa> sounds safe
519 2013-08-11 18:27:16 <iwilcox> Still haven't updated my phone with that patch to fix the .apk package signing bug, anyway ??? really must
520 2013-08-11 18:30:28 <phantomcircuit> TD, instead of using /dev/urandom, wouldn't it have been better to switch to the strategy bitcoind uses which is to use the sha256 of tx data plus some randomness
521 2013-08-11 18:30:49 <TD> hmm? AFAIK bitcoind just uses openssl
522 2013-08-11 18:31:26 <TD> longer term the right approach is to implement rfc 6967. however in our case, it would not make any difference. the keys would still need to all change.
523 2013-08-11 18:38:13 <iddo> why not use deterministic signatures? library like bitcoinj might get used on devices that don't have good source of entropy
524 2013-08-11 18:38:41 <iddo> we discussed it in this channel a few hours ago, no one is aware of reasons why randomized signatures are useful for anything
525 2013-08-11 18:40:12 <sipa> iddo: with openssl, it's not generally possible to change how the k signing nonce is obtained
526 2013-08-11 18:40:23 <sipa> phantomcircuit: bitcoind just uses openssl
527 2013-08-11 18:41:16 <iddo> sipa: but can you use the openssl patch that you mentioned?
528 2013-08-11 18:41:38 <sipa> in libsecp256k1, all randomness is left to the caller (mostly to reduce dependencies), so there it would be possible to construct it from a hash of message, secret, and potentially extra randomness
529 2013-08-11 18:41:53 <sipa> iddo: if you build your own, sure
530 2013-08-11 18:42:30 <sipa> but that also means losing the benefit of os-supploed security updates
531 2013-08-11 18:42:46 <sipa> (which in our case can be a risk too)
532 2013-08-11 18:42:47 <EagleTM> I hope Dual_EC_DRBG isn't used...
533 2013-08-11 18:45:13 <iddo> sipa: what's needed to get that patch pushed to openssl release branch ?
534 2013-08-11 18:45:29 <iddo> it'd be good if the official bitcoin binaries would use it
535 2013-08-11 18:45:36 <sipa> iddo: it is
536 2013-08-11 18:45:45 <iddo> oh
537 2013-08-11 18:45:54 <sipa> it's just very new
538 2013-08-11 18:46:31 <iddo> so you will use it in the future for the release version of bitcoin?
539 2013-08-11 18:47:22 <sipa> i plan to ditch openssl in bitcoin :p
540 2013-08-11 18:47:34 <iddo> oh
541 2013-08-11 18:47:41 <iddo> really?
542 2013-08-11 18:47:57 <sipa> but since that's not likely going to happen soon, i suppose using that mode is the best way
543 2013-08-11 18:48:09 <sipa> http://rt.openssl.org/m/ticket/show?id=3056
544 2013-08-11 18:48:19 <iddo> ditch openssl in favor of what?
545 2013-08-11 18:48:45 <sipa> well, not entirely, but for EC stuff
546 2013-08-11 18:50:43 <iddo> ok, so you should consider whether you want deterministic or randomized signatures in your customized EC code
547 2013-08-11 18:54:39 <sipa> i don't think there's any disadvantage to using hash(message+privkey+randomness)
548 2013-08-11 18:54:51 <sipa> it's as good as randomnesa, if it is good
549 2013-08-11 18:55:02 <sipa> and it's not worse than deterministic otherwise
550 2013-08-11 18:55:43 <sipa> (not saying there is any problem with deterministic, but as far as i can see, it's certainly not worse)
551 2013-08-11 18:56:58 <iddo> right, it's obviously not worse in terms of security
552 2013-08-11 18:59:19 <iddo> or maybe if being pedantic, it's exponentially-negligible worse when the user signs the same message twice
553 2013-08-11 19:01:36 <iddo> maybe for bitcoind signmessage it would be less confusing for users if they always get the same deterministic signature, but when actually signing transactions they don't notice the signatures
554 2013-08-11 19:05:42 <iddo> when googling i see RFC on deterministic DSA signatures, not sure why this document is so long for saying hash(message+privkey), http://tools.ietf.org/html/draft-pornin-deterministic-dsa-01
555 2013-08-11 19:08:15 <augustl> hey folks. Having problems with "what(): TopUpKeyPool() : writing generated key failed
556 2013-08-11 19:09:08 <augustl> whoops, newline fail.. Anyway, getting that error when I try to unencrypt with "walletpassphrase". The people in #bitcoin sugested I'd ask here
557 2013-08-11 19:11:36 <augustl> I haven't been unencrypting for a long time, apparently that's part of the reason. Any suggestions are very welcome :)
558 2013-08-11 19:17:04 <sipa> anything in db.log?
559 2013-08-11 19:17:12 <augustl> sipa: I'll look that up
560 2013-08-11 19:18:01 <augustl> sipa: yes :)
561 2013-08-11 19:19:05 <augustl> I'll clear the log and try again so I only get the relevant log entries
562 2013-08-11 19:20:26 <augustl> sipa: https://www.refheap.com/17508
563 2013-08-11 19:22:42 <sipa> your wallet wasn't closed correctly, it seems
564 2013-08-11 19:22:52 <sipa> or some other corruption happened
565 2013-08-11 19:23:21 <augustl> any suggestions on how to fix it? Or should I take it back to #bitcoin? :)
566 2013-08-11 19:23:36 <sipa> -salvagewallet will mlst likely repair it, but it needs to rescan the blockchain, and you lose everything except the keys (address book entries, eg)
567 2013-08-11 19:23:48 <augustl> sipa: I see, thanks
568 2013-08-11 19:24:28 <shesek> oh fml :-\\ I thought I was copying a random private key from brainwallet, but ended up importing the correct horse one
569 2013-08-11 19:24:54 <shesek> is there a way to remove a private key from a wallet?
570 2013-08-11 19:25:21 <shesek> or would I have to create a new one and move the private keys manually?
571 2013-08-11 19:25:31 <iwilcox> I did that once, and concluded the easiest solution was to restore from backup.
572 2013-08-11 19:34:37 <sipa> shesek: indeed, restore a backup
573 2013-08-11 19:35:09 <shesek> I'm afraid I don't have one for this wallet
574 2013-08-11 19:35:27 <shesek> (its not my primary wallet)
575 2013-08-11 19:35:44 <shesek> I think I'll just export the private key with pywallet and import them into a new wallet
576 2013-08-11 19:35:53 <sipa> if you run on git head, you can use dumpwallet, remove the offending key, and importwallet it
577 2013-08-11 19:36:51 <sipa> all your coins are assigned to a single address?
578 2013-08-11 19:37:02 <sipa> you're aware of how vhange works?
579 2013-08-11 19:37:05 <sipa> change
580 2013-08-11 19:37:07 <shesek> nope, multiple ones
581 2013-08-11 19:37:11 <shesek> yeah, I am aware
582 2013-08-11 19:38:05 <shesek> if I import them manually with importprivkey, can I somehow make it not trigger a rescan for each one?
583 2013-08-11 19:44:34 <sipa> yes, put a false behind it
584 2013-08-11 19:44:45 <sipa> rtfm!
585 2013-08-11 19:44:57 <sipa> ./bitcoind help importprivkey
586 2013-08-11 19:46:07 <shesek> yeah, I should have rtfm
587 2013-08-11 19:46:14 <shesek> thanks tho :)
588 2013-08-11 20:28:39 <runeks> Can anyone confirm that this transaction with 5 inputs only has 3 distinct r-values? https://blockchain.info/tx/569af9e1e4d1c6e02b7574ec551d74a2ccaee1f33b4f9b4191a3c5d81aeeb150
589 2013-08-11 20:28:45 <runeks> Looks like the first two inputs and the last two inputs have the same r-value in their signatures.
590 2013-08-11 20:31:46 <Luke-Jr> petertodd: git annex has a ton of deps! :<
591 2013-08-11 20:32:02 <sipa> runeks: looks like it
592 2013-08-11 20:32:43 <Luke-Jr> petertodd: none of which are stable on Gentoo :<
593 2013-08-11 20:33:36 <runeks> sipa: Thanks for confirming. I thought it was only in transactions spaced far apart timewise.
594 2013-08-11 20:34:21 <runeks> sipa: How do you check the r-values, by the way? I'm using some semi-custom Python code, but I'm wondering if there's a simpler way.
595 2013-08-11 20:34:21 <sipa> was this tramsaction created by bitcoin wallet for android?
596 2013-08-11 20:34:49 <sipa> runeks: i've learnt to decode der signatures by now :)
597 2013-08-11 20:34:56 <Luke-Jr> lol
598 2013-08-11 20:35:21 <runeks> sipa: Dunno. It's not mine. I just went through all the addresses from which transactions were sent to this address 1HKywxiL4JziqXrzLKhmB6a74ma6kxbSDj mentioned in this post: https://bitcointalk.org/index.php?topic=251743.0
599 2013-08-11 20:35:31 <sipa> ok
600 2013-08-11 20:35:40 <runeks> sipa: So you just look at the bytes and the numbers pop into your head? :)
601 2013-08-11 20:36:01 <Luke-Jr> runeks: isn't r in the bytes verbatim?
602 2013-08-11 20:36:07 <Luke-Jr> just need to find the position..
603 2013-08-11 20:36:12 <sipa> well there is a 0x02, followed by a length byte, followed by R
604 2013-08-11 20:36:23 <sipa> then 0x02, length byte, S
605 2013-08-11 20:36:43 <sipa> and there's a 0x30 and a total-length byte before that
606 2013-08-11 20:37:18 <sipa> but it's not particularly hard to find a 0x0220 or 0x0221 that marks the start of a number
607 2013-08-11 20:38:08 <runeks> Luke-Jr, sipa: Oh, right. Of course. I can just look on blockchain.info for that.
608 2013-08-11 20:38:31 <runeks> 30450220/30450221 and then the r value
609 2013-08-11 20:38:41 <sipa> yes
610 2013-08-11 20:38:44 <Luke-Jr> ACTION facepalms
611 2013-08-11 20:39:02 <sipa> respectively 32 and 33 bytes of Rrrrr
612 2013-08-11 20:48:22 <phantomcircuit> sipa, lol
613 2013-08-11 20:58:04 <gmaxwell> It is shown that the over-all entropy of the Android PRNG canbe reduced to 64 bits. Beyond this, multiple weaknesses of entropy collectors arerevealed.
614 2013-08-11 20:58:07 <gmaxwell> http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations
615 2013-08-11 20:58:10 <gmaxwell> :-/
616 2013-08-11 20:58:49 <gmaxwell> I'm a little concerned by the android wallet plan as posted, /dev/urandom may be broken on some devices.
617 2013-08-11 20:59:00 <EagleTM> ;( is windows much better? There have been flaws in Windows PRNG as well iirc
618 2013-08-11 20:59:46 <Goonie> gmaxwell: afaik SecureRandom also uses /dev/urandom, so its at least no regression.
619 2013-08-11 20:59:57 <gmaxwell> EagleTM: bitcoin-qt is somewhat armored against insecure system randomness.
620 2013-08-11 21:00:28 <Goonie> gmaxwell: but yes, I'm concerned as well. For example, does QNX (which also runs Android apps) provide /dev/urandom at all?
621 2013-08-11 21:00:34 <EagleTM> gmaxwell: ok that's good.
622 2013-08-11 21:00:45 <gmaxwell> Goonie: it may be a regression in that it generates a new key and sends all funds to it. So by chance your prior ones might have been okay enough, and the new one might not be.
623 2013-08-11 21:00:45 <lianj> gmaxwell: how?
624 2013-08-11 21:01:12 <gmaxwell> lianj: we maintain our own randomness pool and add additional sources of potential entropy into it.
625 2013-08-11 21:02:09 <lianj> last i checked it just took openssl RAND
626 2013-08-11 21:02:10 <Goonie> gmaxwell: it will be same flaky /dev/urandom implementation, unless the user moved keys between devices (which is not supported).
627 2013-08-11 21:02:27 <gmaxwell> lianj: then you didn't look enough, search the codebase for RandAddSeed.
628 2013-08-11 21:02:28 <deego> 27189 <- random, 100% guaranteed!
629 2013-08-11 21:02:57 <EagleTM> it's fairly new code?
630 2013-08-11 21:03:03 <gmaxwell> EagleTM: no, it's satoshi code.
631 2013-08-11 21:03:06 <EagleTM> ah ok
632 2013-08-11 21:03:07 <lianj> gmaxwell: thanks
633 2013-08-11 21:03:14 <gwillen> Goonie: causing people to make more transactions increases the chance of exposure, I think is the issue
634 2013-08-11 21:03:23 <gwillen> Goonie: in the event that the new keys/signatures are no less vulnerable then the old
635 2013-08-11 21:03:27 <gwillen> than*