1 2012-05-07 00:00:05 <gavinandresen> luke-jr: what?
   2 2012-05-07 00:00:19 graingert is now known as tards
   3 2012-05-07 00:00:24 tards is now known as graingert
   4 2012-05-07 00:00:24 sausage2 has joined
   5 2012-05-07 00:00:29 Zarutian has quit (Quit: Zarutian)
   6 2012-05-07 00:00:37 <luke-jr> gavinandresen: any ruling on 82e6b92 and/or bd1aabe? :p
   7 2012-05-07 00:00:49 MobiusL has joined
   8 2012-05-07 00:01:10 <sausage2> So. How is the dev going?
   9 2012-05-07 00:01:31 Zarutian has joined
  10 2012-05-07 00:01:37 RainbowDashh has quit (Quit: RainbowDashh)
  11 2012-05-07 00:04:26 * luke-jr puts kids to bed while he waits for someone to decide which to put in 0.6.2
  12 2012-05-07 00:07:08 <sipa> i'm quite sure the asserts are harmless (i didn't trigger any while reproducing the addrman crash, and i believe all code paths have been tested now
  13 2012-05-07 00:07:17 <sausage2> gmaxwell: hi, how's it going? nice wather today, huh?
  14 2012-05-07 00:07:36 <sipa> on the other hand, addrman failures are not that critical
  15 2012-05-07 00:07:43 <sausage2> So, the dev is going pretty well, isnt it? :)
  16 2012-05-07 00:07:45 da2ce7 has joined
  17 2012-05-07 00:08:31 <sausage2> Isnt it so gmaxwell? You're a BTC-dev too, I've heard. An eminent one.
  18 2012-05-07 00:08:37 <sipa> the other bug fix was just not storing a value to base bucket decisions on
  19 2012-05-07 00:08:55 <sipa> i don't see how it could influence much
  20 2012-05-07 00:09:15 <sausage2> so, how do I use JSON for btc?
  21 2012-05-07 00:09:15 <sipa> but that's certainly not critical
  22 2012-05-07 00:09:18 <sausage2> the rpc service?
  23 2012-05-07 00:09:41 <gmaxwell> sausage2: https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29
  24 2012-05-07 00:10:00 <sausage2> is it so gmaxwell? Can I do it in linux?
  25 2012-05-07 00:10:45 <sausage2> Thanks gmaxwell, you are a very kind person :)
  26 2012-05-07 00:11:00 <sipa> ?
  27 2012-05-07 00:11:00 <luke-jr> so just 56f1e91(addrman crash fix) and 6860133(stuck download fix) then?
  28 2012-05-07 00:11:13 <gmaxwell> (he was spamming me in PM with scatological nonsense)
  29 2012-05-07 00:11:24 <sipa> luke-jr: fine by me
  30 2012-05-07 00:12:17 <gavinandresen> luke-jr: I'll create a 0.6.2 branch on github, version numbers in READMEs/etc need to be bumped, too
  31 2012-05-07 00:12:44 <luke-jr> gavinandresen: I already made a branch…
  32 2012-05-07 00:12:57 <gavinandresen> okey doke
  33 2012-05-07 00:13:19 Zarutian has quit (Quit: Zarutian)
  34 2012-05-07 00:14:41 mmoya has quit (Ping timeout: 260 seconds)
  35 2012-05-07 00:14:46 <gavinandresen> https://github.com/bitcoin/bitcoin/tree/0.6.2
  36 2012-05-07 00:15:25 <luke-jr> …
  37 2012-05-07 00:15:48 <gavinandresen> So: how about we all compile/run that branch overnight, and assuming no issues by tomorrow night I'll tag and we'll gitian-build it as 0.6.2?
  38 2012-05-07 00:16:39 <luke-jr> gavinandresen: so you're including the non-critical bugfix and risky assertions?
  39 2012-05-07 00:16:42 <gmaxwell> We also need to test new nodes with this branch, and groups of nodes connected to each other with this branch (to check for inv loops)
  40 2012-05-07 00:16:58 <gmaxwell> luke-jr: The assertions are not pure risk. There is risk either way.
  41 2012-05-07 00:17:12 <luke-jr> gmaxwell: there is no *additional* risk to leaving them out
  42 2012-05-07 00:18:05 <sipa> i wouldn't mind leaving them out
  43 2012-05-07 00:18:26 <gmaxwell> I don't care about 'additional' risk, I care about the total resulting safty and stability. At least the risk from assertions is just DOS and not data corruption of security compromises.  I think the risk from them is adequately addressed by testing in any case.
  44 2012-05-07 00:19:36 <gavinandresen> I want to fail early, so assertions stay in
  45 2012-05-07 00:20:19 <gmaxwell> with how slowly people tend to deploy it's not that scarry.
  46 2012-05-07 00:22:01 <luke-jr> sounds like we're good to go until tomorrow then
  47 2012-05-07 00:22:10 devrandom has quit (Ping timeout: 276 seconds)
  48 2012-05-07 00:22:45 RainbowDashh has joined
  49 2012-05-07 00:24:55 paul0 has joined
  50 2012-05-07 00:25:14 <gmaxwell> luke-jr: actually we could use gitian builds of that branch, so we can nag more people to run them.
  51 2012-05-07 00:25:49 Guest27760 is now known as splatster
  52 2012-05-07 00:25:49 splatster has quit (Changing host)
  53 2012-05-07 00:25:49 splatster has joined
  54 2012-05-07 00:25:50 <luke-jr> am I the only one with working gitian now? :P
  55 2012-05-07 00:25:57 <sipa> mine works
  56 2012-05-07 00:26:14 <BlueMatt> give me like 2 days
  57 2012-05-07 00:26:30 <riush> why is there no address displayed for mined/coinbase tx?
  58 2012-05-07 00:27:13 <luke-jr> riush: known bug. want to fix it?
  59 2012-05-07 00:27:16 <freewil> because i think that part of the code was made with the assumption that a coinbase wouldnt be sent
  60 2012-05-07 00:27:25 <luke-jr> bbiab (hopefully with gitina builds)
  61 2012-05-07 00:27:33 <freewil> ... and you would be generating it for yourself
  62 2012-05-07 00:27:50 <sipa> gavinandresen: no annotated tag for 0.6.2?
  63 2012-05-07 00:28:05 <sipa> (git describe says v0.6.1-5-gf367e5d)
  64 2012-05-07 00:28:50 <sipa> apology for offtopicness, but i find this hilarious: http://www.youtube.com/watch?v=w1gusAIRN8M
  65 2012-05-07 00:29:15 <BlueMatt> thats very offtopic...
  66 2012-05-07 00:29:19 devrandom has joined
  67 2012-05-07 00:29:55 <gavinandresen> sipa: I don't want to tag it until it gets a little testing
  68 2012-05-07 00:30:20 <sipa> ok
  69 2012-05-07 00:32:33 <sipa> i'll tag it myself as 0.6.2rc1, ok?
  70 2012-05-07 00:32:47 <sipa> (just locally, to get it in the version info)
  71 2012-05-07 00:32:57 <luke-jr> sipa: your build won't match mine if you do
  72 2012-05-07 00:33:03 <sipa> ah, right
  73 2012-05-07 00:33:08 <graingert> gavinandresen: do you think "bitcoin.org" could be a commercial sponsor for a University Group Design Project?  Every student on a four year course has to participate in a GDP.  Which will either be a standard issue exercise or a problem submitted by a commercial sponsor.  A commercial sponsor suggests a problem, eg "bitcoin multicast":  something that they want doing that should take 5 people 2/3 of a semester to do.
  74 2012-05-07 00:33:17 <graingert> "(01:30:27) gavinandresen: try gmaxwell or sipa, maybe they have cool project ideas...."
  75 2012-05-07 00:33:51 <luke-jr> O.o
  76 2012-05-07 00:33:52 rdponticelli_ has quit (Ping timeout: 276 seconds)
  77 2012-05-07 00:34:09 <luke-jr> graingert: bitcoin.org is tcatm or sirius anyway
  78 2012-05-07 00:34:15 <theorbtwo> Bitcoin multicast actually sounds like an interesting idea.
  79 2012-05-07 00:34:20 <graingert> gavinandresen: okay if I pastbin the entire chat log from 01:24:25
  80 2012-05-07 00:34:27 <theorbtwo> Too bad multicast doesn't actually work on the general internet.
  81 2012-05-07 00:34:35 <graingert> theorbtwo: it works over JANET
  82 2012-05-07 00:34:43 <graingert> ie all of UK
  83 2012-05-07 00:34:58 <luke-jr> theorbtwo: yet to be seen on IPv6
  84 2012-05-07 00:35:05 <theorbtwo> graingert: .ac.uk.
  85 2012-05-07 00:35:13 <gavinandresen> graingert: sure, I don't mind if everybody sees me being a curmudgeon....
  86 2012-05-07 00:35:16 <graingert> sorry yes
  87 2012-05-07 00:35:17 <theorbtwo> luke-jr: By my definitions, ipv6 isn't the general internet.
  88 2012-05-07 00:35:25 <graingert> http://pastie.org/3871060
  89 2012-05-07 00:35:32 <luke-jr> theorbtwo: you must be living in 1990
  90 2012-05-07 00:35:46 <graingert> ipv6 is as general internet as you can get
  91 2012-05-07 00:35:55 <graingert> you've got google
  92 2012-05-07 00:35:57 <graingert> and facebook
  93 2012-05-07 00:36:00 <graingert> what more do you want
  94 2012-05-07 00:36:05 <theorbtwo> What I mean is that you can't expect J. Random user, connected to a commercial DSL modem, to have working multicast.
  95 2012-05-07 00:36:19 <graingert> theorbtwo: no but it's not too far off
  96 2012-05-07 00:37:02 <theorbtwo> graingert: widespread ipv6 is one of those things that's always a couple of years off.
  97 2012-05-07 00:37:08 <Dagger2> graingert: I want Youtube and Yahoo too!
  98 2012-05-07 00:37:08 bitinstant has joined
  99 2012-05-07 00:37:16 <graingert> back on topic?
 100 2012-05-07 00:37:22 <theorbtwo> Back on topic.
 101 2012-05-07 00:37:32 <graingert> cool ideas for GDP, gmaxwell sipa bitinstant
 102 2012-05-07 00:37:58 <graingert> mtgox is currently deliberating
 103 2012-05-07 00:38:21 <theorbtwo> graingert: Considering sponsoring a gdp, you mean?
 104 2012-05-07 00:38:28 <graingert> yes
 105 2012-05-07 00:38:46 <theorbtwo> Interesting.
 106 2012-05-07 00:38:49 <sipa> what does sponsoring imply?
 107 2012-05-07 00:39:48 <graingert> sipa: you're telepresence is required at a few meetings: requirements and demo presentation
 108 2012-05-07 00:39:52 <graingert> your*
 109 2012-05-07 00:40:29 <theorbtwo> I do wonder if you / one could work out a way to make quick bitcoin for POS applications, which would need to transparently interoperate with normal bitcoin.
 110 2012-05-07 00:41:02 <graingert> theorbtwo: that's been done
 111 2012-05-07 00:41:15 <graingert> or do you mean a SPV?
 112 2012-05-07 00:41:46 <theorbtwo> Reading more.
 113 2012-05-07 00:41:56 <theorbtwo> I've not been following things closely, apparenytly.
 114 2012-05-07 00:42:00 RainbowDashh has quit (Quit: RainbowDashh)
 115 2012-05-07 00:42:15 <graingert> "Do an SPV: Go!" would be an interesting project request
 116 2012-05-07 00:42:28 RainbowDashh has joined
 117 2012-05-07 00:42:57 <sipa> Do a barrel roll!
 118 2012-05-07 00:42:59 <XMPPwocky> solar powered vehicle?
 119 2012-05-07 00:43:08 <graingert> !google SPV bitcoin
 120 2012-05-07 00:43:09 <TiggrBot> [SPV bitcoin] http://webcache.googleusercontent.com/search?q=cache:9VZRyUeW_N4J:https://en.bitcoin.it/wiki/Thin_Client_Security+SPV+bitcoinhl=ct=clnk (Cached)
 121 2012-05-07 00:43:09 <gribble> Thin Client Security - Bitcoin: <https://en.bitcoin.it/wiki/Thin_Client_Security>; Alternative Chains - Bitcoin: <https://en.bitcoin.it/wiki/Alternative_Chains>; Scalability - Bitcoin: <https://en.bitcoin.it/wiki/Scalability>
 122 2012-05-07 00:43:20 <sipa> graingert: you start by using bitcoinj, then ...
 123 2012-05-07 00:43:30 <BlueMatt> 1. use bitcoinj
 124 2012-05-07 00:43:32 <BlueMatt> 2. ???
 125 2012-05-07 00:43:34 <BlueMatt> 3. profit
 126 2012-05-07 00:43:43 <graingert> 4. finney attack
 127 2012-05-07 00:43:45 <graingert> 5. cry
 128 2012-05-07 00:43:54 <sipa> graingert: ipv6 multicast would actually be very interesting, imho
 129 2012-05-07 00:44:02 <graingert> truefax
 130 2012-05-07 00:44:20 <graingert> and I think implementing it as a fake client would probably be the easiest
 131 2012-05-07 00:44:29 <graingert> for a prototype
 132 2012-05-07 00:44:45 <graingert> eg you add 127.0.0.1:port as a peer
 133 2012-05-07 00:45:02 <graingert> and that peer pretends to be a bitcoin node interested in tx and giving you tx
 134 2012-05-07 00:45:19 <sipa> so, a gateway
 135 2012-05-07 00:45:21 <graingert> when in actual fact it's communicating with everyone else on JANET
 136 2012-05-07 00:45:29 <graingert> yes
 137 2012-05-07 00:45:31 <sipa> that's probably the easiest way to implement it
 138 2012-05-07 00:45:34 <graingert> yes
 139 2012-05-07 00:46:00 <graingert> super
 140 2012-05-07 00:46:07 <graingert> I have a supervisor who <3 multicast
 141 2012-05-07 00:46:40 rdponticelli has joined
 142 2012-05-07 00:47:12 <graingert> and <3 ipv6
 143 2012-05-07 00:48:05 <sipa> i'll see if i can come up with some other ideas
 144 2012-05-07 00:51:19 <da2ce7> I would love to have a feature where you enter a ipv6 address and a public key hash... and your client contacts the remote bitcoin client and that remote client retunrs a signed new public key to send the coins to.
 145 2012-05-07 00:51:32 <da2ce7> *signed by their main public key.
 146 2012-05-07 00:51:54 <da2ce7> kinda like the orignal send-to-ip... but secure.
 147 2012-05-07 00:52:04 devrandom has quit (Ping timeout: 276 seconds)
 148 2012-05-07 00:52:06 <sipa> why does it need to be ipv6?
 149 2012-05-07 00:52:12 <luke-jr> da2ce7: a script hash would be better
 150 2012-05-07 00:52:16 <luke-jr> sipa: because IPv4 is dead
 151 2012-05-07 00:52:27 <luke-jr> da2ce7: so N-of-M can be used if desired
 152 2012-05-07 00:52:36 <sipa> it should just return a script
 153 2012-05-07 00:52:41 <sipa> not an address or a hash
 154 2012-05-07 00:52:57 <luke-jr> sure
 155 2012-05-07 00:53:04 <luke-jr> I mean to authenticate the connection
 156 2012-05-07 00:53:13 <da2ce7> well it depends how we design it... however I think that scritps should be stored in a DHT.
 157 2012-05-07 00:53:22 <da2ce7> *stored.
 158 2012-05-07 00:53:22 * luke-jr runs
 159 2012-05-07 00:53:26 <sipa> ooh, a DHT!!!
 160 2012-05-07 00:53:42 <gmaxwell> graingert: I have a whole speculative features list page— though I'm probably due to update it.... a few things on it are done or very near done, and of course I've had more thoughts since then.
 161 2012-05-07 00:53:53 * gmaxwell gets out the stabbing machine
 162 2012-05-07 00:54:30 <gmaxwell> da2ce7: you do realize that you've just trigged the bayesian idiot detector here, right? or was that the point.
 163 2012-05-07 00:54:50 <graingert> stabbing machine?
 164 2012-05-07 00:55:08 <sipa> luke-jr: also, however much i'd like your statement about ipv4 to be true, i think you should stop dreaming
 165 2012-05-07 00:55:35 <graingert> sipa: much the same way one can still slide use a dead horse as a sledge
 166 2012-05-07 00:55:37 <gmaxwell> luke-jr: I really wish it were dead, instead carriers are deploying massive nat boxes (or gearing up to do so where they haven't yet)
 167 2012-05-07 00:55:40 <graingert> ipv4 is dead
 168 2012-05-07 00:55:47 <gmaxwell> graingert: https://en.bitcoin.it/wiki/User:Gmaxwell/features
 169 2012-05-07 00:55:48 <da2ce7> well won't there be private scripts, that are only known on spend, and scripts that are public from the start?
 170 2012-05-07 00:55:59 <sipa> da2ce7: read BIP16
 171 2012-05-07 00:56:21 <sipa> even if ipv6 starts to take off now (which i assume it will), most services on the internet will remain on IPv4 for years to come, just to remain accessible to both
 172 2012-05-07 00:56:36 * da2ce7 re-reads.
 173 2012-05-07 00:57:26 <graingert> IPv6 at all would be nice :p
 174 2012-05-07 00:57:35 <sipa> graingert: done
 175 2012-05-07 00:57:41 <graingert> oh really
 176 2012-05-07 00:57:51 <graingert> gmaxwell: you need to keep that up to date
 177 2012-05-07 00:58:03 <sipa> graingert: https://github.com/bitcoin/bitcoin/pull/1021
 178 2012-05-07 00:58:06 <BlueMatt> pulling bitcoin: uris into a full secure payment system with support for multisig on multiple devices passing info back and forth and all would be cool
 179 2012-05-07 00:58:58 <gavinandresen> I still prefer a mime-type / file download to bitcoin: URIs...
 180 2012-05-07 00:59:00 <gmaxwell> graingert: I just went and updated it a bit.
 181 2012-05-07 00:59:10 * sipa points to https://gist.github.com/1237788
 182 2012-05-07 01:00:15 <sipa> combinding it with BIP10 would be cool
 183 2012-05-07 01:00:20 <sipa> *combing
 184 2012-05-07 01:00:24 <sipa> **combining
 185 2012-05-07 01:00:28 <graingert> why not just use https
 186 2012-05-07 01:00:33 <graingert> or webid
 187 2012-05-07 01:00:50 <BlueMatt> gavinandresen: except uris are handled more gracefully in many cases...
 188 2012-05-07 01:01:15 <sipa> it can well be a URI that is required to point to a file with a particular mime-type
 189 2012-05-07 01:01:25 <gmaxwell> graingert: look at all the bitcoin sites with invalid HTTPS certs, or the fact that 100% of them are downgrading attack vulnerable... I couldn't even talk any of them into using HSTS.
 190 2012-05-07 01:01:46 <graingert> you'd demand https at the protocol
 191 2012-05-07 01:01:49 <graingert> ie like webid
 192 2012-05-07 01:01:50 devrandom has joined
 193 2012-05-07 01:02:04 <da2ce7> ok... I stil feel stupid... you need the serialized script to spend a output. if you loose the script the the output is unspendable. So it is as-important to know the scripts as the private keys, but they don't need to remain private.  Why is it such as awful idea to store them in DHT?
 194 2012-05-07 01:02:12 <graingert> eg to pay to a domain
 195 2012-05-07 01:02:22 <BlueMatt> sipa: that just makes it overcompliced, its ugly to add a ton of crap to a uri, but doable...
 196 2012-05-07 01:02:34 <graingert> type the domain in the box, it looks up https://domain/.well-know/bitcoin
 197 2012-05-07 01:02:39 <graingert> type the domain in the box, it looks up https://domain/.well-known/bitcoin
 198 2012-05-07 01:02:53 <graingert> that file contains a json file with a new address each time it's called
 199 2012-05-07 01:03:06 <BlueMatt> anyone have the link to gavinandresen's gist where we were discussing payment systems a while back?
 200 2012-05-07 01:03:09 <gmaxwell> da2ce7: because if you know the private key then you know the script.  There is also no such thing as an usably attack resistant DHT, which is why DHT is usually an idiot filter trigger in the context of bitcoin.
 201 2012-05-07 01:03:39 <gavinandresen> BlueMatt: I probably do :)
 202 2012-05-07 01:03:47 <da2ce7> why don't reqire every script-has of the DHT to be already included in the block-chain?
 203 2012-05-07 01:03:58 <da2ce7> *hash
 204 2012-05-07 01:04:18 <graingert> I think https urls is the way to go for payments
 205 2012-05-07 01:04:31 <graingert> ie if I want to add money to my mtgox account
 206 2012-05-07 01:04:49 <graingert> I would enter https://mtgox.com/user/graingert in my client
 207 2012-05-07 01:04:55 <sipa> graingert: if you trust the SSL PKI
 208 2012-05-07 01:05:05 <gavinandresen> BlueMatt:  this one?  https://gist.github.com/2217885
 209 2012-05-07 01:05:09 <sipa> (not that i mean to say you shouldn't, but certainly not everyone will)
 210 2012-05-07 01:05:09 <BlueMatt> graingert: avoiding trusting _anyone_ would be nice
 211 2012-05-07 01:05:13 <gmaxwell> The SSL PKI is demonstrably untrustworthy.
 212 2012-05-07 01:05:18 <BlueMatt> gavinandresen: thats the one!
 213 2012-05-07 01:05:31 <graingert> BlueMatt: that would be nice but you'd need to trust mtgox.com if you were sending to them
 214 2012-05-07 01:05:39 <BlueMatt> well, yea
 215 2012-05-07 01:05:45 <BlueMatt> but minimal trust is the goal
 216 2012-05-07 01:05:51 <graingert> you can't do it any other way
 217 2012-05-07 01:06:00 <graingert> if I was a shop I'd have to deliver my bitcoin address to you
 218 2012-05-07 01:06:07 <graingert> and the best way at the moment is ssl in a page
 219 2012-05-07 01:06:13 <gmaxwell> da2ce7: great you just encouraged blockchain spamming in order to 'register' addresses, address reuse which hurts anonymity in order to leverage existing registration, ... and for no real purpose because you didn't need to store anything more to begin with.
 220 2012-05-07 01:06:39 <graingert> okay so the cool challenges are
 221 2012-05-07 01:06:49 <graingert> nicer secure payment system
 222 2012-05-07 01:06:55 <graingert> and IPv5 multicast
 223 2012-05-07 01:07:02 <graingert> durp
 224 2012-05-07 01:07:04 <graingert> 6*
 225 2012-05-07 01:07:18 <sipa> da2ce7: if you own an address, it means you generated the script associated with it (to be able to give out the hash) using the private keys you have
 226 2012-05-07 01:07:36 <gmaxwell> (and to whatever extent you did, even if you remove the DOS vulnerability by requring the chain— you didn't really save yourself much because the distributed storage isn't guarenteed, so you still have to save it yourself)
 227 2012-05-07 01:07:48 <sipa> da2ce7: assuming your client does that in a minially-controlled way, it can easily recreate the scripts
 228 2012-05-07 01:07:52 <sipa> given the keys
 229 2012-05-07 01:08:14 <da2ce7> sipa: but if we have  2-of-3 script, how can I recreate that determeistaly?
 230 2012-05-07 01:08:47 <graingert> anyone want to write that up/be a sponsor? sipa?
 231 2012-05-07 01:09:16 <gmaxwell> graingert: I don't think multicast is espeically interesting.
 232 2012-05-07 01:09:16 <sipa> da2ce7: anyone of the 3 owners of that address have an interest in keeping the script around, as much as they have an interest in keeping their private keys around
 233 2012-05-07 01:09:24 <graingert> gmaxwell: :(
 234 2012-05-07 01:09:51 <gmaxwell> (I mean, it's generally interesting, but not for bitcoin— the reason is that the inv process makes bitcoin very transmission efficient)
 235 2012-05-07 01:10:22 <graingert> that's true
 236 2012-05-07 01:11:11 <sipa> gavinandresen: just realized, my build script doesn't call gsign unless it is a build with a version tag :s
 237 2012-05-07 01:11:30 <gmaxwell> da2ce7: You should just consider the script to be part of the private key.  In bitcoin we call the scripts scriptpubkey and such for that reason.
 238 2012-05-07 01:11:50 amandapanda has joined
 239 2012-05-07 01:11:51 <gmaxwell> da2ce7: the crazy proposal on bitcoin talk which actually removes ECDSA entirely from bitcoin (MAVE) is pretty enlightening in that regard.
 240 2012-05-07 01:11:59 <amandapanda> hey
 241 2012-05-07 01:15:28 chrisb__ has quit (Remote host closed the connection)
 242 2012-05-07 01:15:54 <sipa> gmaxwell: in theory, you could replace the inv/tx/block system by just a block/tx transmit on multicast
 243 2012-05-07 01:16:02 <graingert> gmaxwell: ?
 244 2012-05-07 01:16:04 <sipa> but it's probably way too easy to exploit
 245 2012-05-07 01:16:06 <graingert> gmaxwell: how?
 246 2012-05-07 01:16:22 <graingert> amandapanda: hey
 247 2012-05-07 01:17:15 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1214 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1214>
 248 2012-05-07 01:17:30 <gmaxwell> graingert: the same way namecoin prevents claim jumping.
 249 2012-05-07 01:18:00 <graingert> have you got a link to that?
 250 2012-05-07 01:18:36 <gmaxwell> graingert: https://bitcointalk.org/index.php?topic=76073.20  (a lot of the rest of his paper is meh... he has a high spew to research ratio)
 251 2012-05-07 01:18:54 <gmaxwell> oops page one of that thread, of course.
 252 2012-05-07 01:21:22 <graingert> got an abstract on the "clever bit"
 253 2012-05-07 01:25:54 <gmaxwell> At any moment, each address has a secret matched with it. The H(secret) is stored in the chain.  When that address whants to send it first announces H(secret+H(txn)+H(new secret)) + txn, and once that is good and burried it announces secret,H(new secret).
 254 2012-05-07 01:26:27 <graingert> oh
 255 2012-05-07 01:26:30 <graingert> that's clever
 256 2012-05-07 01:26:35 <gmaxwell> The advantage of this system is that it's very very fast. The disadvantage is that a >50% attacker can steal everyone's money for as far back as he can cut the chain.
 257 2012-05-07 01:27:05 <graingert> but not an advantage in bitcoin
 258 2012-05-07 01:27:12 <graingert> as that's not the bottleneck
 259 2012-05-07 01:27:14 <graingert> afaik
 260 2012-05-07 01:27:16 <graingert> it's disk
 261 2012-05-07 01:27:25 <gmaxwell> it's also resistant to attacker by quantum computers (except in so far as a QC enabled attacker can mount a >50% attack), but without a lot of space bloat that you'd get from a real QC resistant signature function.
 262 2012-05-07 01:28:18 <gmaxwell> Oh I agree.. or rather, if you allow the txn volume to go high enough that signauture validation is a bottleneck, then you throughly have lost decenteralization due to storage requirements. but it's still a cute idea if not useful.
 263 2012-05-07 01:29:30 amandapanda is now known as pandasamanda
 264 2012-05-07 01:29:41 paulo__ has joined
 265 2012-05-07 01:29:44 paulo__ has quit (Client Quit)
 266 2012-05-07 01:29:57 <gmaxwell> The whole secret management part also discourages using fresh addresses for everything.. breaks privacy.
 267 2012-05-07 01:32:00 <graingert> so what's the txn then
 268 2012-05-07 01:32:14 <graingert> how is that generated from secret_b
 269 2012-05-07 01:32:17 paulo__ has joined
 270 2012-05-07 01:32:28 paulo_ has quit (Disconnected by services)
 271 2012-05-07 01:32:40 paulo__ is now known as paulo_
 272 2012-05-07 01:34:02 <graingert> gmaxwell: ^
 273 2012-05-07 01:35:54 <gmaxwell> graingert: the txn is just like a regular bitcoin transaction. Basically the idea is that you commit to preimages in the blockchain, and then reveal the secrets to prove that your transactions are yours.  (I think his actual protocol had one more step than my toy example, in order to close a DOS attack, but thats the basic idea)
 274 2012-05-07 01:36:17 <graingert> but how do you send money to secrets?
 275 2012-05-07 01:36:45 gavinandresen has quit (Quit: gavinandresen)
 276 2012-05-07 01:36:52 <gmaxwell> You send to an address. which already has a preregistered secret in the chain. You don't give anyone your address until you've successfully registered it.
 277 2012-05-07 01:37:04 <graingert> oh I see
 278 2012-05-07 01:37:19 <graingert> and you can only get that by mining it yourself
 279 2012-05-07 01:38:35 <gmaxwell> You dont have to mine it yourself— no one has any incentive to claim jump your address because you won't use it unless you see that you're successful in getting it in.  I think he proposed some external POW system (e.g. not mining) to rate limiting the production of new addresses.
 280 2012-05-07 01:38:48 <graingert> oh
 281 2012-05-07 01:38:51 <graingert> that makes sense
 282 2012-05-07 01:40:49 <luke-jr> gmaxwell: my carrier is IPv6 only with NAT64
 283 2012-05-07 01:41:03 <gmaxwell> luke-jr: Are you using a cellphone in japan?
 284 2012-05-07 01:41:08 <luke-jr> gmaxwell: USA cellphone
 285 2012-05-07 01:41:18 <luke-jr> T-Mobile
 286 2012-05-07 01:41:30 <gmaxwell> Ah, I knew that AT&T was going to do that on the LTE stuff, didn't know that anyone else had done it yet.
 287 2012-05-07 01:41:36 <luke-jr> the only USA carrier compliant with international 3G frequencies
 288 2012-05-07 01:42:34 <gmaxwell> the cell providers are a bit crazy— most are giving each phone three IPs on their LTE networks.
 289 2012-05-07 01:42:50 <gmaxwell> (one for internet, one for voice, one for management)
 290 2012-05-07 01:42:56 <luke-jr> 03b23aea05a107448512a5fbf791529021b950b901fc10ef0712a36fde03da10  build/out/bitcoin-0.6.2-win32-setup.exe
 291 2012-05-07 01:43:10 <luke-jr> hmm. was I supposed to save the actual file for that? <.<
 292 2012-05-07 01:43:14 <gmaxwell> hahah
 293 2012-05-07 01:43:39 * gmaxwell blows away his gitian vm and tries installing newer ubuntu on it
 294 2012-05-07 01:43:43 <luke-jr> XD
 295 2012-05-07 01:43:54 <luke-jr> I didn't actually delete it, but I did shutdown
 296 2012-05-07 01:44:05 <luke-jr> in hopes of minimizing my nested-KVM-panic risk
 297 2012-05-07 01:45:56 <luke-jr> http://luke.dashjr.org/programs/bitcoin/files/bitcoind/0.6.2/test/rc1/
 298 2012-05-07 01:46:20 <luke-jr> (uploading in progress)
 299 2012-05-07 01:47:20 t7 has quit (Remote host closed the connection)
 300 2012-05-07 01:53:49 da2ce7 has quit (Ping timeout: 276 seconds)
 301 2012-05-07 01:55:50 RainbowDashh has quit (Read error: Connection reset by peer)
 302 2012-05-07 01:57:31 <amiller> so gmaxwell, if you have any attention available for this proof-of-work discussion
 303 2012-05-07 01:57:58 <amiller> i'm not really sure where the essence of our disagreement is
 304 2012-05-07 01:58:41 <amiller> it's better for bitcoin the more people that can independently validate transactions and blocks
 305 2012-05-07 01:59:05 <amiller> since you get reimbursed for investing in mining hardware, lots of people will have whatever is required to mine
 306 2012-05-07 01:59:32 <amiller> so if the proof-of-work requires a transaction validation machine, then lots of people will be able to validate transactions
 307 2012-05-07 02:01:52 <gmaxwell> If ~regular users without investements in special mining hardware can not fully validate transactions then bitcoin has lost its value— because it won't be very decenteralized anymore.
 308 2012-05-07 02:02:14 <amiller> regular users (without a coin database) can still verify transactions if they're handed O(log N) proofs
 309 2012-05-07 02:02:40 <gmaxwell> This risk is currently eliminated in bitcoin by the maximum txn rate created indirectly by the block size limits.
 310 2012-05-07 02:03:24 <gmaxwell> Given that we have no risk of regular users being simply unable to validate— there is little point in making miners prove they have validation superpowers far beyond regular users.
 311 2012-05-07 02:03:55 <amiller> there are two cases.  a) miners will validate blocks using O(1) communications, O(log N) time, and they are maintaining O(N) state         b) users will validate blocks using O(log N) communication, O(log N) time, and they only need O(1) state
 312 2012-05-07 02:05:18 <gmaxwell> If many users are not fully upholding the network rules then bitcoin loses its decenteralization. It sounds like you're making the mistake of thinking only miners fully enforce the rules?
 313 2012-05-07 02:06:13 <amiller> by regular users, you do mean users with O(1) state, a block hash maybe but no unspent-inputs tables?
 314 2012-05-07 02:06:26 <amiller> if so, regular users right now _are not_ able to indepently validate
 315 2012-05-07 02:06:43 <gmaxwell> No. I just mean full nodes who are not mining, which is the overwhelming supermajority of nodes now.
 316 2012-05-07 02:07:42 <gmaxwell> The power race to increase mining capacity is fundimentally anti-decentralization because it favors capital investment in specialized hardware. This sucks, but at least in bitcoin as it is today it only influnces control over the total order of transactions— all the rest of the nodes (save a small number of mobile ones) still validate the whole of the system rules.
 317 2012-05-07 02:08:17 <gmaxwell> And the maximum block sizes ensure that it will always be in the reach of fairly modest hardware to do so.
 318 2012-05-07 02:10:26 m00p has quit (Read error: Operation timed out)
 319 2012-05-07 02:10:49 <amiller> full nodes in my scheme will continue to be able to verify work, but with O(k * log N) effort per block, is your point that that is too much of an increased burden?
 320 2012-05-07 02:11:52 sgornick has quit (Quit: Ex-Chat)
 321 2012-05-07 02:12:01 <amiller> just to clarify, i think you have two criticisms in flight here, first that this harms validation by non-miners somehow, and second that it's not much of an improvement
 322 2012-05-07 02:12:21 <gmaxwell> It's no so much the increased burden— it's that it doesn't have a matching reward.  You could have them do O(1*log N) work to prove they're not cheating on storage... and that has basically all the real value but very little cost.
 323 2012-05-07 02:13:05 <gmaxwell> increasing K over 1 doesn't really prove much of anything, since once they have the storage the lookup costs are small given that we want modest nodes without extensive hardware investments to continue to do full validation.
 324 2012-05-07 02:13:14 <amiller> oh, let me explain K
 325 2012-05-07 02:13:22 <amiller> if you don't have K, then it's easy to cheat at the proof-of-work
 326 2012-05-07 02:13:28 <gmaxwell> (maybe I've mistook your nomenclature)
 327 2012-05-07 02:13:38 <gmaxwell> I think if you have to cooperate with a non-cheater then thats not much of a cheat.
 328 2012-05-07 02:13:51 <gmaxwell> (because you could use the same cooperation to do the validation)
 329 2012-05-07 02:14:21 <amiller> this K idea is due to a recent paper by rivest
 330 2012-05-07 02:14:30 <amiller> http://www.rsa.com/rsalabs/staff/bios/kbowers/publications/RAFT.pdf
 331 2012-05-07 02:14:40 <amiller> it's not cheating that's the threat here, it's "cheap and lazy"
 332 2012-05-07 02:14:54 <amiller> every pooled miner knows it's easy to cooperate by letting the pool operator validate your tx for you
 333 2012-05-07 02:15:13 RainbowDashh has joined
 334 2012-05-07 02:15:14 <gmaxwell> woah hey.
 335 2012-05-07 02:15:21 <gmaxwell> okay you just changed my opinion
 336 2012-05-07 02:15:49 <gmaxwell> Your system is incompatible with pooling for validation (perfectly compatible with pooling for payment).
 337 2012-05-07 02:16:07 <amiller> this system is also incompatible with merged mining
 338 2012-05-07 02:16:46 <gmaxwell> I don't think thats desirable. (merged mining changes the failure modes of bitcoin in a positive way) but I expect that could be fixed.
 339 2012-05-07 02:17:28 <gmaxwell> okay, I can see the benefit of what you're describing for the purpose of discouraging pooling for validation.
 340 2012-05-07 02:18:01 <gmaxwell> Though one issue is that ecdsa computation is a non-trivial part of the validation cost and you're ignoring it by just being IO centric. Perhaps thats sufficient though.
 341 2012-05-07 02:19:31 devrandom has quit (Remote host closed the connection)
 342 2012-05-07 02:20:07 devrandom has joined
 343 2012-05-07 02:20:12 <gmaxwell> amiller: for your reference, it was mentioning "pool operator validate your tx for you"  — my mindset was more around attackers who mine without validating (e.g. don't include transactions) because they're lazy. I hadn't thought of pools as a way of coperating to cheat on validation because thats not why pool users do that today.
 344 2012-05-07 02:20:36 graingert has quit (Read error: Connection reset by peer)
 345 2012-05-07 02:20:48 <gmaxwell> (they cooperate for pooled payments— which is a harmless thing, the delegation of  validation is an unfortunate accident of history mostly)
 346 2012-05-07 02:21:13 <amiller> you're that right i'm being io centric for now, i believe it would be possible to tweak the proof-of-work to include some proportional measure of signature validation
 347 2012-05-07 02:21:42 <gmaxwell> it's perfectly possible to do pooling without delgating validation— p2pool, bitpenny, and eligius memorypool mode all do it.. but they all came too late for wide adoption and they are all somewhat more 'costly' than the systems they replace.
 348 2012-05-07 02:21:44 <amiller> like you have to compute some number of group multiplies in between queries to your unspent inputs database
 349 2012-05-07 02:22:12 <gmaxwell> amiller: just make your hash function used to compine them be group multiplies.
 350 2012-05-07 02:22:26 <amiller> sure
 351 2012-05-07 02:22:44 <amiller> so the full nodes will always be more costly
 352 2012-05-07 02:22:50 <gmaxwell> s/compine/combine/
 353 2012-05-07 02:22:51 <amiller> you don't get reimbursed proportionally for maintaining it
 354 2012-05-07 02:23:09 <amiller> maintaining that database is unpaid-overtime
 355 2012-05-07 02:23:25 <amiller> also notice that it's still burning cycles
 356 2012-05-07 02:23:26 <gmaxwell> amiller: yes but it doesn't matter if the cost is not substantial— you get paid in the form of increased security.
 357 2012-05-07 02:26:41 <gmaxwell> amiller: I still think you should take more advantage of the non-public side effects of validating the prior blocks in the chain. Yes, you could cooperate with other nodes.. but at least that work is ~free.
 358 2012-05-07 02:28:24 kish_ has joined
 359 2012-05-07 02:28:52 <amiller> the proof-of-work necessarily involves burning cycles, but it also encourages investment in a particular kind of apparatus
 360 2012-05-07 02:29:05 <amiller> so you might as well design it so that the necessary apparatus does whatever is most important to the network
 361 2012-05-07 02:29:31 <amiller> there isn't anything more essential than transaction validation, so the natural thing is to align the proof-of-work with what's required to validate, as closely as possible
 362 2012-05-07 02:30:04 <amiller> anything else is wasted slack, i think you agree with that general idea now at least
 363 2012-05-07 02:30:05 <luke-jr> I would argue there is.
 364 2012-05-07 02:30:27 <luke-jr> more essential than transaction validation, is keeping permanent resource requirements to a minimum
 365 2012-05-07 02:30:35 <luke-jr> SHA256 proof-of-work does that well
 366 2012-05-07 02:30:42 <luke-jr> there are zero additional resources required
 367 2012-05-07 02:31:05 <amiller> what do you mean by 'permanent'
 368 2012-05-07 02:31:28 paulo_ has quit (Ping timeout: 260 seconds)
 369 2012-05-07 02:31:31 kish has quit (Ping timeout: 276 seconds)
 370 2012-05-07 02:32:10 <gmaxwell> amil19:26 < amiller> the proof-of-work necessarily involves burning cycles, but it also encourages investment in a particular kind of apparatus
 371 2012-05-07 02:32:17 <gmaxwell> ^ that was the argument I found uncompelling.
 372 2012-05-07 02:32:24 <amiller> ah
 373 2012-05-07 02:33:17 kish_ has quit (Ping timeout: 256 seconds)
 374 2012-05-07 02:33:18 <gmaxwell> Because if you need more than X units of validation apparatus then the system is a failure.  Encouraging people to invest in more than X units of it does us no good. (except in so far as it changes the market prices of that apparatus)
 375 2012-05-07 02:33:22 kish has joined
 376 2012-05-07 02:33:53 <gmaxwell> I mean, it's still a POW ... but I think it loses its aligment value once it goes beyond what you need for basic full falication.
 377 2012-05-07 02:33:57 <gmaxwell> er validation.
 378 2012-05-07 02:34:03 kish has quit (Read error: Connection reset by peer)
 379 2012-05-07 02:34:16 <luke-jr> amiller: the blockchain
 380 2012-05-07 02:34:28 <gmaxwell> I think the real value of what you're suggesting is that it making mining bandwidth heavy in a way that discourages pooled validation.
 381 2012-05-07 02:35:08 <gmaxwell> And that the change from one pow type to another is basically no better than what scrypt did.. it shuffles around the winners and losers but doesn't really improve the system.
 382 2012-05-07 02:35:50 <gmaxwell> amiller: Do you understand now where my objection was coming from?
 383 2012-05-07 02:36:50 <amiller> heh, no i don't think i do yet
 384 2012-05-07 02:36:52 <gmaxwell> That if X units of IO are required to fully validate the chain, the mining work with >X IO is just 'wasted' and might as well be some other task.  And that X must be small if we're to have many full nodes anyways.
 385 2012-05-07 02:37:19 <luke-jr> gmaxwell: I think I understand amiller's argument, though.
 386 2012-05-07 02:37:29 <luke-jr> gmaxwell: X is variable.
 387 2012-05-07 02:37:41 <luke-jr> so even if >X IO is wasted now, it might be needed as we grow
 388 2012-05-07 02:37:50 <luke-jr> and will be readily available this way
 389 2012-05-07 02:37:58 paulo_ has joined
 390 2012-05-07 02:38:15 <gmaxwell> Requiring miners to have X capacity is a grand thing.  Requring them to have X*1000 is no better than X+Y*1000 where Y is sha256 or whatever equally $$ costly thing.
 391 2012-05-07 02:38:25 kish has joined
 392 2012-05-07 02:38:32 <amiller> gmaxwell, in this rivest paper
 393 2012-05-07 02:38:34 <gmaxwell> luke-jr: you can fully validate the maximum rate of bitcoin on a fast desktop.
 394 2012-05-07 02:38:42 <amiller> they measure throughput as a way of measuring redundancy
 395 2012-05-07 02:39:03 <amiller> the goal is to have higher redundancy more than it is to have higher throughput
 396 2012-05-07 02:39:04 <gmaxwell> amiller: yes, I get the anti-pooled-validation advantage and I accept the value in that.
 397 2012-05-07 02:39:44 <luke-jr> gmaxwell: but that maximum rate needs to be lifted at some point
 398 2012-05-07 02:40:44 <amiller> okay i see your objection now
 399 2012-05-07 02:40:50 <amiller> so when i say it encourages investment in validation apparatus
 400 2012-05-07 02:40:53 <gmaxwell> luke-jr: I don't necessarily agree. Or rather— its my position that if its lifted the limit _must_ be such that the maximum rate can be reached with currently modest hardware, or bitcoin becomes controled exclusively by governments and central banks... becuase few could afford to watch the miners.
 401 2012-05-07 02:41:22 <amiller> i intend that to mean that it encourages more people to have this minimum apparatus, not that it should encourage greater capital investment in 1000*X individual apparatuses
 402 2012-05-07 02:41:29 m00p has joined
 403 2012-05-07 02:41:44 <amiller> there doesn't seem to be a way to one without the other without something complicated involving identity
 404 2012-05-07 02:41:48 <luke-jr> gmaxwell: I consider that an acceptable improvement over the current monopolistic money.
 405 2012-05-07 02:41:49 <gmaxwell> luke-jr: Bitcoin will never be a replacement for visa, at least not a good one. The fact that you'd have to exchange your gold (bitcoin) for cash (ripple?) to make many small transactions isn't a problem in my mind... So I'm comfortable with the max txn rate being capped.
 406 2012-05-07 02:42:25 <gmaxwell> luke-jr: even ignoring the loss of full nodes, if it's not capped the lack of txn fees will make the system insecure once the subsidy is gone.
 407 2012-05-07 02:43:05 <gmaxwell> amiller: I don't know that the problem is actually having the minimum apparatus.
 408 2012-05-07 02:43:33 <gmaxwell> amiller: I think if the first pooled system was p2pool or bitpenny then thats ~all we'd have today except perhaps for some botnet operators.
 409 2012-05-07 02:43:35 <amiller> gmaxwell, let me go over one more part of this again. there are two kinds of validation going on here, a) miners require O(N) state, do O(1) communication with each other, and validate with O(log N) time    b) people who aren't miners require O(1) state, and can independently validate with O(log N) effort and communication
 410 2012-05-07 02:43:48 <amiller> so my argument is on two fronts
 411 2012-05-07 02:43:50 <gmaxwell> amiller: No. stop. wrong assumptions.
 412 2012-05-07 02:43:53 <amiller> for ah k
 413 2012-05-07 02:44:07 <gmaxwell> Bitcoin is worthless in the model you just proposed— because its subject to fully centeralized control.
 414 2012-05-07 02:44:42 <gmaxwell> You're falling back into this mental model where only miners impose the rules of the system. Thats a possible outcome but it would make the system a complete failure at its goals.
 415 2012-05-07 02:45:10 <amiller> no no you misunderstood what i just wrote, my system enables both a) and b) to occur, b) is the one you're talking about where non-miners participate in validation, and my suggestion is a huge improvement in that area
 416 2012-05-07 02:45:25 TheSeven has joined
 417 2012-05-07 02:45:31 [7] has quit (Disconnected by services)
 418 2012-05-07 02:46:23 <amiller> there is currently no equivalent for b), people without O(N) state are unable to independently verify anything
 419 2012-05-07 02:46:37 <gmaxwell> amiller: well, if you're talking about the tree of unspent transactions part— yes I'm familar with that, considering that I believe I was the first person to propose it.
 420 2012-05-07 02:48:04 <gmaxwell> I just think of that seperately from the POW changes.
 421 2012-05-07 02:48:11 <gmaxwell> Is there a reason I shouldn't be?
 422 2012-05-07 02:49:34 <amiller> well consider that there is a role for proof-publishers to service all of these independent validators
 423 2012-05-07 02:50:07 <amiller> that's more specifically what the PoW subsidizes investment in
 424 2012-05-07 02:55:13 <gmaxwell> Hm!
 425 2012-05-07 02:55:20 <gmaxwell> There is an elegance in that.
 426 2012-05-07 02:55:36 <amiller> if you read one of these authenticated datastructures papers, they're all 3 party protocols, a Source a Server and a Client
 427 2012-05-07 02:55:48 <amiller> it's interesting in bitcoin because the miners are effectively the Source and they sign things with their work
 428 2012-05-07 02:56:00 <gmaxwell> One interesting thing to do would be to make the POW be exactly N proof publications hashed up togeather.
 429 2012-05-07 02:56:42 devrandom has quit (Remote host closed the connection)
 430 2012-05-07 02:57:03 <amiller> by N you mean all the unspent transactions now?
 431 2012-05-07 02:57:35 <amiller> in my scheme the proof of work is exactly K proof publications, K*log N in total
 432 2012-05-07 02:57:38 devrandom has joined
 433 2012-05-07 02:58:24 <gmaxwell> Okay, you win.
 434 2012-05-07 02:58:32 <amiller> okay! while i've got you here
 435 2012-05-07 02:58:35 <amiller> let me add one more layer to this
 436 2012-05-07 02:58:35 <gmaxwell> This is a fantastic idea.
 437 2012-05-07 02:58:42 <amiller> it's not enough to mine on just the unspent transactions
 438 2012-05-07 02:58:46 <amiller> you also need a backlog
 439 2012-05-07 02:58:52 <amiller> in order to be able to validate new proposed forks
 440 2012-05-07 02:59:07 ThomasV has joined
 441 2012-05-07 02:59:18 <amiller> you can either have just the current unspent coins database, some sliding window that goes back some M blocks
 442 2012-05-07 02:59:22 <amiller> or all the history forever
 443 2012-05-07 03:00:38 <amiller> storage cost is N + M * log N   for a window of M transactions
 444 2012-05-07 03:00:41 <gmaxwell> I had assumed that new nodes that were semi-full validators would just listen for a while before becoming fully active. (basically acting as non-validating SPV nodes until they've heard enough history to be confident they weren't being tricked)
 445 2012-05-07 03:03:23 Clipse has quit (Ping timeout: 240 seconds)
 446 2012-05-07 03:04:51 <amiller> it's reasonable to set the sliding window to just past wherever you would feel safe checkpointing spv clients
 447 2012-05-07 03:08:00 <gmaxwell> yea, ... just to prove that they themselvs were properly bootstrapped. Though is it required? If they mine without proper boostrapping they'll end up orphaned unless the majority was also not correctly bootstrapped.
 448 2012-05-07 03:10:24 <amiller> well using the term 'proof-publishing' since that seemed to go over well, it's worth incentivizing proof-publishers that would be capable of telling you that a longer legitimate fork has shown up
 449 2012-05-07 03:10:39 <gmaxwell> Fair enough.
 450 2012-05-07 03:11:02 <gmaxwell> or even— so that they'd have enough history to bootstrap you to that point yourself.
 451 2012-05-07 03:13:48 <gmaxwell> amiller: While we're on the subject of crazy ideas— have you run into any papers describing compressed lamport signatures? e.g. ones where the public key is sizeof(H()) average signature size is less than sizeof(H())^2*2 ?  I have a scheme for this and I can't believe that no one else has described it previously.
 452 2012-05-07 03:14:51 <amiller> https://plus.google.com/100836058911699642153/posts/gV3CAiTbeQ5 zooko and davidsarah posted on there for a while
 453 2012-05-07 03:14:58 sytse has quit (Read error: Operation timed out)
 454 2012-05-07 03:16:46 <gmaxwell> ah zooko does there. great.
 455 2012-05-07 03:18:28 devrandom has quit (Remote host closed the connection)
 456 2012-05-07 03:18:46 devrandom has joined
 457 2012-05-07 03:19:13 <gmaxwell> Now, there is another optimization, which is to instead code in radix-4 instead of radix-2 which halves the amount of private data you must disclose.
 458 2012-05-07 03:19:31 <gmaxwell> amiller: thanks much for the link, I should have just thought to ask zooko as I knew he was fond of lamport too.
 459 2012-05-07 03:20:46 b4epoche_ has quit (Ping timeout: 260 seconds)
 460 2012-05-07 03:21:18 <gmaxwell> (higher radix doesn't help because while 2^2 == 2*2  2^3 > 2*3)
 461 2012-05-07 03:21:19 <amiller> yup, i only know about merkle trees because of hanging out with tahoe-lafs. i went to stay with them in boulder for for a week last month partly in hopes of getting some direction in this proofofwork thing
 462 2012-05-07 03:21:40 zooko has joined
 463 2012-05-07 03:21:59 <amiller> hehe
 464 2012-05-07 03:22:35 MrTiggr is now known as NotMrTIggr
 465 2012-05-07 03:22:42 NotMrTIggr is now known as MrTIggr
 466 2012-05-07 03:22:47 MrTIggr is now known as MrTiggr
 467 2012-05-07 03:23:44 b4epoche_ has joined
 468 2012-05-07 03:24:24 <amiller> well while we're on the topic of crazy ideas, one of zooko's suggestions was to consider having old unspent transactions expire
 469 2012-05-07 03:24:32 <amiller> i think that makes a lot of sense now
 470 2012-05-07 03:25:05 <gmaxwell> Meh.. it does potentially, but its such a change I don't think it could be implemented in something called bitcoin.
 471 2012-05-07 03:25:17 <amiller> what i think would make the most sense is to consider the bitcoin values to be tied to the amount of storage your unspent inputs consume
 472 2012-05-07 03:25:27 <gmaxwell> I think if we ever had to do a disruptive cryptosystem upgrade to avoid ecdsa weaknesses then maybe it could be pulled off.
 473 2012-05-07 03:25:57 ThomasV has quit (Ping timeout: 244 seconds)
 474 2012-05-07 03:26:05 <gmaxwell> (expiring unspent transactions also serves the purpose of reducing the uncertanty in the currency supply)
 475 2012-05-07 03:26:08 <amiller> you're basically renting part of a common resource, you need to keep enough coins in the parking meter
 476 2012-05-07 03:26:47 <gmaxwell> amiller: expiration is fairly incompatible with usecases like the cassius coins though.
 477 2012-05-07 03:26:57 <amiller> i've grown to prefer thinking of bitcoin as a usage token system for a network that handles contracts rather than as money
 478 2012-05-07 03:28:06 <gmaxwell> I agree that it's a worthwhile trade-off in any case, I just suspect that its one which can't be retrofitted in an existing system without ruining the trust in it ('what if the next upgrade breaks _my_ useage!')
 479 2012-05-07 03:28:19 <amiller> sure
 480 2012-05-07 03:28:28 <amiller> so i used to run about panicking about merged mining for startup networks
 481 2012-05-07 03:28:38 devrandom has quit (Remote host closed the connection)
 482 2012-05-07 03:28:51 <gmaxwell> Why panic? if you don't want it— just don't do it.
 483 2012-05-07 03:28:58 <amiller> because someone with a lot of gpus would be able to crush a startup network
 484 2012-05-07 03:29:13 <amiller> ah i don't think i'm going anywhere consistent with that, strike it
 485 2012-05-07 03:29:31 <gmaxwell> (merged mining isn't something that can be invuluntarily imposed in any case)
 486 2012-05-07 03:29:46 devrandom has joined
 487 2012-05-07 03:30:10 <amiller> yeah, i meant panicking about startup networks if merged mining isn't available
 488 2012-05-07 03:30:36 <amiller> i do think that this proposed scheme makes merged mining useless, but i also think that's a neutral consequence
 489 2012-05-07 03:31:07 olp has quit (Ping timeout: 244 seconds)
 490 2012-05-07 03:31:09 <amiller> merged mining relies on 'work' being valid between two networks, and if the work is now aligned with the transaction data, then it will be different if the networks are different
 491 2012-05-07 03:34:47 <gmaxwell> well it can make independant merged mining impossible, but dependant merged mining still fine.
 492 2012-05-07 03:35:13 <amiller> i'm not familiar with those terms
 493 2012-05-07 03:35:44 <gmaxwell> E.g. if you're merging only for the purpose of making a timestamp committment to a tree of random data to prove its publication... the fact that the works is slaved to bitcoin is harmless.
 494 2012-05-07 03:35:57 <zooko> Hi folks.
 495 2012-05-07 03:36:03 Karmaon has joined
 496 2012-05-07 03:36:52 <gmaxwell> zooko: hey! I wanted your attention. I see you published a comment about lamport signatures with the public part compressed by transmitting middle nodes. I'm glad someone else had that idea too.
 497 2012-05-07 03:38:30 <gmaxwell> zooko: There is another optimizaiton that can be made, which is to code radix-4 digits (e.g. 0,1,2,3 instead of 0,1), which can be used to halve the amount of preimages you must disclose in a signature.  This reduces the effectiveness of the public tree compression, but the 25% off the top reduction in total signature size makes up for it.
 498 2012-05-07 03:38:39 pandasamanda is now known as pandaamanda
 499 2012-05-07 03:38:59 twmz has quit (Read error: Connection reset by peer)
 500 2012-05-07 03:39:04 twmz__ has joined
 501 2012-05-07 03:39:14 <gmaxwell> zooko: I was surprised that I couldn't find any papers on these simple lamport enhancements (beyond the basic one used for chaining signatures so you can use multiple times)
 502 2012-05-07 03:40:49 <zooko> Hi! I am busy right now planning some travel with my wife, but I am very concerned about Bitcoin changes/enhancements and would love to talk about it.
 503 2012-05-07 03:41:29 <gmaxwell> zooko: very concered about aht changes/enhancements? There aren't any changes/enhancements going on right now.
 504 2012-05-07 03:41:34 <gmaxwell> s/aht/what/
 505 2012-05-07 03:42:24 <luke-jr> gmaxwell: there aren't? :p
 506 2012-05-07 03:42:42 <gmaxwell> Not really!
 507 2012-05-07 03:43:26 <luke-jr> HD wallets.
 508 2012-05-07 03:43:39 <gmaxwell> (I mean I assume no one is concerned about fixing crash bugs, adding a console to the GUI, or giving people more control over their inputs)
 509 2012-05-07 03:44:57 <gmaxwell> zooko: Ah, yes you'd be interested in https://gist.github.com/1799467 save that and read if when you have a chance... though it's not something immediately impending right now.
 510 2012-05-07 03:45:09 <gmaxwell> (though even that isn't something people would have to use)
 511 2012-05-07 03:45:42 <zooko> The radix choice optimization sounds like a well-understood optimization.
 512 2012-05-07 03:45:58 <zooko> David-Sarah Hopwood has a better grasp of all of those than I do.
 513 2012-05-07 03:46:29 <gmaxwell> zooko: I'll search, thank you!
 514 2012-05-07 03:47:00 <zooko> I think that's called the "Winternitz parameter"...
 515 2012-05-07 03:47:06 pandaamanda has quit ()
 516 2012-05-07 03:47:25 <zooko> David-Sarah posted quite a lot of notes about hash-based digital signatures on the tahoe-lafs wiki...
 517 2012-05-07 03:47:32 <zooko> But hey, why are we talking about digital signatures anyway?
 518 2012-05-07 03:47:35 * zooko reads IRC backlog
 519 2012-05-07 03:47:38 <luke-jr> no idea
 520 2012-05-07 03:47:55 <gmaxwell> zooko: that was totally a tangent.
 521 2012-05-07 03:48:03 <zooko> Reading back, gmaxwell says "Also serves the purpose" of reducing uncertainty.
 522 2012-05-07 03:48:16 <zooko> That is one of my two biggest concerns about Bitcoin right now.
 523 2012-05-07 03:48:27 <zooko> That is: the uncertainty about the monetary base.
 524 2012-05-07 03:48:37 <zooko> And the propect of that uncertainty increasing over time.
 525 2012-05-07 03:48:49 <gmaxwell> zooko: the recent backlog is mostly amiller and I talking about things which have little to zero applicaiblity to bitcoin, because they change system invariants. (e.g. like that one)
 526 2012-05-07 03:49:06 <zooko> That one could in theory be upgraded-to, maybe.
 527 2012-05-07 03:49:07 <zooko> IMO
 528 2012-05-07 03:49:28 <zooko> I'm still catching up on the backlog.
 529 2012-05-07 03:50:06 <zooko> Note that the cassius-coins breakage -- and by the way I applaud your thinking about loss of confidence due to backwards-incompatibilities as such -- could be ameliorated by grandfathering-in old coins.
 530 2012-05-07 03:50:13 <gmaxwell> Maybe. I'm pretty sure we can't pull that one off without impending risk of cryptosystem compromise. — if people thought ecdsa would be broken soon, they'd accept expiring old ecdsa coins that would return into circulation and blow up the economy. I'm doubtful that anything less would get people to accept expiration.
 531 2012-05-07 03:50:24 <gmaxwell> hm. Thats an interesting thought.
 532 2012-05-07 03:50:26 <zooko> That would put a stop to the increasing uncertainty but wouldn't retroactively start working on old uncertainty.
 533 2012-05-07 03:50:38 <luke-jr> cassius-coins breakage?
 534 2012-05-07 03:50:39 <luke-jr> what's this?
 535 2012-05-07 03:51:02 ThomasV has joined
 536 2012-05-07 03:51:15 <gmaxwell> luke-jr: It would be very adventagious if old outputs expired for several technical and economic reasons, but it would break things like cassius coins... which might expire before you could spend them.
 537 2012-05-07 03:51:32 <luke-jr> oh, yes
 538 2012-05-07 03:51:45 <zooko> Another possibility that reduces uncertainty over time would be making the monetary base continue to increase.
 539 2012-05-07 03:52:00 <gmaxwell> (Technical reasons: spam times out, Economic: we don't know if there is a pot of a million sleeping coins that might someday be injected into the economy all at once)
 540 2012-05-07 03:52:04 <zooko> I am well aware that such ideas are politically inflammatory.
 541 2012-05-07 03:52:36 <zooko> Another economic reason: without such recycling, the actual monetary base shrinks over time, and possibly even with large jumps.
 542 2012-05-07 03:52:52 <gmaxwell> zooko: It's not that it's political inflammatory, it's that such a change would totally undermine trust in the system.  You can't change things people consider essential to the value of their bitcoins without leaving them rightfully thinking "what will the next change be?"
 543 2012-05-07 03:53:12 <zooko> That's a good argument.
 544 2012-05-07 03:53:24 <gmaxwell> zooko: thats less of a problem, increasing the divisiblity of coins is technically simple and economically neutral (unless you have almost none left)
 545 2012-05-07 03:53:50 <zooko> Yeah sure, I don't care about the notion of coins getting too small to be divided.
 546 2012-05-07 03:54:20 <zooko> But, the MB shrinking, especially in unpredictable and potentially large jumps, is still potentially an economic problem even if coins are infinitely divisibl.
 547 2012-05-07 03:54:21 <amiller> i think unspent-inputs should be charged rent on the storage they take up
 548 2012-05-07 03:54:24 <amiller> that solves both problems at once
 549 2012-05-07 03:54:26 RainbowDashh has quit (Quit: RainbowDashh)
 550 2012-05-07 03:54:52 <zooko> gmaxwell: I like your arguments. I'll cogitate on that.
 551 2012-05-07 03:54:58 <gmaxwell> I'd also argue that such a system (one where coin production never stops) isn't obviously non-inflationary, even if you've carefully calibrated it to be.. and as such people who want a non-inflationary system wouldn't be comfortable with it.
 552 2012-05-07 03:55:20 <zooko> Yes, that's part of the politically inflammatory aspect.
 553 2012-05-07 03:55:22 <BTC_Bear> In order to counter-act attrition, you need to 'print' exactly what was lost. Determining what is lost is the problem, imo.
 554 2012-05-07 03:55:33 <zooko> However, even a fixed MB could be inflationary.
 555 2012-05-07 03:55:34 <gmaxwell> (it's also perhaps impossible to calibrate it so— not without some kind of distributed control that adjusts the inflation rate, and the users probably won't trust the control whatever it is)
 556 2012-05-07 03:55:56 <zooko> Inflation is a function of two inputs -- money supply and wealth.
 557 2012-05-07 03:56:00 <gmaxwell> BTC_Bear: you don't. You just make coins more divisible. (and at some point switch to using µBTC as your units)
 558 2012-05-07 03:56:07 <zooko> Expert disagree about what sort of "money supply" is the money supply that should be used for that input.
 559 2012-05-07 03:56:25 <zooko> The easy, simple thing is to use monetary base, but I wouldn't be surprised if that's actually the wrong input.
 560 2012-05-07 03:56:38 <gmaxwell> zooko: I know, — but I'm mostly talking about people's first impression reasoning on the system, not complex economic ananlysis.
 561 2012-05-07 03:56:42 brwyatt is now known as brwyatt|Away
 562 2012-05-07 03:56:43 <zooko> Anyway, regardless of what you put in for the first input, what you put in for the second input is total wealth in the system.
 563 2012-05-07 03:56:52 <zooko> Yeah, okay, that's a good point.
 564 2012-05-07 03:57:05 <zooko> So you made some good points about that. I've gotta go. I'll think about these things. Thanks!
 565 2012-05-07 03:58:18 <gmaxwell> Okay! TTYL.
 566 2012-05-07 03:58:18 <BTC_Bear> Yes, I see the divisibility but if the monetary base decreases at 10% per year, divisibility isn't the answer. $1 is 100 pennies but losing 10% per year it wouldn't matter if you were talking $1 or 100 pennies.
 567 2012-05-07 03:58:20 <amiller> by both problems i mean a) it obviously solves the growing storage problem  and b) it solves the same economic purpose as inflation, but this is the only way that's intuitively fair - you pay proportionally for the resource you take up
 568 2012-05-07 03:59:29 <BTC_Bear> Now if you are proposing to increase divisibility below a satoshi, then yes. But then that would be a big problem.
 569 2012-05-07 03:59:40 <gmaxwell> BTC_Bear: but we're not talking about $1 vs 1000 pennies. Bitcoin is currently divisble to 1e-8.
 570 2012-05-07 04:00:13 <gmaxwell> BTC_Bear: I'm pointing out that we can easily make it divisble as deeply as needed. And such a change is both technically simple and economically neutral.. it's just not needed anytime soon.
 571 2012-05-07 04:00:42 <BTC_Bear> I agree, it isn't needed soon. But it is a problem that needs to be worked out.
 572 2012-05-07 04:01:04 <gmaxwell> If bitcoin survives 40 years then a 10 year migration could be implemented that would give it divisiblity to 1e-128 or something.
 573 2012-05-07 04:01:26 <gmaxwell> During that time we'd probably need to do a breaking change to replace the cryptographic functions in any case, so it could be done at the same time if people thought it was needed.
 574 2012-05-07 04:01:43 <BTC_Bear> Yes, I was for the migration method.
 575 2012-05-07 04:01:50 <BTC_Bear> Over a long period of time.
 576 2012-05-07 04:02:19 <gmaxwell> You deploy new versions of software that will switch to a new block format at block XXX where XXX is 5-10 years out.  Anyone who hasn't upgraded at that point stops working.
 577 2012-05-07 04:02:43 <BTC_Bear> agreed
 578 2012-05-07 04:02:56 <gmaxwell> We used something like this for the network protocol update (though that was just date triggered). It worked okay.
 579 2012-05-07 04:05:53 <luke-jr> infinite divisibility is better
 580 2012-05-07 04:07:05 <jgarzik> no, infinite divisibility makes life more annoying for very little value
 581 2012-05-07 04:08:35 <amiller> well i'll talk about the rent extraction scheme another, the couple of things i'm working on now are all related to paving the way towards opening up bitcoin-scripts for more general use as contracts
 582 2012-05-07 04:08:48 <gmaxwell> luke-jr: What jeff said.. though .... life gets harder as soon as we go to more than 4x more divisiblity.. because then we star running out of room in int64.
 583 2012-05-07 04:09:16 <gmaxwell> amiller: go workout your ideas with roconner first, since he really really dislikes any additional computing power in scripts.
 584 2012-05-07 04:09:23 <amiller> another time*.... anyway a) is how to pay proportionally for the storage as well as computation and b) is to decide what script functionalities could make sense
 585 2012-05-07 04:09:25 <amiller> ah yeah
 586 2012-05-07 04:09:31 <luke-jr> gmaxwell: at the protocol level, int64 doesn't help much
 587 2012-05-07 04:09:40 <luke-jr> except for miners I guess
 588 2012-05-07 04:10:03 <gmaxwell> luke-jr: forget the protocol— the callers need to handle things too.. already it's hard to convice people to not @#$#@ use float for bitcoin values.
 589 2012-05-07 04:10:14 <gmaxwell> (which MTGOX _still_ does at least in some parts of their system)
 590 2012-05-07 04:10:18 <luke-jr> >_<
 591 2012-05-07 04:12:26 <gmaxwell> making everyone use decNumber (an arbitrary-precision decimal float library) for bitcoin values would not be a kind thing. :)
 592 2012-05-07 04:13:35 <gmaxwell> hey, not something I see often:
 593 2012-05-07 04:13:35 <gmaxwell> 05/07/12 04:10:54 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
 594 2012-05-07 04:13:44 <luke-jr> gmaxwell: yes, decimal is lame
 595 2012-05-07 04:13:50 <luke-jr> gmaxwell: and it would break with 1/3
 596 2012-05-07 04:14:37 <amiller> ok, good suggestion, i'll hit up roconnor about that then
 597 2012-05-07 04:15:48 <gmaxwell> 05/07/12 01:08:00 50.16.195.87:59371 version message: version 31900, blocks=0 currentbest=178993
 598 2012-05-07 04:15:51 <gmaxwell> 05/07/12 01:08:00 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
 599 2012-05-07 04:15:54 <gmaxwell> --
 600 2012-05-07 04:15:56 <gmaxwell> 05/07/12 02:39:16 50.16.195.87:60642 version message: version 31900, blocks=0 currentbest=179001
 601 2012-05-07 04:16:00 <gmaxwell> 05/07/12 02:39:16 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
 602 2012-05-07 04:16:04 <gmaxwell> --
 603 2012-05-07 04:16:06 <gmaxwell> 05/07/12 02:40:19 50.16.195.87:60647 version message: version 31900, blocks=0 currentbest=179002
 604 2012-05-07 04:16:10 <gmaxwell> 05/07/12 02:40:19 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
 605 2012-05-07 04:16:12 <gmaxwell> --
 606 2012-05-07 04:16:15 <gmaxwell> 05/07/12 04:10:54 50.16.195.87:33799 version message: version 31900, blocks=0 currentbest=179014
 607 2012-05-07 04:16:16 <DiabloD3> whats this
 608 2012-05-07 04:16:18 <gmaxwell> 05/07/12 04:10:54 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
 609 2012-05-07 04:16:21 <gmaxwell> someone has a very strangly broken node.
 610 2012-05-07 04:16:42 JZavala has quit (Ping timeout: 244 seconds)
 611 2012-05-07 04:17:09 <luke-jr> gmaxwell: also, you don't need to be able to represent the full quantity of all bitcoin units in an int64 ;)
 612 2012-05-07 04:18:09 <luke-jr> ie, even if Bitcoin goes that route, the limit is on how big outputs can be
 613 2012-05-07 04:18:33 <gmaxwell> I think you ought to be able to represent the full quantity squared, in fact. So then someone can write fixed point code knowing that if they never do anything worse then square it can never overflow.
 614 2012-05-07 04:19:07 <luke-jr> well, time will tell what requirements Bitcoin needs to face in the future :P
 615 2012-05-07 04:20:01 <gmaxwell> Indeed.
 616 2012-05-07 04:21:46 <amiller> i have a toy python implementation of my proposed proof-of-work scheme up here https://github.com/amiller/redblackmerkle i'm not too sure how to be more helpful than that, i suppose i should write to the bitcoin-dev list
 617 2012-05-07 04:22:09 RainbowDashh has joined
 618 2012-05-07 04:23:09 <gmaxwell> amiller: etotheipi wants these trees keyed off the output address so its easier to enumerate txn that belong to you.
 619 2012-05-07 04:24:59 Slix` has quit (Read error: Connection reset by peer)
 620 2012-05-07 04:25:04 <gmaxwell> (for domain names they should be keyed on some hash of the name, so that you can have provable nxdomain)
 621 2012-05-07 04:25:17 <amiller> mmm
 622 2012-05-07 04:25:23 DiabloD3 has quit (Ping timeout: 240 seconds)
 623 2012-05-07 04:25:25 <amiller> i suddenly wonder if it's possible to pay for multiple indexes
 624 2012-05-07 04:26:01 <gmaxwell> (though again, I think those requirements risk giving us unbalanced trees)
 625 2012-05-07 04:26:13 <amiller> no way, i can balance all the trees
 626 2012-05-07 04:27:00 <gmaxwell> OKAY.
 627 2012-05-07 04:28:10 <amiller> if you have fancy hash functions, you can get all sorts of different tradeoffs, there's a lattice based technique for an authenticated bloom filter
 628 2012-05-07 04:28:16 * jgarzik bangs his head against this stupid BDB usage...  should just be txhash or blockhash as a key, for those respective indices, nothing else.  and no need for DB_BTREE there.
 629 2012-05-07 04:28:19 <amiller> i'm content thinking on log N for everything now
 630 2012-05-07 04:28:30 <gmaxwell> amiller: then.. could you make it so you could mine some kinds of outputs (kind being different index types) so long as you don't touch the trees of other kinds?  Then you have merged mining back, but internalized.
 631 2012-05-07 04:29:03 <gmaxwell> jgarzik: oh, hey, that sounds like a lowhanging performance improvement!
 632 2012-05-07 04:30:02 <amiller> etotheipi's idea is awesome
 633 2012-05-07 04:30:12 one_zero has joined
 634 2012-05-07 04:30:18 <jgarzik> gmaxwell: easy to code.  upgrades would be annoying
 635 2012-05-07 04:30:19 <amiller> if you had an index for address, then you could get a proof that you're aware of _all_ of the inputs directed to you
 636 2012-05-07 04:30:32 <amiller> it's possible to get authenticated range searches
 637 2012-05-07 04:30:37 <gmaxwell> (we're really building btrees over txhahes? yuck— though it might be wise to do something to provide attack resistance, otherwise someone might start intentionally creating txn with constant prefixes in order to complexity attack the lookups)
 638 2012-05-07 04:30:39 <jgarzik> either (a) code the upgrade or (b) d/l block chain again, into new fmt
 639 2012-05-07 04:30:45 olp has joined
 640 2012-05-07 04:31:08 <gmaxwell> amiller: yea I'd pointed that out in some post before wrt name lookups. Same thing.
 641 2012-05-07 04:31:18 <gmaxwell> amiller: and I tried really hard to get the namecoin people to implement it.
 642 2012-05-07 04:31:39 <gmaxwell> jgarzik: just make it a flag, and newly downloaded chains get the new mode.
 643 2012-05-07 04:31:42 <jgarzik> gmaxwell: yes, it's that ugly.  it's a common enough paradigm... manage your key namespace like a filesystem, where key='foo/obj' and key='bar/obj' tell us something interesting and distinguishing about 'foo' and 'bar' subsets
 644 2012-05-07 04:31:58 <jgarzik> common enough... but annoying and performance-killing, for bitcoin
 645 2012-05-07 04:33:35 <gmaxwell> explains some of the extreme write inflation I saw on the indexes.
 646 2012-05-07 04:34:29 <jgarzik> gmaxwell: we store tx hashes, block hashes, and misc. metadata (hashBestChain) all in one big btree
 647 2012-05-07 04:34:53 <jgarzik> gmaxwell: tx hashes and block hashes clearly want to be separate indices
 648 2012-05-07 04:35:27 <gmaxwell> meh. right. maintaining both forms would be a code mess.
 649 2012-05-07 04:35:29 <jgarzik> maybe satoshi was worried about ACID, but transactions in bdb work fine across databases
 650 2012-05-07 04:35:45 <jgarzik> gmaxwell: indeed
 651 2012-05-07 04:37:30 <gmaxwell> I can see the reason for being conservative— unexpected bdb behavior can be the end of bitcoin (cause irreparable splits) BDB usually seems to be pretty good (in spite of people's whines) but I don't think it's really sutiable for the minor-acid-glitch-makes-millions-of-dollars-in-value-vanish-forever that we're asking of it.
 652 2012-05-07 04:41:14 <amiller> gmaxwell, that's interesting, it seems like it could make sense to have several different overlays of the same data
 653 2012-05-07 04:43:01 <amiller> the requirements for a valid transaction would be more constrained the more layers inside you go, with bitcoin being the outermost layer
 654 2012-05-07 04:46:36 devrandom has quit (Remote host closed the connection)
 655 2012-05-07 04:46:52 devrandom has joined
 656 2012-05-07 04:52:45 <BlueMatt> gmaxwell: I would argue bdb would be better in that scenario than literally anything else, but that just means we need to code redundancy and sanity checks into our code...
 657 2012-05-07 04:52:56 <BlueMatt> s/literally/just about/
 658 2012-05-07 04:54:05 <gmaxwell> BlueMatt: I'm not sure. Reorgs are hard and its very scarry the complicated way they interact wth the database.
 659 2012-05-07 04:54:16 <gmaxwell> Without them our needs for the database are stupidly simple.
 660 2012-05-07 04:54:56 <BlueMatt> gmaxwell: yea, and in that case Id rather have the well-tested bdb than something we create or most other dbs
 661 2012-05-07 04:55:56 <BlueMatt> not to say more research needs to be done in all the options in bdb, but...
 662 2012-05-07 04:57:27 Joric has joined
 663 2012-05-07 04:58:21 Motest003 has joined
 664 2012-05-07 04:58:22 devrandom has quit (Remote host closed the connection)
 665 2012-05-07 04:58:56 devrandom has joined
 666 2012-05-07 04:58:57 <gmaxwell> BlueMatt: there really are all kinds of options. For example, if you have an otherwise valid block and a tx index lookup fails you probaby should seq scan the whole blockchain because its far more likely that your index got corrupted than someone mined a block with some non-existing inputs.
 667 2012-05-07 04:59:37 <BlueMatt> yea, thats what Im saying - code in more redundancy against db failure, but Id rather stick with bdb for complicated things like reorgs, is my point
 668 2012-05-07 04:59:57 <gmaxwell> And we absolutely are seeing potentially network ending BDB related events in the wild, we've just been very lucky that none of them have been the sort that happen to trigger on all nodes at once.
 669 2012-05-07 05:00:07 <gmaxwell> (for example! the fact that large reorgs fail!)
 670 2012-05-07 05:00:28 <BlueMatt> yea, thats why I said more research in bdb options would also be nice
 671 2012-05-07 05:00:49 <BlueMatt> but, again, I think we would shoot ourselves in the foot if we went to our own db to handle all the complicated mess of reorgs
 672 2012-05-07 05:01:17 <gmaxwell> The fact that such a failure arises out of some sneakyness of BDB vs bugs isn't really relevant, the failure is all that matters. :)
 673 2012-05-07 05:01:30 <BlueMatt> true
 674 2012-05-07 05:01:41 <gmaxwell> And this stuff is all very hard to test because BDB encapsulates an enormous amount of invisible state.
 675 2012-05-07 05:01:48 <BlueMatt> but researching potential bdb sneakiness seems better than writing our own, imho
 676 2012-05-07 05:02:00 <gmaxwell> Probably. Still— it's a reason to be paranoid.
 677 2012-05-07 05:02:14 <BlueMatt> simplifying db code, and in the process, researching bdb further, that is
 678 2012-05-07 05:02:28 <BlueMatt> oh, absolutely, more paranoia is almost always better, in this case
 679 2012-05-07 05:02:35 <gmaxwell> I'd like to have a non-bdb based full node, even if it was slow as @#$#@$@.. just so we could have loud klaxon if it ever disagreed with the reference code.
 680 2012-05-07 05:02:50 <gmaxwell> I was hoping roconner would give us that, but I think he burned out or something. :(
 681 2012-05-07 05:03:10 <BlueMatt> Id like to have a ton of different full nodes, so that we could have that
 682 2012-05-07 05:04:13 da2ce7 has joined
 683 2012-05-07 05:12:05 <BlueMatt> how far is like libbitcoin towards being a full node?
 684 2012-05-07 05:13:57 <setkeh> Does anyone know of a Module for ZenCart that can execute a shell command on sucessful payment instead of useing a shipping module
 685 2012-05-07 05:27:48 sytse has joined
 686 2012-05-07 05:34:36 RainbowDashh has quit (Quit: RainbowDashh)
 687 2012-05-07 05:38:38 <gmaxwell> sipa: my test user wasn't so bad. They made a backup of the chain first. I got them to start the patched code on the backup and they let it run for an hour but it remained stuck.
 688 2012-05-07 05:38:48 <gmaxwell> sipa: I'm going to try to talk a copy of the chain out of the,
 689 2012-05-07 05:38:59 <wumpus>  but I don't think it's really sutiable for the minor-acid-glitch-makes-millions-of-dollars-in-value-vanish-forever that we're asking of it <-   not that writing your own code instead of battle-tested db code will necessarily be better , of course
 690 2012-05-07 05:39:11 <gribble> New news from bitcoinrss: laanwj opened pull request 1215 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1215>
 691 2012-05-07 05:40:00 <gmaxwell> wumpus: indeed, there may currently be no better option— but as I mentioned later, simply having more full implementations to compare would be good.
 692 2012-05-07 05:41:41 Ukto has quit (Read error: Connection reset by peer)
 693 2012-05-07 05:41:46 Ukyo has joined
 694 2012-05-07 05:41:50 <wumpus> next step up would probably be a fully-fledged RDMS
 695 2012-05-07 05:41:53 Ukyo is now known as Ukto
 696 2012-05-07 05:42:34 <gmaxwell> wumpus: RE: the log viewer comments on github. I think you have the wrong perspective.  I don't really give a shit what the user wants for his logging— in order to diagnose problems he's seeing with bitcoin I need to know what bitcoin has been saying in the debug log greatly. Logging to the system log would actually counterprodutive to my interests.
 697 2012-05-07 05:43:07 <gmaxwell> (if the user wants that, he can have it too.. I don't really care— but it doesn't help me troubleshoot some random user whos crying for help)
 698 2012-05-07 05:43:40 <wumpus> gmaxwell, that may be true, but unless there is some liberally-licensed log viewer that we can integrate, that's just not a project I'm starting on
 699 2012-05-07 05:44:09 * jgarzik would like to extend ArtForz' half-a-node to support very basic bitcoind-like operation (getwork + simple wallet)
 700 2012-05-07 05:44:15 * jgarzik poked at that a bit
 701 2012-05-07 05:44:17 <gmaxwell> wumpus: does QT not have some texteditor widget that can do everything needed?
 702 2012-05-07 05:44:31 <wumpus> oh sure it does... but put 4Gb of data in it and it's insta-dead
 703 2012-05-07 05:45:00 <gmaxwell> wumpus: 'fully-fledged RDMS' is really the wrong direction. Except for needing to change the transactions in the open set atomically during a reorg bitcoind's database needs are just simple hash lookups on blocks and txns.
 704 2012-05-07 05:45:01 * luke-jr thought a text-viewer widget for the RPC API would make sense
 705 2012-05-07 05:45:46 <wumpus> unless you put the log in some database too, of course, which supports range queries... but that makes it impossible to process it with text tools
 706 2012-05-07 05:45:50 <gmaxwell> And this stuff people want to do with tree commitments on open transactions to enable semi-full nodes would require moving the open transaction set management into bitcoin anyways, or at least more than it is now.
 707 2012-05-07 05:46:22 <gmaxwell> wumpus: well we could easily track the last 100 entries or whatever in memory.
 708 2012-05-07 05:46:34 <wumpus> that's what I proposed?!
 709 2012-05-07 05:46:45 Ukto has quit (Read error: Connection reset by peer)
 710 2012-05-07 05:46:54 Ukyo has joined
 711 2012-05-07 05:47:00 Ukyo is now known as Ukto
 712 2012-05-07 05:47:15 rdponticelli has quit (Ping timeout: 272 seconds)
 713 2012-05-07 05:47:20 <gmaxwell> Okay, fair enough.  I'm surprised that there isn't a text editor widget that doesn't require the file being in memory, but alas. okay.
 714 2012-05-07 05:49:22 guruvan has quit (Remote host closed the connection)
 715 2012-05-07 05:51:22 RainbowDashh has joined
 716 2012-05-07 05:52:53 <wumpus> I'm sure someone, somewhere, at some time wrote such a thing
 717 2012-05-07 05:54:17 Sedra has joined
 718 2012-05-07 05:57:20 Sedra- has quit (Ping timeout: 244 seconds)
 719 2012-05-07 05:57:59 Sedra- has joined
 720 2012-05-07 05:58:07 devrandom has quit (Remote host closed the connection)
 721 2012-05-07 05:58:47 devrandom has joined
 722 2012-05-07 05:58:52 TD has joined
 723 2012-05-07 06:00:11 Sedra has quit (Ping timeout: 276 seconds)
 724 2012-05-07 06:02:47 <gjs278> can you rate limit the network connection for bitcoind
 725 2012-05-07 06:03:02 <gjs278> sometimes they start taking like 700kb/s upload on me
 726 2012-05-07 06:05:50 guruvan has joined
 727 2012-05-07 06:07:20 RainbowDashh has quit (Ping timeout: 276 seconds)
 728 2012-05-07 06:07:40 zooko has quit (Remote host closed the connection)
 729 2012-05-07 06:07:45 zooko has joined
 730 2012-05-07 06:09:51 <gmaxwell> gjs278: there isn't anything built into bitcoin to do that—  but you can do it yourself at your router if it has that functionality.
 731 2012-05-07 06:10:17 <gmaxwell> gjs278: if you disable listening and make outbound counnections only you'll rarely use a lot of bandwidth— those spikes are new nodes pulling the chain from you.
 732 2012-05-07 06:13:02 fiddur has joined
 733 2012-05-07 06:16:35 <gjs278> yeah ok
 734 2012-05-07 06:20:04 minimoose has joined
 735 2012-05-07 06:26:43 paul0 has quit (Quit: paul0)
 736 2012-05-07 06:31:47 devrandom has quit (Remote host closed the connection)
 737 2012-05-07 06:32:21 devrandom has joined
 738 2012-05-07 06:32:35 RainbowDashh has joined
 739 2012-05-07 06:38:13 elkingrey has quit (Quit: Leaving)
 740 2012-05-07 06:40:22 m00p has quit (Remote host closed the connection)
 741 2012-05-07 06:41:46 sgornick has joined
 742 2012-05-07 06:44:09 mmoya has joined
 743 2012-05-07 06:46:33 dvide has quit ()
 744 2012-05-07 06:53:09 chrisb__ has joined
 745 2012-05-07 06:57:34 Motest003 has quit ()
 746 2012-05-07 06:58:11 Motest003 has joined
 747 2012-05-07 06:59:31 minimoose has quit (Quit: minimoose)
 748 2012-05-07 07:08:56 paulo_ is now known as mtgox_customers
 749 2012-05-07 07:10:34 jarkinox has joined
 750 2012-05-07 07:10:46 toffoo has quit ()
 751 2012-05-07 07:11:19 mtgox_customers is now known as paulo_
 752 2012-05-07 07:12:41 TD has quit (Quit: TD)
 753 2012-05-07 07:24:41 zooko has quit (Ping timeout: 276 seconds)
 754 2012-05-07 07:32:52 dusty__ has quit (Quit: Konversation terminated!)
 755 2012-05-07 07:36:35 b4epoche_ has quit (Ping timeout: 252 seconds)
 756 2012-05-07 07:37:24 Motest003 has quit (Ping timeout: 240 seconds)
 757 2012-05-07 07:37:45 Motest003 has joined
 758 2012-05-07 07:39:16 sirk390 has joined
 759 2012-05-07 07:39:16 b4epoche_ has joined
 760 2012-05-07 07:43:15 jarkinox has quit (Ping timeout: 244 seconds)
 761 2012-05-07 07:50:09 bob12321 has quit (Ping timeout: 252 seconds)
 762 2012-05-07 07:51:56 bob12321 has joined
 763 2012-05-07 07:52:18 erle- has joined
 764 2012-05-07 08:00:54 sneak has quit (Ping timeout: 272 seconds)
 765 2012-05-07 08:01:08 sneak has joined
 766 2012-05-07 08:15:38 Joric has quit (Ping timeout: 255 seconds)
 767 2012-05-07 08:21:16 Ken`_ has quit (Remote host closed the connection)
 768 2012-05-07 08:24:28 Ken` has joined
 769 2012-05-07 08:26:55 pierre` has quit (Remote host closed the connection)
 770 2012-05-07 08:31:31 BTC_Bear is now known as BTC_Bear|hbrntng
 771 2012-05-07 08:38:01 devrandom has quit (Remote host closed the connection)
 772 2012-05-07 08:39:25 devrandom has joined
 773 2012-05-07 08:40:24 RazielZ has joined
 774 2012-05-07 08:42:11 ThomasV has quit (Ping timeout: 260 seconds)
 775 2012-05-07 08:45:16 ThomasV has joined
 776 2012-05-07 08:51:55 danbri has joined
 777 2012-05-07 08:54:25 BurtyB has joined
 778 2012-05-07 08:55:15 devrandom has quit (Remote host closed the connection)
 779 2012-05-07 08:56:07 devrandom has joined
 780 2012-05-07 08:57:01 pierre` has joined
 781 2012-05-07 08:58:59 ThomasV has quit (Ping timeout: 245 seconds)
 782 2012-05-07 09:00:29 <jine> Is there any easy way/script/whatever to show the coinbase of a block?
 783 2012-05-07 09:06:48 <sipa> jine: getblock rpc?
 784 2012-05-07 09:07:22 devrandom has quit (Remote host closed the connection)
 785 2012-05-07 09:08:15 devrandom has joined
 786 2012-05-07 09:13:51 <gribble> New news from bitcoinrss: olea opened pull request 1216 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1216>
 787 2012-05-07 09:17:40 molecular has quit (Ping timeout: 252 seconds)
 788 2012-05-07 09:18:40 molecular has joined
 789 2012-05-07 09:24:32 <Eliel> gmaxwell: I think I just realised why my network connection is laggy sometimes. It's bitcoind sending blocks. However, I don't think it's a very good solution to have people wanting to limit bandwidth usage to go outbound only. It'll cripple the network.
 790 2012-05-07 09:25:11 <gmaxwell> Eliel: no it won't. If you're starved enough on bandwidth that it's a problem you probably really should be outbound only.
 791 2012-05-07 09:25:46 <gmaxwell> Though sure, some rate limiting for block feeding would be nice—  but I think we first need the software to cope with peers that feed blocks slowly.
 792 2012-05-07 09:26:50 <Eliel> my upstream can handle 100kB/s at maximum but using all that does add noticeable latency.
 793 2012-05-07 09:27:17 <Eliel> I guess I might consider creating a QoS script again.
 794 2012-05-07 09:28:13 <gmaxwell> It's pretty reasonable to deprioritize bitcoin... it's not latency sensitive in the slighest.
 795 2012-05-07 09:39:12 _Fireball has joined
 796 2012-05-07 09:50:02 <jine> sipa: getblock rpc doesn't show the coinbase, does it?
 797 2012-05-07 10:10:24 ThomasV has joined
 798 2012-05-07 10:10:35 ThomasV has quit (Changing host)
 799 2012-05-07 10:10:35 ThomasV has joined
 800 2012-05-07 10:12:13 Joric has joined
 801 2012-05-07 10:24:51 DamascusVG has quit (Ping timeout: 260 seconds)
 802 2012-05-07 10:36:09 danbri has quit (Read error: Connection reset by peer)
 803 2012-05-07 10:36:28 danbri has joined
 804 2012-05-07 10:40:20 abbe has joined
 805 2012-05-07 10:42:39 devrandom has quit (Remote host closed the connection)
 806 2012-05-07 10:43:56 devrandom has joined
 807 2012-05-07 10:44:39 DamascusVG has joined
 808 2012-05-07 10:47:43 RainbowDashh has quit (Quit: RainbowDashh)
 809 2012-05-07 10:51:50 drizztbsd has joined
 810 2012-05-07 10:52:32 sneak has quit (Ping timeout: 272 seconds)
 811 2012-05-07 10:52:38 sneak has joined
 812 2012-05-07 10:52:38 sneak has quit (Changing host)
 813 2012-05-07 10:52:38 sneak has joined
 814 2012-05-07 10:56:46 Clipse has joined
 815 2012-05-07 11:03:18 sneak has quit (Ping timeout: 272 seconds)
 816 2012-05-07 11:11:45 rcorreia_ has quit (Quit: No Ping reply in 180 seconds.)
 817 2012-05-07 11:12:00 rcorreia has joined
 818 2012-05-07 11:12:06 comboy has quit (Read error: Connection reset by peer)
 819 2012-05-07 11:12:11 guruvan has quit (Ping timeout: 276 seconds)
 820 2012-05-07 11:12:11 comboy has joined
 821 2012-05-07 11:13:43 sneak has joined
 822 2012-05-07 11:13:43 sneak has quit (Changing host)
 823 2012-05-07 11:13:43 sneak has joined
 824 2012-05-07 11:13:50 d4de has quit (Read error: Connection reset by peer)
 825 2012-05-07 11:14:22 guruvan has joined
 826 2012-05-07 11:21:55 Mobius_ has joined
 827 2012-05-07 11:21:56 random_cat_ has quit (Ping timeout: 276 seconds)
 828 2012-05-07 11:22:02 devrandom has quit (Remote host closed the connection)
 829 2012-05-07 11:22:25 devrandom has joined
 830 2012-05-07 11:25:11 MobiusL has quit (Ping timeout: 276 seconds)
 831 2012-05-07 11:32:43 copumpkin has joined
 832 2012-05-07 11:34:39 random_cat_ has joined
 833 2012-05-07 11:47:39 Joric has quit ()
 834 2012-05-07 11:51:15 b4epoche_ has quit (Read error: Operation timed out)
 835 2012-05-07 11:53:25 b4epoche_ has joined
 836 2012-05-07 11:58:19 denisx has joined
 837 2012-05-07 12:00:12 cdecker has joined
 838 2012-05-07 12:09:10 sneak has quit (Ping timeout: 272 seconds)
 839 2012-05-07 12:09:15 sneak has joined
 840 2012-05-07 12:11:32 agricocb has quit (Quit: Leaving.)
 841 2012-05-07 12:14:44 denisx has quit (Read error: Connection timed out)
 842 2012-05-07 12:16:25 denisx has joined
 843 2012-05-07 12:29:26 sneak has quit (Ping timeout: 272 seconds)
 844 2012-05-07 12:29:47 sneak has joined
 845 2012-05-07 12:30:54 antix_ has quit (Ping timeout: 252 seconds)
 846 2012-05-07 12:33:05 denisx has quit (Read error: Connection timed out)
 847 2012-05-07 12:34:27 denisx has joined
 848 2012-05-07 12:36:37 antix has joined
 849 2012-05-07 12:37:02 paulo_ has quit (Remote host closed the connection)
 850 2012-05-07 12:37:21 paulo_ has joined
 851 2012-05-07 13:05:36 t7 has joined
 852 2012-05-07 13:05:44 agricocb has joined
 853 2012-05-07 13:06:02 datagutt has joined
 854 2012-05-07 13:06:49 Zarutian has joined
 855 2012-05-07 13:08:07 guruvan has quit (Quit: I probably voided the warranty on this thing.....)
 856 2012-05-07 13:08:11 zooko has joined
 857 2012-05-07 13:08:54 Diapolo has joined
 858 2012-05-07 13:09:19 <Diapolo> sipa: Did you have the time to do that Win-build for me?
 859 2012-05-07 13:10:33 <Diapolo> and hello everyone
 860 2012-05-07 13:10:39 <sipa> there was a bug in master yesterday that prevented me from building, let me try again
 861 2012-05-07 13:11:27 Neskia is now known as Nesetalis
 862 2012-05-07 13:17:54 <denisx> has anybody else problems with bitcoin running at 100% all the time?
 863 2012-05-07 13:18:06 <denisx> version 0.6.1
 864 2012-05-07 13:18:10 <gmaxwell> denisx: on OSX?
 865 2012-05-07 13:18:16 <denisx> yep, and on freebsd
 866 2012-05-07 13:18:25 <gmaxwell> (I thought we killed that bug on OSX…)
 867 2012-05-07 13:18:32 <gmaxwell> The GUI?
 868 2012-05-07 13:18:40 <sipa> it's probably a different one, if it's on FreeBSD as well
 869 2012-05-07 13:19:05 <denisx> the problem appeared some time after 0.6.0
 870 2012-05-07 13:19:20 <sipa> after? :o
 871 2012-05-07 13:19:33 <denisx> 0.6.0 did not had that problem
 872 2012-05-07 13:20:12 <drizztbsd> denisx: are you using gen=1? :P
 873 2012-05-07 13:20:19 <denisx> no
 874 2012-05-07 13:20:30 <jine> "the transaction will be reversed. The case is now closed.Inquiry by PayPal - Case ID: "
 875 2012-05-07 13:20:39 <jine> Oh crap, wrong channgel :) sorry
 876 2012-05-07 13:20:51 <sipa> Diapolo: can you check using gdb which thread/functions are consuming the cpu?
 877 2012-05-07 13:20:52 <drizztbsd> (never buy/sells bitcoin with paypal :P)
 878 2012-05-07 13:21:01 <sipa> *denisx:
 879 2012-05-07 13:21:05 <Diapolo> Are you using the 0.6.1 final? The RCs had a GUI bug that caused high CPU usage.
 880 2012-05-07 13:21:12 <denisx> yes, final
 881 2012-05-07 13:22:28 <gmaxwell> wumpus: ^
 882 2012-05-07 13:23:19 <Diapolo> I can verify a high CPU usage while syncing.
 883 2012-05-07 13:23:22 <Tyklol> denisx: I'll try upgrading to 6.1 on freebsd and see if I can reproduce it tonight, might be able to see what is going on with dtrace :)
 884 2012-05-07 13:26:49 <Diapolo> I think that happens during block-chain downloads, because the GUI is redrawn at a too high rate. wumpus want to fix this with https://github.com/bitcoin/bitcoin/pull/1205
 885 2012-05-07 13:29:48 <sipa> Diapolo: http://bitcoin.sipa.be/builds/0.6.1-35-g34a0eab/
 886 2012-05-07 13:30:18 <denisx> time is used in ThreadOpenConnections2
 887 2012-05-07 13:30:21 <sipa> https://github.com/Diapolo/bitcoin/commit/34a0eab
 888 2012-05-07 13:31:38 guruvan has joined
 889 2012-05-07 13:31:47 <sipa> Diapolo: no particular warnings when building
 890 2012-05-07 13:32:29 <gmaxwell> denisx: seems unlikely unless Sleep() doesn't work on your platform for some reason.
 891 2012-05-07 13:32:48 <Diapolo> sipa: great, thank you
 892 2012-05-07 13:33:26 <Diapolo> sipa: I can start the debugger in the Qt creator, but I never used it to track down any CPU usage bugs ... :-/.
 893 2012-05-07 13:33:40 <sipa> Diapolo: i actually meant denisx
 894 2012-05-07 13:34:14 <Diapolo> sipa: alright :) as I wrote I think it's related to GUI updates, but that is in contrast to ThreadOpenConnections2
 895 2012-05-07 13:34:17 <denisx> sipa: on freebsd, no. the osx version is the prebuild one from sourceforge
 896 2012-05-07 13:34:31 <sipa> could be
 897 2012-05-07 13:37:00 guruvan has quit (Quit: I probably voided the warranty on this thing.....)
 898 2012-05-07 13:41:00 <denisx> were there any changes to ThreadOpenConnections2 after 0.6.0?
 899 2012-05-07 13:41:02 d4de has joined
 900 2012-05-07 13:43:46 <gmaxwell> erp.
 901 2012-05-07 13:43:49 <gmaxwell> WAIT() is busy.
 902 2012-05-07 13:48:00 <sipa> gmaxwell: it's a loop, but not a busy loop
 903 2012-05-07 13:48:31 <gmaxwell> ah, the lock itself sleeps. okay.
 904 2012-05-07 13:48:37 <Diapolo> sipa: that build works, thank you very much ... is it okay to let people test this so I can check if it works?
 905 2012-05-07 13:48:37 <sipa> yes
 906 2012-05-07 13:49:22 Joric has joined
 907 2012-05-07 13:50:18 <gmaxwell> denisx: there were changes but none which should have obviously caused this. It would be great if you could attack a debugger and break that thread a few times to see where it was landing.
 908 2012-05-07 13:51:08 <sipa> Diapolo: as long as you either warn them it's experimental, or assume responsability yourself :)
 909 2012-05-07 13:51:13 <denisx> I did
 910 2012-05-07 13:51:26 <denisx> last place in bitcoin is ThreadOpenConnections2
 911 2012-05-07 13:51:36 <sipa> where exactly?
 912 2012-05-07 13:51:42 <denisx> then comes sched_yield, swtch_pri
 913 2012-05-07 13:52:07 <sipa> in Sleep you mean?
 914 2012-05-07 13:52:34 <denisx> I just attached Instruments to the running binary
 915 2012-05-07 13:52:46 <sipa> i have no idea what that means
 916 2012-05-07 13:53:17 <denisx> osx GUI version of dtrace is called Instruments
 917 2012-05-07 13:55:30 <denisx> no source code
 918 2012-05-07 13:55:59 Clipse has quit (Ping timeout: 276 seconds)
 919 2012-05-07 13:56:01 guruvan has joined
 920 2012-05-07 13:59:14 zooko has quit (Ping timeout: 276 seconds)
 921 2012-05-07 14:02:39 capiscuas has joined
 922 2012-05-07 14:08:16 capiscuas has quit (Quit: Leaving)
 923 2012-05-07 14:09:40 Glasswalker has quit (Ping timeout: 252 seconds)
 924 2012-05-07 14:09:57 <denisx> looks it is time to test git bisect
 925 2012-05-07 14:12:21 ThomasV has quit (Quit: Quitte)
 926 2012-05-07 14:13:18 <Diapolo> Can anyone tell me if it's possible to use posix_fallocate() on non Windows systems like Mac, Linux / Unix?
 927 2012-05-07 14:13:38 <Diapolo> I mean is it somehow standard.
 928 2012-05-07 14:13:48 <gmaxwell> The word "posix" is a keyword there...
 929 2012-05-07 14:14:06 <gmaxwell> I don't know if mac has it— but linux certantly does.
 930 2012-05-07 14:16:28 zooko has joined
 931 2012-05-07 14:17:58 <Diapolo> Now things get bad, I need to create a Mac / Linux version I can't test or com
 932 2012-05-07 14:17:59 <Diapolo> pile ^^
 933 2012-05-07 14:18:21 <gmaxwell> Diapolo: I can give you a shell.
 934 2012-05-07 14:18:57 <gmaxwell> and even set it all up to compile for you.
 935 2012-05-07 14:20:16 <Diapolo> gmaxwell: What are the things I need to know, before you do some work and I can't even use it.
 936 2012-05-07 14:20:33 <Diapolo> you remember that Windows-Guy-thing ^^
 937 2012-05-07 14:21:29 <gmaxwell> How to use putty and winscp.  I'll be glad to walk you through it. thought it might need to wait until a bit later.
 938 2012-05-07 14:21:32 sneak has quit (Ping timeout: 272 seconds)
 939 2012-05-07 14:23:20 one_zero has quit ()
 940 2012-05-07 14:23:37 <Diapolo> At first I want to look a bit into what I need to do the code and afterwards (perhaps in a few days) we can talk further, ok?
 941 2012-05-07 14:24:04 zooko has quit (Ping timeout: 272 seconds)
 942 2012-05-07 14:24:17 <Diapolo> no rush or hurry and thanks for your helping hand :)
 943 2012-05-07 14:25:32 <jgarzik> Diapolo: what do you need to know about fallocate?
 944 2012-05-07 14:25:49 <jgarzik> Diapolo: what are you trying to do?
 945 2012-05-07 14:26:11 <jgarzik> Diapolo: it is almost always easier, and more portable, to simply write zeroes to a file
 946 2012-05-07 14:26:46 sneak has joined
 947 2012-05-07 14:26:46 sneak has quit (Changing host)
 948 2012-05-07 14:26:46 sneak has joined
 949 2012-05-07 14:27:42 <Diapolo> jgarzik: I want to pre-allloc the space needed for the blk000x.dat files ... I have a patch that does this for Windows (experimental) and would like to add it for other Systems aswell.
 950 2012-05-07 14:28:55 <drizztbsd> why do you want to pre-allocate?
 951 2012-05-07 14:29:13 fiddur has quit (Quit: Leaving.)
 952 2012-05-07 14:30:03 <Diapolo> to have that file in 1 fragment
 953 2012-05-07 14:30:13 <jgarzik> drizztbsd: slow growing files are the worst use case for fragmentation
 954 2012-05-07 14:30:26 <drizztbsd> not if you are using ssd :P
 955 2012-05-07 14:30:37 <jgarzik> drizztbsd: yes, even if you use an ssd
 956 2012-05-07 14:30:41 <Diapolo> I dont consider SSD standard!
 957 2012-05-07 14:30:48 <jgarzik> irrelevant
 958 2012-05-07 14:31:02 <jgarzik> an SSD must still churn out more ATA commands, more interrupts, more completions
 959 2012-05-07 14:32:44 <jgarzik> Diapolo: posix_fallocate() must necessarily degenerate to writing zeros inside libc -- if not downright failure
 960 2012-05-07 14:33:27 graingert has joined
 961 2012-05-07 14:33:36 Glasswalker has joined
 962 2012-05-07 14:35:37 <Diapolo> jgarzik: I read about filesystems that support quick pre-allocation, so that no zeroes need to be written to that space.
 963 2012-05-07 14:35:56 <jgarzik> Diapolo: yes
 964 2012-05-07 14:36:02 <Diapolo> jgarzik: I even don't know if its an idea that will work on non Windows systems ... as I'm a pure Win user
 965 2012-05-07 14:36:35 <jgarzik> Diapolo: some filesystems do support it on non-Windows...  and some do not.  thus, you must be prepared to handle the "they do not" case.
 966 2012-05-07 14:36:59 <Diapolo> jgarzik: sure that needs to be added and taken into coding considerations
 967 2012-05-07 14:37:08 * helo wonders why he has been stuck on block 145657 for ~35 min
 968 2012-05-07 14:37:09 <Diapolo> Currently I started with this here: https://github.com/Diapolo/bitcoin/commit/183e99e7c77b52e8394f6c456d9ec53ea7f4bdb6
 969 2012-05-07 14:37:10 <sipa> is there any reason to not just write zeroes?
 970 2012-05-07 14:37:21 <sipa> hahuang65: which version?
 971 2012-05-07 14:37:23 <Diapolo> sipa: that takes a long time for 2GB file
 972 2012-05-07 14:37:28 <helo> sipa: 0.6.1
 973 2012-05-07 14:37:50 <helo> bitcoin-qt_0.6.1-precise0_amd64.deb
 974 2012-05-07 14:38:08 <sipa> helo: mind sending your debug.log file?
 975 2012-05-07 14:38:19 <helo> where to?
 976 2012-05-07 14:38:23 <sipa> pastebin?
 977 2012-05-07 14:38:38 <sipa> or pieter dot wuille at gmail dot com
 978 2012-05-07 14:38:40 <gmaxwell> helo: I assume this is syncing up a new node?
 979 2012-05-07 14:38:44 <gmaxwell> ;;tslb
 980 2012-05-07 14:38:44 <gribble> Error: "tslb" is not a valid command.
 981 2012-05-07 14:38:47 <gmaxwell> ;;bc,tslb
 982 2012-05-07 14:38:48 <gribble> Time since last block: 46 minutes and 48 seconds
 983 2012-05-07 14:38:54 <sipa> ah
 984 2012-05-07 14:38:55 <helo> gmaxwell: yes
 985 2012-05-07 14:39:02 <sipa> right, that doesn't mean much
 986 2012-05-07 14:39:13 <sipa> the node you were downloading from can just have gone offline
 987 2012-05-07 14:39:15 <gmaxwell> I think that behavior is not surprising. If the node you are initially pulling from goes away you won't start pulling again until the next block.
 988 2012-05-07 14:39:17 <jgarzik> Diapolo: first off, posix_fallocate() takes a file descriptor, not a FILE*.  So, fileno(hFile) not hFile
 989 2012-05-07 14:39:32 <jgarzik> posix_fallocate() will pause for a LONG TIME if the underlying fs does not support
 990 2012-05-07 14:39:38 <gmaxwell> (we should probably change that behavior...)
 991 2012-05-07 14:39:39 zooko has joined
 992 2012-05-07 14:41:09 <Diapolo> jgarzik: thanks that's the first fix ^^ it was just a quick write down and is no official pull
 993 2012-05-07 14:41:38 <Diapolo> jgarzik: How could I determine if the FS supports quick pre-alloc?
 994 2012-05-07 14:41:51 <sipa> Diapolo: i doubt you can
 995 2012-05-07 14:41:57 <jgarzik> Diapolo: it is difficult
 996 2012-05-07 14:42:09 <sipa> Diapolo: i wonder, if you can't build for windows, how do you test it yourself?
 997 2012-05-07 14:42:27 <jgarzik> sipa: anything is -possible- ;)  fallocate (not posix_fallocate) will return EOPNOTSUPP on Linux
 998 2012-05-07 14:42:43 <Diapolo> I can build on WIndows but not statically linked, so I can't redistribute builds.
 999 2012-05-07 14:42:51 <Diapolo> sipa: they only run on my machine then
1000 2012-05-07 14:43:26 <sipa> hmm, ok
1001 2012-05-07 14:44:16 <Diapolo> sipa: I could not figure out how to do this as it seems it's a mess with Qt on Windows, so I don't investigated further.
1002 2012-05-07 14:44:18 KoKo360 has quit (Read error: Connection reset by peer)
1003 2012-05-07 14:44:23 <helo> too big for pastebin... helo.org/debug.log
1004 2012-05-07 14:44:56 <sipa> helo: right, i was too fast; just wait for a new block first
1005 2012-05-07 14:45:05 <helo> oh, yep there it goes
1006 2012-05-07 14:45:10 <sipa> ;;bc,tslb
1007 2012-05-07 14:45:11 <gribble> Time since last block: 3 minutes and 49 seconds
1008 2012-05-07 14:45:14 <sipa> if it remains stalled, you may have an interesting situation
1009 2012-05-07 14:45:44 bitvampire has joined
1010 2012-05-07 14:47:12 <Diapolo> jgarzik: If you are interested in helping me with this that would be rather cool, do you think it's worth to pursuit that idea or do you consider it worthless for the client?
1011 2012-05-07 14:47:54 <sipa> Diapolo: i like the idea of preallocation, but it'd do it a bit more incrementally
1012 2012-05-07 14:48:06 <sipa> like adding blocks of 100MiB
1013 2012-05-07 14:48:11 zooko has quit (Read error: Connection reset by peer)
1014 2012-05-07 14:48:16 zooko has joined
1015 2012-05-07 14:48:16 <gmaxwell> esp jumping 2 more gb when it adds a second block file would be bad.
1016 2012-05-07 14:48:24 <jgarzik> Diapolo: sipa has the right idea
1017 2012-05-07 14:48:26 <Diapolo> it does not do it
1018 2012-05-07 14:48:34 <jgarzik> initial block download shouldn't be too bad, WRT fragmentation
1019 2012-05-07 14:48:38 <Diapolo> it creates another one if our limit is reached
1020 2012-05-07 14:48:41 <jgarzik> it's the slow-growing afterwards that hurts
1021 2012-05-07 14:48:57 <jgarzik> even 4MB at a time would be highly useful
1022 2012-05-07 14:50:32 <Diapolo> I tried the code with 64MB block files and that worked ... I would like to get the base running on non Win-Systems, the values can be tuned then.
1023 2012-05-07 14:51:16 <jgarzik> the main bitcoin change, IMO, would be to avoid appending to the end of the file, but rather at a file position of our choice
1024 2012-05-07 14:51:33 <sipa> jgarzik: that's what Diapolo's branch does
1025 2012-05-07 14:52:11 <jgarzik> so
1026 2012-05-07 14:52:21 <jgarzik> I don't see any need for preallocate, vs. writing zeroes
1027 2012-05-07 14:52:21 <Diapolo> and I used std::fstream
1028 2012-05-07 14:52:37 <jgarzik> writing 4MB of zeroes is easy, quick and highly portable
1029 2012-05-07 14:52:48 <Diapolo> and harmfull to SSDs
1030 2012-05-07 14:52:54 <jgarzik> hardly
1031 2012-05-07 14:53:13 <Diapolo> the more you do this the more write/erase cycles are eaten
1032 2012-05-07 14:53:25 <Diapolo> but that's another problem ^^
1033 2012-05-07 14:53:42 <jgarzik> Diapolo: run the numbers..  it is clearly lost in the noise
1034 2012-05-07 14:53:52 <jgarzik> _one_ preallocation is nothing
1035 2012-05-07 14:54:15 TD has joined
1036 2012-05-07 14:55:26 <Diapolo> for a 2GB file with adding 4MB chunks that would be 512 cycles vs. 0 for a big file and perhaps 512 fragments vs. a single one
1037 2012-05-07 14:55:37 <Diapolo> you are right, the cycles are of no harm really
1038 2012-05-07 14:56:39 RainbowDashh has joined
1039 2012-05-07 14:57:51 <sipa> i wonder what the performance difference is between 4 and 64 MiB blocks
1040 2012-05-07 14:58:41 <sipa> because compared to 1.7 GiB diskspace used by the blockchain, 0.064 GiB is negligable
1041 2012-05-07 14:59:03 erle- has quit (Quit: erle-)
1042 2012-05-07 14:59:11 <sipa> excuse me, 0.0625 GiB ;)
1043 2012-05-07 15:00:24 <Diapolo> sipa: :-P
1044 2012-05-07 15:01:18 <sipa> writing 64 MiB of zeroes may of course already cause some UI sluggishness
1045 2012-05-07 15:02:21 <Diapolo> I really dislike that zero-writing. Writing nothing just to allocate diskspace seems to be not a good style.
1046 2012-05-07 15:02:47 <jgarzik> quite the opposite.  it is (a) simple and (b) works everywhere, guaranteed.
1047 2012-05-07 15:03:05 <jgarzik> preallocate(), instead, requires arcane filesystem support that may or may not exist
1048 2012-05-07 15:03:08 <sipa> it's not the most efficient solution, but it is certainly the easiest and most portable one
1049 2012-05-07 15:03:22 <Diapolo> on Windows it's easy and guaranteed to work ^^
1050 2012-05-07 15:03:31 <jgarzik> if it does not exist, you _must_ handle the writing zeroes case _anyway_, either explicitly or implicitly
1051 2012-05-07 15:03:49 <sipa> to be honest, i don't mind having a #ifdef WIN32 block there
1052 2012-05-07 15:04:17 <Diapolo> I understand that portable aspect, too ... but I would also say nothing agains something that is possible easy on Linux and not on Win.
1053 2012-05-07 15:04:39 <Diapolo> So have the best of both worlds and a working portable base.
1054 2012-05-07 15:05:39 fahadsadah has quit (Ping timeout: 245 seconds)
1055 2012-05-07 15:05:39 dstien has quit (Ping timeout: 245 seconds)
1056 2012-05-07 15:06:34 dstien has joined
1057 2012-05-07 15:07:04 <Diapolo> I'll leave for now, bye.
1058 2012-05-07 15:07:24 Diapolo has quit (Quit: Page closed)
1059 2012-05-07 15:09:46 bitvampire has quit (Remote host closed the connection)
1060 2012-05-07 15:10:55 _Fireball has quit (Read error: Connection reset by peer)
1061 2012-05-07 15:11:16 RainbowDashh has quit (Quit: RainbowDashh)
1062 2012-05-07 15:11:53 _Fireball has joined
1063 2012-05-07 15:12:10 fahadsadah has joined
1064 2012-05-07 15:15:36 towerr has joined
1065 2012-05-07 15:15:36 tower has quit (Disconnected by services)
1066 2012-05-07 15:15:36 towerr has quit (Changing host)
1067 2012-05-07 15:15:36 towerr has joined
1068 2012-05-07 15:15:45 towerr is now known as tower
1069 2012-05-07 15:16:00 dvide has joined
1070 2012-05-07 15:16:57 RainbowDashh has joined
1071 2012-05-07 15:17:14 t7 has quit (Ping timeout: 276 seconds)
1072 2012-05-07 15:20:39 <gribble> New news from bitcoinrss: rebroad opened issue 1217 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1217>
1073 2012-05-07 15:24:45 TD has quit (Quit: TD)
1074 2012-05-07 15:25:07 Joric_ has joined
1075 2012-05-07 15:25:07 Joric_ has quit (Changing host)
1076 2012-05-07 15:25:07 Joric_ has joined
1077 2012-05-07 15:25:49 Joric has quit (Ping timeout: 252 seconds)
1078 2012-05-07 15:27:02 toffoo has joined
1079 2012-05-07 15:28:12 gavinandresen has joined
1080 2012-05-07 15:29:40 RainbowDashh has quit (Quit: RainbowDashh)
1081 2012-05-07 15:33:27 BTC_Bear is now known as hbrntng!~BTC_Bear@unaffiliated/btc-bear/x-5233302|BTC_Bear
1082 2012-05-07 15:36:30 DiabloD3 has joined
1083 2012-05-07 15:40:03 t7 has joined
1084 2012-05-07 15:52:10 paul0 has joined
1085 2012-05-07 15:57:38 TD has joined
1086 2012-05-07 16:05:35 Turingi has joined
1087 2012-05-07 16:05:37 Turingi has quit (Changing host)
1088 2012-05-07 16:05:37 Turingi has joined
1089 2012-05-07 16:06:16 b4epoche_ has quit (Ping timeout: 252 seconds)
1090 2012-05-07 16:07:56 sneak has quit (Ping timeout: 272 seconds)
1091 2012-05-07 16:08:11 sneak has joined
1092 2012-05-07 16:08:47 b4epoche_ has joined
1093 2012-05-07 16:09:36 toffoo has quit (Ping timeout: 244 seconds)
1094 2012-05-07 16:10:32 Joric has joined
1095 2012-05-07 16:10:35 Joric has quit (Changing host)
1096 2012-05-07 16:10:35 Joric has joined
1097 2012-05-07 16:11:01 zooko has quit (Read error: Connection reset by peer)
1098 2012-05-07 16:11:20 zooko has joined
1099 2012-05-07 16:11:47 Joric has quit (Client Quit)
1100 2012-05-07 16:12:02 ThomasV has joined
1101 2012-05-07 16:12:22 Joric_ has quit (Ping timeout: 255 seconds)
1102 2012-05-07 16:13:58 toffoo has joined
1103 2012-05-07 16:16:29 drizztbsd has quit (Ping timeout: 245 seconds)
1104 2012-05-07 16:17:34 drizztbsd has joined
1105 2012-05-07 16:22:19 ThomasV has quit (Ping timeout: 260 seconds)
1106 2012-05-07 16:24:22 gasteve has joined
1107 2012-05-07 16:29:28 barmstrong has quit (Ping timeout: 272 seconds)
1108 2012-05-07 16:30:54 barmstrong has joined
1109 2012-05-07 16:32:44 jarkinox has joined
1110 2012-05-07 16:32:47 cdecker has quit (Quit: Leaving.)
1111 2012-05-07 16:33:22 jarkinox has quit (Client Quit)
1112 2012-05-07 16:33:30 Joric has joined
1113 2012-05-07 16:35:13 <jgarzik> hmmmmm
1114 2012-05-07 16:36:51 <jgarzik> can someone refresh my memory on what happens if two wallets both hold the same private key?  i.e. for redundancy, site A and site B both maintain the same list of private keys.  site A spends some coins, broadcasting the TX to all (including site B).  will bitcoind running on site B properly handle all that?
1115 2012-05-07 16:38:22 <gavinandresen> mostly.  If site B decides to spend using that private key before it sees A's transaction you can end up with a will-never-be-confirmed transaction, if I recall correctly
1116 2012-05-07 16:40:39 <t7> jgarzik: its worked fine for me, i share a wallet at home and at work
1117 2012-05-07 16:41:09 <luke-jr> t7: that's a bad idea for other reasons btw :p
1118 2012-05-07 16:41:16 <luke-jr> they'll fork eventually
1119 2012-05-07 16:42:08 RainbowDashh has joined
1120 2012-05-07 16:42:18 RainbowDashh has quit (Remote host closed the connection)
1121 2012-05-07 16:42:45 <jgarzik> gavinandresen: yeah, I can work to prevent that
1122 2012-05-07 16:42:50 <sipa> gavinandresen is right
1123 2012-05-07 16:43:09 <jgarzik> my software would necessarily have to deal with private key distribution
1124 2012-05-07 16:43:34 <jgarzik> and any issues that may arise thereof from poor/corrupted/improper/delayed distribution
1125 2012-05-07 16:43:45 <sipa> jgarzik: i once made a rejectedtx branch, that kept two extra booleans per transaction, one whether it's active, and one whether it's in conflict with the blockchain
1126 2012-05-07 16:43:53 <sipa> i should rewrite it
1127 2012-05-07 16:44:03 <sipa> that could detect and recover from such cases
1128 2012-05-07 16:44:04 <gavinandresen> if you sync newly generated keypool keys often enough and you only spend from one at time and never switch from one to another if you have 0-confirmation spends...
1129 2012-05-07 16:44:08 * luke-jr thinks bitcoind should show negative confirmations for every block in conflict
1130 2012-05-07 16:44:16 <sipa> luke-jr: indeed
1131 2012-05-07 16:44:24 * jgarzik is trying to design a bit of a "bitcoin cloud"
1132 2012-05-07 16:44:45 * zooko perks up
1133 2012-05-07 16:44:50 * jgarzik is generating and maintaining private keys outside of bitcoin, and then importing for actual use
1134 2012-05-07 16:45:11 <jgarzik> let bitcoind do the heavy lifting
1135 2012-05-07 16:45:12 <luke-jr> jgarzik: kindof like My Wallet, but p2p?
1136 2012-05-07 16:45:27 <jgarzik> not peer to peer, tightly integrated cloud controlled by me
1137 2012-05-07 16:45:27 minimoose has joined
1138 2012-05-07 16:45:34 <luke-jr> i c
1139 2012-05-07 16:45:37 <jgarzik> distributed computing, yes
1140 2012-05-07 16:45:53 <luke-jr> so a My Wallet clone? <.<
1141 2012-05-07 16:46:00 <jgarzik> trying to design a service that doesn't rely on a single bitcoind wallet
1142 2012-05-07 16:46:20 TD has quit (Quit: TD)
1143 2012-05-07 16:46:27 <jgarzik> a resilient design should handle a single "virtual" wallet shared across multiple bitcoind's, IOW
1144 2012-05-07 16:46:30 * t7 forgot to mention that he never spends from work
1145 2012-05-07 16:46:56 barmstrong has quit (Ping timeout: 276 seconds)
1146 2012-05-07 16:47:50 <jgarzik> I can guarantee that site B will never spend coin 1234, if site A has already spent coin 1234
1147 2012-05-07 16:48:00 danbri has quit (Read error: Connection reset by peer)
1148 2012-05-07 16:48:14 <jgarzik> but site B might see a TX before it receives new private keys
1149 2012-05-07 16:48:18 danbri has joined
1150 2012-05-07 16:49:02 <sipa> won't be a problem
1151 2012-05-07 16:50:09 bob12321 has quit (Ping timeout: 252 seconds)
1152 2012-05-07 16:51:22 <sipa> jgarzik: would a deterministic wallet help?
1153 2012-05-07 16:51:38 sneak has quit (Ping timeout: 272 seconds)
1154 2012-05-07 16:52:48 <jgarzik> sipa: perhaps marginally.  the underlying assumption i must make is that any one or two bitcoind's may die or get stuck, but my distributed bitcoin engine needs to continue processing transactions for customers regardless.  most of the logic occurs at a higher level.
1155 2012-05-07 16:54:12 _W_ has quit (Excess Flood)
1156 2012-05-07 16:54:14 <jgarzik> keys generated by a distributed, component-can-fail system, stored in a distributed filesystem, etc.  those are fed to downstream bitcoind's, which import the keys and assist in watching for transactions, and creating new transactions
1157 2012-05-07 16:54:23 _W_ has joined
1158 2012-05-07 16:55:00 TD has joined
1159 2012-05-07 16:55:32 <jgarzik> being p2p, a cluster of bitcoind's is wonderfully resilient to failure anyway
1160 2012-05-07 16:56:01 <jgarzik> so the main issue is keeping the wallets sync'd (or really, just "not confused")
1161 2012-05-07 16:56:50 Nicksasa has joined
1162 2012-05-07 16:56:55 barmstrong has joined
1163 2012-05-07 16:57:03 barmstrong has quit (Remote host closed the connection)
1164 2012-05-07 16:58:14 sneak has joined
1165 2012-05-07 16:58:15 bob12321 has joined
1166 2012-05-07 17:00:43 <luke-jr> jgarzik: HD wallets would keep them in sync without any direct communication or controller
1167 2012-05-07 17:01:05 <gavinandresen> jgarzik sipa : I want to start a Bitcoin Testing Project organization to accept donations and then fund QA, testing tools, etc.  And maybe vulnerability bounties.
1168 2012-05-07 17:01:59 <zooko> gavinandresen: neat idea!
1169 2012-05-07 17:02:21 <gavinandresen> And I'm thinking of doing something slightly crazy and using bettermeans.com  to make it a non-traditional, distributed organization....
1170 2012-05-07 17:02:49 paul0 has quit (Quit: paul0)
1171 2012-05-07 17:02:51 <jgarzik> gavinandresen: I want to start a Bitcoin Network Maintenance and Monitoring org to accept donatoins, then fund nodes and seeds
1172 2012-05-07 17:03:06 <jgarzik> and real time network metrics and alert
1173 2012-05-07 17:03:28 <jgarzik> luke-jr: HD?
1174 2012-05-07 17:04:13 <gavinandresen> jgarzik: good idea!
1175 2012-05-07 17:04:38 <jgarzik> an org devoted to operational network health
1176 2012-05-07 17:04:56 <denisx> can someone connect his bitcoind to 195.160.173.3
1177 2012-05-07 17:05:15 <jgarzik> anyway, babysitting time ("quiet time" -> "nap time", hopefully)
1178 2012-05-07 17:05:26 <gavinandresen> we've got the same goals-- i want proactive testing so the network stays healthy (and i see the testing project as focusing on cross-implementation issues/tools)
1179 2012-05-07 17:05:32 <zooko> Enjoy babysitting!
1180 2012-05-07 17:05:43 <luke-jr> jgarzik: sipa's Hierarchial Deterministic wallets :p
1181 2012-05-07 17:06:48 <Joric> i'll implement those in js ) already tested hmac-sha512 works just fine
1182 2012-05-07 17:09:37 <luke-jr> gavinandresen: so what's up with 0.6.2? tagging?
1183 2012-05-07 17:10:11 <luke-jr> I made some Windows builds at http://luke.dashjr.org/programs/bitcoin/files/bitcoind/0.6.2/test/rc1/ if more testing is desired
1184 2012-05-07 17:10:33 <gavinandresen> luke-jr: just "soak" testing-- I've been running the fixes on three machines since yesterday (including the Faucet, which gets lots of connections)
1185 2012-05-07 17:12:20 zooko has quit (Quit: bbiab)
1186 2012-05-07 17:12:37 theorbtwo has quit (Ping timeout: 260 seconds)
1187 2012-05-07 17:12:45 <luke-jr> gavinandresen: ping me if you want me to do another gitian build when you tag it (fyi, I think sipa and BlueMatt are gitian-down atm)
1188 2012-05-07 17:12:46 <luke-jr> bbl
1189 2012-05-07 17:13:52 occulta has joined
1190 2012-05-07 17:16:16 <sipa> i can do gitian builds
1191 2012-05-07 17:16:46 <sipa> gavinandresen: the stuck download fix fix seems to need another fix, btw...
1192 2012-05-07 17:16:54 theorbtwo has joined
1193 2012-05-07 17:17:34 guruvan has quit (Quit: I probably voided the warranty on this thing.....)
1194 2012-05-07 17:18:16 <gavinandresen> sipa: ok.  Now I'm regretting including it in the 0.6.2 cherry-picks....
1195 2012-05-07 17:19:05 guruvan has joined
1196 2012-05-07 17:20:52 <gmaxwell> meh, it's an important fix. ... if it were right. I've got a user sending me a stuck chain to test on today.
1197 2012-05-07 17:27:02 Clipse has joined
1198 2012-05-07 17:33:31 <DiabloD3> [01:02:21] <jgarzik> an org devoted to operational network health
1199 2012-05-07 17:33:50 <DiabloD3> jgarzik: make bitcoin run on alpine and Ill run a perm supernode.
1200 2012-05-07 17:33:54 <DiabloD3> for free.
1201 2012-05-07 17:38:08 p0s has joined
1202 2012-05-07 17:39:16 <Graet> will p2pool orphaning thier own blocks become an issue as p2pool grows? http://blockchain.info/
1203 2012-05-07 17:39:53 <DiabloD3> Graet: well, this is one of the reasons I want to run a bitcoin supernode
1204 2012-05-07 17:40:11 <Graet> so yes?
1205 2012-05-07 17:41:42 <gmaxwell> Graet: no.
1206 2012-05-07 17:41:49 <gmaxwell> Graet: has nothing to do with p2pool's size.
1207 2012-05-07 17:42:01 <DiabloD3> p2pool would have to be the size of bitcoin for it to be an issue I think
1208 2012-05-07 17:42:08 <gmaxwell> DiabloD3: nope.
1209 2012-05-07 17:42:18 <DiabloD3> gmaxwell: well, blocks are orphaned periodically
1210 2012-05-07 17:42:25 <DiabloD3> if we do all the hashing, we get all the orphans.
1211 2012-05-07 17:42:47 <forrestv> no more than everyone would if everyone were solo mining
1212 2012-05-07 17:42:51 <gmaxwell> Well sure, but there isn't any special p2pool orphan vulnerability (except perhaps due to bugs)
1213 2012-05-07 17:43:03 <Graet> well as p2pool grows the potential to orphan thier own blocks must also grow?
1214 2012-05-07 17:43:30 <Graet> due to lots of nodes working "independently" but "together"
1215 2012-05-07 17:43:34 <gmaxwell> Graet: any normal pool running multiple bitcoin daemons has the same risk.
1216 2012-05-07 17:43:57 <DiabloD3> yeah what gmaxwell said
1217 2012-05-07 17:44:07 <Graet> i understand gmaxwell - we run 2, but the chance of 2 versus ?p2pool nodes?
1218 2012-05-07 17:44:10 <gmaxwell> (and p2pool in theory has low overhead node to node block communication, since p2pool nodes can realy inside p2pool with less validation overhead)
1219 2012-05-07 17:44:15 graingert has quit (Read error: Connection reset by peer)
1220 2012-05-07 17:44:40 barmstrong has joined
1221 2012-05-07 17:44:42 <Graet> ok, well i will watch with interest :)
1222 2012-05-07 17:44:49 barmstrong has quit (Remote host closed the connection)
1223 2012-05-07 17:45:11 <gmaxwell> Graet: fair enough.
1224 2012-05-07 17:45:20 barmstrong has joined
1225 2012-05-07 17:45:28 <Graet> :)
1226 2012-05-07 17:46:31 <gmaxwell> sipa: I've got another stuck block victim, this user at
1227 2012-05-07 17:46:38 <gmaxwell> 176947.
1228 2012-05-07 17:46:53 <gmaxwell> sipa: have a gitian build of your fix with the break?
1229 2012-05-07 17:49:49 TimothyA has joined
1230 2012-05-07 17:50:07 <nanotube> and btw, did i mention that i really like the 'blocks remaining' progress bar a lot better than the % bar, in 0.6.1? :)
1231 2012-05-07 17:51:09 <DiabloD3> nanotube: they fixed that?
1232 2012-05-07 17:51:10 <DiabloD3> I should upgrade
1233 2012-05-07 17:51:22 <gmaxwell> DiabloD3: wait until you see the integrated console.
1234 2012-05-07 17:51:25 <nanotube> yes, the progress bar doesn't suck now. :)
1235 2012-05-07 17:51:39 <nanotube> wait, what's that about integrated console? is that in .1?
1236 2012-05-07 17:51:45 <gmaxwell> I'm still sad it doesn't work like quake— type ` and an overlay scrolls down over the cliemt.
1237 2012-05-07 17:51:49 <TimothyA> I was wondering if it is possible to send bitcoins while offline; as long as one party is online
1238 2012-05-07 17:51:59 <gmaxwell> nanotube: it'll be pulled as soon as we cut 0.6.2
1239 2012-05-07 17:52:06 <nanotube> ah i c gmaxwell :)
1240 2012-05-07 17:52:20 <nanotube> TimothyA: yes you can receive coins if you're not online
1241 2012-05-07 17:52:27 <TimothyA> nanotube: *send* :P
1242 2012-05-07 17:52:29 <nanotube> you can't send them without connecting to the network though of course :)
1243 2012-05-07 17:52:40 <nanotube> i mean, you could snail-mail the transaction data to your recipient
1244 2012-05-07 17:52:40 <gmaxwell> You can also send while you're offline .. but they don't go anywhere until you're back on!
1245 2012-05-07 17:52:47 <gmaxwell> or that.
1246 2012-05-07 17:52:50 <nanotube> heh
1247 2012-05-07 17:52:52 <TimothyA> hmm... and there are no other ways to faciliate that for in-person transactions?
1248 2012-05-07 17:53:14 <gmaxwell> TimothyA: at some point we'll have the ability to make a txn and export it.. then the online node could import it.
1249 2012-05-07 17:53:22 <gmaxwell> BIP10 describes a text format for the exports.
1250 2012-05-07 17:53:31 <TimothyA> that would be desirable
1251 2012-05-07 17:53:43 <TimothyA> just text? not as QR as well?
1252 2012-05-07 17:53:46 <gmaxwell> (primary usecase for us is so you can have a wallet which is _never_ connected to the internet)
1253 2012-05-07 17:54:09 <gmaxwell> well, it's too much data for a small QR code... but I guess it could fit in the bigger ones.
1254 2012-05-07 17:54:59 <TimothyA> should fit on a regular mobile phone's scree
1255 2012-05-07 17:55:01 <TimothyA> n
1256 2012-05-07 17:55:01 ThomasV has joined
1257 2012-05-07 17:55:12 <denisx> I used bisect to hunt down the 100% cpu hogging
1258 2012-05-07 17:55:17 <denisx> here is what I found: http://pastebin.com/xAEYuyRW
1259 2012-05-07 17:55:50 <sipa> denisx: ow...
1260 2012-05-07 17:56:38 <gmaxwell> denisx: it would still be very good to know what line it was spending time at.
1261 2012-05-07 17:57:39 <sipa> gmaxwell: not yet, i was experimenting with it a bit first
1262 2012-05-07 17:59:19 <gmaxwell> sipa: when you've got something you're happy with point me at builds and I will pass them on to the victims I've collected for you.
1263 2012-05-07 17:59:40 ThomasV has quit (Client Quit)
1264 2012-05-07 18:00:34 <gmaxwell> This latest victim is on win XP, always on node, stuck at 176947 with 0.6.1 now, was on 0.6.0 previously— and it's been stuck there for 13 days.
1265 2012-05-07 18:02:18 sytse_ has joined
1266 2012-05-07 18:02:50 sytse has quit (Disconnected by services)
1267 2012-05-07 18:02:55 sytse_ is now known as sytse
1268 2012-05-07 18:12:09 zooko has joined
1269 2012-05-07 18:12:49 danbri_ has joined
1270 2012-05-07 18:13:56 tyn has joined
1271 2012-05-07 18:15:06 brocktice has quit (Remote host closed the connection)
1272 2012-05-07 18:15:07 tyn has quit (Read error: Connection reset by peer)
1273 2012-05-07 18:16:42 danbri has quit (Ping timeout: 244 seconds)
1274 2012-05-07 18:19:11 <gavinandresen> Right:  damn the torpedoes, full steam ahead, the Bitcoin Testing Project is looking for members:  https://bitcointalk.org/index.php?topic=80019.0
1275 2012-05-07 18:26:33 paraipan has joined
1276 2012-05-07 18:29:09 Z0rZ0rZ0r has joined
1277 2012-05-07 18:32:35 Joric has quit ()
1278 2012-05-07 18:41:48 guruvan has quit (Quit: I probably voided the warranty on this thing.....)
1279 2012-05-07 18:48:31 jgarzik has left ("Client exiting")
1280 2012-05-07 18:48:47 p0s has quit (Remote host closed the connection)
1281 2012-05-07 18:49:24 jgarzik has joined
1282 2012-05-07 18:49:38 <jgarzik> very strange
1283 2012-05-07 18:50:20 drizztbsd has quit (Ping timeout: 245 seconds)
1284 2012-05-07 18:51:10 Zarutian has quit (Ping timeout: 248 seconds)
1285 2012-05-07 18:55:02 bitfoo has quit (Quit: ZNC - http://znc.in)
1286 2012-05-07 18:56:39 Zarutian has joined
1287 2012-05-07 19:00:09 <gribble> New news from bitcoinrss: luke-jr opened issue 1218 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1218>
1288 2012-05-07 19:00:45 minimoose has quit (Quit: minimoose)
1289 2012-05-07 19:01:47 rdponticelli has joined
1290 2012-05-07 19:04:01 anonyminer has joined
1291 2012-05-07 19:04:07 <anonyminer> Hi
1292 2012-05-07 19:04:14 <anonyminer> I need help urgently
1293 2012-05-07 19:04:45 <anonyminer> Bitcoin isn't working since new update
1294 2012-05-07 19:05:07 <gmaxwell> anonyminer: Define not working?
1295 2012-05-07 19:05:21 <anonyminer> Ok I have the error one sec
1296 2012-05-07 19:05:39 <gavinandresen> (I predict DB_RUNRECOVERY....)
1297 2012-05-07 19:05:42 <anonyminer> Runaway Exception
1298 2012-05-07 19:06:04 <anonyminer> A Fatal Error Occured
1299 2012-05-07 19:06:28 <anonyminer> EXCEPTION: 11DbException
1300 2012-05-07 19:06:49 <anonyminer> Db::get: Not enought space
1301 2012-05-07 19:07:02 AsymmetricInfo has joined
1302 2012-05-07 19:07:11 <luke-jr> anonyminer: sounds like you're out of disk space
1303 2012-05-07 19:07:21 t7 has quit (Ping timeout: 276 seconds)
1304 2012-05-07 19:07:21 <anonyminer> nah I have 90 GB Free
1305 2012-05-07 19:07:22 <anonyminer> :P
1306 2012-05-07 19:07:44 <gmaxwell> I think I've seen corrupt addr.dat cause that.
1307 2012-05-07 19:08:25 <anonyminer> does this mean I lost all my coins :(
1308 2012-05-07 19:08:53 <gmaxwell> anonyminer: No. Thats quite unlikely.
1309 2012-05-07 19:09:10 <gmaxwell> First, make a new backup of your appdata directory.
1310 2012-05-07 19:09:27 <anonyminer> Ok :)
1311 2012-05-07 19:12:02 <gmaxwell> After than try deleting the addr.dat file and restarting.
1312 2012-05-07 19:12:51 <anonyminer> blkindex.dat failed to load at first so I backed it up and Bitcoin loaded after that than it started to download the blkindex.dat again and I don't know why it won't open now,,, says Unconfirmed Bitcoins
1313 2012-05-07 19:12:52 <gribble> Error: "," is not a valid command.
1314 2012-05-07 19:13:40 <anonyminer> same error as before after deleting addr.dat
1315 2012-05-07 19:13:41 <anonyminer> :(
1316 2012-05-07 19:14:19 <gmaxwell> okay, so this time shut down and delete addr.dat blk001.dat and blkindex.dat.
1317 2012-05-07 19:14:41 <gmaxwell> Then restart.
1318 2012-05-07 19:14:42 minimoose has joined
1319 2012-05-07 19:14:58 toffoo has quit ()
1320 2012-05-07 19:15:44 <anonyminer> Ok its working now but this has already done this once than it says error blocks may be incorrect in the bottom why is this happening?
1321 2012-05-07 19:17:14 TD has quit (Quit: TD)
1322 2012-05-07 19:17:25 <gmaxwell> anonyminer: thats okay, it's just resyncing up with the network now. Is the block count progressin the lower right corner going up?
1323 2012-05-07 19:19:49 <anonyminer> yes
1324 2012-05-07 19:20:23 <anonyminer> But this already did this once and it wasn't showing my coins as confirmed :(
1325 2012-05-07 19:20:34 zooko has left ("#tahoe-lafs")
1326 2012-05-07 19:20:45 <gmaxwell> anonyminer: okay, it will take a little while to catch back up again— assuming you left your wallet.dat along you'll be perfectly fine when it craches back up (and it will then show your coins as confirmed)
1327 2012-05-07 19:23:54 imsaguy2 has joined
1328 2012-05-07 19:23:54 imsaguy2 has quit (Changing host)
1329 2012-05-07 19:23:54 imsaguy2 has joined
1330 2012-05-07 19:25:05 Sedra- is now known as Sedra
1331 2012-05-07 19:25:14 RazielZ has quit (Ping timeout: 245 seconds)
1332 2012-05-07 19:26:29 Sedra has quit (Quit: ( Quit ))
1333 2012-05-07 19:30:09 RazielZ has joined
1334 2012-05-07 19:30:38 <gribble> New news from bitcoinrss: luke-jr opened pull request 1219 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1219>
1335 2012-05-07 19:31:15 t7 has joined
1336 2012-05-07 19:37:52 Motest031 has joined
1337 2012-05-07 19:38:25 Motest003 has quit (Ping timeout: 240 seconds)
1338 2012-05-07 19:38:59 Raziel_ has joined
1339 2012-05-07 19:42:26 RazielZ has quit (Ping timeout: 245 seconds)
1340 2012-05-07 19:43:44 random_cat_ has quit (Ping timeout: 276 seconds)
1341 2012-05-07 19:45:03 random_cat_ has joined
1342 2012-05-07 19:47:09 datagutt has quit (Quit: kthxbai)
1343 2012-05-07 19:48:00 SphericalCow has joined
1344 2012-05-07 19:49:31 danbri has joined
1345 2012-05-07 19:52:50 Clipse has quit (Ping timeout: 276 seconds)
1346 2012-05-07 19:53:09 danbri_ has quit (Ping timeout: 245 seconds)
1347 2012-05-07 20:00:39 Sedra has joined
1348 2012-05-07 20:02:46 TD has joined
1349 2012-05-07 20:04:06 danbri has quit (Read error: Operation timed out)
1350 2012-05-07 20:04:52 danbri has joined
1351 2012-05-07 20:06:30 <gribble> New news from bitcoinrss: laanwj opened pull request 1220 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1220>
1352 2012-05-07 20:11:50 <t7> its still 'new news'
1353 2012-05-07 20:12:35 <sipa> yes?
1354 2012-05-07 20:18:28 <gmaxwell> sipa: got a trial binary yet?
1355 2012-05-07 20:19:38 minimoose has quit (Quit: minimoose)
1356 2012-05-07 20:20:29 <sipa> uploading!
1357 2012-05-07 20:21:07 <sipa> i added the creation of a "COMMITS" file to my build script
1358 2012-05-07 20:21:13 b4epoche_ has quit (Ping timeout: 244 seconds)
1359 2012-05-07 20:21:49 <gmaxwell> might be interesting to run diff `last tag`.
1360 2012-05-07 20:23:37 <sipa> http://bitcoin.sipa.be/builds/0.6.1-35-g1ec1702/
1361 2012-05-07 20:24:11 b4epoche_ has joined
1362 2012-05-07 20:25:10 danbri has quit (Remote host closed the connection)
1363 2012-05-07 20:28:52 sneak has quit (Ping timeout: 272 seconds)
1364 2012-05-07 20:39:04 <anonyminer> Seems like its frozen :(
1365 2012-05-07 20:39:22 <anonyminer> been sitting on block 73.30% Complete and its just sitting there
1366 2012-05-07 20:39:45 <anonyminer> 49617 Blocks Remaining :(
1367 2012-05-07 20:39:57 <sipa> for how long has it been stuck?
1368 2012-05-07 20:40:17 Z0rZ0rZ0r has quit (Ping timeout: 260 seconds)
1369 2012-05-07 20:44:05 <anonyminer> 1 Hour :(
1370 2012-05-07 20:44:20 <sipa> ;;bc,tslb
1371 2012-05-07 20:44:21 <gribble> Time since last block: 4 minutes and 41 seconds
1372 2012-05-07 20:44:27 <sipa> 0.6.1?
1373 2012-05-07 20:44:31 <anonyminer> yes'
1374 2012-05-07 20:45:08 <sipa> wait till a few more blocks have been generated; if it's still stuck: you may have hit a bug we're currently trying to fix
1375 2012-05-07 20:45:08 <luke-jr> sipa: he said it just *started* being a problem with 0.6.1
1376 2012-05-07 20:46:01 <gmaxwell> luke-jr: nah, his chain got corrupted during the upgrade. (my guess due to a unclean shutdown before the upgrade) his problems are on resync.
1377 2012-05-07 20:46:35 Z0rZ0rZ0r has joined
1378 2012-05-07 20:46:52 <anonyminer> Yes
1379 2012-05-07 20:47:31 <gmaxwell> ;bc,tslb
1380 2012-05-07 20:47:35 <anonyminer> I Closed it a now it won't open says blkindex.dat could not open
1381 2012-05-07 20:47:35 <gmaxwell> ;;bc,tslb
1382 2012-05-07 20:47:36 <gribble> Time since last block: 7 minutes and 57 seconds
1383 2012-05-07 20:48:57 <luke-jr> gmaxwell: see :p
1384 2012-05-07 20:49:13 danbri has joined
1385 2012-05-07 20:49:54 erle- has joined
1386 2012-05-07 20:50:07 <anonyminer> Error Loading blkindex.dat now Ok I deleted the blkindex.dat I am going to try for the third time to resync
1387 2012-05-07 20:50:55 <luke-jr> I'm starting to see why Windows tries to hide the filesystem from users.
1388 2012-05-07 20:51:28 toffoo has joined
1389 2012-05-07 20:51:54 <gmaxwell> anonyminer: I hope you were deleting blk0001.dat at the same time.
1390 2012-05-07 20:52:02 <jgarzik> luke-jr: if nothing else, android/iphone apps have proven the value of a very tightly controlled sandbox for each app
1391 2012-05-07 20:52:03 <gmaxwell> but this doesn't sounds like a productive path.
1392 2012-05-07 20:54:42 sneak has joined
1393 2012-05-07 20:54:42 sneak has quit (Changing host)
1394 2012-05-07 20:54:42 sneak has joined
1395 2012-05-07 20:55:15 <anonyminer> I did already the first time
1396 2012-05-07 20:55:24 <anonyminer> do I have to keep deleting it
1397 2012-05-07 20:57:02 <sipa> anonyminer: always delete blkindex.dat and blk0001.dat together
1398 2012-05-07 20:58:14 <sipa> (the first is an index into the second)
1399 2012-05-07 21:00:37 <jgarzik> really, "delete everything but wallet.dat" is surely the most simple, foolproof instruction
1400 2012-05-07 21:01:14 <luke-jr> "everything but" isn't foolproof ;)
1401 2012-05-07 21:01:23 <gmaxwell> jgarzik: and when wallet.dat is then unreadable because they deleted database/ and their last shutdown was unclean?
1402 2012-05-07 21:02:14 <sipa> if you delete blkindex.dat and blk0001.dat, but don't delete database/, there is a risk that they get recreated from the log files anyway, and then cause failure
1403 2012-05-07 21:02:40 <sipa> that may have been the problem here
1404 2012-05-07 21:03:04 <gmaxwell> :-/
1405 2012-05-07 21:03:09 <gmaxwell> Damned either way here.
1406 2012-05-07 21:03:19 graingert has joined
1407 2012-05-07 21:03:47 <gmaxwell> I've certantly seen wallets become totally unreadable from deleting database/ — and in the same case that would happen, except wallet is clean more of the time.
1408 2012-05-07 21:04:48 <anonyminer> can't I just create a brand new bitcoin folder and import my wallet to the bitcoin wallet?
1409 2012-05-07 21:05:12 <sipa> yes, you can
1410 2012-05-07 21:05:24 <sipa> assuming the client shut down cleanly
1411 2012-05-07 21:05:51 <sipa> (that's exactly identical to "remove everything except wallet.dat", by the way)
1412 2012-05-07 21:06:03 <luke-jr> anonyminer: just don't delete the old directory under any circumstances
1413 2012-05-07 21:06:07 <luke-jr> anonyminer: rename it
1414 2012-05-07 21:06:59 <gmaxwell> luke-jr: hopefully he made a backup at the start where I asked.
1415 2012-05-07 21:09:24 <jgarzik> gmaxwell: http://pybsddb.sourceforge.net/utility/db_recover.html
1416 2012-05-07 21:10:31 <jgarzik> gmaxwell: or 'db_dump -r'
1417 2012-05-07 21:11:04 <gmaxwell> jgarzik: indeed. that works.
1418 2012-05-07 21:14:00 <anonyminer> WARNING: Displayed Transaction may be Incorrect :(
1419 2012-05-07 21:14:14 <anonyminer> 71.56% Done
1420 2012-05-07 21:15:09 <anonyminer> Yes I did Make a Back like you asked bro :)
1421 2012-05-07 21:17:15 <anonyminer> I should of stayed at version 6.0 this is a Bug it has to be :(
1422 2012-05-07 21:17:28 <anonyminer> Its not working ever since I upgraded to 6.1
1423 2012-05-07 21:19:09 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
1424 2012-05-07 21:19:17 Glasswalker has quit (Ping timeout: 256 seconds)
1425 2012-05-07 21:21:49 <gmaxwell> anonyminer: it sounds like its working fine now.
1426 2012-05-07 21:22:55 Nicksasa has quit (Remote host closed the connection)
1427 2012-05-07 21:24:42 dusty_ has joined
1428 2012-05-07 21:32:31 tower has joined
1429 2012-05-07 21:38:22 <luke-jr> thinking about refactoring the priority code to include dependents and fees; how does this algo sound: priority = (inputs * ((confirms * confirmWeight) + (fee * feeWeight))) / size
1430 2012-05-07 21:39:05 <luke-jr> (in the case of dependents, the child-fees get added to the parent, and size includes them, whichever combination gives it the highest prio)
1431 2012-05-07 21:47:53 AsymmetricInfo has quit (Quit: Page closed)
1432 2012-05-07 21:48:00 <gmaxwell> whats the weight stuff?
1433 2012-05-07 21:55:01 <luke-jr> gmaxwell: user configurable
1434 2012-05-07 21:57:25 Snapman is now known as Snapman[afkers]
1435 2012-05-07 22:00:47 _Fireball has quit (Quit:  Try HydraIRC -> http://www.hydrairc.com <-)
1436 2012-05-07 22:03:03 occulta has quit (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/)
1437 2012-05-07 22:03:31 elkingrey has joined
1438 2012-05-07 22:03:35 agricocb has quit (Quit: Leaving.)
1439 2012-05-07 22:07:43 anonyminer has quit (Ping timeout: 245 seconds)
1440 2012-05-07 22:13:09 danbri has quit (Remote host closed the connection)
1441 2012-05-07 22:25:50 Z0rZ0rZ0r has quit (Disconnected by services)
1442 2012-05-07 22:25:50 Z0rZ0rZ0r1 has joined
1443 2012-05-07 22:43:26 Raziel_ has quit (Quit: Leaving)
1444 2012-05-07 22:45:56 sirk390 has quit (Quit: Leaving.)
1445 2012-05-07 22:49:56 agricocb has joined
1446 2012-05-07 22:51:13 Turingi has quit (Read error: Connection reset by peer)
1447 2012-05-07 22:52:12 BNCatDIGISHELL has quit (Ping timeout: 265 seconds)
1448 2012-05-07 22:54:04 BNCatDIGISHELL has joined
1449 2012-05-07 22:55:27 Clipse has joined
1450 2012-05-07 22:59:27 <splatster> Bitcoin-qt is using 30% CPU on a simple chain catchup.
1451 2012-05-07 23:00:58 <sipa> it should be 100%
1452 2012-05-07 23:01:05 <sipa> ideally
1453 2012-05-07 23:01:17 <sipa> if it's not, it means that network or disk are the bottleneck
1454 2012-05-07 23:01:29 RainbowDashh has joined
1455 2012-05-07 23:01:29 <splatster> Hmm, prolly my network.
1456 2012-05-07 23:01:41 <sipa> unlikely :)
1457 2012-05-07 23:01:54 <splatster> It keeps spiking up to 70s and 80s then back down to 30s.
1458 2012-05-07 23:02:24 <splatster> sipa: I'm on a crappy connection, something like 200 KB/s or maybe less.
1459 2012-05-07 23:02:43 <splatster> And I'm on an SSD/HDD hybrid.
1460 2012-05-07 23:02:43 <sipa> ok
1461 2012-05-07 23:07:12 random_cat_ has quit (Ping timeout: 276 seconds)
1462 2012-05-07 23:08:32 random_cat_ has joined
1463 2012-05-07 23:08:42 erle- has quit (Quit: erle-)
1464 2012-05-07 23:13:56 anonyminer has joined
1465 2012-05-07 23:14:35 <anonyminer> I need help with my Bitcoin Clien still not working it freezes when it is trying to catch up...
1466 2012-05-07 23:16:06 <sipa> how many blocks do you have alreadt?
1467 2012-05-07 23:19:05 knotwork_ has joined
1468 2012-05-07 23:21:34 knotwork has quit (Ping timeout: 248 seconds)
1469 2012-05-07 23:28:56 eoss has joined
1470 2012-05-07 23:28:56 eoss has quit (Changing host)
1471 2012-05-07 23:28:56 eoss has joined
1472 2012-05-07 23:37:30 paul0 has joined
1473 2012-05-07 23:37:34 twmz__ is now known as twmz
1474 2012-05-07 23:40:21 Ukto has quit (Ping timeout: 276 seconds)
1475 2012-05-07 23:41:14 Ukyo has joined
1476 2012-05-07 23:41:20 Ukyo is now known as Ukto
1477 2012-05-07 23:44:19 toffoo has quit ()
1478 2012-05-07 23:52:01 RainbowDashh has quit (Ping timeout: 250 seconds)
1479 2012-05-07 23:53:10 sytse has quit (Ping timeout: 245 seconds)
1480 2012-05-07 23:54:23 anonyminer has quit (Ping timeout: 245 seconds)
1481 2012-05-07 23:57:18 brwyatt is now known as Away!~brwyatt@pool-96-226-236-130.dllstx.fios.verizon.net|brwyatt
1482 2012-05-07 23:58:15 sytse has joined
1483 2012-05-07 23:59:12 rdponticelli has quit (Ping timeout: 260 seconds)