1 2013-08-20 00:45:22 <k9quaint> gmaxwell: oh you fiend! you locked a new BFL thread :(
2 2013-08-20 00:47:55 <gmaxwell> k9quaint: why cry, there were ten more made while you wrote that complaint?
3 2013-08-20 01:00:27 <k9quaint> gmaxwell: I have found a way to harness BFL threads to generate power
4 2013-08-20 01:01:17 <Diablo-D3> k9quaint: hows this
5 2013-08-20 01:01:25 <Diablo-D3> you can shut the fuck up and stop talking about bfl.
6 2013-08-20 01:01:27 <Diablo-D3> because honestly
7 2013-08-20 01:01:32 <Diablo-D3> Im tired of hearing those three letters
8 2013-08-20 01:02:39 <k9quaint> ok
9 2013-08-20 01:02:43 <k9quaint> but only since you asked nicely
10 2013-08-20 01:37:54 <warren> I'm giving a public talk explaining Bitcoin tech tomorrow. Any info graphics, slides or videos you folks recommend that I can reuse?
11 2013-08-20 04:08:24 <warren> Regarding, the MacOS X leveldb corruption: https://code.google.com/p/leveldb/issues/detail?id=197
12 2013-08-20 04:08:44 <warren> Dana Powers says this patch will "significantly degrade performance as F_FULLFSYNC will force all buffers to write, including those unrelated to leveldb"
13 2013-08-20 04:11:54 <gmaxwell> OSX bitcoin is nearly unusable now, nothing could be worse, and I wouldn't be surprised if the performance hit wasnt that interesting for our workload. it's hard to have worse performance than needing a full resync.
14 2013-08-20 04:15:57 <phantomcircuit> warren, relative to osx relative to linux performance should be the exact same
15 2013-08-20 04:16:27 <phantomcircuit> there's a lot of os x benchmarks which use fsync/fdatasync that show osx being miraculously fast
16 2013-08-20 04:47:14 <warren> phantomcircuit: ok good to hear that mac is fake. It confirms my worldview.
17 2013-08-20 05:05:39 <sipa> warren, gmaxwell: i think it will not
18 2013-08-20 05:05:48 <sipa> we rarely fsync
19 2013-08-20 05:06:38 <sipa> Luke-Jr: every 100s IIRC
20 2013-08-20 06:36:41 <bitexchanger> Any devs here?
21 2013-08-20 06:37:17 <bitexchanger> If someone gives you a raw transaction, is there any way to broadcast it?
22 2013-08-20 06:39:35 <gmaxwell> bitexchanger: I'm curious how you attempted to answer this question before asking here? (so we can improve documentation, of course)
23 2013-08-20 06:40:23 <gmaxwell> ;;lmgtfy bitcoin broadcast raw transaction
24 2013-08-20 06:40:24 <gribble> http://lmgtfy.com/?q=bitcoin%20broadcast%20raw%20transaction
25 2013-08-20 06:42:12 <bitexchanger> dilemma: someone tried to withdraw btc from gox
26 2013-08-20 06:42:14 <bitexchanger> 7 days ago..
27 2013-08-20 06:43:06 <gmaxwell> bitexchanger: gox's withdraw page says that if the txn doesn't show up in 24 hours, nag them.
28 2013-08-20 06:43:25 <bitexchanger> gmaxwell: this has been 7 days
29 2013-08-20 06:43:32 <bitexchanger> it didnt show up because he forgot to put a transaction fee
30 2013-08-20 06:43:36 <bitexchanger> I talked to magicaltux today
31 2013-08-20 06:43:43 <bitexchanger> and he said that it wasnt processed because there was no fee added
32 2013-08-20 06:43:52 <bitexchanger> and he sent me the raw transaction copy and pasted
33 2013-08-20 06:46:10 <MagicalTux> [17:37:17] <bitexchanger> If someone gives you a raw transaction, is there any way to broadcast it? <- sendrawtransaction ?
34 2013-08-20 06:46:28 <bitexchanger> MagicalTux: Canyou just rebroadcast it please?
35 2013-08-20 06:46:30 <bitexchanger> or send it with a fee?
36 2013-08-20 06:46:53 <gmaxwell> bitexchanger: that google result I gave you gives you several solutions including multiple webpages that will do it for you.
37 2013-08-20 06:47:13 <MagicalTux> bitexchanger, we are broadcasting it all the time, but it doesn't go through because of the lack of fees
38 2013-08-20 06:47:17 <MagicalTux> would need help from a miner
39 2013-08-20 06:47:28 <bitexchanger> So can you put a fee on it?
40 2013-08-20 06:47:52 <bitexchanger> How am i supposed to add a fee to it when it has been sitting in gox for 7 days?
41 2013-08-20 06:48:02 <gmaxwell> MagicalTux: in seven days? bitexchanger do you mind sharing this txid with me?
42 2013-08-20 06:48:52 <bitexchanger> MagicalTux has it handy... I don't have access to it right now
43 2013-08-20 06:54:55 <gmaxwell> ::sigh::
44 2013-08-20 06:54:58 <gmaxwell> 01:45:10.433 [New I/O worker #10] INFO c.g.bitcoin.core.AbstractBlockChain - 184 blocks per second
45 2013-08-20 06:54:58 <gmaxwell> multibit
46 2013-08-20 06:55:02 <gmaxwell> 01:45:11.139 [New I/O worker #10] INFO c.g.bitcoin.core.AbstractBlockChain - Connected 1 orphan blocks.
47 2013-08-20 06:55:12 <gmaxwell> and then it just stops and doesn't ever seem to fetch blocks anymore.
48 2013-08-20 06:55:50 <gmaxwell> (if it gets a new block announcement while its in the middle of syncing)
49 2013-08-20 07:34:31 <gmaxwell> ==9715== at 0x5E7568: CWallet::GenerateNewKey() (wallet.cpp:47)
50 2013-08-20 07:34:31 <gmaxwell> ==9715== by 0x5E7B26: CWallet::TopUpKeyPool(unsigned int) (wallet.cpp:1576)
51 2013-08-20 07:34:31 <gmaxwell> ==9715== Conditional jump or move depends on uninitialised value(s)
52 2013-08-20 07:34:31 <gmaxwell> random tidbit, test_bitcoin is not valgrind clean at:
53 2013-08-20 07:34:34 <gmaxwell> ==9715== by 0x5E7ECC: CWallet::ReserveKeyFromKeyPool(long long&, CKeyPool&) (wallet.cpp:1593)
54 2013-08-20 07:36:25 <sipa> hmm
55 2013-08-20 07:38:25 <gmaxwell> ==9715== by 0x4745CD: miner_tests::CreateNewBlock_validity_invoker() (miner_tests.cpp:50)
56 2013-08-20 07:38:33 <gmaxwell> (might have helped if I gave the specific test!)
57 2013-08-20 07:39:54 <sipa> if (!nTimeFirstKey || nCreationTime < nTimeFirstKey)
58 2013-08-20 07:39:54 <sipa> ^- that line
59 2013-08-20 07:40:31 <sipa> my guess: we don't initialize nTimeFirstKey if a wallet isn't loaded from a file
60 2013-08-20 07:40:56 <TD> yup
61 2013-08-20 08:22:36 <jgarzik> sipa, indeed
62 2013-08-20 08:25:42 <jgarzik> warren, (RE ubuntu/fedora men usage) might be BDB library
63 2013-08-20 08:26:13 <jgarzik> warren, (RE disable wallet) getblocktemplate must be disabled without a wallet, because it requires a wallet key to generate a block
64 2013-08-20 08:26:21 <warren> jgarzik: oh, I should try disable-wallet
65 2013-08-20 08:26:49 <warren> jgarzik: hmm, any way around this? pools don't need to generate to an address that itself controls.
66 2013-08-20 08:27:15 <jgarzik> warren, sure there is always a way around anything -- just needs coding, hence the TODO ;p
67 2013-08-20 08:27:44 <jgarzik> warren, CreateNewBlock() takes a key argument, and need not. getblocktemplate would require specification changes, though.
68 2013-08-20 08:28:16 <warren> jgarzik: priv
69 2013-08-20 08:31:06 <gmaxwell> "getblocktemplate would require specification changes, though."
70 2013-08-20 08:31:07 <gmaxwell> huh?
71 2013-08-20 08:31:20 <gmaxwell> GBT in bitcoin doesn't send a coinbase transaction I thought, it's optional.
72 2013-08-20 08:31:30 <warren> or just overload it
73 2013-08-20 08:32:19 <gmaxwell> (in fact, I'm sure of it, I'm just being polite. :P )
74 2013-08-20 08:34:08 <jgarzik> gmaxwell, the code differs from your opinion of the specification...
75 2013-08-20 08:34:42 <warren> Is there a way to reindex at a certain point, not the entire chain?
76 2013-08-20 08:35:13 <warren> jgarzik: important question in priv re bitpay and public talk I'm doing tomorrow
77 2013-08-20 08:35:28 <jgarzik> gmaxwell, the coinbase transaction is not sent back verbatim, but several bits of the coinbase are sent back nonetheless
78 2013-08-20 08:35:36 <gmaxwell> jgarzik: IIRC it uses createnew block, so that code expects a wallet, but it doesn't actually emit a coinbase transaction, so no spec anything is required.
79 2013-08-20 08:35:38 <jgarzik> gmaxwell, thus it is needed
80 2013-08-20 08:35:48 <jgarzik> gmaxwell, not correct. read the code...
81 2013-08-20 08:36:22 <Luke-Jr> jgarzik: getblocktemplate doesn't require a key
82 2013-08-20 08:36:23 <gmaxwell> jgarzik: I think we're suffering a communications failure here, and perhaps aren't in disagreement.
83 2013-08-20 08:36:31 <Luke-Jr> jgarzik: bitcoind's implementation doesn't even use it
84 2013-08-20 08:36:45 <jgarzik> Please read the code
85 2013-08-20 08:36:58 <warren> jgarzik: any ideas what we can do about the huge memory difference in fedora?
86 2013-08-20 08:36:59 <Luke-Jr> I know it uses it in code, but it discards that before it returns
87 2013-08-20 08:37:08 <gmaxwell> jgarzik: My belief is that the software uses the wallet because it calls createnewblock. But it doesn't actually emit any data in the output of the rpc.
88 2013-08-20 08:37:11 <Luke-Jr> once getwork and BitcoinMiner are gone, that can go away too
89 2013-08-20 08:37:16 <gmaxwell> And I've read this code.
90 2013-08-20 08:37:44 <jgarzik> "doesn't need key" != "doesn't send back coinbase data"
91 2013-08-20 08:38:19 <gmaxwell> jgarzik: This is a communications failure, I was attempting to respond to your initial assertion and I spoke unclearly. Sorry.
92 2013-08-20 08:38:35 <gmaxwell> 03:26 < jgarzik> warren, (RE disable wallet) getblocktemplate must be disabled without a wallet, because it requires a wallet key to generate a block
93 2013-08-20 08:38:38 <gmaxwell> 03:27 < jgarzik> warren, CreateNewBlock() takes a key argument, and need not. getblocktemplate would require specification changes, though.
94 2013-08-20 08:38:53 <gmaxwell> No need for a specification change. Just some code tinkering.
95 2013-08-20 08:38:55 <Luke-Jr> I'm not aware of any coinbase data that comes from bitcoind's GBT RPC
96 2013-08-20 08:39:05 <gmaxwell> Luke-Jr: e.g. the height and such, no wallet data.
97 2013-08-20 08:39:11 <jgarzik> Luke-Jr, you need to read the code, then
98 2013-08-20 08:39:17 <Luke-Jr> gmaxwell: that's not really coinbase data :/
99 2013-08-20 08:39:30 <gmaxwell> Luke-Jr: yea, but it's what jeff is referring to here.
100 2013-08-20 08:39:53 <jgarzik> gmaxwell, as stated in the pull request and much earlier in IRC, createNewBlock() may be updated to take a coinbase parameter not a key, to solve the issue
101 2013-08-20 08:40:13 <Luke-Jr> bitcoind's GBT code doesn't get the height from the coinbase either
102 2013-08-20 08:40:14 <jgarzik> gmaxwell, so perhaps this is just a restatement of what was already mentioned in the pull request days ago
103 2013-08-20 08:40:49 <gmaxwell> Luke-Jr: IIRC we do get the value from it, no?
104 2013-08-20 08:41:04 <Luke-Jr> gmaxwell: no, that code predates height-in-cb
105 2013-08-20 08:41:53 <gmaxwell> jgarzik: yep. Sounds fine to me. Sorry, just saw comments on 'spec change'. ... I actually do wish to, some extent, that GBT in bitcoind actually emitted a coinbase transaction. ... since con has not been willing to add coinbase creation to cgminer. Not exactly the most important feature.
106 2013-08-20 08:43:40 <gmaxwell> (and since nothing except some crazy solo miner would use that??? uh. "more niche code we don't really need")
107 2013-08-20 08:45:06 <warren> jgarzik: wait a minute, would the gitian static built BDB being the same between Ubuntu and Fedora explain the huge memory difference?
108 2013-08-20 08:45:10 <jgarzik> gmaxwell, BIP 22 does mention coinbasetxn, though we do not send it back
109 2013-08-20 08:45:22 <jgarzik> warren, shouldn't...
110 2013-08-20 08:45:32 <jgarzik> warren, but it depends on version etc.
111 2013-08-20 08:45:47 <jgarzik> gmaxwell, we just send back coinbaseaux and coinbasevalue
112 2013-08-20 08:45:55 <sipa> so, sounds like we should just send a dummy key to createnewblock in GBT
113 2013-08-20 08:45:57 <jgarzik> both of which are taken from coinbase TX
114 2013-08-20 08:46:11 <jgarzik> sipa, I was thinking EFF pubkeyhash :)
115 2013-08-20 08:46:14 <warren> jgarzik: the very same standard gitian built-binary running on Ubuntu and Fedora, like 200MB difference in memory use.
116 2013-08-20 08:46:24 <warren> jgarzik: both have wallets with no transactions
117 2013-08-20 08:46:28 <sipa> what does the electronic frontier foundation have to do with it?
118 2013-08-20 08:46:36 <Luke-Jr> sipa: no need, and just slows things down in bitcoind (we'd have to get rid of some caching stuff)
119 2013-08-20 08:46:44 <sipa> ok
120 2013-08-20 08:46:45 <gmaxwell> If we want a dummy value to use in coinbase transactions, it should probably be an anyone can spend output. "free coins for the next miner" :P
121 2013-08-20 08:47:00 <sipa> Luke-Jr, jgarzik: you're probably both more familiar with the code than i am
122 2013-08-20 08:47:44 <gmaxwell> (free coins, is probably the least politically complicated option. Personally I say we just put one of Sipa's address there. :P)
123 2013-08-20 08:48:03 <warren> gmaxwell: entirely appropriate for the dummy value to go to <charity that everyone likes>. It's the miner's own fault for not setting the actual target address in their miner, pretty implausible for this to matter.
124 2013-08-20 08:48:04 <jgarzik> bikeshedding at any rate? the key is discarded
125 2013-08-20 08:48:09 <sipa> NO ADDRESS REUSE!!!11
126 2013-08-20 08:48:15 <jgarzik> after CreateNewBlock() uses it
127 2013-08-20 08:48:17 <sipa> oh, wait, BIP32 code was merged :p
128 2013-08-20 08:48:40 <gmaxwell> warren: the only totally neutral charity is transaction fees. :P
129 2013-08-20 08:48:45 <Luke-Jr> fwiw, I don't think BFGMiner will override a coinbasetxn if present, at the moment.
130 2013-08-20 08:48:55 <jgarzik> sipa, what warren said :) But since the value is actually discarded, it's more a fun message than anything relevant
131 2013-08-20 08:48:56 <warren> gmaxwell: ok then.
132 2013-08-20 08:49:27 <sipa> gmaxwell: i'd say that OP_FALSE is even more neutral :)
133 2013-08-20 08:49:29 <warren> I demand blue, BTW.
134 2013-08-20 08:49:30 <Luke-Jr> ACTION doesn't see a reason to initialize a value that is never used
135 2013-08-20 08:49:49 <gmaxwell> sipa: people get kinda spazzy about "destroying coins"
136 2013-08-20 08:50:22 <jgarzik> the internal miner still provides a useful key to CreateNewBlock(). getblocktemplate need only provide a dummy value. Therefore, the suggestion in the pull request since pull req was created -- provide the txout, and remove the key argument from CreateNewBlock()
137 2013-08-20 08:50:33 <Luke-Jr> jgarzik: so we're not removing the internal miner?
138 2013-08-20 08:50:47 <jgarzik> <shrug> I don't want to, gmaxwell does
139 2013-08-20 08:50:55 <gmaxwell> Luke-Jr: I'm a moron, mostly.
140 2013-08-20 08:51:00 <Luke-Jr> O.o
141 2013-08-20 08:51:11 <gmaxwell> I just assumed that jgarzik's patch would do that, because if you don't removing getwork removes very little code.
142 2013-08-20 08:51:13 <sipa> who are you, and what have you done to gmaxwell?
143 2013-08-20 08:51:26 <gmaxwell> And a moment after posting with that assumption I went and read the actual patch.
144 2013-08-20 08:51:36 <gmaxwell> And I've been trying to get this brown paper bag off my head ever since.
145 2013-08-20 08:51:41 <warren> I don't care if the internal miner is removed. I do want -disable-wallet with working GBT.
146 2013-08-20 08:52:11 <gmaxwell> Though I am in favor of removing the internal one, ??? and also packaging up a miner that uses GBT so that all testing is on one set of code paths. But I do not think it either important or urgent.
147 2013-08-20 08:52:17 <Luke-Jr> IMO removing the internal miner is just one step toward splitting up the codebase
148 2013-08-20 08:52:34 <sipa> if people object to distributing a fully-fledged miner, it's not hard to include a very simplistic one that is not worse than the internal one, i guess?
149 2013-08-20 08:52:44 <sipa> ah right, it needs GBT support of course
150 2013-08-20 08:52:50 <Luke-Jr> no reason to include a miner with node/wallet
151 2013-08-20 08:53:04 <warren> with bfgminer and pooler's CPU minerd both doing auto-mining with RPC auth from ~/.bitcoin/bitcoin.conf, the laziness factor can be explained away.
152 2013-08-20 08:53:12 <jgarzik> Luke-Jr, for test net, there is
153 2013-08-20 08:53:20 <Luke-Jr> jgarzik: there is?
154 2013-08-20 08:53:38 <Luke-Jr> what makes using another program so much harder for testnet? :x
155 2013-08-20 08:53:41 <warren> jgarzik: less code in bitcoind is win
156 2013-08-20 08:54:12 <gmaxwell> sipa: yea, mostly I think a complete miner is a solved problem. We could strip one down, but then have more stuff to maintain.
157 2013-08-20 08:54:44 <Luke-Jr> warren: auto-mining might not be as simple as you think. one problem to address is coordinating extranonces across potentially infinite systems that don't talk to each other..
158 2013-08-20 08:55:18 <warren> Luke-Jr: and this matters to how many people?
159 2013-08-20 08:55:22 <gmaxwell> if you just have users providing a non-unique address to pay to, you do have to take care to avoid duplicating work.
160 2013-08-20 08:55:27 <Luke-Jr> node, blockstore, wallet, GUI, miner <-- 5 pieces that IMO should be independent eventually
161 2013-08-20 08:55:34 <gmaxwell> warren: once you include the software, well, it ought to not be a trap.
162 2013-08-20 08:55:36 <Luke-Jr> warren: anyone solo mining from more than one machine
163 2013-08-20 08:55:48 <warren> argh.
164 2013-08-20 08:56:24 <warren> jgarzik: I suppose you're busy, but really hoping for an answer re bitpay live demo for my talk tomorrow.
165 2013-08-20 08:56:26 <Luke-Jr> it'd be nice if systems had a UUID we could just hash
166 2013-08-20 08:56:56 <Luke-Jr> but I didn't see a portable simple way to do that
167 2013-08-20 08:57:14 <gmaxwell> Luke-Jr: really just grabbing 32 bits of entropy from the rng every new block and using that is probably adequate.
168 2013-08-20 08:57:35 <Luke-Jr> gmaxwell: portable RNG isn't exactly simple either :|
169 2013-08-20 08:57:47 <gmaxwell> esp since the liklyhood of seperate nodes having absolutely identical blocks already is somewhat low.
170 2013-08-20 08:58:46 <Luke-Jr> unless they run Android
171 2013-08-20 08:58:48 <Luke-Jr> ACTION ducks
172 2013-08-20 08:59:13 <gmaxwell> :P
173 2013-08-20 09:34:45 <petertodd> jgarzik: you're fast
174 2013-08-20 09:35:47 <jgarzik> petertodd, alas, pynode isn't
175 2013-08-20 09:36:11 <jgarzik> petertodd, signaturehash really needs to hash as a stream, rather than deep copying, editing, and hashing
176 2013-08-20 09:36:24 <jgarzik> petertodd, would make everything much faster, from pynode on down
177 2013-08-20 09:36:39 <petertodd> jgarzik: yeah, and I'm disappointed Cython scared me off with a compiler bug :(
178 2013-08-20 09:36:47 <jgarzik> or just do it in C/C++
179 2013-08-20 09:37:58 <petertodd> jgarzik: heh, well... pythonizing C/C++ libraries isn't anywhere near as painful as you'd expect
180 2013-08-20 09:38:04 <petertodd> good excuse to make a library out of bitcoin
181 2013-08-20 09:38:12 <sipa> ACTION murmurs something about #2645
182 2013-08-20 09:38:40 <Luke-Jr> sipa: for Python?
183 2013-08-20 09:39:03 <sipa> you can copy the logic
184 2013-08-20 09:39:19 <sipa> i don't mean this particular implementation, but the algorithm is tested at least
185 2013-08-20 09:39:38 <Luke-Jr> ACTION wonders if Python supports hashing a stream O.o
186 2013-08-20 09:40:25 <petertodd> sipa: and the python library already has enough bugs that weren't not too worried if it doesn't work :/
187 2013-08-20 09:40:58 <petertodd> Luke-Jr: the hashing libraries probably optimize that case...
188 2013-08-20 09:41:17 <jgarzik> petertodd, if you could find time to import bitcoind unit tests and get those working, that would have community-wide benefit?
189 2013-08-20 09:41:29 <jgarzik> [in python-bitcoinlib, I mean]
190 2013-08-20 09:42:44 <petertodd> jgarzik: yeah, the "get them working" is the hardest part
191 2013-08-20 09:43:15 <petertodd> jgarzik: I've got code to run the scripting tests, but so much of that fails... I dunno, I think EvalScript() in libraries is dangerous
192 2013-08-20 09:44:02 <jgarzik> Luke-Jr, The speed would be obtained from doing small encode+hash bits just like in sipa's recent C++ SignatureHash update? Hashing to a stream is more a figure of speech, not a specific technical need. python can do what this bitcoin problem requires.
193 2013-08-20 09:44:35 <jgarzik> petertodd, it needs to be correct. even SPV wallets doing transaction signing should be performing a quick script test before sending the TX out the door.
194 2013-08-20 09:45:08 <petertodd> jgarzik: yeah, but that stuff can be special-cased / stripped down versions - no need to claim you've gotten CODESEPARATOR right for instance
195 2013-08-20 09:46:01 <jgarzik> petertodd, on a practical level, it is fine to (say) import the script tests, and then comment out specific cases that aren't passing tests just yet
196 2013-08-20 09:46:38 <jgarzik> petertodd, it then becomes an iteractive process, working on individual tests. something that can be done by multiple programmers in paralle, once initial import is complete.
197 2013-08-20 09:46:49 <petertodd> jgarzik: on a practical level, I'll have to change the script test case format so you even can comment out tests :P
198 2013-08-20 09:47:15 <petertodd> jgarzik: parallelism is good though
199 2013-08-20 09:47:47 <sipa> it is webscale
200 2013-08-20 09:47:54 <petertodd> ...
201 2013-08-20 09:48:05 <jgarzik> *iterative
202 2013-08-20 09:48:09 <sipa> (sorry, couldn't resist)
203 2013-08-20 09:48:15 <jgarzik> ACTION -> too little sleep
204 2013-08-20 09:48:22 <petertodd> clouds... ever noticed how there are lots of them? all, like, next to each other? in layers? that's webscale man
205 2013-08-20 09:48:28 <sipa> and cloud computing
206 2013-08-20 09:48:28 <sipa> needs virtual machines though
207 2013-08-20 09:48:41 <jgarzik> nested virtual clouds
208 2013-08-20 09:48:57 <petertodd> ACTION wonders how fast python-bitcoinlib would run on a python interpreter implemented in python
209 2013-08-20 09:49:07 <jgarzik> petertodd, JSON data format needs a way to comment out sections
210 2013-08-20 09:49:09 <jgarzik> JSONpp
211 2013-08-20 09:49:17 <jgarzik> petertodd, I run into this problem again and again
212 2013-08-20 09:49:22 <petertodd> jgarzik: same
213 2013-08-20 09:49:32 <petertodd> jgarzik: json also needs to not suck, but I digress
214 2013-08-20 09:50:00 <jgarzik> petertodd, let's just declare a comment standard, e.g. ^\\s*\\/\\/
215 2013-08-20 09:50:09 <jgarzik> petertodd, and implement it into bitcoind and python-bitcoinlib
216 2013-08-20 09:51:13 <jgarzik> petertodd, JSON also needs to permit trailing commas on the last element in an array or dictionary
217 2013-08-20 09:51:23 <petertodd> jgarzik: easy enough to implement
218 2013-08-20 09:51:36 <petertodd> jgarzik: YES! god I hate languages that don't do that
219 2013-08-20 09:51:55 <jgarzik> makes patching a bitch; always must change a line that otherwise does not need changing
220 2013-08-20 09:52:08 <petertodd> yup
221 2013-08-20 09:52:09 <sipa> or insert at the start instead of at the end :)
222 2013-08-20 09:52:31 <jgarzik> sipa, it's crappy if your data format dictates your array order ;p
223 2013-08-20 09:52:59 <sipa> or have a dummy finalizer object in the array
224 2013-08-20 09:53:06 <sipa> *terminator
225 2013-08-20 09:57:53 <petertodd> jgarzik: FWIW I'm pretty confident that https://github.com/jgarzik/python-bitcoinlib/pull/6 is safe
226 2013-08-20 10:17:59 <petertodd> https://bitcointalk.org/index.php?topic=277595.msg2970668#msg2970668 <- blockchain.info is vulnerable to poor RNG generation
227 2013-08-20 10:18:33 <petertodd> only in signing tx's apparently, key generation is supposedly not affected
228 2013-08-20 10:19:10 <sipa> old news :)
229 2013-08-20 10:19:24 <sipa> they published an update, i saw on twitter
230 2013-08-20 10:19:40 <petertodd> er, perhaps I should make it clear: that's the link to piuk confirming it, and mentioning the fix
231 2013-08-20 10:19:51 <petertodd> I know there's been suspicions for, what, at least a day or three?
232 2013-08-20 10:20:59 <sipa> oh, ok :)
233 2013-08-20 10:22:33 <TD> "Users of the web interface should clear their browsers cache before next login."
234 2013-08-20 10:22:34 <TD> ??
235 2013-08-20 10:22:45 <TD> what is the point of a web app if you are required to clear the cache to get a new version of the site
236 2013-08-20 10:23:11 <sipa> i suppose a long cache TTL on javascript code?
237 2013-08-20 10:23:12 <petertodd> TD: it's more 2.0
238 2013-08-20 10:23:34 <petertodd> sipa: likely, could in theory help against attacks too
239 2013-08-20 10:24:42 <gmaxwell> you should say 'help with attacks', then it works better for "helps stop attacks" as well as "helps attacks be more potent" :P
240 2013-08-20 10:25:03 <petertodd> gmaxwell: lol, very true
241 2013-08-20 10:27:16 <TD> so it seems html5 lets you either have secure random numbers, or concurrency, but not both?
242 2013-08-20 10:28:10 <sipa> ....?
243 2013-08-20 10:48:04 <t7> use some non-standard html, render it in <canvas> get a hash of the the result. That is like 256bits of entropy right there
244 2013-08-20 11:53:01 <tcatm> Is there somebody who'd like to take over the transifex project for bitcoin-qt?
245 2013-08-20 11:54:57 <Luke-Jr> tcatm: I'd ask Diapolo, he seems into it
246 2013-08-20 11:55:09 <sipa> +1 for Diapolo
247 2013-08-20 11:56:43 <gmaxwell> from #avalon:
248 2013-08-20 11:56:44 <gmaxwell> 06:53 < r0sc0e> how can i solomine with avalons?
249 2013-08-20 11:56:44 <gmaxwell> 06:55 < conman> or use ozcoin's solopool
250 2013-08-20 11:56:44 <gmaxwell> 06:55 < conman> set up ppool software
251 2013-08-20 11:56:54 <gmaxwell> ... to solo mine, use a centeralized pool.
252 2013-08-20 11:57:06 <gmaxwell> Nice world we've ended up with here. :(
253 2013-08-20 11:57:13 <tcatm> Luke-Jr: Got an contact address?
254 2013-08-20 11:57:26 <Luke-Jr> tcatm: I'd check git log :P
255 2013-08-20 11:57:32 <Graet> it is seperate from the ozcoin pool
256 2013-08-20 11:58:03 <Graet> seem to be a lot of solo curious ppl, so we set something up for if they wanted to try
257 2013-08-20 11:58:10 <gmaxwell> Graet: I'm not criticizing you.
258 2013-08-20 11:58:36 <Graet> it's ok only 1 800mh miner has tried
259 2013-08-20 11:59:15 <kinlo> Graet: you have a "solopool" ? :)
260 2013-08-20 11:59:38 <TD> how does that work?
261 2013-08-20 12:00:07 <Cusipzzz> sounds like the worst of both worlds :)
262 2013-08-20 12:00:09 <kinlo> anyway, people should know that we're like 1% blocks found by solo's....
263 2013-08-20 12:00:13 <Luke-Jr> Graet: but it isn't solo
264 2013-08-20 12:00:38 <gmaxwell> I'm saying we've screwed up when someone has .1% of the network hashpower, and wants to solo, and the only things we can offer are "use a pool" or "use this centeralized service"
265 2013-08-20 12:00:46 <gmaxwell> Thats just busted.
266 2013-08-20 12:00:49 <Graet> no
267 2013-08-20 12:01:04 <kinlo> gmaxwell: well, what would you recommend?
268 2013-08-20 12:01:13 <kinlo> gmaxwell: besides p2pool
269 2013-08-20 12:01:15 <Graet> there are options fort ppl to solo, i offer a solo like sevice where the miner gets 24.5btc+1/2txn fees
270 2013-08-20 12:01:53 <kinlo> even with 500 GH you are just not enough to mine enough blcoks....
271 2013-08-20 12:01:53 <Luke-Jr> kinlo: real solo
272 2013-08-20 12:01:55 <jgarzik> for solo mining? I use eloipool locally
273 2013-08-20 12:01:57 <Graet> + stats etc they would normally need to setup themselves
274 2013-08-20 12:01:58 <TD> gmaxwell: do you know what the cause of enormous amounts of whitespace after OTR messages can be? some people say they see it, and others don't
275 2013-08-20 12:02:01 <gmaxwell> kinlo: There is no straight forward suggestion to make, installing elopool is a mild pain depending on the persons system and technical background.
276 2013-08-20 12:02:17 <Graet> and technical background. << important point
277 2013-08-20 12:02:20 <gmaxwell> TD: I've never seen anyone report that. :( I saw your message on the otr list.
278 2013-08-20 12:02:22 <jgarzik> bfgminer -- I thought?? -- could solo mine straight to bitcoind
279 2013-08-20 12:02:25 <Luke-Jr> ^
280 2013-08-20 12:02:32 <gmaxwell> jgarzik: bfgminer can, yes.
281 2013-08-20 12:02:44 <kinlo> gmaxwell: every avalon can directly mine to GBT in bitcoind, no need to install pool software
282 2013-08-20 12:02:49 <TD> gmaxwell: how much whitespace is it supposed to add?
283 2013-08-20 12:02:55 <gmaxwell> kinlo: no, thats not true.
284 2013-08-20 12:02:57 <Luke-Jr> kinlo: only if they install bFGMiner
285 2013-08-20 12:03:01 <Luke-Jr> kinlo: cgminer doesn't support GBT
286 2013-08-20 12:03:09 <kinlo> gmaxwell: it's not a technical problem - it's a problem that solo mining with 500GH is just not enough...
287 2013-08-20 12:03:15 <TD> odd
288 2013-08-20 12:03:20 <TD> i can't see the whitespace in the gmail logs.
289 2013-08-20 12:03:27 <gmaxwell> kinlo: It's fine enough.
290 2013-08-20 12:03:29 <kinlo> it doesn't? I've been mining with cgminer with GBT in the past...
291 2013-08-20 12:03:40 <jgarzik> OH GOD PYTHON IS SO SLOW
292 2013-08-20 12:03:41 <gmaxwell> kinlo: not against bitcoind you haven't.
293 2013-08-20 12:03:45 <Luke-Jr> kinlo: it's broken in various subtle ways - I'm surprised you didn't see the errors on your pool
294 2013-08-20 12:03:47 <kinlo> gmaxwell: true...
295 2013-08-20 12:04:02 <kinlo> Luke-Jr: I've changed some eloi settings to avoid them....
296 2013-08-20 12:04:15 <kinlo> basicly, if d is an int, it seems to be working fine
297 2013-08-20 12:04:25 <jgarzik> Processing one block every 3-6 seconds, here. Go, pynode, go.
298 2013-08-20 12:04:38 <Luke-Jr> kinlo: d?
299 2013-08-20 12:04:44 <kinlo> difficulty
300 2013-08-20 12:04:45 <gmaxwell> kinlo: To be frank, your response was also dishonest, saying that someone could not make a profit with 500 GH solo mining. But thats another issue.
301 2013-08-20 12:04:48 <Luke-Jr> kinlo: lthat doesn't make sense
302 2013-08-20 12:04:51 <sipa> jgarzik: try this: http://abstrusegoose.com/219
303 2013-08-20 12:05:23 <Luke-Jr> kinlo: GBT doesn't have "difficulty", just "target", which is always an int
304 2013-08-20 12:06:10 <sipa> ;;genrate 500000
305 2013-08-20 12:06:11 <gribble> The expected generation output, at 500000.0 Mhps, given difficulty of 50810339.0483, is 4.94886007307 BTC per day and 0.206202503045 BTC per hour.
306 2013-08-20 12:06:11 <kinlo> gmaxwell: I understand your position, but I don't want to recommend someone that has spent thousands of dollars on mining hardware to go gamble with such high variance....
307 2013-08-20 12:06:25 <sipa> it's one block every 5 days?
308 2013-08-20 12:06:30 <gmaxwell> yea.
309 2013-08-20 12:06:35 <sipa> i guess that's on the border of acceptable variance
310 2013-08-20 12:06:36 <kinlo> gmaxwell: but perhaps I should have made that point more clear to the guy
311 2013-08-20 12:06:43 <gribble> The average time to generate a block at 300000.0 Mhps, given difficulty of 50810339.0483, is 1 week, 1 day, 10 hours, 4 minutes, and 0 seconds
312 2013-08-20 12:06:43 <jgarzik> ;;gentime 300000
313 2013-08-20 12:06:47 <jgarzik> that's me
314 2013-08-20 12:06:49 <kinlo> sipa: the border :)
315 2013-08-20 12:06:51 <gmaxwell> kinlo: Then say that you consider it risky. Do not tell an outright lie and say it is unprofitable.
316 2013-08-20 12:06:51 <kinlo> imho
317 2013-08-20 12:07:19 <jgarzik> ;;gentime 500000
318 2013-08-20 12:07:20 <gribble> The average time to generate a block at 500000.0 Mhps, given difficulty of 50810339.0483, is 5 days, 1 hour, 14 minutes, and 24 seconds
319 2013-08-20 12:07:29 <gmaxwell> Sorry for being harsh, I get that you were trying to speak simply. At the same time, as a pool operator I think you have biases that influence your simplficiations there. :)
320 2013-08-20 12:07:40 <gribble> The average time to generate a block at 10500.0 Mhps, given difficulty of 50810339.0483, is 34 weeks, 2 days, 13 hours, 20 minutes, and 7 seconds
321 2013-08-20 12:07:40 <sipa> ;;gentime 10500
322 2013-08-20 12:07:48 <sipa> ^ /me will not solo mine
323 2013-08-20 12:08:25 <kinlo> gmaxwell: I didn't say it was unprofitable, I said one needed many avalons to be profitable... if he only had one it did make sense...
324 2013-08-20 12:09:10 <gmaxwell> kinlo: the number of devices you have doesn't influence the profitablity on average.. just the variance.
325 2013-08-20 12:09:48 <gribble> The average time to generate a block at 333.0 Mhps, given difficulty of 50810339.0483, is 20 years, 40 weeks, 5 days, 2 hours, 6 minutes, and 14 seconds
326 2013-08-20 12:09:48 <jgarzik> ;;gentime 333
327 2013-08-20 12:09:57 <jgarzik> good ole block erupter
328 2013-08-20 12:10:00 <gmaxwell> hehe.
329 2013-08-20 12:10:06 <kinlo> gmaxwell: dunno, the variance is relevant.... especially with the predicted difficulties...
330 2013-08-20 12:10:38 <winbtc_moarrr> Can I ask, why is the bitcoin community so anti-litecoin?
331 2013-08-20 12:10:43 <gmaxwell> Man, I think Bitcoin is doing more to set back math understanding in this world than all the octal you could throw at a textbook.
332 2013-08-20 12:10:46 <petertodd> kinlo: only if you have a family to feed, or in general don't live on love
333 2013-08-20 12:11:13 <gmaxwell> kinlo: expectations are timeless. You can figure out your expected returns even if this were the last block to ever get mined being worked on right now.
334 2013-08-20 12:11:14 <sipa> jgarzik: mine is still somewhere in the US, according to the tracking page :(
335 2013-08-20 12:11:30 <sipa> winbtc_moarrr: not sure what you mean - i'm not anti litecoin, though i don't really care about it much
336 2013-08-20 12:11:32 <Luke-Jr> winbtc_moarrr: individual reasons vary, but for me it's because it's a scam, makes bitcoin look bad, and leeches off bitcoin resources
337 2013-08-20 12:11:54 <jgarzik> I haven't had time to set mine up :( It's such a low hash rate, it's almost too much effort to plug in and set up a separate bfgminer process :)
338 2013-08-20 12:12:09 <Luke-Jr> jgarzik: why separate? :p
339 2013-08-20 12:12:15 <jgarzik> my variance with 5x 60GH is above 333 Mhps
340 2013-08-20 12:12:17 <jgarzik> :)
341 2013-08-20 12:12:21 <sipa> why a separate bfgminer?
342 2013-08-20 12:12:49 <jgarzik> paranoia, I suppose. Don't want block erupters to kill my much more valuable BFL mining
343 2013-08-20 12:12:50 <Luke-Jr> jgarzik: that won't change by using a separate instance <.<
344 2013-08-20 12:12:50 <petertodd> winbtc_moarrr: don't assume that everyone agrees with luke either
345 2013-08-20 12:12:56 <gmaxwell> kinlo: the common calculating of time-till-block fixates a non-memoryless system in people's minds "I'm not fast enough to get a block before the difficulty goes up".. and yet we all know mining is memoryless.
346 2013-08-20 12:13:03 <gmaxwell> Luke-Jr: that doesn't inspire confidence!
347 2013-08-20 12:13:23 <Luke-Jr> gmaxwell: I meant in response to [14:12:14] <jgarzik> my variance with 5x 60GH is above 333 Mhps
348 2013-08-20 12:13:45 <Luke-Jr> jgarzik: while true; do ./bfgminer . . . ; done
349 2013-08-20 12:13:46 <Luke-Jr> ???
350 2013-08-20 12:14:06 <Luke-Jr> otoh
351 2013-08-20 12:14:22 <Luke-Jr> I have to admit, plugging erupters into my colo machine screws up the minirig hardware somehow
352 2013-08-20 12:14:29 <gmaxwell> hahah
353 2013-08-20 12:14:30 <Luke-Jr> I have to power cycle the minirig when I add an erupter :<
354 2013-08-20 12:14:45 <gmaxwell> ACTION hands the trophy to jeff for this round
355 2013-08-20 12:14:47 <Luke-Jr> not even sharing a USB hub either
356 2013-08-20 12:15:02 <Luke-Jr> :p
357 2013-08-20 12:15:17 <Luke-Jr> I've not had that kind of problem with my singles though
358 2013-08-20 12:15:22 <Luke-Jr> on my desktop PC
359 2013-08-20 12:15:42 <jgarzik> monetarily speaking, it is worth it to simply set up an ancient laptop for the erupters
360 2013-08-20 12:15:42 <sipa> my erupters a still in the US, according tot eh tracker page
361 2013-08-20 12:15:45 <sipa> to the
362 2013-08-20 12:16:12 <jgarzik> but then, considering the time cost of all this, the erupters are even more net unprofitable :)
363 2013-08-20 12:16:16 <kinlo> gmaxwell: I know but that's not how people think
364 2013-08-20 12:16:41 <kinlo> jgarzik: it remains a hobby, so in a way it's entertainment therefore not to be calculated :)
365 2013-08-20 12:16:46 <kinlo> (at least for me)
366 2013-08-20 12:17:33 <winbtc_moarrr> Luke-Jr: cant there be enough resources for both litecoin and bitcoin?
367 2013-08-20 12:18:29 <Luke-Jr> winbtc_moarrr: people who are helping voluntarily because they believe in bitcoin, can be offended if they find out they're helping with a scam instead
368 2013-08-20 12:18:39 <Luke-Jr> and litecoin leeches tend to hide that
369 2013-08-20 12:19:08 <gmaxwell> <--offtopic--
370 2013-08-20 12:21:48 <winbtc_moarrr> Luke-Jr: why is litecoin a scam yet bitcoin isnt?
371 2013-08-20 12:21:56 <winbtc_moarrr> Luke-Jr: are they not virtually identical?
372 2013-08-20 12:22:07 <Luke-Jr> winbtc_moarrr: now it's getting very off topic, but no, they're not
373 2013-08-20 12:22:16 <winbtc_moarrr> oh ok
374 2013-08-20 12:22:21 <winbtc_moarrr> ACTION will shut up
375 2013-08-20 12:22:33 <Luke-Jr> winbtc_moarrr: I also have to leave; if you want perhaps we can discuss it later in #eligius or something
376 2013-08-20 12:22:44 <winbtc_moarrr> sure :)
377 2013-08-20 12:23:01 <winbtc_moarrr> Supa is doing very well too, hes already paid off some of his debt :)
378 2013-08-20 12:23:36 <Luke-Jr> that is even more off-topic here
379 2013-08-20 12:23:42 <winbtc_moarrr> oh sorry
380 2013-08-20 12:45:38 <sipa> ;;genrate 330
381 2013-08-20 12:45:39 <gribble> The expected generation output, at 330.0 Mhps, given difficulty of 50810339.0483, is 0.00326624764823 BTC per day and 0.00013609365201 BTC per hour.
382 2013-08-20 12:46:29 <gmaxwell> Better off solo mining with that. It's not an income source, it's a digital lottery ticket.
383 2013-08-20 12:46:32 <gmaxwell> :P
384 2013-08-20 13:15:03 <jgarzik> man
385 2013-08-20 13:15:11 <jgarzik> sipa's PGP signature list is long and impressive
386 2013-08-20 13:16:39 <petertodd> jgarzik: mike on the other hand is a zen master
387 2013-08-20 13:17:20 <jgarzik> sipa > gmaxwell > petertodd, according to the view here ;p
388 2013-08-20 13:17:24 <jgarzik> > jgarzik
389 2013-08-20 13:17:31 <jgarzik> I need TD's fingerprint
390 2013-08-20 13:17:33 <petertodd> lol
391 2013-08-20 13:18:06 <TD> i only have my pgp key at home.
392 2013-08-20 13:18:28 <petertodd> I keep mine in my wallet - the card reader on the other hand...
393 2013-08-20 13:18:30 <TD> i need to make sure i have it in the various places i might want to use it
394 2013-08-20 13:19:21 <petertodd> TD: you should use a subkey for that, or just do a "low security key" like I do
395 2013-08-20 13:19:46 <petertodd> TD: might as well be able to learn what was compromised - shitty usability though :(
396 2013-08-20 13:19:57 <sipa> jgarzik: i once participated in a FOSDEM keysigning party, with 200 people or so
397 2013-08-20 13:19:59 <TD> i guess i should investigate that feature. i'm not sure how i'd revoke such a key if it were present or whether people would understand how to use it.
398 2013-08-20 13:20:00 <TD> yeah
399 2013-08-20 13:20:18 <TD> sipa: the interesting question is - how do you know the people whose keys you signed were really the people they claimed to be?
400 2013-08-20 13:20:25 <jgarzik> Yeah, back in my Linux days there were many keysigning parties
401 2013-08-20 13:20:34 <sipa> TD: i checked their ID
402 2013-08-20 13:20:41 <petertodd> TD: there is a revsubkey or similar thing in GPG - it's all thought out in the standards fairly well, just not so much the UI's
403 2013-08-20 13:20:50 <TD> i have a PKIX key issued for my email address
404 2013-08-20 13:21:04 <TD> so i guess S/MIME could be used to encrypt mails too. but then i suspect even fewer people know how to handle them
405 2013-08-20 13:21:13 <sipa> TD: which is a relatively weak check, given that it had to happen quickly, but i did not sign any key for which i did *some* check
406 2013-08-20 13:21:17 <TD> sipa: oh, you did? ok
407 2013-08-20 13:21:22 <TD> that's cool
408 2013-08-20 13:21:33 <TD> makes me want to implement my epassport-fu even more though :)
409 2013-08-20 13:21:35 <petertodd> TD: yeah, mutt checks them, but who knows how good that check actually is - IE do the revoke bad CA's? dunno
410 2013-08-20 13:21:35 <sipa> TD: you get a paper with all keys and identities in advance
411 2013-08-20 13:21:46 <jgarzik> TD, BitPay is gonna deploy SINs
412 2013-08-20 13:21:51 <TD> SINs?
413 2013-08-20 13:22:00 <petertodd> jgarzik: oh crazy, so it's not just a hobby side project
414 2013-08-20 13:22:04 <sipa> TD: and then walk around, marking each one that matches
415 2013-08-20 13:22:13 <TD> i see
416 2013-08-20 13:22:15 <jgarzik> TD, anonymous passports if you will: https://en.bitcoin.it/wiki/Identity_protocol_v1
417 2013-08-20 13:22:25 <TD> ah. nice. what's the first integration target?
418 2013-08-20 13:22:30 <jgarzik> petertodd, yep, definitely found several uses
419 2013-08-20 13:22:32 <petertodd> sipa: speaking of, you still haven't signed my key if you still have that card
420 2013-08-20 13:22:40 <TD> if i was doing it i'd probably pick wordpress or something. allow you to post blog comments anonymously but with a passport
421 2013-08-20 13:23:19 <petertodd> jgarzik: the fidelity bonded version too?
422 2013-08-20 13:23:43 <jgarzik> TD / petertodd: internal, for now. Assign people a SIN related to invoices or somesuch. A totally separate use case just arose, too: a local doctor wants to use SINs for AIDS-style anonymous test identities.
423 2013-08-20 13:24:06 <jgarzik> petertodd, Type 2, non-sacrifice :/
424 2013-08-20 13:24:35 <TD> what does SIN stand for?
425 2013-08-20 13:24:39 <TD> something identity number?
426 2013-08-20 13:25:00 <petertodd> jgarzik: well it's a start, although I'd be careful not to accidentally reimplement PGP if it goes in that direction...
427 2013-08-20 13:26:16 <TD> sipa: the thing is, if the people in keysigning parties are just checking government ID, you might as well short circuit that whole process and use zk-SNARKs to digest the ePassport certificate and combine it with a private key that way.
428 2013-08-20 13:26:19 <jgarzik> TD, system identification number. SIN comes from years-ago science fiction.
429 2013-08-20 13:26:23 <TD> sipa: the tech doesn't exist yet but i feel sure it'sc lose
430 2013-08-20 13:26:59 <sipa> TD: there's no problem with that, IMHO
431 2013-08-20 13:27:00 <TD> jgarzik: what's the point of a type 2 SIN?
432 2013-08-20 13:27:22 <sipa> TD: IMHO, the identity itself should specify what sort of verification it claims to pass
433 2013-08-20 13:27:47 <sipa> TD: so if the identity is an e-mail address, i'm fine with signing if i have proof the owner of that key has access to that e-mail address
434 2013-08-20 13:27:51 <petertodd> TD: heck, don't bother with fancy crypto, just use the ePassport cert to sign your key and timestamp it so later compromise isn't an issue
435 2013-08-20 13:27:58 <sipa> if the identity is a picture, i'll sign when he looks like it
436 2013-08-20 13:28:14 <sipa> if the identity is a government e-passport something, well
437 2013-08-20 13:28:20 <TD> petertodd: i wouldn't be talking about the fancy crypto if it were optional. unfortunately not all passports can sign things. some of them are just literally bearer tokens
438 2013-08-20 13:28:38 <TD> petertodd: there isn't even a list that i can find of which countries passports can sign challenges
439 2013-08-20 13:28:45 <TD> but UK passports definitely can't. i think US passports can't either.
440 2013-08-20 13:29:00 <gmaxwell> man, some passports can sign challenges? wild!
441 2013-08-20 13:29:08 <TD> yeah. it's an anti-cloning feature.
442 2013-08-20 13:29:16 <petertodd> TD: right, but my understanding was the pure bearer tokens don't help there - anyone can copy the token after all
443 2013-08-20 13:29:28 <TD> i suspect quite a few governments decided to go with the cheaper chips that just store data because the physical anti-cloning features work well enough already
444 2013-08-20 13:29:57 <petertodd> gmaxwell: yup, and lots of national ID cards too, and military id cards (like the US military ones)
445 2013-08-20 13:30:10 <TD> petertodd: hence the crypto magic. the idea is you convert your cert (signed copy of what's already on the paper passport) into a cert+public key where you retain the private key on your computer
446 2013-08-20 13:30:14 <TD> then you can sign things with it
447 2013-08-20 13:30:35 <petertodd> gmaxwell: though my understanding is the US military ones do two way authentication, so you can't use at least one of the keys to sign unless the computer authenticates to the card as well
448 2013-08-20 13:30:37 <TD> basically you run a provable program that takes in: ePassport cert chain, your new ecdsa public key
449 2013-08-20 13:30:57 <TD> + whatever public data you wish to include in the output "cert", like name/photo hash/date of birth/country of citizenship
450 2013-08-20 13:31:06 <TD> the ePassport data is a private input. the rest are public.
451 2013-08-20 13:31:08 <sipa> i'm sure in 10 years we'll have SCIP signatures proving the signer's DNA or something!
452 2013-08-20 13:31:16 <petertodd> TD: right, but my point is because it's a token, you are risking compromise the second anyone gets physical access to your passport - quite worrying
453 2013-08-20 13:31:19 <TD> the program accepts if the cert chain is valid. now you can present the public inputs and the acceptance proof as a cert.
454 2013-08-20 13:31:49 <TD> well, someone who compromises your passport (thief or government) could generate a second keypair that is linked to the legal identity.
455 2013-08-20 13:32:05 <TD> if they're uploaded to a keyserver, you wouldn't know which to use
456 2013-08-20 13:32:07 <petertodd> TD: exactly
457 2013-08-20 13:32:14 <TD> but if you see two certificates linked to the same passport -> halt
458 2013-08-20 13:32:20 <TD> (of course then rotation/revocation becomes an issue)
459 2013-08-20 13:32:31 <petertodd> TD: granted, that's fair enough, although it gets ugly if participation isn't 100%
460 2013-08-20 13:32:50 <TD> yeah
461 2013-08-20 13:33:03 <petertodd> TD: if you assume 100% participation, just timestamping UID's associated with an emial addr is pretty good
462 2013-08-20 13:33:24 <TD> with a GPG keysigning party, the "binding" is checking the face of the person in front of you vs the face in the ID dodcument
463 2013-08-20 13:34:00 <TD> with an entirely online system you need something else - like if you see a presentation by someone or a photo, and want to contact them, you trust that the photo/presentation is "legitimate" and can do the face match yourself
464 2013-08-20 13:34:21 <TD> i think it's sufficient most of the time for someone to say "You can contact me using FooSystem"
465 2013-08-20 13:34:37 <TD> then a user of FooSystem can just search their name facebook style, and verify the face that pops up is the one that is expected.
466 2013-08-20 13:35:04 <petertodd> TD: incidentally, that's exactly how warren verified my key fingerprint - I just recorded a short video (wearing the same shirt!) which he compared to the video of my talk, along with other verifications (like the zillions of PGP signed emails...)
467 2013-08-20 13:35:20 <petertodd> TD: indeed...
468 2013-08-20 13:35:38 <petertodd> TD: what's google's name disambiguation policy for employees anyway?
469 2013-08-20 13:35:45 <TD> for it to be practical i think ben-sassons SNARK system would need to be extended to have an efficient way to do RSA. not sure.
470 2013-08-20 13:35:51 <TD> name disambiguation policy?
471 2013-08-20 13:36:05 <petertodd> TD: IE I'm also named Mike Hearn, what @google.com email do I get?
472 2013-08-20 13:36:18 <handle> Mike.Hearn.Jr@google.com
473 2013-08-20 13:36:19 <handle> :D
474 2013-08-20 13:36:21 <TD> you get to choose your own username when you are hired
475 2013-08-20 13:36:24 <handle> ok maybe not
476 2013-08-20 13:36:28 <TD> you get three choices.
477 2013-08-20 13:36:44 <TD> so you get to choose. unless you're stupid like i was, of course, and choose "mike" "mikeh" or "mh"
478 2013-08-20 13:36:45 <TD> lol
479 2013-08-20 13:36:50 <petertodd> TD: right, which does limit the "I'm mike hearn at google, find me", although not by much
480 2013-08-20 13:36:50 <TD> that's how i got stuck with hearn
481 2013-08-20 13:37:11 <TD> sure, there was a name conflict at one point and lots of internal (postal) mail got accidentally routed to me after he left
482 2013-08-20 13:37:44 <petertodd> heh, nice
483 2013-08-20 13:37:52 <TD> name is a bit ambiguous by itself, but name+photo seems to work well enough to disambiguate everyone. at least it works fine for facebook and it's natural and intuitive.
484 2013-08-20 13:38:12 <TD> that's why i like the ePassport idea. basically everyone who travels has one and the setup process can be just a two-step thing with a modern android phone.
485 2013-08-20 13:38:26 <TD> just scan+hold, wait a bit, and now people can find you and send you end to end encrypted data
486 2013-08-20 13:38:33 <TD> no key signing parties or key imports needed.
487 2013-08-20 13:39:36 <petertodd> Well, it's not perfect, but just having better usability is probably worth it...
488 2013-08-20 13:40:03 <TD> yeah. the most obvious angle of attack is governments cloning your passport and then doing a DoS by uploading a conflicting certificate
489 2013-08-20 13:40:04 <petertodd> IMO just having a long history of PGP signed emails etc. is very convincing in of itself.
490 2013-08-20 13:40:09 <petertodd> yup
491 2013-08-20 13:40:10 <TD> yes
492 2013-08-20 13:40:16 <petertodd> and it's nice to force them to go that far...
493 2013-08-20 13:40:24 <TD> *if* you post to a lot of public mailing lists. which most people don't.
494 2013-08-20 13:40:37 <TD> i was thinking about this in the context of how one might establish contact with a journalist like snowden did
495 2013-08-20 13:40:55 <TD> that was obviously a very painful process, and unfortunately greenwald et al *still* don't seem to have any easily locatable pgp key
496 2013-08-20 13:40:56 <petertodd> well obviously the journalist should be PGP signing their articles.. :/
497 2013-08-20 13:41:28 <TD> end to end crypto for articles themselves? hah
498 2013-08-20 13:42:00 <petertodd> it's bad enough forum software - like bitcointalk - just can't do it
499 2013-08-20 13:42:29 <TD> once the payment protocol is further along, i'd like to write a tutorial on how to set up custom CAs. like, theymos should be able to issue certs for each forum user that they can use to sign payment requests
500 2013-08-20 13:42:45 <TD> it's not all that hard really. MacOS even has a gui wizard for it!
501 2013-08-20 13:42:50 <TD> it's buggy as hell but ... it's there.
502 2013-08-20 13:43:47 <jgarzik> journalists are tech-sad
503 2013-08-20 13:44:07 <TD> s/journalists/all normal people including many computer science PhDs/
504 2013-08-20 13:44:13 <TD> or did you never read "why jonny can't encrypt"?
505 2013-08-20 13:44:21 <TD> wtf seriously? https://blockchain.info/address/1HackerRpwYH7F6uGu8422dScNxaHAtWYz
506 2013-08-20 13:44:23 <jgarzik> During this NSA thing, a lot of reporters were "surprised to learn" that email going across the Internet was not encrypted / not private
507 2013-08-20 13:44:23 <TD> ugh
508 2013-08-20 13:44:56 <jgarzik> *facepalm*
509 2013-08-20 13:45:00 <TD> ACTION shrugs
510 2013-08-20 13:45:02 <TD> it's not that obvious
511 2013-08-20 13:45:09 <jgarzik> These are the people who are in charge of reporting this stuff to the general public
512 2013-08-20 13:45:12 <TD> i mean, passwords and credit card data on the web was encrypted for years
513 2013-08-20 13:45:26 <TD> it's not entirely unreasonable to assume email would be as well. especially as when you use webmail these days you see the little padlock
514 2013-08-20 13:45:38 <TD> the fact that SMTP-TLS is sort of a joke, is not at all obvious. unless you're an internet engineer.
515 2013-08-20 13:46:03 <TD> and the whole "all major providers are badly compromised" angle is kind of what's new and interesting. so i can't blame them for that.
516 2013-08-20 13:46:35 <TD> now ..... when they still don't bother using crypto even afterwards. that is harder to forgive. it appears the Guardian has decided "all electronic communication is suspect, thus, we will deliver all important messages and documents by hand and suck up the cost of flying"
517 2013-08-20 13:46:37 <TD> FAIL
518 2013-08-20 13:47:25 <petertodd> TD: I wouldn't call that fail at all *if* they encrypted the data on the harddrives - just good precautionary two-factor protection given who they are up against
519 2013-08-20 13:47:50 <TD> that's great for handling their existing set of leaks
520 2013-08-20 13:47:56 <TD> what about the next set? how do they expect to receive them, exactly?
521 2013-08-20 13:47:57 <petertodd> TD: SMTP-TLS by default allows non-authenticated right?
522 2013-08-20 13:48:14 <petertodd> TD: fair enough, they should have a PGP key right on their front page among other things...
523 2013-08-20 13:48:14 <TD> AFAIK all major implementations fall back to non-TLS if they can't validate, yes, and many don't validate at all
524 2013-08-20 13:48:19 <TD> right
525 2013-08-20 13:49:15 <petertodd> I think it's funny how the only journalist I've seen doing that is Adrian Jeffries, who's roughly my age
526 2013-08-20 13:49:20 <jgarzik> smtp includes starttls
527 2013-08-20 13:49:28 <jgarzik> but huge providers fail to use it
528 2013-08-20 13:49:34 <jgarzik> including google outgoing :/
529 2013-08-20 13:49:50 <jgarzik> yahoo, [now dead?] hotmail, ...
530 2013-08-20 13:50:01 <TD> no
531 2013-08-20 13:50:04 <TD> google does use smtp-tls
532 2013-08-20 13:50:19 <TD> the problem is most other providers don't support it. also, it's one of those "fall back to cleartext if tls is broken" setups
533 2013-08-20 13:50:29 <jgarzik> TD, not always. My exim installation, which is fully tls-safe, receives non-TLS from google.
534 2013-08-20 13:50:44 <jgarzik> TD, have not nailed down the conditions, because it is not 100% either/or
535 2013-08-20 13:50:55 <TD> i think it may have to be enabled manually per-provider or something. i know it is getting looked at more closely these days :)
536 2013-08-20 13:51:18 <jgarzik> TD, of course, I am a statistical weirdo, running my own smtpd, unlike 99.9% of the planet
537 2013-08-20 13:51:48 <jgarzik> anyway, bbiaw
538 2013-08-20 13:51:51 <BlueMatt> jgarzik: you arent the only one :)
539 2013-08-20 13:52:04 <petertodd> jgarzik: hi five!
540 2013-08-20 13:52:16 <marcusw> ACTION feels like part of the club
541 2013-08-20 13:53:03 <petertodd> Of course, given I have that email server on amazon EC2, it's not like it's secure or anything.
542 2013-08-20 13:54:10 <TD> pond!
543 2013-08-20 13:54:35 <BlueMatt> ACTION votes for security review of pond
544 2013-08-20 13:54:44 <BlueMatt> s/review/audit/
545 2013-08-20 13:55:00 <TD> unfortunately the code uses lots of advanced crypto, and is written in Go
546 2013-08-20 13:55:12 <BlueMatt> Go....yuck
547 2013-08-20 13:56:05 <sipa> link?
548 2013-08-20 13:56:11 <BlueMatt> pond.imperialviolet.org
549 2013-08-20 13:56:37 <TD> agl really likes it for some reason. i can't really see what's so great about Go myself.
550 2013-08-20 13:56:38 <sipa> ah, agl's page
551 2013-08-20 13:56:53 <TD> but whatever. it's probably better than C :)
552 2013-08-20 13:57:08 <BlueMatt> TD: I cant say Im a huge fan, but I havent done anything large with it, maybe Id fall in love if I spent tons of time on it
553 2013-08-20 13:57:20 <sipa> i have way to little experience with it too judge it
554 2013-08-20 13:57:25 <sipa> which is to say: none
555 2013-08-20 14:01:30 <TD> from a portability perspective it loses .... apparently building pond on a mac is a nightmare
556 2013-08-20 14:01:51 <BlueMatt> building pond isnt easy to begin with...given it doesnt have a build system released
557 2013-08-20 15:23:35 <swulf--> ERROR: CScriptCheck() : 7a79975c2e1db07afa5f9208b8d18266598ae962bda7f6ecd69920fa4be94c0f VerifySignature failed -- blockchain.info says this txn is fine.. any idea what's wrong with it?
558 2013-08-20 15:24:13 <gdoteof> i have a backed up wallet from the bitcoin-android app
559 2013-08-20 15:24:18 <gdoteof> but don't have an android
560 2013-08-20 15:24:31 <gdoteof> is it easier to just get an android or can i unlock it somehow from my ubuntu
561 2013-08-20 15:24:44 <gmaxwell> swulf--: read the surrounding lines.
562 2013-08-20 15:25:08 <swulf--> ERROR: Non-canonical signature: wrong length marker
563 2013-08-20 15:25:09 <swulf--> ERROR: CTxMemPool::accept() : ConnectInputs failed 7a79975c2e1db07afa5f9208b8d18266598ae962bda7f6ecd69920fa4be94c0f
564 2013-08-20 15:25:27 <gmaxwell> Yup.
565 2013-08-20 15:25:31 <gmaxwell> There you go.
566 2013-08-20 15:25:42 <sipa> wrong length marker
567 2013-08-20 15:25:45 <gmaxwell> The signature's DER encoding is malformed. Do you know what software created it?
568 2013-08-20 15:25:46 <sipa> that's an original one
569 2013-08-20 15:27:10 <Ry4an> gdoteof: probably "easier" to just download google's android emulator and import it, but certainly possible to do w/o.
570 2013-08-20 15:27:40 <swulf--> wrong length marker?
571 2013-08-20 15:27:41 <swulf--> hmm
572 2013-08-20 15:28:06 <swulf--> part of the program, i presume?
573 2013-08-20 15:28:56 <gmaxwell> swulf--: any idea what software authored this transaction?
574 2013-08-20 15:29:19 <swulf--> i authored it by hand :)
575 2013-08-20 15:29:26 <lianj> ^^
576 2013-08-20 15:31:08 <swulf--> is this going to be a problem if some miner out there accepts the txn?
577 2013-08-20 15:31:57 <gmaxwell> swulf--: your hand authoring needs work. :P
578 2013-08-20 15:32:13 <gmaxwell> No, it has fairly low odds of getting mined anytime soon though.
579 2013-08-20 15:32:18 <swulf--> gmaxwell: i've been doing it fine for a while, so this is a new one. It's why I'm here ;)
580 2013-08-20 15:32:36 <swulf--> well, thats good :)
581 2013-08-20 15:33:29 <gmaxwell> swulf--: by hand do you mean with some python code you found on the interwebs?
582 2013-08-20 15:34:04 <swulf--> well, I pieced together my own code based on bitcoind src and the documentation on the web
583 2013-08-20 15:34:36 <gmaxwell> well you dun goofed.
584 2013-08-20 15:34:53 <swulf--> I dun did.
585 2013-08-20 15:35:20 <swulf--> Is the length marker its referring to the byte length of a pushdata op in the script?
586 2013-08-20 15:35:22 <gmaxwell> in any case, go look at the test that triggers "wrong length marker" and fix it.
587 2013-08-20 15:35:26 <swulf--> ok
588 2013-08-20 15:35:38 <gmaxwell> no. it's reffering to the lengths encoded in the der encoded signature, IIRC.
589 2013-08-20 15:36:32 <swulf--> that's odd
590 2013-08-20 15:39:34 <swulf--> gmaxwell: I'm guessing blockchain.info either uses the same stuff I did to generate the key, doesn't check it, or has a similar bug..
591 2013-08-20 15:39:38 <swulf--> s/key/signature
592 2013-08-20 15:40:13 <gmaxwell> swulf--: they're just not checking much, most likely.
593 2013-08-20 15:40:25 <swulf--> yeah.
594 2013-08-20 15:40:26 <gmaxwell> swulf--: e.g., in the past: https://people.xiph.org/~greg/21mbtc.png
595 2013-08-20 15:40:49 <swulf--> nice
596 2013-08-20 15:44:12 <sipa> swulf--: can you paste the signature?
597 2013-08-20 15:44:31 <swulf--> hrm
598 2013-08-20 15:45:12 <Luke-Jr> so Canary has a Bitcoin-Qt on Windows, that is reporting LevelDB corruption even when started with -reindex
599 2013-08-20 15:45:24 <swulf--> sipa: I'm not sure which input is the incorrect one
600 2013-08-20 15:46:21 <sipa> Luke-Jr: bleh :(
601 2013-08-20 15:46:39 <Luke-Jr> sipa: how can it be corrupt in the same initial session? :/
602 2013-08-20 15:46:48 <sipa> Luke-Jr: there is always the possibility for bad ram, or os/disk problems
603 2013-08-20 15:46:54 <Luke-Jr> LevelDB read failure: Corruption: block checksum mismatch
604 2013-08-20 15:47:08 <sipa> but we see this way too often to just ascribe it to that
605 2013-08-20 15:47:08 <swulf--> I got it once while doing -reindex as well
606 2013-08-20 15:49:58 <swulf--> sipa/gmaxwell: fwiw, this is the code that generates the signature: http://pastebin.com/wxhP6X6G
607 2013-08-20 15:50:17 <swulf--> i'm probably doing something wrong here
608 2013-08-20 15:53:33 <jgarzik> what does a blank script look like? varint indicating length zero, and that's it?
609 2013-08-20 15:53:43 <jgarzik> txTmp.vin[i].scriptSig = CScript();
610 2013-08-20 15:54:02 <gmaxwell> swulf--: I'm python dumb, but you don't appear to be resizing the signature to the resulting siglen.
611 2013-08-20 15:54:14 <swulf--> hmmm
612 2013-08-20 15:54:45 <Diablo-D3> ;;ticker
613 2013-08-20 15:54:45 <gribble> MtGox BTCUSD ticker | Best bid: 119.60000, Best ask: 119.89998, Bid-ask spread: 0.29998, Last trade: 119.60000, 24 hour volume: 21739.00915439, 24 hour low: 116.67089, 24 hour high: 123.01111, 24 hour vwap: 120.34495
614 2013-08-20 15:54:50 <gmaxwell> swulf--: the signature is not a constant length, it returns the length.
615 2013-08-20 15:54:50 <Luke-Jr> CanaryInTheMine: so why do you assume the HD isn't bad?
616 2013-08-20 15:54:54 <Luke-Jr> oh, the new SSD, right.
617 2013-08-20 15:54:58 <Luke-Jr> sipa: he tried another disk
618 2013-08-20 15:55:00 <swulf--> gmaxwell: I'm double checking now
619 2013-08-20 15:56:01 <swulf--> oh interesting, i see
620 2013-08-20 15:56:07 <Luke-Jr> CanaryInTheMine: possible bad RAM?
621 2013-08-20 15:58:10 <swulf--> gmaxwell: in the transaction, there are several zero bytes at the end of the signature in some of the scripts
622 2013-08-20 15:58:41 <swulf--> I think your find is correct
623 2013-08-20 15:59:40 <gmaxwell> Twenty years from now I will work as a consultant, and be paid to fly into places, where I will point at that spot in their python signing code and say "you forgot to resize the array" and collect my check. I can see it now.
624 2013-08-20 16:00:54 <Ry4an> :)
625 2013-08-20 16:01:19 <swulf--> gmaxwell: what's your Bitcoin address? ;)
626 2013-08-20 16:02:26 <gmaxwell> swulf--: 1EzHALbEEYBjXjvE34cSWG5VEkUNrcMzfj
627 2013-08-20 16:02:44 <swulf--> now I'm obligated ;)
628 2013-08-20 16:03:20 <gmaxwell> Nah, you never are. :P now if i sent a payment request, otoh...
629 2013-08-20 16:03:57 <swulf--> well, I'll draft a txn using this fix.
630 2013-08-20 16:04:19 <Luke-Jr> gmaxwell: CanaryInTheMine can't talk here?
631 2013-08-20 16:05:25 <gmaxwell> Luke-Jr: channel +q non-registered with freenode.
632 2013-08-20 16:07:10 <Luke-Jr> ah
633 2013-08-20 16:07:15 <Luke-Jr> CanaryInTheMine: reg with freenode :P
634 2013-08-20 16:10:34 <ingsoc_> Lol.
635 2013-08-20 16:13:38 <gmaxwell> moment of truth?
636 2013-08-20 16:13:53 <gmaxwell> I believe our canary is dead.
637 2013-08-20 16:22:11 <swulf--> gmaxwell: received?
638 2013-08-20 16:22:49 <gmaxwell> swulf--: thanks!
639 2013-08-20 16:23:11 <swulf--> :)
640 2013-08-20 16:25:13 <CanaryInTheMine> did it finally work?
641 2013-08-20 16:25:20 <gmaxwell> IT WORKED.
642 2013-08-20 16:25:26 <gmaxwell> WE GET SIGNAL.
643 2013-08-20 16:25:37 <Cusipzzz> ACTION waves at the canary
644 2013-08-20 16:25:50 <CanaryInTheMine> fcuk!!!! make this simpler!!!! anyway back to issue
645 2013-08-20 16:26:24 <CanaryInTheMine> so the smart info showed everything to be OK on th primary ssd drive.