1 2014-05-24 01:27:13 <warren> coryfields: that drops 10.6 compat?
  2 2014-05-24 01:27:20 <coryfields> no
  3 2014-05-24 01:27:24 <warren> ah
  4 2014-05-24 01:27:45 <coryfields> iirc it would drop 10.5, which is why we weren't using it to begin with
  5 2014-05-24 01:28:06 <coryfields> warren: how did you conclude that the bump that 5.2.1 fixed the font issue?
  6 2014-05-24 01:28:06 <warren> 0.8.x in our testing didn't work on 10.5, it did for you?
  7 2014-05-24 01:28:25 <warren> coryfields: the weird character went away when the only change was 5.2.0 -> 5.2.1
  8 2014-05-24 01:29:22 <coryfields> warren: ah, that's right, it was the comma or something
  9 2014-05-24 01:29:25 <coryfields> but
 10 2014-05-24 01:29:30 <warren> not a comma
 11 2014-05-24 01:29:43 <coryfields> on 10.9 for me, that font is busted
 12 2014-05-24 01:29:47 <coryfields> it's just blocks
 13 2014-05-24 01:30:04 <coryfields> i fixed it in code and i'll PR in a min, but i'm curious as to why you didn't see that
 14 2014-05-24 01:30:14 <warren> https://github.com/bitcoin/bitcoin/pull/4185#issuecomment-43194688
 15 2014-05-24 01:33:52 <coryfields> warren: http://i.imgur.com/c7zPTqn.png
 16 2014-05-24 01:34:06 <coryfields> that's with a current gitian dmg
 17 2014-05-24 01:34:22 <coryfields> again, i've fixed it, i'm just really curious why i'm the only one seeing it
 18 2014-05-24 01:34:32 <warren> maybe nobody else is testing it ...
 19 2014-05-24 01:34:44 <warren> coryfields: 5.2.0 didn't have the busted font?
 20 2014-05-24 01:34:53 <warren> coryfields: my testing was *only* on 10.6
 21 2014-05-24 01:35:08 <coryfields> oh ok, well there's the answer
 22 2014-05-24 01:35:20 <coryfields> it's 10.9 only.
 23 2014-05-24 01:35:21 <coryfields> thanks
 24 2014-05-24 01:35:36 <coryfields> bbl
 25 2014-05-24 03:59:39 <warren> A note of warning, if you modify sources in src/leveldb, make at the toplevel won't always rebuild it
 26 2014-05-24 03:59:45 <warren> wasted a lot of time on this one
 27 2014-05-24 08:15:26 <dabura667> Question: is anyone other than the DarkWallet devs working on the stealth address protocol? The reason I ask this is that if we took away the stealth aspect and used the "prefix" value within the stealth address (currently the last few bytes before the checksum) as a 1:1 to the 4 byte nonce placed before the ephemeral pubkey in the OP_RETURN txout.
 28 2014-05-24 08:15:45 <dabura667> Then we could solve the address reuse issue.
 29 2014-05-24 08:17:00 <dabura667> It wouldn't have any of the anonymity properties of the stealth address used currently, but the privkey would easily be found by searching all utxos for your prefix rather than brute forcing all the ephemkeys with their nonces to look for a match etc.
 30 2014-05-24 10:49:24 <petertodd> dabura667: I suggested something not unlike that awhile back in conjunction with HD wallets actually, only with just incrementing indexes until your prefix matched
 31 2014-05-24 10:50:34 <petertodd> dabura667: and yeah, the stealth addr protocol was put out for public review months ago; didn't get much useful feedback aside from adam back and gmaxwell.
 32 2014-05-24 12:14:28 <dabura667> Bitcoin needs something like stealth address without the stealth in order to ensure 1. no reuse of keys. 2. easy lookup and recovery of funds.
 33 2014-05-24 12:14:28 <dabura667> petertodd: recently I was studying ECC vulnerability vectors and I came across the "same k for two sigs = privkey stolen" case. I was suprised at how amazingly easy it was to solve the privkey with exact matches (like algebra easy) and even wrote a simple brute forcer that if you could guess parameters for k values that might occur based on knowledge of a vulnerability, the processing cost is very low... It made me think that
 34 2014-05-24 12:16:23 <dabura667> in an ideal world, there would be the choice of privacy over ease of lookup / processing cost... or who knows, tomorrow some great idea could make fully stealth addresses low processor cost.
 35 2014-05-24 12:17:56 <dabura667> Anecdote: my wife asked what I was doing, and I said "hacking a bitcoin address that was shown to have a vulnerability a year ago." then she said "wow, you can hack bitcoins? Does that mean we can buy a house?" :-D
 36 2014-05-24 12:18:33 <holyboot> dabura667: I've had similar conversations with my wife <g>
 37 2014-05-24 12:18:43 <dabura667> yeah no, that address's privkey is public domain now lol
 38 2014-05-24 12:19:56 <shesek> dabura667, address reuse doesn't imply K reuse
 39 2014-05-24 12:19:59 <dabura667> holyboot: my wife is very tech savvy, but not to the point where saying "elliptic" to her in our language will garner any excitement.
 40 2014-05-24 12:20:21 <buZz> you could train her, pavlov style
 41 2014-05-24 12:20:21 <holyboot> dabura667:  hahahahaha
 42 2014-05-24 12:20:37 <buZz> mention elliptic curves during something she enjoys
 43 2014-05-24 12:20:47 <buZz> in due time she will make the synaptic connection ;)
 44 2014-05-24 12:21:47 <Luke-Jr> dabura667: even if you can technically spend bitcoins, you might want to consider whether it's legal.. a case can easily be made that it is fraud to claim bitcoins which were not yours
 45 2014-05-24 12:21:50 <dabura667> shesek: true, but I think there should be layers of protection for every good program, and currently a lot of programs rely on "cryptographically secure" PRNGs that are provided with libraries. Of course anyone worth their weight in salt will know ways to get proper entropy... but still
 46 2014-05-24 12:22:21 <shesek> dabura667, is it actually quite easy to create unique K values - you can simply use H(privkey||data)
 47 2014-05-24 12:22:28 <dabura667> Luke-Jr: read my post, I was studying attack vectors using a reported hack from 1 year ago.
 48 2014-05-24 12:22:30 <shesek> `data` being the data being signed
 49 2014-05-24 12:22:51 <shesek> you can also add some entropy to that (H(privkey||data||random)), but its not really needed
 50 2014-05-24 12:22:53 <Luke-Jr> dabura667: that's not my point.
 51 2014-05-24 12:23:39 <dabura667> Luke-Jr: yes, if your point is "stealing is bad" then we are in agreement.
 52 2014-05-24 12:25:24 <dabura667> shesek: Yes, this is a good idea. Unfortunately, things like the Android vulnerability last year etc. happen. When that DOES happen, having a safety net is always nice.
 53 2014-05-24 12:26:53 <dabura667> Though you could go one step further and say, if the k in the sig alg is broken, then you shouldn't trust any privkeys generated on that machine...
 54 2014-05-24 12:27:19 <sipa> deterministic k is safe, assuming the key generation is safe
 55 2014-05-24 12:27:28 <sipa> and if key generation isn't safe, you're screwed anyway
 56 2014-05-24 12:31:20 <Luke-Jr> dabura667: pedantically, I'd argue that it's fine (ie, not a vulnerability) to use a fixed K per ECDSA key, since you should only ever be signing with it once ;)
 57 2014-05-24 12:31:52 <Luke-Jr> (obv not the case for the Android instance, but theoretically possible to have a fixed K without breaking the RNG)
 58 2014-05-24 13:00:49 <prof7bit_> I've made pure Java code to parse wallet.dat (no non-java dependency): https://github.com/prof7bit/wallet-key-tool/blob/master/src/main/java/prof7bit/bitcoin/wallettool/fileformats/WalletDatHandler.xtend can anybody spot any obvious mistake, especially in handling the different bdb key types?
 59 2014-05-24 13:19:17 <Luke-Jr> prof7bit_: … why?
 60 2014-05-24 13:20:06 <prof7bit_> to avoid libdb dependency
 61 2014-05-24 13:21:18 <Luke-Jr> prof7bit_: you know the bdb format will be going away Real Soon Now™? :p
 62 2014-05-24 13:22:08 <Luke-Jr> seems like a lot of work just to temporarily avoid a C dep
 63 2014-05-24 13:22:09 <prof7bit_> yes, but old wallet dats might be found on some old hdds
 64 2014-05-24 13:22:10 <Luke-Jr> 
ACTION shrugs

 65 2014-05-24 13:22:45 <prof7bit_> Luke-Jr: it was actually easier than I have thought. This file format is actually extremely simple
 66 2014-05-24 13:22:56 <Luke-Jr> hm
 67 2014-05-24 13:23:15 <prof7bit_> took me only 3 days (have some time currently)
 68 2014-05-24 13:24:02 <prof7bit_> only documentation i needed was db_page.h and bywallet for the bitcoin related stuff
 69 2014-05-24 13:24:09 <prof7bit_> pywallet
 70 2014-05-24 13:25:40 <prof7bit_> and sometimes i do stuff just to see whether it can actually be done (by me).
 71 2014-05-24 13:26:45 <Luke-Jr> ☺
 72 2014-05-24 15:04:17 <chmod755> cb7caf0b4c0ee266cce5fbd8f8ba3903f5efa82e is still the latest bootstrap.dat torrent right?
 73 2014-05-24 15:06:03 <hearn> saivann: where on the website is it?
 74 2014-05-24 15:06:21 <harding> hearn: it's still building
 75 2014-05-24 15:06:24 <saivann> hearn: You checked 30 seconds too soon
 76 2014-05-24 15:06:27 <harding> hearn: It'll be at https://bitcoin.org/en/developer-documentation
 77 2014-05-24 15:06:29 <saivann> It's live now!
 78 2014-05-24 15:06:31 <hearn> :)
 79 2014-05-24 15:06:44 <hearn> yay! i see it :)
 80 2014-05-24 15:07:20 <saivann> Wonderful work, awesome to see this live on the main domain now!
 81 2014-05-24 15:07:36 <hearn> high fives all round
 82 2014-05-24 15:07:40 <hearn> we should do some promo work so people learn about it
 83 2014-05-24 15:07:44 <hearn> coindesk should cover it at least
 84 2014-05-24 15:08:10 <saivann> That's a good idea!
 85 2014-05-24 15:08:34 <harding> saivann: the warning doesn't disapear for me when pressing the X, even though it did on the preview.
 86 2014-05-24 15:09:17 <saivann> harding: Will fix that, I see JS errors in the console too
 87 2014-05-24 15:09:36 <saivann> (Thanks for reporting!)
 88 2014-05-24 15:09:54 <harding> :-)
 89 2014-05-24 15:19:38 <saivann> Just fixed some too aggresive caching policies
 90 2014-05-24 15:20:20 <CodeShark> is it normal for the latest master HEAD to show a bunch of messages like
 91 2014-05-24 15:20:23 <CodeShark> 2014-05-24 15:19:45 ProcessBlock: ORPHAN BLOCK 256, prev=00000000000001e7dfdc2a13b69b8b9d314330b5cdc77507e6ed3b12ed2a597a
 92 2014-05-24 15:20:47 <CodeShark> it shows like 700+ lines of this
 93 2014-05-24 15:24:29 <CodeShark> and while it's showing these lines it doesn't seem to be getting any other network updates
 94 2014-05-24 15:24:40 <CodeShark> i.e. tip updates
 95 2014-05-24 15:27:13 <chichov> I see that CBitcoinAddress (base58.h) only stores the first 20 bytes of a bitcoin address
 96 2014-05-24 15:27:22 <chichov> is there any way to retrieve the complete address from a CPubKey?
 97 2014-05-24 15:27:22 <sipa> CodeShark: it means blocks being received out of order
 98 2014-05-24 15:27:42 <sipa> chichov: a bitcoin address IS a 20-byte hash of the public key
 99 2014-05-24 15:28:02 <sipa> (base58check encoded)
100 2014-05-24 15:28:20 <chichov> hm, how can I retrieve the "whole" thing then? including network byte, checksum etc
101 2014-05-24 15:28:53 <sipa> those are only present after base58 encoding
102 2014-05-24 15:29:07 <sipa> you can look at the constants in chainparams
103 2014-05-24 15:31:23 <chichov> I thought the address is: Base58Enc(NetworkByte||pubkeyHash||checksum) ?
104 2014-05-24 15:31:54 <sipa> which is base58check(networkbyte || pubkeyhash)
105 2014-05-24 15:32:04 <chichov> unless there is some mistake in the terminology
106 2014-05-24 15:32:26 <chichov> ah yes, so that's how it looks like
107 2014-05-24 15:32:27 <sipa> sur
108 2014-05-24 15:32:34 <sipa> but the networkbyte is a constant
109 2014-05-24 15:32:39 <chichov> yep
110 2014-05-24 15:32:46 <sipa> it is added when encoding an address as a string
111 2014-05-24 15:32:52 <sipa> and removed when parsing
112 2014-05-24 15:33:16 <sipa> you could convert an address to a string, and then base58 decode it
113 2014-05-24 15:33:39 <sipa> but all you'd get would be networkbyte || pubkeyhash || chrcksum
114 2014-05-24 15:34:15 <chichov> my goal is to get from CPubKey to Base58Check(NetworkByte||pubkeyHash)
115 2014-05-24 15:34:21 <chichov> any idea how to get there?
116 2014-05-24 15:34:42 <sipa> CBitcoinAddress(pubkey.GetId()).ToString()
117 2014-05-24 15:35:11 <chichov> interesting, that's gonna give me the "whole" thing?
118 2014-05-24 15:35:16 <chichov> I'll look into that
119 2014-05-24 15:35:34 <sipa> it will give you the base58 encoded address
120 2014-05-24 15:38:18 <chichov> just for the terminology: the address is Base58(pubkeyHash)?
121 2014-05-24 15:47:21 <dabura667> Base58(NetworkByte||pubkeyHash||checksum); NetworkByte = 0x00, checksum = sha256(sha256(NetworkByte||pubkeyHash))(first 4 bytes only)
122 2014-05-24 15:48:29 <dabura667> chichov
123 2014-05-24 15:50:11 <dabura667> so with pubkeyhash of 0xc4c5d791fcb4654a1ef5e03fe0ad3d9c598f9827
124 2014-05-24 15:50:56 <dabura667> we sha256(sha256(00c4c5d791fcb4654a1ef5e03fe0ad3d9c598f9827))[:4]
125 2014-05-24 15:51:11 <dabura667> which is 4abb8f1a
126 2014-05-24 15:51:35 <dabura667> Base58 encode 00c4c5d791fcb4654a1ef5e03fe0ad3d9c598f98274abb8f1a to get 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T
127 2014-05-24 15:52:04 <sipa> chichov left
128 2014-05-24 15:52:53 <dabura667> oops
129 2014-05-24 15:53:16 <sipa> and i'm sure he knows
130 2014-05-24 15:53:27 <sipa> he's just asking for terminology and how it is implemented
131 2014-05-24 16:07:18 <CodeShark> sipa: I presumed as much - blocks out of order...but 700+ out of order blocks and no tip updates?
132 2014-05-24 16:07:56 <sipa> if you're more than 700 blocks behind that's perfectly possible
133 2014-05-24 16:08:00 <sipa> eventually they'll connect
134 2014-05-24 16:27:43 <coryfields> wumpus: i think with those two PR's, the gitian OSX build is do-able for 0.9.2 again
135 2014-05-24 16:39:28 <CodeShark> sipa: it's getting stuck on ORPHAN BLOCK 751
136 2014-05-24 16:39:49 <CodeShark> it keeps showing new orphan blocks (different hashes) but the count remains 751
137 2014-05-24 16:40:39 <sipa> CodeShark: that's because the memory pool is limited to 750
138 2014-05-24 16:40:48 <sipa> so it drops orphans when there's more
139 2014-05-24 16:40:57 <CodeShark> the tip hasn't updated, though
140 2014-05-24 16:41:02 <CodeShark> so it seems to be stuck
141 2014-05-24 16:41:13 <sipa> how long has it been?
142 2014-05-24 16:41:17 <CodeShark> several hours
143 2014-05-24 16:41:20 <sipa> ouch
144 2014-05-24 16:41:23 <sipa> mainnet?
145 2014-05-24 16:41:25 <CodeShark> yes
146 2014-05-24 16:43:14 <CodeShark> when I restart it, it does add to the tip for a while
147 2014-05-24 16:43:19 <CodeShark> then it seems to get stuck again
148 2014-05-24 16:45:03 <sipa> ugh
149 2014-05-24 16:45:16 <sipa> i really want to get rid of that code
150 2014-05-24 16:47:58 <CodeShark> do you have something to replace it yet?
151 2014-05-24 16:48:46 <CodeShark> I really like the architecture we've discussed earlier - but it would require an almost total reimplementation of the networking cod
152 2014-05-24 16:48:48 <CodeShark> *code
153 2014-05-24 16:49:01 <sipa> been working on headers-first sync for... a year or so now :)
154 2014-05-24 16:49:06 <sipa> 
ACTION doesn't have that much time

155 2014-05-24 16:49:30 <CodeShark> get the Bitcoin Foundation to pay you ;)
156 2014-05-24 16:49:46 <CodeShark> it would be a great use of funds
157 2014-05-24 17:04:02 <benkay> hey theree #bitcoin-dev!
158 2014-05-24 17:04:44 <benkay> i'm looking to use a bitcoin thinger to watch an address as a part of another application. which of the spv clients have the best interfaces against which to program?
159 2014-05-24 17:04:53 <benkay> (or least awful, that'd work too ;) )
160 2014-05-24 17:13:46 <minium> what's the correct way to get from a hex string of a private key to CKey?
161 2014-05-24 17:14:21 <minium> I tried building a CBitcoinSecret from EncodeBase58(ParseHex("string")), but it says it's not valid
162 2014-05-24 17:20:18 <sipa> you need EncodeBase58Check
163 2014-05-24 17:41:26 <BatBuddha> so im sniffing raw bitcoin packets with wireshark. it catches the version message, gets the magic and payload size right, but neglects the checksum, messing interpretation of everything else up.  any idea why?
164 2014-05-24 17:43:08 <sipa> maybe it was written for pre-209 protocol version which was removed in februari 2012?
165 2014-05-24 17:43:25 <sipa> which did not have a checksum on the version message
166 2014-05-24 17:44:14 <BatBuddha> thats what I thought. was hoping there might be an upgrade to the filter but I guess not.
167 2014-05-24 17:44:42 <sipa> write it yourself :)
168 2014-05-24 17:45:33 <BatBuddha> got some work set out for me then :)
169 2014-05-24 17:46:58 <coryfields> anyone around who could do a gitian build?
170 2014-05-24 17:47:02 <BatBuddha> actually looks like theres a couple more up to date repos if I build from source
171 2014-05-24 18:20:46 <CodeShark> there doesn't really seem to be too much of a point storing orphan blocks if we only store 750
172 2014-05-24 18:21:40 <CodeShark> at least if the intention is to avoid network overhead
173 2014-05-24 18:22:29 <CodeShark> I guess it arguably shaves off a few minutes for a fast connection
174 2014-05-24 18:23:07 <CodeShark> what we need is parallel sync
175 2014-05-24 18:23:40 <CodeShark> could the protocol be modified to improve parallel sync capabilities?
176 2014-05-24 18:24:01 <CodeShark> i.e. avoiding downloading long chains that don't connect to the genesis block
177 2014-05-24 18:25:01 <CodeShark> also applicable to headers-only sync
178 2014-05-24 18:25:06 <CodeShark> or headers-first
179 2014-05-24 18:27:43 <CodeShark> i.e. detecting bad chains by target and timestamp
180 2014-05-24 18:31:30 <CodeShark> I'm also seeing this orphan block saturation issue with 0.9.2, not just master/HEAD
181 2014-05-24 18:32:11 <minium> I'll be damned, it seems like the example in the wiki doesn't use a valid public key
182 2014-05-24 18:32:42 <minium> although, nope, my bad
183 2014-05-24 18:33:21 <lechuga_> CodeShark: oprhan block saturation issue?
184 2014-05-24 18:33:46 <minium> I got the bug, it's missing the 0x80 private key prefix
185 2014-05-24 18:35:28 <sipa> CodeShark: if we didn't store orphans we'd download the same block over and over again (the newly announced tips durinh sync)
186 2014-05-24 18:35:42 <sipa> and with headers-first, parallel download is easy
187 2014-05-24 18:35:59 <CodeShark> lechuga_: when doing initial sync, it downloads a bunch of orphan blocks and fills the mempool
188 2014-05-24 18:36:59 <sipa> note that orphan here just means "we don't have their parent yet", not "blocks orphaned by a reorg"
189 2014-05-24 18:37:13 <CodeShark> we really should come up with a new term for this
190 2014-05-24 18:37:26 <sipa> too late
191 2014-05-24 18:37:29 <lechuga_> heh
192 2014-05-24 18:37:46 <CodeShark> well, it seems that the term "orphan" has been mostly coopted for the latter sense
193 2014-05-24 18:37:54 <CodeShark> so we should come up with a new term for the former sense
194 2014-05-24 18:38:06 <CodeShark> since it only really affects the core code
195 2014-05-24 18:38:13 <CodeShark> and isn't really relevant at the user level
196 2014-05-24 18:38:50 <gmaxwell> "unresolved-parent"
197 2014-05-24 18:38:55 <CodeShark> I propose "unconnected block"
198 2014-05-24 18:38:56 <lechuga_> "bastard"
199 2014-05-24 18:38:56 <shadowbroker> newborn?
200 2014-05-24 18:39:22 <shadowbroker> or genesis block
201 2014-05-24 18:39:24 <shadowbroker> iono
202 2014-05-24 18:39:54 <Diablo-D3> sipa: blocks orphaned by a re-org is an alternate reality
203 2014-05-24 18:40:19 <CodeShark> Diablo-D3: unfortunately it seems most of the community lives in that alternate reality
204 2014-05-24 18:40:38 <CodeShark> language is defined by usage
205 2014-05-24 18:40:50 <CodeShark> and the usage now is almost exclusively this sens
206 2014-05-24 18:40:56 <Diablo-D3> [02:36:59] <sipa> note that orphan here just means "we don't have their parent yet",
207 2014-05-24 18:41:03 <Diablo-D3> you're using orphan weirdly then
208 2014-05-24 18:41:14 <Diablo-D3> we dont have a word for that, and its not orphan
209 2014-05-24 18:41:23 <Luke-Jr> we do, "stale block"
210 2014-05-24 18:41:51 <lechuga_> i was calling them "side chain blocks" but that obviously doesn't work in modern context
211 2014-05-24 18:41:54 <Diablo-D3> Luke-Jr: its not stale if we dont have the parent yet though
212 2014-05-24 18:42:21 <Luke-Jr> eh, that's just an orphan block
213 2014-05-24 18:42:26 <lechuga_> agree
214 2014-05-24 18:42:43 <Diablo-D3> 
ACTION shrugs

215 2014-05-24 18:42:47 <Luke-Jr> I thought you meant the ones we have a parent for, but aren't in the main chain, which are called stale
216 2014-05-24 18:42:57 <Diablo-D3> yeah, those are stale
217 2014-05-24 18:43:14 <Diablo-D3> although the term is used more for shares, but hey
218 2014-05-24 18:44:34 <Zoop_> so i hadn't run the bitcoin client for a few months
219 2014-05-24 18:44:39 <Zoop_> opened it up
220 2014-05-24 18:44:47 <Zoop_> everything loaded just fine
221 2014-05-24 18:44:55 <Zoop_> i realise it's an old version
222 2014-05-24 18:44:58 <Zoop_> close it up
223 2014-05-24 18:45:00 <CodeShark> given that the size of the community that still uses "orphan block" in the original sense of "we don't know the parent" is significantly smaller than the size of the community that uses "orphan block" to mean "in side chain" the path of least resistance is to just accept the latter definition and come up with a new term for the former
224 2014-05-24 18:45:02 <Zoop_> update
225 2014-05-24 18:45:07 <Zoop_> run it again
226 2014-05-24 18:45:13 <Zoop_> everything loads
227 2014-05-24 18:45:28 <Zoop_> but program is stuck in the tray bar
228 2014-05-24 18:45:34 <Zoop_> consuming all my cpu
229 2014-05-24 18:45:40 <Zoop_> for a solid 5 minutes
230 2014-05-24 18:46:05 <Luke-Jr> CodeShark: I wouldn't mind abandoning the confused term entirely, but using the *wrong* term is just wrong :p
231 2014-05-24 18:46:16 <Luke-Jr> Zoop_: this is not #bitcoin (where support is)
232 2014-05-24 18:46:28 <Zoop_> oh shit
233 2014-05-24 18:46:29 <CodeShark> Luke-Jr: for better or worse, usage makes terms *right*
234 2014-05-24 18:46:30 <Zoop_> sorry
235 2014-05-24 18:46:33 <Zoop_> ;_;
236 2014-05-24 18:46:36 <CodeShark> it's just how language evolves
237 2014-05-24 18:46:50 <Luke-Jr> CodeShark: well, in English, it's wrong :p
238 2014-05-24 19:15:51 <lechuga_> sipa: can you point me to your block downloading optimization experiment branch?
239 2014-05-24 19:41:02 <minium> is there any way (through the API) to dump all bitcoin addresses in a wallet?
240 2014-05-24 19:42:16 <lechuga_> bitcoind listreceivedbyaddress 0 true
241 2014-05-24 19:42:44 <minium> lechuga_: that's neat, thank you
242 2014-05-24 19:43:02 <lechuga_> np
243 2014-05-24 19:44:46 <gmaxwell> lechuga_: that doesn't show all the addresses in the wallet, just all the used ones, not the future ones.
244 2014-05-24 19:45:02 <gmaxwell> There is no way to get out the future ones, since doing so potentially invalidates backups.
245 2014-05-24 19:45:22 <minium> gmaxwell: what do you mean with future addresses precisely?
246 2014-05-24 19:45:43 <gmaxwell> minium: the address pool, addresses that are precomputed buy have not been issued yet.
247 2014-05-24 19:45:51 <minium> oh, that one
248 2014-05-24 19:46:06 <gmaxwell> You should probably not be messing around with addresses nad low level wallet stuff unless you've got a pretty firm handle on how things like the address pool work.
249 2014-05-24 19:46:38 <minium> that's no problem, I'm just importing a few keys manually and want to be able to list the addresses for them
250 2014-05-24 21:21:33 <elichai2> something exciting in the development?
251 2014-05-24 21:44:22 <jgarzik> elichai2, yes
252 2014-05-24 22:04:39 <elichai2> jgarzik: ?
253 2014-05-24 22:11:36 <posita> This is a purely theoretical nitpick, since I'm pretty sure that a transaction with more than 0xffffffff outputs can't practically exist, but the Wiki claims up to a full 1-9 byte VarInt for input/output counters, whereas it looks like the source only allows for 1-5 (i.e., it uses u_int32s, not u_int64s).
254 2014-05-24 22:11:43 <posita> See: https://en.bitcoin.it/wiki/Transactions
255 2014-05-24 22:11:48 <posita> Vs: https://github.com/bitcoin/bitcoin/blob/master/src/core.h#L75
256 2014-05-24 22:12:00 <posita> (If anyone cares. I just noticed it and thought I'd bring it up.)
257 2014-05-24 22:13:08 <posita> If anything, it seems like the Wiki should probably change (not the code).
258 2014-05-24 22:22:44 <elichai2> jgarzik: