1 2012-02-27 00:03:06 <etotheipi_> I'm realizing that the MITM is too easy for this situation
  2 2012-02-27 00:03:30 <etotheipi_> I send a challenge to someone who claims they own an address.... they just send the challenge to the actual owner, get a response and forward it
  3 2012-02-27 00:03:54 <etotheipi_> obviously the actual owner shouldn't just sign everyone that comes across, but there should be a more secure way to do it
  4 2012-02-27 00:04:02 <luke-jr> etotheipi_: that's why the signature must cover the full statement with details
  5 2012-02-27 00:04:17 <luke-jr> and why the sign message dialog has a freaking huge textarea
  6 2012-02-27 00:07:18 <etotheipi_> I'm not sure how that avoids the MITM situation...
  7 2012-02-27 00:08:03 <sipa> etotheipi_: the point is that proof of ownership only proves someone owns the key
  8 2012-02-27 00:08:14 <luke-jr> MITM is irrelevant if the MITM can't change anything
  9 2012-02-27 00:08:23 <sipa> if the message also includes what this person would like the achieve by this, there is no problem
 10 2012-02-27 00:09:07 <sipa> etotheipi_: rather said, in your scenario, the signature would have to be kept secret, as possession of the signature implies ownership of the key (or at least consent from this person)
 11 2012-02-27 00:09:09 <etotheipi_> okay, so there really isn't a safe "default" in this situation... the user really needs to type something in
 12 2012-02-27 00:10:02 <sipa> in luke's scenario, it is not secret; the signature simply certifies that the owner of the key agrees with the message
 13 2012-02-27 00:12:18 <luke-jr> etotheipi_: or paste
 14 2012-02-27 00:20:37 <etotheipi_> so it's basically: "the owner of this address agrees with this statement"...
 15 2012-02-27 00:21:14 <etotheipi_> I'm trying to figure out, when someone says "I sent the 1000 BTC to you, please send the merchandise to the following address..."
 16 2012-02-27 00:21:45 <etotheipi_> oh, I see... I could make the challenge "I donated 1000 BTC for X and would like stuff delivered to this address: ..."
 17 2012-02-27 00:22:08 <luke-jr> "I paid 1000 BTC for X delivered to Y"
 18 2012-02-27 00:22:15 <luke-jr> it's not a donation if you're purchasing ;P
 19 2012-02-27 00:22:28 <etotheipi_> luke-jr, :)  I'm mixing up use cases here
 20 2012-02-27 00:22:53 <etotheipi_> but in this case, it doesn't require challenge-response... the person who paid 1000 BTC would just create that message themself
 21 2012-02-27 00:23:06 <sipa> What we should have is "I, proven creator of transaction X, would like X to be accepted as payment for my requested delivery of goods Y to Z."
 22 2012-02-27 00:24:26 <sipa> The problem is that "access to private keys corresponding to one source address of X" does is not equal to "creator of X"
 23 2012-02-27 00:25:28 <sipa> For example Mt.Gox may well have access to the source address keys of a transaction I make them do for something I buy.
 24 2012-02-27 00:26:21 <luke-jr> sipa: this is why the current signmessage spec is insufficient
 25 2012-02-27 00:26:29 <luke-jr> we need a txn verison
 26 2012-02-27 00:26:58 <luke-jr> the current signmessage is mainly good for *receiving*
 27 2012-02-27 02:27:31 <etotheipi_> sipa, luke-jr, for the message signing, is there some sort of ASCII-armored standard for creating signature blocks like PGP uses?
 28 2012-02-27 02:28:08 <etotheipi_> regardless of implementation details, the signatures will have to be sent/rx, and I'm trying to figure out a good way to do it...
 29 2012-02-27 02:28:39 <luke-jr> paste it into a textbox on webpage
 30 2012-02-27 02:29:00 <etotheipi_> not the sending part... the encoding part
 31 2012-02-27 02:29:22 <etotheipi_> like:  http://pastebin.com/1u5KxvDR
 32 2012-02-27 05:57:59 <clowninasack> hi, i was told someone may be able to help here. I am trying to make bitcoind jail-friendly and only bind to the jail's IP, but I see two addrLocalHost entries in debug.log, one for my local ip (specified via listenaddress in bitcon.conf) and one for 0.0.0.0
 33 2012-02-27 05:58:09 <clowninasack> i just want to bind to the local ip
 34 2012-02-27 05:58:40 <copumpkin> rumor has it slush + deepbit exceed 50%
 35 2012-02-27 05:59:27 <splatster> They do
 36 2012-02-27 05:59:47 <Diablo-D3> rumor? dude
 37 2012-02-27 05:59:49 <splatster> Pie Chart Time: http://blockchain.info/pools
 38 2012-02-27 05:59:56 <Diablo-D3> they both list their hash rates
 39 2012-02-27 05:59:57 <Diablo-D3> do the math
 40 2012-02-27 06:00:27 <splatster> They mined 51% of the recent blocks.
 41 2012-02-27 06:32:48 <graingert> woah deepbit is big
 42 2012-02-27 06:49:23 <gjs278> how much traffic can you send to memcached over a network because memcached will just not be able to keep up on a modern cpu
 43 2012-02-27 06:49:35 <gjs278> before memcached will crash that is
 44 2012-02-27 06:49:52 <Diablo-D3> hrm
 45 2012-02-27 06:49:58 <Diablo-D3> yeah, but why use memcached at all
 46 2012-02-27 06:50:01 <gjs278> see
 47 2012-02-27 06:50:04 <gjs278> that is because they are dumb
 48 2012-02-27 06:50:16 <gjs278> and right now the site is varnish/nginx proxying incompatible
 49 2012-02-27 06:50:18 <Diablo-D3> use infinispan and it's memcached emulation daemon
 50 2012-02-27 06:50:18 <gjs278> cookies everywhere
 51 2012-02-27 06:50:37 <Diablo-D3> infinispan == distributed parallel key/value store database
 52 2012-02-27 06:50:42 <Diablo-D3> written in java, extremely fast
 53 2012-02-27 06:51:01 <gjs278> hmm ok
 54 2012-02-27 06:51:05 <Diablo-D3> scalable past a hundred boxen
 55 2012-02-27 06:51:16 <Diablo-D3> they have a daemon for it that emulates the memcached protocol
 56 2012-02-27 06:51:34 <gjs278> that will probably work then
 57 2012-02-27 06:51:35 <Diablo-D3> so you'd just be connecting to memcached locally, and tell it to mirror the cache on all boxen
 58 2012-02-27 06:51:49 <Diablo-D3> they have a channel #infinispan
 59 2012-02-27 06:52:49 <Karmaon> if you want more features use redis
 60 2012-02-27 06:53:02 <Diablo-D3> yeah, screw redis
 61 2012-02-27 06:53:06 <Diablo-D3> redis is slow shit
 62 2012-02-27 06:53:14 <Karmaon> but but but the features!!111
 63 2012-02-27 06:53:19 <Diablo-D3> if you want more features, you use infinispan natively
 64 2012-02-27 06:53:22 <gjs278> I just want the site to not crash due to internal network traffic
 65 2012-02-27 06:54:47 <Karmaon> thats like asking how much traffic can i send to nginx or apache over a network before it'll crash
 66 2012-02-27 06:55:05 <gjs278> a lot more than memcached thankfully
 67 2012-02-27 06:55:29 <Diablo-D3> memcached actually sucks badly on multi-box situations
 68 2012-02-27 06:55:50 <Diablo-D3> since you end up with a lot of duplicated items calculated n times
 69 2012-02-27 06:55:58 <Diablo-D3> gjs278: btw, multi-level caching isnt uncommon
 70 2012-02-27 06:56:25 <Diablo-D3> varnish static items, dummy template layouts for content customization per user, and cache the template items
 71 2012-02-27 06:56:49 <Diablo-D3> although at that point its a lot easier to run the layout engine as client-side javascript
 72 2012-02-27 06:56:58 <gjs278> right now the "varnish static items" phrase of the site = pull the entire page stored from memcached and just display it. with the cookie hit to make the caching not work.
 73 2012-02-27 06:57:16 <Diablo-D3> I mean like static css, js, images, etc, for varnish
 74 2012-02-27 06:57:22 <gjs278> yeah of course
 75 2012-02-27 06:57:41 <Diablo-D3> (with etags forcibly shut off for those)
 76 2012-02-27 06:59:40 <gjs278> what do you use for translations
 77 2012-02-27 06:59:57 <Diablo-D3> what do you mean?
 78 2012-02-27 07:00:04 <gjs278> well the method we are using now is dumb
 79 2012-02-27 07:00:08 <Diablo-D3> as in content translated into different languages?
 80 2012-02-27 07:00:11 <gjs278> yes
 81 2012-02-27 07:00:21 <Diablo-D3> you do it normally
 82 2012-02-27 07:00:47 <Diablo-D3> it just means theres no content static to the page, ie, every element is dynamic, but each dynamic element can be statically cached at the layout level
 83 2012-02-27 07:00:50 <Diablo-D3> ie, memcached
 84 2012-02-27 07:01:38 <gjs278> right now there are 6 languages, about 10k phrases each language. the entire thing is stored in a memcached key to do the replacement. that's pretty much what is killing the memcached background
 85 2012-02-27 07:01:51 <Diablo-D3> yeah thats stupid
 86 2012-02-27 07:02:02 <Diablo-D3> it should be built into the template
 87 2012-02-27 08:53:45 <sje> anyone have any clues about how the code for 'verify message' might look, as opposed to 'sign message'?
 88 2012-02-27 08:54:38 <sje> i.e. how to convert a bitcoin address to a pub key (if necessary), and decode the signature?
 89 2012-02-27 09:02:19 <sje> nm
 90 2012-02-27 10:15:22 <sje> why strMessageMagic in signed message? won't that make it harder for other apps to verify messages?
 91 2012-02-27 10:54:22 <gribble> New news from bitcoinrss: dooglus opened pull request 905 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/905>
 92 2012-02-27 11:00:14 <gribble> New news from bitcoinrss: sje397 opened pull request 906 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/906>
 93 2012-02-27 11:10:08 <sipa> sje: you need some arbitrary marker string, otherwise the function could potentially be used to sign transactions
 94 2012-02-27 11:10:54 <sipa> sje: and it is already a custom format anyway, with key recovery
 95 2012-02-27 11:12:40 <sje> sipa: i don't follow....either of those points :) to recover the signed address, I had to add the magic string myself, to mirror the signing function
 96 2012-02-27 11:13:05 <sje> and what's wrong with signing transactions? could i cause trouble using that code?
 97 2012-02-27 11:13:43 <sje> *signing address
 98 2012-02-27 11:15:27 <sipa> sje: i do not want the responsability when someone is tricked into signing a transaction that robs all their money
 99 2012-02-27 11:16:09 <sipa> and to verify a signature: see verifymessage in bitcoinrpc.cpp
100 2012-02-27 11:17:17 <sje> sipa: aha understood
101 2012-02-27 11:17:19 <sipa> sje: and the 65-byte "compactsignature" was invented by me, so it is already specific to bitcoin
102 2012-02-27 11:17:37 <sje> i did the code for verify already - in that last pull request
103 2012-02-27 11:19:08 <sje> sipa: gotcha
104 2012-02-27 11:23:02 <sipa> ok, looks good at first sight; i'll test it later
105 2012-02-27 13:43:11 <Tykling> hello, how short can a BTC address be ? apparently some are shorter than others due to leading zeroes (I want to do some basic validation before accepting it on a website)
106 2012-02-27 13:44:20 <phantomcircuit> Tykling, iirc 32-35 chars
107 2012-02-27 13:44:37 <Eliel> Tykling: if you want to validate the address, you should decode the base58 coding and then verify the checksum at the end matches.
108 2012-02-27 13:44:48 <nanotube> phantomcircuit: i just looked up on the wiki, https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses, 25-34
109 2012-02-27 13:44:58 <nanotube> unless it's wrong... :)
110 2012-02-27 13:45:17 <nanotube> Eliel: or run 'bitcoind validateaddress' :)
111 2012-02-27 13:45:39 <Eliel> nanotube: yes, that works much better if you're running bitcoind on the system :)
112 2012-02-27 13:45:51 <Tykling> hmm, might be easier just to run bitcoind validateaddress - thanks guys!
113 2012-02-27 13:46:03 <gmaxwell> there is js code out there for validation
114 2012-02-27 13:46:07 <Eliel> but I'm pretty sure there's readymade functions for validateaddress out there for php and python at least.
115 2012-02-27 13:46:15 <phantomcircuit> nanotube, that is wrong
116 2012-02-27 13:46:17 <nanotube> yea i think there are a few out there
117 2012-02-27 13:46:51 <Tykling> this is PHP - suppose I might as well do basic validation in php before calling bitcoind
118 2012-02-27 13:46:52 <nanotube> phantomcircuit: well.... someone should correct it , then. :)
119 2012-02-27 13:46:56 <phantomcircuit> otoh i just set an upward bound and use a validator genjix wrote
120 2012-02-27 13:47:01 <phantomcircuit> so i guess i could be wrong
121 2012-02-27 13:47:08 <nanotube> mm
122 2012-02-27 13:47:35 <phantomcircuit> no that's impossible
123 2012-02-27 13:48:36 <phantomcircuit> you would need a 1:1 mapping from the version + hash + checksum to the base58 encoded version for it to be 25 bytes
124 2012-02-27 13:48:50 <phantomcircuit> which is literally impossible
125 2012-02-27 15:34:14 <iddo> gmaxwell: i bumped your thread on deterministic wallets, with simple info why composing PRG and signatures is safe
126 2012-02-27 15:35:04 <sipa> PRG?
127 2012-02-27 15:35:49 <iddo> pseudorandom generator, i meant that the keys are pseudorandom instead of independent
128 2012-02-27 15:36:50 <sipa> iddo: you may be interested in reading https://gist.github.com/1799467
129 2012-02-27 15:37:46 <iddo> cool, i'll look
130 2012-02-27 15:39:39 <iddo> anyway we were confused last time we discussed it here, or at least i was confused, it's easy to argue that pseudorandom keys are secure from related-key attacks
131 2012-02-27 15:44:45 <iddo> sipa: now i actually think that having default deterministic wallet for the official client is more healthy, it's true that in a technical sense it's a bit less secure because of added pseudorandomness assumption, but it should help a lot with backups of wallet.dat issues that non-tech-savvy users could have
132 2012-02-27 15:45:52 <sipa> iddo: i agree; i ??e already implemnted a determinstic-wallet patch for the satoshi client
133 2012-02-27 15:46:22 <helo> one-time backup creation is invaluable
134 2012-02-27 15:47:03 <sipa> But I'd rather have those hierarchical determinstic wallets implemented, as they allow much more than what is currently implemented.
135 2012-02-27 15:47:06 <helo> i.e. the amount of money that will be lost over time to backup mistakes is not bounded :)
136 2012-02-27 15:49:02 <iddo> sipa: one thing i wonder about now, what's a good way to decide how much entropy the random seed should have?
137 2012-02-27 15:50:31 <sipa> iddo: i doubt more than 256 bit is ever useful
138 2012-02-27 15:53:58 <iddo> "256 bits of entropy should be enough for everybody", a la Bill Gates' 640k is enough for anyone... :)
139 2012-02-27 15:54:22 <iddo> though i suppose you are right
140 2012-02-27 15:57:15 <iddo> but current wallet.dat files use a lot more entropy, maybe even 10,000+ random bits? so it might be hard to sell 256 bits
141 2012-02-27 15:57:40 <gmaxwell> anyone competent to worry about it will also be competent to know that it shouldn't be worried about.
142 2012-02-27 15:58:48 <iddo> it's still important to separate the seed from master sk (i mean not use master sk as the seed), so that public keys are independent of master sk
143 2012-02-27 15:59:24 <sipa> ?
144 2012-02-27 15:59:55 <gmaxwell> (though IIRC in sipa's scheme master could be any size... and up to 512 bits is not unreasonable)
145 2012-02-27 16:01:28 <iddo> sipa: i meant type-2 keys can be generated independently of master secret key, so the public keys don't reveal anything on master sk
146 2012-02-27 16:03:32 <iddo> what's the motivation for hierarchical deterministic wallet proposal? is there discussion of it somewhere?
147 2012-02-27 16:03:42 <gavinandresen> sipa:  what's the status of compressed public keys and old wallets?  I'd like to get a 0.6rc2 out in the next day or two, and I think that's the only issue that might hold it up.
148 2012-02-27 16:03:58 <gavinandresen> sipa: I mean compressed keys and using a new wallet on older releases....
149 2012-02-27 16:06:57 <kish> are keys generated using openssl's routines?
150 2012-02-27 16:07:25 <kish> and why in gods name was c++ chosen
151 2012-02-27 16:08:00 <phantomcircuit> kish, yes and ask satoshi... oh wait
152 2012-02-27 16:08:05 <gmaxwell> kish: To irritate you, personally. :)
153 2012-02-27 16:08:09 <kish> doesn't exist phantomcircuit
154 2012-02-27 16:08:13 <phantomcircuit> sure he does
155 2012-02-27 16:08:17 <sipa> gavinandresen: https://github.com/bitcoin/bitcoin/pull/864
156 2012-02-27 16:08:19 <phantomcircuit> just doesn't want to talk :)
157 2012-02-27 16:08:30 <kish> how do you know he exists
158 2012-02-27 16:08:52 <sipa> gavinandresen: already fixed, in other words
159 2012-02-27 16:08:54 <gavinandresen> sipa: great! thanks.
160 2012-02-27 16:09:44 <sipa> iddo: it arose from a discussion with gmaxwell; the idea is that it allows selective sharing of a wallet (entire wallet, one account, or only public addresses of one account), and for each part either with or without the ability to spend funds
161 2012-02-27 16:11:23 <phantomcircuit> gavinandresen, is there a person/persons who goes by the name of satoshi
162 2012-02-27 16:11:25 <phantomcircuit> y/n
163 2012-02-27 16:11:49 <iddo> sipa: ok, i'm just wondering if there are specific useful scenarios for this that i'm missing
164 2012-02-27 16:12:07 <sipa> iddo: there may be, I intend to write them in the BIP proposal :)
165 2012-02-27 16:12:22 <sipa> gmaxwell had some interesting use cases
166 2012-02-27 16:12:28 <gavinandresen> phantomcircuit: yes....   or, anyway, there was, I haven't heard form him/her/them in months
167 2012-02-27 16:12:39 <phantomcircuit> kish, ^ that
168 2012-02-27 16:13:37 <sipa> gavinandresen: I don't think there are any pressing issues for 0.6.0rc2 left; fixing the bitcoin-qt lockup under windows when using getmemorypool would have been nice, though
169 2012-02-27 16:15:12 <vegard> about 25 minutes into the talk http://www.youtube.com/watch?v=hlWyTqL1hFA they make some sort of strange claim that "block creation is not a poisson process"
170 2012-02-27 16:15:57 <gmaxwell> vegard: it isn't if you consider it over enormous windows that have difficulty changes in them.
171 2012-02-27 16:16:19 <gmaxwell> vegard: but if thats not what they mean, I suspect that they're on crack.
172 2012-02-27 16:16:37 <vegard> they said something along the lines of "mining pools go into some sort of resonance phenomenon" (~27:50)
173 2012-02-27 16:17:32 <gmaxwell> that sounds a bit handwavy. Perhaps poolhoppers are confusing them because they're looking at single pools rather than the whole network?
174 2012-02-27 16:17:58 <gribble> New news from bitcoinrss: sipa opened pull request 907 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/907>
175 2012-02-27 16:18:11 <vegard> as far as I understand they're actually saying: the creation (time) of two blocks are not independent
176 2012-02-27 16:18:42 <vegard> no, they are using data from the blockchain
177 2012-02-27 16:20:26 <sipa> Given that miners fiddle with block's creation timestamps, i suppose that would introduce some dependency.
178 2012-02-27 16:21:30 <vegard> I don't take them too seriously because their presentation is obviously not too good and they make a few other claims under dubious assumptions
179 2012-02-27 16:21:47 <vegard> I just wanted to hear if this was something that had been discussed in the community or among the developers
180 2012-02-27 16:22:13 <gmaxwell> "they are using data from the blockchain" hahaha
181 2012-02-27 16:22:23 <gmaxwell> well, you can throw their results out complete.
182 2012-02-27 16:22:56 <vegard> because of what sipa said?
183 2012-02-27 16:23:18 <phantomcircuit> lol
184 2012-02-27 16:23:24 <gmaxwell> vegard: yes.
185 2012-02-27 16:23:26 <phantomcircuit> that feeling right after you do something
186 2012-02-27 16:23:36 <phantomcircuit> and you know it's a bad idea immediately after
187 2012-02-27 16:23:55 <gmaxwell> vegard: and because miners clocks aren't in agreement.
188 2012-02-27 16:24:35 <jrmithdobbs> sipa: that os x issue fixed in rc2?
189 2012-02-27 16:24:46 <gmaxwell> vegard: shame on them if thats all they did did the great many blocks with negative relative times not clue them in on the fact that the timestamps are not especially accurate.
190 2012-02-27 16:24:52 <jrmithdobbs> haven't been paying attention, just asking since you were talking about remaining issues in rc2
191 2012-02-27 16:25:20 <vegard> gmaxwell: oh really? example of that (negative relative times)?
192 2012-02-27 16:25:28 <jrmithdobbs> vegard: they're all over the chain
193 2012-02-27 16:25:33 <jrmithdobbs> ALL over
194 2012-02-27 16:25:41 <gmaxwell> vegard: I posted a graph showing the observed timestamps differences vs the expectation, you can see in the rug at the bottom that there are a great many blocks with negative offsets. http://people.xiph.org/~greg/theory-vs-practice.png
195 2012-02-27 16:25:43 <sipa> gavinandresen: Did that OSX IPC problem get fixed? I know there was a fix implemented, but I don't see it in the commit log.
196 2012-02-27 16:25:59 <jrmithdobbs> missing that and then making any claims whatsoever pretty much discredits them completely
197 2012-02-27 16:26:35 <vegard> aha.
198 2012-02-27 16:26:55 <vegard> is it known how exactly the timestamps are (usually) modified?
199 2012-02-27 16:27:08 <jrmithdobbs> what do you mean how?
200 2012-02-27 16:27:18 <jrmithdobbs> it's known exactly how, whoever mined the block said that's what time it was
201 2012-02-27 16:27:32 <vegard> well, if they just set the lower bits of the timestamp bits to random values, you might see negative times
202 2012-02-27 16:27:47 <jrmithdobbs> and it was within the parameters to be considered valid so the rest of the network accepted the block
203 2012-02-27 16:28:01 <vegard> but pools might use the lower bits of the timestamp as a counter when the work is handed out
204 2012-02-27 16:28:08 <jrmithdobbs> vegard: the blocks have some basic constraints on how close to the last block they must be
205 2012-02-27 16:28:15 <gmaxwell> 'exactly'? No.  Clocks are wrong, they're not required to be especially accurate by the network. Miners also intentionally roll the clocks forward to reduce network traffic and computation to effectively expand the nonce space.
206 2012-02-27 16:28:21 <jrmithdobbs> vegard: roughly "within 120 minutes" doesn't matter if negative or positive
207 2012-02-27 16:28:34 <vegard> aha, so this effect is probably mostly due to unsynchronised clocks
208 2012-02-27 16:28:43 <jrmithdobbs> partially
209 2012-02-27 16:28:50 <jrmithdobbs> also because of what gmaxwell just said
210 2012-02-27 16:28:52 <gmaxwell> vegard: standalone RPC miners will even modify the times (forward) to create more search space. Search for ntime rolling.
211 2012-02-27 16:29:06 <jrmithdobbs> eligius is one example that twiddles the time for that reason (to prevent extra getworks)
212 2012-02-27 16:29:36 <vegard> I see
213 2012-02-27 16:30:00 <jrmithdobbs> vegard: basically it's another "someone that doesnt understand bitcoin says stupid shit about bitcoin" occurance
214 2012-02-27 16:30:03 <jrmithdobbs> heh
215 2012-02-27 16:30:11 <gmaxwell> Technically the time limit is greater than the median of the last 10 blocks, and less than or equal to two hours in the future from the perspective of the recieving node.
216 2012-02-27 16:30:51 <gmaxwell> Because recieving nodes are themselves unsynced it would be really unwise to generate blocks with times anywhere near that 2 hour cutoff. In practice an hour is probably safe enough.
217 2012-02-27 16:30:56 <vegard> even so... these modifications should be somewhat random in nature, right? so it shouldn't actually affect the distribution that much
218 2012-02-27 16:31:20 <gmaxwell> vegard: er, no,  all the rolling modifications tend to be forward in time.
219 2012-02-27 16:31:33 <gmaxwell> The clamps are also further out in the future direction.
220 2012-02-27 16:31:39 <vegard> right
221 2012-02-27 16:32:41 <gmaxwell> There is also no reason to assume that clock errors are symmetrically distributed, though I have no idea what their distribution looks like. But even if they are, the miners are not uniformly sized so e.g. if one big miner has a clock that is +1 minute, thats going to create a shift in the distribution.
222 2012-02-27 16:33:10 <vegard> yes.
223 2012-02-27 16:33:22 <vegard> and obviously if deepbit has 30% of the blocks...
224 2012-02-27 16:33:28 <gmaxwell> Right.
225 2012-02-27 16:34:07 <cande> is it possible to get the tx hash from bitcoin-qt ??
226 2012-02-27 16:35:12 <jrmithdobbs> gmaxwell: actually, you have a pretty good indicator about how it's distributed
227 2012-02-27 16:35:27 <jrmithdobbs> gmaxwell: if you watch the offset modifications in the log it could be derived, anyways ;p
228 2012-02-27 16:35:54 <gmaxwell> jrmithdobbs: I think it's reasonable to expect that users and miners are drawn from very different distributions.
229 2012-02-27 16:36:12 <luke-jr> db1a560 (origin-pull/862/head, matt/warnings) Fix compilation warning.
230 2012-02-27 16:36:17 <luke-jr> anyone know what this fixes? -.-
231 2012-02-27 16:36:26 <jrmithdobbs> gmaxwell: I'm not sure it's necessarily an important distinction as it relates to consistent clocks
232 2012-02-27 16:37:17 <vegard> oh... they did all their analysis on data from blockexplorer.com LOL poor site
233 2012-02-27 16:37:47 <gmaxwell> vegard: no wonder blockexplorer has been randomly unusable. :(
234 2012-02-27 16:38:02 <gmaxwell> lame, it's easy to extract this stuff from a local client.
235 2012-02-27 16:38:34 <gmaxwell> jrmithdobbs: e.g. jrandom user is likely to be on an undermaintained residentally localted windows box with no NTP, set by eye, and no drift compentation. .. vs a mining pool which is probably running NTP which is doing drift compenstation, in a datacenter with stable temp, etc.
236 2012-02-27 16:38:47 <jrmithdobbs> just from the brief discussion here and your comments on their method inclines me to not bother listening to that talk / reading that paper, ha
237 2012-02-27 16:43:05 <gribble> New news from bitcoinrss: luke-jr opened issue 908 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/908>
238 2012-02-27 17:22:49 <DeLorean731> When I try to start up the Bitcoin client on my Windows 7x64 box, once the splash screen gets to "Loading Block Index..." I get the error message: Microsoft Visual C++ Runtime Library: This application has requested the Runtime to terminate in an unusual way.
239 2012-02-27 17:22:54 <DeLorean731> is my wallet corrupt?
240 2012-02-27 17:36:56 <captain^k> DeLorean731: maybe not the wallet, it _is_ loading the block index after all - what version of bitcoin are you running?
241 2012-02-27 17:37:33 <DeLorean731> 0.5.2
242 2012-02-27 17:37:43 <DeLorean731> the readme says it's 0.5.2 beta
243 2012-02-27 17:37:49 <DeLorean731> I don't know if all 0.5.2 is beta or not d:
244 2012-02-27 17:37:58 <DeLorean731> not familiar with the numbering scheme
245 2012-02-27 17:40:06 <luke-jr> BlueMatt: ping
246 2012-02-27 17:40:23 <luke-jr> BlueMatt: What did this fix? db1a560 (origin-pull/862/head, matt/warnings) Fix compilation warning.
247 2012-02-27 17:43:06 <BlueMatt> a compilation warning that we redefine _WIN32_WINNT
248 2012-02-27 17:43:17 <BlueMatt> (because its already defined in some mingw header)
249 2012-02-27 17:44:26 <captain^k> DeLorean731: delete %appdata%lk*.dat and try loading again
250 2012-02-27 17:46:51 <luke-jr> BlueMatt: & but it only adds a #define :/
251 2012-02-27 18:03:13 <luke-jr> is it just me, or is bitcoind's txn fee no longer saved in git master?
252 2012-02-27 18:09:49 <sipa> saved?
253 2012-02-27 18:10:36 <luke-jr> sipa: it used to be in the wallet, so close/start would keep the same txnfee
254 2012-02-27 18:10:42 <luke-jr> now it seems to be nowhere?
255 2012-02-27 18:12:42 <sipa> luke-jr: it should be in ~/.config/Bitcoin/Bitcoin-qt.conf now
256 2012-02-27 18:13:30 <luke-jr> sipa: for bitcoind?
257 2012-02-27 18:13:50 <sipa> ~/.bitcoin/bitcoin.conf
258 2012-02-27 18:14:07 <luke-jr> what code adds it there?
259 2012-02-27 18:14:12 <sipa> none
260 2012-02-27 18:14:47 <luke-jr> &
261 2012-02-27 18:15:15 <luke-jr> so it's no longer saved&?
262 2012-02-27 18:15:34 <sipa> not in bitcoind, no
263 2012-02-27 18:19:41 <sipa> gavinandresen: reminder to put that clearly in the release notes ^
264 2012-02-27 18:36:27 <Tykling> can someone help me find out where I am failing with this ? http://pastebin.com/9upfbzT5
265 2012-02-27 18:37:16 <Tykling> I am trying to write some php code to validate the checksum at the end of the base58 decoded address but I can't seem to get back to the same checksum as the input :)
266 2012-02-27 18:40:54 <sipa> Tykling: pasting your code would help
267 2012-02-27 18:42:43 <Tykling> sipa: of course - I just assumed that someone would be able to calculate the hashes and point me at which one is wrone
268 2012-02-27 18:42:56 <Tykling> one sec and I'll pastebin the functions
269 2012-02-27 18:43:17 <ThomasV> paste! paste! paste! paste! paste! paste! paste!
270 2012-02-27 18:43:26 <Tykling> http://pastebin.com/S35D6Tyu
271 2012-02-27 18:44:38 <sipa> Tykling: the input checksum should be 8 hex characters
272 2012-02-27 18:44:47 <sipa> not 6
273 2012-02-27 18:44:55 <Tykling> oh shit really
274 2012-02-27 18:44:56 <Tykling> lol
275 2012-02-27 18:47:08 <Tykling> okay
276 2012-02-27 18:47:38 <Tykling> I changed it to 8 bytes, it still doesn't validate though
277 2012-02-27 18:48:38 <Tykling> http://gobittest.appspot.com/Address I tried inputting the address part of the base58 decoded BTC address here, in number 4 on that site
278 2012-02-27 18:50:57 <Tykling> and my sha256 hashes are different than those
279 2012-02-27 18:51:27 <sipa> just to be sure: you're not sending the data encoded in hex to sha256?
280 2012-02-27 18:51:29 <vegard> gsoc now accepting mentoring org applications
281 2012-02-27 18:51:36 <vegard> was there a plan for bitcoin to apply?
282 2012-02-27 18:53:34 <Tykling> sipa: yes I am
283 2012-02-27 18:54:13 <sipa> That explains; the hex encoding is only for visualizing the internal data structures to humans; you should send it to sha256 in binary
284 2012-02-27 18:54:33 <Tykling> I see
285 2012-02-27 18:54:51 <Tykling> I'll try that, you've been very helpful, thanks :)
286 2012-02-27 18:59:50 <Tykling> sipa: works! thanks again
287 2012-02-27 20:31:52 <luke-jr> new next-test done
288 2012-02-27 20:36:31 <luke-jr> O.o
289 2012-02-27 20:36:59 <luke-jr> it might be possible to enable merged mining on Bitcoin gradually
290 2012-02-27 20:37:43 <luke-jr> so long as 50% of miners don't enable support until ~all the clients are upgraded, for example&
291 2012-02-27 20:53:44 <sipa> What would need to be modified to Bitcoin to make that work?
292 2012-02-27 20:57:39 <luke-jr> sipa: block acceptance terms
293 2012-02-27 20:57:59 <sipa> ?
294 2012-02-27 20:58:04 <luke-jr> sipa: basically, enabling merged mining with Bitcoin as an "aux" chain
295 2012-02-27 20:58:28 <luke-jr> except replacing the coinbase txn with just the aux root
296 2012-02-27 20:59:21 <sipa> You want to allow bitcoin to be merge-mined into some other chain?
297 2012-02-27 20:59:35 <sipa> So the other way of how it's currently done?
298 2012-02-27 20:59:55 <luke-jr> except there is no other chain
299 2012-02-27 20:59:59 <luke-jr> just a proof-of-work
300 2012-02-27 21:00:34 <luke-jr> eg, as we discusssed for Bitcoin 2.0
301 2012-02-27 21:00:45 <luke-jr> except it might not actually require a sudden hardfork
302 2012-02-27 21:01:35 <sipa> I don't think you can do it without a hardfork; you'd need to take the proof-of-work of the "higher" chain into account when calculating a chain's work.
303 2012-02-27 21:01:56 <sipa> Wait, that doesn't *really* need a hardfork, indeed.
304 2012-02-27 21:03:17 <luke-jr> eventually old clients will stop working, but we can have a nice 2 year transition period
305 2012-02-27 21:03:59 <sipa> On the other hand, I don't see a practical use for it as long as bitcoin is the most worked-on chain.
306 2012-02-27 21:04:28 <sipa> For Bitcoin 2.0, it would be nice to have a separation between the proof-of-work-master-chain, and the financial chain.
307 2012-02-27 21:09:08 <luke-jr> sipa: merged mining pollutes aux chains right now
308 2012-02-27 21:09:23 <luke-jr> the entire Bitcoin coinbase has to be in them
309 2012-02-27 21:11:52 <sipa> Why?
310 2012-02-27 21:12:32 <sipa> (I never looked into the details of MM, but I would expect that they'd just need a merkle path to the hash in the bitcoin chain?)
311 2012-02-27 21:12:42 <sipa> s/chain/coinbase/
312 2012-02-27 21:15:09 <doublec> that would require alt chains to always have the bitcoin chain available wouldn't it?
313 2012-02-27 21:15:19 <jrmithdobbs> yes
314 2012-02-27 21:15:23 <jrmithdobbs> that's why it's like that iirc
315 2012-02-27 21:15:26 <doublec> right
316 2012-02-27 21:19:14 <luke-jr> sipa: the merkle path is against the coinbase txnid. the txnid is based on the entire txn
317 2012-02-27 21:24:13 <sipa> Hmm, i see.
318 2012-02-27 21:26:30 <luke-jr> sipa: also, splitting the proof-of-work off allows possibly expanding the nonce area
319 2012-02-27 21:27:15 <luke-jr> though it does require, as gmaxwell pointed out, changing the block header time to an offset from the POW-time rather than absolute value
320 2012-02-27 22:15:54 <sipa> getblockhash seems broken in git master?
321 2012-02-27 22:16:02 <forrestv> luke-jr, i came up with a solution to auxchain pollution that's in use in p2pool right now - you put the auxchain merkle root near the end of the coinbase txn, and then collapse most of the coinbase txn into a sha256 midstate
322 2012-02-27 22:16:40 <sipa> Never mind, used an old bitcoind as client it seems.
323 2012-02-27 22:16:50 <luke-jr> forrestv: can't, outputs are last
324 2012-02-27 22:17:10 <forrestv> luke-jr, yes, that's why p2pool creates its fake output :p
325 2012-02-27 22:17:35 <luke-jr> i c
326 2012-02-27 22:17:46 <luke-jr> won't work for NMC tho
327 2012-02-27 22:17:56 <forrestv> right, obviously incompatible with existing implementations
328 2012-02-27 22:55:15 <gribble> New news from bitcoinrss: sipa reopened issue 901 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/901>
329 2012-02-27 23:06:12 <sipa> Can someone test #902 ?