1 2014-03-06 00:00:20 <maxplm> Ademan: I just fixed it in electrum by deleting the blockheaders and resyncing them. still weird, I feel like this should not happen
2 2014-03-06 00:00:35 <Anduck> i am using listsinceblock
3 2014-03-06 00:02:11 <sipa> Ademan: confirmations are a client-side policy
4 2014-03-06 00:02:20 <sipa> Ademan: what you're talking about is maturity
5 2014-03-06 00:02:27 <sipa> Ademan: which is a protocol rule
6 2014-03-06 00:02:45 <sipa> so yes, if someone mines directly to your address, you need to wait 101 blocks before you can spend the coin
7 2014-03-06 00:02:49 <Anduck> ahh
8 2014-03-06 00:02:52 <Anduck> anduck btw*
9 2014-03-06 00:03:02 <sipa> ugh, confusing!
10 2014-03-06 00:03:12 <sipa> but bitcoind's rpcs will list the transaction as immature before
11 2014-03-06 00:03:39 <Anduck> what i thought i'll do is do listsinceblock (lastblockhashIchecked, 1)
12 2014-03-06 00:03:54 <Anduck> and then check for all where category=='receive'
13 2014-03-06 00:04:07 <Anduck> and 'confirmations' >= 6
14 2014-03-06 00:04:53 <Anduck> is there a wat to distinguish a mined tx from normal tx
15 2014-03-06 00:05:34 <Anduck> way*
16 2014-03-06 00:07:35 <sipa> it will not be 'receive' but 'immature'
17 2014-03-06 00:08:09 <Anduck> hmm
18 2014-03-06 00:08:22 <Anduck> there's no note about that in the source code btw
19 2014-03-06 00:08:35 <Anduck> \"category\":\"send|receive\",
20 2014-03-06 00:08:57 <Anduck> line 1370 src/rpcwallet.cpp
21 2014-03-06 00:09:04 <sipa> pull requests welcome to improve it :)
22 2014-03-06 00:09:23 <sipa> it can also be 'orphan' or 'generate'
23 2014-03-06 00:09:25 <Anduck> hmm.. i searched code for 'immature'
24 2014-03-06 00:09:27 <Anduck> ok
25 2014-03-06 00:09:44 <Ademan> sipa: you confused me for a minute there lol
26 2014-03-06 00:10:43 <Anduck> found it
27 2014-03-06 00:10:43 <lechuga_> i cant imagine doing bitcoin dev and not parking a client in here 24/7
28 2014-03-06 00:11:26 <Anduck> category is 'orphan', 'immature' or 'generate'
29 2014-03-06 00:11:36 <Anduck> and for -regular- send and receive it's 'send' or 'receive'
30 2014-03-06 00:11:57 <Anduck> so i should be safe from people mining to the address by only looking at 'receie
31 2014-03-06 00:12:24 <sipa> yes
32 2014-03-06 00:12:36 <Anduck> great. thanks for help!
33 2014-03-06 00:13:07 <Anduck> if a transaction for malleated, how would it show?
34 2014-03-06 00:13:33 <Anduck> though i only show >= 1 conf tx's
35 2014-03-06 00:13:34 <sipa> one confirmed or unconfirmed
36 2014-03-06 00:13:40 <Anduck> ok
37 2014-03-06 00:13:44 <sipa> another with -1 confirmations, as of 0.9
38 2014-03-06 00:13:50 <Anduck> alright
39 2014-03-06 00:13:52 <sipa> before, one that just never confirms
40 2014-03-06 00:14:40 <Anduck> now i've solved incoming malleated tx's by removing the non-confirmed tx's after some time (from a system that lists all incoming transactions after they have 1 conf)
41 2014-03-06 00:14:58 <Anduck> but yeah -1 conf mark will be better
42 2014-03-06 00:15:13 <dexX7> maxplm: to what electrum server are you connected?
43 2014-03-06 00:16:57 <maxplm> dexX7 it did not matter, none showed it correctly. someone from #electrum told me to delete blockchain_headers and reconnect, and that fixed it. said it was a known bug, soon to be fixed
44 2014-03-06 00:17:47 <dexX7> ah.. i searched for the tx via electrum's console and it showed up, so i was curious
45 2014-03-06 00:18:40 <maxplm> apparently something fscked the headers in my client. all is well now, except that bc.i is still completely weird
46 2014-03-06 00:26:11 <lechuga_> lianj: don't suppose there's any chance you're actually up
47 2014-03-06 00:26:12 <dexX7> maybe they have the exactly same problem?
48 2014-03-06 00:26:17 <Gerendon> Hiring a programmer proficient in Ruby for a blockchain parser. PM for more information.
49 2014-03-06 00:30:54 <Ademan> really dumb question: what is the block index referred to by the getblockhash rpc call?
50 2014-03-06 00:31:10 <maxplm> dexX7 yeah I jokingly suggested to the electrum guys they should tell bc.i how they fixed it
51 2014-03-06 00:32:15 <Ademan> is index the same as height?
52 2014-03-06 00:32:56 <dexX7> yea that's the height
53 2014-03-06 00:37:35 <Ademan> I was confused because blockchain.info/block-index/$bi?format=json doesn't seem to be the same as height
54 2014-03-06 00:38:09 <sipa> Ademan: the block index is the database that bitcoind maintains with information about every block
55 2014-03-06 00:38:18 <sipa> Ademan: including some metadata, and where to find it on disk
56 2014-03-06 00:39:49 <Ademan> sipa: sorry, I guess 'help' just refers to it as "index", but I mean the argument to getblockhash.
57 2014-03-06 00:40:09 <Ademan> getblockhash <index>
58 2014-03-06 00:42:41 <sipa> oh, that should be height, indeed
59 2014-03-06 00:43:10 <sipa> "index" here is just used as "position in database"
60 2014-03-06 00:50:13 <fake_nickname_00> Hello all. I'm looking to use Nakamoto block chains for a project of mine. I've looked on the wiki (https://en.bitcoin.it/wiki/Alternative_chain), but is there a well-documented guide for creating an altcoin.
61 2014-03-06 00:50:18 <fake_nickname_00> I want to create a coin that is 100% premined and that is distributed via faucets/bots. I specifically want to avoid public mining to prevent stockpile of the coins. (They can be transferred freely of course.)
62 2014-03-06 00:50:37 <fake_nickname_00> Also, so I can prevent DDOS/Abuse.
63 2014-03-06 00:51:21 <dexX7> http://pastebin.com/XVxxGk5n those are the missing ones for block 288788
64 2014-03-06 00:51:59 <edcba> fake_nickname_00: see altcoin-dev chan :)
65 2014-03-06 00:52:10 <Ademan> ACTION didn't know that existed
66 2014-03-06 00:52:20 <fake_nickname_00> edcba: Thanks!!
67 2014-03-06 00:52:25 <Ademan> heh it doesn't
68 2014-03-06 00:52:51 <Ademan> fake_nickname_00: I hope you understand everything you just described about your proposed altcoin would be extremely controversial
69 2014-03-06 00:53:09 <fake_nickname_00> Well, I don't want it to be currency.
70 2014-03-06 00:53:58 <edcba> why not just use some centralized server to track all spending ?
71 2014-03-06 00:55:05 <fake_nickname_00> I want the "confirmation" capability for transactions. (To prevent falsification, DDOS of nodes, decentralization, etc.)
72 2014-03-06 00:55:33 <Ademan> ugh what's wrong with you python-bitcoinlib... manually issuing the call works fine...
73 2014-03-06 00:56:27 <fake_nickname_00> edcba: I just don't want a user with a stockpile creating bots that create arbitrary transactions.
74 2014-03-06 00:58:55 <fake_nickname_00> Ademan: How did you guys deal with the ddos a few days ago?
75 2014-03-06 01:00:38 <fake_nickname_00> And so bitcoin-dev went dark....
76 2014-03-06 01:05:33 <fake_nickname_00> join bitcoin
77 2014-03-06 01:05:50 <Ademan> fake_nickname_00: I'm unaware of a ddos but maybe someone else in here knows, I'm not a core dev
78 2014-03-06 01:06:47 <fake_nickname_00> Ademan: I thought that some douche was creating an absurd amount of satoshi-scale transactions, and brought down a few exchanges.
79 2014-03-06 01:07:48 <Ademan> fake_nickname_00: well all nodes running software authored in the past year(?) will reject transactions smaller than 5430 satoshis
80 2014-03-06 01:09:21 <Ademan> I'm not quite sure how such an attack would be carried out unless a ton of malicious nodes managed to connect directly to the exchange nodes
81 2014-03-06 01:09:47 <Ademan> anyways, if the exchanges couldn't handle that strain, how could your centralized(?) node possibly?
82 2014-03-06 01:12:50 <fake_nickname_00> Ademan: There is no centralized node, I just want to prevent a user from accumulating a stupidly high amount of coins. (I know I'm not making sense to you, but trust me on this one.)
83 2014-03-06 01:13:47 <fake_nickname_00> Ademan: *In the initial period that is*
84 2014-03-06 01:31:51 <Ademan> Did getblock ever take a second parameter?
85 2014-03-06 01:33:35 <dexX7> the blockhash
86 2014-03-06 01:34:55 <Ademan> dexX7: hrm? isn't the blockhash the first parameter?
87 2014-03-06 01:35:28 <dexX7> getblock 00000000000000010a3cf6ac89eda17dad289a4e48986f711f594c732ae3145c
88 2014-03-06 01:35:35 <dexX7> ahh
89 2014-03-06 01:35:37 <dexX7> sorry
90 2014-03-06 01:36:02 <dexX7> the second one is optional and allows to get the raw data
91 2014-03-06 01:39:49 <Ademan> ah thanks
92 2014-03-06 01:40:30 <Ademan> it looks like bitcoin-qt doesn't like it?
93 2014-03-06 01:41:36 <Ademan> hrm, but my bitcoind definitely does, egh
94 2014-03-06 01:42:58 <dexX7> try false, could take a moment to respond though
95 2014-03-06 01:43:38 <Ademan> yeah it responds immediately "getblock <hash>\nReturns details of a block with given block-hash."
96 2014-03-06 01:45:55 <Ademan> oh well, I was just annoyed because python-bitcoinlib unconditionally passes False as the second parameter, and my bitcoin-qt doesn't like it, but I'm issuing the rpc call manually now without the second parameter and it's all good
97 2014-03-06 01:58:15 <Cylta> b.i is offering to send password as plaintext in URL in https protocol. Is it any safe against traffic sniffers?
98 2014-03-06 02:02:46 <Zarutian> Cylta: well, depends. Is the password in the hash fragment of the URL or not? (If latter then that damn HTTP Refferal header entry will leak it)
99 2014-03-06 02:03:27 <Cylta> example: https://blockchain.info/merchant/$guid/balance?password=$main_password
100 2014-03-06 02:04:24 <Cylta> does the https encrypt URL? or last part of URL after "?"?
101 2014-03-06 02:05:41 <SomeoneWeird> Cylta, afaik, yes, but it still shouldn't be used like that
102 2014-03-06 02:06:10 <phantomcircuit> Cylta, that completely defeats the entire purpose of their javascript wallets
103 2014-03-06 02:06:19 <phantomcircuit> Cylta, when you say "offering" what do you mean exactly?
104 2014-03-06 02:06:59 <Cylta> I mean that it's official how-to from https://blockchain.info/api/blockchain_wallet_api
105 2014-03-06 02:07:47 <phantomcircuit> Cylta, that is 10000000% insecure
106 2014-03-06 02:08:00 <phantomcircuit> those passwords will be sent to blockchain.info in plaintext
107 2014-03-06 02:08:09 <phantomcircuit> they will be sent OVER tls/ssl
108 2014-03-06 02:08:16 <phantomcircuit> however blockchain will receive them in plaintext
109 2014-03-06 02:08:41 <Cylta> is it safe against sniffers in between?
110 2014-03-06 02:08:52 <phantomcircuit> Cylta, and actually cloudflare would be able to see it plaintext inbetween
111 2014-03-06 02:09:07 <phantomcircuit> and their internal controls/security are (as far as I can tell) a joke
112 2014-03-06 02:13:41 <saracen> Cylta: https encrypts everything
113 2014-03-06 02:15:19 <Cylta> saracen: so, https connection for sniffer will look like IP address + bunch of encrypted text? no URL and keys in it, no content?
114 2014-03-06 02:16:37 <phantomcircuit> Cylta, the connection will look like this
115 2014-03-06 02:17:15 <SomeoneWeird> saracen, yes, but it's still insecure as fuck
116 2014-03-06 02:17:21 <phantomcircuit> Cylta, (your computer) <- encrypted nonsense -> (cloudflare.com servers) < - encrypted nonsense -> (blockchain.info servers)
117 2014-03-06 02:17:35 <phantomcircuit> Cylta, ie both cloudflare.com and blockchain.info can see the password
118 2014-03-06 02:17:46 <Cylta> okay, thanks
119 2014-03-06 02:17:51 <phantomcircuit> so either one (or their employees) could steal your bitcoins
120 2014-03-06 02:18:03 <phantomcircuit> otoh bc.i can just change the js they serve and rob you blind anyways
121 2014-03-06 02:18:04 <SomeoneWeird> and wait, bc.i is using file_get_contents?
122 2014-03-06 02:18:05 <SomeoneWeird> ugh.
123 2014-03-06 02:18:06 <Ademan> haha wow bc.i
124 2014-03-06 02:18:12 <phantomcircuit> and there's basically no way to prove they did it
125 2014-03-06 02:18:24 <phantomcircuit> it's a brilliant scam really
126 2014-03-06 02:18:33 <saracen> But that's the case for every site using cloudflare
127 2014-03-06 02:18:40 <phantomcircuit> anybody who complains about losing bc.i funds must have had a bad password.... right? ???
128 2014-03-06 02:18:42 <phantomcircuit> wrong
129 2014-03-06 02:18:44 <saracen> It doesn't matter that here's a password involved.
130 2014-03-06 02:18:48 <saracen> there's*
131 2014-03-06 02:18:58 <gmaxwell> and there are already tons of people who've lost coin in bc.i which has been blamed on weak passwords and malware, ... and no way to tell if thats all there is to it. :( (probably! but you can't tell)
132 2014-03-06 02:19:00 <Cylta> is cloudfare expensive? how to check that my hosting is not using it? =)
133 2014-03-06 02:19:03 <phantomcircuit> saracen, there is a reason you wont find banks using cloudflare
134 2014-03-06 02:19:38 <saracen> phantomcircuit: I don't dispute that :)
135 2014-03-06 02:20:15 <phantomcircuit> otoh cf can intercept anything
136 2014-03-06 02:20:26 <phantomcircuit> iirc they can issue BGP routes and can issue arbitrary https certs
137 2014-03-06 02:20:46 <Ademan> I should probably know this, but what does cloudflare do? Do they do more than just deliver static content with regional servers?
138 2014-03-06 02:21:19 <phantomcircuit> Ademan, that is really all that they do, but because of the weird way they implemented this, they also work like a really shitty ddos protection service
139 2014-03-06 02:21:38 <phantomcircuit> Ademan, basically the way they implmented it is that they proxy all of your requests
140 2014-03-06 02:21:51 <phantomcircuit> and automatically determine what can be cached
141 2014-03-06 02:21:59 <Cylta> another question. how many people\companies have access to https certificates that are enough to decrypt random session?
142 2014-03-06 02:22:01 <phantomcircuit> instead of you explicitly putting static content on a cdn
143 2014-03-06 02:22:17 <SomeoneWeird> they also "filter" xss & sqli attempts
144 2014-03-06 02:22:21 <SomeoneWeird> (which barely works)
145 2014-03-06 02:22:54 <phantomcircuit> lol do they?
146 2014-03-06 02:23:12 <lechuga_> Cylta: it depends on the organization's policy
147 2014-03-06 02:23:38 <SomeoneWeird> phantomcircuit, i was understating the "barely" bit
148 2014-03-06 02:23:44 <lechuga_> if its poorly run any given ops guy could have access to the cert's private key
149 2014-03-06 02:23:46 <Ademan> so it sounds like a zero-configuration cdn that has so much magic it's a problem?
150 2014-03-06 02:24:00 <SomeoneWeird> lechuga_, Ademan correct
151 2014-03-06 02:24:03 <phantomcircuit> Ademan, that would be about 99% correct
152 2014-03-06 02:25:39 <maaku> so much magic sounds like a good problem to have :\
153 2014-03-06 02:27:51 <Ademan> magic is great until you want to do something slightly different, and it becomes horrible, or if something goes wrong for other reasons it's impossible to debug
154 2014-03-06 02:28:41 <lechuga_> all cdns have to do something interesting for ssl
155 2014-03-06 02:29:58 <Ademan> How so? Couldn't you just have a subdomain and give the cdn the cert for only that subdomain?
156 2014-03-06 02:30:31 <lechuga_> well at least the case for akamai is
157 2014-03-06 02:30:39 <lechuga_> they want to route u to a server topologically close to you
158 2014-03-06 02:30:54 <saracen> Ademan: If you're using them for protection, the idea is that no client directly connects to you. They have to go through cloudflare.
159 2014-03-06 02:31:05 <lechuga_> which means several servers need to be able to use the same cert
160 2014-03-06 02:32:03 <lechuga_> and you're trusting the cdn to manage that correctly and securely
161 2014-03-06 02:32:07 <lechuga_> which is a lot of trust
162 2014-03-06 02:33:23 <lechuga_> and several banks and govt institutions use them
163 2014-03-06 02:33:31 <lechuga_> and gox :)
164 2014-03-06 02:34:38 <Ademan> I had to retrofit some stuff for an unnamed department of the state of california... oh.my.god. that was some of the worst code I've ever seen
165 2014-03-06 02:34:59 <lechuga_> i'd argue most code is terrible
166 2014-03-06 02:35:08 <lechuga_> it's the norm not the exception
167 2014-03-06 02:35:26 <Ademan> not my code! /s
168 2014-03-06 02:35:33 <olalonde> is there a tool to build custom scripts using OP codes?
169 2014-03-06 02:35:51 <dexX7> fyi: https://blog.blockchain.com/2014/03/05/occasional-unconfirmed-transactions-are-being-addressed/
170 2014-03-06 02:35:53 <olalonde> without having to edit the binary directly
171 2014-03-06 02:40:00 <Ademan> olalonde: you could cook something up really easily with python-bitcoinlib
172 2014-03-06 02:40:19 <olalonde> Ademan: thanks. just found out about it actually
173 2014-03-06 02:47:23 <Ademan> Anyone else end up PM-ed by RandDev ?
174 2014-03-06 02:48:53 <jcorgan> Ademan: i've spent a bit of time in State of California's sacramento datacenter (a long time ago). eww.
175 2014-03-06 02:54:17 <kjj> so, what is an appropriate reply to AIRCOINDEV 0? diaf?
176 2014-03-06 02:54:49 <Ademan> kjj: are nodes sending that on the network?
177 2014-03-06 02:55:26 <Ademan> oh is that a user?
178 2014-03-06 02:55:27 <kjj> no idea. does it interact with the network? I'm just reading my PMs on the forum, figured most of us got the same junk
179 2014-03-06 02:55:54 <Ademan> ah sorry, I was thinking something stupid
180 2014-03-06 02:56:04 <Ademan> jcorgan: haha, if you can share, what were you doing for them?
181 2014-03-06 03:00:01 <jcorgan> i was a field engineer for a company whose networking gear they had installed, and would go onsite to help them debug issues.
182 2014-03-06 03:01:32 <Ademan> I bet you have some stories as a field engineer
183 2014-03-06 03:01:48 <jcorgan> heh
184 2014-03-06 03:01:50 <jcorgan> yah
185 2014-03-06 03:07:50 <Ademan> anyone know if blockchain.info will ratelimit/ban me for frequent requests? I'm using a 1s wait but since I'm going through the entire blockchain that'll be like... 80 hours... not including my processing time...
186 2014-03-06 03:12:14 <SomeoneWeird> Ademan, wtf are you doing that for?
187 2014-03-06 03:12:54 <kjj> Ron needed to update his paper?
188 2014-03-06 03:14:01 <Ademan> SomeoneWeird: Curiosity, while we were discussing someone's transaction not showing confirmed on blockchain.info I noticed that the blockchain.info page for the block in question was missing ~200 transactions from it... so I'm scanning for other such blocks
189 2014-03-06 03:14:48 <kjj> it would probably be easier to just not use them as a serious data source. their quirks are legendary
190 2014-03-06 03:15:25 <SomeoneWeird> Ademan, right, that makes slightly more sense
191 2014-03-06 03:29:04 <sugarpuff> sipa: i'm calling the rolling-root 99.9% trustless once the current "window" of size X has been received: https://bitcointalk.org/index.php?topic=501039.msg5539097#msg5539097
192 2014-03-06 03:29:16 <sugarpuff> sipa: if i am wrong, please enlighten me
193 2014-03-06 03:30:19 <kjj> just page through dev&tech. enlightenment is there if you want to go looking for it
194 2014-03-06 03:30:43 <sugarpuff> kjj: constructive comments are welcome. others are not.
195 2014-03-06 03:31:26 <kjj> I'll be sure to keep that in mind
196 2014-03-06 03:32:53 <kjj> I really don't understand why you are discussing this. Clearly you've come up with an idea that no one ever has before. Now you just need to code it up and the whole world will switch to your fork.
197 2014-03-06 03:33:51 <sugarpuff> kjj: like, there's another unconstructive comment from you. do you want me to just ignore you? i'll pay attention when you actually talk about the merits of the proposal
198 2014-03-06 03:35:18 <kjj> you are already ignoring me. why do you think I'll be offended if you also stop reading me?
199 2014-03-06 03:36:18 <kjj> but if you read what I just wrote, skipping the sarcasm if you must, you'll fine enlightenment there.
200 2014-03-06 03:49:07 <sugarpuff> gmaxwell: thanks for the response, replied.
201 2014-03-06 04:21:50 <jtimon> I'm trying to run a node on testnet and be isolated, but I can't find any value for pchMessageStart for which there's no peers, what would be the simplest solution to achive what I want? (basically have 2 nodes locally, one with "bitcoin-qt -testnet -datadir=tmp -nolisten -connect=127.0.0.1:18333")
202 2014-03-06 04:21:50 <jtimon> should I mine another genesis block?
203 2014-03-06 04:21:51 <jtimon> is there many people doing this same thing and that's why I find unwanted peers?
204 2014-03-06 04:23:56 <gmaxwell> yea, usually you just run two nodes locally.
205 2014-03-06 04:25:46 <jtimon> so how do people find unused magic numbers fast? just trial an error?
206 2014-03-06 04:26:16 <jtimon> s/an/and
207 2014-03-06 04:28:42 <jtimon> maybe it would be simpler to have a -localtest flag that only connects to nodes in localhost or something?
208 2014-03-06 05:11:24 <jtimon> I must be doing something wrong, i don't think there can be so many people testing simultaneusly on so many different values for pchMessageStart on -testnet
209 2014-03-06 05:22:18 <kjj> dude. fix your connection
210 2014-03-06 05:49:48 <Ademan> they were quitting from excess flood, isn't that usually some form of spamming?
211 2014-03-06 05:50:18 <kjj> probably a script gone wrong.
212 2014-03-06 05:51:32 <kjj> typo in a script to automatically authenticate with nickserv, for example, causing a loop. Or it could just be a funny part message.
213 2014-03-06 05:54:56 <gmaxwell> Ademan: no, its a dumbness in freenode/irc.
214 2014-03-06 05:55:04 <gmaxwell> /clients.
215 2014-03-06 05:55:31 <gmaxwell> if you're in too many channels and get dissconnected on timeout, your client will emit joins too fast on reconnect and freenode will punt you again.
216 2014-03-06 05:55:52 <gmaxwell> Current irssi appears not to have the problem but a lot of other ones do.
217 2014-03-06 05:59:01 <Ademan> ah
218 2014-03-06 06:08:39 <michagogo> cloud|gmaxwell: iirc it's often not just joins
219 2014-03-06 06:08:52 <michagogo> cloud|But perhaps other commands, such as /who
220 2014-03-06 06:10:25 <Ademan> bitcoin-qt doesn't have different RPC commands than bitcoind does it? I'm not sure why my bitcoin-qt (from the Ubuntu PPA) doesn't like getblock $hash False as best I can tell from git blame, the second (verbose) parameter has been around for a pretty long time
221 2014-03-06 06:11:24 <michagogo> cloud|Ademan: verbose isn't in 0.8.6
222 2014-03-06 06:11:44 <michagogo> cloud|You'll need to run from git
223 2014-03-06 06:11:51 <michagogo> cloud|(Or 0.9.0rc2)
224 2014-03-06 06:12:13 <michagogo> cloud|bitcoin.org/bin/
225 2014-03-06 06:12:18 <kjj> just skip that parameter?
226 2014-03-06 06:12:34 <michagogo> cloud|kjj: that doesn't give you the block in hex
227 2014-03-06 06:12:53 <michagogo> cloud|Basically, 0.8.6 only does verbose
228 2014-03-06 06:13:21 <michagogo> cloud|0.9 adds a flag, true by default, to give you the raw block instead
229 2014-03-06 06:13:26 <kjj> ahh
230 2014-03-06 06:13:46 <michagogo> cloud|Erm, you set it to false for the raw block
231 2014-03-06 06:15:37 <Ademan> oh derp, the code could be old but still not in the release, got it heh
232 2014-03-06 06:16:31 <michagogo> cloud|Ademan: yeah, 0.8.(3..6) forked off from 0.8.2
233 2014-03-06 06:17:05 <michagogo> cloud|Anything that was merged after 0.8.2 may not be in 0.8.(3..6)
234 2014-03-06 06:17:47 <dexX7> does the mem pool only contain transactions that are not yet in a block?
235 2014-03-06 06:18:13 <michagogo> cloud|dexX7: yes
236 2014-03-06 06:19:29 <dexX7> thanks. and is there any way to get some kind of notification, if a new transaction (or block) was seen, instead of pulling the info?
237 2014-03-06 06:19:34 <Ademan> woo thunder!
238 2014-03-06 06:19:48 <kjj> like -walletnotify and -blocknotify?
239 2014-03-06 06:20:22 <dexX7> awesome, thanks!
240 2014-03-06 06:25:39 <dexX7> as far as i can see walletnotify does not report any, but only wallet related transactions?
241 2014-03-06 06:26:10 <kjj> oh, right. there is no way to get a notification on non-wallet transactions
242 2014-03-06 06:26:25 <kjj> but I suppose you could troll your debug.log
243 2014-03-06 06:27:16 <comboy> is tihs something new? http://eprint.iacr.org/2014/161.pdf
244 2014-03-06 06:27:46 <dexX7> haha yea, that should work
245 2014-03-06 06:29:02 <gmaxwell> comboy: new paper, though the only thing news about it is that they apparently implemented it (and maybe that they needed only ~200 samples)
246 2014-03-06 06:29:40 <gmaxwell> (e.g. we knew that openssl made no effort at timing/side-channel attack resistance for our curve)
247 2014-03-06 06:29:54 <Ademan> gmaxwell: ?!
248 2014-03-06 06:30:07 <comboy> gmaxwell: I'm suprised it's under 200, seems scary
249 2014-03-06 06:30:24 <Ademan> if there was any library anywhere I'd expect to be robust to that sort of thing... it'd be OpenSSL
250 2014-03-06 06:30:35 <gmaxwell> comboy: it requires running a tightly coupled process on the same host which is able to trigger l3 cache flushes.
251 2014-03-06 06:30:54 <kjj> as in, if you are already owned...
252 2014-03-06 06:31:15 <comboy> gmaxwell: ok, I did not understand it at all
253 2014-03-06 06:31:21 <comboy> yeah, I'm dumb
254 2014-03-06 06:31:26 <jcorgan> Ademan: your faith in OpenSSL is...disturbing :)
255 2014-03-06 06:31:44 <Ademan> comboy: It's not really a practical attack
256 2014-03-06 06:31:47 <gmaxwell> well, it's still not great. if you'd asked me a week ago I would have said ~2000-20000 probes for a local process, millions for one across a network.
257 2014-03-06 06:31:52 <gmaxwell> Ademan: it may be in some enviroments.
258 2014-03-06 06:32:29 <gmaxwell> there are a lot of bitcoin businesses running on VPSes, not clear to me how well it would work across a virtualization enviroment (certantly would add more noise).
259 2014-03-06 06:33:08 <gmaxwell> of course, avoiding address reuse mostly kills it but it would be prudent to use a constant time / constant memory access signing implementation in any case.
260 2014-03-06 06:34:03 <Ademan> haven't there been a few VM escape exploits? I wouldn't trust a VM in a multi-tenant environment with lots of BTC...
261 2014-03-06 06:35:54 <maaku> I wouldn't trust a multi-tenant environment with lots of BTC....
262 2014-03-06 06:36:15 <Ademan> heh fair enough
263 2014-03-06 06:37:02 <gmaxwell> yea, well but people do.
264 2014-03-06 06:38:36 <Ademan> so has this bitcoin/secp256k1 been audited at all?
265 2014-03-06 06:39:20 <gmaxwell> what are you referring to specifically?
266 2014-03-06 06:39:32 <gmaxwell> libscep256k1 or?
267 2014-03-06 06:39:35 <Ademan> sorry, the actual library https://github.com/bitcoin/secp256k1
268 2014-03-06 06:39:59 <gmaxwell> Yes, it's been audited but it needs more auditing, it's been brutally hard to get people to look at it.
269 2014-03-06 06:40:44 <gmaxwell> though TBH I wouldn't be surprised if at this point it's had more inspection than the parallel openssl code. :( In any case, it still doesn't have constant time/memory access signing yet.
270 2014-03-06 06:43:07 <Ademan> well signing is a relatively rare occurrence isn't it? If it verifies faster it's probably a massive win overall for bitcoin's usage
271 2014-03-06 06:44:15 <gmaxwell> the whole point of the library is to be faster.
272 2014-03-06 06:44:30 <gmaxwell> It's like 6x faster than openssl on x86_64.
273 2014-03-06 06:44:48 <gmaxwell> but it should also have constant time signing to address things like that paper.
274 2014-03-06 06:45:05 <gmaxwell> (and the constant time signing will be slow, but no one cares.)
275 2014-03-06 06:46:07 <Ademan> ah, right I was thinking something really stupid by "constant time", not security oriented
276 2014-03-06 06:48:05 <tarix_jp> was pondering the malleability a bit and wondered if this is a valid use. one has a POS system for bitcoin and a user pays without adding a fee. can you rebroadcast a new transaction to add an extra input with a fee? obviously only one goes through and you don't care much which one, but the idea is to push a free transaction into the paid blocks and re-send that to miners.
277 2014-03-06 06:55:21 <kadoban> tarix_jp: that's not actually malleability
278 2014-03-06 06:56:24 <tarix_jp> let's say Bitcoin Android Wallet sends a transaction to BitPay/Coinbase and then Bitpay/Coinbase add an extra input to add the fee. that's manipulating a transaction that they didn't create isn't it?
279 2014-03-06 06:56:58 <tarix_jp> it seems valid since each input is signed independently, and of course merchant service wallets don't care which transaction gets confirmed.
280 2014-03-06 07:02:46 <gmaxwell> tarix_jp: they aren't signed completely independantly unless you are using ANYONECANPAY
281 2014-03-06 07:03:11 <gmaxwell> in sighash all the signatures are independant of other signatures, but not the coins being spent.
282 2014-03-06 07:03:26 <gmaxwell> but indeed, a third party can add fees if you use ANYONECANPAY
283 2014-03-06 07:04:26 <tarix_jp> which requires the wallet to create the "right" kind of transaction for pos and others are already working on better systems anyway.
284 2014-03-06 07:08:33 <gribble> jtimon was last seen in #bitcoin-dev 1 hour, 57 minutes, and 8 seconds ago: <jtimon> I must be doing something wrong, i don't think there can be so many people testing simultaneusly on so many different values for pchMessageStart on -testnet
285 2014-03-06 07:08:33 <michagogo> cloud|;;seen jtimon
286 2014-03-06 07:08:40 <michagogo> cloud|Oh
287 2014-03-06 08:05:46 <tlrobinson> if you were to pick an ideal existing serialization scheme (protobufs, msgpack, asn.1, etc) to replace the hodgepodge that is the bitcoin protocol(s) currently, what would you pick and why?
288 2014-03-06 08:12:32 <wumpus> tlrobinson: satoshi commented on that: https://bitcointalk.org/index.php?topic=632.15
289 2014-03-06 08:12:57 <wumpus> basically he didn't want to rely on an external serialization library: too many unknowns
290 2014-03-06 08:13:26 <gmaxwell> tlrobinson: absolutely none of them (well: I am not familar with msgpack), they all have underspecified behaviror, malleability, non-canonical encoding that leads to failure on roundtripping. Basically every serious technical complaint we've had about the encoding other than alt implementers complaining about actually having to code. :)
291 2014-03-06 08:14:09 <gmaxwell> the places where satoshi did use external seralization (e.g. der encoding from openssl) turned out to be problematic too. :(
292 2014-03-06 08:15:52 <wumpus> the inconsistency is what makes it a hodgepodge: if only he just had sticked with his serialization scheme everywhere, and not used DER for public keys for example
293 2014-03-06 08:18:35 <tlrobinson> not to mention inconsistent endianness, and now protobufs in bip 70 :)
294 2014-03-06 08:20:09 <wumpus> nah bad example, bip 70 is an external protocol for user/merchant interaction, it doesn't interface with the protocol or blockchain in any way
295 2014-03-06 08:25:34 <Goonie> morning!
296 2014-03-06 08:25:50 <wumpus> morning
297 2014-03-06 08:27:23 <tlrobinson> wumpus: ok well i was asking because i'd like something like the previously discussed zeromq support https://github.com/bitcoin/bitcoin/pull/2415 but perhaps with a serialization that's easier to parse in a variety of languages
298 2014-03-06 08:28:40 <tlrobinson> (sort of like what mongrel2 does for http)
299 2014-03-06 08:29:20 <wumpus> json-over-zmq as used in that pull was fine -- the reason that it was closed is twofold: 1) bitcoind is not modular enough yet to integrate alternative RPC schemes without making the code a mess 2) the comments were not addressed, ie it allowed all RPC commands without authentication
300 2014-03-06 08:30:47 <gmaxwell> tlrobinson: if you mean for things like bitcoin transaction data, you can't really change the serialization and do anything with it. E.g. if I give you a transaction which has been reseralized into another form, and I ask you to spend itâ you can't because doing so requires hashing the data in the original serialization. (unless you do something kinda ugly and send both a decode and the original data)
301 2014-03-06 08:30:49 <wumpus> (that was also before autotools; we can now cope slightly better with optional dependencies)
302 2014-03-06 08:36:55 <tlrobinson> makes sense, i think. my immediate use case was to dump blocks/txs into a database, in which case i suppose including the hash as another field would be sufficient, but that might not be as useful in the general case
303 2014-03-06 08:37:58 <wumpus> gmaxwell: but in a way that's what decoderawtransaction / createrawtransaction does, it converts from tx serialization to/from json, so before the signing stage it can make some sense
304 2014-03-06 08:38:32 <gmaxwell> yup. including the original serialization too.
305 2014-03-06 08:38:48 <wumpus> aha, that's an example of the 'ugly' :<
306 2014-03-06 08:39:53 <gmaxwell> hm. actually decoderaw doesn't, I stand corrected. Things like getrawtransaction with the decode argument do...
307 2014-03-06 08:40:09 <gmaxwell> and I don't really have a problem with it, it's ugly however, but I've personally found it pretty useful.
308 2014-03-06 08:40:42 <gmaxwell> (I guess it makes sense decode doesn't since you actually send that as an input. :) )
309 2014-03-06 08:41:05 <gmaxwell> anyways, point was that for anything where the data gets hashed (e.g. signing, spending) you need the original serailzation.
310 2014-03-06 08:41:08 <wumpus> in any case those are just utility methods, they could just as well be an external library, having them RPCs is just a way to avoid having to make an implementation in every language and/or mess around with bindings :p
311 2014-03-06 08:41:30 <gmaxwell> wumpus: they also make bitcoin-cli a useful cli client.
312 2014-03-06 08:42:03 <wumpus> a cli could implement them cilent-side too :-)
313 2014-03-06 08:42:41 <gmaxwell> it's trueâ then that would make the RPC very hard to use if you end up having to then reimplement the friendly interafaces in every application where you need them. :P
314 2014-03-06 08:42:44 <TD> good morning
315 2014-03-06 08:42:44 <wumpus> we've chosen to make bitcoin-cli a thin RPC client as that's most straightforward and RPC has the utility functions
316 2014-03-06 08:42:55 <wumpus> a bit of a chicken and egg
317 2014-03-06 08:43:25 <gmaxwell> well its also a learning curve thing to have good agreement between the rpc and cli where doing so makes sense.
318 2014-03-06 08:43:26 <wumpus> gmaxwell: yes, that's what i meant with the client-side library and bindings for every language
319 2014-03-06 08:43:34 <gmaxwell> okay that works too.
320 2014-03-06 08:43:45 <wumpus> not saying it'd be better but it was just a choice
321 2014-03-06 08:44:23 <gmaxwell> right, would probably be a lot faster than decoding data to json, seralizing to json, deseralizing json, etc. :P oh well.
322 2014-03-06 08:44:51 <wumpus> yep! especially when the RPC server is another machine
323 2014-03-06 08:45:50 <wumpus> then one could make a super-stripped down RPC interface with just the commands that require actual connection to the network and/or control bitcoind execution
324 2014-03-06 08:45:59 <wumpus> nah
325 2014-03-06 08:46:33 <gmaxwell> rpc is already pretty slow, I was doing some blockchain analysis, last week which involved doing a getraw on every transactions inputs, and I rewrote my analysis code in C++ (from the original python/rpc code) in the time the python/rpc analyized 10 blocks. (and then the C++ code ran at several blocks per second)
326 2014-03-06 08:46:35 <wumpus> next is 'you don't need sendrawtransaction you can just do it over P2P fool!'
327 2014-03-06 08:47:11 <wumpus> the RPC interface is always a compromise between minimalism and usability
328 2014-03-06 08:48:02 <wumpus> yes, RPC is slow, it was never designed for pumping over large amounts of data
329 2014-03-06 08:48:47 <jouke> gmaxwell: the python code worked with RPC, and your C++ code worked with the blockfiles?
330 2014-03-06 08:49:29 <gmaxwell> no c++ code inside bitcoind, that used the same codepaths the rpc used, but without the seralize+socket+deseralize/python overhead.
331 2014-03-06 08:50:02 <gmaxwell> er to make that clear I should have written "no," instead of "no"
332 2014-03-06 08:50:18 <jouke> ok :)
333 2014-03-06 09:16:06 <finway> anybody see this ? http://eprint.iacr.org/2014/161.pdf
334 2014-03-06 09:16:25 <finway> OpenSSL / Bitcoin implementation of ECDSA Flaw discovered (beta.slashdot.org)
335 2014-03-06 09:16:26 <finway> http://www.reddit.com/r/Bitcoin/comments/1zp4ck/openssl_bitcoin_implementation_of_ecdsa_flaw/
336 2014-03-06 09:22:49 <gmaxwell> finway: someone decided they wanted to manipulate markets with a crappy sensationalist headline I guess. Yea, we're aware of it.
337 2014-03-06 09:23:25 <finway> gmaxwell, so it's not a serious problem ?
338 2014-03-06 09:23:39 <gmaxwell> I don't think any of it is really news to us except: (1) they actually apparently implemented it, and (2) that it sometimes works with 200 probes instead of 1000s. It requires the ability to run code on the same machine as the signer and to get it to do lots of signatures with the same key on demand.
339 2014-03-06 09:25:16 <finway> gmaxwell: i guess so,thanks.
340 2014-03-06 09:26:07 <sipa> gmaxwell: my implementation has uniform memory access, iirc
341 2014-03-06 09:26:41 <sipa> gmaxwell: but there are a few possible branches still (if you accidentally hit the same point as you're adding or its opposite)
342 2014-03-06 09:27:02 <finway> sipa: funny
343 2014-03-06 09:28:22 <gmaxwell> sipa: I think I totally missed adding constant time stuff to it. I don't think I've looked at any of that code.
344 2014-03-06 09:28:58 <gmaxwell> uh
345 2014-03-06 09:29:56 <sipa> gmaxwell: so what i do (iirc, it's been a while), is have precomputed multiples of the form a*16^n*G, with a between 1 and 4, and n 0 through 63
346 2014-03-06 09:30:27 <sipa> gmaxwell: then pick bits in groups of 4 from the multiplicand, pick that G multiple, and add it
347 2014-03-06 09:30:51 <sipa> then in the end subtract (1+16+256+4096+...)*G
348 2014-03-06 09:31:20 <sipa> and those G multiples are striped per byte in memory
349 2014-03-06 09:32:06 <sipa> a between 1 and 16
350 2014-03-06 09:32:09 <gmaxwell> CodeShark: so while looking at the history of that repository, FieldElem::IsZeroCT() return (n[0] == 0 && n[1] == 0 && n[2] == 0 && n[3] == 0 && n[4] == 0); ... you know that && is shortcutting (it _must_ be shortcutting, in fact, its not optional)
351 2014-03-06 09:32:56 <CodeShark> yeah, not all functions in that library are constant-time
352 2014-03-06 09:34:36 <gmaxwell> CodeShark: that particular diff added several "*CT" operations and at least to of them weren't. :P
353 2014-03-06 09:34:51 <CodeShark> which file, which commit?
354 2014-03-06 09:35:14 <gmaxwell> it's an old commit, 8803181c6178a39129b15f21f70aaa2553f56c49 I think this isn't in the current code. field.cpp
355 2014-03-06 09:35:44 <gmaxwell> I only mentioned it in case you actually didn't know that rather than it being temporary thing or a momentary brainfart.
356 2014-03-06 09:36:21 <CodeShark> are you talking about CodeShark/cmp?
357 2014-03-06 09:36:46 <gmaxwell> sipa: interesting!
358 2014-03-06 09:36:57 <gmaxwell> CodeShark: no commits in sipa's libsecp256k1
359 2014-03-06 09:37:03 <CodeShark> oh
360 2014-03-06 09:37:18 <CodeShark> yeah, we started working on constant-time implementations, but never finished
361 2014-03-06 09:38:03 <CodeShark> constant time would be return ~(n[0] | n[1] | n[2] | n[3] | n[4])
362 2014-03-06 09:38:39 <CodeShark> err, &
363 2014-03-06 09:38:58 <CodeShark> err, I'm tired :p
364 2014-03-06 09:39:04 <gmaxwell> yea yea don't worry.
365 2014-03-06 09:39:23 <sipa> gmaxwell: i believe the result may actually be timing-attack free, as the only way to hit one of the branches is by having a multiplication that ends up with the point at infinity near the end of the algorithm (which means the signature is potentially not even valid)
366 2014-03-06 09:39:46 <sipa> wait, that's a too strong statement
367 2014-03-06 09:40:31 <sipa> anyway, i believe (but will certainly not promise) that it may in practice be resistant to cache timimg
368 2014-03-06 09:40:35 <CodeShark> return !(n[0] | n[1] | n[2] | n[3] | n[4])
369 2014-03-06 09:41:30 <gmaxwell> as I've said before I think, timing attack free is probably impossible to be sure of (1) in C, unless you audit the asm yourself, and/or (2) running on modern hardware...
370 2014-03-06 09:41:37 <gmaxwell> but certantly there are degrees⦠:)
371 2014-03-06 09:41:51 <CodeShark> you mean the compiler could subvert your efforts? :)
372 2014-03-06 09:42:08 <gmaxwell> Absolutely. There is no promises in the timing behavior of the code.
373 2014-03-06 09:42:21 <sipa> you can make it arbitrarily hard for the compiler, i think
374 2014-03-06 09:42:33 <gmaxwell> Sure, sure, but its still hard to be sure.
375 2014-03-06 09:42:41 <CodeShark> wouldn't it be fairly easy to scan the asm for branch instructions?
376 2014-03-06 09:43:10 <sipa> well you can just implement a constant-time compare operation is assembly...
377 2014-03-06 09:43:19 <gmaxwell> branches aren't the only way to get timing differences though, cache behavior does too. (E.g. data dependant memory accesses)
378 2014-03-06 09:43:21 <CodeShark> but even if you write it in C
379 2014-03-06 09:43:38 <CodeShark> how can you have data-dependent memory access if you're always using the same inputs everywhere?
380 2014-03-06 09:43:42 <gmaxwell> CodeShark: that was my "audit the asm"
381 2014-03-06 09:44:30 <CodeShark> that's to say, there's no pointer arithmetic taking place
382 2014-03-06 09:45:09 <CodeShark> or at least no data-dependent pointer arithmetic
383 2014-03-06 09:45:10 <gmaxwell> well for example it can reorder the accesses, so for example code that works by accessing two things and throwing away one could be subverted by the compiler.
384 2014-03-06 09:45:21 <antephialtic> disable optimizations for crypto code?
385 2014-03-06 09:45:24 <gmaxwell> (same kinds of optimizations that surprise people in concurrent software)
386 2014-03-06 09:45:41 <CodeShark> I think you could make it essentially impossible for the compiler to optimize certain things
387 2014-03-06 09:45:51 <sipa> pretty sure that libsecp256k1 is resistant to the attack in that paper; it does not have direct branches because of bits set in the multiplicant
388 2014-03-06 09:46:01 <TD> when can we switch? :)
389 2014-03-06 09:46:03 <gmaxwell> sipa: go ask them? :P
390 2014-03-06 09:46:13 <antephialtic> so absent 1) data dependent branching, 2) data dependent array indexing, compiler optimizations can still make timing attacks possible?
391 2014-03-06 09:46:41 <gmaxwell> CodeShark: you can try. And probably be successful. And hope next year as smarter compiler doesn't come along.
392 2014-03-06 09:47:01 <gmaxwell> In any case, I just encourage caution about saying that something is completely free.
393 2014-03-06 09:47:26 <CodeShark> if you're really paranoid about the compiler, you could even use some form of masking with arbitrary inputs that don't get specified until after compilation
394 2014-03-06 09:47:29 <gmaxwell> Esp since _power_ analysis is much harder to control, and there can be software accessible ways to perform power analysis (e.g. record with a soundcard)
395 2014-03-06 09:47:52 <antephialtic> actually this is a quote from djb "Even on architectures that support fast constant-time conditional-move instructions, always assume that a comparison in C is compiled into a branch, not a conditional move. Compilers can be remarkably stupid."
396 2014-03-06 09:48:13 <CodeShark> but anyhow, I think a cursory examination of the machine code could demonstrate that the three conditions antephialtic mentioned are satisfied
397 2014-03-06 09:48:26 <gmaxwell> antephialtic: the compiler isn't always stupid wrt cmov ... on p4 it stalled the pipeline, on later processors its basically the same speed as the branch. :P
398 2014-03-06 09:48:33 <sipa> gmaxwell: the method i'm using can be adapted to be initialized with a random (secret) multiplicant, and then in the end subtract it
399 2014-03-06 09:48:54 <sipa> gmaxwell: of course, perhaps there is way that secret can leak as well
400 2014-03-06 09:49:19 <CodeShark> the secret multiplicant could be hardcoded after compilation
401 2014-03-06 09:49:19 <gmaxwell> sipa: right, still another degree of freedom. In a signature you already have the secret r factor.
402 2014-03-06 09:49:34 <CodeShark> the point is only to make it impossible for the compiler to optimize
403 2014-03-06 09:49:45 <CodeShark> once compilation is complete, you can make that multiplicant a hardcoded constant
404 2014-03-06 09:49:46 <gmaxwell> CodeShark: there isn't realy an optimization threat there.
405 2014-03-06 09:50:30 <gmaxwell> sadly it's really hard to include a in-distribution unit test for this stuff... since timing tests aren't terribly reliable in the field.
406 2014-03-06 09:50:36 <CodeShark> in any case, I'm pretty certain it's possible to satisfy the three conditions antephialtic mentioned without the need for extremely sophisticated tools
407 2014-03-06 09:50:37 <gmaxwell> and false postives stink.
408 2014-03-06 09:51:16 <gmaxwell> CodeShark: you are _still_ not guarenteed sidechannel freeness even with all of that and more.
409 2014-03-06 09:51:29 <gmaxwell> (though indeed you can be much closer)
410 2014-03-06 09:51:56 <sipa> CodeShark: the code is indeed independent of which secret constant you choose; it can be determined at runtime
411 2014-03-06 09:52:15 <gmaxwell> it's just a form of blinding.
412 2014-03-06 09:52:15 <sipa> (there is a bit of preprocessing, but that is not data dependent in any case)
413 2014-03-06 09:52:29 <sipa> but it is not constant time
414 2014-03-06 09:52:43 <CodeShark> the business of security is not about making attacks by determined, motivated, well-resourced individuals impossible - it's about just making attacks hard enough so that attackers either lack the motivation or the resources
415 2014-03-06 09:52:58 <gmaxwell> CodeShark: I think you're arguing with someone who isn't me.
416 2014-03-06 09:52:58 <sipa> there are still branches inside (though thenodds of hitting them is astronomically small, i THINK)
417 2014-03-06 09:53:50 <CodeShark> we're only smart enough to devise systems that we ourselves can't break, after all :p
418 2014-03-06 09:54:25 <gmaxwell> CodeShark: absolutely nowhere have I suggested getting the most constant time we can realistically achieve is bad. I'm just cautioning against saying its free of sidechannels, because then someone will say "I can put this on a shared host, and reuse keys, and have no risk" and thats not true. Not only do we not know what we don't knowâ we actually know this promise is unusually hard to make.
419 2014-03-06 09:54:38 <CodeShark> I'm not arguing for complacency :)
420 2014-03-06 09:54:54 <CodeShark> there are plenty of other attack vectors that are far simpler in practice in most deployments of bitcoin wallets
421 2014-03-06 09:55:02 <gmaxwell> oh sure.
422 2014-03-06 09:55:25 <gmaxwell> sipa: maybe the authors of that paper would like to do a second one about analyizing and hardening your implementation. :P
423 2014-03-06 09:56:27 <gmaxwell> playing around with the blinding approach sounds like a nice science project for someone.
424 2014-03-06 09:56:42 <gmaxwell> sipa: hm I see your constant timeness is not uniform between the different field implementations.
425 2014-03-06 09:57:00 <gmaxwell> e.g. secp256k1_fe_is_zero in field_10x26.h vs field_gmp.h
426 2014-03-06 09:57:02 <Diablo-D3> gmaxwell: hey, do any of the payment gateways secure their wallets with m-of-n addresses?
427 2014-03-06 09:57:26 <gmaxwell> at least there are nice todo's in the code.
428 2014-03-06 09:58:27 <sipa> gmaxwell: hmm, those seem like an easy target fornfurther hardening
429 2014-03-06 10:00:35 <gmaxwell> in any case, wouldn't be hard to setup a test shim that times the multiply using the TSC over and over again and tested withâ say, keys with low and high hamming weights and see if they're classifyable by time.
430 2014-03-06 10:01:38 <sipa> gmaxwell: seems i misremember and don't stripe by byte
431 2014-03-06 10:02:17 <gmaxwell> yea, so indeed there is a cache locality leak then.
432 2014-03-06 10:02:41 <sipa> which means you may get some cache timing from doing multiple multiplications with numbers that share bit sequences
433 2014-03-06 10:03:38 <gmaxwell> I hate that there is so pressure against publishing negative results.
434 2014-03-06 10:04:09 <gmaxwell> it's a reason why people working on this would be uninterested in attempting to attack something believed to be strongerâ too likely to get a negative result.
435 2014-03-06 10:05:13 <sipa> well, at least their interests align with those of actual attackers :)
436 2014-03-06 10:05:38 <sipa> you don't needbto outrun the tiger, just your friend
437 2014-03-06 10:05:54 <CodeShark> I'm still looking forward to dedicated hardware for signing :)
438 2014-03-06 10:06:35 <gmaxwell> hah
439 2014-03-06 10:06:40 <CodeShark> dedicated hardware with its own power supply, of course:)
440 2014-03-06 10:07:26 <gmaxwell> CodeShark: power analysis resistance is just miserably hard.
441 2014-03-06 10:07:29 <sipa> gmaxwell: do we need to supportnhardware with cache lines less than 16 bytes? :p
442 2014-03-06 10:07:53 <gmaxwell> sipa: no.
443 2014-03-06 10:07:57 <vegard> maybe it's easier to introduce some random delays/memory accesses into the computation to mask the leaked information?
444 2014-03-06 10:08:24 <gmaxwell> vegard: often doesn't help.
445 2014-03-06 10:08:35 <gmaxwell> probably most effective against remote attacks.
446 2014-03-06 10:08:56 <gmaxwell> but local attacks can measure things like cache sidechannels without actually timing the operation.
447 2014-03-06 10:09:03 <antephialtic> how would you go about exploiting this in practice
448 2014-03-06 10:09:52 <antephialtic> just go start/stopping up a bunch of ec2 instances, exploiting the cache info until you were sure that one was loading the shared lib for ecdsa signing in openSSL?
449 2014-03-06 10:10:25 <antephialtic> (this is all hypothetical of course)
450 2014-03-06 10:10:25 <CodeShark> as for power analysis resistance, if you're using a Haswell chip, chances are signing operations are practically indistinguishable from noise - but if you're using a small, low-power microcontroller it's a different story
451 2014-03-06 10:10:42 <gmaxwell> Nah, in pratice its useful only in a very targeted sense. Like if there is a frontend and a backend server on the same host and you cracked the front end.
452 2014-03-06 10:11:44 <antephialtic> hmm. I was under the impression that this could be exploited by anyone running on the same vm as you
453 2014-03-06 10:12:07 <gmaxwell> antephialtic: yes but you have to actually know its there and know how to trigger it to sign.
454 2014-03-06 10:12:17 <gmaxwell> otherwise you're measuring rather faint noise.
455 2014-03-06 10:17:40 <antephialtic> gmaxwell: yes that seems to be the case. seems like a vulnerability that one would need quite a bit of expertise to use in practice.
456 2014-03-06 10:18:16 <CodeShark> smart company policies and good tools to create them and enforce them is where it's at :)
457 2014-03-06 10:18:53 <CodeShark> all the technology in the world can't save you from stupid policy
458 2014-03-06 10:19:26 <gmaxwell> sipa: the smallest cacheline I can find on anything I think we might run on, and can find spec for is the 486's L1 had a 16 byte cacheline.
459 2014-03-06 10:19:58 <gmaxwell> antephialtic: sure sure, though thats the case for many things.
460 2014-03-06 10:20:26 <gmaxwell> because of things like VM escapes and other data leaks I think running anything high value on shared hardware is mildly crazy to begin with.
461 2014-03-06 10:20:46 <CodeShark> redundancy and rotation :)
462 2014-03-06 10:21:43 <CodeShark> and a little unpredictability to throw your adversary off
463 2014-03-06 10:22:01 <CodeShark> but not so much unpredictability that you confuse yourself
464 2014-03-06 10:22:05 <antephialtic> yeah, I would only use shared servers for something low-value. Like say, trading magic the gathering cards.
465 2014-03-06 10:22:11 <CodeShark> haha
466 2014-03-06 10:22:41 <gmaxwell> CodeShark: yea, I have mixed feeling about things like trying to blind operations ... maybe it throws off attacks, but maybe it adds bugs that create weaknesses.
467 2014-03-06 10:34:32 <anton000> currently how big is the testnet blockchain?
468 2014-03-06 10:48:51 <stonecoldpat> am i right in thinking, listsinceblock will give me a list of all transactions from a given block? so just an array of transactions?
469 2014-03-06 10:48:58 <stonecoldpat> an array of the transaction hash?
470 2014-03-06 10:49:58 <sipa> stonecoldpat: https://github.com/bitcoin/bitcoin/blob/master/src/rpcwallet.cpp#L1360
471 2014-03-06 10:50:01 <sipa> RTFM :)
472 2014-03-06 10:53:07 <stonecoldpat> ah ok, thanks :)
473 2014-03-06 10:57:21 <hno> anton000, 519M
474 2014-03-06 10:59:38 <hno> anton000, or 485M if only counting blocks.
475 2014-03-06 11:02:31 <sheepman> when I run the gettxoutsetinfo what does the total_amount actually equate to? I'm confused.
476 2014-03-06 11:04:58 <gmaxwell> sipa: heh. I've 'instrumented' the binary to detect private key dependant branches... it appears to be free of them in a simple signing test, ... one I turned off asserts. :)
477 2014-03-06 11:08:48 <gmaxwell> hm. secp256k1_ecmult_gen->secp256k1_num_shift->__gmpn_rshift has a branch.
478 2014-03-06 11:10:42 <gmaxwell> sipa: num_gmp.h:246 data conditional branch there.
479 2014-03-06 11:10:56 <sipa> sheepman: the sum of the values of all unspent transaction outputs
480 2014-03-06 11:11:20 <sipa> gmaxwell: oh at the low level i'm sure there are dependencies
481 2014-03-06 11:11:30 <sheepman> sipa: Still above me I'm afraid, but I won't waste your time... I'll do some reading :) Thanks
482 2014-03-06 11:15:52 <sipa> sheepman: every transaction creates outputs (of a particular value, assigned to an address/script) and consumes older outputs created by previous transactions
483 2014-03-06 11:16:20 <sheepman> i see
484 2014-03-06 11:17:32 <gmaxwell> sipa: in any case, I think thats all I'm seeing right now, but I might find more if I twiddle harder... I have valgrind doing this.
485 2014-03-06 11:17:44 <sipa> gmaxwell: that's very useful :)
486 2014-03-06 11:18:24 <gmaxwell> ah, got more in gmp.
487 2014-03-06 11:18:35 <gmaxwell> secp256k1_num_mod_mul->secp256k1_num_mod->__gmpn_sub_n
488 2014-03-06 11:18:50 <gmaxwell> some of these may actually be clear of the badness or uninteresting.
489 2014-03-06 11:19:43 <gmaxwell> in any case, I think I can add not too obstructive instrumentation to the code that makes it possible to use valgrind to measure this. :) won't replace performance measurement and review, but at least it should be helpful.
490 2014-03-06 11:20:13 <sipa> i just implemented cache striping, but haven't pushed it
491 2014-03-06 11:20:22 <gmaxwell> did it slow it down, or speed it up?
492 2014-03-06 11:20:53 <sipa> didn't try
493 2014-03-06 11:21:01 <sipa> i don't have good performance measurements for signing
494 2014-03-06 11:21:44 <gmaxwell> I have a keygen benchmark here so I can try it later.
495 2014-03-06 11:27:29 <BabySuperman> how does someone not just listen for your proof of work and fake that they sent it?
496 2014-03-06 11:41:13 <airbreather> BabySuperman, your proof-of-work is only valid for the exact problem you're trying to solve, which includes a payment to yourself. If someone tried to use your proof-of-work for a block that pays them instead, then other nodes will reject their block as invalid
497 2014-03-06 11:42:39 <airbreather> thus the use of the term "proof"
498 2014-03-06 11:54:56 <chichov> is the transaction replacement mechanism not yet implemented?
499 2014-03-06 12:26:41 <venzen> hi there HeySteve
500 2014-03-06 12:27:07 <venzen> wrong wondow...
501 2014-03-06 12:44:58 <michagogo> cloud|12:22:08 <antephialtic> yeah, I would only use shared servers for something low-value. Like say, trading magic the gathering cards.
502 2014-03-06 12:45:13 <michagogo> cloud|Apparently some MtG cards are actually quite valuable
503 2014-03-06 12:47:11 <anton000> @hno thnx!
504 2014-03-06 13:23:40 <edcba> I like when people speak to journalists and act surprised something they told finish in a newspaper...
505 2014-03-06 13:26:07 <michagogo> cloud|edcba: referring to Gavin?
506 2014-03-06 13:26:21 <edcba> generalizing :)
507 2014-03-06 13:26:26 <michagogo> cloud|He may not have realized or known what the article was
508 2014-03-06 13:27:01 <michagogo> cloud|For all we know the relevant questions were slipped into a more general discussion
509 2014-03-06 13:27:08 <edcba> anyway the rule always has been : don't speak to journalists
510 2014-03-06 13:27:12 <michagogo> cloud|Wait, this is -dev...
511 2014-03-06 13:30:11 <TD> edcba: i guess that would refer to satoshi himself :)
512 2014-03-06 13:44:30 <finway> So satoshi is back?
513 2014-03-06 13:45:22 <anton000> lolololol
514 2014-03-06 13:45:47 <SomeoneWeird> ACTION facepalms
515 2014-03-06 13:50:09 <TD> what's up with martti saying the code uses "reverse polish notation". i hope that's a mental transcription error by the journo
516 2014-03-06 13:50:35 <vegard> for the scripts, no?
517 2014-03-06 13:52:22 <emowataji> thinking of hungarian?
518 2014-03-06 13:52:40 <TD> yeah
519 2014-03-06 13:52:44 <TD> he meant hungarian
520 2014-03-06 13:53:00 <vegard> wait... the scripts use reverse polish notation, don't they??
521 2014-03-06 13:53:52 <TD> oh ok it's something andresen said
522 2014-03-06 13:53:57 <TD> speak of the devil!
523 2014-03-06 13:54:08 <TD> the quote was: "Satoshi's style of writing code was old-school. He used things like reverse Polish notation." which i guess refers to the c++
524 2014-03-06 13:55:08 <sipa> that should be hungarian, yeah
525 2014-03-06 13:55:51 <edcba> yes i think it's hungarian because i don't really see when rpn is used
526 2014-03-06 13:56:26 <vegard> I just said the scripts do...
527 2014-03-06 13:56:52 <sipa> yes, scripts do, but i doubt that is what he's referring to
528 2014-03-06 13:57:27 <edcba> scripts use rpn really ?
529 2014-03-06 13:57:39 <edcba> isn't that script << op << data1 << data2 ?
530 2014-03-06 13:58:01 <sipa> if you want to write 5 + 3 in Script, it's "5 3 OP_PLUS"
531 2014-03-06 13:59:09 <edcba> ok it's a stack but in code it's not really rpn iirc
532 2014-03-06 13:59:50 <sipa> well rpn == stack based execution
533 2014-03-06 14:00:19 <sipa> rpn is how you write things if they're to be executed on a stack machine
534 2014-03-06 14:00:30 <sipa> saying that c++ code uses rpn makes no sense
535 2014-03-06 14:00:45 <edcba> of course it does
536 2014-03-06 14:01:05 <edcba> a = 3 + 4 is not same than a language using 3 4 + a =
537 2014-03-06 14:01:10 <sipa> c++ uses infix operators, not rpn...
538 2014-03-06 14:01:47 <TD> i always wondered if satoshi was retired. or maybe tenured.
539 2014-03-06 14:02:00 <sipa> i'm not sure how to interpret gavin's tweet
540 2014-03-06 14:02:03 <TD> the amount of time it needed and the style of code pointed to something like that
541 2014-03-06 14:02:18 <TD> sipa: "i didn't know what the story was really about" i'd assume
542 2014-03-06 14:02:35 <sipa> it may just mean "i wish they had left the guy alone", regardless of whether he is bitcoin's creator or not
543 2014-03-06 14:04:45 <TD> well, i think we'd all agree with that. though all the people freaking out about it seem to have overlooked the fact that there are lots of public people who control large amounts of bitcoin. if they fear for satoshi they should fear for those people too
544 2014-03-06 14:05:01 <TD> frankly we need tamper-proof secure hardware wallets that do risk analysis of submitted transactions, yesterday.
545 2014-03-06 14:05:17 <TD> there are too many people who got too rich too fast. and i worry about exchange operators being extorted
546 2014-03-06 14:05:32 <TD> Gemalto could clean up here
547 2014-03-06 14:05:42 <sipa> Gemalto?
548 2014-03-06 14:08:19 <TD> they make the secure hardware chips used in credit cards and other things
549 2014-03-06 14:08:29 <TD> AFAIK they are the world specialist at it. French company
550 2014-03-06 14:08:44 <TD> secure tamper-proof chips for financial applications is right up their street
551 2014-03-06 14:11:38 <michagogo> cloud|I just heard the Satoshi story on the radio news here
552 2014-03-06 14:12:14 <michagogo> cloud|The thing is that whether or not this is the same Satoshi, this is going to ruin his life
553 2014-03-06 14:12:27 <michagogo> cloud|Or at the very least the next several months of it