1 2012-05-07 00:00:25 <gmaxwell> This risk is currently eliminated in bitcoin by the maximum txn rate created indirectly by the block size limits.
  2 2012-05-07 00:01:08 <gmaxwell> Given that we have no risk of regular users being simply unable to validate there is little point in making miners prove they have validation superpowers far beyond regular users.
  3 2012-05-07 00:01:39 <amiller> there are two cases.  a) miners will validate blocks using O(1) communications, O(log N) time, and they are maintaining O(N) state         b) users will validate blocks using O(log N) communication, O(log N) time, and they only need O(1) state
  4 2012-05-07 00:03:03 <gmaxwell> If many users are not fully upholding the network rules then bitcoin loses its decenteralization. It sounds like you're making the mistake of thinking only miners fully enforce the rules?
  5 2012-05-07 00:03:57 <amiller> by regular users, you do mean users with O(1) state, a block hash maybe but no unspent-inputs tables?
  6 2012-05-07 00:04:10 <amiller> if so, regular users right now _are not_ able to indepently validate
  7 2012-05-07 00:04:28 <gmaxwell> No. I just mean full nodes who are not mining, which is the overwhelming supermajority of nodes now.
  8 2012-05-07 00:05:26 <gmaxwell> The power race to increase mining capacity is fundimentally anti-decentralization because it favors capital investment in specialized hardware. This sucks, but at least in bitcoin as it is today it only influnces control over the total order of transactions all the rest of the nodes (save a small number of mobile ones) still validate the whole of the system rules.
  9 2012-05-07 00:06:01 <gmaxwell> And the maximum block sizes ensure that it will always be in the reach of fairly modest hardware to do so.
 10 2012-05-07 00:08:33 <amiller> full nodes in my scheme will continue to be able to verify work, but with O(k * log N) effort per block, is your point that that is too much of an increased burden?
 11 2012-05-07 00:09:46 <amiller> just to clarify, i think you have two criticisms in flight here, first that this harms validation by non-miners somehow, and second that it's not much of an improvement
 12 2012-05-07 00:10:05 <gmaxwell> It's no so much the increased burden it's that it doesn't have a matching reward.  You could have them do O(1*log N) work to prove they're not cheating on storage... and that has basically all the real value but very little cost.
 13 2012-05-07 00:10:50 <gmaxwell> increasing K over 1 doesn't really prove much of anything, since once they have the storage the lookup costs are small given that we want modest nodes without extensive hardware investments to continue to do full validation.
 14 2012-05-07 00:10:59 <amiller> oh, let me explain K
 15 2012-05-07 00:11:07 <amiller> if you don't have K, then it's easy to cheat at the proof-of-work
 16 2012-05-07 00:11:12 <gmaxwell> (maybe I've mistook your nomenclature)
 17 2012-05-07 00:11:23 <gmaxwell> I think if you have to cooperate with a non-cheater then thats not much of a cheat.
 18 2012-05-07 00:11:35 <gmaxwell> (because you could use the same cooperation to do the validation)
 19 2012-05-07 00:12:05 <amiller> this K idea is due to a recent paper by rivest
 20 2012-05-07 00:12:15 <amiller> http://www.rsa.com/rsalabs/staff/bios/kbowers/publications/RAFT.pdf
 21 2012-05-07 00:12:25 <amiller> it's not cheating that's the threat here, it's "cheap and lazy"
 22 2012-05-07 00:12:39 <amiller> every pooled miner knows it's easy to cooperate by letting the pool operator validate your tx for you
 23 2012-05-07 00:12:58 <gmaxwell> woah hey.
 24 2012-05-07 00:13:06 <gmaxwell> okay you just changed my opinion
 25 2012-05-07 00:13:33 <gmaxwell> Your system is incompatible with pooling for validation (perfectly compatible with pooling for payment).
 26 2012-05-07 00:13:51 <amiller> this system is also incompatible with merged mining
 27 2012-05-07 00:14:30 <gmaxwell> I don't think thats desirable. (merged mining changes the failure modes of bitcoin in a positive way) but I expect that could be fixed.
 28 2012-05-07 00:15:13 <gmaxwell> okay, I can see the benefit of what you're describing for the purpose of discouraging pooling for validation.
 29 2012-05-07 00:15:45 <gmaxwell> Though one issue is that ecdsa computation is a non-trivial part of the validation cost and you're ignoring it by just being IO centric. Perhaps thats sufficient though.
 30 2012-05-07 00:17:57 <gmaxwell> amiller: for your reference, it was mentioning "pool operator validate your tx for you"   my mindset was more around attackers who mine without validating (e.g. don't include transactions) because they're lazy. I hadn't thought of pools as a way of coperating to cheat on validation because thats not why pool users do that today.
 31 2012-05-07 00:18:32 <gmaxwell> (they cooperate for pooled payments which is a harmless thing, the delegation of  validation is an unfortunate accident of history mostly)
 32 2012-05-07 00:18:57 <amiller> you're that right i'm being io centric for now, i believe it would be possible to tweak the proof-of-work to include some proportional measure of signature validation
 33 2012-05-07 00:19:27 <gmaxwell> it's perfectly possible to do pooling without delgating validation p2pool, bitpenny, and eligius memorypool mode all do it.. but they all came too late for wide adoption and they are all somewhat more 'costly' than the systems they replace.
 34 2012-05-07 00:19:28 <amiller> like you have to compute some number of group multiplies in between queries to your unspent inputs database
 35 2012-05-07 00:19:57 <gmaxwell> amiller: just make your hash function used to compine them be group multiplies.
 36 2012-05-07 00:20:10 <amiller> sure
 37 2012-05-07 00:20:28 <amiller> so the full nodes will always be more costly
 38 2012-05-07 00:20:34 <gmaxwell> s/compine/combine/
 39 2012-05-07 00:20:35 <amiller> you don't get reimbursed proportionally for maintaining it
 40 2012-05-07 00:20:53 <amiller> maintaining that database is unpaid-overtime
 41 2012-05-07 00:21:09 <amiller> also notice that it's still burning cycles
 42 2012-05-07 00:21:10 <gmaxwell> amiller: yes but it doesn't matter if the cost is not substantial you get paid in the form of increased security.
 43 2012-05-07 00:24:25 <gmaxwell> amiller: I still think you should take more advantage of the non-public side effects of validating the prior blocks in the chain. Yes, you could cooperate with other nodes.. but at least that work is ~free.
 44 2012-05-07 00:26:36 <amiller> the proof-of-work necessarily involves burning cycles, but it also encourages investment in a particular kind of apparatus
 45 2012-05-07 00:26:49 <amiller> so you might as well design it so that the necessary apparatus does whatever is most important to the network
 46 2012-05-07 00:27:16 <amiller> there isn't anything more essential than transaction validation, so the natural thing is to align the proof-of-work with what's required to validate, as closely as possible
 47 2012-05-07 00:27:48 <amiller> anything else is wasted slack, i think you agree with that general idea now at least
 48 2012-05-07 00:27:49 <luke-jr> I would argue there is.
 49 2012-05-07 00:28:11 <luke-jr> more essential than transaction validation, is keeping permanent resource requirements to a minimum
 50 2012-05-07 00:28:19 <luke-jr> SHA256 proof-of-work does that well
 51 2012-05-07 00:28:27 <luke-jr> there are zero additional resources required
 52 2012-05-07 00:28:49 <amiller> what do you mean by 'permanent'
 53 2012-05-07 00:29:55 <gmaxwell> amil19:26 < amiller> the proof-of-work necessarily involves burning cycles, but it also encourages investment in a particular kind of apparatus
 54 2012-05-07 00:30:01 <gmaxwell> ^ that was the argument I found uncompelling.
 55 2012-05-07 00:30:09 <amiller> ah
 56 2012-05-07 00:31:02 <gmaxwell> Because if you need more than X units of validation apparatus then the system is a failure.  Encouraging people to invest in more than X units of it does us no good. (except in so far as it changes the market prices of that apparatus)
 57 2012-05-07 00:31:37 <gmaxwell> I mean, it's still a POW ... but I think it loses its aligment value once it goes beyond what you need for basic full falication.
 58 2012-05-07 00:31:41 <gmaxwell> er validation.
 59 2012-05-07 00:32:00 <luke-jr> amiller: the blockchain
 60 2012-05-07 00:32:12 <gmaxwell> I think the real value of what you're suggesting is that it making mining bandwidth heavy in a way that discourages pooled validation.
 61 2012-05-07 00:32:52 <gmaxwell> And that the change from one pow type to another is basically no better than what scrypt did.. it shuffles around the winners and losers but doesn't really improve the system.
 62 2012-05-07 00:33:34 <gmaxwell> amiller: Do you understand now where my objection was coming from?
 63 2012-05-07 00:34:35 <amiller> heh, no i don't think i do yet
 64 2012-05-07 00:34:36 <gmaxwell> That if X units of IO are required to fully validate the chain, the mining work with >X IO is just 'wasted' and might as well be some other task.  And that X must be small if we're to have many full nodes anyways.
 65 2012-05-07 00:35:04 <luke-jr> gmaxwell: I think I understand amiller's argument, though.
 66 2012-05-07 00:35:13 <luke-jr> gmaxwell: X is variable.
 67 2012-05-07 00:35:25 <luke-jr> so even if >X IO is wasted now, it might be needed as we grow
 68 2012-05-07 00:35:34 <luke-jr> and will be readily available this way
 69 2012-05-07 00:36:00 <gmaxwell> Requiring miners to have X capacity is a grand thing.  Requring them to have X*1000 is no better than X+Y*1000 where Y is sha256 or whatever equally $$ costly thing.
 70 2012-05-07 00:36:16 <amiller> gmaxwell, in this rivest paper
 71 2012-05-07 00:36:19 <gmaxwell> luke-jr: you can fully validate the maximum rate of bitcoin on a fast desktop.
 72 2012-05-07 00:36:26 <amiller> they measure throughput as a way of measuring redundancy
 73 2012-05-07 00:36:47 <amiller> the goal is to have higher redundancy more than it is to have higher throughput
 74 2012-05-07 00:36:49 <gmaxwell> amiller: yes, I get the anti-pooled-validation advantage and I accept the value in that.
 75 2012-05-07 00:37:28 <luke-jr> gmaxwell: but that maximum rate needs to be lifted at some point
 76 2012-05-07 00:38:28 <amiller> okay i see your objection now
 77 2012-05-07 00:38:35 <amiller> so when i say it encourages investment in validation apparatus
 78 2012-05-07 00:38:37 <gmaxwell> luke-jr: I don't necessarily agree. Or rather its my position that if its lifted the limit _must_ be such that the maximum rate can be reached with currently modest hardware, or bitcoin becomes controled exclusively by governments and central banks... becuase few could afford to watch the miners.
 79 2012-05-07 00:39:06 <amiller> i intend that to mean that it encourages more people to have this minimum apparatus, not that it should encourage greater capital investment in 1000*X individual apparatuses
 80 2012-05-07 00:39:28 <amiller> there doesn't seem to be a way to one without the other without something complicated involving identity
 81 2012-05-07 00:39:33 <gmaxwell> luke-jr: Bitcoin will never be a replacement for visa, at least not a good one. The fact that you'd have to exchange your gold (bitcoin) for cash (ripple?) to make many small transactions isn't a problem in my mind... So I'm comfortable with the max txn rate being capped.
 82 2012-05-07 00:39:33 <luke-jr> gmaxwell: I consider that an acceptable improvement over the current monopolistic money.
 83 2012-05-07 00:40:09 <gmaxwell> luke-jr: even ignoring the loss of full nodes, if it's not capped the lack of txn fees will make the system insecure once the subsidy is gone.
 84 2012-05-07 00:40:49 <gmaxwell> amiller: I don't know that the problem is actually having the minimum apparatus.
 85 2012-05-07 00:41:17 <gmaxwell> amiller: I think if the first pooled system was p2pool or bitpenny then thats ~all we'd have today except perhaps for some botnet operators.
 86 2012-05-07 00:41:19 <amiller> gmaxwell, let me go over one more part of this again. there are two kinds of validation going on here, a) miners require O(N) state, do O(1) communication with each other, and validate with O(log N) time    b) people who aren't miners require O(1) state, and can independently validate with O(log N) effort and communication
 87 2012-05-07 00:41:32 <amiller> so my argument is on two fronts
 88 2012-05-07 00:41:34 <gmaxwell> amiller: No. stop. wrong assumptions.
 89 2012-05-07 00:41:38 <amiller> for ah k
 90 2012-05-07 00:41:52 <gmaxwell> Bitcoin is worthless in the model you just proposed because its subject to fully centeralized control.
 91 2012-05-07 00:42:27 <gmaxwell> You're falling back into this mental model where only miners impose the rules of the system. Thats a possible outcome but it would make the system a complete failure at its goals.
 92 2012-05-07 00:42:54 <amiller> no no you misunderstood what i just wrote, my system enables both a) and b) to occur, b) is the one you're talking about where non-miners participate in validation, and my suggestion is a huge improvement in that area
 93 2012-05-07 00:44:07 <amiller> there is currently no equivalent for b), people without O(N) state are unable to independently verify anything
 94 2012-05-07 00:44:22 <gmaxwell> amiller: well, if you're talking about the tree of unspent transactions part yes I'm familar with that, considering that I believe I was the first person to propose it.
 95 2012-05-07 00:45:49 <gmaxwell> I just think of that seperately from the POW changes.
 96 2012-05-07 00:45:55 <gmaxwell> Is there a reason I shouldn't be?
 97 2012-05-07 00:47:19 <amiller> well consider that there is a role for proof-publishers to service all of these independent validators
 98 2012-05-07 00:47:51 <amiller> that's more specifically what the PoW subsidizes investment in
 99 2012-05-07 00:52:57 <gmaxwell> Hm!
100 2012-05-07 00:53:04 <gmaxwell> There is an elegance in that.
101 2012-05-07 00:53:20 <amiller> if you read one of these authenticated datastructures papers, they're all 3 party protocols, a Source a Server and a Client
102 2012-05-07 00:53:33 <amiller> it's interesting in bitcoin because the miners are effectively the Source and they sign things with their work
103 2012-05-07 00:53:44 <gmaxwell> One interesting thing to do would be to make the POW be exactly N proof publications hashed up togeather.
104 2012-05-07 00:54:47 <amiller> by N you mean all the unspent transactions now?
105 2012-05-07 00:55:20 <amiller> in my scheme the proof of work is exactly K proof publications, K*log N in total
106 2012-05-07 00:56:08 <gmaxwell> Okay, you win.
107 2012-05-07 00:56:16 <amiller> okay! while i've got you here
108 2012-05-07 00:56:19 <amiller> let me add one more layer to this
109 2012-05-07 00:56:19 <gmaxwell> This is a fantastic idea.
110 2012-05-07 00:56:26 <amiller> it's not enough to mine on just the unspent transactions
111 2012-05-07 00:56:30 <amiller> you also need a backlog
112 2012-05-07 00:56:37 <amiller> in order to be able to validate new proposed forks
113 2012-05-07 00:57:02 <amiller> you can either have just the current unspent coins database, some sliding window that goes back some M blocks
114 2012-05-07 00:57:06 <amiller> or all the history forever
115 2012-05-07 00:58:22 <amiller> storage cost is N + M * log N   for a window of M transactions
116 2012-05-07 00:58:26 <gmaxwell> I had assumed that new nodes that were semi-full validators would just listen for a while before becoming fully active. (basically acting as non-validating SPV nodes until they've heard enough history to be confident they weren't being tricked)
117 2012-05-07 01:02:36 <amiller> it's reasonable to set the sliding window to just past wherever you would feel safe checkpointing spv clients
118 2012-05-07 01:05:44 <gmaxwell> yea, ... just to prove that they themselvs were properly bootstrapped. Though is it required? If they mine without proper boostrapping they'll end up orphaned unless the majority was also not correctly bootstrapped.
119 2012-05-07 01:08:08 <amiller> well using the term 'proof-publishing' since that seemed to go over well, it's worth incentivizing proof-publishers that would be capable of telling you that a longer legitimate fork has shown up
120 2012-05-07 01:08:23 <gmaxwell> Fair enough.
121 2012-05-07 01:08:46 <gmaxwell> or even so that they'd have enough history to bootstrap you to that point yourself.
122 2012-05-07 01:11:32 <gmaxwell> amiller: While we're on the subject of crazy ideas have you run into any papers describing compressed lamport signatures? e.g. ones where the public key is sizeof(H()) average signature size is less than sizeof(H())^2*2 ?  I have a scheme for this and I can't believe that no one else has described it previously.
123 2012-05-07 01:12:35 <amiller> https://plus.google.com/100836058911699642153/posts/gV3CAiTbeQ5 zooko and davidsarah posted on there for a while
124 2012-05-07 01:14:31 <gmaxwell> ah zooko does there. great.
125 2012-05-07 01:16:57 <gmaxwell> Now, there is another optimization, which is to instead code in radix-4 instead of radix-2 which halves the amount of private data you must disclose.
126 2012-05-07 01:17:15 <gmaxwell> amiller: thanks much for the link, I should have just thought to ask zooko as I knew he was fond of lamport too.
127 2012-05-07 01:19:02 <gmaxwell> (higher radix doesn't help because while 2^2 == 2*2  2^3 > 2*3)
128 2012-05-07 01:19:03 <amiller> yup, i only know about merkle trees because of hanging out with tahoe-lafs. i went to stay with them in boulder for for a week last month partly in hopes of getting some direction in this proofofwork thing
129 2012-05-07 01:19:43 <amiller> hehe
130 2012-05-07 01:22:09 <amiller> well while we're on the topic of crazy ideas, one of zooko's suggestions was to consider having old unspent transactions expire
131 2012-05-07 01:22:16 <amiller> i think that makes a lot of sense now
132 2012-05-07 01:22:49 <gmaxwell> Meh.. it does potentially, but its such a change I don't think it could be implemented in something called bitcoin.
133 2012-05-07 01:23:02 <amiller> what i think would make the most sense is to consider the bitcoin values to be tied to the amount of storage your unspent inputs consume
134 2012-05-07 01:23:11 <gmaxwell> I think if we ever had to do a disruptive cryptosystem upgrade to avoid ecdsa weaknesses then maybe it could be pulled off.
135 2012-05-07 01:23:50 <gmaxwell> (expiring unspent transactions also serves the purpose of reducing the uncertanty in the currency supply)
136 2012-05-07 01:23:52 <amiller> you're basically renting part of a common resource, you need to keep enough coins in the parking meter
137 2012-05-07 01:24:31 <gmaxwell> amiller: expiration is fairly incompatible with usecases like the cassius coins though.
138 2012-05-07 01:24:42 <amiller> i've grown to prefer thinking of bitcoin as a usage token system for a network that handles contracts rather than as money
139 2012-05-07 01:25:50 <gmaxwell> I agree that it's a worthwhile trade-off in any case, I just suspect that its one which can't be retrofitted in an existing system without ruining the trust in it ('what if the next upgrade breaks _my_ useage!')
140 2012-05-07 01:26:03 <amiller> sure
141 2012-05-07 01:26:13 <amiller> so i used to run about panicking about merged mining for startup networks
142 2012-05-07 01:26:35 <gmaxwell> Why panic? if you don't want it just don't do it.
143 2012-05-07 01:26:42 <amiller> because someone with a lot of gpus would be able to crush a startup network
144 2012-05-07 01:26:57 <amiller> ah i don't think i'm going anywhere consistent with that, strike it
145 2012-05-07 01:27:15 <gmaxwell> (merged mining isn't something that can be invuluntarily imposed in any case)
146 2012-05-07 01:27:54 <amiller> yeah, i meant panicking about startup networks if merged mining isn't available
147 2012-05-07 01:28:21 <amiller> i do think that this proposed scheme makes merged mining useless, but i also think that's a neutral consequence
148 2012-05-07 01:28:53 <amiller> merged mining relies on 'work' being valid between two networks, and if the work is now aligned with the transaction data, then it will be different if the networks are different
149 2012-05-07 01:32:31 <gmaxwell> well it can make independant merged mining impossible, but dependant merged mining still fine.
150 2012-05-07 01:32:57 <amiller> i'm not familiar with those terms
151 2012-05-07 01:33:28 <gmaxwell> E.g. if you're merging only for the purpose of making a timestamp committment to a tree of random data to prove its publication... the fact that the works is slaved to bitcoin is harmless.
152 2012-05-07 01:33:42 <zooko> Hi folks.
153 2012-05-07 01:34:36 <gmaxwell> zooko: hey! I wanted your attention. I see you published a comment about lamport signatures with the public part compressed by transmitting middle nodes. I'm glad someone else had that idea too.
154 2012-05-07 01:36:14 <gmaxwell> zooko: There is another optimizaiton that can be made, which is to code radix-4 digits (e.g. 0,1,2,3 instead of 0,1), which can be used to halve the amount of preimages you must disclose in a signature.  This reduces the effectiveness of the public tree compression, but the 25% off the top reduction in total signature size makes up for it.
155 2012-05-07 01:36:58 <gmaxwell> zooko: I was surprised that I couldn't find any papers on these simple lamport enhancements (beyond the basic one used for chaining signatures so you can use multiple times)
156 2012-05-07 01:38:34 <zooko> Hi! I am busy right now planning some travel with my wife, but I am very concerned about Bitcoin changes/enhancements and would love to talk about it.
157 2012-05-07 01:39:13 <gmaxwell> zooko: very concered about aht changes/enhancements? There aren't any changes/enhancements going on right now.
158 2012-05-07 01:39:18 <gmaxwell> s/aht/what/
159 2012-05-07 01:40:08 <luke-jr> gmaxwell: there aren't? :p
160 2012-05-07 01:40:27 <gmaxwell> Not really!
161 2012-05-07 01:41:10 <luke-jr> HD wallets.
162 2012-05-07 01:41:23 <gmaxwell> (I mean I assume no one is concerned about fixing crash bugs, adding a console to the GUI, or giving people more control over their inputs)
163 2012-05-07 01:42:41 <gmaxwell> zooko: Ah, yes you'd be interested in https://gist.github.com/1799467 save that and read if when you have a chance... though it's not something immediately impending right now.
164 2012-05-07 01:42:54 <gmaxwell> (though even that isn't something people would have to use)
165 2012-05-07 01:43:26 <zooko> The radix choice optimization sounds like a well-understood optimization.
166 2012-05-07 01:43:43 <zooko> David-Sarah Hopwood has a better grasp of all of those than I do.
167 2012-05-07 01:44:13 <gmaxwell> zooko: I'll search, thank you!
168 2012-05-07 01:44:44 <zooko> I think that's called the "Winternitz parameter"...
169 2012-05-07 01:45:09 <zooko> David-Sarah posted quite a lot of notes about hash-based digital signatures on the tahoe-lafs wiki...
170 2012-05-07 01:45:17 <zooko> But hey, why are we talking about digital signatures anyway?
171 2012-05-07 01:45:22 <luke-jr> no idea
172 2012-05-07 01:45:39 <gmaxwell> zooko: that was totally a tangent.
173 2012-05-07 01:45:48 <zooko> Reading back, gmaxwell says "Also serves the purpose" of reducing uncertainty.
174 2012-05-07 01:46:01 <zooko> That is one of my two biggest concerns about Bitcoin right now.
175 2012-05-07 01:46:12 <zooko> That is: the uncertainty about the monetary base.
176 2012-05-07 01:46:21 <zooko> And the propect of that uncertainty increasing over time.
177 2012-05-07 01:46:33 <gmaxwell> zooko: the recent backlog is mostly amiller and I talking about things which have little to zero applicaiblity to bitcoin, because they change system invariants. (e.g. like that one)
178 2012-05-07 01:46:50 <zooko> That one could in theory be upgraded-to, maybe.
179 2012-05-07 01:46:51 <zooko> IMO
180 2012-05-07 01:47:12 <zooko> I'm still catching up on the backlog.
181 2012-05-07 01:47:51 <zooko> Note that the cassius-coins breakage -- and by the way I applaud your thinking about loss of confidence due to backwards-incompatibilities as such -- could be ameliorated by grandfathering-in old coins.
182 2012-05-07 01:47:57 <gmaxwell> Maybe. I'm pretty sure we can't pull that one off without impending risk of cryptosystem compromise.  if people thought ecdsa would be broken soon, they'd accept expiring old ecdsa coins that would return into circulation and blow up the economy. I'm doubtful that anything less would get people to accept expiration.
183 2012-05-07 01:48:08 <gmaxwell> hm. Thats an interesting thought.
184 2012-05-07 01:48:11 <zooko> That would put a stop to the increasing uncertainty but wouldn't retroactively start working on old uncertainty.
185 2012-05-07 01:48:22 <luke-jr> cassius-coins breakage?
186 2012-05-07 01:48:24 <luke-jr> what's this?
187 2012-05-07 01:48:59 <gmaxwell> luke-jr: It would be very adventagious if old outputs expired for several technical and economic reasons, but it would break things like cassius coins... which might expire before you could spend them.
188 2012-05-07 01:49:16 <luke-jr> oh, yes
189 2012-05-07 01:49:30 <zooko> Another possibility that reduces uncertainty over time would be making the monetary base continue to increase.
190 2012-05-07 01:49:44 <gmaxwell> (Technical reasons: spam times out, Economic: we don't know if there is a pot of a million sleeping coins that might someday be injected into the economy all at once)
191 2012-05-07 01:49:48 <zooko> I am well aware that such ideas are politically inflammatory.
192 2012-05-07 01:50:21 <zooko> Another economic reason: without such recycling, the actual monetary base shrinks over time, and possibly even with large jumps.
193 2012-05-07 01:50:36 <gmaxwell> zooko: It's not that it's political inflammatory, it's that such a change would totally undermine trust in the system.  You can't change things people consider essential to the value of their bitcoins without leaving them rightfully thinking "what will the next change be?"
194 2012-05-07 01:50:56 <zooko> That's a good argument.
195 2012-05-07 01:51:08 <gmaxwell> zooko: thats less of a problem, increasing the divisiblity of coins is technically simple and economically neutral (unless you have almost none left)
196 2012-05-07 01:51:35 <zooko> Yeah sure, I don't care about the notion of coins getting too small to be divided.
197 2012-05-07 01:52:05 <amiller> i think unspent-inputs should be charged rent on the storage they take up
198 2012-05-07 01:52:05 <zooko> But, the MB shrinking, especially in unpredictable and potentially large jumps, is still potentially an economic problem even if coins are infinitely divisibl.
199 2012-05-07 01:52:08 <amiller> that solves both problems at once
200 2012-05-07 01:52:36 <zooko> gmaxwell: I like your arguments. I'll cogitate on that.
201 2012-05-07 01:52:42 <gmaxwell> I'd also argue that such a system (one where coin production never stops) isn't obviously non-inflationary, even if you've carefully calibrated it to be.. and as such people who want a non-inflationary system wouldn't be comfortable with it.
202 2012-05-07 01:53:04 <zooko> Yes, that's part of the politically inflammatory aspect.
203 2012-05-07 01:53:07 <BTC_Bear> In order to counter-act attrition, you need to 'print' exactly what was lost. Determining what is lost is the problem, imo.
204 2012-05-07 01:53:17 <zooko> However, even a fixed MB could be inflationary.
205 2012-05-07 01:53:18 <gmaxwell> (it's also perhaps impossible to calibrate it so not without some kind of distributed control that adjusts the inflation rate, and the users probably won't trust the control whatever it is)
206 2012-05-07 01:53:40 <zooko> Inflation is a function of two inputs -- money supply and wealth.
207 2012-05-07 01:53:44 <gmaxwell> BTC_Bear: you don't. You just make coins more divisible. (and at some point switch to using ???BTC as your units)
208 2012-05-07 01:53:52 <zooko> Expert disagree about what sort of "money supply" is the money supply that should be used for that input.
209 2012-05-07 01:54:09 <zooko> The easy, simple thing is to use monetary base, but I wouldn't be surprised if that's actually the wrong input.
210 2012-05-07 01:54:22 <gmaxwell> zooko: I know,  but I'm mostly talking about people's first impression reasoning on the system, not complex economic ananlysis.
211 2012-05-07 01:54:27 <zooko> Anyway, regardless of what you put in for the first input, what you put in for the second input is total wealth in the system.
212 2012-05-07 01:54:36 <zooko> Yeah, okay, that's a good point.
213 2012-05-07 01:54:50 <zooko> So you made some good points about that. I've gotta go. I'll think about these things. Thanks!
214 2012-05-07 01:56:02 <gmaxwell> Okay! TTYL.
215 2012-05-07 01:56:03 <BTC_Bear> Yes, I see the divisibility but if the monetary base decreases at 10% per year, divisibility isn't the answer. $1 is 100 pennies but losing 10% per year it wouldn't matter if you were talking $1 or 100 pennies.
216 2012-05-07 01:56:04 <amiller> by both problems i mean a) it obviously solves the growing storage problem  and b) it solves the same economic purpose as inflation, but this is the only way that's intuitively fair - you pay proportionally for the resource you take up
217 2012-05-07 01:57:14 <BTC_Bear> Now if you are proposing to increase divisibility below a satoshi, then yes. But then that would be a big problem.
218 2012-05-07 01:57:24 <gmaxwell> BTC_Bear: but we're not talking about $1 vs 1000 pennies. Bitcoin is currently divisble to 1e-8.
219 2012-05-07 01:57:58 <gmaxwell> BTC_Bear: I'm pointing out that we can easily make it divisble as deeply as needed. And such a change is both technically simple and economically neutral.. it's just not needed anytime soon.
220 2012-05-07 01:58:26 <BTC_Bear> I agree, it isn't needed soon. But it is a problem that needs to be worked out.
221 2012-05-07 01:58:48 <gmaxwell> If bitcoin survives 40 years then a 10 year migration could be implemented that would give it divisiblity to 1e-128 or something.
222 2012-05-07 01:59:11 <gmaxwell> During that time we'd probably need to do a breaking change to replace the cryptographic functions in any case, so it could be done at the same time if people thought it was needed.
223 2012-05-07 01:59:28 <BTC_Bear> Yes, I was for the migration method.
224 2012-05-07 01:59:35 <BTC_Bear> Over a long period of time.
225 2012-05-07 02:00:03 <gmaxwell> You deploy new versions of software that will switch to a new block format at block XXX where XXX is 5-10 years out.  Anyone who hasn't upgraded at that point stops working.
226 2012-05-07 02:00:27 <BTC_Bear> agreed
227 2012-05-07 02:00:41 <gmaxwell> We used something like this for the network protocol update (though that was just date triggered). It worked okay.
228 2012-05-07 02:03:37 <luke-jr> infinite divisibility is better
229 2012-05-07 02:04:50 <jgarzik> no, infinite divisibility makes life more annoying for very little value
230 2012-05-07 02:06:20 <amiller> well i'll talk about the rent extraction scheme another, the couple of things i'm working on now are all related to paving the way towards opening up bitcoin-scripts for more general use as contracts
231 2012-05-07 02:06:33 <gmaxwell> luke-jr: What jeff said.. though .... life gets harder as soon as we go to more than 4x more divisiblity.. because then we star running out of room in int64.
232 2012-05-07 02:07:00 <gmaxwell> amiller: go workout your ideas with roconner first, since he really really dislikes any additional computing power in scripts.
233 2012-05-07 02:07:08 <amiller> another time*.... anyway a) is how to pay proportionally for the storage as well as computation and b) is to decide what script functionalities could make sense
234 2012-05-07 02:07:09 <amiller> ah yeah
235 2012-05-07 02:07:16 <luke-jr> gmaxwell: at the protocol level, int64 doesn't help much
236 2012-05-07 02:07:24 <luke-jr> except for miners I guess
237 2012-05-07 02:07:47 <gmaxwell> luke-jr: forget the protocol the callers need to handle things too.. already it's hard to convice people to not @#$#@ use float for bitcoin values.
238 2012-05-07 02:07:59 <gmaxwell> (which MTGOX _still_ does at least in some parts of their system)
239 2012-05-07 02:08:03 <luke-jr> >_<
240 2012-05-07 02:10:10 <gmaxwell> making everyone use decNumber (an arbitrary-precision decimal float library) for bitcoin values would not be a kind thing. :)
241 2012-05-07 02:11:19 <gmaxwell> hey, not something I see often:
242 2012-05-07 02:11:28 <luke-jr> gmaxwell: yes, decimal is lame
243 2012-05-07 02:11:34 <luke-jr> gmaxwell: and it would break with 1/3
244 2012-05-07 02:12:22 <amiller> ok, good suggestion, i'll hit up roconnor about that then
245 2012-05-07 02:13:32 <gmaxwell> 05/07/12 01:08:00 50.16.195.87:59371 version message: version 31900, blocks=0 currentbest=178993
246 2012-05-07 02:13:35 <gmaxwell> 05/07/12 01:08:00 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
247 2012-05-07 02:13:38 <gmaxwell> --
248 2012-05-07 02:13:41 <gmaxwell> 05/07/12 02:39:16 50.16.195.87:60642 version message: version 31900, blocks=0 currentbest=179001
249 2012-05-07 02:13:44 <gmaxwell> 05/07/12 02:39:16 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
250 2012-05-07 02:13:48 <gmaxwell> --
251 2012-05-07 02:13:50 <gmaxwell> 05/07/12 02:40:19 50.16.195.87:60647 version message: version 31900, blocks=0 currentbest=179002
252 2012-05-07 02:13:54 <gmaxwell> 05/07/12 02:40:19 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
253 2012-05-07 02:13:57 <gmaxwell> --
254 2012-05-07 02:13:59 <gmaxwell> 05/07/12 04:10:54 50.16.195.87:33799 version message: version 31900, blocks=0 currentbest=179014
255 2012-05-07 02:14:01 <DiabloD3> whats this
256 2012-05-07 02:14:02 <gmaxwell> 05/07/12 04:10:54 ProcessMessage(verack, 0 bytes) : CHECKSUM ERROR nChecksum=e2e0f65d hdr.nChecksum=d9b4bef9
257 2012-05-07 02:14:05 <gmaxwell> someone has a very strangly broken node.
258 2012-05-07 02:14:53 <luke-jr> gmaxwell: also, you don't need to be able to represent the full quantity of all bitcoin units in an int64 ;)
259 2012-05-07 02:15:53 <luke-jr> ie, even if Bitcoin goes that route, the limit is on how big outputs can be
260 2012-05-07 02:16:17 <gmaxwell> I think you ought to be able to represent the full quantity squared, in fact. So then someone can write fixed point code knowing that if they never do anything worse then square it can never overflow.
261 2012-05-07 02:16:51 <luke-jr> well, time will tell what requirements Bitcoin needs to face in the future :P
262 2012-05-07 02:17:45 <gmaxwell> Indeed.
263 2012-05-07 02:19:30 <amiller> i have a toy python implementation of my proposed proof-of-work scheme up here https://github.com/amiller/redblackmerkle i'm not too sure how to be more helpful than that, i suppose i should write to the bitcoin-dev list
264 2012-05-07 02:20:54 <gmaxwell> amiller: etotheipi wants these trees keyed off the output address so its easier to enumerate txn that belong to you.
265 2012-05-07 02:22:48 <gmaxwell> (for domain names they should be keyed on some hash of the name, so that you can have provable nxdomain)
266 2012-05-07 02:23:01 <amiller> mmm
267 2012-05-07 02:23:09 <amiller> i suddenly wonder if it's possible to pay for multiple indexes
268 2012-05-07 02:23:46 <gmaxwell> (though again, I think those requirements risk giving us unbalanced trees)
269 2012-05-07 02:23:58 <amiller> no way, i can balance all the trees
270 2012-05-07 02:24:44 <gmaxwell> OKAY.
271 2012-05-07 02:25:54 <amiller> if you have fancy hash functions, you can get all sorts of different tradeoffs, there's a lattice based technique for an authenticated bloom filter
272 2012-05-07 02:26:03 <amiller> i'm content thinking on log N for everything now
273 2012-05-07 02:26:14 <gmaxwell> amiller: then.. could you make it so you could mine some kinds of outputs (kind being different index types) so long as you don't touch the trees of other kinds?  Then you have merged mining back, but internalized.
274 2012-05-07 02:26:48 <gmaxwell> jgarzik: oh, hey, that sounds like a lowhanging performance improvement!
275 2012-05-07 02:27:46 <amiller> etotheipi's idea is awesome
276 2012-05-07 02:28:02 <jgarzik> gmaxwell: easy to code.  upgrades would be annoying
277 2012-05-07 02:28:03 <amiller> if you had an index for address, then you could get a proof that you're aware of _all_ of the inputs directed to you
278 2012-05-07 02:28:16 <amiller> it's possible to get authenticated range searches
279 2012-05-07 02:28:21 <gmaxwell> (we're really building btrees over txhahes? yuck though it might be wise to do something to provide attack resistance, otherwise someone might start intentionally creating txn with constant prefixes in order to complexity attack the lookups)
280 2012-05-07 02:28:24 <jgarzik> either (a) code the upgrade or (b) d/l block chain again, into new fmt
281 2012-05-07 02:28:52 <gmaxwell> amiller: yea I'd pointed that out in some post before wrt name lookups. Same thing.
282 2012-05-07 02:29:02 <gmaxwell> amiller: and I tried really hard to get the namecoin people to implement it.
283 2012-05-07 02:29:23 <gmaxwell> jgarzik: just make it a flag, and newly downloaded chains get the new mode.
284 2012-05-07 02:29:27 <jgarzik> gmaxwell: yes, it's that ugly.  it's a common enough paradigm... manage your key namespace like a filesystem, where key='foo/obj' and key='bar/obj' tell us something interesting and distinguishing about 'foo' and 'bar' subsets
285 2012-05-07 02:29:43 <jgarzik> common enough... but annoying and performance-killing, for bitcoin
286 2012-05-07 02:31:20 <gmaxwell> explains some of the extreme write inflation I saw on the indexes.
287 2012-05-07 02:32:14 <jgarzik> gmaxwell: we store tx hashes, block hashes, and misc. metadata (hashBestChain) all in one big btree
288 2012-05-07 02:32:38 <jgarzik> gmaxwell: tx hashes and block hashes clearly want to be separate indices
289 2012-05-07 02:33:11 <gmaxwell> meh. right. maintaining both forms would be a code mess.
290 2012-05-07 02:33:13 <jgarzik> maybe satoshi was worried about ACID, but transactions in bdb work fine across databases
291 2012-05-07 02:33:29 <jgarzik> gmaxwell: indeed
292 2012-05-07 02:35:14 <gmaxwell> I can see the reason for being conservative unexpected bdb behavior can be the end of bitcoin (cause irreparable splits) BDB usually seems to be pretty good (in spite of people's whines) but I don't think it's really sutiable for the minor-acid-glitch-makes-millions-of-dollars-in-value-vanish-forever that we're asking of it.
293 2012-05-07 02:38:59 <amiller> gmaxwell, that's interesting, it seems like it could make sense to have several different overlays of the same data
294 2012-05-07 02:40:45 <amiller> the requirements for a valid transaction would be more constrained the more layers inside you go, with bitcoin being the outermost layer
295 2012-05-07 02:50:29 <BlueMatt> gmaxwell: I would argue bdb would be better in that scenario than literally anything else, but that just means we need to code redundancy and sanity checks into our code...
296 2012-05-07 02:50:40 <BlueMatt> s/literally/just about/
297 2012-05-07 02:51:49 <gmaxwell> BlueMatt: I'm not sure. Reorgs are hard and its very scarry the complicated way they interact wth the database.
298 2012-05-07 02:52:00 <gmaxwell> Without them our needs for the database are stupidly simple.
299 2012-05-07 02:52:41 <BlueMatt> gmaxwell: yea, and in that case Id rather have the well-tested bdb than something we create or most other dbs
300 2012-05-07 02:53:40 <BlueMatt> not to say more research needs to be done in all the options in bdb, but...
301 2012-05-07 02:56:41 <gmaxwell> BlueMatt: there really are all kinds of options. For example, if you have an otherwise valid block and a tx index lookup fails you probaby should seq scan the whole blockchain because its far more likely that your index got corrupted than someone mined a block with some non-existing inputs.
302 2012-05-07 02:57:21 <BlueMatt> yea, thats what Im saying - code in more redundancy against db failure, but Id rather stick with bdb for complicated things like reorgs, is my point
303 2012-05-07 02:57:41 <gmaxwell> And we absolutely are seeing potentially network ending BDB related events in the wild, we've just been very lucky that none of them have been the sort that happen to trigger on all nodes at once.
304 2012-05-07 02:57:52 <gmaxwell> (for example! the fact that large reorgs fail!)
305 2012-05-07 02:58:13 <BlueMatt> yea, thats why I said more research in bdb options would also be nice
306 2012-05-07 02:58:33 <BlueMatt> but, again, I think we would shoot ourselves in the foot if we went to our own db to handle all the complicated mess of reorgs
307 2012-05-07 02:59:01 <gmaxwell> The fact that such a failure arises out of some sneakyness of BDB vs bugs isn't really relevant, the failure is all that matters. :)
308 2012-05-07 02:59:14 <BlueMatt> true
309 2012-05-07 02:59:26 <gmaxwell> And this stuff is all very hard to test because BDB encapsulates an enormous amount of invisible state.
310 2012-05-07 02:59:32 <BlueMatt> but researching potential bdb sneakiness seems better than writing our own, imho
311 2012-05-07 02:59:44 <gmaxwell> Probably. Still it's a reason to be paranoid.
312 2012-05-07 02:59:59 <BlueMatt> simplifying db code, and in the process, researching bdb further, that is
313 2012-05-07 03:00:12 <BlueMatt> oh, absolutely, more paranoia is almost always better, in this case
314 2012-05-07 03:00:19 <gmaxwell> I'd like to have a non-bdb based full node, even if it was slow as @#$#@$@.. just so we could have loud klaxon if it ever disagreed with the reference code.
315 2012-05-07 03:00:34 <gmaxwell> I was hoping roconner would give us that, but I think he burned out or something. :(
316 2012-05-07 03:00:54 <BlueMatt> Id like to have a ton of different full nodes, so that we could have that
317 2012-05-07 03:09:49 <BlueMatt> how far is like libbitcoin towards being a full node?
318 2012-05-07 03:11:41 <setkeh> Does anyone know of a Module for ZenCart that can execute a shell command on sucessful payment instead of useing a shipping module
319 2012-05-07 03:36:22 <gmaxwell> sipa: my test user wasn't so bad. They made a backup of the chain first. I got them to start the patched code on the backup and they let it run for an hour but it remained stuck.
320 2012-05-07 03:36:32 <gmaxwell> sipa: I'm going to try to talk a copy of the chain out of the,
321 2012-05-07 03:36:44 <wumpus> but I don't think it's really sutiable for the minor-acid-glitch-makes-millions-of-dollars-in-value-vanish-forever that we're asking of it <-   not that writing your own code instead of battle-tested db code will necessarily be better , of course
322 2012-05-07 03:36:55 <gribble> New news from bitcoinrss: laanwj opened pull request 1215 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1215>
323 2012-05-07 03:37:44 <gmaxwell> wumpus: indeed, there may currently be no better option but as I mentioned later, simply having more full implementations to compare would be good.
324 2012-05-07 03:39:35 <wumpus> next step up would probably be a fully-fledged RDMS
325 2012-05-07 03:40:18 <gmaxwell> wumpus: RE: the log viewer comments on github. I think you have the wrong perspective.  I don't really give a shit what the user wants for his logging in order to diagnose problems he's seeing with bitcoin I need to know what bitcoin has been saying in the debug log greatly. Logging to the system log would actually counterprodutive to my interests.
326 2012-05-07 03:40:51 <gmaxwell> (if the user wants that, he can have it too.. I don't really care but it doesn't help me troubleshoot some random user whos crying for help)
327 2012-05-07 03:41:25 <wumpus> gmaxwell, that may be true, but unless there is some liberally-licensed log viewer that we can integrate, that's just not a project I'm starting on
328 2012-05-07 03:42:01 <gmaxwell> wumpus: does QT not have some texteditor widget that can do everything needed?
329 2012-05-07 03:42:16 <wumpus> oh sure it does... but put 4Gb of data in it and it's insta-dead
330 2012-05-07 03:42:44 <gmaxwell> wumpus: 'fully-fledged RDMS' is really the wrong direction. Except for needing to change the transactions in the open set atomically during a reorg bitcoind's database needs are just simple hash lookups on blocks and txns.
331 2012-05-07 03:43:31 <wumpus> unless you put the log in some database too, of course, which supports range queries... but that makes it impossible to process it with text tools
332 2012-05-07 03:43:34 <gmaxwell> And this stuff people want to do with tree commitments on open transactions to enable semi-full nodes would require moving the open transaction set management into bitcoin anyways, or at least more than it is now.
333 2012-05-07 03:44:06 <gmaxwell> wumpus: well we could easily track the last 100 entries or whatever in memory.
334 2012-05-07 03:44:18 <wumpus> that's what I proposed?!
335 2012-05-07 03:45:04 <gmaxwell> Okay, fair enough.  I'm surprised that there isn't a text editor widget that doesn't require the file being in memory, but alas. okay.
336 2012-05-07 03:50:37 <wumpus> I'm sure someone, somewhere, at some time wrote such a thing
337 2012-05-07 04:00:32 <gjs278> can you rate limit the network connection for bitcoind
338 2012-05-07 04:00:46 <gjs278> sometimes they start taking like 700kb/s upload on me
339 2012-05-07 04:07:35 <gmaxwell> gjs278: there isn't anything built into bitcoin to do that  but you can do it yourself at your router if it has that functionality.
340 2012-05-07 04:08:01 <gmaxwell> gjs278: if you disable listening and make outbound counnections only you'll rarely use a lot of bandwidth those spikes are new nodes pulling the chain from you.
341 2012-05-07 04:14:20 <gjs278> yeah ok
342 2012-05-07 06:58:13 <jine> Is there any easy way/script/whatever to show the coinbase of a block?
343 2012-05-07 07:04:32 <sipa> jine: getblock rpc?
344 2012-05-07 07:11:35 <gribble> New news from bitcoinrss: olea opened pull request 1216 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1216>
345 2012-05-07 07:22:16 <Eliel> gmaxwell: I think I just realised why my network connection is laggy sometimes. It's bitcoind sending blocks. However, I don't think it's a very good solution to have people wanting to limit bandwidth usage to go outbound only. It'll cripple the network.
346 2012-05-07 07:22:55 <gmaxwell> Eliel: no it won't. If you're starved enough on bandwidth that it's a problem you probably really should be outbound only.
347 2012-05-07 07:23:30 <gmaxwell> Though sure, some rate limiting for block feeding would be nice  but I think we first need the software to cope with peers that feed blocks slowly.
348 2012-05-07 07:24:34 <Eliel> my upstream can handle 100kB/s at maximum but using all that does add noticeable latency.
349 2012-05-07 07:25:01 <Eliel> I guess I might consider creating a QoS script again.
350 2012-05-07 07:25:57 <gmaxwell> It's pretty reasonable to deprioritize bitcoin... it's not latency sensitive in the slighest.
351 2012-05-07 07:47:46 <jine> sipa: getblock rpc doesn't show the coinbase, does it?
352 2012-05-07 11:07:03 <Diapolo> sipa: Did you have the time to do that Win-build for me?
353 2012-05-07 11:08:17 <Diapolo> and hello everyone
354 2012-05-07 11:08:22 <sipa> there was a bug in master yesterday that prevented me from building, let me try again
355 2012-05-07 11:15:37 <denisx> has anybody else problems with bitcoin running at 100% all the time?
356 2012-05-07 11:15:49 <denisx> version 0.6.1
357 2012-05-07 11:15:54 <gmaxwell> denisx: on OSX?
358 2012-05-07 11:16:00 <denisx> yep, and on freebsd
359 2012-05-07 11:16:08 <gmaxwell> (I thought we killed that bug on OSX&)
360 2012-05-07 11:16:16 <gmaxwell> The GUI?
361 2012-05-07 11:16:24 <sipa> it's probably a different one, if it's on FreeBSD as well
362 2012-05-07 11:16:49 <denisx> the problem appeared some time after 0.6.0
363 2012-05-07 11:17:04 <sipa> after? :o
364 2012-05-07 11:17:17 <denisx> 0.6.0 did not had that problem
365 2012-05-07 11:17:56 <drizztbsd> denisx: are you using gen=1? :P
366 2012-05-07 11:18:03 <denisx> no
367 2012-05-07 11:18:13 <jine> "the transaction will be reversed. The case is now closed.Inquiry by PayPal - Case ID: "
368 2012-05-07 11:18:23 <jine> Oh crap, wrong channgel :) sorry
369 2012-05-07 11:18:34 <sipa> Diapolo: can you check using gdb which thread/functions are consuming the cpu?
370 2012-05-07 11:18:36 <drizztbsd> (never buy/sells bitcoin with paypal :P)
371 2012-05-07 11:18:45 <sipa> *denisx:
372 2012-05-07 11:18:49 <Diapolo> Are you using the 0.6.1 final? The RCs had a GUI bug that caused high CPU usage.
373 2012-05-07 11:18:56 <denisx> yes, final
374 2012-05-07 11:20:11 <gmaxwell> wumpus: ^
375 2012-05-07 11:21:03 <Diapolo> I can verify a high CPU usage while syncing.
376 2012-05-07 11:21:05 <Tyklol> denisx: I'll try upgrading to 6.1 on freebsd and see if I can reproduce it tonight, might be able to see what is going on with dtrace :)
377 2012-05-07 11:24:33 <Diapolo> I think that happens during block-chain downloads, because the GUI is redrawn at a too high rate. wumpus want to fix this with https://github.com/bitcoin/bitcoin/pull/1205
378 2012-05-07 11:27:31 <sipa> Diapolo: http://bitcoin.sipa.be/builds/0.6.1-35-g34a0eab/
379 2012-05-07 11:28:02 <denisx> time is used in ThreadOpenConnections2
380 2012-05-07 11:28:05 <sipa> https://github.com/Diapolo/bitcoin/commit/34a0eab
381 2012-05-07 11:29:31 <sipa> Diapolo: no particular warnings when building
382 2012-05-07 11:30:12 <gmaxwell> denisx: seems unlikely unless Sleep() doesn't work on your platform for some reason.
383 2012-05-07 11:30:31 <Diapolo> sipa: great, thank you
384 2012-05-07 11:31:10 <Diapolo> sipa: I can start the debugger in the Qt creator, but I never used it to track down any CPU usage bugs ... :-/.
385 2012-05-07 11:31:23 <sipa> Diapolo: i actually meant denisx
386 2012-05-07 11:31:57 <Diapolo> sipa: alright :) as I wrote I think it's related to GUI updates, but that is in contrast to ThreadOpenConnections2
387 2012-05-07 11:32:01 <denisx> sipa: on freebsd, no. the osx version is the prebuild one from sourceforge
388 2012-05-07 11:32:14 <sipa> could be
389 2012-05-07 11:38:44 <denisx> were there any changes to ThreadOpenConnections2 after 0.6.0?
390 2012-05-07 11:41:29 <gmaxwell> erp.
391 2012-05-07 11:41:32 <gmaxwell> WAIT() is busy.
392 2012-05-07 11:45:44 <sipa> gmaxwell: it's a loop, but not a busy loop
393 2012-05-07 11:46:15 <gmaxwell> ah, the lock itself sleeps. okay.
394 2012-05-07 11:46:21 <Diapolo> sipa: that build works, thank you very much ... is it okay to let people test this so I can check if it works?
395 2012-05-07 11:46:21 <sipa> yes
396 2012-05-07 11:48:02 <gmaxwell> denisx: there were changes but none which should have obviously caused this. It would be great if you could attack a debugger and break that thread a few times to see where it was landing.
397 2012-05-07 11:48:51 <sipa> Diapolo: as long as you either warn them it's experimental, or assume responsability yourself :)
398 2012-05-07 11:48:57 <denisx> I did
399 2012-05-07 11:49:10 <denisx> last place in bitcoin is ThreadOpenConnections2
400 2012-05-07 11:49:20 <sipa> where exactly?
401 2012-05-07 11:49:26 <denisx> then comes sched_yield, swtch_pri
402 2012-05-07 11:49:51 <sipa> in Sleep you mean?
403 2012-05-07 11:50:18 <denisx> I just attached Instruments to the running binary
404 2012-05-07 11:50:30 <sipa> i have no idea what that means
405 2012-05-07 11:51:01 <denisx> osx GUI version of dtrace is called Instruments
406 2012-05-07 11:53:14 <denisx> no source code
407 2012-05-07 12:07:41 <denisx> looks it is time to test git bisect
408 2012-05-07 12:11:02 <Diapolo> Can anyone tell me if it's possible to use posix_fallocate() on non Windows systems like Mac, Linux / Unix?
409 2012-05-07 12:11:22 <Diapolo> I mean is it somehow standard.
410 2012-05-07 12:11:31 <gmaxwell> The word "posix" is a keyword there...
411 2012-05-07 12:11:49 <gmaxwell> I don't know if mac has it but linux certantly does.
412 2012-05-07 12:15:42 <Diapolo> Now things get bad, I need to create a Mac / Linux version I can't test or com
413 2012-05-07 12:15:43 <Diapolo> pile ^^
414 2012-05-07 12:16:04 <gmaxwell> Diapolo: I can give you a shell.
415 2012-05-07 12:16:40 <gmaxwell> and even set it all up to compile for you.
416 2012-05-07 12:17:59 <Diapolo> gmaxwell: What are the things I need to know, before you do some work and I can't even use it.
417 2012-05-07 12:18:17 <Diapolo> you remember that Windows-Guy-thing ^^
418 2012-05-07 12:19:13 <gmaxwell> How to use putty and winscp.  I'll be glad to walk you through it. thought it might need to wait until a bit later.
419 2012-05-07 12:21:21 <Diapolo> At first I want to look a bit into what I need to do the code and afterwards (perhaps in a few days) we can talk further, ok?
420 2012-05-07 12:22:01 <Diapolo> no rush or hurry and thanks for your helping hand :)
421 2012-05-07 12:23:16 <jgarzik> Diapolo: what do you need to know about fallocate?
422 2012-05-07 12:23:33 <jgarzik> Diapolo: what are you trying to do?
423 2012-05-07 12:23:54 <jgarzik> Diapolo: it is almost always easier, and more portable, to simply write zeroes to a file
424 2012-05-07 12:25:26 <Diapolo> jgarzik: I want to pre-allloc the space needed for the blk000x.dat files ... I have a patch that does this for Windows (experimental) and would like to add it for other Systems aswell.
425 2012-05-07 12:26:39 <drizztbsd> why do you want to pre-allocate?
426 2012-05-07 12:27:47 <Diapolo> to have that file in 1 fragment
427 2012-05-07 12:27:57 <jgarzik> drizztbsd: slow growing files are the worst use case for fragmentation
428 2012-05-07 12:28:10 <drizztbsd> not if you are using ssd :P
429 2012-05-07 12:28:21 <jgarzik> drizztbsd: yes, even if you use an ssd
430 2012-05-07 12:28:25 <Diapolo> I dont consider SSD standard!
431 2012-05-07 12:28:32 <jgarzik> irrelevant
432 2012-05-07 12:28:46 <jgarzik> an SSD must still churn out more ATA commands, more interrupts, more completions
433 2012-05-07 12:30:27 <jgarzik> Diapolo: posix_fallocate() must necessarily degenerate to writing zeros inside libc -- if not downright failure
434 2012-05-07 12:33:21 <Diapolo> jgarzik: I read about filesystems that support quick pre-allocation, so that no zeroes need to be written to that space.
435 2012-05-07 12:33:40 <jgarzik> Diapolo: yes
436 2012-05-07 12:33:45 <Diapolo> jgarzik: I even don't know if its an idea that will work on non Windows systems ... as I'm a pure Win user
437 2012-05-07 12:34:19 <jgarzik> Diapolo: some filesystems do support it on non-Windows...  and some do not.  thus, you must be prepared to handle the "they do not" case.
438 2012-05-07 12:34:43 <Diapolo> jgarzik: sure that needs to be added and taken into coding considerations
439 2012-05-07 12:34:53 <Diapolo> Currently I started with this here: https://github.com/Diapolo/bitcoin/commit/183e99e7c77b52e8394f6c456d9ec53ea7f4bdb6
440 2012-05-07 12:34:53 <sipa> is there any reason to not just write zeroes?
441 2012-05-07 12:35:05 <sipa> hahuang65: which version?
442 2012-05-07 12:35:06 <Diapolo> sipa: that takes a long time for 2GB file
443 2012-05-07 12:35:11 <helo> sipa: 0.6.1
444 2012-05-07 12:35:34 <helo> bitcoin-qt_0.6.1-precise0_amd64.deb
445 2012-05-07 12:35:52 <sipa> helo: mind sending your debug.log file?
446 2012-05-07 12:36:02 <helo> where to?
447 2012-05-07 12:36:07 <sipa> pastebin?
448 2012-05-07 12:36:22 <sipa> or pieter dot wuille at gmail dot com
449 2012-05-07 12:36:23 <gmaxwell> helo: I assume this is syncing up a new node?
450 2012-05-07 12:36:28 <gmaxwell> ;;tslb
451 2012-05-07 12:36:28 <gribble> Error: "tslb" is not a valid command.
452 2012-05-07 12:36:31 <gmaxwell> ;;bc,tslb
453 2012-05-07 12:36:31 <gribble> Time since last block: 46 minutes and 48 seconds
454 2012-05-07 12:36:38 <sipa> ah
455 2012-05-07 12:36:39 <helo> gmaxwell: yes
456 2012-05-07 12:36:46 <sipa> right, that doesn't mean much
457 2012-05-07 12:36:56 <sipa> the node you were downloading from can just have gone offline
458 2012-05-07 12:36:58 <gmaxwell> I think that behavior is not surprising. If the node you are initially pulling from goes away you won't start pulling again until the next block.
459 2012-05-07 12:37:01 <jgarzik> Diapolo: first off, posix_fallocate() takes a file descriptor, not a FILE*.  So, fileno(hFile) not hFile
460 2012-05-07 12:37:16 <jgarzik> posix_fallocate() will pause for a LONG TIME if the underlying fs does not support
461 2012-05-07 12:37:21 <gmaxwell> (we should probably change that behavior...)
462 2012-05-07 12:38:53 <Diapolo> jgarzik: thanks that's the first fix ^^ it was just a quick write down and is no official pull
463 2012-05-07 12:39:22 <Diapolo> jgarzik: How could I determine if the FS supports quick pre-alloc?
464 2012-05-07 12:39:34 <sipa> Diapolo: i doubt you can
465 2012-05-07 12:39:40 <jgarzik> Diapolo: it is difficult
466 2012-05-07 12:39:52 <sipa> Diapolo: i wonder, if you can't build for windows, how do you test it yourself?
467 2012-05-07 12:40:11 <jgarzik> sipa: anything is -possible- ;)  fallocate (not posix_fallocate) will return EOPNOTSUPP on Linux
468 2012-05-07 12:40:26 <Diapolo> I can build on WIndows but not statically linked, so I can't redistribute builds.
469 2012-05-07 12:40:35 <Diapolo> sipa: they only run on my machine then
470 2012-05-07 12:41:10 <sipa> hmm, ok
471 2012-05-07 12:41:59 <Diapolo> sipa: I could not figure out how to do this as it seems it's a mess with Qt on Windows, so I don't investigated further.
472 2012-05-07 12:42:07 <helo> too big for pastebin... helo.org/debug.log
473 2012-05-07 12:42:40 <sipa> helo: right, i was too fast; just wait for a new block first
474 2012-05-07 12:42:49 <helo> oh, yep there it goes
475 2012-05-07 12:42:54 <sipa> ;;bc,tslb
476 2012-05-07 12:42:55 <gribble> Time since last block: 3 minutes and 49 seconds
477 2012-05-07 12:42:58 <sipa> if it remains stalled, you may have an interesting situation
478 2012-05-07 12:44:56 <Diapolo> jgarzik: If you are interested in helping me with this that would be rather cool, do you think it's worth to pursuit that idea or do you consider it worthless for the client?
479 2012-05-07 12:45:37 <sipa> Diapolo: i like the idea of preallocation, but it'd do it a bit more incrementally
480 2012-05-07 12:45:50 <sipa> like adding blocks of 100MiB
481 2012-05-07 12:45:59 <gmaxwell> esp jumping 2 more gb when it adds a second block file would be bad.
482 2012-05-07 12:46:08 <jgarzik> Diapolo: sipa has the right idea
483 2012-05-07 12:46:10 <Diapolo> it does not do it
484 2012-05-07 12:46:18 <jgarzik> initial block download shouldn't be too bad, WRT fragmentation
485 2012-05-07 12:46:22 <Diapolo> it creates another one if our limit is reached
486 2012-05-07 12:46:25 <jgarzik> it's the slow-growing afterwards that hurts
487 2012-05-07 12:46:40 <jgarzik> even 4MB at a time would be highly useful
488 2012-05-07 12:48:16 <Diapolo> I tried the code with 64MB block files and that worked ... I would like to get the base running on non Win-Systems, the values can be tuned then.
489 2012-05-07 12:49:00 <jgarzik> the main bitcoin change, IMO, would be to avoid appending to the end of the file, but rather at a file position of our choice
490 2012-05-07 12:49:16 <sipa> jgarzik: that's what Diapolo's branch does
491 2012-05-07 12:49:55 <jgarzik> so
492 2012-05-07 12:50:05 <Diapolo> and I used std::fstream
493 2012-05-07 12:50:05 <jgarzik> I don't see any need for preallocate, vs. writing zeroes
494 2012-05-07 12:50:21 <jgarzik> writing 4MB of zeroes is easy, quick and highly portable
495 2012-05-07 12:50:31 <Diapolo> and harmfull to SSDs
496 2012-05-07 12:50:38 <jgarzik> hardly
497 2012-05-07 12:50:57 <Diapolo> the more you do this the more write/erase cycles are eaten
498 2012-05-07 12:51:09 <Diapolo> but that's another problem ^^
499 2012-05-07 12:51:26 <jgarzik> Diapolo: run the numbers..  it is clearly lost in the noise
500 2012-05-07 12:51:36 <jgarzik> _one_ preallocation is nothing
501 2012-05-07 12:53:10 <Diapolo> for a 2GB file with adding 4MB chunks that would be 512 cycles vs. 0 for a big file and perhaps 512 fragments vs. a single one
502 2012-05-07 12:53:21 <Diapolo> you are right, the cycles are of no harm really
503 2012-05-07 12:55:34 <sipa> i wonder what the performance difference is between 4 and 64 MiB blocks
504 2012-05-07 12:56:24 <sipa> because compared to 1.7 GiB diskspace used by the blockchain, 0.064 GiB is negligable
505 2012-05-07 12:56:55 <sipa> excuse me, 0.0625 GiB ;)
506 2012-05-07 12:58:08 <Diapolo> sipa: :-P
507 2012-05-07 12:59:01 <sipa> writing 64 MiB of zeroes may of course already cause some UI sluggishness
508 2012-05-07 13:00:05 <Diapolo> I really dislike that zero-writing. Writing nothing just to allocate diskspace seems to be not a good style.
509 2012-05-07 13:00:31 <jgarzik> quite the opposite.  it is (a) simple and (b) works everywhere, guaranteed.
510 2012-05-07 13:00:49 <jgarzik> preallocate(), instead, requires arcane filesystem support that may or may not exist
511 2012-05-07 13:00:52 <sipa> it's not the most efficient solution, but it is certainly the easiest and most portable one
512 2012-05-07 13:01:06 <Diapolo> on Windows it's easy and guaranteed to work ^^
513 2012-05-07 13:01:15 <jgarzik> if it does not exist, you _must_ handle the writing zeroes case _anyway_, either explicitly or implicitly
514 2012-05-07 13:01:32 <sipa> to be honest, i don't mind having a #ifdef WIN32 block there
515 2012-05-07 13:02:01 <Diapolo> I understand that portable aspect, too ... but I would also say nothing agains something that is possible easy on Linux and not on Win.
516 2012-05-07 13:02:23 <Diapolo> So have the best of both worlds and a working portable base.
517 2012-05-07 13:04:48 <Diapolo> I'll leave for now, bye.
518 2012-05-07 13:18:23 <gribble> New news from bitcoinrss: rebroad opened issue 1217 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1217>
519 2012-05-07 14:32:57 <jgarzik> hmmmmm
520 2012-05-07 14:34:35 <jgarzik> can someone refresh my memory on what happens if two wallets both hold the same private key?  i.e. for redundancy, site A and site B both maintain the same list of private keys.  site A spends some coins, broadcasting the TX to all (including site B).  will bitcoind running on site B properly handle all that?
521 2012-05-07 14:36:05 <gavinandresen> mostly.  If site B decides to spend using that private key before it sees A's transaction you can end up with a will-never-be-confirmed transaction, if I recall correctly
522 2012-05-07 14:38:23 <t7> jgarzik: its worked fine for me, i share a wallet at home and at work
523 2012-05-07 14:38:52 <luke-jr> t7: that's a bad idea for other reasons btw :p
524 2012-05-07 14:38:59 <luke-jr> they'll fork eventually
525 2012-05-07 14:40:28 <jgarzik> gavinandresen: yeah, I can work to prevent that
526 2012-05-07 14:40:34 <sipa> gavinandresen is right
527 2012-05-07 14:40:53 <jgarzik> my software would necessarily have to deal with private key distribution
528 2012-05-07 14:41:17 <jgarzik> and any issues that may arise thereof from poor/corrupted/improper/delayed distribution
529 2012-05-07 14:41:29 <sipa> jgarzik: i once made a rejectedtx branch, that kept two extra booleans per transaction, one whether it's active, and one whether it's in conflict with the blockchain
530 2012-05-07 14:41:37 <sipa> i should rewrite it
531 2012-05-07 14:41:47 <sipa> that could detect and recover from such cases
532 2012-05-07 14:41:48 <gavinandresen> if you sync newly generated keypool keys often enough and you only spend from one at time and never switch from one to another if you have 0-confirmation spends...
533 2012-05-07 14:41:59 <sipa> luke-jr: indeed
534 2012-05-07 14:42:55 <jgarzik> let bitcoind do the heavy lifting
535 2012-05-07 14:42:55 <luke-jr> jgarzik: kindof like My Wallet, but p2p?
536 2012-05-07 14:43:11 <jgarzik> not peer to peer, tightly integrated cloud controlled by me
537 2012-05-07 14:43:17 <luke-jr> i c
538 2012-05-07 14:43:20 <jgarzik> distributed computing, yes
539 2012-05-07 14:43:36 <luke-jr> so a My Wallet clone? <.<
540 2012-05-07 14:43:44 <jgarzik> trying to design a service that doesn't rely on a single bitcoind wallet
541 2012-05-07 14:44:11 <jgarzik> a resilient design should handle a single "virtual" wallet shared across multiple bitcoind's, IOW
542 2012-05-07 14:45:34 <jgarzik> I can guarantee that site B will never spend coin 1234, if site A has already spent coin 1234
543 2012-05-07 14:45:57 <jgarzik> but site B might see a TX before it receives new private keys
544 2012-05-07 14:46:45 <sipa> won't be a problem
545 2012-05-07 14:49:06 <sipa> jgarzik: would a deterministic wallet help?
546 2012-05-07 14:50:31 <jgarzik> sipa: perhaps marginally.  the underlying assumption i must make is that any one or two bitcoind's may die or get stuck, but my distributed bitcoin engine needs to continue processing transactions for customers regardless.  most of the logic occurs at a higher level.
547 2012-05-07 14:51:57 <jgarzik> keys generated by a distributed, component-can-fail system, stored in a distributed filesystem, etc.  those are fed to downstream bitcoind's, which import the keys and assist in watching for transactions, and creating new transactions
548 2012-05-07 14:53:15 <jgarzik> being p2p, a cluster of bitcoind's is wonderfully resilient to failure anyway
549 2012-05-07 14:53:44 <jgarzik> so the main issue is keeping the wallets sync'd (or really, just "not confused")
550 2012-05-07 14:58:26 <luke-jr> jgarzik: HD wallets would keep them in sync without any direct communication or controller
551 2012-05-07 14:58:48 <gavinandresen> jgarzik sipa : I want to start a Bitcoin Testing Project organization to accept donations and then fund QA, testing tools, etc.  And maybe vulnerability bounties.
552 2012-05-07 14:59:42 <zooko> gavinandresen: neat idea!
553 2012-05-07 15:00:05 <gavinandresen> And I'm thinking of doing something slightly crazy and using bettermeans.com  to make it a non-traditional, distributed organization....
554 2012-05-07 15:00:34 <jgarzik> gavinandresen: I want to start a Bitcoin Network Maintenance and Monitoring org to accept donatoins, then fund nodes and seeds
555 2012-05-07 15:00:50 <jgarzik> and real time network metrics and alert
556 2012-05-07 15:01:11 <jgarzik> luke-jr: HD?
557 2012-05-07 15:01:56 <gavinandresen> jgarzik: good idea!
558 2012-05-07 15:02:21 <jgarzik> an org devoted to operational network health
559 2012-05-07 15:02:40 <denisx> can someone connect his bitcoind to 195.160.173.3
560 2012-05-07 15:02:58 <jgarzik> anyway, babysitting time ("quiet time" -> "nap time", hopefully)
561 2012-05-07 15:03:09 <gavinandresen> we've got the same goals-- i want proactive testing so the network stays healthy (and i see the testing project as focusing on cross-implementation issues/tools)
562 2012-05-07 15:03:16 <zooko> Enjoy babysitting!
563 2012-05-07 15:03:27 <luke-jr> jgarzik: sipa's Hierarchial Deterministic wallets :p
564 2012-05-07 15:04:32 <Joric> i'll implement those in js ) already tested hmac-sha512 works just fine
565 2012-05-07 15:07:20 <luke-jr> gavinandresen: so what's up with 0.6.2? tagging?
566 2012-05-07 15:07:54 <luke-jr> I made some Windows builds at http://luke.dashjr.org/programs/bitcoin/files/bitcoind/0.6.2/test/rc1/ if more testing is desired
567 2012-05-07 15:08:16 <gavinandresen> luke-jr: just "soak" testing-- I've been running the fixes on three machines since yesterday
568 2012-05-07 15:10:28 <luke-jr> gavinandresen: ping me if you want me to do another gitian build when you tag it (fyi, I think sipa and BlueMatt are gitian-down atm)
569 2012-05-07 15:10:29 <luke-jr> bbl
570 2012-05-07 15:14:00 <sipa> i can do gitian builds
571 2012-05-07 15:14:29 <sipa> gavinandresen: the stuck download fix fix seems to need another fix, btw...
572 2012-05-07 15:16:00 <gavinandresen> sipa: ok.  Now I'm regretting including it in the 0.6.2 cherry-picks....
573 2012-05-07 15:18:35 <gmaxwell> meh, it's an important fix. ... if it were right. I've got a user sending me a stuck chain to test on today.
574 2012-05-07 15:31:14 <DiabloD3> [01:02:21] <jgarzik> an org devoted to operational network health
575 2012-05-07 15:31:34 <DiabloD3> jgarzik: make bitcoin run on alpine and Ill run a perm supernode.
576 2012-05-07 15:31:38 <DiabloD3> for free.
577 2012-05-07 15:37:00 <Graet> will p2pool orphaning thier own blocks become an issue as p2pool grows? http://blockchain.info/
578 2012-05-07 15:37:37 <DiabloD3> Graet: well, this is one of the reasons I want to run a bitcoin supernode
579 2012-05-07 15:37:54 <Graet> so yes?
580 2012-05-07 15:39:25 <gmaxwell> Graet: no.
581 2012-05-07 15:39:33 <gmaxwell> Graet: has nothing to do with p2pool's size.
582 2012-05-07 15:39:45 <DiabloD3> p2pool would have to be the size of bitcoin for it to be an issue I think
583 2012-05-07 15:39:51 <gmaxwell> DiabloD3: nope.
584 2012-05-07 15:40:01 <DiabloD3> gmaxwell: well, blocks are orphaned periodically
585 2012-05-07 15:40:09 <DiabloD3> if we do all the hashing, we get all the orphans.
586 2012-05-07 15:40:30 <forrestv> no more than everyone would if everyone were solo mining
587 2012-05-07 15:40:34 <gmaxwell> Well sure, but there isn't any special p2pool orphan vulnerability (except perhaps due to bugs)
588 2012-05-07 15:40:46 <Graet> well as p2pool grows the potential to orphan thier own blocks must also grow?
589 2012-05-07 15:41:13 <Graet> due to lots of nodes working "independently" but "together"
590 2012-05-07 15:41:18 <gmaxwell> Graet: any normal pool running multiple bitcoin daemons has the same risk.
591 2012-05-07 15:41:41 <DiabloD3> yeah what gmaxwell said
592 2012-05-07 15:41:50 <Graet> i understand gmaxwell - we run 2, but the chance of 2 versus ?p2pool nodes?
593 2012-05-07 15:41:54 <gmaxwell> (and p2pool in theory has low overhead node to node block communication, since p2pool nodes can realy inside p2pool with less validation overhead)
594 2012-05-07 15:42:26 <Graet> ok, well i will watch with interest :)
595 2012-05-07 15:42:54 <gmaxwell> Graet: fair enough.
596 2012-05-07 15:43:11 <Graet> :)
597 2012-05-07 15:44:15 <gmaxwell> sipa: I've got another stuck block victim, this user at
598 2012-05-07 15:44:21 <gmaxwell> 176947.
599 2012-05-07 15:44:36 <gmaxwell> sipa: have a gitian build of your fix with the break?
600 2012-05-07 15:47:50 <nanotube> and btw, did i mention that i really like the 'blocks remaining' progress bar a lot better than the % bar, in 0.6.1? :)
601 2012-05-07 15:48:52 <DiabloD3> nanotube: they fixed that?
602 2012-05-07 15:48:54 <DiabloD3> I should upgrade
603 2012-05-07 15:49:06 <gmaxwell> DiabloD3: wait until you see the integrated console.
604 2012-05-07 15:49:08 <nanotube> yes, the progress bar doesn't suck now. :)
605 2012-05-07 15:49:23 <nanotube> wait, what's that about integrated console? is that in .1?
606 2012-05-07 15:49:28 <gmaxwell> I'm still sad it doesn't work like quake type ` and an overlay scrolls down over the cliemt.
607 2012-05-07 15:49:32 <TimothyA> I was wondering if it is possible to send bitcoins while offline; as long as one party is online
608 2012-05-07 15:49:43 <gmaxwell> nanotube: it'll be pulled as soon as we cut 0.6.2
609 2012-05-07 15:49:50 <nanotube> ah i c gmaxwell :)
610 2012-05-07 15:50:03 <nanotube> TimothyA: yes you can receive coins if you're not online
611 2012-05-07 15:50:10 <TimothyA> nanotube: *send* :P
612 2012-05-07 15:50:12 <nanotube> you can't send them without connecting to the network though of course :)
613 2012-05-07 15:50:23 <gmaxwell> You can also send while you're offline .. but they don't go anywhere until you're back on!
614 2012-05-07 15:50:24 <nanotube> i mean, you could snail-mail the transaction data to your recipient
615 2012-05-07 15:50:31 <gmaxwell> or that.
616 2012-05-07 15:50:33 <nanotube> heh
617 2012-05-07 15:50:35 <TimothyA> hmm... and there are no other ways to faciliate that for in-person transactions?
618 2012-05-07 15:50:57 <gmaxwell> TimothyA: at some point we'll have the ability to make a txn and export it.. then the online node could import it.
619 2012-05-07 15:51:06 <gmaxwell> BIP10 describes a text format for the exports.
620 2012-05-07 15:51:14 <TimothyA> that would be desirable
621 2012-05-07 15:51:26 <TimothyA> just text? not as QR as well?
622 2012-05-07 15:51:29 <gmaxwell> (primary usecase for us is so you can have a wallet which is _never_ connected to the internet)
623 2012-05-07 15:51:52 <gmaxwell> well, it's too much data for a small QR code... but I guess it could fit in the bigger ones.
624 2012-05-07 15:52:43 <TimothyA> should fit on a regular mobile phone's scree
625 2012-05-07 15:52:44 <TimothyA> n
626 2012-05-07 15:52:56 <denisx> I used bisect to hunt down the 100% cpu hogging
627 2012-05-07 15:53:00 <denisx> here is what I found: http://pastebin.com/xAEYuyRW
628 2012-05-07 15:53:33 <sipa> denisx: ow...
629 2012-05-07 15:54:22 <gmaxwell> denisx: it would still be very good to know what line it was spending time at.
630 2012-05-07 15:55:22 <sipa> gmaxwell: not yet, i was experimenting with it a bit first
631 2012-05-07 15:57:03 <gmaxwell> sipa: when you've got something you're happy with point me at builds and I will pass them on to the victims I've collected for you.
632 2012-05-07 15:58:17 <gmaxwell> This latest victim is on win XP, always on node, stuck at 176947 with 0.6.1 now, was on 0.6.0 previously and it's been stuck there for 13 days.
633 2012-05-07 16:16:54 <gavinandresen> Right:  damn the torpedoes, full steam ahead, the Bitcoin Testing Project is looking for members:  https://bitcointalk.org/index.php?topic=80019.0
634 2012-05-07 16:47:21 <jgarzik> very strange
635 2012-05-07 16:57:52 <gribble> New news from bitcoinrss: luke-jr opened issue 1218 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1218>
636 2012-05-07 17:01:50 <anonyminer> Hi
637 2012-05-07 17:01:57 <anonyminer> I need help urgently
638 2012-05-07 17:02:28 <anonyminer> Bitcoin isn't working since new update
639 2012-05-07 17:02:50 <gmaxwell> anonyminer: Define not working?
640 2012-05-07 17:03:05 <anonyminer> Ok I have the error one sec
641 2012-05-07 17:03:23 <gavinandresen> (I predict DB_RUNRECOVERY....)
642 2012-05-07 17:03:25 <anonyminer> Runaway Exception
643 2012-05-07 17:03:48 <anonyminer> A Fatal Error Occured
644 2012-05-07 17:04:11 <anonyminer> EXCEPTION: 11DbException
645 2012-05-07 17:04:33 <anonyminer> Db::get: Not enought space
646 2012-05-07 17:04:54 <luke-jr> anonyminer: sounds like you're out of disk space
647 2012-05-07 17:05:04 <anonyminer> nah I have 90 GB Free
648 2012-05-07 17:05:06 <anonyminer> :P
649 2012-05-07 17:05:27 <gmaxwell> I think I've seen corrupt addr.dat cause that.
650 2012-05-07 17:06:09 <anonyminer> does this mean I lost all my coins :(
651 2012-05-07 17:06:36 <gmaxwell> anonyminer: No. Thats quite unlikely.
652 2012-05-07 17:06:53 <gmaxwell> First, make a new backup of your appdata directory.
653 2012-05-07 17:07:10 <anonyminer> Ok :)
654 2012-05-07 17:09:45 <gmaxwell> After than try deleting the addr.dat file and restarting.
655 2012-05-07 17:10:34 <anonyminer> blkindex.dat failed to load at first so I backed it up and Bitcoin loaded after that than it started to download the blkindex.dat again and I don't know why it won't open now,,, says Unconfirmed Bitcoins
656 2012-05-07 17:10:35 <gribble> Error: "," is not a valid command.
657 2012-05-07 17:11:23 <anonyminer> same error as before after deleting addr.dat
658 2012-05-07 17:11:25 <anonyminer> :(
659 2012-05-07 17:12:02 <gmaxwell> okay, so this time shut down and delete addr.dat blk001.dat and blkindex.dat.
660 2012-05-07 17:12:24 <gmaxwell> Then restart.
661 2012-05-07 17:13:27 <anonyminer> Ok its working now but this has already done this once than it says error blocks may be incorrect in the bottom why is this happening?
662 2012-05-07 17:15:08 <gmaxwell> anonyminer: thats okay, it's just resyncing up with the network now. Is the block count progressin the lower right corner going up?
663 2012-05-07 17:17:32 <anonyminer> yes
664 2012-05-07 17:18:06 <anonyminer> But this already did this once and it wasn't showing my coins as confirmed :(
665 2012-05-07 17:18:28 <gmaxwell> anonyminer: okay, it will take a little while to catch back up again assuming you left your wallet.dat along you'll be perfectly fine when it craches back up (and it will then show your coins as confirmed)
666 2012-05-07 17:28:21 <gribble> New news from bitcoinrss: luke-jr opened pull request 1219 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1219>
667 2012-05-07 18:04:13 <gribble> New news from bitcoinrss: laanwj opened pull request 1220 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1220>
668 2012-05-07 18:09:34 <t7> its still 'new news'
669 2012-05-07 18:10:18 <sipa> yes?
670 2012-05-07 18:16:11 <gmaxwell> sipa: got a trial binary yet?
671 2012-05-07 18:18:12 <sipa> uploading!
672 2012-05-07 18:18:50 <sipa> i added the creation of a "COMMITS" file to my build script
673 2012-05-07 18:19:32 <gmaxwell> might be interesting to run diff `last tag`.
674 2012-05-07 18:21:20 <sipa> http://bitcoin.sipa.be/builds/0.6.1-35-g1ec1702/
675 2012-05-07 18:36:48 <anonyminer> Seems like its frozen :(
676 2012-05-07 18:37:05 <anonyminer> been sitting on block 73.30% Complete and its just sitting there
677 2012-05-07 18:37:28 <anonyminer> 49617 Blocks Remaining :(
678 2012-05-07 18:37:40 <sipa> for how long has it been stuck?
679 2012-05-07 18:41:48 <anonyminer> 1 Hour :(
680 2012-05-07 18:42:03 <sipa> ;;bc,tslb
681 2012-05-07 18:42:04 <gribble> Time since last block: 4 minutes and 41 seconds
682 2012-05-07 18:42:10 <sipa> 0.6.1?
683 2012-05-07 18:42:14 <anonyminer> yes'
684 2012-05-07 18:42:51 <luke-jr> sipa: he said it just *started* being a problem with 0.6.1
685 2012-05-07 18:42:51 <sipa> wait till a few more blocks have been generated; if it's still stuck: you may have hit a bug we're currently trying to fix
686 2012-05-07 18:43:44 <gmaxwell> luke-jr: nah, his chain got corrupted during the upgrade. (my guess due to a unclean shutdown before the upgrade) his problems are on resync.
687 2012-05-07 18:44:36 <anonyminer> Yes
688 2012-05-07 18:45:14 <gmaxwell> ;bc,tslb
689 2012-05-07 18:45:18 <gmaxwell> ;;bc,tslb
690 2012-05-07 18:45:19 <anonyminer> I Closed it a now it won't open says blkindex.dat could not open
691 2012-05-07 18:45:19 <gribble> Time since last block: 7 minutes and 57 seconds
692 2012-05-07 18:46:40 <luke-jr> gmaxwell: see :p
693 2012-05-07 18:47:51 <anonyminer> Error Loading blkindex.dat now Ok I deleted the blkindex.dat I am going to try for the third time to resync
694 2012-05-07 18:48:38 <luke-jr> I'm starting to see why Windows tries to hide the filesystem from users.
695 2012-05-07 18:49:37 <gmaxwell> anonyminer: I hope you were deleting blk0001.dat at the same time.
696 2012-05-07 18:49:45 <jgarzik> luke-jr: if nothing else, android/iphone apps have proven the value of a very tightly controlled sandbox for each app
697 2012-05-07 18:49:46 <gmaxwell> but this doesn't sounds like a productive path.
698 2012-05-07 18:52:58 <anonyminer> I did already the first time
699 2012-05-07 18:53:08 <anonyminer> do I have to keep deleting it
700 2012-05-07 18:54:45 <sipa> anonyminer: always delete blkindex.dat and blk0001.dat together
701 2012-05-07 18:55:57 <sipa> (the first is an index into the second)
702 2012-05-07 18:58:20 <jgarzik> really, "delete everything but wallet.dat" is surely the most simple, foolproof instruction
703 2012-05-07 18:58:57 <luke-jr> "everything but" isn't foolproof ;)
704 2012-05-07 18:59:06 <gmaxwell> jgarzik: and when wallet.dat is then unreadable because they deleted database/ and their last shutdown was unclean?
705 2012-05-07 18:59:57 <sipa> if you delete blkindex.dat and blk0001.dat, but don't delete database/, there is a risk that they get recreated from the log files anyway, and then cause failure
706 2012-05-07 19:00:23 <sipa> that may have been the problem here
707 2012-05-07 19:00:47 <gmaxwell> :-/
708 2012-05-07 19:00:52 <gmaxwell> Damned either way here.
709 2012-05-07 19:01:30 <gmaxwell> I've certantly seen wallets become totally unreadable from deleting database/  and in the same case that would happen, except wallet is clean more of the time.
710 2012-05-07 19:02:31 <anonyminer> can't I just create a brand new bitcoin folder and import my wallet to the bitcoin wallet?
711 2012-05-07 19:02:55 <sipa> yes, you can
712 2012-05-07 19:03:07 <sipa> assuming the client shut down cleanly
713 2012-05-07 19:03:34 <sipa> (that's exactly identical to "remove everything except wallet.dat", by the way)
714 2012-05-07 19:03:46 <luke-jr> anonyminer: just don't delete the old directory under any circumstances
715 2012-05-07 19:03:50 <luke-jr> anonyminer: rename it
716 2012-05-07 19:04:42 <gmaxwell> luke-jr: hopefully he made a backup at the start where I asked.
717 2012-05-07 19:07:07 <jgarzik> gmaxwell: http://pybsddb.sourceforge.net/utility/db_recover.html
718 2012-05-07 19:08:15 <jgarzik> gmaxwell: or 'db_dump -r'
719 2012-05-07 19:08:47 <gmaxwell> jgarzik: indeed. that works.
720 2012-05-07 19:11:43 <anonyminer> WARNING: Displayed Transaction may be Incorrect :(
721 2012-05-07 19:11:57 <anonyminer> 71.56% Done
722 2012-05-07 19:12:52 <anonyminer> Yes I did Make a Back like you asked bro :)
723 2012-05-07 19:14:59 <anonyminer> I should of stayed at version 6.0 this is a Bug it has to be :(
724 2012-05-07 19:15:11 <anonyminer> Its not working ever since I upgraded to 6.1
725 2012-05-07 19:19:32 <gmaxwell> anonyminer: it sounds like its working fine now.
726 2012-05-07 19:36:05 <luke-jr> thinking about refactoring the priority code to include dependents and fees; how does this algo sound: priority = (inputs * ((confirms * confirmWeight) + (fee * feeWeight))) / size
727 2012-05-07 19:36:48 <luke-jr> (in the case of dependents, the child-fees get added to the parent, and size includes them, whichever combination gives it the highest prio)
728 2012-05-07 19:45:43 <gmaxwell> whats the weight stuff?
729 2012-05-07 19:52:44 <luke-jr> gmaxwell: user configurable
730 2012-05-07 20:57:10 <splatster> Bitcoin-qt is using 30% CPU on a simple chain catchup.
731 2012-05-07 20:58:41 <sipa> it should be 100%
732 2012-05-07 20:58:48 <sipa> ideally
733 2012-05-07 20:59:00 <sipa> if it's not, it means that network or disk are the bottleneck
734 2012-05-07 20:59:12 <splatster> Hmm, prolly my network.
735 2012-05-07 20:59:23 <sipa> unlikely :)
736 2012-05-07 20:59:37 <splatster> It keeps spiking up to 70s and 80s then back down to 30s.
737 2012-05-07 21:00:06 <splatster> sipa: I'm on a crappy connection, something like 200 KB/s or maybe less.
738 2012-05-07 21:00:26 <sipa> ok
739 2012-05-07 21:00:26 <splatster> And I'm on an SSD/HDD hybrid.
740 2012-05-07 21:12:18 <anonyminer> I need help with my Bitcoin Clien still not working it freezes when it is trying to catch up...
741 2012-05-07 21:13:49 <sipa> how many blocks do you have alreadt?
742 2012-05-07 22:40:39 <BlueMatt> wumpus: you dont happen to have ever seen this: http://pastebin.com/KfUH9AxA ?