1 2013-12-19 00:05:00 <cfields> gavinandresen: backlog ping
  2 2013-12-19 00:05:15 <cfields> mtbomb: pastebin your config.log if you'd like me to help debug for you
  3 2013-12-19 00:06:02 <cfields> gavinandresen: for backlog: is openssl cert loading+osx+qt5 known broken? It's failing a test here.
  4 2013-12-19 00:08:04 <cfields> i'm going to go ahead and PR the qt5 build-support with that caveat. I have a feeling you can track it down much easier than me.
  5 2013-12-19 00:17:43 <mtbomb> cfields: here you go
  6 2013-12-19 00:17:45 <mtbomb> http://pastebin.com/raw.php?i=WN7s9UJe
  7 2013-12-19 00:19:31 <cfields> mtbomb: that looks quite strange. what version of OSX ?
  8 2013-12-19 00:19:38 <mtbomb> 10.7.5
  9 2013-12-19 00:19:43 <mtbomb> I am on a intel i5
 10 2013-12-19 00:20:25 <mtbomb> I think I followed all the steps with MacPorts
 11 2013-12-19 00:20:43 <mtbomb> Also I ran that as administrator, not sure if it matters
 12 2013-12-19 00:22:11 <maaku> mtbomb: config.log?
 13 2013-12-19 00:22:56 <cfields> mtbomb: ah, are you using options for a universal binary?
 14 2013-12-19 00:23:14 <cfields> CXXFLAGS="-arch foo -arch bar" or so?
 15 2013-12-19 00:23:20 <mtbomb> I literally just followed the instructions in the repo docs
 16 2013-12-19 00:23:25 <mtbomb> I didn't change any steps
 17 2013-12-19 00:23:39 <mtbomb> How can I check the CXXFLAGS?
 18 2013-12-19 00:23:44 <cfields> so just vanilla "./configure" ?
 19 2013-12-19 00:23:50 <mtbomb> yes
 20 2013-12-19 00:24:17 <cfields> mtbomb: wait, all of you standard headers are missing
 21 2013-12-19 00:24:34 <cfields> mtbomb: please post the entire log, no snipping
 22 2013-12-19 00:24:39 <mtbomb> ok
 23 2013-12-19 00:24:45 <mtbomb> config.log ?
 24 2013-12-19 00:25:06 <maaku> mtbomb: there should be a config.log file file
 25 2013-12-19 00:25:12 <maaku> it has the full details
 26 2013-12-19 00:26:24 <cfields> mtbomb: yea
 27 2013-12-19 00:26:49 <mtbomb> ok, try this
 28 2013-12-19 00:26:51 <mtbomb> http://pastebin.com/raw.php?i=vXk3Uayr
 29 2013-12-19 00:27:18 <mtbomb> before I just sent the output from running the command. This is from the log file.
 30 2013-12-19 00:27:58 <cfields> ok, there's the prob
 31 2013-12-19 00:28:13 <maaku> install bdb
 32 2013-12-19 00:28:28 <mtbomb> ok
 33 2013-12-19 00:29:48 <mtbomb> is that berkley db ?
 34 2013-12-19 00:30:30 <mtbomb> I ran this command: sudo port install boost db48@+no_java openssl miniupnpc
 35 2013-12-19 00:30:36 <mtbomb> Will that not get it done ?
 36 2013-12-19 00:32:07 <maaku> i don't know
 37 2013-12-19 00:32:16 <maaku> this is someone getting in your build params: -LError: No available formula for berkeley-db4
 38 2013-12-19 00:32:48 <cfields> mtbomb: do you have LIBS exported for some reason?
 39 2013-12-19 00:33:02 <mtbomb> I believe I am starting from a fresh Xcode install
 40 2013-12-19 00:33:11 <mtbomb> so I would have whatever is the default
 41 2013-12-19 00:33:17 <mtbomb> Is there a way to check?
 42 2013-12-19 00:33:20 <maaku> cfields: he has both macports and brew installed
 43 2013-12-19 00:33:21 <cfields> ah, i think i see
 44 2013-12-19 00:33:24 <cfields> brew is there
 45 2013-12-19 00:33:33 <mtbomb> I tried Brew first
 46 2013-12-19 00:33:42 <mtbomb> then ran into an issue, so used ports instead
 47 2013-12-19 00:34:01 <cfields> mtbomb: for now, move brew to brew.old or so
 48 2013-12-19 00:34:06 <cfields> just the binary. that'll fix you.
 49 2013-12-19 00:34:13 <cfields> looking into a real fix.
 50 2013-12-19 00:34:18 <mtbomb> ok, let me try that.
 51 2013-12-19 00:34:36 <cfields> actually...
 52 2013-12-19 00:34:51 <cfields> ./configure BREW=
 53 2013-12-19 00:34:53 <cfields> should work too
 54 2013-12-19 00:37:44 <mtbomb> cool.
 55 2013-12-19 00:37:56 <mtbomb> I believe that worked. I am building now
 56 2013-12-19 00:38:06 <btiefert> I've untangled macports and brew before (removing both and reinstalling python + brew), should you need any assistance.
 57 2013-12-19 00:38:06 <mtbomb> Thanks for the help guys!
 58 2013-12-19 00:38:35 <mtbomb> should I just use cfields' suggestion then? or do I need to do more?
 59 2013-12-19 00:38:55 <cfields> btiefert: in this case, it's our configure, doesn't have to do with brew/macports
 60 2013-12-19 00:39:24 <cfields> the problem is that we have to make a guess as to which one you are using. in this case, we chose both :p
 61 2013-12-19 00:39:42 <mtbomb> great. I am coming from the eclipse/java world. I don't know anything about these build scripts
 62 2013-12-19 00:40:35 <mtbomb> Is there a way you can configure an option for the command line on configure, then just use that in the docs tutorial for each section ?
 63 2013-12-19 00:41:05 <MarkProffitt> Why does it take so long to download the blockchain? What transfer system is being used?
 64 2013-12-19 00:41:24 <BlueMatt> IPoAC
 65 2013-12-19 00:41:46 <BlueMatt> if its a problem for you, you're using the wrong type of client
 66 2013-12-19 00:42:37 <maaku> MarkProffitt: https://bitcointalk.org/index.php?topic=145386.0
 67 2013-12-19 00:43:04 <MarkProffitt> maaku, thank you
 68 2013-12-19 00:44:21 <MarkProffitt> Maybe BitTorrent should be built into the clients?
 69 2013-12-19 00:45:08 <BlueMatt> ^ fundamental misunderstanding of the issues
 70 2013-12-19 00:45:45 <maaku> BlueMatt: meh, i'm not so sure
 71 2013-12-19 00:45:51 <BlueMatt> most of the reason its slow is crypto
 72 2013-12-19 00:45:56 <BlueMatt> the other half is poor implementation
 73 2013-12-19 00:45:57 <maaku> IBD is a big strain on nodes
 74 2013-12-19 00:46:15 <BlueMatt> full nodes dont have to serve the chain
 75 2013-12-19 00:46:20 <BlueMatt> (falls under poor implementation)
 76 2013-12-19 00:46:36 <maaku> if there were a really small, simple one-file bittorrent implementation, I'd be in favor of using it to download to latest checkpoint
 77 2013-12-19 00:46:45 <BlueMatt> no
 78 2013-12-19 00:46:50 <maaku> (just include the infohash in checkpoint.cpp)
 79 2013-12-19 00:46:51 <BlueMatt> there are far better ways of doing this
 80 2013-12-19 00:46:58 <BlueMatt> without just blindly pulling in yet another library
 81 2013-12-19 00:47:15 <maaku> " really small, simple one-file bittorrent implementation"
 82 2013-12-19 00:47:39 <BlueMatt> meh
 83 2013-12-19 00:47:51 <BlueMatt> there are better ways to do it in bitcoin that dont rely on checkpoints, which is another nice property to have
 84 2013-12-19 00:48:03 <BlueMatt> also, now we have 2 p2p networks?
 85 2013-12-19 00:48:25 <BlueMatt> even if you find a simple, small one, we cant use trackers or people will freak out, and dht is broken as hell if its actually under attack
 86 2013-12-19 00:48:27 <maaku> BlueMatt: yes, coinbase commitments of deterministic torrent infohashes
 87 2013-12-19 00:48:34 <BlueMatt> :(
 88 2013-12-19 00:48:40 <BlueMatt> so we'd have to use our own peerdb
 89 2013-12-19 00:48:40 <gmaxwell> yuck.
 90 2013-12-19 00:48:56 <BlueMatt> so now that simple torrent implementation has to interface with a few points in bitcoind
 91 2013-12-19 00:49:10 <BlueMatt> and all of a sudden youre doing more work than you need to to do just do downloads right in bitcoin p2p
 92 2013-12-19 00:49:29 <BlueMatt> plus now you want to fight for miner adoption?
 93 2013-12-19 00:49:30 <gmaxwell> There is no @#$*(@ reason to use bittorrent we have our own p2p network which _must_ be reliable or the system will fail. And we can transfer data more efficiently since we understand the data and its self authenticating.
 94 2013-12-19 00:51:04 <MarkProffitt> "your own p2p network" is ridiculously slow
 95 2013-12-19 00:51:17 <BlueMatt> no, its not
 96 2013-12-19 00:51:20 <BlueMatt> its poorly implemented
 97 2013-12-19 00:51:26 <BlueMatt> but only by a few small bugs
 98 2013-12-19 00:51:33 <BlueMatt> and, bittorrent is really no better
 99 2013-12-19 00:51:44 <BlueMatt> at least under attack
100 2013-12-19 00:52:10 <MarkProffitt> I've downloaded GB+ sized file using BitTorrent in an hour or less, it takes days to download the blockchain
101 2013-12-19 00:52:23 <MarkProffitt> That is ridiculous
102 2013-12-19 00:52:25 <BlueMatt> read scrollback, please
103 2013-12-19 00:53:57 <MarkProffitt> I read it and you didn't answer anything
104 2013-12-19 00:54:10 <MarkProffitt> Maybe you care to explain it better>
105 2013-12-19 00:54:12 <MarkProffitt> ?
106 2013-12-19 00:54:23 <BlueMatt> <BlueMatt> but only by a few small bugs
107 2013-12-19 00:54:23 <BlueMatt> <BlueMatt> its poorly implemented
108 2013-12-19 00:54:30 <gmaxwell> MarkProffitt: Please watch your tone. You are a guest here. Please try to treat the people responding to you with respect.
109 2013-12-19 00:54:32 <BlueMatt> there are a few things that need tweaked and then it will be far better
110 2013-12-19 00:54:50 <BlueMatt> and tweaking those things is far easier than pulling in a bittorrent library to do the transfers
111 2013-12-19 00:54:57 <BlueMatt> which will introduce lots of additional overhead
112 2013-12-19 00:55:26 <BlueMatt> welcome to bitcoin: more things need done than there are developers who can review pulls
113 2013-12-19 00:55:35 <gmaxwell> MarkProffitt: takes under an hour for me. There is more to syncing the blockchain than just fetching the data— where you've seen long delays thats mostly due to some inadequacies in the syncing behavior in the current released versions of bitcoin-qt which are being fixed now. (and must be fixed for unrelated reasons in any case)
114 2013-12-19 00:55:53 <MarkProffitt> OK, so what are those tweaks? Why haven't they occurred already?
115 2013-12-19 00:56:04 <BlueMatt> <BlueMatt> welcome to bitcoin: more things need done than there are developers who can review pulls
116 2013-12-19 00:57:05 <MarkProffitt> gmaxwell, why does it only take you 1 hour where everyone else I've seen takes days? Btw, I have a 12 Mbps conection
117 2013-12-19 00:57:28 <BlueMatt> Ive only ever seen it take an hour or so since ultraprune
118 2013-12-19 00:57:32 <gmaxwell> MarkProffitt: https://github.com/bitcoin/bitcoin/pull/2964  (but its in the process of being split into smaller pulls)
119 2013-12-19 00:57:45 <BlueMatt> maybe once or twice it was slow, restarted to get a different download peer, back to fast
120 2013-12-19 00:57:48 <gmaxwell> MarkProffitt: luck in which peers you select.
121 2013-12-19 00:58:18 <gmaxwell> BlueMatt: it's much worse than that for most people most of the time now, there are a _LOT_ of really slow/poorly behaved nodes on the network since the last month or so.
122 2013-12-19 00:58:35 <BlueMatt> :(
123 2013-12-19 00:58:37 <warren> only the last month?
124 2013-12-19 00:58:55 <BlueMatt> lots and lots of people reimplementing bitcoin or using terrible libraries
125 2013-12-19 00:59:04 <BlueMatt> lots and lots more interest in developing bitcoin-based things
126 2013-12-19 00:59:13 <berndj> speaking of too few devs, is there a list of fairly janitorial stuff that needs doing?
127 2013-12-19 00:59:16 <BlueMatt> which often use something other than bitcoind, often much worse than...
128 2013-12-19 00:59:27 <BlueMatt> berndj: most of it is reviewing pulls, sadly
129 2013-12-19 00:59:35 <gmaxwell> berndj: review and QA are mostly what we need more of, and everyone can contribute to that.
130 2013-12-19 00:59:48 <BlueMatt> berndj: but writing test-cases/building/testing pulls/etc are all incredibly useful
131 2013-12-19 01:00:33 <warren> how complete is btcd?
132 2013-12-19 01:01:25 <BlueMatt> 
ACTION wouldnt call any bitcoin libraries "complete" until they get serious review by a core dev, and don't claim to have a working full-verification engine

133 2013-12-19 01:01:56 <TheLordOfTime> ;;op
134 2013-12-19 01:02:01 <TheLordOfTime> ;;deop
135 2013-12-19 01:02:33 <BlueMatt> warren: anyone who claims to have a full verification engine that people can/should rely on is lying to themselves and shouldn't be trusted to build anything bitcoin
136 2013-12-19 01:02:58 <BlueMatt> (dont actually know if btcd is claiming that, but generally)
137 2013-12-19 01:03:33 <warren> BlueMatt: the coinpunk guy mentioned something about switching to it
138 2013-12-19 01:03:37 <warren> never tried it myself
139 2013-12-19 01:04:35 <BlueMatt> I havent had much interaction, but after some basic clarification in the beginning, they are one of the few groups that has actually run the block tester
140 2013-12-19 01:04:58 <BlueMatt> but, sadly, I havent seen them submit any additional tests upstream or to blocktester, so I doubt their commitment to testing
141 2013-12-19 01:05:11 <MarkProffitt> maaku, thanks. Using hte torrent I downloaded the blockchian in a 3 minutes. The wallet is still 3 weeks behind.
142 2013-12-19 01:05:15 <BlueMatt> (aside from their commitment to getting code-coverage testing, which is backwards...)
143 2013-12-19 01:05:28 <BlueMatt> MarkProffitt: no, you didnt...you still have to import it
144 2013-12-19 01:05:34 <MarkProffitt> fine
145 2013-12-19 01:06:12 <sipa> if your wallet is only 3 weeks behind, the torrent will not help you
146 2013-12-19 01:06:23 <sipa> as it is only until block 250k
147 2013-12-19 01:06:48 <Luke-Jr> would it be bad if I use the "video" UNIX user group for mining devices? <.<
148 2013-12-19 01:06:59 <Luke-Jr> simply because Fedora/RedHat are missing "plugdev"..
149 2013-12-19 01:07:40 <BlueMatt> Luke-Jr: if you point them to a pool that takes a stance on fees/standard tx acceptance, instead of outsourcing that to devs, no
150 2013-12-19 01:07:44 <BlueMatt> (might still be illegal though)
151 2013-12-19 01:08:06 <sipa> ??
152 2013-12-19 01:08:07 <Luke-Jr> BlueMatt: wtf?
153 2013-12-19 01:08:32 <sipa> haha!
154 2013-12-19 01:08:35 <Luke-Jr> I don't get it <.<
155 2013-12-19 01:08:41 <sipa> unix user group
156 2013-12-19 01:08:48 <sipa> he thinks about some community
157 2013-12-19 01:08:53 <Luke-Jr> O.o
158 2013-12-19 01:09:11 <sipa> BlueMatt: he means group as in /etc/groups
159 2013-12-19 01:09:19 <BlueMatt> oh, that kind of group
160 2013-12-19 01:09:27 <BlueMatt> in that case its just a UNIX group, not a UNIX user group...
161 2013-12-19 01:09:34 <Luke-Jr> ok
162 2013-12-19 01:09:40 <Luke-Jr> …
163 2013-12-19 01:09:41 <sipa> wb
164 2013-12-19 01:09:57 <BlueMatt> damn sloppy focus and close shortcuts...
165 2013-12-19 01:12:42 <MarkProffitt> sipa, thanks for the info.
166 2013-12-19 01:37:32 <chrisbro> have any DACs been developed yet on top of bitcoin?
167 2013-12-19 01:40:57 <edcba> digital analog converters ?
168 2013-12-19 01:41:15 <chrisbro> http://en.wikipedia.org/wiki/Decentralized_Autonomous_Corporation
169 2013-12-19 01:42:01 <chrisbro> though the other kind of DACs are nice too.
170 2013-12-19 01:42:12 <edcba> i doubt it will ever be possible since APIs tend to break
171 2013-12-19 01:42:39 <edcba> i mean in general not bitcoin apis :)
172 2013-12-19 01:44:35 <chrisbro> so, say, a sports betting DAC being reliant on an API that reports sports data.
173 2013-12-19 01:50:17 <BlueMatt> chrisbro: talk to jgarzik
174 2013-12-19 01:52:18 <chrisbro> BlueMatt: will do.
175 2013-12-19 01:53:04 <chrisbro> fascinated by the idea but don't quite grok the protocol enough yet to come up with something
176 2013-12-19 01:54:33 <wyager> Anyone know of any tools that support BIP 0038 besides that one online wallet generator? If not, I'm going to whip one up
177 2013-12-19 01:55:20 <gmaxwell> wyager: I'd really not recommend further promoting BIP38 at this time. People are working on a replacement.
178 2013-12-19 01:55:26 <wyager> Oh good
179 2013-12-19 01:55:36 <wyager> Is this progress being logged somewhere? I would like to help
180 2013-12-19 01:56:12 <gmaxwell> yea, I'm looking for the link to the forum thread.
181 2013-12-19 01:56:22 <wyager> Thank you
182 2013-12-19 01:56:24 <monolithik> chrisbro: I like the idea of micropayment based DACs that provide services like tor nodes or VPN access on AWS whenever the spot instance price is low enough
183 2013-12-19 01:58:17 <chrisbro> monolithik: exactly. i guess i'm just having trouble envisioning how to go about actually writing one so I was hoping there was some code out there for me to take a peek at
184 2013-12-19 01:59:10 <monolithik> chrisbro: I've been thinking about the underlying infrastructure that would be needed to do it. Most promising method in the short term is colored coins
185 2013-12-19 01:59:37 <monolithik> A DAC issues coins of a certain color that it accepts as payment for the service it provides.
186 2013-12-19 02:00:10 <chrisbro> do these coins have to be an alt currency, or are they embedded in bitcoin's protocol?
187 2013-12-19 02:00:46 <monolithik> it's possible to embed them as metadata in the blockchain. There are currently competing proposals on the best way to do so, but it is definitely feasable
188 2013-12-19 02:01:09 <chrisbro> interesting. any idea what the leading proposals are?
189 2013-12-19 02:01:48 <gmaxwell> wyager: https://bitcointalk.org/index.php?topic=258678.0
190 2013-12-19 02:01:57 <sunspot> a replacement for dns would be a good service starting point
191 2013-12-19 02:02:06 <gmaxwell> Can you please take the offtopic freaky "DAC" stuff someplace else?
192 2013-12-19 02:02:11 <sunspot> hehe
193 2013-12-19 02:02:49 <jgarzik> heh
194 2013-12-19 02:02:58 <monolithik> gmaxwell: sorry. chrisbro: pm me if you want to discuss.
195 2013-12-19 02:03:16 <BlueMatt> #bitcoin-da
196 2013-12-19 02:03:16 <BlueMatt> c
197 2013-12-19 02:03:20 <BlueMatt> #bitcoin-dac
198 2013-12-19 02:39:15 <BlueMatt> 
ACTION realizes you could train an hmm on the halmark channel and derive literally the entire channel without any strange-sounding sentences

199 2013-12-19 02:49:15 <Diablo-D3> ;;ticker
200 2013-12-19 02:49:16 <gribble> MtGox BTCUSD ticker | Best bid: 558.0, Best ask: 559.0, Bid-ask spread: 1.00000, Last trade: 559.0, 24 hour volume: 110502.36373361, 24 hour low: 455.0, 24 hour high: 709.0, 24 hour vwap: 561.18928
201 2013-12-19 02:49:20 <Diablo-D3> er wrong channel
202 2013-12-19 03:19:49 <jaekwon> can anyone point me to the code in bitcoin where the address is generated from the pubkey, including the network byte prefix & the checksum of the hash160?
203 2013-12-19 03:24:54 <jaekwon> nm got it, it's in base58.h i think.
204 2013-12-19 05:13:19 <Sythic> Hey, does anyone know the current version of Bitcoin (to be used in the version message handshake)?
205 2013-12-19 05:14:58 <Luke-Jr> Sythic: you mean protocol version.. see what 0.8.6 sends
206 2013-12-19 05:15:59 <Sythic> Right, would it be 86000?
207 2013-12-19 05:16:13 <wyager> I'm trying to grok the crypto behind BIP 0032. No matter how I work it out, it looks like it involves finding two separate HMAC-SHA512s with different messages but the same (or correlated) digests. Obviously that's not right. Does anyone know of a walkthrough of how/why the BIP 0032 crypto works? Specifically, why CKD((k, c), i)*G = CKD'((k*G, c), i)
208 2013-12-19 05:17:35 <wyager> I'm just confused because CKD and CKD' both involve mangling their arguments with HMAC-SHA512, so I don't really see how you can just carry on using EC arithmetic on their output
209 2013-12-19 05:17:55 <Luke-Jr> Sythic: no
210 2013-12-19 05:18:33 <Sythic> Sorry, 80600 is what i believe version.h says it should be
211 2013-12-19 05:19:16 <Luke-Jr> 70001
212 2013-12-19 05:19:43 <Sythic> hmm? for bitcoin version 0.8.6? that doesnt make sense..
213 2013-12-19 05:20:07 <Luke-Jr> Sythic: Bitcoin-Qt 0.8.6, not Bitcoin
214 2013-12-19 05:20:12 <Luke-Jr> Bitcoin is a protocol, not software
215 2013-12-19 05:20:48 <Sythic> Oh i see, gotcha, thanks
216 2013-12-19 05:30:37 <wyager> Anyone? This is really confusing me. I must be missing something about HMAC or EC...
217 2013-12-19 05:33:00 <gmaxwell> wyager: you haven't asked a concrete question.
218 2013-12-19 05:33:23 <wyager> I was hoping that someone had written a blog post or something explaining the crypto
219 2013-12-19 05:33:57 <wyager> But my question is, broadly: why does the arithmetic in BIP 0032 hold?
220 2013-12-19 05:34:25 <gmaxwell> Because there is nothing surprising about it in the least?
221 2013-12-19 05:34:40 <wyager> Clearly, considering that it works
222 2013-12-19 05:34:45 <wyager> but I'm obviously missing something
223 2013-12-19 05:35:02 <wyager> Informally, the way I'm understanding it is that it's saying something like
224 2013-12-19 05:35:03 <wyager> (H(c+H(c+0+k+i)) + k % n)*G = (H(c+H(c+2+k*G+i)) + k)*G
225 2013-12-19 05:35:04 <gmaxwell> The only thing it does is scalar,point multiply (in the public derrivation) or a scalar + scalar addition (in a finite field) in the private case.
226 2013-12-19 05:35:37 <wyager> Probably shouldn't use + for both concatenate and add, hold on
227 2013-12-19 05:37:12 <wyager> Re-writing the equations and ignoring a few things that I don't think are critical to understanding, here's what I get
228 2013-12-19 05:37:13 <wyager> (H(c || H(c || "\x00" || k || i)) + k % n)*G = (H(c || H(c || "\x02" || k*G || i)) + k)*G
229 2013-12-19 05:37:26 <gmaxwell> Because the (A+B)*G = A*G + B*G, because the distributive law
230 2013-12-19 05:37:49 <wyager> Right, but what about the fact that the two things inside H() on the different sides of the equation are completely different?
231 2013-12-19 05:38:06 <gmaxwell> They aren't.
232 2013-12-19 05:38:32 <wyager> One side has a "0" and the private key, one side has a "2" and the public key
233 2013-12-19 05:39:40 <gmaxwell> Nope.
234 2013-12-19 05:39:46 <gmaxwell> Are you confusing K and k?
235 2013-12-19 05:39:49 <wyager> No
236 2013-12-19 05:39:55 <wyager> k*G = K
237 2013-12-19 05:40:45 <gmaxwell> Are you confusing the public derivation and the private derivation?
238 2013-12-19 05:40:53 <wyager> CKD' involves hashing the public key (k*G) but CKD involves only hashing the private key (just k), and yet both CKD and CKD' are used in an equivalence
239 2013-12-19 05:41:04 <wyager> I can see how the public derivations are equivalent
240 2013-12-19 05:41:16 <wyager> But that's not what it says
241 2013-12-19 05:41:31 <wyager> It says that the private derivation * G is = to the public derivation
242 2013-12-19 05:41:51 <wyager> but the private derivation involves hashing k and the public derivation involves hashing k*G
243 2013-12-19 05:41:54 <gmaxwell> No, you're confusing two distinct things.
244 2013-12-19 05:42:00 <gmaxwell> Private derivation: knowledge of the private key kpar and cpar is required to compute both ki and Ki. Public derivation: knowledge of the public key Kpar and cpar suffices to compute Ki (but not ki).
245 2013-12-19 05:42:00 <gmaxwell> We allow for two different types of derivation: private and public.
246 2013-12-19 05:42:17 <wyager> Right
247 2013-12-19 05:42:26 <gmaxwell> The private derivation is just that, new keys can _only_ be derrived using private data.
248 2013-12-19 05:42:53 <gmaxwell> They are not in any way equivalent.
249 2013-12-19 05:43:39 <wyager> What two things are not equivalent?
250 2013-12-19 05:44:03 <gmaxwell> private derivation and public derivation.
251 2013-12-19 05:44:19 <wyager> Of course
252 2013-12-19 05:44:25 <wyager> OK, here is where I'm confused
253 2013-12-19 05:44:29 <wyager> from the BIP
254 2013-12-19 05:44:32 <wyager> CKD((k, c), i)*G = CKD'((k*G, c), i)
255 2013-12-19 05:44:57 <wyager> But CKD involves hashing just k, NOT hashing k*G, where CKD' obviously involves hashing k*G
256 2013-12-19 05:45:22 <gmaxwell> Read the entire surrounding text.
257 2013-12-19 05:45:23 <gmaxwell> " with public derivation"
258 2013-12-19 05:45:41 <wyager> Well shit
259 2013-12-19 05:45:44 <wyager> that makes more sense
260 2013-12-19 05:46:04 <gmaxwell> I'll make it more clear, I at least understand how you got caught there now.
261 2013-12-19 05:46:25 <wyager> I wish that whether we were doing a public or private derivation wasn't stored in i
262 2013-12-19 05:46:29 <wyager> rather in a separate boolean
263 2013-12-19 05:46:38 <wyager> it would make it a lot clearer I think
264 2013-12-19 05:46:50 <wyager> Unless that's mathematically important
265 2013-12-19 05:48:22 <gmaxwell> Doing so would complicate implementations and make them far less likely to actually expose both methods, as it would complicate the handling of the coordinates.
266 2013-12-19 05:48:47 <wyager> Fair enough
267 2013-12-19 05:49:08 <gmaxwell> Putting it in the high bit of the index just lets it internalize it completely. This was doubly important because the private was added later and we had to talk other people who implemented it into adding it.
268 2013-12-19 05:49:17 <jcorgan> how long does it take for a new externalip=foo.onion to propagate?  I have a new node up that is advertising that, but other connecting to 8 normal nodes; but i haven't seen any inbound connections via tor except for a manual one to verify tor is working
269 2013-12-19 05:49:39 <wyager> OK, so to continue. Doing a private derivation with CKD((k, c), i)  returns the ith private key, right?
270 2013-12-19 05:50:15 <gmaxwell> jcorgan: should be within 24 hours of the node syncing up completely, assuming that it's all setup right and works.
271 2013-12-19 05:50:36 <gmaxwell> (e.g. have the proxy settings in the node, have the HS setup in tor)
272 2013-12-19 05:50:45 <jcorgan> got it.  i can connect=foo.onion from another node and it shows up ok
273 2013-12-19 05:51:17 <gmaxwell> wyager: sure.
274 2013-12-19 05:51:20 <wyager> (I'm checking if I'm actually understanding this at each step)
275 2013-12-19 05:51:21 <wyager> ok
276 2013-12-19 05:51:37 <wyager> And (the ith private key) * G = (the ith public key), right?
277 2013-12-19 05:51:55 <gmaxwell> right.
278 2013-12-19 05:52:02 <wyager> OK, good.
279 2013-12-19 05:52:29 <wyager> And also, CKD'((k*G, c), i) returns (the ith public key)?
280 2013-12-19 05:52:46 <gmaxwell> or for indexes where public derrivation is used you can use CKD' instead, and it returns public keys and takes a public key in.
281 2013-12-19 05:52:49 <Krellan> Hi, curious about colored coins and how they could be used for a stock exchange
282 2013-12-19 05:52:52 <gmaxwell> Right.
283 2013-12-19 05:52:58 <wyager> OK, so
284 2013-12-19 05:53:17 <Krellan> Point me to a webpage with a project for colored coins?  Are there any existing coins that do that?
285 2013-12-19 05:53:43 <wyager> =>  private derivation with CKD((k,c),i) * G = CKD'((k*G,c),i)
286 2013-12-19 05:54:33 <wyager> Just chaining those 3 things together
287 2013-12-19 05:54:46 <gmaxwell> CKD' returns an error if you use it for an index with private derivation.
288 2013-12-19 05:54:55 <wyager> Sorry
289 2013-12-19 05:55:05 <wyager>  (private derivation with CKD((k,c),i)) * G = CKD'((k*G,c),i)
290 2013-12-19 05:55:54 <gmaxwell> In the BIP the words 'private derivation' refer to the modified formula for i with the high bit set, for which there exists no matching CKD' function.
291 2013-12-19 05:56:12 <gmaxwell> But yes, for indexes which do not have the high bit set  CKD((k,c),i) * G = CKD'((k*G,c),i)
292 2013-12-19 05:56:23 <wyager> hmm
293 2013-12-19 05:56:29 <wyager> ok, let me write this out step by step
294 2013-12-19 05:56:43 <gmaxwell> And thats saying that you can derrive the same public keys starting from either the private data, or the public data.
295 2013-12-19 05:56:54 <wyager> OK
296 2013-12-19 05:56:56 <wyager> good
297 2013-12-19 05:56:59 <wyager> let me write this out proof-like
298 2013-12-19 05:57:06 <wyager> So you can tell me which step is wrong
299 2013-12-19 06:01:23 <wyager> OK
300 2013-12-19 06:01:27 <wyager> I've modified the CKD syntax: the third argument is a string. "private" means private derivation, "public" means public derivation. "private" is the same as having the high bit of i set.
301 2013-12-19 06:01:28 <wyager> 1. CKD((k,c), i, "private") = (ith private key)
302 2013-12-19 06:01:29 <wyager> 2. (ith private key) * G = (ith public key)
303 2013-12-19 06:01:31 <wyager> 3. 1 and 2 => CKD((k,c), i, "private") * G = (ith public key)
304 2013-12-19 06:01:32 <wyager> 4. CKD'((k*G, c), i, "public") = (ith public key)
305 2013-12-19 06:01:32 <wyager> 5. 3 and 5 => CKD((k,c), i, "private") * G = CKD'((k*G, c), i, "public")
306 2013-12-19 06:02:23 <gmaxwell> no, absolutely not.
307 2013-12-19 06:02:30 <wyager> hehe
308 2013-12-19 06:02:34 <wyager> ok, which step is wrong
309 2013-12-19 06:02:38 <wyager> (or steps)
310 2013-12-19 06:03:56 <gmaxwell> wyager: i can never be both "private" and "public", it's high bit cannot be both true and false.
311 2013-12-19 06:04:29 <wyager> What? I never imply that
312 2013-12-19 06:04:35 <wyager> Which step is this in?
313 2013-12-19 06:04:42 <gmaxwell> The step where I stab you.
314 2013-12-19 06:04:44 <gmaxwell> :P
315 2013-12-19 06:04:47 <wyager> lol
316 2013-12-19 06:04:56 <gmaxwell> 22:01 < wyager> 3. 1 and 2 => CKD((k,c), i, "private") * G = (ith public key)
317 2013-12-19 06:04:59 <gmaxwell> 22:01 < wyager> 4. CKD'((k*G, c), i, "public") = (ith public key)
318 2013-12-19 06:05:12 <gmaxwell> in 3 you're talking about i,"private"   and then in 4. you're talking about i,"public"
319 2013-12-19 06:05:17 <gmaxwell> these cannot be the same i.
320 2013-12-19 06:05:32 <wyager> hmm
321 2013-12-19 06:05:36 <wyager> let me think about that
322 2013-12-19 06:06:27 <gmaxwell> e.g. think of this with concrete i values, 1 and -1 (the latter having the high bit set, because twos-compliment)
323 2013-12-19 06:07:15 <wyager> So there is no correspondence between the 1st key and the -1st key?
324 2013-12-19 06:07:21 <jcorgan> the high bit is not masked off before use, is it?
325 2013-12-19 06:07:22 <wyager> They have nothing to do with each other?
326 2013-12-19 06:07:45 <gmaxwell> wyager: correct. They're different indexes.
327 2013-12-19 06:07:54 <wyager> Hmm
328 2013-12-19 06:08:00 <wyager> OK, so I can derive the public key of the 1st key
329 2013-12-19 06:08:06 <gmaxwell> They're derrived in different ways. And the pubkey-using function CKD' cannot be used on the negative indexes.
330 2013-12-19 06:08:06 <wyager> and I can derive the private key of the -1st key
331 2013-12-19 06:08:20 <wyager> So how do I ever get the private key of the 1st key?
332 2013-12-19 06:08:39 <gmaxwell> By running CKD() instead of CKD'()
333 2013-12-19 06:09:42 <wyager> OK, gimme a sec
334 2013-12-19 06:10:24 <gmaxwell> There are kinds of keys BIP32 can produce, "private derivation" and "public derivation". And there are two generating functions CKD() and CKD'().
335 2013-12-19 06:10:48 <wyager> Oh shit
336 2013-12-19 06:10:52 <gmaxwell> CKD() can be used with both "private derivation" and "public derivation", but CKD'() can only be used to generate indexes coorsponding to "public derivation".
337 2013-12-19 06:11:12 <wyager> So the "private derivation" keys are for a completely different set of addresses
338 2013-12-19 06:11:22 <wyager> that can't be determined by someone with just the pubkey
339 2013-12-19 06:11:51 <gmaxwell> Because the "private derivation" intentionally breaks the homorphism, because there is a security weakness created by the homorphism which you'd rather not have when you don't even intend to use CKD'().
340 2013-12-19 06:11:55 <gmaxwell> wyager: yes, exactly.
341 2013-12-19 06:12:02 <wyager> Ahhh
342 2013-12-19 06:12:51 <wyager> OK
343 2013-12-19 06:13:46 <wyager> The way I was trying to comprehend it was as if both functions returned the pubkey in public derivation mode, and CKD returned the privkey corresponding to that index (ignoring the highest bit) in private derivation mode
344 2013-12-19 06:14:20 <gmaxwell> sipa: we should probably rename something so that the "Private child key derivation" / "Public child key derivation" headings are not confused with "Private derivation" and "Public derivation".
345 2013-12-19 06:15:11 <gmaxwell> nah CKD() always returns a private key, CKD'() returns either a public key or an error.
346 2013-12-19 06:15:18 <wyager> OK
347 2013-12-19 06:15:22 <wyager> makes 100x more sense
348 2013-12-19 06:16:23 <gmaxwell> and the generation function depends on i, if i has the high bit set, CKD() does something that CKD'() cannot do.
349 2013-12-19 06:16:33 <wyager> Yeah
350 2013-12-19 06:16:36 <wyager> totally makes sense
351 2013-12-19 06:17:10 <wyager> Maybe put something like this in the document
352 2013-12-19 06:17:11 <wyager> CKD((k,c), 1) = private key A
353 2013-12-19 06:17:12 <wyager> CKD'((K,c), 1) = public key A
354 2013-12-19 06:17:13 <wyager> CKD((k,c), -1) = private key B
355 2013-12-19 06:17:14 <wyager> CKD'((K,c) -1) = error
356 2013-12-19 06:22:22 <gmaxwell> yea, I was thinking of a little graphic with four boxes for CKD / CKD'  on the left and 'Pub derv' 'Priv derv' in the top.. and a red X in one of the quadrants.
357 2013-12-19 06:22:28 <gmaxwell> so vaguely similar.
358 2013-12-19 06:27:53 <wyager> Thanks for being patient with me :)
359 2013-12-19 06:36:00 <gmaxwell> Thanks for tolerating the stab wounds.
360 2013-12-19 06:52:58 <wyager> Another suggestion to help explain the idea behind this:
361 2013-12-19 06:53:01 <wyager> let priv2 = priv + ∆
362 2013-12-19 06:53:01 <wyager> let pub = g * priv
363 2013-12-19 06:53:03 <wyager> pub2 = g * priv2
364 2013-12-19 06:53:04 <wyager> pub2 = g * (priv + ∆)
365 2013-12-19 06:53:05 <wyager> pub2 = (g * priv) + (g * ∆)
366 2013-12-19 06:53:06 <wyager> pub2 = pub + (g*∆)
367 2013-12-19 06:55:05 <wyager> I hope the delta didn't get mangled by IRC
368 2013-12-19 06:55:21 <Arnavion> Not onutf-8 it didn't
369 2013-12-19 07:01:39 <Krellan> I see delta just fine on Linux and Mac, nice
370 2013-12-19 07:02:09 <Krellan> Still looking for info about stock exchange implemented using colored coins - any pointers?
371 2013-12-19 07:04:36 <jcorgan> scenario and question
372 2013-12-19 07:04:47 <jcorgan> i have a new bitcoind node in onlynet=tor mode
373 2013-12-19 07:05:06 <jcorgan> i have two other nodes in the same config with many connections
374 2013-12-19 07:05:19 <jcorgan> i addnode=foo.onion in each of the two other nodes
375 2013-12-19 07:05:29 <jcorgan> and they successfully connect to the new node
376 2013-12-19 07:05:49 <jcorgan> so, is there anything else i have to do for the new node foo.onion to become known to the wider network?
377 2013-12-19 07:06:40 <jcorgan> the foo.onion node has the two inbound connections, no outbound connections, as has been up for an hour or so
378 2013-12-19 07:08:10 <gmaxwell> you must have externalip=foo.onion set
379 2013-12-19 07:08:21 <gmaxwell> (on the foo.onion node)
380 2013-12-19 07:08:22 <jcorgan> yes, it is
381 2013-12-19 07:09:12 <gmaxwell> jcorgan: it should advertise itself after its synced up and again every 24 hours.
382 2013-12-19 07:09:26 <jcorgan> ok, as you said before, thanks
383 2013-12-19 07:09:57 <jcorgan> now to go tackle electrum-server-behind-tor set up
384 2013-12-19 07:16:06 <wyager> Gmaxwell: Before I posted on the thread, I wanted to run this by you: "4 bytes: SHA256(SHA256(master_bitcoin_public_address))[0...3], used both for typo checking and as part of the salt."
385 2013-12-19 07:16:10 <wyager> Why not use a random salt and base58check typo checking? This is an info leak, and someone can figure out which address is held in a cold wallet if the address has ever been used on the blockchain. They only have to iterate over all known addresses.
386 2013-12-19 07:17:45 <wyager> So if the police find your wallet or something, they can prove with a decently high probability that you control the master public address on the wallet
387 2013-12-19 07:18:30 <wyager> If you've used the address, that is
388 2013-12-19 07:19:21 <gmaxwell> wyager: The purpose is to check that the decrypted data is correct, so it actually has to validate the decrypted data.
389 2013-12-19 07:19:29 <gmaxwell> (including typos in the password)
390 2013-12-19 07:19:58 <wyager> Why is it insufficient to validate the encrypted data?
391 2013-12-19 07:20:10 <gmaxwell> Because the user may type in the wrong password.
392 2013-12-19 07:20:36 <wyager> Can't the validation also be encrypted?
393 2013-12-19 07:20:49 <wyager> I.e. the hash itself is encrypted along with everything else
394 2013-12-19 07:20:55 <wyager> and there is a separate random salt
395 2013-12-19 07:20:57 <gmaxwell> The purpose of the salt is, as always, to prevent precomputation attacks from being effective. Ideally it would be some large random value so that the chance of any precomputation gain is negligible even if you had many stolen keys... but that comes at a cost of increasing the key size.
396 2013-12-19 07:20:59 <wyager> No info leak that way
397 2013-12-19 07:22:42 <gmaxwell> Only at the cost of increasing the length. You can propose that, in the old BIP38 stuff the ability to determine the pubkey directly from the encoding was a very intentional feature, but here, indeed, it could perhaps be eliminated.
398 2013-12-19 07:22:45 <wyager> Could we also take SHA(SHA(private key))?
399 2013-12-19 07:24:13 <gmaxwell> yea, sure, someone might whine about the certificational weakness of that (it leaks some data about the private key, but I think its sufficiently insubstantial)
400 2013-12-19 07:25:18 <wyager> OK cool
401 2013-12-19 07:25:20 <wyager> I posted on the thread
402 2013-12-19 07:25:46 <gmaxwell> Good point I can't believe I didn't point that out before, I guess I was still stuck on the mike caldwell's prior stuff that made the address explicitly visible... which I didn't like then but I was defeated. :P
403 2013-12-19 07:25:56 <wyager> Haha
404 2013-12-19 07:26:58 <gmaxwell> fwiw, I personally don't prefer to use the police as the threat model, its often less realistic then plenty of other boring threads, and its politically loaded. (and also moot, since— as sufficiently evil and powerful state authority can just drop you in a hole and throw away the key)
405 2013-12-19 07:27:10 <wyager> True
406 2013-12-19 07:28:05 <gmaxwell> A fine example is just a boring evil made, finds the keys.. you'd prefer she not be able to determine the value lest she realize its a lot and consider it worth bringing in her firearms expert cousin. :P
407 2013-12-19 07:28:23 <wyager> good point haha
408 2013-12-19 07:28:31 <wyager> made the example less political
409 2013-12-19 07:33:29 <HaltingState> gmaxwell, all the bitcoin users will just disappear for indefinite detention on one of the evil empire's prison ships. When you look at theories of competition between currencies, something like bitcoin cant be allowed to exist (unless it is stays something that is really niche like paypal)
410 2013-12-19 07:34:01 <HaltingState> i hope and think bitcoin might stay in that niche until its ready
411 2013-12-19 07:34:10 <gmaxwell> HaltingState: please, not in this channel.
412 2013-12-19 07:52:34 <wyager> gmaxwell: Any idea why the root key gets xor'd with the first 32 bytes of the hash before AES encryption? A fail-safe if AES is broken?
413 2013-12-19 07:54:43 <gmaxwell> wyager: it's whitening, AES is used in ECB mode, without it it would leak repeated patterns in the key.
414 2013-12-19 07:56:06 <wyager> Oh
415 2013-12-19 08:24:22 <The_Fly> if i have issued 'sendfrom' and bitcoind has created a transaction which was not broadcast on the network, is it sufficient to follow these rather hacky steps and confirm the transaction is gone with 'listtransactions' to ensure it will not be broadcast when I next start up bitcoind? http://bitcoin.stackexchange.com/questions/570/is-there-a-way-to-undo-transactions-with-a-too-low-fee/2415#2415
416 2013-12-19 08:25:38 <The_Fly> at the time the network interface was down, and i'd like to purge this transaction completely
417 2013-12-19 08:43:06 <The_Fly> i'll try pywallet as mentioned here https://bitcointalk.org/index.php?topic=35214.0
418 2013-12-19 08:44:04 <The_Fly> just unsure that this is enough to garauntee that the transaction is never broadcast, if anyone could advise i'd appreciate it massively
419 2013-12-19 08:49:11 <tommygunner> just keep bitcoind running, it will rebroadcast
420 2013-12-19 08:49:22 <The_Fly> i dont want to rebroadcast
421 2013-12-19 08:49:44 <tommygunner> oh
422 2013-12-19 08:49:57 <abishek> when will gettransaction method have block details
423 2013-12-19 08:50:23 <The_Fly> tommygunner: that's what im asking, if it is sufficient to db4.8_dump/load to edit wallet.dat
424 2013-12-19 08:51:12 <tommygunner> you could just dump all private keys and import them to a new wallet
425 2013-12-19 08:51:45 <The_Fly> that is the way to be totally sure, and i can do in this case
426 2013-12-19 08:52:45 <wumpus> removing the transaction from the db48 dump is enough to get rid of it
427 2013-12-19 08:53:03 <The_Fly> wumpus: thanks
428 2013-12-19 08:53:09 <wumpus> you could even remove all tx records then do a rescan
429 2013-12-19 08:53:32 <wumpus> (note: do back up your wallet beforehand)
430 2013-12-19 08:53:41 <The_Fly> indeed :) i have been doing so
431 2013-12-19 08:56:18 <The_Fly> the signed transaction is stored in wallet.dat, along with a hasBeenBroadcast(or whatever) flag? that's what i was hoping
432 2013-12-19 09:02:28 <wumpus> the signed transaction is stored in wallet.dat
433 2013-12-19 09:02:34 <wumpus> there is no hasBeenBroadcast flag
434 2013-12-19 09:02:57 <wumpus> it doesn't need one; it rebroadcasts all transactions that are not in a block yet / anymore
435 2013-12-19 09:03:44 <The_Fly> ah, of course, lol
436 2013-12-19 09:04:07 <The_Fly> i was curious, thanks again wumpus
437 2013-12-19 09:06:12 <wumpus> (it would actually be a possible optimization to include a flag when a transaction made it into the block chain at a certain depth so that the rebroadcast logic can skip it, then again, the bitcoind/-qt wallet code has all kinds of scaling issues with a lot of transactions and this likely isn't the worst offender)
438 2013-12-19 09:22:57 <abishek> what is the configuration to run the bitcoid as a daemon?
439 2013-12-19 09:23:35 <wumpus> abishek: -daemon
440 2013-12-19 09:27:28 <abishek> if I am not enabled server configuration, should i still set the rpcusername and password?
441 2013-12-19 09:31:40 <wumpus> abishek: yes, you cannot run bitcoind without RPC configured
442 2013-12-19 09:31:49 <abishek> ok
443 2013-12-19 09:32:54 <wumpus> (I guess it would make sense in some cases to be able to run the daemon without RPC, pull requests welcome...)
444 2013-12-19 09:34:10 <abishek> anyreason why RPC credentials are requires even if the server conf is set to 0. From the docs, -server is the one that allows rpc communication with bitcoind right
445 2013-12-19 09:35:30 <wumpus> as I said, bitcoind forces server mode
446 2013-12-19 09:36:28 <wumpus> it would be pretty trivial to support -noserver (or -server=0) for bitcoind, so feel free to do that
447 2013-12-19 09:36:50 <t7> oh great now i can get GPG key stolen if someone can hear my cpu
448 2013-12-19 09:37:10 <t7> must only do my personal computing in a vacuum chamber
449 2013-12-19 09:37:19 <wumpus> shhh, silent, so I can hear your CPU :)
450 2013-12-19 09:37:52 <wumpus> t7 in a faraday cage
451 2013-12-19 09:38:50 <abishek> wumpus, what does server=0 mean?
452 2013-12-19 09:39:11 <wumpus> also you should do your typing in a vacuum chamber too, for keyboards are noisy things and from the sound/timing patterns a lot can be reconstructed
453 2013-12-19 09:40:40 <wumpus> abishek: it would mean "don't run a server" *if* bitcoind didn't force server mode ....
454 2013-12-19 09:41:12 <wumpus> (RPC server)
455 2013-12-19 09:42:13 <abishek> what does not work if server is set to 0?
456 2013-12-19 09:42:22 <wumpus> look, the code is here https://github.com/bitcoin/bitcoin/blob/master/src/init.cpp#L490
457 2013-12-19 09:42:47 <wumpus> ... I just said that
458 2013-12-19 09:43:13 <abishek> ok, i will have a look at it
459 2013-12-19 09:46:50 <ntio> why do we care about shamirs paper? I mean bitcoin doesn't use RSA, right?
460 2013-12-19 10:10:44 <sipa> gmaxwell: agree, the double meaning of public/private derivation are confusing
461 2013-12-19 10:10:55 <sipa> gmaxwell: suggestions for a nice adjective?
462 2013-12-19 10:15:18 <sipa> abishek: the -server option simply doesn't exist for bitcoind; it always runs in server mode
463 2013-12-19 10:15:37 <abishek> ok
464 2013-12-19 10:15:42 <sipa> abishek: it only applies to the GUI where having the RPC server is optional
465 2013-12-19 10:15:54 <sipa> as wumpus said, this could be changed
466 2013-12-19 11:42:55 <jaromil> t7: a fix for gpg1 is out, gpg2 is not affected. using an SSD also helps.
467 2013-12-19 11:43:18 <jaromil> i found the bug intriguing and interesting. reminds me of good old tempest times. very nice.
468 2013-12-19 11:43:46 <t7> wumpus: no one can steal my passwords from keyboard sounds, i use voice control
469 2013-12-19 11:44:45 <uiop> regarding WIF private keys, what is the meaning of the distinction between a WIF privkey associated with an uncompressed versus a compressed public key? can't the public key be derived from the private via d*G? (i suspect this distinction has to do with the checksum in the WIF key, but if so i don't get the point, why not just choose *one* pubkey repr?)
470 2013-12-19 11:45:05 <t7> voice recognition is so bad that robots will never steal my private key
471 2013-12-19 11:45:13 <wumpus> t7: hah! foiled them
472 2013-12-19 11:46:35 <lianj> uiop: i don't understand your question :)
473 2013-12-19 11:46:37 <lianj> what?
474 2013-12-19 11:47:52 <uiop> oh wait, (https://en.bitcoin.it/wiki/Private_key) seemed to suggest that was the case, but upon reading (https://en.bitcoin.it/wiki/Wallet_import_format) i see no mention of that
475 2013-12-19 11:48:55 <uiop> lianj: (from https://en.bitcoin.it/wiki/Private_key): "For private keys associated with uncompressed public keys, they are 51 characters and always start with the number 5. Private keys associated with compressed public keys are 52 characters and start with a capital L or K."
476 2013-12-19 11:49:13 <uiop> is what prompted that question
477 2013-12-19 11:49:28 <lianj> uiop: what case? wif can have a compressed flag in which case the derived public key must be compressed
478 2013-12-19 11:50:10 <lianj> ok it better to look at it base58 decoded :)
479 2013-12-19 11:51:31 <uiop> lianj: oh, hmm. but what/who is the consumer of the eventual public key, and why couldn't they just convert to compressed (resp. uncompressed) form? i.e. why is an encoding decision of a derived entity (which hasn't been derived yet) represented in the WIF privkey?
480 2013-12-19 11:52:04 <uiop> 
ACTION is surely missing something obvious

481 2013-12-19 11:53:24 <uiop> oh. i got it.
482 2013-12-19 11:54:28 <uiop> so the *address* computed from a public key will be different depending on if the pubkey is compressed or not, so the format of the privkey tells the importer what address to use
483 2013-12-19 11:54:32 <uiop> (or something)
484 2013-12-19 11:54:53 <lianj> right
485 2013-12-19 12:20:34 <sipa> uiop: exactly
486 2013-12-19 12:49:53 <abishek> could someone advice on what is a suitable way to display bitcoin currencies using PHP
487 2013-12-19 12:51:27 <abishek> if I have 0.04 and if I display using number_format(0.04,8), it displays as 0.039999999. How can i fix this
488 2013-12-19 12:53:39 <wumpus> abishek: does PHP have a 'decimal' class? do not use floating point numbers for monetary values
489 2013-12-19 12:54:28 <abishek> wumpus, not it doesn't I maintain my monetary columns on the DB as float(length,8)
490 2013-12-19 12:55:31 <abishek> wumpus, what is the ideal way to store bitcoin money in mysql?
491 2013-12-19 12:55:34 <sipa> do NOT use a float for monetary types
492 2013-12-19 12:55:38 <wumpus> in that case use int64's and use 8 digits fixed point ... whatever you do, don't use floating point
493 2013-12-19 12:55:54 <wumpus> AFAIK SQL does have a decimal type
494 2013-12-19 12:56:10 <sipa> yup
495 2013-12-19 12:56:41 <sipa> DECIMAL(16,8) is what you want for bitcoin amounts
496 2013-12-19 12:59:06 <abishek> wumpus, sipa, thnx for the help
497 2013-12-19 13:20:12 <abishek> does bitcoin use ICMP protocols or only TCP?
498 2013-12-19 13:25:02 <sipa> only TCP
499 2013-12-19 13:25:15 <sipa> well, it uses DNS lookup, which usually uses UDP
500 2013-12-19 13:47:52 <darsie> Why does the difficulty of finding a pattern with vanitygen depend on the pattern, pattern length being equal?
501 2013-12-19 13:53:07 <darsie> lower case characters after the leading one are rare ... Probably the length of the hash converted to base58check is smaller than the number of bits in strlen(address) base58check digits.
502 2013-12-19 13:53:25 <sipa> only the first character or so should matter
503 2013-12-19 14:03:31 <deanclkclk> hello
504 2013-12-19 14:03:55 <deanclkclk> so anyone use java/spring to communicate with bitcoind json-rpc?
505 2013-12-19 14:04:03 <deanclkclk> I'm using the restTemplate
506 2013-12-19 14:04:22 <darsie> that's a meta question.
507 2013-12-19 14:06:19 <deanclkclk> I know but, do I send the credentials on every request?
508 2013-12-19 14:06:37 <deanclkclk> meaning is bitcoind stateless
509 2013-12-19 14:06:48 <sipa> yes
510 2013-12-19 14:07:18 <ahmedbodi> hey guys
511 2013-12-19 14:07:35 <ahmedbodi> on stratum theres people that try to connect to the pool with http
512 2013-12-19 14:07:58 <ahmedbodi> is it possible to use an X-Stratum header like with getwork to send them to the correct port?
513 2013-12-19 14:09:59 <darsie> http isn't limited to a specific port. I guess you could redicect to host:1337. Not sure if that is applicable  in your case.
514 2013-12-19 14:10:50 <darsie> with a location http header.
515 2013-12-19 14:13:42 <ahmedbodi> darsie: thats what i want to find out about doing with stratum-mining :)
516 2013-12-19 14:26:36 <xeroc> where can I read about the redemption script in P2SH? what is made of? its a hash of a script as i understand it .. but what hash? what script syntax?
517 2013-12-19 14:28:39 <jgarzik> xeroc, https://en.bitcoin.it/wiki/Script
518 2013-12-19 14:31:26 <jgarzik> xeroc, it uses OP_HASH160 for the hash, which is ripemd160(sha256(data))
519 2013-12-19 14:34:21 <xeroc> an the script is much like the good-old multisig script (as an example)
520 2013-12-19 14:34:31 <xeroc> but all other standard scripts are allowed too .. i guess ..
521 2013-12-19 14:39:47 <owowo> http://i.imgur.com/IItQc33.png <<.. license plate, firstbits? ;o)
522 2013-12-19 14:40:16 <jgarzik> xeroc, any script is "allowed" in a block
523 2013-12-19 14:40:21 <jgarzik> xeroc, not all scripts will be relayed
524 2013-12-19 14:57:28 <xeroc> jgarzik: I see .. thx for clarification
525 2013-12-19 14:58:20 <xeroc> owowo: afaik 0,0,o are not valid in btc-addresse ..
526 2013-12-19 14:58:27 <xeroc> base56 coded ..
527 2013-12-19 15:00:58 <owowo> found an address with o just by clicking the top block on blockexplorer
528 2013-12-19 15:03:56 <owowo> but you seem to be right with 0