1 2013-07-13 00:06:04 <gmaxwell> So— a point of interest for continuity.
   2 2013-07-13 00:06:48 paraipan has joined
   3 2013-07-13 00:07:12 <gmaxwell> Apparently if GITHUB gets a well formed DMCA notice they act on it instantly, and without substantive review.
   4 2013-07-13 00:07:30 <gmaxwell> They deny _all_ access to the repository in question and all downstream forks of it.
   5 2013-07-13 00:07:41 <gmaxwell> Doing this also cuts off all access to bugs, issues, and pull requests.
   6 2013-07-13 00:07:56 <gmaxwell> So it might be productive if someone were backing these things up off github.
   7 2013-07-13 00:09:57 bbrian has quit (Ping timeout: 246 seconds)
   8 2013-07-13 00:10:21 <phantomcircuit> gmaxwell, they're required by law to do so
   9 2013-07-13 00:11:28 <gmaxwell> phantomcircuit: they are not—
  10 2013-07-13 00:11:43 <gmaxwell> They are not required to respond the same day— they could delay up to two weeks IIRC
  11 2013-07-13 00:12:00 bmcgee has joined
  12 2013-07-13 00:12:05 <gmaxwell> They're also not required to remove access to auxiliary material.
  13 2013-07-13 00:12:24 bmcgee has quit (Client Quit)
  14 2013-07-13 00:13:07 <MC1984> dosnt taht stuff get cloned to peoples local repos
  15 2013-07-13 00:13:08 <phantomcircuit> gmaxwell, auxiliary material tends to contain things which would be covered by the same copyright
  16 2013-07-13 00:13:10 <gmaxwell> And, if we're to be pedantic: they're not actually required to do anything at all. They condtions under the DMCA are only requirements for maintaining safe harbor in that particular instance. They're free to ignore it completely, at the risk of being named as a party in a civil copyright claim on that specific matter.
  17 2013-07-13 00:13:21 <gmaxwell> MC1984: no, that stuff doesn't.
  18 2013-07-13 00:13:34 <MC1984> wow
  19 2013-07-13 00:13:52 <gmaxwell> phantomcircuit: someone complaining about the code has no copyright interest in people's _bugreports_.
  20 2013-07-13 00:14:10 <phantomcircuit> gmaxwell, bugreports might contain snippets of code
  21 2013-07-13 00:14:18 <phantomcircuit> they're covering their asses
  22 2013-07-13 00:14:29 <gmaxwell> You're missing the point of what I'm saying in any case. I didn't mention it to complain about github's behavior, I pointed it out because it's important to backup the data.
  23 2013-07-13 00:14:52 <MC1984> DMCA is such bad law and the saf harbour has been pushed to breaking point so that companies will just shut down everything in the first instance
  24 2013-07-13 00:14:59 sipa has joined
  25 2013-07-13 00:15:06 <sipa> where did i go?
  26 2013-07-13 00:15:17 <gmaxwell> phantomcircuit: No, under the DMCA the reporter is required to specific the particular urls making the data avilable. Some other copy of the code provided by _another_ user is totally orthogonal.
  27 2013-07-13 00:15:50 <phantomcircuit> gmaxwell, see megaupload
  28 2013-07-13 00:15:56 <MC1984> ^
  29 2013-07-13 00:16:05 <phantomcircuit> the Doj does not agree
  30 2013-07-13 00:16:11 <MC1984> safe harbour has been deliberately gutted
  31 2013-07-13 00:16:13 <phantomcircuit> which is pretty much the only thing that matters
  32 2013-07-13 00:16:53 <gmaxwell> phantomcircuit: it's very different if you're talking about a non-US party (which has no obligations under the DMCA, nor a safe harbor either)
  33 2013-07-13 00:17:09 <gmaxwell> MC1984: hush child,
  34 2013-07-13 00:17:14 <gmaxwell> sipa: moon.
  35 2013-07-13 00:17:24 <MC1984> hmph
  36 2013-07-13 00:17:59 <MC1984> actually the doj considers nearly all useful websites to be under us jurisdiction
  37 2013-07-13 00:19:25 <MC1984> and they have neato extradition treaties with everyone
  38 2013-07-13 00:22:28 <sipa> gmaxwell: Type error: expected event, received "moon".
  39 2013-07-13 00:22:43 owowo has joined
  40 2013-07-13 00:23:09 <phantomcircuit> sipa, ◀━━ Quits: sipa (~pw@unaffiliated/sipa1024) (*.net *.split)
  41 2013-07-13 00:23:17 <sipa> ah
  42 2013-07-13 00:23:18 <phantomcircuit> we dont know what happened after that
  43 2013-07-13 00:23:34 <phantomcircuit> i assume the server you were connected to died
  44 2013-07-13 00:23:48 Application has joined
  45 2013-07-13 00:24:07 <phantomcircuit> sipa, on a totally unrelated note
  46 2013-07-13 00:24:22 <phantomcircuit> have you decided on a format for the wallet?
  47 2013-07-13 00:24:41 Transistorg has quit (Ping timeout: 248 seconds)
  48 2013-07-13 00:26:19 <sipa> format for keys, or for the wallet file, or for the wallet dump?
  49 2013-07-13 00:26:32 <sipa> or for the key records in wallet files?
  50 2013-07-13 00:27:28 <phantomcircuit> sipa, keys/wallet file
  51 2013-07-13 00:27:35 <phantomcircuit> i dont care about wallet dumps
  52 2013-07-13 00:27:57 <sipa> wallet file: more or less, over a year ago
  53 2013-07-13 00:28:07 <sipa> but the key format is orthogonal to that
  54 2013-07-13 00:28:14 <sipa> i mean the key record format
  55 2013-07-13 00:30:35 <sipa> i'd like to unify with the encrypted keys record, and include metadata and keypool data in the same record
  56 2013-07-13 00:31:14 <sipa> and have it support watch-only keys
  57 2013-07-13 00:35:22 <phantomcircuit> hmm
  58 2013-07-13 00:38:07 <sipa> something like <pubkey> -> (<keynum><NO_KEY,PLAIN_KEY,CRYPTED_KEY><privkey><metadata><checksum>)
  59 2013-07-13 00:38:19 <sipa> and then store the keypool as a list of keynums
  60 2013-07-13 00:41:00 <sipa> actually, watch-only doesn't belong in it
  61 2013-07-13 00:41:31 <sipa> as a P2SH address can also meaningfully be a watch-only address
  62 2013-07-13 00:42:17 <sipa> and doesn't metadata or a checksum, and can't be part of the keypool
  63 2013-07-13 00:42:21 <sipa> *have
  64 2013-07-13 00:43:46 <sipa> hmm, it can be
  65 2013-07-13 00:45:34 awaxa is now known as notawaxa
  66 2013-07-13 00:45:40 notawaxa is now known as awaxa
  67 2013-07-13 00:46:12 theymos has quit (Quit: Leaving)
  68 2013-07-13 00:46:41 roconnor has joined
  69 2013-07-13 00:52:16 metabyte has joined
  70 2013-07-13 00:55:57 gritball has quit (Remote host closed the connection)
  71 2013-07-13 01:01:07 <phantomcircuit> sipa, hmm
  72 2013-07-13 01:01:33 <phantomcircuit> logically the keypool is simply a list of keys for which you have the private keys somewhere
  73 2013-07-13 01:01:49 <sipa> yes, but it's really about addresses
  74 2013-07-13 01:01:58 <sipa> or generically, transaction destinations
  75 2013-07-13 01:02:17 <sipa> and a transaction destination can be defined by a key, but not necessarily
  76 2013-07-13 01:02:59 <sipa> and extending the analogy
  77 2013-07-13 01:03:16 <gmaxwell> sipa: An address should have references to private data object(s) required to redeem the address.
  78 2013-07-13 01:03:18 <sipa> a P2SH destination may or may not have an associated script
  79 2013-07-13 01:03:37 <gmaxwell> or perhaps a null reference if you don't know how.
  80 2013-07-13 01:03:43 digitalmagus3 has quit (Ping timeout: 256 seconds)
  81 2013-07-13 01:03:48 <sipa> just as a pubkey destination may or may not have an associated private key
  82 2013-07-13 01:03:57 <gmaxwell> I think the P2SH script is actually 'private key' material.
  83 2013-07-13 01:04:02 <sipa> bingo
  84 2013-07-13 01:04:56 <gmaxwell> A reference also might be to something like "Pop up a dialog and tell the user to call their Aunt Sue and tell her to sign with key 0xDEADBEEF".
  85 2013-07-13 01:05:10 <gmaxwell> (which presumably most clients wouldn't know what to do with that)
  86 2013-07-13 01:05:16 <phantomcircuit> gmaxwell, that's actually a good way to do it
  87 2013-07-13 01:05:20 crank has joined
  88 2013-07-13 01:05:57 <phantomcircuit> the private data object
  89 2013-07-13 01:05:59 <phantomcircuit> not aunt sue
  90 2013-07-13 01:06:12 <sipa> but pretty much all of these can have a birth timestamp (which is relevant for rescanning)
  91 2013-07-13 01:06:26 <sipa> and all can be used as change address, actually
  92 2013-07-13 01:06:34 <phantomcircuit> really wish there was a better level db interface for java
  93 2013-07-13 01:06:38 <phantomcircuit> life would be easier
  94 2013-07-13 01:06:43 <gmaxwell> Well, I think the address itself can have a birth timestamp.
  95 2013-07-13 01:06:56 <sipa> but you don't want a P2SH destination in the keypool
  96 2013-07-13 01:07:03 <sipa> it's a keypool - not an address pool
  97 2013-07-13 01:07:11 <phantomcircuit> well
  98 2013-07-13 01:07:25 <phantomcircuit> the birth timestamp thing is irrelevant if you only display unspent outputs
  99 2013-07-13 01:07:34 <sipa> hmm, maybe you do
 100 2013-07-13 01:07:36 <phantomcircuit> which theoretically is the only thing that matters
 101 2013-07-13 01:07:51 <gmaxwell> I think that sane p2sh usage would probably have some kind of grouping unit (perhaps a whole wallet) where all addresses in it are p2sh addresses with identical redemption rules.
 102 2013-07-13 01:08:16 <sipa> if you have a system with wallets that have corresponding keys in lockstep, you may want change addresses to be taken from a p2sh pool
 103 2013-07-13 01:08:22 <gmaxwell> right.
 104 2013-07-13 01:08:36 <gmaxwell> From a change chain that runs parallel.
 105 2013-07-13 01:09:11 <gmaxwell> Basically "Create multiparty (sub)wallet->Specifiy parties"
 106 2013-07-13 01:09:39 <gmaxwell> and then everything in the group behaves the same way, including change. Using lockstep type-2 derrived keys.
 107 2013-07-13 01:09:46 <phantomcircuit> change chain
 108 2013-07-13 01:09:47 <sipa> indeed
 109 2013-07-13 01:09:49 <phantomcircuit> say that outloud
 110 2013-07-13 01:09:56 * sipa just did
 111 2013-07-13 01:10:22 <gmaxwell> I mean, we speced out the BIP32 stuff specifically to facilitate that. :P
 112 2013-07-13 01:10:28 <sipa> indeed
 113 2013-07-13 01:11:08 <sipa> ooooh, linux 3.11 is next
 114 2013-07-13 01:11:19 <sipa> finally something to compete with windows for workgroups
 115 2013-07-13 01:11:35 <phantomcircuit> sipa, that's the first comment on the /. thread about it
 116 2013-07-13 01:11:42 <sipa> sorry :(
 117 2013-07-13 01:11:48 <phantomcircuit> Holding out for Linux 3.11 for workgroups.
 118 2013-07-13 01:11:53 <phantomcircuit> lol
 119 2013-07-13 01:12:05 <sipa> it should be an aliteration
 120 2013-07-13 01:12:12 <sipa> Linux 3.11 for lurkgroups.
 121 2013-07-13 01:13:03 <phantomcircuit> lol
 122 2013-07-13 01:14:43 <phantomcircuit> that's a new one
 123 2013-07-13 01:14:53 <phantomcircuit> someones trying to ddos momentovps by starting/stopping servers
 124 2013-07-13 01:19:20 <MC1984> yo phantomcircuit
 125 2013-07-13 01:19:42 <phantomcircuit> hello
 126 2013-07-13 01:19:52 <MC1984> sup :)
 127 2013-07-13 01:20:19 <phantomcircuit> not much
 128 2013-07-13 01:20:23 <phantomcircuit> stupid people being stupid
 129 2013-07-13 01:20:24 <phantomcircuit> the usual
 130 2013-07-13 01:20:31 <MC1984> word
 131 2013-07-13 01:24:59 <TheLordOfTime> what's the default port that testnet bitcoin-qt/bitcoind listens on (for localhost RPC, assuming i enabled rpc and didn't specify a port in the bitcoin.conf)
 132 2013-07-13 01:25:46 <phantomcircuit> iirc 18333
 133 2013-07-13 01:25:58 <sipa> 18333 for P2P and 18332 for RPC
 134 2013-07-13 01:26:06 <TheLordOfTime> sipa:  thanks.
 135 2013-07-13 01:27:19 <MC1984> Is the main reason the dev lists are on sourceforge for archival?
 136 2013-07-13 01:27:52 <sipa> i think it's mostly historical
 137 2013-07-13 01:27:54 <phantomcircuit> MC1984, i would assume just because it's easy
 138 2013-07-13 01:27:58 <phantomcircuit> it's already setup
 139 2013-07-13 01:28:16 <MC1984> already setup?
 140 2013-07-13 01:28:32 <phantomcircuit> MC1984, it's mailman or something
 141 2013-07-13 01:28:36 <phantomcircuit> which is annoying to setup
 142 2013-07-13 01:28:43 <phantomcircuit> sf just has a button you click
 143 2013-07-13 01:28:55 <MC1984> oh
 144 2013-07-13 01:29:23 meLon has joined
 145 2013-07-13 01:30:00 <TheLordOfTime> anyone here got any spare testnet coins they can dump?
 146 2013-07-13 01:30:25 <MC1984> yeah
 147 2013-07-13 01:30:30 <phantomcircuit> there's a testnet faucet
 148 2013-07-13 01:30:33 <phantomcircuit> you get like 35 of them
 149 2013-07-13 01:30:34 <TheLordOfTime> phantomcircuit:  where.
 150 2013-07-13 01:30:41 <TheLordOfTime> all the ones i've frequented don't work anymore
 151 2013-07-13 01:30:45 <TheLordOfTime> or are closed or such.
 152 2013-07-13 01:31:25 <MC1984> drop an address
 153 2013-07-13 01:31:37 <TheLordOfTime> MC1984:  mvaHx8M2aAr8uziXE32PmzHGDhNfaANTYd
 154 2013-07-13 01:38:05 <phantomcircuit> sipa, gmaxwell for BIP32 the things that need to be saved are the root key and a list of how far address generation has gotten, right?
 155 2013-07-13 01:39:31 <TheLordOfTime> MC1984:  thanks
 156 2013-07-13 01:39:54 Application has quit (Ping timeout: 246 seconds)
 157 2013-07-13 01:47:20 MobPhone has quit (Read error: Connection reset by peer)
 158 2013-07-13 01:48:34 MobPhone has joined
 159 2013-07-13 01:51:07 c0rw1n has quit (Remote host closed the connection)
 160 2013-07-13 01:52:02 imton has joined
 161 2013-07-13 01:54:44 nowan has joined
 162 2013-07-13 01:57:43 nowan_ has quit (Ping timeout: 246 seconds)
 163 2013-07-13 02:07:32 loget has quit (Ping timeout: 250 seconds)
 164 2013-07-13 02:22:14 Application has joined
 165 2013-07-13 02:22:39 c0rw1n has joined
 166 2013-07-13 02:29:02 wamatt has joined
 167 2013-07-13 02:29:07 Applicat_ has joined
 168 2013-07-13 02:29:46 Applica__ has joined
 169 2013-07-13 02:31:18 wamatt has quit (Read error: Connection reset by peer)
 170 2013-07-13 02:32:12 Application has quit (Ping timeout: 240 seconds)
 171 2013-07-13 02:32:38 Subo1978_ has joined
 172 2013-07-13 02:33:43 Applicat_ has quit (Ping timeout: 260 seconds)
 173 2013-07-13 02:36:09 Subo1978 has quit (Ping timeout: 240 seconds)
 174 2013-07-13 02:36:45 wamatt has joined
 175 2013-07-13 02:38:08 wamatt has quit (Read error: Connection reset by peer)
 176 2013-07-13 02:44:59 br3wb0n1k has joined
 177 2013-07-13 02:49:35 br3wb0n1k has left ()
 178 2013-07-13 02:53:09 wamatt has joined
 179 2013-07-13 02:53:10 fanquake has joined
 180 2013-07-13 03:01:39 squwiggle has quit (Quit: Konversation terminated!)
 181 2013-07-13 03:03:06 gjs278 has quit (Remote host closed the connection)
 182 2013-07-13 03:15:04 cads has joined
 183 2013-07-13 03:26:34 c0rw1n has quit (Ping timeout: 240 seconds)
 184 2013-07-13 03:32:42 c0rw1n has joined
 185 2013-07-13 03:35:05 malaimo has quit (Ping timeout: 264 seconds)
 186 2013-07-13 03:35:50 [7] has quit (Disconnected by services)
 187 2013-07-13 03:35:59 TheSeven has joined
 188 2013-07-13 03:36:57 malaimo has joined
 189 2013-07-13 03:49:36 IanCormac has joined
 190 2013-07-13 03:55:39 c0rw1n has quit (Remote host closed the connection)
 191 2013-07-13 03:59:22 fishfish_ has joined
 192 2013-07-13 04:02:57 fishfish has quit (Ping timeout: 256 seconds)
 193 2013-07-13 04:06:32 robocoin_ has joined
 194 2013-07-13 04:09:23 robocoin has quit (Ping timeout: 260 seconds)
 195 2013-07-13 04:12:37 saintcajetan has quit (Remote host closed the connection)
 196 2013-07-13 04:23:36 BGL has quit (Ping timeout: 240 seconds)
 197 2013-07-13 04:24:41 loget has joined
 198 2013-07-13 04:27:53 PRab has quit (Ping timeout: 264 seconds)
 199 2013-07-13 04:34:57 IanCormac has quit (Quit: IanCormac)
 200 2013-07-13 04:37:19 loget has quit (Quit: Page closed)
 201 2013-07-13 04:41:12 wamatt has quit (Read error: Connection reset by peer)
 202 2013-07-13 04:42:55 BGL has joined
 203 2013-07-13 04:46:27 Diablo-D3 has quit (Ping timeout: 245 seconds)
 204 2013-07-13 04:48:55 gjs278 has joined
 205 2013-07-13 04:50:46 wamatt has joined
 206 2013-07-13 04:56:13 ralphtheninja has quit (Ping timeout: 256 seconds)
 207 2013-07-13 04:57:32 PiZZaMaN2K is now known as away!~PiZZaMaN2@host-72-2-137-170.csinet.net|PiZZaMaN2K
 208 2013-07-13 04:58:23 Gnaf_ has quit (Read error: Connection reset by peer)
 209 2013-07-13 04:58:46 TradeFortress has joined
 210 2013-07-13 04:58:49 gdbz has quit (Ping timeout: 248 seconds)
 211 2013-07-13 04:59:13 <TradeFortress> bitcoind STILL keeps deadlocking even after I moved it to another server
 212 2013-07-13 04:59:53 gdbz has joined
 213 2013-07-13 05:00:46 magicpig has quit (Ping timeout: 246 seconds)
 214 2013-07-13 05:04:09 Prattler has quit (Ping timeout: 248 seconds)
 215 2013-07-13 05:06:07 Prattler has joined
 216 2013-07-13 05:18:09 freewil has quit (Ping timeout: 256 seconds)
 217 2013-07-13 05:21:59 wamatt has quit (Read error: Connection reset by peer)
 218 2013-07-13 05:26:57 owowo has quit (Quit: sayonara)
 219 2013-07-13 05:28:47 o3u has quit (Ping timeout: 246 seconds)
 220 2013-07-13 05:31:50 <helo> TradeFortress: your use case must be fairly unique, as i haven't seen anyone else mention deadlocking problems
 221 2013-07-13 05:31:57 wamatt has joined
 222 2013-07-13 05:32:22 <TradeFortress> helo, I don't think it's very unique. It looks like it's caused by getbalance after a sendtoaddress.
 223 2013-07-13 05:32:28 <TradeFortress> Or a getbalance during a sendtoaddress?
 224 2013-07-13 05:32:41 <helo> TradeFortress: but i'm sure that if you can give enough details for others to reproduce it, it will get fixed
 225 2013-07-13 05:33:19 <TradeFortress> The thing is this happens on a prod enviroment, and I cannot wait 30 minutes for someone to tell me what to do with gdb
 226 2013-07-13 05:33:34 <helo> so you're following a sendtoaddress immediately with a getbalance?
 227 2013-07-13 05:35:12 <helo> yeah i've been there... no fun... i'll load up a debugging version on testnet and bang on it with some scripts. how many addresses do you have?
 228 2013-07-13 05:35:32 <helo> and what version?
 229 2013-07-13 05:36:10 <helo> did you build it?
 230 2013-07-13 05:37:33 wamatt has quit (Read error: Connection reset by peer)
 231 2013-07-13 05:39:12 <helo> all of the devs are out rolling down the strip in their rolls-royces, but i'll give it a shot
 232 2013-07-13 05:40:18 <gmaxwell> helo: pft, nah, we're just eating popcoin and waiting for the y'all to step up and produce a reproducable test case. :P
 233 2013-07-13 05:41:09 paraipan has quit (Ping timeout: 240 seconds)
 234 2013-07-13 05:41:53 <TradeFortress> helo, I'm not following that, it's a web app and there often are getbalance calls
 235 2013-07-13 05:41:59 paraipan has joined
 236 2013-07-13 05:42:04 <TradeFortress> I've tried v0.8.3 and master
 237 2013-07-13 05:42:15 <TradeFortress> 1k addresses
 238 2013-07-13 05:44:34 <helo> did you compile both?
 239 2013-07-13 05:45:31 <TradeFortress> yes, I compile mine
 240 2013-07-13 05:45:36 <helo> what platform?
 241 2013-07-13 05:45:57 <helo> can you pastebin the output of "ldd bitcoind"
 242 2013-07-13 05:50:48 <helo> you may want to try using the released pre-compiled binary, as it is statically linked against the "right" lib versions
 243 2013-07-13 05:51:43 <TradeFortress> ubuntu 12.04 LTS
 244 2013-07-13 05:51:47 <TradeFortress> let me try that
 245 2013-07-13 05:52:22 <TradeFortress> helo: pastebin.com/7Y3nBcGE
 246 2013-07-13 05:54:20 <helo> the wallet's still using libdb, and that's linked to a different version that all of the precompiled (i.e. most well tested) releases
 247 2013-07-13 05:56:11 <gmaxwell> good spotting, but its still worth trying to get a reproduction under both to see if that makes a difference, unfortunately TradeFortress can't run the precompiled binaries due to him using the bdb5.
 248 2013-07-13 05:56:18 <gmaxwell> (since his wallet will be incompatible)
 249 2013-07-13 05:56:30 <gmaxwell> (5 can read 4 but not vice versa, it only goes one way)
 250 2013-07-13 05:56:32 <helo> yeah, that is a problem...
 251 2013-07-13 05:56:39 <TradeFortress> So my wallet.dat is incompatible?
 252 2013-07-13 05:56:52 <helo> if you use 5, it upgrades your wallet
 253 2013-07-13 05:57:07 <TradeFortress> OK, so I download a precompiled v0.8.3 ?
 254 2013-07-13 05:58:00 <helo> gmaxwell: he could start up a v0.8.3 new wallet, and import all of his addresses to have a db4 wallet?
 255 2013-07-13 05:58:18 <gmaxwell> helo: there is no easy and reliable way to "import all of his addresses to have a db4 wallet"
 256 2013-07-13 06:00:08 <TradeFortress> grweat
 257 2013-07-13 06:01:50 <TradeFortress> I'm guessing I'm fairly screwed then?
 258 2013-07-13 06:03:19 <helo> gmaxwell: listreceivedbyaddress to get the addresses, dumpprivkey to get they keys, and then importprivkey into an unsynched 0.8.3 wallet, and then sync?
 259 2013-07-13 06:05:46 imton has quit (Ping timeout: 240 seconds)
 260 2013-07-13 06:07:28 * TradeFortress will start a 10 btc bounty: fix my bitcoind's troubles :P
 261 2013-07-13 06:08:28 <helo> 10btc bounty sounds pretty contradictory to what gmaxwell just said ;)
 262 2013-07-13 06:09:58 <helo> this is all just to see if it is reproducable on the production build, too...
 263 2013-07-13 06:10:38 <TradeFortress> I don't think this is omething that will take 5 days :P
 264 2013-07-13 06:15:28 <helo> afaik (cue gmaxwell explaining otherwise) getting your owned addresses into a v4 wallet seems feasible
 265 2013-07-13 06:16:29 ThomasV has joined
 266 2013-07-13 06:17:29 * helo adds 10k addresses to his testnet v5 wallet
 267 2013-07-13 06:20:22 <TradeFortress> helo, try doing a sendtoaddress and calling getbalance at the same time?
 268 2013-07-13 06:25:51 wamatt has joined
 269 2013-07-13 06:27:52 <TradeFortress> yeah, corrupt wallet when I try the ppa builds
 270 2013-07-13 06:29:07 <helo> i know how to get your addresses that have received balances
 271 2013-07-13 06:30:12 <TradeFortress> helo, I need *all* my addresses.
 272 2013-07-13 06:32:15 <helo> are you using the accounts feature?
 273 2013-07-13 06:32:43 metabyte_ has joined
 274 2013-07-13 06:32:47 <TradeFortress> yes
 275 2013-07-13 06:33:35 <helo> so your ~1k address are distributed among a bunch of accounts?
 276 2013-07-13 06:34:34 <helo> how many accounts?
 277 2013-07-13 06:34:36 metabyte has quit (Ping timeout: 246 seconds)
 278 2013-07-13 06:34:43 <helo> how many addresses per account etc
 279 2013-07-13 06:36:11 CodeName has joined
 280 2013-07-13 06:47:49 owowo has joined
 281 2013-07-13 06:48:33 CodeName has quit (Ping timeout: 245 seconds)
 282 2013-07-13 06:48:35 <helo> are you using accounts in bitcoin to correspond to individual customer accounts?
 283 2013-07-13 06:59:59 metabyte_ is now known as metabyte
 284 2013-07-13 07:01:55 <TradeFortress> helo, yes
 285 2013-07-13 07:02:32 <TradeFortress> 1300 accounts
 286 2013-07-13 07:02:39 <TradeFortress> each account in bitcoin == 1 user account
 287 2013-07-13 07:04:43 <helo> TradeFortress: you can try installing the db5.1-util, and then (after shutting down bitcoind so the db file is closed) doing db5.1_dump wallet.dat.db5 > wallet.dat.dump. then if you can install db4.8-util, you may be able to cat wallet.dat.dump | db4.8_load wallet.dat.db4 to get a db4 wallet. your service would have to be down though. and then you'd need to start up the statically linked bitcoind. it would then do a (probably long) rescan, and would hopef
 288 2013-07-13 07:04:50 <TradeFortress> well not really I can just shut down bitcoind for like less than a minute, get a wallet and do operations on that
 289 2013-07-13 07:05:30 <helo> but then how do you get what happens to the db5 wallet while you're getting the db4 instance up into the db4 wallet?
 290 2013-07-13 07:05:47 <helo> do you have one address per user (and bitcoin) account?
 291 2013-07-13 07:05:52 <TradeFortress> a large keypool?
 292 2013-07-13 07:05:59 <TradeFortress> block generation of new addresses for a while?
 293 2013-07-13 07:06:43 <TradeFortress> is it even likely that it is db5 causing the problem ??
 294 2013-07-13 07:07:10 <helo> it's possible... those are wallet operations, so they're using libdb
 295 2013-07-13 07:07:26 <helo> just a guess though. as i said, nobody has had this problem that i've heard
 296 2013-07-13 07:08:16 peetaur2 has joined
 297 2013-07-13 07:12:23 <TradeFortress> what should I do when it happens again with gdb?
 298 2013-07-13 07:17:19 peetaur2 has quit (Quit: Konversation terminated!)
 299 2013-07-13 07:17:29 CodeName has joined
 300 2013-07-13 07:20:18 willg has joined
 301 2013-07-13 07:21:22 freewil has joined
 302 2013-07-13 07:23:45 peetaur2 has joined
 303 2013-07-13 07:26:03 <helo> you'd need to be running a debug build to have anything to work with
 304 2013-07-13 07:26:25 <helo> and then you could look through the threads to see where they are deadlocked
 305 2013-07-13 07:26:34 CodeName has quit (Ping timeout: 240 seconds)
 306 2013-07-13 07:26:44 <helo> hopefully it won't happen with db4
 307 2013-07-13 07:27:48 <helo> if users can change the address associated with their account, the activity that happens on the db5 wallet while you're getting the db4 wallet up could cause a mess
 308 2013-07-13 07:28:23 <TradeFortress> helo, do you mind testing to see if it's possible to go back to db4? I'm happy to tip you for your time
 309 2013-07-13 07:28:26 <helo> or if new accounts are created, etc... or other things i don't know about how your service works
 310 2013-07-13 07:28:44 <helo> yeah, i just generated a db5 wallet. going to try converting to db4
 311 2013-07-13 07:28:59 <TradeFortress> ok
 312 2013-07-13 07:29:24 <fanquake> Is anyone building with Boost 1.54.0? Upgraded this morning to see Undefined symbols for architecture x86_64:
 313 2013-07-13 07:29:24 <fanquake>   "_TLSv1_1_client_method", referenced from:
 314 2013-07-13 07:29:25 <fanquake>       boost::asio::ssl::context::context(boost::asio::ssl::context_base::method) in bitcoinrpc.o
 315 2013-07-13 07:30:36 theorbtwo has quit (Ping timeout: 240 seconds)
 316 2013-07-13 07:33:19 paybitcoin has quit (Ping timeout: 260 seconds)
 317 2013-07-13 07:33:44 <helo> TradeFortress: do you use sendfrom <account> <tobitcoinaddress>, or just sendtoaddress ...?
 318 2013-07-13 07:34:04 <TradeFortress> sendtoaddress
 319 2013-07-13 07:34:18 Jere_Jones has quit (Ping timeout: 245 seconds)
 320 2013-07-13 07:35:15 <TradeFortress> I know this happens after someone sends coins
 321 2013-07-13 07:35:22 ThomasV has quit (Ping timeout: 240 seconds)
 322 2013-07-13 07:35:29 <TradeFortress> json-rpc becomes unresponsive and times out, then deadlock
 323 2013-07-13 07:37:03 freewil has quit (Ping timeout: 260 seconds)
 324 2013-07-13 07:39:03 <helo> when i do sendtoaddress and then a getbalance <account>, the balance of that account doesn't change... the result of getbalance "" goes down by the amount sent
 325 2013-07-13 07:40:08 <helo> or are you just doing a "getbalance" without listing the account?
 326 2013-07-13 07:40:16 <helo> without *specifying
 327 2013-07-13 07:40:26 <TradeFortress> I keep track of user balances in my db
 328 2013-07-13 07:40:29 <TradeFortress> I don't check the balance of accounts
 329 2013-07-13 07:40:31 <willg> ^^
 330 2013-07-13 07:40:33 <helo> ahh ok
 331 2013-07-13 07:40:50 <helo> so the getbalance is more of a sanity check
 332 2013-07-13 07:41:25 <TradeFortress> nah, the  getbalance is from other users opening up their wallet
 333 2013-07-13 07:41:38 <TradeFortress> here is the txid that caused it to deadlock: http://blockchain.info/tx/79542ad431294752eed0f80b407e6683e874d7c2e8daa672fcb6eb582f0f384b
 334 2013-07-13 07:41:44 <TradeFortress> don't see anything strange
 335 2013-07-13 07:43:21 <willg> i keep track and report out of the db and give every user a separate account to use to getbalance to double check
 336 2013-07-13 07:45:48 <TradeFortress> willg, the more rpc you use, the less your app scales
 337 2013-07-13 07:46:18 <willg> oh for sure .. i mean on a cron timer kinda thing
 338 2013-07-13 07:46:34 <willg> to look for reasons the db should update
 339 2013-07-13 07:48:25 bazyl has quit (Ping timeout: 248 seconds)
 340 2013-07-13 07:50:20 <TradeFortress> I think the problem is with sendtoaddress actaully..
 341 2013-07-13 07:50:25 <TradeFortress> getbalance may or may not be related
 342 2013-07-13 07:50:47 <TradeFortress> after all it fails at sendtoaddress
 343 2013-07-13 07:50:50 <helo> TradeFortress: the db5.1_dump wallet.dat.5.1 > wallet.dump followed by cat wallet.dump | db4.8_load > wallet.dat.4.1 seems to have worked
 344 2013-07-13 07:51:03 <helo> it loaded without corruption complaints, and the accounts are there
 345 2013-07-13 07:51:15 <helo> and ~10k addresses
 346 2013-07-13 07:52:13 <TradeFortress> ok, so I should use the bitcoind in the ppa?
 347 2013-07-13 07:52:46 <helo> the transacitons are there
 348 2013-07-13 07:53:02 <helo> well, you'll need to install db4.8_load to create the db4.8 wallet
 349 2013-07-13 07:53:15 <helo> does ubuntu 12.04 have the db4.8-util package?
 350 2013-07-13 07:53:43 <helo> i happen to have a debian install which includes libdb4.8
 351 2013-07-13 07:54:34 <TradeFortress> yup ubuntu has both
 352 2013-07-13 07:54:42 <TradeFortress> so I need the bitcoind from ppa?
 353 2013-07-13 07:54:53 <helo> you can use the ppa, or you can download it directly from bitcoin.org
 354 2013-07-13 07:54:54 CodesInChaos_ has joined
 355 2013-07-13 07:55:14 tholenst has joined
 356 2013-07-13 07:55:21 <TradeFortress> bitcoin.org links to the ppa
 357 2013-07-13 07:55:22 <TradeFortress> lol
 358 2013-07-13 07:55:24 roconnor has quit (Quit: Konversation terminated!)
 359 2013-07-13 07:56:21 <helo> you can download the tarball from bitcoin.org
 360 2013-07-13 07:56:58 <helo> be sure you use the same architecture binary (the tarball includes 32 and 64)
 361 2013-07-13 07:57:34 <helo> in a production environment, i'd probably hand-install the bitcoind from the tarball so the package manager doesn't upgrade to a version that i haven't tested
 362 2013-07-13 07:58:56 ThomasV has joined
 363 2013-07-13 08:00:04 <TradeFortress> wallet.dat.db5 == wallet.dat, right?
 364 2013-07-13 08:00:28 <helo> yeah... i'm assuming you copied the v5 wallet.dat to wallet.dat.db5 for safe keeping
 365 2013-07-13 08:01:01 <helo> since you have both on the same system, you can do db5.1_dump wallet.dat.db5 | db4.8_load > wallet.dat.db4
 366 2013-07-13 08:01:40 <helo> and then copy the wallet.dat.db4 to ~/.bitcoin/wallet.dat and start up the statically linked bitcoind
 367 2013-07-13 08:02:04 <TradeFortress> helo, that command doesn't wrok, gives me db4.8_load usage
 368 2013-07-13 08:02:33 <TradeFortress> db5.1_dump wallet.dat > db4.8_load ?
 369 2013-07-13 08:02:54 <sipa> TradeFortress: sendtoaddress always deducta from the "" account
 370 2013-07-13 08:03:03 <sipa> TradeFortress: so what you see is normal
 371 2013-07-13 08:03:12 <TradeFortress> sipa, what I'm seeing is a deadlock
 372 2013-07-13 08:03:19 <TradeFortress> when I do sendtoaddress
 373 2013-07-13 08:03:20 <sipa> yes, i know that
 374 2013-07-13 08:03:24 <TradeFortress> not after getbalance or whatever.
 375 2013-07-13 08:03:30 <sipa> but that's a separate problem
 376 2013-07-13 08:03:30 <helo> db5.1_dump wallet.dat.db5 > wallet.db.dump ; db4.8_load wallet.db.dump > wallet.dat.db4
 377 2013-07-13 08:04:08 <TradeFortress> that took like a second
 378 2013-07-13 08:04:28 <helo> i did cat wallet.testnet.dump.5.1 | db4.8_load wallet.dat.4.1.load
 379 2013-07-13 08:04:53 <helo> and then copied wallet.dat.4.1.load to ~/.bitcoin/[testnet3]/wallet.dat
 380 2013-07-13 08:06:03 <TradeFortress> ok, db4.8_load is taking a while and I think terminal stopped responding
 381 2013-07-13 08:06:10 <TradeFortress> no longer blinking
 382 2013-07-13 08:06:21 <helo> ignore that "db4.8_load wallet.db.dump > wallet.dat.db4" nonsense
 383 2013-07-13 08:06:22 <TradeFortress> surprising since dumping it took less than a second
 384 2013-07-13 08:06:28 <TradeFortress> wut
 385 2013-07-13 08:06:51 <TradeFortress> Now I have wallet.dat.dump, what do I do with that
 386 2013-07-13 08:07:48 CodesInChaos__ has joined
 387 2013-07-13 08:08:02 <helo> sorry, i haven't used the dump/load much... what you could have done originally is simply: db5.1_dump wallet.dat.db5 | db4.8_load wallet.dat.db4
 388 2013-07-13 08:08:34 <TradeFortress> unexpected file type or format
 389 2013-07-13 08:09:35 <TradeFortress> nvm now I got db4. I'll put that in .bitcoin
 390 2013-07-13 08:09:51 <TradeFortress> do I need to delete any directories?
 391 2013-07-13 08:10:36 <helo> i'm not sure if the 0.8.3 will need to resync
 392 2013-07-13 08:11:13 <TradeFortress> nope
 393 2013-07-13 08:11:18 <TradeFortress> Error: Error loading wallet.dat: Wallet corrupted
 394 2013-07-13 08:11:34 CodesInChaos_ has quit (Ping timeout: 256 seconds)
 395 2013-07-13 08:11:52 <helo> what does "file wallet.dat" show?
 396 2013-07-13 08:12:18 <TradeFortress> version 9
 397 2013-07-13 08:13:46 <helo> you're sure you shut down the bitcoind and let it sync to disk before you copied wallet.dat to wallet.dat.db5?
 398 2013-07-13 08:13:56 mappum has quit (Ping timeout: 260 seconds)
 399 2013-07-13 08:14:09 <TradeFortress> yep, I did ./bitcoind stop and waited
 400 2013-07-13 08:14:18 <TradeFortress> version 9 is the v5?
 401 2013-07-13 08:14:20 <TradeFortress> or v4?
 402 2013-07-13 08:14:28 <helo> my v4 says version 9
 403 2013-07-13 08:14:49 <TradeFortress> well the thing is all my wallet dats are version 9.
 404 2013-07-13 08:15:10 <helo> yeah, i think that's as much as the "file" util can tell
 405 2013-07-13 08:15:38 <helo> how big is wallet.dat.db4 compared to wallet.dat.db5?
 406 2013-07-13 08:16:59 <TradeFortress> smaller in size
 407 2013-07-13 08:18:00 <TradeFortress> by like 4%
 408 2013-07-13 08:18:13 ThomasV has quit (Ping timeout: 246 seconds)
 409 2013-07-13 08:18:46 <helo> mine is smaller too.
 410 2013-07-13 08:19:11 <helo> but it didn't give me a corruption error, loaded up the addresses, and seems to have the right balances
 411 2013-07-13 08:19:28 <TradeFortress> could it be that I'm using diff versions
 412 2013-07-13 08:19:43 <TradeFortress> my 5.1 is master, I'm now trying to use the 0.8.3
 413 2013-07-13 08:20:08 <helo> my 5.1 is master too
 414 2013-07-13 08:20:29 <TradeFortress> well that is marvellous.
 415 2013-07-13 08:21:15 <helo> your wallet is a lot more complicated than mine... i guess the dump/load could have resulted in some changes that bitcoin didn't like
 416 2013-07-13 08:21:23 <TradeFortress> I can load this wallet.dat from db5.1 fine
 417 2013-07-13 08:21:45 <TradeFortress> helo, maybe because your wallet didn't include any transactions
 418 2013-07-13 08:22:00 <sipa> seems unlikely
 419 2013-07-13 08:22:09 <TradeFortress> grr
 420 2013-07-13 08:22:09 <sipa> dump/load should always work
 421 2013-07-13 08:22:13 <helo> when you try to load your wallet.dat.db5 in the statically linked bitcoind, does it give the same wallet corruption error as you're getting with the converted wallet?
 422 2013-07-13 08:22:21 <helo> i did a few transactions
 423 2013-07-13 08:22:23 <TradeFortress> helo, let me try that
 424 2013-07-13 08:22:56 * sipa wants bdb to die a most painful death 2 years ago
 425 2013-07-13 08:22:58 <helo> hopefully you made a mistake with the dump/load procedure
 426 2013-07-13 08:23:07 <TradeFortress> helo, no, I didn't, I tried multiple times. got same file size
 427 2013-07-13 08:23:12 <sipa> you have no idea how much issues it has caused us already
 428 2013-07-13 08:23:13 <TradeFortress> and "Wallet corrupted"
 429 2013-07-13 08:23:28 <TradeFortress> sipa, april fork
 430 2013-07-13 08:23:42 <helo> so loading the converted db4 wallet gives the same error as the db5 wallet?
 431 2013-07-13 08:23:46 <TradeFortress> yes
 432 2013-07-13 08:24:07 <helo> are you sure you didn't db5.1_dump wallet.dat.db5 | db5.1_load wallet.dat.db4?
 433 2013-07-13 08:24:14 <sipa> the march 11 fork, you mean?
 434 2013-07-13 08:24:58 <TradeFortress> well, I might be off with the exact wording. helo I did db4.8
 435 2013-07-13 08:25:03 <TradeFortress> db4.8_load
 436 2013-07-13 08:25:14 <TradeFortress> with the exact timing*
 437 2013-07-13 08:25:31 <sipa> helo: what version is your self compiled?
 438 2013-07-13 08:25:47 <helo> sipa: HEAD
 439 2013-07-13 08:26:08 <sipa> there may just be an incompatibility between master and 0.8.3
 440 2013-07-13 08:26:19 <sipa> as it's not released
 441 2013-07-13 08:26:59 <helo> booo
 442 2013-07-13 08:27:27 <sipa> TradeFortress: try wiping your database/ subdir before load
 443 2013-07-13 08:27:48 <TradeFortress> sipa, I don't have a database
 444 2013-07-13 08:27:58 <sipa> ok, good
 445 2013-07-13 08:28:17 <sipa> right, we clean that up automatically now
 446 2013-07-13 08:29:04 <TradeFortress> I guess salvagewallet or whatever won't work?
 447 2013-07-13 08:29:12 <sipa> it should
 448 2013-07-13 08:29:33 <sipa> but you will lose account information
 449 2013-07-13 08:29:40 <sipa> it only salvages private keys
 450 2013-07-13 08:29:42 <helo> no-go :/
 451 2013-07-13 08:29:45 <sipa> no transactions
 452 2013-07-13 08:30:13 <TradeFortress> that is ok
 453 2013-07-13 08:30:19 <TradeFortress> because my accounts have a balance of 0 anyway
 454 2013-07-13 08:30:23 <TradeFortress> I move them to "sinkhole"
 455 2013-07-13 08:30:35 <TradeFortress> but I will lose which private key belongs to which account?
 456 2013-07-13 08:30:42 <sipa> then what do you use accounts for anyway?
 457 2013-07-13 08:30:46 <sipa> yes
 458 2013-07-13 08:32:28 <sipa> maybe your db4.8 load is not the same version as the bdb version the bitcoin ppa version was compiled with?
 459 2013-07-13 08:32:46 <sipa> even though both are 4.8, this would not surproise me
 460 2013-07-13 08:32:59 <TradeFortress> I got it from sudo apt-get install db4.8_load
 461 2013-07-13 08:33:28 <helo> you could listaccounts, parse through it for addresses, dumpprivkey to get the privkey, and then importprivkey and use setaccount :(
 462 2013-07-13 08:33:47 <sipa> git head does have dumpwallet and loadwallet
 463 2013-07-13 08:33:58 <sipa> which does include that information
 464 2013-07-13 08:34:10 <sipa> but 0.8.3 does not have that
 465 2013-07-13 08:34:28 <TradeFortress> but I can just build v0.8.3 withv4.8?
 466 2013-07-13 08:34:34 <sipa> yes
 467 2013-07-13 08:34:49 <TradeFortress> doesn't dumpwallet just give you the same wallet.dat
 468 2013-07-13 08:35:09 <sipa> no, it dumps in a human-readable format
 469 2013-07-13 08:35:29 <TradeFortress> but still works as  wallet.dat?
 470 2013-07-13 08:35:33 <sipa> no
 471 2013-07-13 08:35:41 <sipa> you need to import it
 472 2013-07-13 08:35:42 <TradeFortress> odd
 473 2013-07-13 08:35:51 <TradeFortress> I remember I got my current wallet.dat from a dumpwallet wallet.dat
 474 2013-07-13 08:35:59 <sipa> you mean backupwallet
 475 2013-07-13 08:36:03 <sipa> not dumpwallet
 476 2013-07-13 08:36:05 <TradeFortress> ah backupwallet
 477 2013-07-13 08:37:16 <TradeFortress> but should I be running head on prod anyway
 478 2013-07-13 08:37:24 peetaur2 has quit (Quit: Konversation terminated!)
 479 2013-07-13 08:37:25 <helo> well i gotta get up in a few hours... hopefully you can get static 0.8.3 up and stop having deadlocks :/
 480 2013-07-13 08:37:37 <sipa> but what are you trying? whether 0.8.3 from the ppa has the same deadlocks?
 481 2013-07-13 08:37:41 CodesInChaos_ has joined
 482 2013-07-13 08:38:01 <TradeFortress> sipa, I do not think I have used v0.8.3 from ppa. I always used leveldb 5
 483 2013-07-13 08:38:16 <sipa> bdb you mean
 484 2013-07-13 08:38:23 <helo> sipa: whether the db5.1 is causing the deadlocks, vs statically linked to 4.8
 485 2013-07-13 08:38:32 <TradeFortress> bdb yup
 486 2013-07-13 08:38:35 <sipa> that seems very unlikely
 487 2013-07-13 08:38:51 <sipa> i'm pretty sure a deadlock would be our fdault
 488 2013-07-13 08:39:00 <sipa> not bdb's
 489 2013-07-13 08:39:03 <TradeFortress> well I get a deadlock with arbintary sendtoaddress faults
 490 2013-07-13 08:39:13 <TradeFortress> as in unexpected
 491 2013-07-13 08:39:31 <sipa> well deadlocks are always unexpected, i hope
 492 2013-07-13 08:39:51 <sipa> why do you need to run head, btw?
 493 2013-07-13 08:40:07 <TradeFortress> sipa, I don't need to but I can't seem to get back to 0.8.3
 494 2013-07-13 08:40:15 <TradeFortress> I thought maybe head fixed the problem
 495 2013-07-13 08:40:26 <sipa> i see
 496 2013-07-13 08:40:46 <TradeFortress> plus I think you will be very mad at me if it turns out it was already fixed
 497 2013-07-13 08:41:08 <sipa> does a self-compiled 0.8.3 work?
 498 2013-07-13 08:41:27 <TradeFortress> no that had deadlocks
 499 2013-07-13 08:41:32 catcow has quit (Read error: Connection reset by peer)
 500 2013-07-13 08:41:34 Liquid3xB has quit (Read error: Connection reset by peer)
 501 2013-07-13 08:41:37 <sipa> well so does head
 502 2013-07-13 08:41:41 CodesInChaos__ has quit (Ping timeout: 264 seconds)
 503 2013-07-13 08:41:58 <TradeFortress> maybe I should go back to a self compiled 0.8.3?
 504 2013-07-13 08:42:05 <TradeFortress> :/
 505 2013-07-13 08:42:11 <sipa> that should be the first thing to try
 506 2013-07-13 08:42:34 <TradeFortress> I started with self compiled 0.8.3
 507 2013-07-13 08:42:34 <sipa> to assess whether the corruotion is because of the ppa or because of a difference between head and 0.8 e
 508 2013-07-13 08:42:38 <sipa> i know
 509 2013-07-13 08:42:45 <TradeFortress> ok, so how would I properly go back with git?
 510 2013-07-13 08:43:01 <sipa> git checkout v0.8.3
 511 2013-07-13 08:43:09 <sipa> and then rebuild
 512 2013-07-13 08:44:15 <sipa> how reproducible are these deadlocks?
 513 2013-07-13 08:44:36 <TradeFortress> funnily enough they only happen when I am away / asleep
 514 2013-07-13 08:44:40 <sipa> as in, how frequently do they occue
 515 2013-07-13 08:44:41 ivan\ has quit (Ping timeout: 264 seconds)
 516 2013-07-13 08:44:46 <TradeFortress> once every 1-2 days
 517 2013-07-13 08:44:50 Eiii has quit ()
 518 2013-07-13 08:44:50 <sipa> ok
 519 2013-07-13 08:45:03 <sipa> is your wallet encrypted?
 520 2013-07-13 08:45:07 <TradeFortress> every time that happens someone gets coins sent but their balance not deducted. so I'm outta ~10 btc alreadyn
 521 2013-07-13 08:45:08 <TradeFortress> no
 522 2013-07-13 08:45:34 <helo> if you haven't made any progress by tomorrow, i'll try to write some scripts to hammer on my debug build and get a deadlock
 523 2013-07-13 08:45:35 <sipa> ow
 524 2013-07-13 08:45:35 <TradeFortress> not bitcoind's fault, my fault for assuming rpc error = coins not sent
 525 2013-07-13 08:45:57 <TradeFortress> it's ok I can cover that, I spent more on other things anyway
 526 2013-07-13 08:46:14 <sipa> but there is no rpc error, only a timeout, i guess?
 527 2013-07-13 08:46:19 ivan\ has joined
 528 2013-07-13 08:46:20 <TradeFortress> yeah, just a timeout
 529 2013-07-13 08:46:29 <sipa> well that's an error too of course
 530 2013-07-13 08:46:48 <TradeFortress> anyway this isn't machine specific, I've already changed
 531 2013-07-13 08:47:55 <sipa> does 0.8.1 have the problem too?
 532 2013-07-13 08:48:01 <TradeFortress> haven't tried v0.8.1
 533 2013-07-13 08:48:04 <sipa> the deadlocks i mean
 534 2013-07-13 08:48:08 <TradeFortress> and it'd be a bad idea to run that anyway
 535 2013-07-13 08:48:36 GMP has quit (Ping timeout: 240 seconds)
 536 2013-07-13 08:48:59 <sipa> well... testing in production :)
 537 2013-07-13 08:49:40 <TradeFortress> not like I have a choice haha
 538 2013-07-13 08:50:04 tholenst has quit (Remote host closed the connection)
 539 2013-07-13 08:50:52 <TradeFortress> I think it may have something to do with coin selection
 540 2013-07-13 08:50:57 <TradeFortress> v0.8.3 built, will try
 541 2013-07-13 08:51:44 <TradeFortress> v0.8.3: wallet corrupted
 542 2013-07-13 08:53:14 <sipa> with the exact same file as one that works in head?
 543 2013-07-13 08:53:20 <TradeFortress> uh huh
 544 2013-07-13 08:53:34 <TradeFortress> yeah it doesn't load any wallet.dats
 545 2013-07-13 08:53:41 <sipa> ok, so we have a backward compatibility problem
 546 2013-07-13 08:53:48 <sipa> interesting
 547 2013-07-13 08:54:01 <TradeFortress> which is probably something that should be solved before another versoin :P
 548 2013-07-13 08:54:11 <sipa> of course
 549 2013-07-13 08:54:18 <TradeFortress> I could build the debug version and help track it down?
 550 2013-07-13 08:55:40 <TradeFortress> i probably need to go back to master. and keep running that for the time being
 551 2013-07-13 08:57:20 Apexseals has quit (Ping timeout: 260 seconds)
 552 2013-07-13 08:57:32 <TradeFortress> out of the box "fix": if sendtoaddress takes more than 5 seconds, kill bitcoind, assume send went through, and restart bitcoind
 553 2013-07-13 08:57:38 CodesInChaos__ has joined
 554 2013-07-13 09:00:21 <TradeFortress> sipa: you don't have a "if beta throw random deadlock" function to discourage using it for mining / merchant applications anywhere in the code, right?
 555 2013-07-13 09:00:59 CodesInChaos_ has quit (Ping timeout: 240 seconds)
 556 2013-07-13 09:01:58 wamatt has quit (Read error: Connection reset by peer)
 557 2013-07-13 09:03:22 <sipa> no
 558 2013-07-13 09:03:48 <sipa> TradeFortress: is anythimg written in debug.log when this wallet corrupted appears in 0.8.3?
 559 2013-07-13 09:06:49 <TradeFortress> Commiting 29k changed transactions to coin database.. FLush(true)
 560 2013-07-13 09:07:04 <TradeFortress> wallet.dat refcount=0; wallet.dat checpoint; wallet.dat detach; wallet.dat closed; DBFlush(true) ended
 561 2013-07-13 09:07:33 CodesInChaos_ has joined
 562 2013-07-13 09:07:34 <TradeFortress> OH WAIT
 563 2013-07-13 09:07:35 <sipa> that's too far
 564 2013-07-13 09:07:41 <TradeFortress> sipa, CPrivKey pubkey inconsistency
 565 2013-07-13 09:07:54 <TradeFortress> I literally see this like 1000+ times
 566 2013-07-13 09:08:07 <TradeFortress> my debug.log has more than 60,000 lines
 567 2013-07-13 09:08:12 <sipa> and head doesn't complain about that?
 568 2013-07-13 09:09:40 <TradeFortress> no, it is happy accepting transactions
 569 2013-07-13 09:09:45 <TradeFortress> happily*
 570 2013-07-13 09:10:38 CodesInChaos__ has quit (Ping timeout: 245 seconds)
 571 2013-07-13 09:11:07 wamatt has joined
 572 2013-07-13 09:11:35 <TradeFortress> would seeing parts of the wallet.dat help?
 573 2013-07-13 09:14:01 qua-non has joined
 574 2013-07-13 09:15:44 <sipa> i know enough
 575 2013-07-13 09:16:19 <sipa> there was a refactor of the private-key handling code in head
 576 2013-07-13 09:16:44 darkee_ has joined
 577 2013-07-13 09:17:02 <warren> hmm... I included that refactor in litecoin-0.8.3.4
 578 2013-07-13 09:17:04 darkee_ is now known as darkee
 579 2013-07-13 09:17:18 <warren> for no particular reason other than to make it easier to drop-in secp256k1
 580 2013-07-13 09:17:38 <TradeFortress> sipa, well at least that refactor didn't eat up my private keys
 581 2013-07-13 09:18:00 <TradeFortress> have you ever had something that did that?
 582 2013-07-13 09:18:33 <warren> TradeFortress: I missed the earlier part of this conversation, what is the issue?
 583 2013-07-13 09:18:57 <warren> TradeFortress: I'm alarmed if the private-key handling refactor lead to a bug
 584 2013-07-13 09:19:18 qua-non has left ("Konversation terminated!")
 585 2013-07-13 09:21:00 <TradeFortress> warren, I experience unpredictable deadlocks when calling sendtoaddress
 586 2013-07-13 09:21:20 <TradeFortress> the rpc times out, bitcoind deadlocks, and I have to restart.
 587 2013-07-13 09:21:21 <warren> TradeFortress: with the refactor, or only after downgrade?
 588 2013-07-13 09:21:38 <TradeFortress> happened on 0.8.3, happened on head.
 589 2013-07-13 09:22:04 <warren> ok, so the privkey refactor didn't make it worse?
 590 2013-07-13 09:22:09 <TradeFortress> or.. that's what I think. I'm not sure if I *actually* ran 0.8.3
 591 2013-07-13 09:22:21 <TradeFortress> I'm a noobie when it comes to git.. I don't think git checkout was what I typed.
 592 2013-07-13 09:22:24 <warren> TradeFortress: i'm very interested in what you find
 593 2013-07-13 09:22:37 <TradeFortress> so am I because I lose coins everytime Iit deadlocks
 594 2013-07-13 09:22:43 <TradeFortress> :P
 595 2013-07-13 09:23:34 abrkn has quit (Ping timeout: 260 seconds)
 596 2013-07-13 09:24:00 paraipan has quit (Remote host closed the connection)
 597 2013-07-13 09:27:00 <TradeFortress> what is the least resource intensive rpc function that I can check query to see if there's a deadlock?
 598 2013-07-13 09:27:36 <warren> can you reproduce it on testnet?
 599 2013-07-13 09:28:16 <warren> TradeFortress: make a backup of the entire .bitcoin and try a -reindex, problems continue after?
 600 2013-07-13 09:28:19 GordonG3kko has quit (Remote host closed the connection)
 601 2013-07-13 09:28:28 <Scrat> TradeFortress: what HDD are you using, also whats your iowait
 602 2013-07-13 09:28:36 CodesInChaos__ has joined
 603 2013-07-13 09:29:30 <TradeFortress> oh and I have txindex=1 if that matters
 604 2013-07-13 09:29:35 <warren> OH
 605 2013-07-13 09:29:38 <TradeFortress> ?
 606 2013-07-13 09:29:49 <warren> just saying OH, that shouldn't matter
 607 2013-07-13 09:30:26 <TradeFortress> Scrat, not the hdd's issue, it's not confined to a machine. I believe it's a problem with the wallet.dat
 608 2013-07-13 09:30:34 paraipan has joined
 609 2013-07-13 09:30:50 GordonG3kko has joined
 610 2013-07-13 09:31:09 <Scrat> TradeFortress: had the same problem and it disappeared when I moved the thing to an SSD (literally copied the dir along with the wallet)
 611 2013-07-13 09:31:29 CodesInChaos_ has quit (Ping timeout: 264 seconds)
 612 2013-07-13 09:32:37 <Scrat> I was convinced that bitcoind did something funky with fsync which frequently locked up for ~10 seconds on a 5400 rpm drive (high load server)
 613 2013-07-13 09:37:18 <TradeFortress> Scrat, literally the same problem?
 614 2013-07-13 09:38:29 <Scrat> for whatever reason it is very sensitive to IO latency when sending
 615 2013-07-13 09:39:31 <TradeFortress> so it'd time out and then bitcoind deadlocks?
 616 2013-07-13 09:39:46 <warren> when I combine 67 inputs to send bitcoind/litecoind seems to lockup for a minute before sending
 617 2013-07-13 09:39:47 <sipa> slowdowns are not deadlocks
 618 2013-07-13 09:39:56 <warren> but it isn't a deadlock
 619 2013-07-13 09:40:08 <sipa> a MINUTE?
 620 2013-07-13 09:40:11 <sipa> :o
 621 2013-07-13 09:40:13 <warren> yeah
 622 2013-07-13 09:40:34 <Scrat> I'd have to kill it once in a while after waiting for like a minute, but on average it was 10 seconds under high server load
 623 2013-07-13 09:41:03 <TradeFortress> but this literally deadlocks for hours
 624 2013-07-13 09:41:20 <sipa> a deadlock is infinitre
 625 2013-07-13 09:41:46 <TradeFortress> yeah
 626 2013-07-13 09:41:46 <Scrat> oh, then I doubt it's the same issue
 627 2013-07-13 09:48:07 <TradeFortress> so there's nothing I could help debug when a deadlock happens again?
 628 2013-07-13 09:48:23 <warren> TradeFortress: are you SURE the other databases aren't corrupt?
 629 2013-07-13 09:48:50 <TradeFortress> warren, other databases? I have tried clearing out everything but wallet.dat
 630 2013-07-13 09:48:58 <warren> ok
 631 2013-07-13 09:49:34 <warren> TradeFortress: and you aren't sure if the privkey refactor is an issue here or not?
 632 2013-07-13 09:49:52 <TradeFortress> warren, I do not think it is, however I cannot be sure.
 633 2013-07-13 09:50:46 <TradeFortress> but
 634 2013-07-13 09:50:51 <TradeFortress> it is AFTER the tx has been sent to the network
 635 2013-07-13 09:51:12 <sipa> nothing wrt other databases happens then
 636 2013-07-13 09:51:37 <TradeFortress> does it store the tx locally then?
 637 2013-07-13 09:51:42 <sipa> in the wallet
 638 2013-07-13 09:51:45 <sipa> and it's not coin selection, as your transaction was already sent
 639 2013-07-13 09:51:54 <TradeFortress> it may not have been pushed out to the network, just stored
 640 2013-07-13 09:51:54 <warren> txindex=1 doesn't seem relevant here
 641 2013-07-13 09:52:07 <TradeFortress> as the actual sending time may be when I restart bitcoind and it finds a tx not broadcast
 642 2013-07-13 09:52:14 <sipa> right
 643 2013-07-13 09:52:20 <sipa> but still, coin selection was complete
 644 2013-07-13 09:52:55 <sipa> some debug.log lines from around the time of a deadlock would be useful
 645 2013-07-13 09:53:04 <warren> TradeFortress: was the wallet.dat always db4, or db5?
 646 2013-07-13 09:53:10 <TradeFortress> warren, db5
 647 2013-07-13 09:53:12 <warren> TradeFortress: what version of db5?
 648 2013-07-13 09:53:16 <TradeFortress> db5.1
 649 2013-07-13 09:53:44 <TradeFortress> I have been saving all my debug.log. but the total is 60k lines long. do you think there's anything I can narrow it down to deadlocks
 650 2013-07-13 09:54:00 <TradeFortress> like something that only happens when it starts up
 651 2013-07-13 09:54:15 <warren> sipa: would debuginfo, gdb thread apply all bt full help at his deadlock?
 652 2013-07-13 09:55:40 CodesInChaos__ has quit (Ping timeout: 260 seconds)
 653 2013-07-13 10:03:16 freewil has joined
 654 2013-07-13 10:11:23 toffoo has quit ()
 655 2013-07-13 10:13:27 RoboTeddy has quit (Remote host closed the connection)
 656 2013-07-13 10:18:13 <sipa> TradeFortress: the deadlock doesn't happen at startup, right?
 657 2013-07-13 10:18:26 <sipa> warren: yes
 658 2013-07-13 10:18:45 <TradeFortress> sipa, no
 659 2013-07-13 10:18:54 <TradeFortress> so when it deadlocks and this room is empty, what do I do with gdb
 660 2013-07-13 10:19:17 <sipa> attach to the deadlocked bitcoind
 661 2013-07-13 10:19:20 <warren> TradeFortress: make a bitcoind build with all debuginfo available
 662 2013-07-13 10:19:28 <sipa> oh yes, run a debug version from the start
 663 2013-07-13 10:19:37 <warren> TradeFortress: after the deadlock, in another terminal use: gdb attach <pid>
 664 2013-07-13 10:19:44 <warren> TradeFortress: then thread apply all bt full
 665 2013-07-13 10:20:04 <TradeFortress> "thread apply all bt full"
 666 2013-07-13 10:20:07 <TradeFortress> ?
 667 2013-07-13 10:20:11 <warren> I think...
 668 2013-07-13 10:20:29 <TradeFortress> and how do I do that?
 669 2013-07-13 10:20:34 <TradeFortress> (debug build)
 670 2013-07-13 10:20:52 <warren> TradeFortress: run gdb ./bitcoind, it might tell you what symbols in library deps are missing.  on fedora it even tells you the command to install all the debuginfo packages.  Not sure if ubuntu has that.
 671 2013-07-13 10:21:10 <warren> TradeFortress: a local build has the debuginfo by default, but your library deps probably don't
 672 2013-07-13 10:21:36 <TradeFortress> well I made using dev libraries
 673 2013-07-13 10:21:44 <warren> those dev libraries are stripped
 674 2013-07-13 10:21:55 <warren> I don't know if/how Ubuntu distributes debuginfo
 675 2013-07-13 10:22:07 <sipa> install libdb5.1-dbg
 676 2013-07-13 10:22:09 <warren> they're available in side-packages on fedora
 677 2013-07-13 10:22:11 <warren> ah
 678 2013-07-13 10:22:12 <warren> ok
 679 2013-07-13 10:24:35 <TradeFortress> k so i installed libdb5.1-dbg and remade it. now I do gdb ./bitcoind after stopping?
 680 2013-07-13 10:24:54 <warren> TradeFortress: no
 681 2013-07-13 10:25:06 <warren> TradeFortress: gdb ./bitcoind is just to test if debug symbols are available
 682 2013-07-13 10:25:12 <TradeFortress> ok
 683 2013-07-13 10:25:21 <warren> TradeFortress: run bitcoind normally and use "gdb attach" after the deadlock
 684 2013-07-13 10:25:36 <TradeFortress> when it actually happens, I type gdb attach "pid" and "thread apply all bt full" ?
 685 2013-07-13 10:25:58 <warren> I vaguely recall pid, I haven't done it in a month or two.
 686 2013-07-13 10:26:08 <sipa> with pid the pid of the bitcoind, not the string "pid"
 687 2013-07-13 10:26:19 <TradeFortress> lol I know what a pid is
 688 2013-07-13 10:26:37 OldEnK has quit (Quit: Leaving)
 689 2013-07-13 10:26:38 <sipa> ok!
 690 2013-07-13 10:43:53 <sipa> TradeFortress: i have a theory about the 0.8.3 incompatibility
 691 2013-07-13 10:44:05 <TradeFortress> sipa, wasn't that the wallet.dat refactor?
 692 2013-07-13 10:44:08 <TradeFortress> private key
 693 2013-07-13 10:44:44 <sipa> well, i suspected that that refactor introduced the incompatibility yes, but i didn't know what the exact problem was
 694 2013-07-13 10:44:47 <sipa> just where to look :)
 695 2013-07-13 10:48:51 <sipa> no, i'm wrong
 696 2013-07-13 10:49:44 BTCOxygen has joined
 697 2013-07-13 10:49:44 BTCOxygen is now known as Guest80592
 698 2013-07-13 10:49:45 Guest80592 has quit (Killed (hubbard.freenode.net (Nickname regained by services)))
 699 2013-07-13 10:49:45 BTCOxygen is now known as 1!~BTCOxygen@unaffiliated/oxygen|BTCOxygen
 700 2013-07-13 10:51:22 freewil has quit (Ping timeout: 256 seconds)
 701 2013-07-13 10:52:04 paraipan has quit (Quit: Saliendo)
 702 2013-07-13 10:53:34 paraipan has joined
 703 2013-07-13 10:55:19 wamatt has quit (Read error: Connection reset by peer)
 704 2013-07-13 10:56:46 <sipa> TradeFortress: can you make this change to 0.8.3, and try again: http://pastebin.com/bbA5AiF2 ?
 705 2013-07-13 10:57:11 <warren> sipa: if the refactor did introduce incompatibility is that a bug that must be fixed?  or downgrades are not supported?
 706 2013-07-13 10:57:32 <TradeFortress> ok sipa
 707 2013-07-13 10:57:55 <TradeFortress> I will test that when it deadlocks.. this is a prod enviroment I'm talking about anyway
 708 2013-07-13 10:58:37 <warren> sipa: I included the refactor in litecoin about a month ago.  we didn't release this version yet.
 709 2013-07-13 10:59:00 <sipa> warren: yes, if it's what i think it is, it's a bug
 710 2013-07-13 10:59:25 <warren> sipa: hmm, so I should pull it in our 0.8.3.x release, but doing so might screw up some early testers?
 711 2013-07-13 10:59:39 <warren> s/pull it/remove it from/
 712 2013-07-13 10:59:42 <sipa> that's always a risk with pre-releases, yes
 713 2013-07-13 11:00:07 <sipa> warren: wait, just to be clear: the incompatibility is in head, not in 0.8.3
 714 2013-07-13 11:00:20 <sipa> so it's a bug that must be fixed before head is released
 715 2013-07-13 11:00:26 <warren> sipa: https://github.com/litecoin-project/litecoin-0.8/commits/awesomecoin?page=2
 716 2013-07-13 11:00:46 <warren> sipa: we didn't release the litecoin with cprivkey refactor, but testers have been using it for a month now
 717 2013-07-13 11:00:58 <TradeFortress> hehe love the " No LTC support" :P
 718 2013-07-13 11:01:16 <warren> TradeFortress: Litecoin secp256k1 has already found a bug in secp256k1
 719 2013-07-13 11:01:33 <sipa> yeah, i have absolutely no problem with litecoin being a guinea pig :)
 720 2013-07-13 11:02:26 <warren> sipa: I've done thousands of sendtoaddress and haven't seen his problem though
 721 2013-07-13 11:02:40 <sipa> warren: i'm not talking about the deadlock at all
 722 2013-07-13 11:02:43 <warren> oh
 723 2013-07-13 11:02:43 <sipa> it's unrelated
 724 2013-07-13 11:02:55 <warren> sipa: what is the suspected bug?
 725 2013-07-13 11:03:07 <warren> sipa: we're close to release, I need to know if I should remove the refactor
 726 2013-07-13 11:03:25 <sipa> warren: git head always writes private keys with uncompressed pubkeys in them
 727 2013-07-13 11:04:02 <sipa> and i expected that previous versions used the length of the (separately stored) public key to determine whether it's supposed to be compressed or not
 728 2013-07-13 11:04:51 <sipa> TradeFortress: when was this wallet created?
 729 2013-07-13 11:05:23 <TradeFortress> v0.8.3 days
 730 2013-07-13 11:05:25 <sipa> TradeFortress: specifially, with which version?
 731 2013-07-13 11:05:26 <sipa> ok
 732 2013-07-13 11:05:36 <sipa> can you do a validateaddress <addr> for a random address in your wallet?
 733 2013-07-13 11:05:50 <sipa> and tell me the public key? (in PM in you prefer)
 734 2013-07-13 11:05:53 wamatt has joined
 735 2013-07-13 11:06:23 <warren> sipa:  in our case we never had an official release of 0.8.x so we don't need backward compatibility
 736 2013-07-13 11:06:36 <sipa> warren: but 0.8.* is unaffected!
 737 2013-07-13 11:06:42 <sipa> the problem is only in head
 738 2013-07-13 11:06:58 <sipa> whether you have a 0.8.x release is not relevant
 739 2013-07-13 11:06:59 <warren> sipa: we have 0.8.x + your privkey refactor
 740 2013-07-13 11:07:02 <sipa> ah
 741 2013-07-13 11:07:13 <warren> sipa: https://github.com/litecoin-project/litecoin-0.8/commits/awesomecoin?page=2  specifically those commits
 742 2013-07-13 11:07:30 <warren> sipa: as I was subjecting litecoin testers to secp256k1
 743 2013-07-13 11:09:17 <TradeFortress> sipa, iscompressed is yes
 744 2013-07-13 11:09:28 <sipa> ok
 745 2013-07-13 11:09:32 * warren checks here
 746 2013-07-13 11:10:31 <warren> sipa: So ... we're not concerned about backward compatibility, but if the refactor has a bug, I need to decide what to do about it before we release.
 747 2013-07-13 11:10:59 <sipa> if it is what i think it is, it's trivial to fix
 748 2013-07-13 11:12:08 <warren> The fixed refactor will be compatible with keys written by the unfixed refactor?
 749 2013-07-13 11:12:26 <warren> as we aren't concerned with backward compat (no 0.8.x releases) that would be fine
 750 2013-07-13 11:12:29 darkee has quit (Ping timeout: 240 seconds)
 751 2013-07-13 11:12:56 <sipa> yes
 752 2013-07-13 11:13:21 <warren> ok, delaying release for this and LOTS of testing
 753 2013-07-13 11:15:05 <warren> well hmm, the only drawback of not fixing the refactor is inability to downgrade to pre-refactor 0.8?
 754 2013-07-13 11:15:11 <sipa> yes
 755 2013-07-13 11:15:13 <warren> which we don't have
 756 2013-07-13 11:15:22 <sipa> any older litecoin?
 757 2013-07-13 11:15:26 <warren> 0.6.x
 758 2013-07-13 11:15:29 <sipa> yes
 759 2013-07-13 11:15:39 <warren> 0.8.x is a full rebase
 760 2013-07-13 11:15:49 <sipa> yes, so?
 761 2013-07-13 11:16:10 <sipa> it's generally very hard already to downgrade to pre-0.8
 762 2013-07-13 11:16:16 <sipa> because of the database changes
 763 2013-07-13 11:16:17 <warren> yeah, so no issue here
 764 2013-07-13 11:16:22 <sipa> but it's still possible
 765 2013-07-13 11:16:28 <sipa> wallets are intended to be backward compatible
 766 2013-07-13 11:16:43 <warren> between major versions?
 767 2013-07-13 11:16:48 <warren> didn't know that...
 768 2013-07-13 11:17:41 <sipa> you can actually create a wallet still that should be readable by 0.3.x or something
 769 2013-07-13 11:17:48 <sipa> (but by default it won't)
 770 2013-07-13 11:18:01 <warren> we expect 0.6.x will die quickly because Litecoin has no vendors integrated yet, no reason not to upgrade to 0.8.x when we release it.
 771 2013-07-13 11:18:02 <sipa> there's a walletversion in getinfo
 772 2013-07-13 11:18:10 <warren> ah
 773 2013-07-13 11:18:19 <sipa> which will tell you the earlier version that can read your wallet
 774 2013-07-13 11:18:42 <warren> 0.8.x will be the first version that vendors will likely use.
 775 2013-07-13 11:18:50 <sipa> 'vendors' ?
 776 2013-07-13 11:19:17 <warren> err... people who modify the client for whatever purpose and are resistant to upgrades in the future
 777 2013-07-13 11:19:50 <sipa> ok, bug confirmed
 778 2013-07-13 11:23:05 darkee has joined
 779 2013-07-13 11:24:17 <sipa> and fix confirmed too
 780 2013-07-13 11:24:27 <warren> cool
 781 2013-07-13 11:25:55 <warren> sipa: validateaddress should be able to see the bug?
 782 2013-07-13 11:26:09 <sipa> no
 783 2013-07-13 11:26:26 <sipa> to reproduce: create a new wallet using head, and try to load it in 0.8.3
 784 2013-07-13 11:26:43 <warren> in my case, rebuild with refactor reverted
 785 2013-07-13 11:27:25 <warren> anyway, if you confrmed the bug, then we have it too.
 786 2013-07-13 11:28:52 <sipa> #2825 fixes it
 787 2013-07-13 11:29:07 <warren> trying without, with, and #2825
 788 2013-07-13 11:29:35 <sipa> a 'broken' wallet will not be fixed by running with #2825, however
 789 2013-07-13 11:31:24 <warren> we're not concerned, we have no client releases that are expected to read those "broken" wallets
 790 2013-07-13 11:31:30 <sipa> yeah
 791 2013-07-13 11:33:05 c0rw1n has joined
 792 2013-07-13 11:44:35 <warren> sipa: thank you!
 793 2013-07-13 11:46:47 c0rw1n has quit (Remote host closed the connection)
 794 2013-07-13 11:48:01 egis has joined
 795 2013-07-13 11:48:02 c0rw1n has joined
 796 2013-07-13 11:59:45 zer0def has quit (Quit: Quit:)
 797 2013-07-13 12:00:13 zer0def has joined
 798 2013-07-13 12:15:59 handle_ has joined
 799 2013-07-13 12:18:10 random_cat has quit (Ping timeout: 240 seconds)
 800 2013-07-13 12:18:10 handle has quit (Ping timeout: 240 seconds)
 801 2013-07-13 12:19:22 c0rw1n has quit (Remote host closed the connection)
 802 2013-07-13 12:19:42 one_zero has quit ()
 803 2013-07-13 12:19:52 <warren> grrr, accidentally blew away my origin-pull config again
 804 2013-07-13 12:20:06 <warren> I should write down how to configure it...
 805 2013-07-13 12:21:31 weex has quit (Ping timeout: 240 seconds)
 806 2013-07-13 12:26:40 random_cat has joined
 807 2013-07-13 12:34:44 jerkbot1 has quit (Ping timeout: 240 seconds)
 808 2013-07-13 12:43:15 imton has joined
 809 2013-07-13 12:49:07 cads has quit (Ping timeout: 246 seconds)
 810 2013-07-13 12:57:55 Vinnie_win has joined
 811 2013-07-13 13:02:08 Jere_Jones has joined
 812 2013-07-13 13:08:01 egis has quit (Quit: Leaving)
 813 2013-07-13 13:34:13 wamatt has quit (Quit: wamatt)
 814 2013-07-13 13:48:04 PK has joined
 815 2013-07-13 13:49:44 <warren> sipa: your secp256k1 patches need a rebase after that
 816 2013-07-13 13:53:22 ThomasV has joined
 817 2013-07-13 14:00:54 peetaur2 has joined
 818 2013-07-13 14:01:27 rdponticelli has joined
 819 2013-07-13 14:02:50 graingert has joined
 820 2013-07-13 14:07:08 fishfish_ has quit (Quit: Bye!)
 821 2013-07-13 14:10:23 sturles has joined
 822 2013-07-13 14:15:02 Squidicuz has quit (Read error: Connection reset by peer)
 823 2013-07-13 14:15:22 <sipa> warren: i know; will do after it's merged
 824 2013-07-13 14:15:29 Squidicuz has joined
 825 2013-07-13 14:29:13 egis has joined
 826 2013-07-13 14:33:28 chmod755 has joined
 827 2013-07-13 14:36:24 PiZZaMaN2K is now known as PiZZaMaN2K|away
 828 2013-07-13 14:36:25 sirk1t has joined
 829 2013-07-13 14:41:53 TradeFortress has quit (Ping timeout: 245 seconds)
 830 2013-07-13 14:56:29 stochasm has quit (Ping timeout: 246 seconds)
 831 2013-07-13 15:01:51 ThomasV has quit (Ping timeout: 256 seconds)
 832 2013-07-13 15:05:00 ThomasV has joined
 833 2013-07-13 15:10:33 rlifchitz has quit (Remote host closed the connection)
 834 2013-07-13 15:23:47 ThomasV has quit (Ping timeout: 240 seconds)
 835 2013-07-13 15:28:02 Subo1978 has joined
 836 2013-07-13 15:31:10 Subo1978_ has quit (Ping timeout: 240 seconds)
 837 2013-07-13 15:34:42 imton has quit (Quit: imton)
 838 2013-07-13 15:36:07 imton has joined
 839 2013-07-13 15:41:47 MobPhone has quit (Ping timeout: 240 seconds)
 840 2013-07-13 15:42:26 MobPhone has joined
 841 2013-07-13 15:42:34 MobPhone has quit (Read error: Connection reset by peer)
 842 2013-07-13 15:43:45 imton has quit (Quit: imton)
 843 2013-07-13 15:46:48 fanquake has quit (Quit: fanquake)
 844 2013-07-13 15:49:19 tholenst has joined
 845 2013-07-13 15:49:34 JKL1234- has quit (Quit: I'm using a Free IRC Bouncer from BNC4FREE - http://bnc4free.com/)
 846 2013-07-13 15:50:04 sirk1t has quit (Quit: sirk1t)
 847 2013-07-13 15:55:05 wiretapped has quit (Remote host closed the connection)
 848 2013-07-13 15:55:05 MobiusL has quit (Remote host closed the connection)
 849 2013-07-13 15:55:06 cypher_ has quit (Write error: Broken pipe)
 850 2013-07-13 15:55:23 wiretapped has joined
 851 2013-07-13 15:56:05 cypher_ has joined
 852 2013-07-13 15:56:48 rfish has joined
 853 2013-07-13 15:57:13 <rfish> hey, I was looking at BTC-E's website, and it looks like it is vulnerable to a CSFR attack
 854 2013-07-13 16:02:37 chmod755 has quit (Quit: Leaving)
 855 2013-07-13 16:04:23 graingert has quit (Ping timeout: 245 seconds)
 856 2013-07-13 16:06:31 MobiusL has joined
 857 2013-07-13 16:21:03 TradeFortress has joined
 858 2013-07-13 16:21:05 <TradeFortress> help
 859 2013-07-13 16:21:18 <TradeFortress> bitcoind deadlock again
 860 2013-07-13 16:23:35 paracyst has quit ()
 861 2013-07-13 16:23:37 <sipa> TradeFortress: ping
 862 2013-07-13 16:23:46 <sipa> can you gdb attach?
 863 2013-07-13 16:24:41 <TradeFortress> sipa, yes
 864 2013-07-13 16:24:50 <TradeFortress> I have debug.log. it was after selectcoins, committransaction
 865 2013-07-13 16:25:02 <TradeFortress> and then addtowallet
 866 2013-07-13 16:25:19 <TradeFortress> Flush wallet.dat, getbalance twice and then socket.closed and a bunch of disconnects
 867 2013-07-13 16:26:21 <TradeFortress> sipa, I attached what do I do
 868 2013-07-13 16:28:06 <sipa> thread apply all bt all
 869 2013-07-13 16:28:21 <sipa> and pastebin the output or something
 870 2013-07-13 16:28:29 <sipa> eh
 871 2013-07-13 16:28:32 <sipa> thread apply all bt full
 872 2013-07-13 16:29:35 <TradeFortress> sipa, pastein.com/0dHYn1zW
 873 2013-07-13 16:29:41 <TradeFortress> pastebin.com/0dHYn1zW
 874 2013-07-13 16:30:38 <sipa> that's only a small piece
 875 2013-07-13 16:30:53 <sipa> it'll likely be several pages of output
 876 2013-07-13 16:31:16 <TradeFortress> yeah goes type return to continue
 877 2013-07-13 16:31:50 <sipa> yeah, i'd like to see the rest of the output too :)
 878 2013-07-13 16:32:08 <TradeFortress> this like never ends
 879 2013-07-13 16:32:11 <TradeFortress> can I cat it to a file
 880 2013-07-13 16:32:15 <TradeFortress> I feel like my buffer is going to be overwritten
 881 2013-07-13 16:32:44 <sipa> ?
 882 2013-07-13 16:33:03 <TradeFortress> I'm accessing through terminal
 883 2013-07-13 16:33:07 <TradeFortress> I will only see the last x lines or whatever
 884 2013-07-13 16:33:39 <sipa> it pauses after every page written
 885 2013-07-13 16:34:02 <TradeFortress> You expect me to copy that 30 times or so? Can't I dump it to a txt file
 886 2013-07-13 16:34:41 <sipa> sec
 887 2013-07-13 16:34:46 <sipa> exit gdb
 888 2013-07-13 16:34:51 <sipa> and do this:
 889 2013-07-13 16:35:04 <TradeFortress> ok
 890 2013-07-13 16:35:05 <sipa> gdb -batch -ex 'attach 5736' -ex 'thread apply all bt full' | tee stacktrace.txt
 891 2013-07-13 16:35:11 <sipa> with 5736 the pid
 892 2013-07-13 16:36:26 <TradeFortress> GOT IT
 893 2013-07-13 16:38:26 <sipa> can you put it somewhere?
 894 2013-07-13 16:39:47 <TradeFortress> sipa: http://pastebin.com/3uZua1A5
 895 2013-07-13 16:42:50 <TradeFortress> find the cause and I will tip 20 BTC
 896 2013-07-13 16:47:16 DiabloD3 has joined
 897 2013-07-13 16:48:47 <TradeFortress> out of curiosirty, how do you freakng debug that?
 898 2013-07-13 16:48:51 hsmiths has quit (Read error: Connection reset by peer)
 899 2013-07-13 16:50:32 johnsoft has quit (Ping timeout: 260 seconds)
 900 2013-07-13 16:52:34 <sipa> are you sure this deadlock occurred in 0.8.3 as well?
 901 2013-07-13 16:52:46 hsmiths has joined
 902 2013-07-13 16:52:55 <sipa> one of the locked threads is blocked on something that was added in head only
 903 2013-07-13 16:52:59 Applica__ has quit (Ping timeout: 240 seconds)
 904 2013-07-13 16:53:35 Application has joined
 905 2013-07-13 16:54:55 Applicat_ has joined
 906 2013-07-13 16:55:36 <sipa> TradeFortress: i found a deadlock
 907 2013-07-13 16:55:45 <TradeFortress> sipa, you did?
 908 2013-07-13 16:55:46 <sipa> TradeFortress: though it shouldn't have been present in 0.8.3
 909 2013-07-13 16:55:52 <TradeFortress> holy shit
 910 2013-07-13 16:57:24 <TradeFortress> sipa, i probably never used v0.8.3 in the first place. I'm bad with git, you know
 911 2013-07-13 16:57:47 Application has quit (Ping timeout: 240 seconds)
 912 2013-07-13 16:57:55 <sipa> i'll try to find a fix later today
 913 2013-07-13 16:57:58 <sipa> gotta go now
 914 2013-07-13 17:00:54 <TradeFortress> okay..
 915 2013-07-13 17:00:58 <CodeShark> TradeFortress: what are the steps to reproduce this issue?
 916 2013-07-13 17:01:05 <TradeFortress> I hope I can pull it tomorrow when I wake up. CodeShark sendtoaddress
 917 2013-07-13 17:01:07 <TradeFortress> occurs randomly
 918 2013-07-13 17:01:09 <gmaxwell> TradeFortress: do try to take care when reporting bugs, I spent a fair amount of time w/ 0.8.3 on testnet trying to reproduce your deadlock. :P
 919 2013-07-13 17:01:39 <sipa> you need a payment being received simultaneously with sending one
 920 2013-07-13 17:02:05 <gmaxwell> How about sending to yourself?
 921 2013-07-13 17:02:17 <sipa> one first locks setpwalletregistered first, the other locks wallet first
 922 2013-07-13 17:02:38 <sipa> setpwalletregistered needs a shared lock, i think
 923 2013-07-13 17:02:45 awaxa has left ()
 924 2013-07-13 17:02:52 <sipa> though i'll need to think whether there are no edge cases
 925 2013-07-13 17:02:54 <CodeShark> I remember we had discussed something along those lines
 926 2013-07-13 17:03:11 <CodeShark> the locks in the wallet registration functions are too strict
 927 2013-07-13 17:03:39 <CodeShark> really, it's only when registering and unregistering that we need a mutex
 928 2013-07-13 17:03:54 <sipa> well, you still don't want to modify them while it's being used
 929 2013-07-13 17:04:25 <sipa> amyway, afk
 930 2013-07-13 17:04:35 <CodeShark> it's ok if say, SyncWithWallets and EraseFromWallets are called concurrently
 931 2013-07-13 17:04:45 <TradeFortress> gmaxwell, I am sorry
 932 2013-07-13 17:04:50 <TradeFortress> I'll share 20 BTC with the core dev team anyway
 933 2013-07-13 17:04:54 <CodeShark> since the wallet locks should handle those situations
 934 2013-07-13 17:05:29 <CodeShark> but it's not ok if UnregisterWallet and EraseFromWallets are called concurrently
 935 2013-07-13 17:07:19 <CodeShark> so we need something a little bit more than just a simple lock
 936 2013-07-13 17:07:36 <gmaxwell> TradeFortress: no biggie, it happens, don't worry about it— and thanks for actually testing git and reporting the deadlock.
 937 2013-07-13 17:07:58 <TradeFortress> gmaxwell, i loes coins every time it happens
 938 2013-07-13 17:08:08 <CodeShark> sipa is far more an expert than I am on sync stuff, though :)
 939 2013-07-13 17:09:04 <gmaxwell> TradeFortress: hm? presumably they'll get picked up in a rescan.
 940 2013-07-13 17:09:22 <TradeFortress> gmaxwell, no. basically I treat errors as coins not sent
 941 2013-07-13 17:09:24 <TradeFortress> time outs are errors.
 942 2013-07-13 17:09:32 <TradeFortress> not sent means the balance goes back and isn't sent. but the coins are sent.
 943 2013-07-13 17:18:42 hsmiths has quit (Quit: Nettalk6 - www.ntalk.de)
 944 2013-07-13 17:20:06 <gmaxwell> TradeFortress: you should perhapt not be running untested snapshots from git in production then...
 945 2013-07-13 17:20:31 <TradeFortress> gmaxwell, definitely, i thought I was through
 946 2013-07-13 17:20:36 <gmaxwell> (although, if you hadn't found this its possible it would have made it into the next release too—  we simply need more testing)
 947 2013-07-13 17:21:09 <CodeShark> I think I have a fix for that, TradeFortress
 948 2013-07-13 17:21:22 <CodeShark> sipa is right - we need a shared lock
 949 2013-07-13 17:21:36 <CodeShark> testing the fix - will post shortly
 950 2013-07-13 17:21:40 <TradeFortress> ok, cool
 951 2013-07-13 17:22:07 ThomasV has joined
 952 2013-07-13 17:33:14 hsmiths has joined
 953 2013-07-13 17:35:11 mappum has joined
 954 2013-07-13 17:37:26 <CodeShark> TradeFortress: https://github.com/bitcoin/bitcoin/pull/2828
 955 2013-07-13 17:38:42 sirk1t has joined
 956 2013-07-13 17:40:20 <CodeShark> we might want to add some more macros to sync.h for shared locks
 957 2013-07-13 17:42:53 <TradeFortress> codeshark and how'd I test that?
 958 2013-07-13 17:43:11 <CodeShark> try to reproduce your earlier deadlock
 959 2013-07-13 17:44:12 <CodeShark> attempt multiple simultaneous operations on the wallet, I suppose
 960 2013-07-13 17:45:25 <TradeFortress> has that code been tested? I am doing it on prod after all
 961 2013-07-13 17:45:48 MobPhone has joined
 962 2013-07-13 17:46:13 <CodeShark> I definitely would like other devs to look at it before using it for prod.
 963 2013-07-13 17:46:28 <CodeShark> sipa in particular
 964 2013-07-13 17:47:05 <CodeShark> the code builds and seems to run correctly for me - but I haven't done very rigorous testing on it
 965 2013-07-13 17:48:10 <CodeShark> very rigorous testing would require deliberately creating circumstances where multiple wallet operations are performed concurrently
 966 2013-07-13 17:48:35 tholenst has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 967 2013-07-13 17:50:19 <CodeShark> it is my understanding that none of the functions I modified should lock at all except for the registration and unregistration functions, which currently are only called when the program starts and stops
 968 2013-07-13 17:51:25 <CodeShark> and if I understood sipa correctly (I haven't looked at all your output), the problem was that the RPC was locking the wallet before locking the registration functions while main was doing the opposite
 969 2013-07-13 18:01:29 Zoop_ has quit ()
 970 2013-07-13 18:03:04 digitalmagus2 has joined
 971 2013-07-13 18:05:32 JZavala has quit (Ping timeout: 256 seconds)
 972 2013-07-13 18:09:17 hsmiths has quit (Quit: Nettalk6 - www.ntalk.de)
 973 2013-07-13 18:10:56 hsmiths has joined
 974 2013-07-13 18:23:54 sirk1t has quit (Ping timeout: 260 seconds)
 975 2013-07-13 18:26:56 Applicat_ has quit (Remote host closed the connection)
 976 2013-07-13 18:28:11 Jasmin68k has joined
 977 2013-07-13 18:28:20 fishfish has joined
 978 2013-07-13 18:29:22 RoboTeddy has joined
 979 2013-07-13 18:29:34 hsmiths has quit (Read error: Connection reset by peer)
 980 2013-07-13 18:33:14 hsmiths has joined
 981 2013-07-13 18:36:22 wamatt has joined
 982 2013-07-13 18:49:35 Zoop_ has joined
 983 2013-07-13 18:49:53 peetaur2 has quit (Quit: Konversation terminated!)
 984 2013-07-13 18:54:40 peetaur2 has joined
 985 2013-07-13 19:01:58 Scrat is now known as NSAbot
 986 2013-07-13 19:02:28 NSAbot is now known as Guest27366
 987 2013-07-13 19:02:39 Guest27366 is now known as Scrat
 988 2013-07-13 19:04:28 hsmiths has quit (Read error: Connection reset by peer)
 989 2013-07-13 19:08:09 santoscork has joined
 990 2013-07-13 19:09:29 hsmiths has joined
 991 2013-07-13 19:14:28 wamatt has quit (Read error: Connection reset by peer)
 992 2013-07-13 19:15:08 TradeFortress has quit (Quit: Leaving)
 993 2013-07-13 19:17:41 <sipa> CodeShark: a shared lock will work, but there is still a (much smaller) chance for deadlock when you modify the registered wallet set while a callback is happening
 994 2013-07-13 19:17:48 <sipa> i think
 995 2013-07-13 19:19:45 robocoin_ has quit (Remote host closed the connection)
 996 2013-07-13 19:22:24 robocoin has joined
 997 2013-07-13 19:27:50 hsmiths has quit (Read error: Connection reset by peer)
 998 2013-07-13 19:30:01 <CodeShark> in principle each wallet should be responsible for protecting its own integrity when used reentrantly
 999 2013-07-13 19:30:11 hsmiths has joined
1000 2013-07-13 19:30:38 <CodeShark> how would a deadlock occur?
1001 2013-07-13 19:30:52 <CodeShark> oh, you mean if you modify the container
1002 2013-07-13 19:30:59 robocoin has quit (Ping timeout: 240 seconds)
1003 2013-07-13 19:31:54 <CodeShark> if you add or remove a wallet to or from the registered wallet set then yes, you could get a deadlock
1004 2013-07-13 19:32:42 <CodeShark> the RPC code would have to be surrounded by a shared lock
1005 2013-07-13 19:33:26 <CodeShark> I'm not a big fan of externing that mutex, though
1006 2013-07-13 19:33:32 wamatt has joined
1007 2013-07-13 19:34:15 wamatt has quit (Read error: Connection reset by peer)
1008 2013-07-13 19:35:58 robocoin has joined
1009 2013-07-13 19:35:58 <warren> sipa: which post-0.8.3 commit introduced the deadlock?
1010 2013-07-13 19:37:29 wamatt has joined
1011 2013-07-13 19:37:50 <sipa> warren: only in head
1012 2013-07-13 19:38:17 <warren> sipa: I know, just wondering which commit it was
1013 2013-07-13 19:38:57 <warren> oh, I see CodeShark's PR, i'll figure it out
1014 2013-07-13 19:39:42 filleokus has left ("Linkinus - http://linkinus.com")
1015 2013-07-13 19:44:12 k9quaint_ has quit (Changing host)
1016 2013-07-13 19:44:12 k9quaint_ has joined
1017 2013-07-13 19:44:51 Application has joined
1018 2013-07-13 19:46:10 Applicat_ has joined
1019 2013-07-13 19:48:52 Gnaf has joined
1020 2013-07-13 19:49:07 Application has quit (Ping timeout: 246 seconds)
1021 2013-07-13 19:49:25 santoscork has quit (Quit: Quiet while I make like a cat)
1022 2013-07-13 19:49:52 <warren> sipa: CodeShark: is there a reproduce case for this deadlock?
1023 2013-07-13 19:50:38 ThomasV has quit (Remote host closed the connection)
1024 2013-07-13 19:52:25 wamatt has quit (Read error: Connection reset by peer)
1025 2013-07-13 19:54:43 BurtyB has quit (Read error: Connection reset by peer)
1026 2013-07-13 19:55:14 BurtyB has joined
1027 2013-07-13 19:55:25 hsmiths has quit (Quit: Nettalk6 - www.ntalk.de)
1028 2013-07-13 19:57:00 hsmiths has joined
1029 2013-07-13 19:59:10 peter_ has joined
1030 2013-07-13 19:59:18 peetaur2 has quit (Read error: Operation timed out)
1031 2013-07-13 19:59:34 peter_ is now known as Guest5289
1032 2013-07-13 20:09:20 ThomasV has joined
1033 2013-07-13 20:14:29 OldEnK has joined
1034 2013-07-13 20:20:09 peetaur2 has joined
1035 2013-07-13 20:22:35 Guest5289 has quit (Ping timeout: 240 seconds)
1036 2013-07-13 20:29:18 jeewee has quit (Read error: Connection reset by peer)
1037 2013-07-13 20:31:44 Applicat_ has quit (Remote host closed the connection)
1038 2013-07-13 20:35:33 cads has joined
1039 2013-07-13 20:43:44 serp has joined
1040 2013-07-13 20:46:34 hsmiths has quit (Read error: Connection reset by peer)
1041 2013-07-13 20:47:04 i2pRelay has joined
1042 2013-07-13 20:47:49 CodesInChaos_ has joined
1043 2013-07-13 20:48:26 hsmiths has joined
1044 2013-07-13 20:49:46 peetaur2 has quit (Read error: Operation timed out)
1045 2013-07-13 20:54:01 rfish has quit (Read error: Connection reset by peer)
1046 2013-07-13 21:01:30 jaromil has quit (Ping timeout: 248 seconds)
1047 2013-07-13 21:07:32 CodesInChaos__ has joined
1048 2013-07-13 21:07:44 CodesInChaos_ has quit (Read error: Connection reset by peer)
1049 2013-07-13 21:12:47 hsmiths has quit (Read error: Connection reset by peer)
1050 2013-07-13 21:13:55 <serp> If I'm using the rpc api and I use getblock to get info on a block it lists a bunch of transaction id/keys.  How can I use that id/key to get information about a transaction then?  I've tried using it with gettransaction, getrawtransaction, and decoderawtransaction without luck.
1051 2013-07-13 21:14:39 hsmiths has joined
1052 2013-07-13 21:15:48 <gmaxwell> serp: you need txindex enabled to get info on spent transactions via getrawtransaction.
1053 2013-07-13 21:16:25 <serp> i'm assuming that's going to increase disk usage a good bit
1054 2013-07-13 21:17:00 <warren> serp: a little slower too
1055 2013-07-13 21:17:13 <serp> ok... thank you all for the answer
1056 2013-07-13 21:18:27 <gmaxwell> serp: yup.
1057 2013-07-13 21:18:49 <gmaxwell> warren: It didn't seem to really matter much for anything I've tested.
1058 2013-07-13 21:19:01 <gmaxwell> (speed wise)
1059 2013-07-13 21:19:28 <gmaxwell> looks like it adds about 1.1GBytes right now.
1060 2013-07-13 21:19:33 <warren> ok
1061 2013-07-13 21:19:48 <serp> that's not too bad
1062 2013-07-13 21:19:52 <gmaxwell> maybe if you didn't have enough ram to get all the relevant data in ram.
1063 2013-07-13 21:19:58 <gmaxwell> serp: it'll grow more in the future, obviously.
1064 2013-07-13 21:20:03 <serp> right
1065 2013-07-13 21:20:20 <serp> all the latest blocks seem to have a lot more tx in them
1066 2013-07-13 21:20:31 <gmaxwell> Sure.
1067 2013-07-13 21:22:03 lle has joined
1068 2013-07-13 21:27:09 lle has quit ()
1069 2013-07-13 21:27:23 hsmiths has quit (Read error: Connection reset by peer)
1070 2013-07-13 21:28:18 hsmiths has joined
1071 2013-07-13 21:31:12 paracyst has joined
1072 2013-07-13 21:31:14 Toresh has quit (Read error: Connection reset by peer)
1073 2013-07-13 21:34:00 <Luke-Jr> serp: depending on what you need to do, getrawtransaction might be sufficient without txindex
1074 2013-07-13 21:34:25 <Luke-Jr> serp: basically, without txindex it will just error if the coins have been spent already; but if you know that isn't the case, you can ignore it
1075 2013-07-13 21:34:41 <Luke-Jr> so for example, post-processing a new block
1076 2013-07-13 21:35:06 <Luke-Jr> while coins might be spent in the same block, that shouldn't happen if you're controlling the receiving wallet and wait for confirms
1077 2013-07-13 21:35:11 sserrano44 has joined
1078 2013-07-13 21:37:27 cyrozap has joined
1079 2013-07-13 21:37:36 CodesInChaos_ has joined
1080 2013-07-13 21:38:12 CodesInChaos__ has quit (Read error: Connection reset by peer)
1081 2013-07-13 21:39:06 hsmiths has quit (Quit: Nettalk6 - www.ntalk.de)
1082 2013-07-13 21:40:09 cyrozap is now known as cyrozap-Away
1083 2013-07-13 21:41:08 hsmiths has joined
1084 2013-07-13 21:41:32 cyrozap-Away is now known as cyrozap
1085 2013-07-13 21:42:08 MC1984 has quit (Quit: Leaving)
1086 2013-07-13 21:42:26 Application has joined
1087 2013-07-13 21:43:08 Applicat_ has joined
1088 2013-07-13 21:43:59 cyrozap has quit (Quit: Bye!)
1089 2013-07-13 21:44:24 cyrozap has joined
1090 2013-07-13 21:45:55 ksh has joined
1091 2013-07-13 21:46:35 Application has quit (Ping timeout: 240 seconds)
1092 2013-07-13 21:47:27 CodesInChaos_ has quit (Read error: Connection reset by peer)
1093 2013-07-13 21:47:31 CodesInChaos__ has joined
1094 2013-07-13 21:48:37 cyrozap has quit (Client Quit)
1095 2013-07-13 21:48:59 cyrozap has joined
1096 2013-07-13 21:53:46 eculver has quit (Ping timeout: 248 seconds)
1097 2013-07-13 21:56:59 CodesInChaos__ has quit (Ping timeout: 240 seconds)
1098 2013-07-13 21:57:57 cyrozap has quit (Quit: Bye!)
1099 2013-07-13 21:59:48 <serp> Yeah, getrawtransaction was passing back a "No information available about transaction" error
1100 2013-07-13 22:00:39 <serp> it was for transactions in a different wallet
1101 2013-07-13 22:03:57 <Luke-Jr> yeah, depends on what you need it for
1102 2013-07-13 22:07:34 hsmiths has quit (Quit: Nettalk6 - www.ntalk.de)
1103 2013-07-13 22:08:09 Ukto has joined
1104 2013-07-13 22:08:28 hsmiths has joined
1105 2013-07-13 22:08:46 PK has quit ()
1106 2013-07-13 22:10:14 TradeFortress has joined
1107 2013-07-13 22:14:03 OOcean is now known as Mad7Scientist
1108 2013-07-13 22:16:05 saulimus has joined
1109 2013-07-13 22:25:43 c0rw1n has joined
1110 2013-07-13 22:26:29 Prattler has quit (Ping timeout: 245 seconds)
1111 2013-07-13 22:28:38 c0rw1n has quit (Remote host closed the connection)
1112 2013-07-13 22:29:49 Prattler has joined
1113 2013-07-13 22:32:29 c0rw1n has joined
1114 2013-07-13 22:41:29 ThomasV has quit (Ping timeout: 245 seconds)
1115 2013-07-13 22:42:52 ThomasV has joined
1116 2013-07-13 22:45:04 random_cat has quit (Remote host closed the connection)
1117 2013-07-13 22:46:14 random_cat has joined
1118 2013-07-13 22:48:25 TradeFortress has quit (Quit: Leaving)
1119 2013-07-13 22:52:21 TradeFortress has joined
1120 2013-07-13 22:53:24 Applicat_ has quit (Ping timeout: 240 seconds)
1121 2013-07-13 22:57:19 ThomasV has quit (Ping timeout: 245 seconds)
1122 2013-07-13 23:08:53 TradeFortress has quit (Quit: Leaving)
1123 2013-07-13 23:11:09 saulimus has quit (Disconnected by services)
1124 2013-07-13 23:15:21 Application has joined
1125 2013-07-13 23:15:53 Applicat_ has joined
1126 2013-07-13 23:15:59 Jasmin68k has quit (Quit: Leaving.)
1127 2013-07-13 23:19:24 Application has quit (Ping timeout: 240 seconds)
1128 2013-07-13 23:19:38 Cory has quit ()
1129 2013-07-13 23:25:56 TradeFortress has joined
1130 2013-07-13 23:26:06 <TradeFortress> How do I check which account an address belongs to
1131 2013-07-13 23:26:30 <sipa> what do you need that for?
1132 2013-07-13 23:26:44 egis has quit (Quit: Leaving)
1133 2013-07-13 23:27:08 <sipa> validateaddress will tell you
1134 2013-07-13 23:27:16 <TradeFortress> sipa, someone is complaining that their deposit was not credited. I looked at listtransactions for that users acc and nothing
1135 2013-07-13 23:27:54 <TradeFortress> sipa, OK, this account is correct however listtransactions isn't working
1136 2013-07-13 23:28:14 jaromil has joined
1137 2013-07-13 23:28:38 <sipa> that's remarkable
1138 2013-07-13 23:28:50 <sipa> is the transaction in the wallet at all
1139 2013-07-13 23:28:51 <sipa> ?
1140 2013-07-13 23:29:11 <TradeFortress> no. error: {"code":-5,"message":"Invalid or non-wallet transaction id"}
1141 2013-07-13 23:29:24 <TradeFortress> db8f80d2311c3b3e46a3205f898268e365208726bc8557690a0140678fe71718
1142 2013-07-13 23:30:11 <sipa> and 1JWLk4mGBwVuKbDb7UAnjr1zbd6fkvUmMu or 1CD73oJmamZSdkqVowPupxPknurmaLuqDT is the relevant address?
1143 2013-07-13 23:30:37 <TradeFortress> 1JWLk4mGBwVuKbDb7UAnjr1zbd6fkvUmMu
1144 2013-07-13 23:30:51 c0rw1n has quit (Remote host closed the connection)
1145 2013-07-13 23:31:00 <sipa> and validateaddress 1JWLk4mGBwVuKbDb7UAnjr1zbd6fkvUmMu says ismine?
1146 2013-07-13 23:31:08 <TradeFortress> true
1147 2013-07-13 23:31:12 <TradeFortress> and I have txindex=1 anyway
1148 2013-07-13 23:31:18 <sipa> that's not relevant
1149 2013-07-13 23:32:16 <sipa> i wonder, was that transaction perhaps received exactly when the deadlock occurred?
1150 2013-07-13 23:32:21 <sipa> perhaps even triggered it?
1151 2013-07-13 23:32:24 <TradeFortress> hmmm
1152 2013-07-13 23:32:28 <TradeFortress> I can getrawtransaction.
1153 2013-07-13 23:32:34 <sipa> yes, not relevant
1154 2013-07-13 23:32:46 <sipa> blockchain engine and wallet are almost entirely separate
1155 2013-07-13 23:33:09 <sipa> your deadlock involved a call to the wallet to inform it of a new transaction
1156 2013-07-13 23:33:34 <TradeFortress> hmm
1157 2013-07-13 23:33:48 <TradeFortress> Was there a patch to fix the deadlock btw?
1158 2013-07-13 23:33:52 <sipa> yes
1159 2013-07-13 23:34:03 <sipa> CodeShark wrote one, which will work in practice
1160 2013-07-13 23:34:11 <TradeFortress> work in practice .. ?
1161 2013-07-13 23:34:24 <sipa> in theory there is still a risk for deadlocks, but that won't be exposed until multiwallet
1162 2013-07-13 23:34:41 <TradeFortress> ok, so how do I apply this patch
1163 2013-07-13 23:35:15 <sipa> sorry, i'm tired now - i'm sure others can help you with that :)
1164 2013-07-13 23:35:29 <CodeShark> clone the repo, checkout the branch, build
1165 2013-07-13 23:35:30 <TradeFortress> ok. mornining here lol
1166 2013-07-13 23:35:36 <sipa> 1am here
1167 2013-07-13 23:35:36 <TradeFortress> ah so it's in head ok
1168 2013-07-13 23:35:44 <sipa> it's in head of that branch
1169 2013-07-13 23:35:48 <sipa> it's not in master head
1170 2013-07-13 23:35:49 <TradeFortress> which branch?
1171 2013-07-13 23:35:54 <TradeFortress> which branch do I checkout?
1172 2013-07-13 23:36:11 <sipa> afk :)
1173 2013-07-13 23:36:12 <CodeShark> one sec, TradeFortress
1174 2013-07-13 23:37:08 <CodeShark> TradeFortress: do you already have a local clone of the repo?
1175 2013-07-13 23:37:17 <TradeFortress> yeah!
1176 2013-07-13 23:37:28 <CodeShark> ok, then git remote add codeshark https://github.com/CodeShark/bitcoin.git
1177 2013-07-13 23:37:58 <CodeShark> then git fetch codeshark wallet_registration_shared_lock
1178 2013-07-13 23:38:42 <TradeFortress> done
1179 2013-07-13 23:38:47 <TradeFortress> git pull > build?
1180 2013-07-13 23:38:51 <CodeShark> then git branch --track wallet_registration_shared_lock codeshark/wallet_registration_shared_lock
1181 2013-07-13 23:39:06 <TradeFortress> not a valid obj name
1182 2013-07-13 23:39:22 <CodeShark> what happens if you do git branch -r?
1183 2013-07-13 23:39:46 <TradeFortress> I don't see anything like wallet_registration
1184 2013-07-13 23:40:34 <CodeShark> but the git fetch didn't cause any errors?
1185 2013-07-13 23:41:07 <TradeFortress> bope
1186 2013-07-13 23:41:17 <TradeFortress>  * branch            wallet_registration_shared_lock -> FETCH_HEAD
1187 2013-07-13 23:42:25 <CodeShark> try git config remote.codeshark.fetch +refs/heads/*:refs/remotes/codeshark/*
1188 2013-07-13 23:43:07 Jasmin68k has joined
1189 2013-07-13 23:43:20 <TradeFortress> Still not a valid object name.
1190 2013-07-13 23:44:34 <CodeShark> try git remote update
1191 2013-07-13 23:45:29 <TradeFortress> Branch wallet_registration_shared_lock set up to track remote branch wallet_registration_shared_lock from codeshark.
1192 2013-07-13 23:45:35 <CodeShark> ok, excellent
1193 2013-07-13 23:45:49 <CodeShark> so now if you do git branch, does this branch have the asterisk?
1194 2013-07-13 23:45:56 <TradeFortress> master has
1195 2013-07-13 23:46:05 <TradeFortress> I switched to the lock
1196 2013-07-13 23:47:14 <CodeShark> so main.cpp should now be using a shared_mutex for cs_setpwalletRegister
1197 2013-07-13 23:47:28 <CodeShark> if that's the case you're on the correct branch
1198 2013-07-13 23:47:39 <TradeFortress> yes
1199 2013-07-13 23:48:02 <TradeFortress> building
1200 2013-07-13 23:54:21 nimdAHK has joined
1201 2013-07-13 23:54:51 <TradeFortress> ok. lets hope no more deadlocks
1202 2013-07-13 23:54:57 <TradeFortress> CodeShark, what do I do in the future when I want to upgrade?
1203 2013-07-13 23:55:47 JKL1234- has joined
1204 2013-07-13 23:56:14 <CodeShark> hopefully we'll get this fix merged into master soon
1205 2013-07-13 23:56:22 <CodeShark> then you won't have to worry about it anymore :)
1206 2013-07-13 23:57:04 <CodeShark> if you do run into any problems, please let me know
1207 2013-07-13 23:57:54 <TradeFortress> ok
1208 2013-07-13 23:58:17 <CodeShark> if it does fix it, are you still offering rewards? ;)
1209 2013-07-13 23:58:56 <CodeShark> make sure to tip sipa
1210 2013-07-13 23:59:15 <CodeShark> because he was the one who discovered it