1 2015-03-14 00:02:34 <sipa> phantomcircuit: it does after the checkpoint
2 2015-03-14 00:03:47 <phantomcircuit> sipa, yeah im talking about the version without checkpoints
3 2015-03-14 00:03:58 <phantomcircuit> without checkpoints reindex runs all the scripts
4 2015-03-14 00:04:06 <sipa> yes
5 2015-03-14 00:04:10 <phantomcircuit> since it doesn't connect to any peers to get the headers and they're not saved
6 2015-03-14 00:04:28 <sipa> ah
7 2015-03-14 00:05:14 <phantomcircuit> sipa, also what's the best way to verify that the block being processed is in the chain associated with the best known header?
8 2015-03-14 00:05:51 <phantomcircuit> or is that even necessary in ConnectBlock ?
9 2015-03-14 00:12:41 <phantomcircuit> currently im calling pindexBestHeader->GetAncestor(pindex->nHeight);
10 2015-03-14 00:12:49 <phantomcircuit> but that seem sunlikely to be the most efficient way
11 2015-03-14 00:13:40 <sipa> i think it is
12 2015-03-14 00:14:01 <sipa> getancestor is fast
13 2015-03-14 00:14:48 <phantomcircuit> oh it's a bisecting algorithm
14 2015-03-14 00:15:10 <phantomcircuit> then it's probably my extra LogPrintf
15 2015-03-14 00:15:14 <sipa> no
16 2015-03-14 00:15:34 <sipa> it uses a skiplist, with logarithmic complexity
17 2015-03-14 00:16:26 <gmaxwell> Where do we call CheckBlock on a block that doesn't already connect to the best chain?
18 2015-03-14 00:19:03 <phantomcircuit> sipa, oh i see, so the CBlockIndex is serialized to disk with pskip set to some prior block?
19 2015-03-14 00:19:41 <sipa> nit to disk
20 2015-03-14 00:19:49 <sipa> the skiplist is only in memory
21 2015-03-14 00:20:10 <sipa> see the buildskip method and comments there
22 2015-03-14 00:20:35 <phantomcircuit> sipa, "//! Build the skiplist pointer for this entry."
23 2015-03-14 00:20:36 <phantomcircuit> :P
24 2015-03-14 00:20:49 <sipa> there is a lot more
25 2015-03-14 00:22:03 <phantomcircuit> there's more about the calculation of which height the previous block should be
26 2015-03-14 00:22:13 <phantomcircuit> anyways yeah i see how it work snow
27 2015-03-14 00:22:17 <phantomcircuit> works now
28 2015-03-14 00:22:19 <sipa> yes
29 2015-03-14 00:23:06 <phantomcircuit> LoadBlock(s?)Index is calling BuildSkip on each CBlockIndex as it's loaded
30 2015-03-14 00:23:58 <sipa> yes
31 2015-03-14 00:26:27 <phantomcircuit> gmaxwell, I haven't completely walked back from ConnectBlock but there doesn't seem to be anything enforcing that the block is on the same chain as the best headers
32 2015-03-14 00:26:55 <phantomcircuit> just that it's previous block hash points to the current tip of the best fully validated block
33 2015-03-14 00:26:58 <phantomcircuit> chain
34 2015-03-14 00:27:38 <gmaxwell> consider, you can't even validate a block unless it would be becoming the best block that you've verified.
35 2015-03-14 00:28:10 <phantomcircuit> gmaxwell, yeah so? i can have a fork which isn't the longest and still give it to you
36 2015-03-14 00:28:42 <gmaxwell> yes, and you can't verify it.
37 2015-03-14 00:28:45 <phantomcircuit> i doubt this would be an issue for more than a few seconds since you'd get the real best chain blocks from another peer (ie one that was giving you the headers)
38 2015-03-14 00:28:55 <phantomcircuit> hmm
39 2015-03-14 00:29:13 <gmaxwell> you'd have to rewind to the point that it diverged from to verify it.
40 2015-03-14 00:29:35 <phantomcircuit> oh right yeah no im thinking that you get this during IBD from someone being a joker
41 2015-03-14 00:29:36 <gmaxwell> The machinery is constantly driving towards the best known and not invalidated tip.
42 2015-03-14 00:29:49 <gmaxwell> you still won't ever validate it.
43 2015-03-14 00:30:09 <gmaxwell> AFAIK, the only place we connectblock is on the path to connecting the best block.
44 2015-03-14 00:33:46 <phantomcircuit> gmaxwell, iono i haven't looked at the since it was changed a bunch
45 2015-03-14 00:33:54 <phantomcircuit> time to get reacquainted i guess
46 2015-03-14 00:45:54 <phantomcircuit> gmaxwell, so that's kind of true but pindexMostWork is set only from blocks for which the entire block has been received
47 2015-03-14 00:46:05 <phantomcircuit> it doesn't appear to consider headers only
48 2015-03-14 00:46:39 <phantomcircuit> so ConnectBlock really does need to check that the block being considered is on the same chain as the best known header
49 2015-03-14 00:47:09 <phantomcircuit> and actually thinking about it we might want to change the logic there to simply ignore "block" messages that aren't in the same chain as the best known header
50 2015-03-14 00:48:05 <gmaxwell> Just go try to figure out the codepatch under when this would happen, e.g. trace it through from recieving a block message.
51 2015-03-14 00:48:31 <phantomcircuit> gmaxwell, you've processed all of the blocks upto say 200,000
52 2015-03-14 00:48:55 <phantomcircuit> out of the blue i send you a block which builds on 200,000 but which is not in the same chain as the best known header
53 2015-03-14 00:49:09 <phantomcircuit> you haven't seen any other blocks from any other peers
54 2015-03-14 00:49:18 <phantomcircuit> so you try to process that as the chain with the most work
55 2015-03-14 00:49:28 <phantomcircuit> you didn't request the block
56 2015-03-14 00:49:36 <phantomcircuit> i just sent it to you because of reasons
57 2015-03-14 00:49:52 <gmaxwell> I don't think it will try to connnect that.
58 2015-03-14 00:50:33 <phantomcircuit> i think it will since the candidates for being connected is the pool of complete blocks received and doesn't appear to reference the headers at all
59 2015-03-14 00:51:16 <gmaxwell> hm!
60 2015-03-14 00:52:37 <phantomcircuit> i think there's a maybe two line change we could throw in there to ignore blocks that aren't ancestors of pindexBestHeader
61 2015-03-14 00:53:00 <phantomcircuit> which would make shenanigans like early low difficulty forks irrelevant even without checkpoints
62 2015-03-14 00:53:16 <phantomcircuit> bbl dinner
63 2015-03-14 01:16:05 <dgenr8> <Dodger_> Okay, so I was calculating the median instead of the average. <- that is exactly right. to be fair, you did ask for the median. they differ by a factor of ln(2).
64 2015-03-14 01:23:47 <theymos> After reading that news about someone scraping the network (which is not particularly surprising, of course), I was once again tempted to connect my Bitcoin node to a Tor hidden service. But I just feel like Tor hidden services are in general pretty pointless because there's absolutely no protection against DoS attacks. At least with IP you can ban IP addresses/subnets, which works not-so-bad. But a
65 2015-03-14 01:23:47 <theymos> single person could eat up the max configured bandwidth of my hidden service and there'd be nothing I could do to stop them.
66 2015-03-14 01:23:51 <theymos> IMO this is really a Tor problem, but are there any ideas for improving this on Bitcoin's end?
67 2015-03-14 01:30:40 <petertodd> dgenr8: credit where credit is due: the sudoku example is from andreas antonopoulos
68 2015-03-14 01:31:41 <petertodd> theymos: run a HS node and watch it - you'll find it doesn't get DoS attacks in practice
69 2015-03-14 01:32:59 <dgenr8> petertodd: oh yeah. thx. it shows the difference between solution complexity and verification complexity well.
70 2015-03-14 01:36:25 <theymos> petertodd: Yeah, I might give it a try. But I find it frustrating to know that anyone who wanted to shut down all of the HS nodes could probably do so without much trouble, and there'd be no way to block them even with manual intervention.
71 2015-03-14 01:37:11 <petertodd> theymos: sure, but that's a fundementally unsolvable problem in anonymous systems - there will be *some* resource the attacker can spend to do that
72 2015-03-14 01:37:48 <petertodd> theymos: I've talked to jacob about this directly, and his take on it was " tor anti-dos is proof-of-bandwidth" which I think is actually pretty insightful
73 2015-03-14 01:38:53 <petertodd> bbl, plane landing
74 2015-03-14 01:39:04 <petertodd> hello sfo!
75 2015-03-14 09:42:41 <kyuupichan> Hi, I've noticed the documentation for CVarInt in serialize.h is incorrect. In particular, the examples given of 16511 and 65535 are incorrect; 16511 should be [0xFF 0x7F] and 65535 should be [0x82 0xFE 0x7F].
76 2015-03-14 09:43:14 <sipa> kyuupichan: patches welcome :)
77 2015-03-14 09:44:00 <kyuupichan> sipa, will do, it'll take a while for me to get github etc setup
78 2015-03-14 09:44:17 <johnguest> spartancoin
79 2015-03-14 11:10:35 <jonasschnelli> needs GUI label: https://github.com/bitcoin/bitcoin/issues/5897
80 2015-03-14 11:32:49 <robbak> Well, the build is broken for me, since commit 3ca5854. INcomprehensible things like 'internal compiler error' or 'C++ requires a type specifier for all declarations' with inline uint16_t htobe16(uint16_t host_16bits) in /compat/endian.h. Does anyone have any ideas?
81 2015-03-14 11:34:44 <robbak> It's clearly in the endian stuff.
82 2015-03-14 11:38:32 <sipa> internal compiler error means a bug in the compiler :)
83 2015-03-14 11:39:10 <sipa> can you compile with -save-temps, and paste the offending .i file somewhere?
84 2015-03-14 11:39:58 <robbak> OK. I've been bisecting this and trying to find out what is happening most of today, though, so I'm mostly just getting tips for my next session.
85 2015-03-14 11:40:39 <sipa> i'll look at the commit, but it's strange that this is just for you
86 2015-03-14 11:40:49 <robbak> Just re-confirming that commit 4414f5f builds OK. ("compiling!")
87 2015-03-14 11:40:50 <sipa> perhaps different defines
88 2015-03-14 11:41:07 <robbak> Am I the only one building these on FreeBSD?
89 2015-03-14 11:41:16 <sipa> likely :)
90 2015-03-14 11:41:22 <sipa> koobs maybe too
91 2015-03-14 11:41:57 <robbak> Yes, Koobs is the committer I was working with to get the updated port into the tree.
92 2015-03-14 11:42:19 <robbak> Tracking things so I can keep FreeBSD updated is my job.
93 2015-03-14 11:42:50 <robbak> OH drat. 44145f just failed too. I need to do even more research. sigh.
94 2015-03-14 12:26:26 <ahmed_> hi all
95 2015-03-14 12:26:40 <ahmed_> does anyone here know how i can check bitcoin address's in php for validity
96 2015-03-14 12:26:49 <ahmed_> including multi-sig addresses
97 2015-03-14 13:00:47 <benedikt> not sure if i'm in the correct channel - apart from forking the bitcoin/litcoin code, what are my options for creating an alternative blockchain?
98 2015-03-14 13:04:52 <sipa> benedikt: off topic
99 2015-03-14 13:05:49 <benedikt> sipa: in what channel is it on-topic? :)
100 2015-03-14 13:05:54 <Hasimir> and surely there are enough altcoins/scamcoins ... surely?
101 2015-03-14 13:06:12 <sipa> benedikt: no clue, and i'd rather not find out
102 2015-03-14 13:06:22 <benedikt> Hasimir: there are other uses for blockchains than *coin
103 2015-03-14 13:06:47 <Hasimir> yes, like namecoin's weird attempt at dns and domreg
104 2015-03-14 13:07:06 <Hasimir> but most of the forks were made for pump and dumps on minor exchanges
105 2015-03-14 13:08:00 <Hasimir> hence the thorough disregard here (and what else you're doing with a blockchain is usually better achieved in some other way)
106 2015-03-14 13:08:16 <Hasimir> though I'm still on the fence regarding bitmessage
107 2015-03-14 13:08:19 <benedikt> and there is a myriad of tutorials on how to literally fork litecoin to another *coin in 30 minutes.
108 2015-03-14 13:08:33 <benedikt> bitmessage doesn't have a blockchain.
109 2015-03-14 13:09:32 <Hasimir> but it uses a similar principal of constant stream of data in order to play at traffic analysis circumvention (except only those using it install it and there goes that theory)
110 2015-03-14 13:11:48 <sipa> i don't believe you can have a secure blockchain system without mechanisms for incentivizing collaboration
111 2015-03-14 13:12:43 <benedikt> sipa: i actually believe you can and that it all depends on the context in which the blockchain is being used
112 2015-03-14 13:12:59 <Taek> ##altcoin-dev
113 2015-03-14 13:13:05 <sipa> not saying there are no non-currency uses, but so far, all that i have seen are either broken, relying on a central authority anyway (so don't need a blockchain), or or involve interaction with a currency blockchain
114 2015-03-14 13:13:50 <sipa> in any case, this channel is about bitcoin itself
115 2015-03-14 13:14:50 <benedikt> Taek: ah! thanks
116 2015-03-14 13:15:17 <benedikt> although i don't have a coin in mind, that might be more suitable
117 2015-03-14 13:15:47 <Taek> afaik it's the closest thing there is to 'alternative blockchain'
118 2015-03-14 13:16:28 <benedikt> yeah, that sounds reasonable
119 2015-03-14 13:17:07 <benedikt> sipa: some (very rough) outlines of my ideas for blockchain use: https://github.com/benediktkr/lokun-record/wiki/Idea-Blockchain-as-a-CA and https://github.com/benediktkr/lokun-record/wiki/idea-Blockchain-voting
120 2015-03-14 13:17:14 <benedikt> ACTION afk
121 2015-03-14 13:20:36 <sipa> benedikt: there exist cryptographic voting protocols which have better properties in every way
122 2015-03-14 13:21:16 <sipa> (anonimity, ability to prove you voted, inability to prove what you voted for, inability for others to censor votes)
123 2015-03-14 13:22:18 <sipa> benedikt: please don't fall for the "blockchain technology is awesome, let's use it for everything". They're awesome, but you should be aware of the alternatives too for specific use cases.
124 2015-03-14 13:32:32 <hlidutysileh> .
125 2015-03-14 13:32:32 <hlidutysileh> did usa covertly supply isis with weapons like they did with al-qaeda to justify creating wars?
126 2015-03-14 13:32:32 <hlidutysileh> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosion
127 2015-03-14 13:32:32 <hlidutysileh> plz, send my qs to help limiting usa&israel aggression against others.
128 2015-03-14 13:32:32 <hlidutysileh> with uncertain responsibles to create wars?
129 2015-03-14 13:32:33 <hlidutysileh> did usa excute the creative mess in the middle east like they said they will, does the creative mess include explosion with uncertain responsibles to create wars?
130 2015-03-14 13:32:33 <hlidutysileh> plz, send my qs to help limiting usa&israel aggression against others.
131 2015-03-14 13:32:34 <hlidutysileh> .
132 2015-03-14 13:47:55 <benedikt> sipa: i am, but for voting a blockchain actually seems to be the best system available today if you read the litterature.
133 2015-03-14 13:48:10 <benedikt> and blockchains are awesome, but that doesn't mean they are for everything
134 2015-03-14 13:53:09 <sipa> benedikt: miners can censor your votes (especially if the only reason to not do so is being.. paid?) and have very bad privacy compared to some other systems
135 2015-03-14 13:54:43 <sipa> those systems typically have a central server, but the only thing the server can do is stop functioning (it cannot distinguish votes, it cannot selective censor, and it cannot influence outcome)
136 2015-03-14 13:55:50 <sipa> benedikt: using a blockchain for publication makes sense. publishing votes does not :)
137 2015-03-14 14:10:42 <benedikt> sipa: publishing votes does. publishing who voted what doesn't
138 2015-03-14 14:11:45 <benedikt> because if you pubish votes, you don't have to trust the voting authority to count honestly, because everyone can.
139 2015-03-14 14:12:48 <benedikt> but anyhow, i just want to code something like this for fun and for startes i'd like to create some sort of a generic blockchain.
140 2015-03-14 14:18:49 <sipa> benedikt: the choice is between a voting authority (who does not know who you are), and miners (from whom it is very hard to hide)
141 2015-03-14 14:18:57 <sipa> there is always someone controlling access
142 2015-03-14 15:01:38 <linelevel> Hi, is it possible to let `bitcoind` build a transaction that spends from the available utxos of its watch-only addresses, then sends the transactions to an external key server to be signed with whatever keys it needs for the inputs it chose?
143 2015-03-14 15:32:37 <Chillum> linelevel: yes it is possible to make an unsigned tx and to sign it elsewhere
144 2015-03-14 15:33:16 <Chillum> I know the client armory supports it but I am not sure if you can do it with bitcoind though
145 2015-03-14 15:44:16 <Luke-Jr> 24518 be/4 luke-jr 1364.36 K/s 1714.67 K/s 0.00 % 88.04 % ./bitcoin-qt.ljr20150313 [QThread]
146 2015-03-14 15:44:17 <Luke-Jr> odd
147 2015-03-14 15:49:12 <Luke-Jr> hmm, writing leveldb chainstate files even though it's fully syncd?
148 2015-03-14 17:22:30 <linelevel> Chillum: Right, I am specifically asking about watch-only addresses. I do not want bitcoind to have my keys, so it will need to be signed elsewhere, but I'm not sure how to construct the transaction from the available utxos at my watch-only addresses.
149 2015-03-14 17:26:52 <bitanarchy> hi, which applications are supporting trezor already?
150 2015-03-14 17:28:06 <Luke-Jr> bitanarchy: #bitcoin
151 2015-03-14 17:30:01 <Chillum> linelevel: yes, armory can do that
152 2015-03-14 17:30:25 <linelevel> Chillum: I need to do it programmatically though, not manually.
153 2015-03-14 17:30:36 <linelevel> Chillum: So I figured I would have to use the bitcoind JSON RPC.
154 2015-03-14 17:30:38 <Luke-Jr> why does sendrawtransaction refuse to send "insufficient priority" txns? -.-
155 2015-03-14 17:30:45 <sipa> linelevel: watchaddress + listunspent + createrawtransaction
156 2015-03-14 17:31:01 <sipa> Luke-Jr: it will refuse anything your node would node accept for relay
157 2015-03-14 17:31:05 <Chillum> hmm, so you mean there will be a network connection to the server with keys?
158 2015-03-14 17:31:07 <sipa> *would not
159 2015-03-14 17:31:19 <Chillum> The idea of a cold wallet is that the private keys are not on the network
160 2015-03-14 17:31:37 <linelevel> sipa: Oh, good call... I think that will work, though it means I will have to manually choose the utxos rather than letting bitcoind choose them the way it normally would when it creates a transaction.
161 2015-03-14 17:31:38 <Chillum> what you are proposing is possible but it is not a best practice and thus may not be supported by existing tools
162 2015-03-14 17:31:45 <linelevel> sipa: which is suboptimal but it would work.
163 2015-03-14 17:31:49 <Luke-Jr> sipa: that's somewhat annoying. why?
164 2015-03-14 17:31:53 <linelevel> Chillum: Why is it not a best practice?
165 2015-03-14 17:32:02 <sipa> Luke-Jr: because it wouldn't relay it anyway...
166 2015-03-14 17:32:14 <sipa> linelevel: yes, bitcoind currently does not expose its utxo selection algorithm; that may be added in 0.11
167 2015-03-14 17:32:16 <Luke-Jr> sipa: but that's why I'm explicitly asking it to relay it
168 2015-03-14 17:32:30 <Chillum> linelevel: https://bitcointalk.org/index.php?topic=448284.0 This is talking about programatically signing keys
169 2015-03-14 17:32:52 <Chillum> it is not best practice because the primary benefit of separating the keys is to keep the keys off the network
170 2015-03-14 17:32:58 <Chillum> so nobody can break in over the network
171 2015-03-14 17:33:00 <linelevel> Chillum: The private keys are in a PostgreSQL database with strict permissions that will not allow them to be exposed, ever. It will sign transactions when asked, but only if asked by a certain IP address on the local network.
172 2015-03-14 17:33:13 <sipa> Chillum: there are degrees
173 2015-03-14 17:33:22 <Chillum> I agree, layers and such
174 2015-03-14 17:33:37 <sipa> Chillum: of course, not having the private keys online is better, but that requires manual intervention for all signing, which may be unacceptable for some applications
175 2015-03-14 17:33:51 <Chillum> the link I posted above shows a programmatic approach to signing txs
176 2015-03-14 17:33:54 <sipa> but by separating the signing system and the watching system, you do introduce an extra security already
177 2015-03-14 17:34:15 <sipa> (by not having the private keys in a publicly-accessibly node daemon...)
178 2015-03-14 17:34:19 <Chillum> Have not tried it but it is a start, do your own due diligence
179 2015-03-14 17:34:20 <linelevel> Chillum: Well, there's always a weak point if someone can break into the network...even if I let bitcoind manage the keys, anyone who could access the bitcoind RPC could sign whatever they want.. so I actually think my approach is more restrictive than that.
180 2015-03-14 17:34:56 <sipa> linelevel: anyone who could access RPC, or anyone who found a buffer overflow in bitcoind accessible through the P2P network
181 2015-03-14 17:34:57 <Chillum> I agree it is an improvement to have the keys on another server, just saying that tools were mostly designed with offline keys in mind
182 2015-03-14 17:35:15 <linelevel> sipa: Exactly, that was my thought, re: separating keys from the node with publicly open ports
183 2015-03-14 17:35:15 <sipa> (note that no buffer overflows have ever been found in bitcoind, iirc, but that's no guarantee for the future)
184 2015-03-14 17:35:46 <Chillum> I would advise you separate the database with an API, and use sanity checks like max per day, max per hour etc
185 2015-03-14 17:36:31 <Chillum> ie don't allow your public facing server to talk to the DB directly
186 2015-03-14 17:36:47 <sipa> i think this is getting a bit offtopic
187 2015-03-14 17:36:56 <linelevel> Chillum: Already doing that, but the API in front of the db is on a separate node from the db itself. And I'm letting the db do the signing via pl/python stored procedures.
188 2015-03-14 17:37:11 <sipa> bitcoind api discussion is fine, but general security practices for server setups aren't really
189 2015-03-14 17:37:33 <Chillum> I see, I thought because he is trying to sign bitcoind tx it was on topic. Okay, PM me if you want to discuss further
190 2015-03-14 17:37:45 <linelevel> sipa: Sorry, what channel would be more appropriate? #bitcoin or #bitcoin-advanced?
191 2015-03-14 17:38:19 <sipa> never heard of #bitcoin-advanced :)
192 2015-03-14 17:38:21 <Chillum> should be called #bitcoind-dev then, I thought this was general bitcoin dev
193 2015-03-14 17:38:21 <linelevel> Chillum: I'm going to experiment with this a bit, but if you're okay with it I will PM you my findings later.
194 2015-03-14 17:38:28 <Chillum> sure
195 2015-03-14 17:38:44 <sipa> Chillum: it's about development _of_ bitcoin, not development of things on top of it
196 2015-03-14 17:38:50 <Chillum> ah
197 2015-03-14 17:39:11 <linelevel> sipa: I was thinking of the bitcoin-advanced subreddit, woops :p I thought there was another bitcoin channel for more advanced non-dev discussion than #bitcoin, though
198 2015-03-14 17:41:20 <Chillum> ACTION goes to find a channel where you can discuss developing things that use the bitcoin network
199 2015-03-14 18:05:52 <hearn> is development of bitcoin apps really off topic here?
200 2015-03-14 18:06:38 <sipa> i'd say usage of the bitcoin protocol isn't
201 2015-03-14 18:06:44 <sipa> or architecture
202 2015-03-14 19:01:45 <Eliel> is there a spec for storing bitcoin addresses or private keys in QR codes in binary form? It'd reduce the pixel size and thus improve readability of the code.
203 2015-03-14 19:06:17 <Luke-Jr> Eliel: no
204 2015-03-14 19:06:46 <Luke-Jr> Eliel: if you were to make a spec, though, it should probably be payment requests and wallet seeds rather than those though
205 2015-03-14 19:11:00 <Eliel> also, I'm trying to convince someone that using the 22-byte version of the mini private key is not a good idea. However, I lack concrete information on exactly how insecure those are, so I failed on the first attempt.
206 2015-03-14 19:11:38 <maaku> Eliel: what's the entropy on those bytes?
207 2015-03-14 19:11:44 <maaku> i'm not familiar with the standard, if there is one
208 2015-03-14 19:12:53 <Eliel> maaku: https://en.bitcoin.it/wiki/Mini_private_key_format
209 2015-03-14 19:13:01 <maaku> but even with perfect 8 bits per byte entropy that's still only 88 bits of security, which really doesn't leave much buffer room
210 2015-03-14 19:13:57 <Eliel> you can't attack them directly through ECDSA math
211 2015-03-14 19:14:19 <Eliel> because the mini private key is used to produce a 256 bit ECDSA key through SHA256
212 2015-03-14 19:14:29 <maaku> Eliel: no, you can't. but there's not a proof either that you can't find a way to enumerate this subspace more efficiently
213 2015-03-14 19:14:31 <sipa> you still obly have to try 2^88 keys
214 2015-03-14 19:15:02 <sipa> which is faster than attacking the pubkey/signatures, which needs 2^128 tries
215 2015-03-14 19:15:27 <maaku> duh yeah that's the simple way to enumerate the space :)
216 2015-03-14 19:16:52 <maaku> Eliel: how many bitcoins are there assigned to mini private keys?
217 2015-03-14 19:18:55 <Eliel> the plan is to have at most around $50 worth of bitcoins (at current exchange rate) in each. Most will likely only have $10.
218 2015-03-14 19:21:21 <Eliel> I have no way to foretell what the total will be.
219 2015-03-14 19:22:29 <Eliel> there's a new brand of physical bitcoins launching soon (that's what this is for). This is for the initial low value coins.
220 2015-03-14 19:24:23 <Eliel> but casascius coins already use the 22-byte mini private keys.
221 2015-03-14 19:26:21 <maaku> Eliel: the question isn't how much you have, but how much everyone has in 22-byte keys
222 2015-03-14 19:26:35 <maaku> at some point it becomes economical to just enumerate all the keys of that subspace and take all the coins
223 2015-03-14 19:27:53 <Luke-Jr> wumpus: https://github.com/bitcoin/bitcoin/pull/4831 I can't find where the timeout occurs :/
224 2015-03-14 19:33:38 <Eliel> how did you get that 2^88? It seems to me there are 22^58 possible keys and that's bigger that 2^123. Without actually enumerating all possible mini private keys, you can't even tell which bitcoin addresses are created from these.
225 2015-03-14 19:34:12 <maaku> Eliel: you said 22-bytes. Maximum entropy of 22 bytes is 2^88
226 2015-03-14 19:34:38 <Eliel> maaku: the actual private key is 256 bit.
227 2015-03-14 19:34:42 <arubi> 58^22
228 2015-03-14 19:35:14 <Eliel> arubi: ah, right, I typoed it here. I did calculate it correctly though.
229 2015-03-14 19:35:28 <maaku> ah we're dealling with base 58? then that's really atrocious
230 2015-03-14 19:35:33 <Luke-Jr> Eliel: private key size is irrelevant, what matters is entropy
231 2015-03-14 19:36:17 <maaku> Eliel: private key size is meaningless. just enumerate the possible 22-byte mini keys, and check those private keys for balances
232 2015-03-14 19:36:31 <Eliel> yes, and there are over 2^123 of those.
233 2015-03-14 19:36:43 <Eliel> much more than that 2^88
234 2015-03-14 19:39:56 <Luke-Jr> what? is this example code serious?
235 2015-03-14 19:40:14 <Luke-Jr> it's generating private keys by randomly throwing together base58 characters and then checking if it's valid base58check?
236 2015-03-14 19:40:58 <Eliel> Luke-Jr: that's not base58check.
237 2015-03-14 19:43:03 <Luke-Jr> i c
238 2015-03-14 19:43:19 <Luke-Jr> uglier âº
239 2015-03-14 19:43:41 <Eliel> it's a brute force kind of checksum :P
240 2015-03-14 19:44:06 <Eliel> you can't precalculate it, you have to brute force the space to find a valid one.
241 2015-03-14 19:44:10 <Luke-Jr> shouldn't it be 58^30/256 then?
242 2015-03-14 19:44:16 <Luke-Jr> so 167-bit
243 2015-03-14 19:45:01 <Eliel> problem is, there is a 22 byte version also and it's supported in all software that supports this at all.
244 2015-03-14 19:45:20 <Eliel> but if you're going to brute force these, you have to check every invalid one too.
245 2015-03-14 19:47:45 <Luke-Jr> Eliel: once
246 2015-03-14 19:47:49 <Eliel> although, you get by with just sha256 on invalid ones.
247 2015-03-14 19:48:09 <Eliel> no need for ECDSA math to calculate the address
248 2015-03-14 19:49:03 <Eliel> if you count just the valid ones, there's 2^123 of them for the 22 byte version.
249 2015-03-14 19:49:30 <Eliel> oh wait
250 2015-03-14 19:49:44 <Eliel> the first byte is always S, that's minus one more byte
251 2015-03-14 19:49:54 <Eliel> so 2^117
252 2015-03-14 19:58:04 <Luke-Jr> Eliel: I get 115
253 2015-03-14 19:58:45 <Eliel> 117.15961990255146
254 2015-03-14 19:58:45 <Eliel> math.log(58**20)/math.log(2)
255 2015-03-14 19:59:42 <Luke-Jr> math.log2(58â21/256)
256 2015-03-14 19:59:49 <Luke-Jr> math.log2(58**21/256)
257 2015-03-14 20:00:15 <Eliel> oh you're right. That's the right way to do it.
258 2015-03-14 20:04:59 <Eliel> well, ECDSA multiply being a slow operation, I can live with 2**115 for low value coins for now.
259 2015-03-14 20:09:59 <Luke-Jr> slowness is not an intended property of ECDSA, so I wouldn't want to rely on it
260 2015-03-14 20:24:29 <Luke-Jr> cfields: 0.10 regression, do we have a real fix yet (commit message implied it was a temporary change, but it got released..)? https://github.com/bitcoin/bitcoin/issues/5902
261 2015-03-14 20:39:47 <gmaxwell> Eliel: a problem with reduced keyspace is that if it's possible to define a basis the spans most of the keys and not much of the non-key space then it's possible to use pollard-rho to get a sqrt speedup on top of the reduction.
262 2015-03-14 20:40:07 <gmaxwell> Eliel: so half the effective bits of security.
263 2015-03-14 20:41:52 <gmaxwell> Doesn't seem likely, but the loss of security seems gratitious, especially since the applications where a slightly smaller private key might be useful are already usually inadvisable for unrelated reasons.
264 2015-03-14 20:44:10 <gmaxwell> That spec was defined for a very narrow usecase, printing private keys on tiny hologram stickers steal on coins. _maybe_ it was excusable for that application. though who knows, BIP38 had basicall zero peer review, and no cryptographic review, it was basically published by accident (the author's emails to the list went into a black hole)
265 2015-03-14 20:44:37 <Eliel> gmaxwell: well, that spefic very narrow usecase is the usecase here :P
266 2015-03-14 20:47:26 <Eliel> that being said, it'll be a limited quantity that will be made with the weak keys.
267 2015-03-14 20:47:42 <gmaxwell> it's certantly a less exciting use case ever since fincen sent the author of it a letter that said they thought his business was unlawful, and he shut it down.
268 2015-03-14 21:20:44 <Eliel> Yes, well, this is a different jurisdiction, so hopefully the story ends differently here.
269 2015-03-14 21:53:24 <BladeMcCool> what file defines port 8333 as the default?
270 2015-03-14 21:54:06 <BladeMcCool> oh is it protocol.h ? must be.
271 2015-03-14 22:01:55 <phantomcircuit> BladeMcCool,
272 2015-03-14 22:01:59 <phantomcircuit> chainparams
273 2015-03-14 22:10:09 <BladeMcCool> hrm chainparams you say .. is that a file? or something in a certain file?
274 2015-03-14 22:11:52 <BladeMcCool> hrm my local git copy must be old
275 2015-03-14 22:17:01 <BladeMcCool> thanks for the info phantomcircuit.