1 2012-02-25 01:29:46 <gruez> any devs here?
  2 2012-02-25 01:29:57 <gruez> I still have a problem with bitcoin-qt
  3 2012-02-25 01:30:11 <gruez> it crashes upon rpc connection
  4 2012-02-25 01:30:58 <gruez> http://pastie.org/private/3wvhcxgkthwpgqmnb7ttg
  5 2012-02-25 01:36:54 <luke-jr> gdb works on Windows? O.o
  6 2012-02-25 01:37:21 <gruez> luke-jr: sort-of
  7 2012-02-25 01:37:42 <gruez> if i start bitcoin-qt using gdb, it crashes upon startup
  8 2012-02-25 01:37:54 <gruez> if i attach to it after it has started
  9 2012-02-25 01:38:07 <gruez> it works, but it doesn't break when it encounters an error
 10 2012-02-25 01:39:47 <BlueMatt> arg, too many random unreliably reproduceable in a debugger issues on win32...
 11 2012-02-25 01:48:21 <BlueMatt> gruez: what did you use to build that?
 12 2012-02-25 01:48:29 <BlueMatt> is it the one I built?
 13 2012-02-25 01:51:28 <gruez> BlueMatt: yes
 14 2012-02-25 01:51:45 <gruez> SHA-1: E69181DAE234140C0EC29ACCC520BD51BDFC987E
 15 2012-02-25 01:54:43 <BlueMatt> hmm...
 16 2012-02-25 01:54:59 <BlueMatt> do you get a similar error with release versions?
 17 2012-02-25 01:55:05 <BlueMatt> or maybe the current version from jenkins?
 18 2012-02-25 01:55:18 <BlueMatt> http://jenkins.bluematt.me/job/Bitcoin/ws/
 19 2012-02-25 01:57:46 <gruez> BlueMatt: same problem with 0.5
 20 2012-02-25 01:57:49 <gruez> and 0.6 beta
 21 2012-02-25 01:58:18 <gruez> also
 22 2012-02-25 01:58:33 <gruez> is there a reason why symbols won't load in IDA?
 23 2012-02-25 01:58:48 <gruez> it's 322 MB, but all the functions are unnamed
 24 2012-02-25 01:59:04 <BlueMatt> yes, gcc produces different symbol formats from vc
 25 2012-02-25 01:59:50 <BlueMatt> dont know about function names
 26 2012-02-25 02:01:41 <gruez> so in GDB, how do i get it to break on exception?
 27 2012-02-25 02:01:51 <BlueMatt> it should by default...
 28 2012-02-25 02:01:54 <gruez> right now, when it crashes
 29 2012-02-25 02:02:01 <gruez> it shows the windows dialog box
 30 2012-02-25 02:02:05 <luke-jr> my guess, it's not an exception
 31 2012-02-25 02:02:17 <gruez> log from earlier
 32 2012-02-25 02:02:18 <gruez> <gruez> http://pastie.org/private/3wvhcxgkthwpgqmnb7ttg
 33 2012-02-25 02:03:21 <gribble> New news from bitcoinrss: dooglus opened pull request 893 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/893>
 34 2012-02-25 02:17:41 <phantomcircuit> gruez, windows c runtime exceptions aren't exceptions
 35 2012-02-25 02:17:57 <phantomcircuit> well they are but they get caught by the c runtime to display that pretty error box
 36 2012-02-25 02:23:47 <gribble> New news from bitcoinrss: dooglus opened pull request 894 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/894>
 37 2012-02-25 03:25:32 <XMPPwocky> oh
 38 2012-02-25 03:27:45 <XMPPwocky> send a node an addr packet filled with as many 127.0.0.1:8333 pairs as you can
 39 2012-02-25 03:28:32 <XMPPwocky> then wait for network weather to do its worj
 40 2012-02-25 03:28:52 <XMPPwocky> or, just keep sending them
 41 2012-02-25 03:29:03 <XMPPwocky> and watch setAddrKnown grow to new heights!
 42 2012-02-25 03:29:57 <XMPPwocky> boom. node dead or really slow
 43 2012-02-25 03:30:10 <XMPPwocky> hello, pool dos
 44 2012-02-25 03:49:00 <gmaxwell> XMPPwocky: are you just pulling out random shit or have you looked?
 45 2012-02-25 03:50:01 <gmaxwell> my recollection of that code is (1) it's indexed by address so sending the same address won't matter, maybe 127/8 (2) it ignores all past the first 1000 from a peer  but thats just my memory and expirence trumps that.
 46 2012-02-25 03:50:20 <gmaxwell> There _are_ ways to dos related to addr rumoring, which is one reason why Sipa's addrman exists.
 47 2012-02-25 03:50:46 <XMPPwocky> no
 48 2012-02-25 03:51:05 <XMPPwocky> first: just randkm addresses, then
 49 2012-02-25 03:51:39 <gmaxwell> Okay. Please test https://github.com/bitcoin/bitcoin/pull/787
 50 2012-02-25 03:51:43 <XMPPwocky> second: read main.cpp:2185
 51 2012-02-25 03:53:10 <XMPPwocky> it is added to a set immediately after a few sanity checks
 52 2012-02-25 03:53:26 <XMPPwocky> set, so yeah, need random addys /or random ports/
 53 2012-02-25 03:53:35 <gmaxwell> yes. like limiting the number of addresses you get from a peer.
 54 2012-02-25 03:53:42 <XMPPwocky> gmaxwell: np
 55 2012-02-25 03:53:53 <gmaxwell> I'm not saying its not an issue it is, thus that pull request. But it's not news.
 56 2012-02-25 03:54:01 <gmaxwell> jrmithdobbs and I were whining about that a year ago.
 57 2012-02-25 03:54:16 <gmaxwell> sipa only got aroudn to doing the non-trivial work to improve it lately.
 58 2012-02-25 03:54:18 <XMPPwocky> alright, k
 59 2012-02-25 03:56:31 <gmaxwell> XMPPwocky: please do give the addrman stuff the same kind of critical thinking though!
 60 2012-02-25 03:57:23 <XMPPwocky> don't think that miht solve it
 61 2012-02-25 03:57:42 <XMPPwocky> it's pfrom->AddAddressKnown
 62 2012-02-25 03:58:20 <XMPPwocky> from my cursory look that just deals with addr.dat
 63 2012-02-25 04:07:56 <devrandom> XMPPwocky: if you like XMPP, you might like https://guardianproject.info/apps/gibber/
 64 2012-02-25 04:12:09 <luke-jr> why would he like XMPP?
 65 2012-02-25 04:12:35 <gmaxwell> because having to link a 10mb xml library in order to send an IM is _FANTASTIC_
 66 2012-02-25 04:12:42 <XMPPwocky> the name's a subtle pun
 67 2012-02-25 04:13:22 <gmaxwell> hah I got that before but had forgotten it.
 68 2012-02-25 04:18:54 <wizkid057> been meaning to buy the valve complete pack
 69 2012-02-25 04:18:59 <wizkid057> er, wrong channel :P
 70 2012-02-25 04:57:05 <freewil> what effects does settxfee have
 71 2012-02-25 05:01:02 <gmaxwell> freewil: it sets a fee (per kb of txn size) which is always added to transactions.
 72 2012-02-25 05:01:17 <freewil> ah
 73 2012-02-25 05:01:48 <freewil> gmaxwell, how would you estimate the kb size (and therefore the fee) before sending coins?
 74 2012-02-25 05:02:07 <freewil> it is zero by default?
 75 2012-02-25 05:02:58 <gmaxwell> It's zero by default. Estimating the KB sizes isn't trivial, since you need to know all the payments available for spending in your wallet though the software attempts to minimize the size.
 76 2012-02-25 05:04:26 <freewil> ok so if it's zero by default i wouldnt have to worry about any potential exploits by small transactions generating large fees?
 77 2012-02-25 05:04:36 <luke-jr> gmaxwell: vaguely. it doesn't do a good job of minimizing it.
 78 2012-02-25 05:04:42 <freewil> do you know if there are any plans to make fee estimate easier in the future
 79 2012-02-25 05:04:50 <luke-jr> freewil: bitcoind will automatically send a fee if it thinks you'll need it
 80 2012-02-25 05:04:59 <freewil> luke-jr, via the api?
 81 2012-02-25 05:05:06 <luke-jr> freewil: that's how you access bitcoind..
 82 2012-02-25 05:05:22 <luke-jr> if you don't want it to do that, you need to merge one of my branches
 83 2012-02-25 05:05:29 <luke-jr> that gives you more control over it
 84 2012-02-25 05:05:30 <gmaxwell> The automatic, required fees can not in any case be larger than 0.05 BTC. (normally they are only 0.0005 BTC in the few cases where they are required at all)
 85 2012-02-25 05:05:44 <luke-jr> gmaxwell: I don't see that in code&
 86 2012-02-25 05:06:06 <gmaxwell> luke-jr: Then you shouldn't be telling people to run forks where you've changed the logic. :)
 87 2012-02-25 05:06:20 <gmaxwell> luke-jr: it's a constraint that arises because of the size check.
 88 2012-02-25 05:06:42 <luke-jr> so.. entirely unrelated to the fee logic? :p
 89 2012-02-25 05:06:55 <gmaxwell> No, it's in the same code that applies the fees in the coin selection.
 90 2012-02-25 05:07:07 <gmaxwell> Basically it won't create a txn which is over 100k.
 91 2012-02-25 05:07:42 <gmaxwell> (it's not obvious  I agree, that whole code isn't obvious, which is why I'm mostly scared to publish patches against it!)
 92 2012-02-25 05:08:01 <freewil> i think my solution will be to just charge at least 0.05BTC per withdraw
 93 2012-02-25 05:08:14 <gmaxwell> freewil: thats a little silly.
 94 2012-02-25 05:08:38 <freewil> im not hearing a better solution
 95 2012-02-25 05:08:51 <gmaxwell> Charge 0.01 instead you'll find it to be very profitable.
 96 2012-02-25 05:09:02 <gmaxwell> and you won't be accused of being a ripoff.
 97 2012-02-25 05:10:01 <freewil> is that based on a guestimated probability of fees being generated?
 98 2012-02-25 05:10:31 <gmaxwell> 0.01 is already something like >200x the expected fees you'll be be having if you don't keep an empty wallet.
 99 2012-02-25 05:11:32 <freewil> so does less transactions in the wallet actually increase the probability of having more fees since there is less inputs to select from?
100 2012-02-25 05:12:15 <gmaxwell> It's not so much a "guestimated probability": Getting a transaction up to a fee of 0.01 would take something like 300 hundreds of inputs.  the software won't do that unless it has no other option.
101 2012-02-25 05:12:46 <gmaxwell> freewil: yes, generally. More is helpful if they're reasonable sized  having a bunch of very tiny inputs doesn't help.
102 2012-02-25 05:13:06 <gmaxwell> er s/300 hundreds/300/
103 2012-02-25 05:15:17 <freewil> alright thanks gmaxwell
104 2012-02-25 05:18:38 <luke-jr> gmaxwell: 0.01 BTC will be enough for accusations, from what I've seen
105 2012-02-25 05:19:15 <gmaxwell> Hm. everyone seems to leave doublec alone about his exchange.
106 2012-02-25 05:20:48 <phantomcircuit> freewil, i think we've paid on the order of 0.11 USD in bitcoin fees operating intersango
107 2012-02-25 05:20:58 <k9quaint> gmaxwell: which exchange does he run?
108 2012-02-25 05:21:00 <phantomcircuit> which is probably orders of magnitude more than most people
109 2012-02-25 05:21:12 <phantomcircuit> so
110 2012-02-25 05:21:14 <phantomcircuit> yeah
111 2012-02-25 05:21:19 <gmaxwell> k9quaint: bitparking
112 2012-02-25 05:21:41 <phantomcircuit> it's all altcoin
113 2012-02-25 05:21:44 <phantomcircuit> who cares
114 2012-02-25 05:21:45 <phantomcircuit> :)
115 2012-02-25 05:22:26 <freewil> phantomcircuit, do you use any sort of techniques to prevent many small deposit/withdraw potential exploits
116 2012-02-25 05:22:36 <phantomcircuit> yes
117 2012-02-25 05:23:42 <freewil> care to name any?
118 2012-02-25 05:24:59 <phantomcircuit> no :)
119 2012-02-25 05:25:17 <freewil> meh ok
120 2012-02-25 05:25:37 <phantomcircuit> you're weakpoint is going to be a sybil attack
121 2012-02-25 05:25:41 <phantomcircuit> so watch out for that
122 2012-02-25 05:26:00 <phantomcircuit> other than that it's pretty easy
123 2012-02-25 05:27:42 <freewil> is that just where you have a potential attacker flood your client with clients under their control, creating a walled off network?
124 2012-02-25 05:32:14 <phantomcircuit> freewil, read the wikipedia entry
125 2012-02-25 05:32:21 <phantomcircuit> it's not an attack specific to bitcoin
126 2012-02-25 05:33:02 <phantomcircuit> im off to bed
127 2012-02-25 05:36:03 <freewil> yeah its an interesting issue
128 2012-02-25 05:36:06 <freewil> all things bitcoin are
129 2012-02-25 05:39:39 <luke-jr> gmaxwell: people were ranting about blockchain.info's ewallet
130 2012-02-25 05:39:55 <luke-jr> for its 0.01 BTC fees
131 2012-02-25 06:03:04 <doublec> gmaxwell: leave me along about what?
132 2012-02-25 06:03:12 <doublec> s/along/alone
133 2012-02-25 06:03:53 <doublec> ah right, fees
134 2012-02-25 12:39:24 <makomk> Oh bugger.
135 2012-02-25 12:41:50 <makomk> I just realised how I could in theory quite easily create a very effective partition of the Bitcoin network. Whoops.
136 2012-02-25 12:44:22 <badluck> makomk: how?
137 2012-02-25 12:49:47 <makomk> Hmmmm. Do I want to talk about the details publicly...
138 2012-02-25 12:58:08 <badluck> does it have anything to do with orphan blocks
139 2012-02-25 12:58:26 <makomk> Meh, guess it's probably not a total disaster thanks to the P2SH backports.
140 2012-02-25 12:59:07 <makomk> Newer versions of Bitcoin disconnect from and blacklist nodes that send them invalid transactions, in order to prevent attacks.
141 2012-02-25 12:59:39 <badluck> oh i c
142 2012-02-25 12:59:47 <makomk> Unfortunately, thanks to P2SH newer versions also consider some transactions invalid that older versions consider valid and are happy to forwards.
143 2012-02-25 13:00:45 <badluck> you can do some selective double spending and get a node blacklisted for forwarding the second tx
144 2012-02-25 13:00:56 <makomk> If someone were to send out one of those transactions then in theory the part of the network running the newer version would partition it off from the older version.
145 2012-02-25 13:01:22 <makomk> Nah, it doesn't disconnect over double-spends for exactly that reason.
146 2012-02-25 13:01:32 <cande> where is the webpage where i can se 0confirm tx ?
147 2012-02-25 13:01:38 <badluck> so only on other types of validation errors?
148 2012-02-25 13:02:04 <makomk> Yeah, basically, it's meant to be only for stuff that other nodes should consider invalid too.
149 2012-02-25 13:02:09 <badluck> i c
150 2012-02-25 13:03:02 <badluck> i thought p2sh was backwards compat.. odd that it invalidates tx's older versions accept
151 2012-02-25 13:03:33 <badluck> what happens if one of those invalid tx's makes it into the chain - the newer nodes will consider the block invalid?
152 2012-02-25 13:03:45 <makomk> The reason it's backwards compatible is because the transactions are still accepted by older versions, even though they can't verify them fully.
153 2012-02-25 13:04:16 <makomk> If one of the invalid txes makes it into the chain, the newer nodes will accept that block so long as it's before the switch on date.
154 2012-02-25 13:04:24 <badluck> hmmm
155 2012-02-25 13:05:10 <makomk> After the switch-on date, which is scheduled to be after enough nodes are validating P2SH to 51% out of existence blocks containing invalid TXes, they will consider the blocks invalid
156 2012-02-25 13:06:18 <badluck> maybe there should also be an exception to the blacklisting logic for those types of tx
157 2012-02-25 13:06:58 <makomk> Probably yeah.
158 2012-02-25 13:07:15 <badluck> sicne its not enabled yet, it doesnt impact the existing network
159 2012-02-25 13:28:00 <cande> i just made this strage tx, it took around 1hour to get through the network (0confirm), and it's still not in a block, i guess, because i cant find it in blockexplorer. but i'm curios why this tx took so much longer that my previous tx (which took 2 sec. to save reciever)
160 2012-02-25 13:28:21 <cande> to same reciever
161 2012-02-25 14:40:18 <cande> how does the bitcoin-qt client update 0confirm tx ?
162 2012-02-25 14:41:05 <cande> if i send btc to someone, its there within seconds
163 2012-02-25 14:41:50 <cande> so how does that communcation work?
164 2012-02-25 14:43:32 <sipa> it sends the transaction to your peers
165 2012-02-25 14:43:43 <sipa> and those forward it
166 2012-02-25 14:44:02 <cande> so if my budy is not online
167 2012-02-25 14:44:07 <cande> at the moment
168 2012-02-25 14:44:16 <cande> he "misses" the 0confirm tx
169 2012-02-25 14:44:38 <cande> and will recieve it when it's in the block-chain?
170 2012-02-25 14:45:36 <nanotube> yes
171 2012-02-25 14:46:11 <luke-jr> cande: well, when it connects, the peer will probably forward it to him
172 2012-02-25 14:46:48 <cande> they always forward all 0confirm tx they have to a new connection?
173 2012-02-25 14:49:37 <gribble> New news from bitcoinrss: luke-jr opened pull request 895 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/895>
174 2012-02-25 14:51:29 <cande> luke-jr, I can tell you that my peers are not forwarding the tx i'm expecting to recieve. and I was offline when the tx was sent out to the network
175 2012-02-25 15:19:59 <sipa> cande: your client will occasionally retransmit all *your* zero-conf transactions
176 2012-02-25 15:31:12 <makomk> Hmmmmmm. Testnet is kinda useless.
177 2012-02-25 15:32:01 <makomk> I guess I could partition mainnet, but that'd probably be a bad idea.
178 2012-02-25 15:32:53 <badluck> hmm but isnt p2sh not yet activated?
179 2012-02-25 15:32:57 <sipa> no
180 2012-02-25 15:33:14 <nanotube> makomk: what are you trying to do? there's also testnet in a box
181 2012-02-25 15:34:05 <badluck> are the blacklists permanent
182 2012-02-25 15:34:52 <sipa> badluck: 24 hours
183 2012-02-25 15:34:59 <sipa> or what is specified by -bantime
184 2012-02-25 15:35:13 <sipa> makomk: but you raise a very good point
185 2012-02-25 15:35:43 <makomk> nanotube: there's probably a really lovely network-partitioning attack based on P2SH, but older and newer testnet nodes disagree on the blockchain so it's difficult to test on testnet.
186 2012-02-25 15:36:03 <nanotube> ah
187 2012-02-25 15:36:22 <sipa> makomk: i can set up a git-head testnet node if you want one to play with
188 2012-02-25 15:39:31 <makomk> sipa: thanks, but I'm running one already. The trouble is that the attack involves multiple Bitcoin versions, and the versions involved aren't on the same chain on testnet due to the difficulty algorithm change.
189 2012-02-25 15:42:52 <sipa> makomk: i know
190 2012-02-25 15:55:13 <luke-jr> makomk: BIP 16 or 17?
191 2012-02-25 15:56:03 <makomk> Both, I think.
192 2012-02-25 15:58:09 <sipa1024> indeed, both allow a transaction that is standard and valid for old clients, but invalid for new nodes
193 2012-02-25 15:58:21 <luke-jr> relevance?
194 2012-02-25 15:58:51 <luke-jr> keep in mind, it's only invalid for new nodes iff over 55% of the miners supportit
195 2012-02-25 15:59:05 <sipa> old nodes will forward such transactions
196 2012-02-25 15:59:10 <luke-jr> so?
197 2012-02-25 15:59:17 <sipa> and when they reach new nodes, those will disconnect them for bad behaviour
198 2012-02-25 15:59:22 <luke-jr> oh
199 2012-02-25 15:59:31 <sipa> at least, that is makomk's untested assumptio
200 2012-02-25 15:59:35 <sipa> but it sound reasonable to me
201 2012-02-25 15:59:43 <luke-jr> hmm
202 2012-02-25 16:01:28 <luke-jr> looks like that's a problem
203 2012-02-25 16:02:28 <luke-jr> but all it takes is one P2SH node to disable anti-DoS stuff to fix it :P
204 2012-02-25 16:04:12 <makomk> Yeah. Did the anti-DoS stuff get included in the 0.3.x BIP16 backport and is anyone using that?
205 2012-02-25 16:04:34 <sipa> I doubt it.
206 2012-02-25 16:05:08 <sipa> But it shouldn't be hard to change the anti-DOS rules for 0.6 to allow bad transaction in certain circumstances
207 2012-02-25 16:43:31 <sipa> makomk: I'm not sure whether this is intentional or a bug, but AcceptToMemoryPool does not perform the extra pay-to-hash verification
208 2012-02-25 16:44:11 <sipa> but that implies a formerly-valid transaction will not cause anti-DoS behaviour
209 2012-02-25 16:45:20 <gribble> The operation succeeded.
210 2012-02-25 16:45:20 <sipa> ;;later tell gavinandresen What is the reason for not setting fValidatePayToScriptHash in AcceptToMemoryPool? It does prevent anti-DoS behaviour of new nodes again attacked old nodes, but is it always safe?
211 2012-02-25 16:46:19 <makomk> Interesting.
212 2012-02-25 16:49:37 <makomk> sipa: actually, if you look more closely fStrictPayToScriptHash defaults to true if not specified, so I think it does do the P2Sh verification
213 2012-02-25 16:51:27 <sipa> makomk: you're right; i miscounted the bool arguments at the end of the call
214 2012-02-25 17:07:44 <gribble> New news from bitcoinrss: sipa opened pull request 896 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/896>
215 2012-02-25 17:07:46 <sipa> makomk: ^
216 2012-02-25 17:09:06 <makomk> sipa: yeah, that looks reasonable.
217 2012-02-25 17:12:48 <gribble> New news from bitcoinrss: laanwj opened pull request 897 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/897>
218 2012-02-25 18:15:08 <sipa> Wow, a git-bundle of the entire history is only 4.56 MiB
219 2012-02-25 18:15:17 <sipa> (of bitcoin/bitcoin master)
220 2012-02-25 18:24:53 <sytse> sipa: dude, that's 13 double density floppy disks ;-)
221 2012-02-25 18:26:11 <Someguy123> sytse it's just 3 2.5"'s
222 2012-02-25 18:27:26 <sytse> no, 4
223 2012-02-25 18:27:28 <sytse> round up
224 2012-02-25 18:27:37 <sytse> and those aren't floppy ;-))
225 2012-02-25 18:28:03 <sytse> also, it's 19 DECtape II tape cartridges
226 2012-02-25 18:28:25 <gribble> 6.63566236896
227 2012-02-25 18:28:25 <sipa> ;;calc 4780225/720384
228 2012-02-25 18:28:30 <sipa> -> 7 DD's
229 2012-02-25 18:28:51 <sytse> no, 13 5???" DD's
230 2012-02-25 18:28:59 <sipa> Ah.
231 2012-02-25 18:31:08 <sytse> in 3???" floppy disk format you can get 200 MB magnetic and 240 MB optical drives, both from the last century
232 2012-02-25 18:31:18 <sytse> also, they're not floppy so they're not real!
233 2012-02-25 18:31:42 <sipa> You must be old ;)
234 2012-02-25 18:32:13 <JFK911> what lame storage media
235 2012-02-25 18:32:25 <Someguy123> how about ZIP disks?
236 2012-02-25 18:32:26 <JFK911> my 9 track 1250 bpi crushes everything mentioned
237 2012-02-25 18:32:31 <JFK911> especially because it's AUTOLOADER.
238 2012-02-25 18:33:06 <makomk> OK, that's interesting. Looks like Bitcoin only disconnects the first peer that tells it about the transaction.
239 2012-02-25 18:33:32 <sytse> sipa: yep, I'm very old..
240 2012-02-25 18:33:38 <sytse> 27 long years
241 2012-02-25 18:33:45 <sytse> ancient
242 2012-02-25 18:34:48 <sipa> Damn.
243 2012-02-25 18:34:50 <sipa> Me too...
244 2012-02-25 18:36:48 <sytse> ah well
245 2012-02-25 18:37:42 <sytse> who am I kidding, I get nostalgic when I even see a PATA drive
246 2012-02-25 18:39:42 <gribble> New news from bitcoinrss: dooglus opened pull request 898 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/898>
247 2012-02-25 19:15:29 <gribble> New news from bitcoinrss: sipa opened pull request 899 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/899>
248 2012-02-25 23:06:45 <davex__> Are gavin's bitcointools meant to work on an encrypted wallet?
249 2012-02-25 23:07:06 <sipa> davex__: don't think so
250 2012-02-25 23:07:25 <sipa> But Joric adapted his pywallet to encrypted wallets.
251 2012-02-25 23:09:34 <davex__> ok
252 2012-02-25 23:09:54 <davex__> somehow my wallet got corrupted when i ran encryptwallet
253 2012-02-25 23:10:34 <sipa> Which bitcoin version?
254 2012-02-25 23:10:49 <davex__> um... bip16option latest branch
255 2012-02-25 23:11:13 <sipa> git bitcoin/bitcoin master?
256 2012-02-25 23:11:51 <davex__> there's a bip16option branch on gavin's repo i used
257 2012-02-25 23:13:14 <sipa> Isn't that merged in main?
258 2012-02-25 23:13:31 <davex__> i wasn't sure, i suppose it is
259 2012-02-25 23:14:01 <sipa> Yeah, seems so.
260 2012-02-25 23:14:04 <davex__> my git skills aren't too good
261 2012-02-25 23:14:18 <sipa> Anyway, wallet corruption shouldn't happen.
262 2012-02-25 23:14:38 <sipa> You just selected encrypt wallet, restarted, and got an error?
263 2012-02-25 23:14:40 <davex__> i ran bitcoind encryptwallet, and it said to restart bitcoind
264 2012-02-25 23:14:52 <davex__> and when i restart and tail -f debug.log, it says:
265 2012-02-25 23:15:04 <davex__> Bitcoin: Error loading wallet.dat: Wallet corrupted
266 2012-02-25 23:15:31 <sipa> That looks familiar.
267 2012-02-25 23:16:36 <sipa> It was fixed here: https://github.com/bitcoin/bitcoin/pull/827
268 2012-02-25 23:16:48 <davex__> oh
269 2012-02-25 23:16:49 <davex__> ok
270 2012-02-25 23:17:06 <davex__> so.  i didn't back up  my wallet first. :/
271 2012-02-25 23:17:22 <sipa> Don't worry.
272 2012-02-25 23:19:04 <sipa> Make a backup now, and try opening the file with git master
273 2012-02-25 23:19:41 <sipa> (or at least something that has commit 7c39b56c
274 2012-02-25 23:39:26 <davex__> sipa still there?
275 2012-02-25 23:39:34 <sipa> davex__: yes
276 2012-02-25 23:39:42 <davex__> built latest master, same thing.
277 2012-02-25 23:39:50 <davex__> can send you the wallet if that'll be useful
278 2012-02-25 23:39:55 <davex__> not much in it
279 2012-02-25 23:47:18 <sipa> davex__: use db4.8_dump to see how many "key" entries are left in your wallet; it should be at most a few
280 2012-02-25 23:47:40 <sipa> davex__: if you remove those, you should be able to open the wallet
281 2012-02-25 23:47:48 <sipa> (and it won't hurt)
282 2012-02-25 23:48:32 <davex__> k
283 2012-02-25 23:49:15 <sipa> db4.6_dump -p; look in the output for \03key
284 2012-02-25 23:49:46 <davex__> 4.6 instead of 4.8?
285 2012-02-25 23:49:55 <sipa> whatever version of bdb you use
286 2012-02-25 23:50:01 <sipa> probably 4.8
287 2012-02-25 23:50:05 <davex__> oh
288 2012-02-25 23:53:49 <davex__> i'm not sure how to tell what is a key entry
289 2012-02-25 23:54:06 <davex__> i see a lot of hex lines after HEADER=END
290 2012-02-25 23:54:34 <sipa> It's always 1 line key, 1 line value
291 2012-02-25 23:54:38 <davex__> ah
292 2012-02-25 23:54:51 <sipa> and "key" entries have a key line that starts with \03key
293 2012-02-25 23:55:08 <davex__> i see those
294 2012-02-25 23:55:13 <sipa> How many?
295 2012-02-25 23:55:14 <luke-jr> davex__: needless to say, DO backup now
296 2012-02-25 23:55:23 <davex__> did backup
297 2012-02-25 23:55:57 <davex__> there are 3 of them looks like
298 2012-02-25 23:56:17 <sipa> Ok, dump the output of db4.8_dump to a file
299 2012-02-25 23:56:22 <davex__> although 2 other lines starting with 03, but shorter
300 2012-02-25 23:56:40 <davex__> k
301 2012-02-25 23:56:53 <sipa> Then remove all lines that start with \03key, plus the line that follows it.
302 2012-02-25 23:57:05 <sipa> Do the same for lines that start with \04pool
303 2012-02-25 23:58:03 <davex__> er, i don't see \03key anywhere.
304 2012-02-25 23:58:17 <davex__> sorry misinterpreted.  everyhting is just hex
305 2012-02-25 23:58:29 <sipa> Did you use -p ?
306 2012-02-25 23:58:34 <davex__> ah
307 2012-02-25 23:58:45 <davex__> there we go
308 2012-02-25 23:59:01 <davex__> ok, now what is deleting those lines actually doing?
309 2012-02-25 23:59:45 <sipa> Ok, the \03key lines contain unencrypted keys; encrypted keys are stored in lines that start with \04ckey