1 2012-07-08 00:02:13 <gribble> New news from bitcoinrss: jothan opened issue 1568 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1568>
  2 2012-07-08 00:04:45 <gmaxwell> Diablo-D3: no you're nuts.
  3 2012-07-08 00:05:07 <Diablo-D3> no, I remember you throwing a fit about it
  4 2012-07-08 00:05:11 <gmaxwell> I dont generally care about logging, beyond the fact of freenode policy against public logs without notice.
  5 2012-07-08 00:58:53 <Brett__> hello
  6 2012-07-08 00:59:30 <Brett__> as soon as i open the wallet "this application has requested the runtime to terminate in an unusual way"
  7 2012-07-08 00:59:39 <Brett__> and then it crashes
  8 2012-07-08 01:00:35 <Diablo-D3> then dont do that.
  9 2012-07-08 01:00:53 <Brett__> then i cant acces my bitcoin wallet
 10 2012-07-08 01:02:21 <luke-jr> Brett__: what version?
 11 2012-07-08 01:02:49 <Brett__> sorry but how do i check the version?
 12 2012-07-08 01:03:24 <luke-jr> dunno
 13 2012-07-08 01:03:50 <Brett__> i only downlaoded it the other day
 14 2012-07-08 01:05:44 <luke-jr> try 0.5.3rc3 for now https://bitcointalk.org/?topic=88826
 15 2012-07-08 01:46:00 <freewil> does anything ever get written to db.log
 16 2012-07-08 01:46:13 <freewil> maybe only seriously fatal errors?
 17 2012-07-08 08:42:14 <amiller> the 49% vs 51% thing is a dimensionless quantity
 18 2012-07-08 08:43:36 <amiller> the ideal number of blocks to wait for should depend only on that spread and not on something like time
 19 2012-07-08 10:32:46 <Ferroh> amiller, explain.
 20 2012-07-08 10:33:34 <Ferroh> you're suggesting that if the last block was found in 1 minute, then we should ideally wait for more blocks than if it was found in 20 minutes, correct?
 21 2012-07-08 10:37:09 <amiller> there are only two environment parameters the way i'm looking at it, one is the delay it takes for blocks to propagate to everyone, the other is the relative tolerance for bad behavior like 49%/51%
 22 2012-07-08 12:02:00 <plato> o/
 23 2012-07-08 12:02:48 <plato> can v0.6.3 read wallets from v0.3.x
 24 2012-07-08 12:03:32 <sipa> yes
 25 2012-07-08 12:04:44 <plato> will it modify the file
 26 2012-07-08 12:05:10 <plato> i.e. can I go back and use the same file on 0.3.x client after opening it once in 0.6.3
 27 2012-07-08 12:05:13 <sipa> yes
 28 2012-07-08 12:05:17 <plato> kthx!
 29 2012-07-08 12:05:21 <sipa> unless you use -upgradewallet or encrypt the file
 30 2012-07-08 12:27:01 <amiller> gmaxwell, here's another good one i think you'll like
 31 2012-07-08 12:27:23 <amiller> ( time-to-trigger  ||   txhash )
 32 2012-07-08 12:27:59 <D34TH> so i figured out why i cant get bitcoin-qt to compile on windows so far
 33 2012-07-08 12:28:00 <amiller> this way something like something can be triggered by the absence of a transaction
 34 2012-07-08 12:28:09 <D34TH> libdb hates me
 35 2012-07-08 12:28:37 <amiller> something like a namecoin registration*
 36 2012-07-08 12:28:55 <amiller> this would also be the way i would implement garbage collection or demurrage or replenishing the money pool
 37 2012-07-08 12:30:52 <amiller> it's a merkle priority queue!
 38 2012-07-08 12:31:19 <D34TH> does someone have a spare libdb compiled they can spare me
 39 2012-07-08 14:06:08 <sipa> hi TD
 40 2012-07-08 14:06:16 <TD> hi
 41 2012-07-08 14:07:01 <sipa> saw my mail about "ultraprune" ?
 42 2012-07-08 14:39:40 <TD> sipa: yeah. i didn't dig into it yet
 43 2012-07-08 14:39:50 <TD> i'm not sure how it interacts with the leveldb work. it sounded more experimental
 44 2012-07-08 14:40:54 <sipa> TD: sure, but i'd like to see how well it performs in combination with leveldb
 45 2012-07-08 14:41:03 <TD> cool
 46 2012-07-08 14:41:43 <sipa> now, not sure how much room for improvement there still is; i currently -loadblock up 185k (before the last checkpoint) in 11 minutes with BDB on disk, and in 6 minutes with BDB on tmpfsa
 47 2012-07-08 14:45:13 <sipa> i was wondering about an in-memory backend for the coins db
 48 2012-07-08 14:45:38 <sipa> kyotocabinet has a dense in-memory database that supports variable-length records
 49 2012-07-08 14:47:48 <TD> i'm not sure where the bottleneck is with your current system
 50 2012-07-08 14:47:57 <TD> i found that even after disabling sig checking i/o did not become the bottlenec
 51 2012-07-08 14:48:47 <sipa> with BDB on disk here, my CPU isn't maxed out
 52 2012-07-08 14:51:03 <TD> yeah, i was seeing 100% cpu on one core with leveldb. seems like the work of doing all the data structure management, calculating the merkle roots, rummaging through hash maps etc was still enough to max out the core
 53 2012-07-08 14:51:14 <TD> the background leveldb thread was seeing around 30% iowait time
 54 2012-07-08 14:52:23 <sipa> i've already eliminated all duplicate tx hash calculation, and did some optimization to reduce copying/allocation/...
 55 2012-07-08 14:53:31 <TD> cool
 56 2012-07-08 14:53:55 <TD> i didn't really look at where the time was going. a quick oprofile showed it spending a lot of time inside a hashmap<uint256, pair<something>>
 57 2012-07-08 14:53:59 <TD> but i don't remember which map it was
 58 2012-07-08 14:54:10 <TD> anyway, i still didn't make leveldb run on windows yet. that's mondays problem
 59 2012-07-08 14:56:40 <gribble> New news from bitcoinrss: Diapolo opened pull request 1569 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1569>
 60 2012-07-08 14:58:36 <MC1984> corrupted blk index for no reason ffffffffffffffffffffffffffff
 61 2012-07-08 14:58:55 <MC1984> can i just get it to rebuild from the chain its already got
 62 2012-07-08 14:59:10 <sipa> MC1984: yes
 63 2012-07-08 14:59:18 <sipa> oh, not with 0.6.x i think
 64 2012-07-08 14:59:40 <MC1984> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFff
 65 2012-07-08 15:00:30 <MC1984> closed it last night, opened today
 66 2012-07-08 15:00:36 <MC1984> "cannot load block index lol"
 67 2012-07-08 15:03:00 <gmaxwell> I'm pretty sure the software did not say "lol".
 68 2012-07-08 15:03:29 <gmaxwell> Can you pastbin the actual error it gives if you launch it from the terminal and the end of the debug.log?
 69 2012-07-08 15:04:30 <MC1984> it didnt say lol but thats the way i read it in my head
 70 2012-07-08 15:05:52 <MC1984> which one do i launch from terminal
 71 2012-07-08 15:06:00 <MC1984> bitcoind?
 72 2012-07-08 15:06:00 <sipa> gmaxwell: i've done several improvements to ultraprune; if you'd like to retry profiling it...
 73 2012-07-08 15:06:18 <sipa> (or tell me how to make such fancy profile maps)
 74 2012-07-08 15:06:56 <gribble> New news from bitcoinrss: Diapolo opened issue 1570 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1570>
 75 2012-07-08 15:09:11 <gmaxwell> Sure, I'll reprofile, but I'll also tell you how. Install kcachegrind,  run valgrind like valgrind --tool=callgrind --trace-children=yes --collect-jumps=yes  --separate-threads=yes  ~/bitcoin/src/bitcoind    it will write out a bunch of callgrind files when the program stops (or you break it).  Start kcachgrind in that directory.  It's a gui app, the images were the 'caller tree' or something like that.
 76 2012-07-08 15:09:23 <MC1984> C:Program FilesBitcoindaemon>bitcoind.exe
 77 2012-07-08 15:10:14 <gmaxwell> sipa: also, at higher optimization levels inlining and such will hide things strangly.
 78 2012-07-08 15:14:10 <MC1984> gmaxwell http://pastebin.com/kX18xrMv
 79 2012-07-08 15:15:47 <luke-jr> MC1984: you sure you closed it cleanly?
 80 2012-07-08 15:16:34 <MC1984> i pressed X, window closed
 81 2012-07-08 15:16:36 <MC1984> thats all i know
 82 2012-07-08 15:16:42 <luke-jr> MC1984: and left the computer on?
 83 2012-07-08 15:17:11 <MC1984> it got shut down, i cnt remember if it was straight after
 84 2012-07-08 15:17:36 <luke-jr> until the system tray icon disappears, it's not done
 85 2012-07-08 15:17:37 <gmaxwell> In any case, looks like the block file is failing a read.. so its either truncated or your OS is returning an error (disk problem). I thought truncation gave a different error though.
 86 2012-07-08 15:17:44 <MC1984> will sleeping it by closing the lid while its running tend to fuck up the chain?
 87 2012-07-08 15:17:55 <luke-jr> gmaxwell: or the data is wrong
 88 2012-07-08 15:18:03 <luke-jr> MC1984: if it then loses power, maybe
 89 2012-07-08 15:18:08 <gmaxwell> MC1984: sleeping it won't if you actually come back.
 90 2012-07-08 15:18:43 <MC1984> yeah i did, it got shut down the good way
 91 2012-07-08 15:21:01 <MC1984> so i cant just rebuild the index right? If i delete blkindex.dat, a new one gets started and it looks like it start chain download again, but the old blk001.dat is still there and appears to be having the data appended to it or somthing :/
 92 2012-07-08 15:21:51 <luke-jr> MC1984: with 0.6 (I think) you can
 93 2012-07-08 15:21:57 <luke-jr> or maybe it needs 0.7 :/
 94 2012-07-08 15:22:14 <luke-jr> MC1984: rename blk0001.dat to somethign else, then delete blkindex
 95 2012-07-08 15:22:23 <luke-jr> then start bitcoin-qt with -loadblock=renamedfile
 96 2012-07-08 15:23:19 <luke-jr> meh, it's a 0.7 feature
 97 2012-07-08 15:23:45 <luke-jr> MC1984: you can get my next-test build if you want, but it might be buggy - I've been getting a lot of crashes with the latest
 98 2012-07-08 15:24:33 <luke-jr> or BlueMatt has master builds up somewhere
 99 2012-07-08 15:24:40 <gmaxwell> MC1984: its not the index thats corrupt in any case. It's the end of the blocks file.  Though loadblock would work, if the version you're running had it.
100 2012-07-08 15:25:19 <MC1984> why cant it just chop off a few KB off the end and carry on :/
101 2012-07-08 15:25:30 <luke-jr> MC1984: 0.7 does I think
102 2012-07-08 15:26:01 <luke-jr> but it's also possible 0.6 added that and you're hitting some odd corner case
103 2012-07-08 15:26:10 <MC1984> screw it, what the eta on that levelDB thing? I think i will wait until then before trying again
104 2012-07-08 15:26:33 <MC1984> this SSD has been reamed enough for now
105 2012-07-08 15:28:51 <luke-jr> MC1984: I'm not sure anyone's done anything more than talk about it yet - but I might just be behind
106 2012-07-08 15:29:37 <MC1984> doesnt someone maintain daily chain downloads?
107 2012-07-08 15:29:52 <MC1984> zip files
108 2012-07-08 15:30:12 <luke-jr> yes, but it's not secure to use those without -loadblock (which would also handle your blk0001.dat fine)
109 2012-07-08 15:32:14 <MC1984> 7th winbldon for federer goddamn
110 2012-07-08 15:33:04 <gmaxwell> MC1984: 'what the eta on that levelDB thing' months.
111 2012-07-08 15:33:42 <gmaxwell> luke-jr: er, unless someone merged it when I wasn't looking 0.7 still does not recover from a truncated block file.
112 2012-07-08 15:34:05 <luke-jr> gmaxwell: I thought -checkblocks would just invalidate problems it found?
113 2012-07-08 15:34:37 <gmaxwell> luke-jr: right, but in the trucated case it gets an exception trying to seek past the end and it bubbles up uncaught.
114 2012-07-08 15:34:42 <luke-jr> :/
115 2012-07-08 15:34:48 <gmaxwell> or did. I haven't checked in a while.
116 2012-07-08 16:04:30 <CodesInChaos> does the official client use the standard randomized DSA (random `k`), or a deterministic variant?
117 2012-07-08 16:07:18 <Diablo-D3> oh, it just uses 3.
118 2012-07-08 16:07:30 <CodesInChaos> you're not sony
119 2012-07-08 16:07:53 <Diablo-D3> THANK GOD
120 2012-07-08 16:09:12 <CodesInChaos> But deterministic does not mean constant or guessable
121 2012-07-08 16:38:31 <gmaxwell> CodesInChaos: no, we do not use the ed25519 like approach.
122 2012-07-08 16:38:48 <gmaxwell> CodesInChaos: use random k.
123 2012-07-08 16:38:57 <gmaxwell> (or rather openssl does)
124 2012-07-08 16:39:12 <CodesInChaos> ok, thanks
125 2012-07-08 16:40:27 <CodesInChaos> personally I prefer determinisitc approaches, because I'm paranoid about PRNGs
126 2012-07-08 16:41:10 <gmaxwell> In idealized bitcoin usage each key is only used once, however. Which helps in any case.
127 2012-07-08 17:38:40 <amiller> gmaxwell, so with a bitcoin priority queue, you could schedule a transaction to be executed in a particular block, the target block number would be stored as a leading key in the merkle tree index
128 2012-07-08 17:39:25 <amiller> when validating a block, you have to check the left side of the tree for the smallest scheduled interaction, and if one exists at the current block number or below you apply it
129 2012-07-08 17:42:42 <gmaxwell> I follow what you're saying, but I don't see why it's interesting.
130 2012-07-08 17:44:09 <gmaxwell> (also, generally being able to schedule things that have future computational/bandwidth/storage burden seems like it would have unwelcome economic behavior because it creates an additional kind of externalized cost for the party inserting the thing)
131 2012-07-08 17:44:27 <gmaxwell> Though indeed, storing an epoch for things that expire is interesting.
132 2012-07-08 17:55:33 <amiller> well the computational bandwidth is advertised
133 2012-07-08 17:55:34 <amiller> er
134 2012-07-08 17:55:37 <amiller> amortized
135 2012-07-08 17:55:52 <amiller> you only have to apply it once, even though the priority queue is checked each block
136 2012-07-08 17:56:07 <amiller> if the transaction is paid for ahead of time
137 2012-07-08 17:56:19 <amiller> then it's not any different than having an unspent tx lying around
138 2012-07-08 17:56:39 <amiller> i mean it puts no additional computational load than an additional txout
139 2012-07-08 17:57:57 <gmaxwell> I didn't mean maintaining the queue. I meant having to actually do something with it when the time comes. If you don't have to do something with it, then it has no protocol impact.
140 2012-07-08 17:58:37 <amiller> but what you have to do with it is process it just like a transaction
141 2012-07-08 17:59:32 <amiller> lets say i create a new time delay txoutput that activates 10 blocks later
142 2012-07-08 17:59:59 <amiller> i'd basically have to place a transaction fee on it ahead of time
143 2012-07-08 18:00:46 <amiller> there's no additional computation besides what there would have been if i just created a normal txout rather than a time-delay txout
144 2012-07-08 18:00:54 <gmaxwell> I suppose. I'm not seeing the pratical advantage over nlock time, when then requires no normative handling (you can handle future locked txn however you like)
145 2012-07-08 18:01:40 <amiller> well for one thing you can guarantee that something will be executed at block B and no later
146 2012-07-08 18:02:11 <amiller> that's a little bit analogous to how the merkle search tree lets you prove that an element isn't in the set
147 2012-07-08 18:04:06 <gmaxwell> but the availablity of a txout is hardly 'execution'. If a txout becomes available in a tree and no one redeems it, does it make a sound?
148 2012-07-08 18:05:04 <sipa> it says "ni!"
149 2012-07-08 18:05:06 <amiller> can ascii bernanke testify
150 2012-07-08 18:05:37 <amiller> so it would make it easier to compose these if you can guarantee something happens on a time and no later
151 2012-07-08 18:05:51 <gmaxwell> Bitcoin intentionally doesn't make expiring transaction possible because doing so would make exclusions proftable. And if you use this to expire and avoid that risk you still have the coins get burnt if they're only available in some particular block.
152 2012-07-08 18:09:41 <amiller> not if you use this mechanism
153 2012-07-08 18:10:04 <amiller> because 'only available in some particular block' means that it _will_ occur in that block, normatively, at no additional amortized cost
154 2012-07-08 18:10:56 <amiller> suppose i want to send you some money as a gift but i'm afraid you're going to lose your public key
155 2012-07-08 18:11:16 <amiller> if i send it to you like normal, and you lost your key, then it's burnt forever
156 2012-07-08 18:11:54 <amiller> but if there's a trigger to send it back to me, then if you can't claim it it will be returned to me
157 2012-07-08 18:12:09 <amiller> if you do claim it, then you remove that trigger from the tree at the same time
158 2012-07-08 18:12:24 <amiller> the trigger is 1 operation in either case, so i'd initially pay an ordinary transaction fee for it ahead of tim
159 2012-07-08 18:12:39 <amiller> twice the transaction fee, once for inserting the trigger into the tree, and the second time for either removing it or applying it
160 2012-07-08 18:13:41 <quintopia> amiller: easier than "until a particular time" would be "until a particular block"
161 2012-07-08 18:13:47 <amiller> that isn't a really compelling motivation but i think it's a useful example of how it works
162 2012-07-08 18:13:53 <amiller> yeah i assume that time is measured in blocks
163 2012-07-08 18:14:02 <amiller> i've started scheduling my appointments based on the blockchain
164 2012-07-08 18:14:47 <amiller> "i'll be there in about 9 blocks"
165 2012-07-08 18:16:15 <amiller> so this is the opposite of expiring transactions, since it's delay-activated transactions
166 2012-07-08 18:17:09 <amiller> it solves the problem of exclusion by adding a new normative step (which it's just another key in the merkle tree)
167 2012-07-08 18:17:15 <gmaxwell> amiller: but as a miner it's in my interest for that coin to be burnt. So I just don't process your redemption unless you use a higher than normal fee.
168 2012-07-08 18:18:04 <amiller> just assume the fee is paid in advance and gets given to the miner whether someone redeems it early or the delay triggers it
169 2012-07-08 18:18:42 <gmaxwell> Ah I misread you. above. In any case. I can just write you a valid transaction, without broadcasting.. and give it to you. You announce it when you decide to spend it.
170 2012-07-08 18:18:52 <gmaxwell> 100 fold complexity reduction.
171 2012-07-08 18:19:09 <amiller> but then i could also spend it out from under you
172 2012-07-08 18:20:24 <gmaxwell> amiller: until the unannoucned txn is mined it can go either way. once its mined it can't.  This isn't any different under your proposal.
173 2012-07-08 18:20:49 <gmaxwell> Because the miner can selectively do whatever it wants at the magic block send it to me or you.
174 2012-07-08 18:21:30 <gmaxwell> You've narrowed the window, but I think its a distinction without a difference.
175 2012-07-08 18:21:36 <amiller> if you wait until the T-1 block to announce the transaction
176 2012-07-08 18:21:43 <amiller> then yeah miners can influence the outcome one way or the other
177 2012-07-08 18:21:52 <amiller> but if you announce it with a few blocks to spare
178 2012-07-08 18:22:21 <amiller> it's still in each miner's best interest to include the redemption transaction rather than wait for the time trigger
179 2012-07-08 18:24:58 <gmaxwell> why won't they just reinsert the trigger in the next block?
180 2012-07-08 18:28:24 <gmaxwell> In any case, I'm still struggling to see the actual problem this solves over what you can do with nlocktime and out-of-chain transactions.  Generally for refunds what you'd do is I pay you X -> (payment criteria) or (me+you),  and then before I tell you that txn I make you sign a me+you refund transaction with a future nlock time.
181 2012-07-08 18:29:12 <gmaxwell> If the payment criteria are met before the nlocktime happens you use it to redeem the payment.  Otherwise I announce the pregenerated refund transaction when the locktime hits.
182 2012-07-08 18:33:34 <amiller> hm, i guess i can't even think of a really compelling example for now.
183 2012-07-08 18:34:06 <amiller> it sure seems useful though.
184 2012-07-08 18:47:21 <gribble> New news from bitcoinrss: Diapolo reopened issue 1452 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1452>
185 2012-07-08 23:05:41 <BlueMatt> yay! ultraprune-ing bitcoinj working...next step more unit tests, then full script verification, then....mining
186 2012-07-08 23:12:15 <BlueMatt> ;;later tell TD I know its not exactly the purpose of bitcoinj, but me+boredom doesnt go well so I wrote a ultraprune-style BlockChain into bitcoinj...
187 2012-07-08 23:12:16 <gribble> The operation succeeded.
188 2012-07-08 23:58:43 <mcorlett> Hello, is it true that an attacker that controls more than 50% of the network's computing power can reverse transactions that he sends?
189 2012-07-08 23:59:21 <luke-jr> mcorlett: yes
190 2012-07-08 23:59:24 <gmaxwell> mcorlett: Yes, subject to limitations.