1 2013-08-12 00:02:37 <jgarzik> yword
2 2013-08-12 00:03:11 <Luke-Jr> ?
3 2013-08-12 00:06:42 <rethaw> keyword
4 2013-08-12 00:08:54 <gmaxwell> keyscore?
5 2013-08-12 00:09:19 <Cusipzzz> XKeyscore?
6 2013-08-12 00:10:24 <jgarzik> whoops
7 2013-08-12 00:10:30 <jgarzik> That should have been "word"
8 2013-08-12 00:10:40 <jgarzik> A prototypical American greeting from the 1990s
9 2013-08-12 00:11:11 <gmaxwell> yo daug. I put a 1990s greeting in your 1990s communications medium.
10 2013-08-12 00:11:13 <jgarzik> So Electrum gets stuck on block 251526, eh?
11 2013-08-12 00:11:20 <gavinandresen> howdy!
12 2013-08-12 00:11:31 <Diablo-D3> gmaxwell: IRC was released in 1989 =P
13 2013-08-12 00:11:55 <gavinandresen> Anybody figured out which transaction in block 251526 is the offender?
14 2013-08-12 00:11:58 <gmaxwell> (citation for jgarzik's comment: https://bitcointalk.org/index.php?topic=271761.new )
15 2013-08-12 00:12:50 <gmaxwell> the smoking gun is that exception, I guess.
16 2013-08-12 00:13:18 <gmaxwell> someone asked me earlier about an odd transaction that I could have seen triggering that, lemme see if it's in my shell history.
17 2013-08-12 00:14:26 <gmaxwell> hm, no. that was 5a5d8c82a9d32ad2bd8674a20b25d06cd9ab7f206115fc7d55cddd5747feccc0 which was the wrong block.
18 2013-08-12 00:16:08 <gavinandresen> Looking at the patch that fixes it: https://github.com/spesmilo/electrum-server/commit/c1d96aba96296bda1e6b792cb3762754613fa3d0 ??? I'm guessing the Electrum server deserializes unspent scriptPubKeys ?
19 2013-08-12 00:16:55 <gavinandresen> ??? and there is an unspendable scriptPubKey in the block???.
20 2013-08-12 00:17:03 <gavinandresen> (but I haven't taken the time to look)
21 2013-08-12 00:18:11 <jgarzik> and as a kernel programmer, this SecureRandom thing makes me want to yell at somebody
22 2013-08-12 00:18:28 <gmaxwell> (for tx in ` bd getblock 00000000000000123fdfd8cc207b3364d2dbdf183a730a8850b25856dea8d255 | grep ' "' |cut -d'"' -f2` ; do bd getrawtransaction $tx 1 ; done | grep asm) | sed -re 's/[0-9a-f]{8,}//g'| sort -n
23 2013-08-12 00:18:32 <jgarzik> SecureRandom is... not secure. One possible fix... use the damn kernel facility that has always been there.
24 2013-08-12 00:18:36 <jgarzik> *facepalm*
25 2013-08-12 00:18:46 <gmaxwell> "asm" : "OP_INVALIDOPCODE",
26 2013-08-12 00:18:46 <gmaxwell> "asm" : "OP_RETURN ",
27 2013-08-12 00:18:57 <gmaxwell> jgarzik: SecureRandom uses the kernel facility, but craps on it.
28 2013-08-12 00:19:10 <gmaxwell> (*maybe)
29 2013-08-12 00:19:15 <gavinandresen> gmaxwell: mmm, I woulda done something like that myself but I'm in the middle of trying to debug chainstate leveldb corruption on this machine....
30 2013-08-12 00:19:51 <gmaxwell> gavinandresen: yea, 8a68c461a2473653fe0add786f0ca6ebb99b257286166dfb00707be24716af3a
31 2013-08-12 00:20:27 <jgarzik> gavinandresen, you too ? BitPay is all-OSX, and a couple colleagues also reported Bitcoin-Qt-on-OSX corruption.
32 2013-08-12 00:20:48 <gavinandresen> jgarzik: yup, me too. There is definitely a bug??? somewhere....
33 2013-08-12 00:20:52 <jgarzik> gavinandresen, as TD(?) guessed, it seems to coincide with sleep/resume while Bitcoin-QT is running.
34 2013-08-12 00:21:08 <gmaxwell> lots and lots of reports on OSX.
35 2013-08-12 00:21:10 <jgarzik> gavinandresen, if not a cause, sleep/resume exacerbates the problem
36 2013-08-12 00:21:24 <gavinandresen> jgarzik: hmm. Not sure this machine ever sleeps, it's an 8-core desktop
37 2013-08-12 00:21:33 <gmaxwell> the OP_RETURN output in that block is bc00cc28c9be4f15cf5fa4b93c79c36aefd5bcc54f54e689017d528333b6fd7b
38 2013-08-12 00:22:16 <jgarzik> gavinandresen, have rotational storage media? are the platters ever spun down?
39 2013-08-12 00:22:34 <gavinandresen> jgarzik: nope, blockchain is stored on an SSD
40 2013-08-12 00:22:55 <jgarzik> gavinandresen, we are all-SSD shop here, and we see it.
41 2013-08-12 00:23:06 <gavinandresen> I did have another corruption (that I've saved) where I was running on a USB-attached spinning disk
42 2013-08-12 00:23:29 <jgarzik> it's worth a tech note or something, IMO, to let people know this is going on
43 2013-08-12 00:23:49 <gavinandresen> agreed. Today would be a bad day to get any attention, though
44 2013-08-12 00:23:53 <jgarzik> thoughts: fiddle with mmap/sync ifdefs and options
45 2013-08-12 00:23:56 <jgarzik> agreed
46 2013-08-12 00:24:28 <gmaxwell> It's gone on so long and been reported so much, I'm not sure that delaying another week to actually get some idea of the cause would be bad. It's good to hear that someone has actual captures of the bad state.
47 2013-08-12 00:25:05 <jgarzik> gut feeling: leveldb and not bitcoin
48 2013-08-12 00:25:09 <gavinandresen> The particular error I'm seeing in this case is: "Corruption: missing start of fragmented record(2)"
49 2013-08-12 00:25:29 <gmaxwell> jgarzik: gavinandresen: have you ever seen the uncorruption behavior that we've had a couple reports of? e.g. after a reboot it just worked?
50 2013-08-12 00:25:51 <gmaxwell> jgarzik: I'd put money on that (or at least leveldb or OS and not bitcoin), but ??? still our problem. :)
51 2013-08-12 00:25:54 <runeks> jgarzik: Would you happen to know why python-bitcoinrpc would leave its connections in a TIME_WAIT state? I'm querying bitcoind for basically all the transactions in the block chain, rapidly, one after another. After a while it chokes with a 'Cannot assign requested address' error and subsequently CannotSendRequest() errors. netstat tells me there are 22812 connections to 127.0.0.1 in the TIME_WAIT state.
52 2013-08-12 00:25:59 <jgarzik> gavinandresen, do you use the OSX disk encryption feature? we do.
53 2013-08-12 00:26:06 <gavinandresen> gmaxwell: I haven't seen it fix itself, but I haven't rebooted yet....
54 2013-08-12 00:26:11 <gavinandresen> jgarzik: no
55 2013-08-12 00:26:35 <jgarzik> gmaxwell, certainly
56 2013-08-12 00:28:23 <jgarzik> (RE still our problem)
57 2013-08-12 00:28:47 <jgarzik> gmaxwell, haven't seen any uncorruption behavior @ BitPay. Only heard of it via #bitcoin-dev discussion
58 2013-08-12 00:28:48 <gavinandresen> ??? lunch time. I'll copy the corrupt chainstate, then reboot after eating and see if the problem magically fixes itself.
59 2013-08-12 00:40:44 <phantomcircuit> gmaxwell, iirc leveldb handles partial records in it's log quite poorly
60 2013-08-12 00:41:07 <phantomcircuit> i would say the journal format is pretty dangerous actually
61 2013-08-12 00:41:46 <phantomcircuit> gavinandresen, jgarzik ^
62 2013-08-12 00:43:12 <toffoo> gavinandresen jgarzik this is the first concrete sign I've seen that the OSX corruption issues may be addressed sometime soon, thanks for your attention!
63 2013-08-12 00:43:45 <toffoo> I've made a bit of noise about it myself, please let me know if there's anything I can do to help find/squash whatever bug it is
64 2013-08-12 00:43:48 <phantomcircuit> toffoo, so far everybody who has reported a problem had already done a -reindex
65 2013-08-12 00:43:52 <phantomcircuit> at least that im aware of
66 2013-08-12 00:43:59 <phantomcircuit> which makes it pretty hard to fix
67 2013-08-12 00:44:02 <toffoo> I downgraded to v0.7.2 long ago
68 2013-08-12 00:44:25 <toffoo> no v0.8.x release worked for more than a few hours for me,
69 2013-08-12 00:44:38 <jgarzik> oh, random disclosure, bought some ASICMINER shares
70 2013-08-12 00:44:46 <toffoo> and I have too much dinero tied up in BTC these days to have my client die on me several times a day
71 2013-08-12 00:45:00 <jgarzik> ridiculously overpriced, but whatever
72 2013-08-12 00:45:47 <toffoo> jgarzik doesn't sound like a bad idea. a -PT or direct? I hope you got some below 3.75 or so!
73 2013-08-12 00:46:07 <jgarzik> direct
74 2013-08-12 00:46:11 <jgarzik> no, ~4, alas
75 2013-08-12 00:46:58 <toffoo> I have plenty (too many) but was thinking of dipping into more when I saw it dip below 4 again
76 2013-08-12 00:57:47 <runeks> I sold my ASICMiner shares and bought some PUT options on btct.co. I think they need to go down in price. Especially with Bitfury coming soon.
77 2013-08-12 00:58:41 <runeks> jgarzik: By the way, would you happen to know why bitcoinrpc doesn't reuse its connections? I can see with Wireshark that it creates a new connection for every request, eventually running out of ports.
78 2013-08-12 01:01:58 <jgarzik> runeks, not offhand, no
79 2013-08-12 01:02:17 <runeks> OK. I'll try to investigate further.
80 2013-08-12 01:25:05 <runeks> jgarzik: I have fixed the problem, but for some strange reason it actually makes it slower... 26 seconds for all the transactions in 10 blocks when reusing the connection vs 10 seconds when not reusing it :\\
81 2013-08-12 03:52:50 <Luke-Jr> hmm, wonderful: BW4A fails to send my coins
82 2013-08-12 03:56:54 <gmaxwell> BW4A?
83 2013-08-12 03:59:58 <Luke-Jr> Goonie_'s client
84 2013-08-12 04:00:10 <Luke-Jr> which also needs a real name
85 2013-08-12 04:00:12 <Luke-Jr> -.-
86 2013-08-12 04:01:05 <warren> Luke-Jr: you just did name it
87 2013-08-12 04:01:31 <gmaxwell> ah, you confused me, BW4A sounded like a pretty random string ... so obviously you couldn't be referring to the bitcoin wallet for android.
88 2013-08-12 04:01:34 <gmaxwell> :P
89 2013-08-12 04:02:25 <gmaxwell> hm. contemplates disabling leveldb mmap on osx.
90 2013-08-12 04:12:27 <runeks> ;;later tell jgarzik I don't know why, but your python-bitcoinrpc is almost 3 times slower than standard jsonrpc. Here's the test code: http://pastebin.com/TYTdmKfA
91 2013-08-12 04:12:28 <gribble> The operation succeeded.
92 2013-08-12 04:13:42 <gmaxwell> runeks: I'd WAG decimal vs float numbers.
93 2013-08-12 04:14:01 <runeks> gmaxwell: What's the point of Decimal() anyway?
94 2013-08-12 04:14:06 <Luke-Jr> runeks: it's not float
95 2013-08-12 04:14:16 <runeks> Luke-Jr: Ok...
96 2013-08-12 04:15:22 <runeks> Luke-Jr: Is that good?
97 2013-08-12 04:15:43 <Luke-Jr> runeks: float is imprecise
98 2013-08-12 04:15:47 <Luke-Jr> you don't want that with money
99 2013-08-12 04:16:39 <runeks> Luke-Jr: Right. Fair point. That's why we use 64 bit integers for money in bitcoin qt along with COIN. Why not use the same with the RPC interface?
100 2013-08-12 04:16:44 <gavinandresen> Bah: https://code.google.com/p/leveldb/issues/detail?id=197
101 2013-08-12 04:17:09 <Luke-Jr> runeks: because nobody considers it a priority to fix RPC nits like that
102 2013-08-12 04:17:19 <runeks> Fair enough.
103 2013-08-12 04:18:18 <runeks> I don't really use it for anything important either. So I'm just gonna use the standard json library. I can always multiply by 1e8 and convert to int.
104 2013-08-12 04:18:25 <gmaxwell> runeks: the rpc is, for all intents and purposes 64 bit integers with some funny formatting.
105 2013-08-12 04:19:13 <runeks> gmaxwell: So it's just a 64 bit int with a decimal point at the 8th position (from the right)?
106 2013-08-12 04:19:38 <gmaxwell> runeks: so long as you're sure it always stays in doubles and never passes through a Float, and don't do any non-trivial manipulations, you won't lose precision.
107 2013-08-12 04:19:47 <gmaxwell> runeks: yes, right, it's even formatted that way (Extra zeros)
108 2013-08-12 04:20:53 <runeks> gmaxwell: I see. Good to know. What about the difficulty? Should I treat that as an integer as well?
109 2013-08-12 04:21:11 <runeks> Looks like it's the same format (8 numbers after the decimal place).
110 2013-08-12 04:21:24 <Luke-Jr> runeks: no, difficulty is inherently floating
111 2013-08-12 04:23:14 <gmaxwell> runeks: difficulty isn't the high preceision representation, it's just a display target, I doubt you can reliably round trip that value.
112 2013-08-12 04:23:37 <Luke-Jr> gmaxwell: we store it as a 24-bit floating point number <.<
113 2013-08-12 04:23:41 <Luke-Jr> I'd think you can
114 2013-08-12 04:24:20 <runeks> Luke-Jr, gmaxwell: I guess the protocol doesn't even check for that floating point number? It just looks at the target and the difficulty is just a more humanly readable figure?
115 2013-08-12 04:25:20 <Luke-Jr> runeks: correct
116 2013-08-12 04:25:34 <gmaxwell> runeks: Whats in the protocol is the bits field, which gets expanded to a target value. There is no floating point in the protocol whatsoever.
117 2013-08-12 04:25:50 <runeks> Right. That explains it.
118 2013-08-12 04:27:33 <Luke-Jr> gmaxwell: bits *is* floating point O.o
119 2013-08-12 04:28:15 <gmaxwell> Luke-Jr: this is conflating multiple uses of the word.
120 2013-08-12 04:28:36 <Luke-Jr> 1-bit sign, 23-bit significand, and 8-bit exponent
121 2013-08-12 04:29:35 <gmaxwell> Yes, and you might as well say that the whole block hash is a 'floating point number'.
122 2013-08-12 04:30:02 <gmaxwell> It's not a system machine float. It's a binary value that gets handled in precise ways according to the protocol..
123 2013-08-12 04:30:42 <gmaxwell> If you go around calling it a float you'll get people thinking its (float) and then making broken implementations.
124 2013-08-12 04:33:24 <Luke-Jr> I'm not sure someone expecting a specific float format just because someone says 'float' should be writing a node
125 2013-08-12 04:35:01 <gmaxwell> maybe, but you don't add anything to bits when you call it float, if calling it float doesn't let people use the code they'd normally use for 'floats' on it. :P
126 2013-08-12 04:36:05 <gmaxwell> Thats why we give names to thinks, you know??? so people know which library code to apply. :)
127 2013-08-12 05:36:50 <fanquake> nice to see some progress on the osx corruption issues :)
128 2013-08-12 05:49:56 <sipa> gavinandresen: great that you found that issue
129 2013-08-12 06:03:21 <sipa> iirc we are also running in paranoid mode
130 2013-08-12 06:10:37 <gavinandresen> sipa: I don't see paranoid_checks being used anywhere...
131 2013-08-12 06:14:19 <sipa> oh, only verify_checksums
132 2013-08-12 06:14:30 <sipa> maybe we should enable paranoid?
133 2013-08-12 06:14:53 <gavinandresen> yes, I'm going to enable paranoid and then reindex (and then run with paranoid)
134 2013-08-12 06:16:29 <sipa> also, the linked issue talks about a race
135 2013-08-12 06:16:50 <sipa> afaik, we only write to chainstate while holding cs_main
136 2013-08-12 06:17:23 <sipa> hmm, but leveldb has its own background write thread
137 2013-08-12 06:17:52 <sipa> also, it talks about corruption in log files... for us, or at least what you observed, was in the manifest file?
138 2013-08-12 06:18:06 <gavinandresen> MANIFEST_nnnn is a log-format-file
139 2013-08-12 06:18:15 <sipa> ok
140 2013-08-12 06:33:56 <Happzz> updating from 0.8.0-beta to 0.8.3, can i just replace the .exe or something?
141 2013-08-12 06:34:19 <Happzz> or there's more to it?
142 2013-08-12 06:42:08 <Luke-Jr> Happzz: why not just upgrade normally?
143 2013-08-12 06:44:14 <Happzz> Luke-Jr i use unusual locations
144 2013-08-12 06:44:22 <Happzz> and i normally don't like using installers
145 2013-08-12 06:44:29 <Happzz> they tend to add crap
146 2013-08-12 06:45:19 <Happzz> i just replaced the bitcoin-qt.exe and bitcoind.exe. seems to work.
147 2013-08-12 06:48:21 <Luke-Jr> Happzz: on Windows, installers are how things get installed. Bitcoin-Qt's won't add crap.
148 2013-08-12 06:48:41 <Luke-Jr> if you really don't like installers, you should probably consider a different OS o.O
149 2013-08-12 06:49:23 <Happzz> ... i just replaced the bitcoin-qt.exe and bitcoind.exe. seems to work.
150 2013-08-12 06:49:25 <TD> good morning
151 2013-08-12 06:49:50 <Luke-Jr> Happzz: "seems to work" and probably does in this case - but what if one of the other files had a security fix, and then you got your coins stolen?
152 2013-08-12 06:49:53 <Happzz> and really, if not the games i play, which usually demand winblows, i'd move to unix a long time ago
153 2013-08-12 06:50:34 <Happzz> Luke-Jr these are the only 2 files....
154 2013-08-12 06:51:00 <sipa> pretty sure that on windows, you really only need those files
155 2013-08-12 06:51:11 <Luke-Jr> oh
156 2013-08-12 06:51:18 <sipa> though that advice won't hold for other programs
157 2013-08-12 06:51:43 <Luke-Jr> *ideally* there would be DLLs too
158 2013-08-12 06:51:52 <Happzz> sipa i have a few bitcoin-qt suggestions that i'm sure aren't that hard to implement:
159 2013-08-12 06:51:53 <Happzz> 1) show the balance of each address in the receive tab
160 2013-08-12 06:52:05 <sipa> ADDRESSES DO NOT HAVE A BALANCE
161 2013-08-12 06:52:08 <Luke-Jr> ^
162 2013-08-12 06:52:16 <Luke-Jr> also, there is no shortage of suggestions
163 2013-08-12 06:52:19 <sipa> there's coin control
164 2013-08-12 06:52:29 <sipa> which will likely allow what you want
165 2013-08-12 06:52:49 <Luke-Jr> if he's talking about address balances, he probably doesn't know what he wants <.<
166 2013-08-12 06:53:00 <sipa> but showing "address balances" without breakig the wallet abstraction entirely, will only confuse people
167 2013-08-12 06:53:17 <Happzz> how so?
168 2013-08-12 06:53:28 <sipa> the wallet functions as a black box
169 2013-08-12 06:53:30 <Luke-Jr> Happzz: because addresses are single-use and don't have balances
170 2013-08-12 06:53:37 <sipa> addresses are entry points into it
171 2013-08-12 06:53:50 <sipa> and coins are managed internally further
172 2013-08-12 06:54:03 <Luke-Jr> Happzz: likely when wumpus gets around to it, the list of receive addresses will go away entirely
173 2013-08-12 06:54:26 <Happzz> so if you send 1 btc to 1whateveraddress, what keys are used to send that coin elsewhere?
174 2013-08-12 06:54:33 <Happzz> not that address'?
175 2013-08-12 06:54:35 <Luke-Jr> Happzz: the wallet.dat file
176 2013-08-12 06:55:01 <sipa> whatever key necessary to prove ownership of the address the input coin previously belonged to
177 2013-08-12 06:55:13 <sipa> but the word address here is confusing
178 2013-08-12 06:55:14 <Happzz> i.e. that address has the coin, no?
179 2013-08-12 06:55:14 <Luke-Jr> Happzz: the meaning of 1whateveraddress disappears as soon as it's sent
180 2013-08-12 06:55:32 <sipa> Happzz: yes, it is not wrong, just not the abstraction the wallet uses
181 2013-08-12 06:55:34 <Happzz> Luke-Jr the meaning is kept as long as the coin is "kept" there
182 2013-08-12 06:55:34 <Luke-Jr> Happzz: the wallet has the coin. the address just told the sender what wallet it goes to.
183 2013-08-12 06:55:49 <Happzz> well, the wallet is a pack of many addresses, right?
184 2013-08-12 06:55:51 <sipa> Happzz: but the wallet moves coins around on its own
185 2013-08-12 06:56:00 <Luke-Jr> Happzz: internally, but that's not something users are exposed to
186 2013-08-12 06:56:06 <Happzz> how can it move coins around without telling the network about it?
187 2013-08-12 06:56:11 <sipa> it does
188 2013-08-12 06:56:26 <sipa> if you send a transaction, change is sent to a new address
189 2013-08-12 06:56:44 <sipa> if tou do not break the abstraction entirely, people will shoot themself in the foot
190 2013-08-12 06:56:47 <Happzz> oh. why won't the change be sent to the same address?
191 2013-08-12 06:56:59 <sipa> because addresses are supposed to be sigle use
192 2013-08-12 06:57:01 <Luke-Jr> Happzz: addresses can only be used a single time
193 2013-08-12 06:57:08 <Happzz> Luke-Jr CAN or SHOULD?
194 2013-08-12 06:57:10 <sipa> for privacy
195 2013-08-12 06:57:10 <sipa> of the entire system
196 2013-08-12 06:57:16 <Happzz> i see.
197 2013-08-12 06:57:20 <Luke-Jr> Happzz: things break subtley if you use an address more than once
198 2013-08-12 06:57:29 <sipa> meh
199 2013-08-12 06:57:30 <Luke-Jr> one person just had 55 BTC stolen because he reused his address
200 2013-08-12 06:57:38 <Happzz> how did that happen
201 2013-08-12 06:57:44 <Luke-Jr> Happzz: a bug in Android
202 2013-08-12 06:57:50 <sipa> that was because of another issue
203 2013-08-12 06:57:52 <Happzz> oh. not a bitcoin issue
204 2013-08-12 06:57:59 <Luke-Jr> but had he been using Bitcoin addresses correctly, he wouldn't have been vulnerable in the same way
205 2013-08-12 06:58:00 <sipa> but indeed, sigle use would have prevented it
206 2013-08-12 06:58:16 <Happzz> so my wallet actually "has" a bunch of addresses that my client won't even show to me?
207 2013-08-12 06:58:24 <Luke-Jr> yes
208 2013-08-12 06:58:49 <Luke-Jr> wallets are opaque. you're not supposed to think about what they do internally unless you're debugging. :p
209 2013-08-12 06:59:34 <Happzz> makes much more sense now.
210 2013-08-12 07:00:03 <Happzz> what about a feature to send all of the coins from all of the internal addresses to 1 single address, so it could be backed up more easily?
211 2013-08-12 07:01:15 <Luke-Jr> Happzz: there is a backup wallet function for backups
212 2013-08-12 07:01:28 <Happzz> i mean to a paper or something
213 2013-08-12 07:01:35 <Luke-Jr> resending all your coins to a single address only serves to incur transaction fees and slowness
214 2013-08-12 07:01:49 <Happzz> why is that?
215 2013-08-12 07:01:51 <Luke-Jr> Happzz: 0.9 will hopefully have HD wallets, which can do paper backups easier
216 2013-08-12 07:02:07 <Luke-Jr> although even then, those backups won't be complete
217 2013-08-12 07:02:08 <Happzz> "hd wallet"?
218 2013-08-12 07:02:14 <Luke-Jr> eg, you'd lose your labels/comments
219 2013-08-12 07:02:22 <Happzz> that won't be critical
220 2013-08-12 07:02:22 <Luke-Jr> Happzz: HD wallets are what Armory uses
221 2013-08-12 07:02:31 <Happzz> i see
222 2013-08-12 07:02:49 <Luke-Jr> Hierarchial Deterministic wallets
223 2013-08-12 07:03:11 <Luke-Jr> they essentially pregenerate infinite addresses from a single seed key
224 2013-08-12 07:03:13 <Happzz> i guess you could tell the client to send all change of every coin sends to a specific address, and that way move it all to a single address
225 2013-08-12 07:03:23 <Luke-Jr> Happzz: that would be reusing an address
226 2013-08-12 07:03:27 <TD> paper wallets i think will come to be seen more as a "last chance" backup rather than an actual way to store money
227 2013-08-12 07:03:34 <TD> because with time wallet metadata will become more and more important
228 2013-08-12 07:03:49 <Luke-Jr> TD: of course, or savings
229 2013-08-12 07:03:54 <TD> sure
230 2013-08-12 07:04:02 <Happzz> i don't trust my harddisk that much, really
231 2013-08-12 07:04:14 <Luke-Jr> Happzz: so make a wallet.dat backup
232 2013-08-12 07:04:20 <Luke-Jr> encrypted on some server
233 2013-08-12 07:04:23 <Happzz> i had the thoughts of saving a backup of my wallet in an encrypted truecrypt container on dropbox or something
234 2013-08-12 07:04:30 <Happzz> think that's safe enough?
235 2013-08-12 07:04:36 <Luke-Jr> just be sure to use a good encryption key
236 2013-08-12 07:04:42 <Luke-Jr> which means, something you can't memorize
237 2013-08-12 07:04:49 <Luke-Jr> and was generated by a computer
238 2013-08-12 07:05:34 <Luke-Jr> as a rule, humans are incapable of generating (or usually memorizing) reasonable passphrases
239 2013-08-12 07:11:24 <Luke-Jr> TD: btw, any idea how to debug BW for Android?
240 2013-08-12 07:11:31 <Luke-Jr> TD: it refuses to send my coins :/
241 2013-08-12 07:11:45 <Luke-Jr> and there's no upgrade available either
242 2013-08-12 07:11:57 <TD> refuses to send your coins?
243 2013-08-12 07:12:03 <TD> no, Goonie_ is about to start the play store rollout now
244 2013-08-12 07:12:23 <TD> there is a bug reported built into the app that sends detailed logs to Goonie_. you can also use "adb logcat" to see what's being logged
245 2013-08-12 07:12:33 <TD> but if this is key rotation related, wait and you'll get upgraded and rotated automatically
246 2013-08-12 07:13:31 <Luke-Jr> TD: someone is probably building a database of all possible Android privkeys as we speak, no?
247 2013-08-12 07:14:22 <TD> hard to say. the currently public details aren't enough to do a fast brute force. you'd still have to scan 2^64 keys. however non-public information would allow you to brute force a subset of the private keys faster. that's why we're in a hurry
248 2013-08-12 07:14:37 <Luke-Jr> isn't all the code in question public?
249 2013-08-12 07:14:43 <TD> if you could ensure eligius has removed the soft block size limit that'd help. i guess we're going to dump as much traffic onto the system as possible
250 2013-08-12 07:14:59 <TD> yes but the exact nature of some of the RNG failures are very subtle and not easily seen by code inspection
251 2013-08-12 07:15:29 <Luke-Jr> blockmaxsize=900000
252 2013-08-12 07:15:40 <TD> thanks
253 2013-08-12 07:15:44 <Luke-Jr> (already)
254 2013-08-12 07:15:59 <Luke-Jr> will there be fees on these?
255 2013-08-12 07:16:17 <Luke-Jr> or should I consider hacking Eligius to look for vulnerable keys somehow and let them past?
256 2013-08-12 07:16:30 <TD> min fee is included
257 2013-08-12 07:16:35 <Luke-Jr> ok
258 2013-08-12 07:16:40 <TD> we don't currently have any code that enumerates all vulnerable keys
259 2013-08-12 07:17:13 <Luke-Jr> ACTION wonders if the autoupgrade migration will work, if he can't even send his coins now
260 2013-08-12 07:17:21 <TD> how are your coins stuck?
261 2013-08-12 07:17:31 <Luke-Jr> dunno, the client just fails to send them
262 2013-08-12 07:17:36 <TD> huh
263 2013-08-12 07:17:37 <Luke-Jr> I'll give the adb a try
264 2013-08-12 07:17:41 <TD> do you see an error message or anything?
265 2013-08-12 07:17:44 <TD> the tx just doesn't propagate?
266 2013-08-12 07:17:46 <TD> Goonie: welcome back
267 2013-08-12 07:17:54 <Luke-Jr> TD: no, it fails to create a tx
268 2013-08-12 07:17:59 <TD> huh
269 2013-08-12 07:18:04 <TD> do you have a giant wallet?
270 2013-08-12 07:18:10 <Goonie> just noticed I could not talk
271 2013-08-12 07:18:10 <Luke-Jr> nope, 1 coin
272 2013-08-12 07:18:12 <TD> if it can't build a tx that's under the max std size it'll fail.
273 2013-08-12 07:18:15 <TD> ok
274 2013-08-12 07:18:33 <TD> that's not something i've heard of before. yes logs would help. Goonie how do you trigger the bug reporter?
275 2013-08-12 07:18:35 <Luke-Jr> btw, I hope by "rotation" you don't mean you're going to try to preserve mappings to addresses - this should be just sending all to 1 new address :x
276 2013-08-12 07:18:43 <TD> it sends to 1 checkpubkey output
277 2013-08-12 07:18:47 <TD> many->one
278 2013-08-12 07:18:58 <Luke-Jr> phew good
279 2013-08-12 07:18:59 <TD> it's all optimised to generate as few bytes as possible
280 2013-08-12 07:19:13 <Luke-Jr> 0.16727216
281 2013-08-12 07:19:55 <Luke-Jr> "Problem sending coins!" is what it displays
282 2013-08-12 07:20:23 <Luke-Jr> W/Wallet ( 3974): [backgroundThread] Insufficient value in wallet for send: needed 0.16737216
283 2013-08-12 07:20:37 <TD> oh
284 2013-08-12 07:20:41 <TD> you're trying to empty your wallet out entirely?
285 2013-08-12 07:20:43 <Luke-Jr> bah, it's demanding a fee when there shouldn't be one, and not telling me why it failed
286 2013-08-12 07:20:45 <Luke-Jr> yes
287 2013-08-12 07:20:49 <TD> that's fixed in the version we're about to deply
288 2013-08-12 07:20:58 <Goonie> can you repeat what's the problem? I must have missed it because I needed to close and reopen irc.
289 2013-08-12 07:21:00 <TD> there's an "empty wallet" menu item that auto calculates the right amount - fee and builds the correct tx
290 2013-08-12 07:21:05 <TD> Goonie: he needs the empty wallet feature in 0.10
291 2013-08-12 07:21:07 <Luke-Jr> Goonie: apparently already fixed
292 2013-08-12 07:21:19 <Luke-Jr> TD: is the fee calc fixed too? :p
293 2013-08-12 07:21:37 <Luke-Jr> 0.16+ BTC from before the Conference should IMO be feeless by now
294 2013-08-12 07:21:39 <TD> Luke-Jr: pressing "empty wallet" sends your current balance - correct fee for the size of that tx (min fee*kb)
295 2013-08-12 07:22:02 <TD> yeah unfortunately bitcoinj always attaches a fee, because fee-less transactions tend to sit for a long time. due to the weird 27kb limit on free txns per block
296 2013-08-12 07:22:21 <TD> fee handling is all kinds of broke in bitcoin. gavinandresen is on the case, i think. at least he is post-payment-protocol
297 2013-08-12 07:23:47 <Goonie> ok just a aware that if your wallet is corrupt due to earlier bugs (since the last replay), the "empty wallet" will probably never confirm.
298 2013-08-12 07:23:50 <Luke-Jr> there we go, sent to my -Qt
299 2013-08-12 07:23:59 <TD> great
300 2013-08-12 07:24:50 <Luke-Jr> TD: btw, is there any way to get a proper SSH or VNC server on Android? :/
301 2013-08-12 07:24:58 <Luke-Jr> I wasted hours trying to get one, but failed
302 2013-08-12 07:25:16 <Luke-Jr> proper as in, not a chroot/virtual SSH
303 2013-08-12 07:25:16 <TD> you can use adb to get a shell. on modern androids it's RSA protected and can be routed over TCP. For VNC, not sure, I think you might need a rooted phone for that.
304 2013-08-12 07:25:34 <Luke-Jr> mine is rooted, but all the VNC server apps don't work
305 2013-08-12 07:25:45 <Goonie> Luke-Jr: if there was, I'm sure it would use SecureRandom (-:
306 2013-08-12 07:25:45 <Luke-Jr> (what's with 90% of Google Play being broken anyhow?)
307 2013-08-12 07:26:02 <Luke-Jr> Goonie: OpenSSH isn't Java
308 2013-08-12 07:26:21 <t7> im sick of android/google now and am going to get a jolla phone or something similar next
309 2013-08-12 07:26:28 <Luke-Jr> t7: Jolla?
310 2013-08-12 07:26:34 <TD> the ex nokia thing
311 2013-08-12 07:26:37 <Luke-Jr> ACTION would google, but that'd be ironic
312 2013-08-12 07:26:43 <Luke-Jr> ah
313 2013-08-12 07:26:49 <t7> real linux phone
314 2013-08-12 07:27:01 <Goonie> ndk native apps must use the java api as well, except some whitelisted apis like opengl
315 2013-08-12 07:27:07 <Luke-Jr> I hate phones. I'm holding out for someone to make a device that runs Gentoo and has a keyboard again.
316 2013-08-12 07:27:10 <Luke-Jr> stuck with N900 for now
317 2013-08-12 07:27:41 <Luke-Jr> Goonie: in other words, I won't find what I'm looking for in Google Play because of some stupid restrictions <.<
318 2013-08-12 07:28:03 <Luke-Jr> s/runs/can run/
319 2013-08-12 07:28:09 <Goonie> Luke-Jr: to be honest I don't know
320 2013-08-12 07:28:46 <Luke-Jr> oh well
321 2013-08-12 07:29:00 <TD> actually you can write entirely native android apps now
322 2013-08-12 07:29:08 <TD> but they don't get access to the full api of course. it's intended for games.
323 2013-08-12 07:29:17 <TD> you can bring up an opengl context and stuff without any java code at all, iirc
324 2013-08-12 07:29:20 <Luke-Jr> I just want to install stock OpenSSH
325 2013-08-12 07:29:33 <TD> Luke-Jr: probably the cyanogen guys have what you want.
326 2013-08-12 07:30:21 <Luke-Jr> TD: it's too bad you're not on the Android team, or I'd beg you for a keyboarded handheld :P
327 2013-08-12 07:30:50 <TD> yeah i miss the G1 keyboard too. that said the modern soft keyboards with swiping on them are really good
328 2013-08-12 07:30:54 <TD> you can go very fast
329 2013-08-12 07:31:00 <TD> so i don't miss it too much these days
330 2013-08-12 07:31:22 <warren> Goonie: hey, still here?
331 2013-08-12 07:31:28 <Luke-Jr> swiping sounds like a disaster while driving :p
332 2013-08-12 07:32:07 <warren> Luke-Jr: dude!
333 2013-08-12 07:32:13 <Luke-Jr> lol
334 2013-08-12 07:32:20 <warren> Luke-Jr: there's a perfect phone with keyboard
335 2013-08-12 07:32:24 <Luke-Jr> there is?
336 2013-08-12 07:32:34 <warren> well, I wish it had a bigger screen, but it's quite nice
337 2013-08-12 07:33:26 <warren> Luke-Jr: apextmo a.k.a. T-Mobile Galaxy S Relay 4G. 1.5GH dual core, 4 inch screen, slideout 5 row qwerty keyboard, same guts as "d2" (SGS3 generation)... and it has a Cyanogenmod port.
338 2013-08-12 07:34:03 <Luke-Jr> 1.5 GH? it does mining too? :P
339 2013-08-12 07:34:13 <warren> heh... GHz
340 2013-08-12 07:34:32 <Luke-Jr> warren: any idea how the mainline (or at least free software) Linux support is for it?
341 2013-08-12 07:34:46 <warren> many distros will run in a chroot
342 2013-08-12 07:35:02 <Luke-Jr> hmm, just 8 GB flash :x
343 2013-08-12 07:35:09 <Luke-Jr> warren: don't want a chroot.. :p
344 2013-08-12 07:35:15 <Luke-Jr> want full X.org + KDE
345 2013-08-12 07:35:20 <warren> what you want doesn't exist
346 2013-08-12 07:35:27 <petertodd> interesting, coinbae choked on block 000000000000001fbc5a74fb56b1cf8949bcfad8e3ae06f2af638b94f7633fbc, this tx in that block is interesting: 77822fd6663c665104119cb7635352756dfc50da76a92d417ec1a12c518fad69
347 2013-08-12 07:35:29 <Luke-Jr> ideally with a resistive touchscreen! :P
348 2013-08-12 07:35:42 <wizkid057> Luke-Jr: http://www.motorola.com/us/consumers/MOTOROLA-PHOTON-Q/m-PHOTON-Q-4G-LTE,en_US,pd.html
349 2013-08-12 07:35:44 <Luke-Jr> warren: N900 can do it
350 2013-08-12 07:35:55 <warren> then stick to N900...
351 2013-08-12 07:36:01 <Luke-Jr> it's so RAM-limited..
352 2013-08-12 07:36:23 <warren> Luke-Jr: SGS3 or SGS4 with 2GB RAM and 32GB onboard flash + microSD slot is quite nice, but no slideout keyboard.
353 2013-08-12 07:36:43 <warren> Luke-Jr: the apextmo has only 1GB RAM, 8GB flash + microSD, so not ideal.
354 2013-08-12 07:37:03 <Luke-Jr> warren: N900 is 256 MB RAM :p
355 2013-08-12 07:37:08 <Luke-Jr> but 16 GB flash
356 2013-08-12 07:37:13 <warren> Luke-Jr: OTOH, I used to run openssh and rsync in a fedora chroot on my epicmtd, 512MB RAM, 1GB flash + microSD.
357 2013-08-12 07:37:45 <warren> I used ssh + rsync to backup my phone when on home wifi.
358 2013-08-12 07:37:46 <petertodd> Rather strange what coinbase has done too, it says "opcode-65285", so I suspect they've somehow been confused parsing an opcode as two bytes rather than one, weird.
359 2013-08-12 07:38:18 <Luke-Jr> petertodd: O.o
360 2013-08-12 07:38:18 <warren> petertodd: you know, they'd probably pay you a lot in bug bounties if you explained them stuff rather than ridicule them.
361 2013-08-12 07:38:27 <petertodd> warren: huh/
362 2013-08-12 07:38:30 <petertodd> ?
363 2013-08-12 07:38:32 <Luke-Jr> warren: didn't they hire coblee for that? :p
364 2013-08-12 07:38:41 <petertodd> warren: I didn't make that tx
365 2013-08-12 07:38:42 <warren> Luke-Jr: I have no idea why they hired coblee.
366 2013-08-12 07:39:16 <warren> petertodd: I'm guessing they want analysis/fixes/vulnerabilities
367 2013-08-12 07:39:17 <TD> this is the bug that killed off electrum servers?
368 2013-08-12 07:39:23 <TD> anyone figure out what the issue with that script is yet?
369 2013-08-12 07:39:33 <sipa> an unparseable scriptPubKey, i read?
370 2013-08-12 07:39:36 <petertodd> TD: what bug is that?
371 2013-08-12 07:39:52 <petertodd> TD: oh crazy, someone embedded a patch in the tx...
372 2013-08-12 07:40:03 <TD> lolwut
373 2013-08-12 07:40:11 <warren> Luke-Jr: plain Cyanogenmod on pretty much any supported phone with openssh or dropbear sshd + rsync is quite nice. Doesn't require much RAM at all.
374 2013-08-12 07:40:14 <TD> petertodd: electrum servers all stopped following the chain at exactly the same height
375 2013-08-12 07:40:19 <TD> due to some script parsing exception
376 2013-08-12 07:40:24 <warren> Luke-Jr: I used to dev there a lot.
377 2013-08-12 07:40:35 <TD> https://bitcointalk.org/index.php?topic=271761.0
378 2013-08-12 07:40:48 <petertodd> http://pastebin.com/8mjzE6yY <- said patch
379 2013-08-12 07:40:57 <Goonie> Ok the fun begins. 3.15 is released to Google Play. I increated versionCode again, so everyone will upgrade including the beta testers. Don't worry, anyone who's already been rotated won't be rotated again.
380 2013-08-12 07:41:10 <Luke-Jr> cute
381 2013-08-12 07:41:54 <TD> my node is catching up so i don't know how big the mempool is currently
382 2013-08-12 07:42:02 <petertodd> huh... I mentioned this in the forums a few weeks ago actually, way back when Satoshi briefly added some code that would have done double-width 16-bit opcodes, and sounds like some people didn't realize the code was removed years ago...
383 2013-08-12 07:42:09 <Luke-Jr> how do I tell android to upgrade?
384 2013-08-12 07:42:22 <Goonie> TD: I'll have a look at it. But don't worry, usually it takes hours before Google starts the rollout.
385 2013-08-12 07:42:32 <TD> oh, really? interesting. i wonder what the source of delay is
386 2013-08-12 07:42:39 <TD> presumably anti-malware scanning takes a bit of time, but hours?
387 2013-08-12 07:43:04 <Goonie> TD: It's been that long since I do Android development. Back then, there was no word of malware at all.
388 2013-08-12 07:43:12 <TD> ok
389 2013-08-12 07:43:21 <Luke-Jr> automated antimalware at this level is impossible..? O.o
390 2013-08-12 07:43:23 <TD> i guess it has to replicate out to serving datacenters, devices have to check in to learn there's an update, etc
391 2013-08-12 07:43:44 <Goonie> I'm off to brush my teeth (-:
392 2013-08-12 07:43:53 <petertodd> ah, here's why coinbase died: https://github.com/lian/bitcoin-ruby/commit/29c2c01b09db165b2a746a2409e0c1ed3b67d7e6 looks like they didn't update production, same issue as electrum
393 2013-08-12 07:44:47 <warren> Luke-Jr: Cyanogenmod has a built-in updater now, you can choose stable, maintenance or nightly build stream.
394 2013-08-12 07:45:22 <TD> i wish there was a working testnet block explorer
395 2013-08-12 07:46:01 <petertodd> someone just spent an odd tx in eligius last block too: 61a078472543e9de9247446076320499c108b52307d8d0fafbe53b5c4e32acc4
396 2013-08-12 07:46:15 <petertodd> TD: blockchain.info really should have a public testnet version iMO
397 2013-08-12 07:46:28 <TD> it would be nice
398 2013-08-12 07:46:42 <petertodd> TD: it's a good way of publicly showing you do testing too
399 2013-08-12 07:47:04 <Luke-Jr> I wish there was a block explorer builtin to Bitcoin-Qt <.<
400 2013-08-12 07:48:47 <sipa> Luke-Jr: tried overblock?
401 2013-08-12 07:48:49 <TD> it's unfortunate that b.i nosedived just when we need it most
402 2013-08-12 07:56:09 <petertodd> https://bitcointalk.org/index.php?topic=271486.msg2916349#msg2916349 <- wow, apache harmony screwed up so badly the worst case is 9 bits of entropy
403 2013-08-12 07:56:56 <TD> yeah but that will never happen on android
404 2013-08-12 07:57:14 <petertodd> i know, says so right in the post, still remarkable
405 2013-08-12 07:57:19 <TD> indeed
406 2013-08-12 07:58:00 <TD> i would love to know what was going through their head when they added % 128
407 2013-08-12 07:58:03 <Goonie> What would be a high/an alerting number of tx in the mempool? I assume everything below 3000 is nothing to worry about, because that's roughly the number of tx that fit in a block?
408 2013-08-12 07:58:29 <petertodd> Goonie: what do you mean by 'alerting'?
409 2013-08-12 07:58:42 <Goonie> petertodd: before nodes will go down due to oom
410 2013-08-12 07:58:52 <TD> nobody knows, unfortunately.
411 2013-08-12 07:58:54 <TD> it varies by node
412 2013-08-12 07:59:03 <TD> 3000 is probably nowhere near enough to cause issues though
413 2013-08-12 07:59:20 <petertodd> Goonie: oh, not likely, just do the math for how many btc it costs per mb and you'll see how unlikely it is for a fast OOM situation to happen
414 2013-08-12 07:59:40 <warren> Goonie: PM ... although if you're busy now I can send it via e-mail
415 2013-08-12 07:59:49 <TD> that said there's not much point putting txns into the mempool faster than they can drain out
416 2013-08-12 07:59:59 <TD> petertodd: txns use up more space in RAM than on the wire though
417 2013-08-12 08:00:14 <TD> we shouldn't worry too much but it's still worth being careful
418 2013-08-12 08:01:34 <petertodd> TD: oh, granted, now that the fee is 0.1mBTC/KB that's only $10k USD per GB... and as you say, maybe $5K including overhead
419 2013-08-12 08:02:27 <Luke-Jr> sipa: nhoi?
420 2013-08-12 08:02:56 <sipa> Luke-Jr: ?
421 2013-08-12 08:03:07 <sipa> https://github.com/realazthat/overblock
422 2013-08-12 08:03:23 <sipa> it's an RPC-based block explorer
423 2013-08-12 08:03:43 <Goonie> petertodd: the cost of a tx is not a factor for me, since in the current case I am rotating my users bitcoins and not mine.
424 2013-08-12 08:04:02 <petertodd> Goonie: i'm talking about attacks
425 2013-08-12 11:33:15 <handle> 17:43 < Luke-Jr> I wish there was a block explorer builtin to Bitcoin-Qt <.<
426 2013-08-12 11:33:41 <handle> on one hand, that would be incredible - on the other hand, it makes it less friendly to new users
427 2013-08-12 11:33:45 <jgarzik> NY regulator memo, on virtual currencies and bitcoin: https://bitcointalk.org/index.php?topic=272269.0
428 2013-08-12 11:33:54 <handle> but if someone wants to build a block explorer into bitcoin-qt, screw the new users :P
429 2013-08-12 11:34:08 <sipa> handle: why would it be less friendly...?
430 2013-08-12 11:34:32 <sipa> it can't be enabled by default in any case
431 2013-08-12 11:34:45 <sipa> (it requires some indexes that are optional in normal operation)
432 2013-08-12 11:36:43 <t7> 'national security' so long yanks
433 2013-08-12 11:36:58 <handle> hmm, I guess it wouldn't be that bad in terms of friendliness - it would at least (hopefully) dispel the "untrackable" myth
434 2013-08-12 11:37:25 <handle> also, would it not be better to build the indexes as the blockchain is gathered?
435 2013-08-12 11:37:40 <handle> why couldn't it be enabled by default?
436 2013-08-12 11:38:06 <gmaxwell> handle: because it increases the burden of running a node for no purpose (if that functionality isn't used)
437 2013-08-12 11:38:49 <gmaxwell> Our supply of public full nodes wouldn't be enhanced by needing another 2 gigs (and growing) and additional IO to maintain them.
438 2013-08-12 11:38:59 <lianj> aw, missed all the fun from last night
439 2013-08-12 11:39:09 <gmaxwell> lianj: more fun today, no doubt.
440 2013-08-12 11:39:14 <helo> jgarzik: "Taking steps to ensure that transactions are processed virmly is vital..." ??
441 2013-08-12 11:39:22 <lianj> is http://paste.mhanne.net/raw/fd2164218635b1ad62bf513f6d3030129a0b2307 really from him or just peter
442 2013-08-12 11:39:30 <helo> ack, bad brain
443 2013-08-12 11:39:41 <helo> *promptly
444 2013-08-12 11:40:18 <gmaxwell> lianj: so, when doing the ruby stuff... did you model your parsing code after abe? I'm wondering how you got 16 bit opcode support code.... :)
445 2013-08-12 11:40:20 <jgarzik> helo, yeah, WTF
446 2013-08-12 11:40:42 <lianj> gmaxwell: i think from bitcoinj back then
447 2013-08-12 11:40:43 <helo> i guess they are referring to mtgox withdrawal delays?
448 2013-08-12 11:40:52 <handle> gmaxwell: but do you think more people would use full nodes if the block explorer were built in, even despite the 2GB overhead?
449 2013-08-12 11:40:53 <gmaxwell> lianj: ah! interesting.
450 2013-08-12 11:41:04 <lianj> gmaxwell: but at least i catched it on the testnet3 tx 7 days ago :|
451 2013-08-12 11:41:05 <sipa> handle: also, if indexes are enabled for everyone, it will probably encourage people to build infrastructure that relies on it
452 2013-08-12 11:41:14 <handle> I suppose at that point, having it optional would be best
453 2013-08-12 11:41:21 <sipa> handle: instead of more scalable solutions (decent wallets that track only what is necessary)
454 2013-08-12 11:41:31 <gmaxwell> handle: generally the kind of high uptime publically reachable nodes we need most aren't running on systems with users sitting at them. Hard to say. But you don't need a _default_ to get that outcome.
455 2013-08-12 11:41:44 <gmaxwell> handle: if you want an explorer, you'll know it, and can check the box. :)
456 2013-08-12 11:41:46 <sipa> handle: as we hope to get block pruning at some point in the future, it's preferable that people don't rely on always having all blocks available
457 2013-08-12 11:41:47 <handle> gmaxwell: I'll agree with that
458 2013-08-12 11:42:27 <handle> ah yes, that's true
459 2013-08-12 11:42:57 <handle> however doesn't block pruning require the knowledge of all unspent outputs anyways?
460 2013-08-12 11:43:06 <sipa> it does
461 2013-08-12 11:43:15 <sipa> that's why we keep unspent outputs in a completely separate database
462 2013-08-12 11:43:22 <sipa> the blocks are hardly necessary at all
463 2013-08-12 11:43:27 <handle> ah
464 2013-08-12 11:43:30 <sipa> (only for serving to other nodes, and rescanning)
465 2013-08-12 11:43:44 <sipa> and for reorganizations you need the last few ones
466 2013-08-12 11:44:58 <gmaxwell> Right now the indexes are about 2gb overhead, over pruning they're more like 11gb overhead.
467 2013-08-12 11:45:29 <jgarzik> speaking of
468 2013-08-12 11:45:34 <jgarzik> what's the status of the pruning pull req?
469 2013-08-12 11:45:42 <sipa> i have never seen a pruning pull req
470 2013-08-12 11:45:44 <jgarzik> gettxoutset needed a flag?
471 2013-08-12 11:45:51 <sipa> ah, the OP_RETURN thing
472 2013-08-12 11:45:54 <jgarzik> sipa, your prune-unspendable
473 2013-08-12 11:45:57 <sipa> sorry, haven't had time
474 2013-08-12 11:46:40 <sipa> i hoped to complete headers-first this weekend, but there were these damned social activities :)
475 2013-08-12 11:49:08 <handle> gmaxwell: so pruning could potentially take 11GB out of the blockchain storage? (or am I understanding that wrong)
476 2013-08-12 11:49:50 <sipa> handle: count the size of your blk* and rev* files
477 2013-08-12 11:49:56 <sipa> a bit less than that can be pruned
478 2013-08-12 11:50:06 <sipa> in ~/.bitcoin/blocks
479 2013-08-12 11:50:42 <gmaxwell> handle: a pruned node would only need a couple hundred megs right now plus however many of the most recent blocks you keep, plus whatever amount of the fractional history you keep.
480 2013-08-12 11:51:25 <petertodd> interesting tx on blockchain.info: http://blockchain.info/tx/59bd7b2cff5da929581fc9fef31a2fba14508f1477e366befb1eb42a8810a000
481 2013-08-12 11:53:45 <jgarzik> petertodd, what makes it interesting? apart from gmaxwell ref of course
482 2013-08-12 11:53:59 <petertodd> jgarzik: it has a javascript popup
483 2013-08-12 11:54:14 <petertodd> jgarzik: bc.i doesn't escape the binary payload
484 2013-08-12 11:54:44 <lianj> lol
485 2013-08-12 11:55:01 <sipa> outch!
486 2013-08-12 11:55:10 <petertodd> I just messaged piuk about it on bitcointalk - is there a faster way to get ahold of him?
487 2013-08-12 11:55:19 <sipa> petertodd: yes, start exploiting it :D
488 2013-08-12 11:55:28 <petertodd> sipa: heh, well...
489 2013-08-12 11:55:36 <gmaxwell> Check.
490 2013-08-12 11:55:51 <sipa> like "what's the fastest way to the hospital? just jump down this building"
491 2013-08-12 11:55:59 <jgarzik> heh
492 2013-08-12 11:56:59 <gmaxwell> apparently we have no phone number for him.
493 2013-08-12 11:58:18 <handle> gmaxwell: nice to hear - does only that portion need to be downloaded from peers? (ignoring any fractional history)
494 2013-08-12 11:58:19 <gmaxwell> petertodd: this link would have worked better: http://blockchain.info/tx/59bd7b2cff5da929581fc9fef31a2fba14508f1477e366befb1eb42a8810a000?show_adv=true
495 2013-08-12 11:58:25 <gmaxwell> handle: no.
496 2013-08-12 11:58:39 <gmaxwell> handle: it doesn't change the bandwidth/computation, just storiage.
497 2013-08-12 11:58:49 <petertodd> gmaxwell: ah, good point
498 2013-08-12 11:58:56 <petertodd> ACTION always uses advanced
499 2013-08-12 11:59:27 <handle> I see
500 2013-08-12 11:59:31 <petertodd> tx bc00cc28c9be4f15cf5fa4b93c79c36aefd5bcc54f54e689017d528333b6fd7b is the same, but more subtle...
501 2013-08-12 11:59:45 <sipa> handle: the fact that peers still need to be able to download it, is why pruning hasn't been implemented
502 2013-08-12 12:00:38 <gmaxwell> petertodd: can you also please tell piuk to move the mywallet stuff to something which isn't the same domain (or a subdomain) of something that displays untrusted input?
503 2013-08-12 12:00:51 <petertodd> gmaxwell: good idea
504 2013-08-12 12:00:54 <gmaxwell> blocks.blockchain.info / wallet.blockchain.info would be fine.
505 2013-08-12 12:01:16 <handle> blockwallet.info
506 2013-08-12 12:02:14 <iddo> sipa: gmaxwell: about "self-descriptive strengthened keying" (https://bitcointalk.org/index.php?topic=102349.0), have you compared it to this HKDF scheme: http://robotics.stanford.edu/~xb/security07/index.html ?
507 2013-08-12 12:02:30 <iddo> i think that the advantage of HKDF is that it makes life even harder for an attacker who tries to a dictionary attack
508 2013-08-12 12:03:05 <iddo> and the disadvantage is that the user has to save a public string, i.e. not jt remember a passphrase
509 2013-08-12 12:03:27 <iddo> s/jt/just
510 2013-08-12 12:05:44 <gmaxwell> sort of interesting that none of the normal transaction visualization tools show you that a signature is SINGLE|ANYONECANPAY.
511 2013-08-12 12:07:05 <petertodd> gmaxwell: yeah, it should be some kind of nice visual showing how the signature encloses various things and not other things
512 2013-08-12 12:07:59 <gmaxwell> that XSS exploit on blockchain.info was signed blind to the actual attack in it???
513 2013-08-12 12:08:29 <petertodd> gmaxwell: what does that mean?
514 2013-08-12 12:10:29 <gmaxwell> petertodd: it's a sighash single, and the signature on the input spending one of my coins doesn't cover the OP_RETURN.
515 2013-08-12 12:10:31 <lianj> at least there is no tweets about "omg xss in bc.i. everything is doomed" already. lets hope it stays that way until fixed
516 2013-08-12 12:11:15 <petertodd> gmaxwell: oh right
517 2013-08-12 12:14:48 <petertodd> ...and it's fixed
518 2013-08-12 12:15:00 <petertodd> also piuk says the wallet is moving to another domain soon
519 2013-08-12 12:28:51 <Vinnie_win> Hey guys
520 2013-08-12 12:28:55 <Vinnie_win> http://codepad.org/QVE7P3A5 What do I put on line 14?
521 2013-08-12 12:30:42 <sipa> (true) ?
522 2013-08-12 12:31:02 <jgarzik> sipa, http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/assert.h.html ?
523 2013-08-12 12:31:07 <jgarzik> er
524 2013-08-12 12:31:10 <jgarzik> Vinnie_win, http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/assert.h.html ?
525 2013-08-12 12:31:11 <sipa> ah
526 2013-08-12 12:31:19 <sipa> do {} while(true)
527 2013-08-12 12:31:26 <Vinnie_win> jgarzik: Thanks!
528 2013-08-12 12:31:38 <Vinnie_win> sipa: Yes but that makes visual studio produce idiotic warnings, which I dont like to turn off.
529 2013-08-12 12:32:01 <gmaxwell> Vinnie_win: you can disable VS warnings on a line by line basis or with pragams around the offending stupidity.
530 2013-08-12 12:32:17 <Vinnie_win> gmaxwell: I'm well are but its laborious
531 2013-08-12 12:56:26 <Vinnie_win> *I'm well aware but its laborious.
532 2013-08-12 12:56:29 <Vinnie_win> How go things on the bitcoin front?
533 2013-08-12 13:04:11 <CodeShark> quiet, apparently :p
534 2013-08-12 13:06:09 <Luke-Jr> we're all busy building private key tables for all the possible Android addresses
535 2013-08-12 13:06:11 <Luke-Jr> :P
536 2013-08-12 13:06:58 <CodeShark> lol
537 2013-08-12 13:07:21 <Cusipzzz> for research, of course
538 2013-08-12 13:07:25 <CodeShark> while you're at it you might want to take a crack at some other types of applications besides bitcoin :)
539 2013-08-12 13:08:16 <Ry4an> Yeah, I'm wondering if my android ssh's client's private keys were well generated. I'm guessing no.
540 2013-08-12 13:09:42 <CodeShark> is there an in-depth article published on this vulnerability yet?
541 2013-08-12 13:10:48 <CodeShark> is it just the SecureRandom class?
542 2013-08-12 13:11:11 <TD> "it's complicated"
543 2013-08-12 13:11:58 <CodeShark> do you understand the vulnerability well, TD?
544 2013-08-12 13:12:43 <TD> yes
545 2013-08-12 13:13:01 <gmaxwell> TD: is it bigger than a breadbox?
546 2013-08-12 13:13:14 <TD> blink
547 2013-08-12 13:13:23 <TD> depends how much you like bread, i guess
548 2013-08-12 13:13:38 <gmaxwell> hm. /me consults the side-channel table for "blink"
549 2013-08-12 13:13:40 <CodeShark> can you give a three sentence summary?
550 2013-08-12 13:13:55 <TD> no
551 2013-08-12 13:14:16 <TD> unfortunately my understanding is based on non-public information from the android internal bug tracker. because i'm not on the android team or security-pr team, i can't really discuss things in detail. also, knowing exactly what the bugs are would allow much faster and worse exploitation than we've seen so far
552 2013-08-12 13:14:47 <TD> however you can be assured that right now people are beating down press@google.com with a battering ram, so i guess there will be some public statements tonight or tomorrow after california has woken up and had a chance to put something together
553 2013-08-12 13:15:14 <gmaxwell> there have been some people going around saying that it's _just_ earlier android. I'd advised that I was relatively sure that was a seperate issue and not the case here.
554 2013-08-12 13:15:25 <TD> i think that is good advice
555 2013-08-12 13:15:40 <jgarzik> gmaxwell, petertodd, TD: Has anyone mapped out a model for a zero-trust, or low-trust, decentralized auction? That's one problem I would love to solve without a centralized website.
556 2013-08-12 13:16:02 <TD> i haven't. i was interested in auctions a while ago but got distracted with other things.
557 2013-08-12 13:16:08 <TD> ACTION discovered that jgarzik wrote rngd yesterday
558 2013-08-12 13:16:13 <jgarzik> heh
559 2013-08-12 13:16:14 <TD> funny how the same names crop up repeatedly in the open source world :)
560 2013-08-12 13:16:43 <TD> i wish we had tools that gave insight into how tx are chosen for blocks. it's not really clear to me why the mempool is growing and blocks that are being mined aren't full.
561 2013-08-12 13:16:49 <TD> it'd be nice if i could see a breakdown graphically
562 2013-08-12 13:17:01 <jgarzik> I wrote original hardware RNG drivers for AMD, VIA and Intel RNGs (such hardware, except perhaps VIA, are long disappeared from the scene)
563 2013-08-12 13:17:09 <jgarzik> then it began to make sense to put some of that in userspace
564 2013-08-12 13:17:19 <jgarzik> people complained about FIPS testing code in the kernel and whatnot
565 2013-08-12 13:17:25 <TD> why use a daemon though? why doesn't /dev/random just pull from the hardware RNG directly?
566 2013-08-12 13:17:46 <TD> btw also - why do you bother testing for randomness of the output? if it's not random mixing into the entropy pool can't hurt, and you can't do anything about it beyond log an alert anyway
567 2013-08-12 13:18:03 <gmaxwell> jgarzik: the transaction part for an auction wouldn't be hard. You'd announce the auction along with a anyone can pay signed input. And people propose their bids by giving you transactions which they pay into.. only one can be valid.
568 2013-08-12 13:18:18 <jgarzik> TD, in some situations like CPU RNGs, it is nice to schedule that operation, so you cannot trigger the kernel pounding the RNG hardware from userland
569 2013-08-12 13:18:42 <Diablo-D3> [11:11:44] <TD> why use a daemon though? why doesn't /dev/random just pull from the hardware RNG directly?
570 2013-08-12 13:18:49 <Diablo-D3> only if you have a driver for it
571 2013-08-12 13:19:07 <Diablo-D3> and not all hardware RNGs constantly stream random data as fast as you can read it
572 2013-08-12 13:19:10 <gmaxwell> TD: logging an alert wouldn't be totally useless... though the fact that rngd throws the data away when the fips test fails is unfortunate, though not a material weakness.
573 2013-08-12 13:19:18 <jgarzik> the kernel does have an internal get-hardware-rng-bytes call. /dev/random does a long of mixing. rngd does FIPS testing and is a scheduled process. a lot of parts and details flying around in the air. :)
574 2013-08-12 13:19:31 <Diablo-D3> jgarzik: /dev/random DOES do a lot of mixing
575 2013-08-12 13:19:32 <jgarzik> notably, if the hardware RNG goes south and returns all zero or all-fffff
576 2013-08-12 13:19:39 <Diablo-D3> jgarzik: but its not an infinite source
577 2013-08-12 13:19:41 <jgarzik> you want to notice those simple cases
578 2013-08-12 13:19:48 <Diablo-D3> thats what urandom is for
579 2013-08-12 13:19:50 <gmaxwell> (or all 0101...)
580 2013-08-12 13:20:11 <TD> yea
581 2013-08-12 13:20:26 <gmaxwell> (which is the failure mode of most hardware that does simple unbiasing)
582 2013-08-12 13:20:51 <Diablo-D3> gmaxwell: yeah but
583 2013-08-12 13:21:02 <Diablo-D3> that has to come up occasionally normally
584 2013-08-12 13:21:29 <gmaxwell> yes, the fips tests run on a rather big block of data, the rate of false positives is fairly low.
585 2013-08-12 13:21:30 <jgarzik> TD, if you use an ATA device or any ethernet (not wireless) NIC, you are running kernel code I wrote
586 2013-08-12 13:21:55 <Diablo-D3> yeah jgarzik is a real dev =P
587 2013-08-12 13:24:05 <TD> well
588 2013-08-12 13:24:05 <TD> yeah
589 2013-08-12 13:24:14 <TD> if you load an adsense ad into your browser, you're running code i wrote ;)
590 2013-08-12 13:24:21 <TD> ACTION waves his dick around like a boss
591 2013-08-12 13:24:40 <Diablo-D3> well thats simple
592 2013-08-12 13:24:43 <Diablo-D3> I use adp.
593 2013-08-12 13:24:52 <TD> but yeah it was funny to see your name in rngd. too bad android doesn't use it ...
594 2013-08-12 13:25:01 <Diablo-D3> er abp
595 2013-08-12 13:25:21 <TD> heh
596 2013-08-12 13:25:37 <Diablo-D3> seriously, google ads suck
597 2013-08-12 13:25:54 <jgarzik> FWIW, I tend to like multi-level RNG solutions
598 2013-08-12 13:26:10 <Diablo-D3> jgarzik: well, its a good idea either way, more random input is always better
599 2013-08-12 13:26:13 <jgarzik> get entropy from the kernel, process counters and other locations, and mix it yourself in an app-internal RNG
600 2013-08-12 13:26:16 <TD> i've stopped trusting them
601 2013-08-12 13:26:23 <TD> i've seen too many userspace RNGs that just break things instead of making them better
602 2013-08-12 13:26:29 <TD> reading /dev/urandom is fast. one syscall. big deal.
603 2013-08-12 13:26:36 <jgarzik> nod
604 2013-08-12 13:26:38 <gmaxwell> jgarzik: thats a ducky plan, except a lot of app writers don't have the time or the background to do that safely.
605 2013-08-12 13:26:49 <jgarzik> and a fair point
606 2013-08-12 13:26:52 <TD> i really wonder why openssl even has its own entropy pool on linux. AFAICT it just opens up the potential for errors.
607 2013-08-12 13:26:59 <gmaxwell> and you get things like %128 on bytes fed through libc's random(). :P
608 2013-08-12 13:27:12 <jgarzik> I'm just overly paranoid about single-source
609 2013-08-12 13:27:26 <TD> looks like btcguild is maxing out its blocks
610 2013-08-12 13:27:31 <gmaxwell> TD: portablity, and performance.
611 2013-08-12 13:27:34 <Diablo-D3> TD: honestly, I dont know why openssl is even still around
612 2013-08-12 13:27:48 <Diablo-D3> I mean, there arent "better" ssl frameworks out there
613 2013-08-12 13:27:54 <TD> gmaxwell: i wonder if it's really so much faster ..... syscalls are so fast these days on good hardware.
614 2013-08-12 13:28:00 <Diablo-D3> but other frameworks are better licensed and have saner code
615 2013-08-12 13:28:03 <gmaxwell> TD: see also the fun last year with embedded linux devices where /dev/random was determinstic. :(
616 2013-08-12 13:28:06 <Diablo-D3> even if they cant do everything openssl does
617 2013-08-12 13:28:36 <TD> for embedded devices, i can well believe it. hardware RNG is essential there.
618 2013-08-12 13:29:24 <handle> I'm actually quite surprised most devices don't have a hardware RNG
619 2013-08-12 13:29:42 <Diablo-D3> handle: intel is trying to change that
620 2013-08-12 13:29:51 <CodeShark> they've been trying for quite some time
621 2013-08-12 13:29:52 <Diablo-D3> sandy bridge and up? ivy bridge? have hw rngs
622 2013-08-12 13:29:57 <handle> that said, there are many potential sources of entropy on a phone, considering how many sensors there are
623 2013-08-12 13:30:02 <CodeShark> finally they are putting it into the CPU
624 2013-08-12 13:30:03 <TD> hmmm. is there a way via RPC to see the priority and such of every tx in the mempool?
625 2013-08-12 13:30:10 <handle> Diablo-D3: yeah, I use the RNG on my box and it's really nice
626 2013-08-12 13:30:15 <Diablo-D3> CodeShark: putting it into the cpu fixes shit
627 2013-08-12 13:30:21 <Diablo-D3> like putting all the VRMs into haswell
628 2013-08-12 13:30:42 <Diablo-D3> means about 90% less shit a mobo can fuck up that involves the part of the board near the cpu
629 2013-08-12 13:32:08 <gmaxwell> handle: estimating their entropy is harder. Linux kernel rng lost a lot of its randomness sources due to concern that the sources weren't all that random.
630 2013-08-12 13:32:10 <jgarzik> TD, where "maxing out their blocks" == 500k?
631 2013-08-12 13:32:14 <TD> jgarzik: it'd be nice if there was a way to change command line parameters at runtime
632 2013-08-12 13:32:15 <TD> jgarzik: yeah
633 2013-08-12 13:32:39 <handle> gmaxwell: yeah
634 2013-08-12 13:32:39 <jgarzik> TD, (re cmd line) you talking about rngd or bitcoind?
635 2013-08-12 13:32:54 <TD> bitcoind
636 2013-08-12 13:33:22 <gmaxwell> TD: IIRC there is some code to log the priorities but it's hidden behind a switch or commeted out or something.
637 2013-08-12 13:33:27 <TD> yeah -printpriorities
638 2013-08-12 13:33:38 <gmaxwell> Luke has a patch to let you rpc set priorities which is pretty nice (as a miner, at least)
639 2013-08-12 13:34:04 <gmaxwell> also, wizkid057/luke do generally take requests to bump up specific transactions.
640 2013-08-12 13:34:18 <gmaxwell> though thats only a few percent of hashrate.
641 2013-08-12 13:34:42 <TD> i'm more interested in improving my understanding at the moment
642 2013-08-12 13:35:01 <gmaxwell> Though, uh, if this android wallet sweeping stuff is not doing size proportional fees, then thats not going to get processed too quickly I expect. Miners priortize fee bearing transactions in order of fee per kb.
643 2013-08-12 13:35:06 <TD> e.g. there are 2000 txns in my mempool, a block gets 200 put in. so what happened to the other 90%. if i set the block size to X, how many would get in, etc.
644 2013-08-12 13:35:09 <CodeShark> ACTION considers writing a tool to display mempool transactions and dependencies
645 2013-08-12 13:35:16 <TD> it pays the min fee * kilobytes
646 2013-08-12 13:35:19 <TD> so it's size proportional
647 2013-08-12 13:35:20 <gmaxwell> cool.
648 2013-08-12 13:35:22 <TD> CodeShark: pleeeeeeeeeease :)
649 2013-08-12 13:35:35 <TD> did anyone else get a rather phishy-looking mail that claims to be from theymos just now?
650 2013-08-12 13:36:07 <gmaxwell> Nope.
651 2013-08-12 13:36:44 <TD> it's begging for donations and has a static address in it. god, payment protocol can't come soon enough
652 2013-08-12 13:38:03 <gmaxwell> he's about the last person I'd expect to see with beg emails.
653 2013-08-12 13:38:27 <TD> exactly
654 2013-08-12 13:39:51 <TD> besides, i know theymos is sitting on a massive pile of funds for the forum. it has no need for any further funding
655 2013-08-12 13:40:19 <gmaxwell> Yea thats what I mean mostly.
656 2013-08-12 13:40:57 <gmaxwell> hopefully all forum members will get passes to the forum owned space station after bitcoin really takes off. :P
657 2013-08-12 13:41:47 <Cusipzzz> lol
658 2013-08-12 13:42:42 <gmaxwell> wait. I don't think I'd want to be locked in a flying can with these people. Nevermind!
659 2013-08-12 13:56:22 <petertodd> TD
660 2013-08-12 13:56:32 <TD> petertodd
661 2013-08-12 13:56:33 <petertodd> TD: my mempool patch actually does pretty close to that, shows fee/kb
662 2013-08-12 13:56:37 <TD> nice
663 2013-08-12 13:56:49 <petertodd> TD: had to include that for debugging after all...
664 2013-08-12 13:58:30 <petertodd> the bitcointalk donations fund is damn near big enough to hire a developer to make a distributed bitcointalk from the sounds of it
665 2013-08-12 13:59:27 <Cusipzzz> big enough * 3, it's huge.
666 2013-08-12 14:06:25 <maaku> anyone know if there are homomorphic encryption schemes for elliptic curve?
667 2013-08-12 14:06:35 <maaku> i'm trying to figure out a way to do something like this : http://www.eecs.harvard.edu/~shieber/Biblio/Papers/icec06.pdf
668 2013-08-12 14:06:47 <sipa> for linear transformations :)
669 2013-08-12 14:07:14 <gmaxwell> sure. pretty easy to do some homomorphic encryption things with ecc.
670 2013-08-12 14:07:29 <gmaxwell> like if you want to encrypt points and then decrypt them in any order you like.
671 2013-08-12 14:07:38 <gmaxwell> and ... um. thats about it.
672 2013-08-12 14:07:40 <gmaxwell> :P
673 2013-08-12 14:08:00 <maaku> so no, then :P
674 2013-08-12 14:08:07 <gmaxwell> maaku: but why care about ECC? a secure auction thing doesn't have to use bitcoin's curve.
675 2013-08-12 14:08:19 <maaku> speed
676 2013-08-12 14:08:28 <TD> FHE is slow
677 2013-08-12 14:08:31 <TD> no way around that currently
678 2013-08-12 14:08:35 <TD> paillier is faster
679 2013-08-12 14:09:21 <maaku> i'm trying to find a minimal way to extend the bitcoin scripting language to support these auctions
680 2013-08-12 14:09:27 <maaku> TD: the paper uses paillier
681 2013-08-12 14:09:43 <gmaxwell> maaku: Thats probably not a grand idea.
682 2013-08-12 14:09:51 <maaku> not for bitcoin, but for a side-chain
683 2013-08-12 14:10:03 <gmaxwell> Usually you can do things external to the transactions, but then have a simple binding.
684 2013-08-12 14:10:12 <gmaxwell> And chains are seldom the right way to express a distributed system. :P
685 2013-08-12 14:10:13 <maaku> side-chain and/or bitmessage like system, for transmitting bids and reporting results
686 2013-08-12 14:10:55 <maaku> yeah maybe not, this is still exploratory...
687 2013-08-12 14:11:39 <gmaxwell> probably the most important thing to do is try something out and publish some code. If you do that maybe you'll change the norms and other people working on these things will publish code too.
688 2013-08-12 14:12:45 <gmaxwell> It's seriously screwed up, in my opinion, that I can't just go grab some code off freshmeat, say ??? and conduct a secure secret ballot election with my friends on IRC. ... lots of great protocols for things have been described, but implementations ??? even unfriendly ones??? are nonexistant.
689 2013-08-12 14:13:36 <petertodd> gmaxwell: As barbie says, math is hard.
690 2013-08-12 14:13:39 <jgarzik> Whoops. Popped a breaker. Gotta turn off the least efficient miner for now (avalon #1).
691 2013-08-12 14:13:45 <gmaxwell> hahah
692 2013-08-12 14:13:56 <petertodd> gmaxwell: You see the same thing with CAD software, both mechanical and electrical.
693 2013-08-12 14:14:01 <gmaxwell> jgarzik: yea, "rebalancing the circuts dance" time.
694 2013-08-12 14:14:10 <jgarzik> Was accompanied by a *foomp* sound, suspiciously like a flame-related sound perhaps.
695 2013-08-12 14:14:23 <jgarzik> Nothing /smells/ burnt...
696 2013-08-12 14:14:25 <petertodd> ACTION wishes he had to rebalance circuits for his mining rig...
697 2013-08-12 14:14:38 <petertodd> jgarzik: circuit breakers do that when they pop under load, no big deal
698 2013-08-12 14:14:39 <gmaxwell> jgarzik: it's normal for the breakers to make a foomp.
699 2013-08-12 14:14:58 <petertodd> jgarzik: yeah, it's a persistant crackle that you should be worried about...
700 2013-08-12 14:15:07 <jgarzik> and associated smoke ;p
701 2013-08-12 14:15:17 <Cusipzzz> if no ball of flame came down the hallway, you should be ok
702 2013-08-12 14:15:27 <gmaxwell> this is how you end up with miners in three rooms of your house.
703 2013-08-12 14:15:39 <petertodd> Cusipzzz: I'm sure jgarzik cares more about the miners...
704 2013-08-12 14:16:34 <petertodd> TD: you know, getblocktemplate does what you want re: tx's actually...
705 2013-08-12 14:16:54 <jgarzik> Although this would be quite inefficient, mining is still profitable enough to rent a crappy out-of-town apartment for each 1-2 miners
706 2013-08-12 14:17:00 <jgarzik> distributed data center
707 2013-08-12 14:18:06 <gmaxwell> ::knock:: ::knock:: "Free heater installation crew, reporting for your install!" "Uh, but I didn't order a heater!" "It's free!"
708 2013-08-12 14:18:23 <Diablo-D3> https://github.com/philipl/pifs
709 2013-08-12 14:18:25 <maaku> gmaxwell: agreed. i was hesitant to work on something
710 2013-08-12 14:18:40 <maaku> something where there wasn't already good crypto
711 2013-08-12 14:19:07 <jgarzik> need a good mining-over-unreliable connections (3G/4G) protocol, something less connection-oriented than stratum
712 2013-08-12 14:19:16 <maaku> but maybe I should just publish something with warnings not to use it, and let people rip it apart to make it better
713 2013-08-12 14:19:19 <jgarzik> to avoid having to run wires
714 2013-08-12 14:19:28 <TD> petertodd: well yeah, not exactly easy to work with though :)
715 2013-08-12 14:19:34 <gmaxwell> maaku: a lot of papers have been written on all sorts of neat things in this space (elections and auctions are closely related problems), so no shortage of things to try.
716 2013-08-12 14:19:58 <gmaxwell> maaku: a lot of people aren't even aware of what is possible, more could probably get done if people's eyes were opened to the possibilities.
717 2013-08-12 14:20:11 <jgarzik> maaku, auctions would be a great problem to solve
718 2013-08-12 14:20:17 <TD> hmm, odd
719 2013-08-12 14:20:28 <TD> i set my blockmaxsize to 1mb and the biggest block it'll make is 423kb
720 2013-08-12 14:20:49 <jgarzik> essentially the bidder needs to escrow some funds, and a notary must timestamp/verify highest bids, and end of auction.
721 2013-08-12 14:20:58 <maaku> jgarzik: http://www.eecs.harvard.edu/~shieber/Biblio/Papers/icec06.pdf
722 2013-08-12 14:21:03 <maaku> jgarzik: http://www.eecs.harvard.edu/econcs/pubs/fc_ccpa.pdf
723 2013-08-12 14:21:04 <jgarzik> and the latter must stand up to end-of-auction assault.
724 2013-08-12 14:21:20 <maaku> as far as I can tell, those both pretty well solve auctions for practical applications
725 2013-08-12 14:21:23 <jgarzik> you can always make a centralized auction robot, but how to decentralize?
726 2013-08-12 14:21:52 <maaku> jgarzik: hence my interest in adding the homomorphic encryption necessary to support these in bitcoin scripts
727 2013-08-12 14:22:19 <maaku> jtimon and I already have a proposal that adds english, dutch and double auctions
728 2013-08-12 14:22:21 <jgarzik> ACTION is far from convinced that is the direction to go
729 2013-08-12 14:22:28 <nsh> gmaxwell, you want a secure decentralized multiparty computation framework?
730 2013-08-12 14:22:50 <nsh> i'll see what i can knock up over the weekend lol
731 2013-08-12 14:22:55 <maaku> this would add vickrey auctions
732 2013-08-12 14:23:19 <jgarzik> gmaxwell, (RE opened to possibilities) that's why I think demos are now important. People just don't know what's possible, or don't understand how to accomplish these things discussed in academic papers or wiki.
733 2013-08-12 14:23:34 <jgarzik> a simple 100-line demo of a concept can go a long way, IMO
734 2013-08-12 14:23:50 <jgarzik> (though certainly auctions are far more than 100 lines)
735 2013-08-12 14:24:40 <maaku> jgarzik: it's more of a zerocoin-like addition. way too big to ever become part of bitcoin core
736 2013-08-12 14:24:57 <maaku> but you could have an auction side-chain and use cross-chain trade to settle
737 2013-08-12 14:25:22 <gmaxwell> gah with the "chain"s.
738 2013-08-12 14:25:32 <gmaxwell> There isn't a need to invoke chains for everything. :P
739 2013-08-12 14:26:21 <gmaxwell> and the best evidence available (altcoins) suggests that blockchain consensus sidechains are unlikely to provide (much?) security.
740 2013-08-12 14:26:36 <maaku> gmaxwell: agreed in principle, but how do you get people to commit their bids before the auction closes?
741 2013-08-12 14:26:44 <jgarzik> gmaxwell, nonetheless it is a useful decentralized, replicated database system :)
742 2013-08-12 14:27:06 <gmaxwell> maaku: the person with the goods under auction timestamps blinded bids.
743 2013-08-12 14:27:07 <jgarzik> massively replicated, eventual consistency, with built-in numeric tokens
744 2013-08-12 14:27:36 <gmaxwell> maaku: the bids are unsealed after the deadline.
745 2013-08-12 14:27:46 <Cusipzzz> ...until NY state shuts it down :)
746 2013-08-12 14:29:17 <jgarzik> need RPC ProveIControlABalance($amount), that spits out a signed message covering sufficient txouts/keys for $amount
747 2013-08-12 14:29:24 <gmaxwell> maaku: another form (that also works for elections) is you agree on bidders in advance, and restart the auction if a bidder drops out. Not quite the same thing as an open ended auction that runs for days, but also a potential model.
748 2013-08-12 14:29:31 <jgarzik> maybe associated with lockunspent use
749 2013-08-12 14:29:33 <maaku> jgarzik: working on that ;)
750 2013-08-12 14:30:09 <jgarzik> also, lockunspent needs wallet support for persistance
751 2013-08-12 14:30:48 <gmaxwell> yea, non-persistance of that is a bit lameo. also it needs labels on the locks if its persistant.
752 2013-08-12 14:31:05 <maaku> gmaxwell: yes but I think we're saying the same thing, except that I would prefer a solution with bid privacy (hence the homomorphic encryption)
753 2013-08-12 14:31:10 <gmaxwell> but we don't even have coin control merged yet. :(
754 2013-08-12 14:31:20 <gmaxwell> Did we lose all our GUI contributors? :(