1 2011-11-10 00:25:55 <denisx> gna, jansson 2.x is also not API compatible to 1.x
  2 2011-11-10 01:16:59 <denisx> so, I added a little zerocopy to pushpoold
  3 2011-11-10 01:17:34 <gmaxwell> denisx: did you make it use the async apis for the databases or is the whole thing still blocking on database writes? :)
  4 2011-11-10 01:18:04 <gmaxwell> At least when I ran oprofile on it a long time ago thats where it was spending basically all of its time.
  5 2011-11-10 01:18:24 <denisx> gmaxwell: what database do you use?
  6 2011-11-10 01:19:22 <gmaxwell> I was testing against mysql, but it was using the blocking api for both postgres and mysql before and I assume it still is.
  7 2011-11-10 01:21:35 <denisx> I rarely see my db with any load at all
  8 2011-11-10 01:21:39 <denisx> sometimes 0.5%
  9 2011-11-10 01:23:04 <phantomcircuit> gmaxwell, what exactly does pushpoold do
 10 2011-11-10 01:23:09 <phantomcircuit> i never bothered to investigate
 11 2011-11-10 01:23:20 <phantomcircuit> it keeps track of who sends what shares right?
 12 2011-11-10 01:23:32 <denisx> yes
 13 2011-11-10 01:24:00 <gmaxwell> Right. and it's doing blocking requests to the db so if the db is busy at all, pushpool blocks on it and doesn't respond to connections.
 14 2011-11-10 01:24:09 <denisx> client asks pushpoold for work, pushpool gets work from bitcoind
 15 2011-11-10 01:24:17 <gmaxwell> So you do some select to figure out what users are owed what, .. and you're getting timeouts.
 16 2011-11-10 01:24:35 <phantomcircuit> gmaxwell, that is
 17 2011-11-10 01:24:37 <phantomcircuit> hilarious
 18 2011-11-10 01:24:41 <phantomcircuit> i tried to compile it
 19 2011-11-10 01:24:43 <denisx> client reports 'success' on a hash, pushpoold verifies that with bitcoind and adds that to the client account in the db
 20 2011-11-10 01:24:48 <phantomcircuit> and just decided i didn't care
 21 2011-11-10 01:24:56 <phantomcircuit> like a couple months ago ro something
 22 2011-11-10 01:25:44 <CFSworks> denisx, wait, what? pushpoold verifies share hashes using bitcoind's RPC? :S
 23 2011-11-10 01:26:05 <gmaxwell> CFSworks: it does a basic sanity check first internally, IIRC.
 24 2011-11-10 01:26:19 <denisx> yes, some checks first
 25 2011-11-10 01:26:33 <phantomcircuit> there is absolutely no reason to check with bitcoind
 26 2011-11-10 01:27:00 <phantomcircuit> you just verify that the block header is correct and that it matches a version you gave out previously to be worked on
 27 2011-11-10 01:27:03 <denisx> ah, I mean for real blocks it checks bitcoind!
 28 2011-11-10 01:27:08 <phantomcircuit> within x seconds
 29 2011-11-10 01:27:16 <gmaxwell> phantomcircuit: what happens with I start giving you ntimes that are from the future which the network wouldn't accept?
 30 2011-11-10 01:27:58 <phantomcircuit> restrict times to +- 5 minutes from a true time clock
 31 2011-11-10 01:28:13 <gmaxwell> All the modern miners implement ntime rolling (presumably so they don't sit idle while pushpool is blocked on the database or bitcoind...)
 32 2011-11-10 01:28:25 <phantomcircuit> ironic
 33 2011-11-10 01:28:58 <CFSworks> gmaxwell: Yeah... About that... >_>
 34 2011-11-10 05:36:26 <Lolcust> Hello respected btc-dev channel residents! Recent(ish) discussion of  fee regime  brought me to drink... I mean, to think ~__^, about possible system for tweaking of fee regime by dev (so, this writeup  does not imply "liberalizing" mandatory fee system) that would not involve updating the software just to change mandatory  fee from X to Y... This is a quickie writeup I came up with:
 35 2011-11-10 05:36:53 <Lolcust> http://pastie.org/private/1n0gtwzuynkcbnsb2g27ma
 36 2011-11-10 05:37:32 <Lolcust> Let the ... civilized discussion and constructive criticism commence :)
 37 2011-11-10 05:38:23 <theymos> It's bad for things to be centralized like that. One simple feature would fix everything: allow transactions to be canceled. Then there's no need for a mandatory fee at all.
 38 2011-11-10 05:39:20 <justmoon> canceled by who? the sender?
 39 2011-11-10 05:39:59 <justmoon> Lolcust: how do the developers know the "correct" fee to set?
 40 2011-11-10 05:40:55 <theymos> Right. If the sender could cancel stuck payments, people would learn to sent transactions with proper fees. Maybe later some advanced proper-fee-detection features could be created.
 41 2011-11-10 05:41:02 <gmaxwell> 'simple'
 42 2011-11-10 05:41:07 <Lolcust> theymos well, I explicitly said that it does not attempt to decentralize mandatory fee management. Also, pardon my dimness, but how would transaction cancelation prevent spam issues that arise if mandatory fee is too low and some of the miners are willing to "let the spammer vampires in"
 43 2011-11-10 05:41:45 <theymos> OK, it's not that simple. But it's simpler than trying to keep a correct mandatory fee.
 44 2011-11-10 05:41:56 <Lolcust> justmoon exactly same way developers know the correct minimum mandatory fee now, when hardcoding it ^__~
 45 2011-11-10 05:42:39 <justmoon> Lolcust, right now only a default fee setting is hardcoded, and from I understand most people want to get rid of that in favor of a more dynamic solution
 46 2011-11-10 05:42:41 <theymos> It's not a problem if miners accept bad transactions. Malicious miners can right now fill blocks with garbage.
 47 2011-11-10 05:42:54 <Lolcust> theymos - current system (minimum mandatory fees are "guessed / estimated" by dev team and hardcoded) works
 48 2011-11-10 05:43:05 <Lolcust> Thus I see no reaon to liberalize it
 49 2011-11-10 05:43:23 <justmoon> Lolcust, developers deciding the fee essentially is a form of central planning - it requires the central planners to have knowledge that only exists in the minds of the users and miners
 50 2011-11-10 05:44:16 <justmoon> things like, how much are you willing to spend for the security you get from an extra TH/s in hashing power?
 51 2011-11-10 05:44:25 <gmaxwell> theymos: okay, we probably agree there... though the built in fee pain is pretty long term. E.g. we have no need to change it now and probably won't the rest of the year.
 52 2011-11-10 05:44:54 <Lolcust> justmoon central plannig sort of works in smaller economic systems (corporations and privately held companies are often like that ) and like I said, I am a centrist and I don't mind a touch of interventionism here and there
 53 2011-11-10 05:45:16 <justmoon> Lolcust, precisely, it works right, because Bitcoin is small
 54 2011-11-10 05:45:20 <justmoon> right now*
 55 2011-11-10 05:45:27 <gmaxwell> justmoon: the developers aren't deciding fees in any case. they're deciding a _minimum_ fee for realying, and it is no different from deciding the coefficients used in other anti-DOS behavior.
 56 2011-11-10 05:45:34 <justmoon> gmaxwell, that's what I said
 57 2011-11-10 05:45:41 <gmaxwell> (today and for the next several years)
 58 2011-11-10 05:46:08 <Lolcust> gmaxwell my proposal only deals with Mandatory MINIMUM fee as well
 59 2011-11-10 05:46:34 <metaperl> The `gen` option isnt copiously described here - https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File   ... does that mean that the daemon started up will attempt to mine for coins?
 60 2011-11-10 05:46:46 <gmaxwell> Lolcust: oh, just saw it.
 61 2011-11-10 05:47:25 <gmaxwell> Lolcust: if it has to be updated frequently then we've done something horribly wrong and it's no longer just a basic anti-ddos rate limiting thing. As evidence you're not suggesting using the same method for updating all the other DDOS limits.
 62 2011-11-10 05:47:33 <Lolcust> justmoon , I strongly doubt that BTC will ever reach the scales at which "antispam" minimum fee being decided by the dev team can cause scaling issues. And if that happens, nothing prevents "deregulating" it then (and likely dying by spam)
 63 2011-11-10 05:48:03 <Lolcust> gmaxwell I did leave a provision for using it for updating "other parameters:
 64 2011-11-10 05:48:52 <Lolcust> It's just that updating software just to pop fee up/down (with the "right fee" being essentially a function of coin price at exchange) seems....clumsy
 65 2011-11-10 05:49:20 <theymos> The network is already not homogeneous, and when more miners break from the recommended fee values (especially miners who demand higher fees), there will be problems. I think it will probably need to be solved in sooner than a year.
 66 2011-11-10 05:49:55 <gmaxwell> It shouldn't be much of a function of the coin price at an exchange though.. because it should be so low that it should be able to move an order of magnitude in either direction without substantially burdening users or losing its effectiveness for anti-dos.
 67 2011-11-10 05:50:33 <justmoon> Lolcust, personally I think there are ways that don't require a steering committee. but let's assume bitcoin goes with your proposal, wouldn't that mean its rules are now made by the developers? how would it differ from other currencies/settlement systems like Euro/SEPA?
 68 2011-11-10 05:50:34 <Lolcust> gmaxwell , but the antispam effect stems, essentially, from attacker not being able to spam while paying the fee
 69 2011-11-10 05:51:11 <gmaxwell> Lolcust: yes but it still works pretty well even if its quite small.
 70 2011-11-10 05:51:39 <Lolcust> if coin price is high, even a tiny fee will stop the spammer, but if it is low, he can buy a fistful for cheap and spam on
 71 2011-11-10 05:51:53 <Lolcust> current price is, in typical human terms, rather high
 72 2011-11-10 05:52:15 <gmaxwell> Lolcust: you can cut the fee by a factor of 100 and they can only send 100x more spam... vs if there is no fee, I can while true; do bitcoind sendtoaddress `bitcoind getnewaddress` ; done  and send 1000000000000x spam.
 73 2011-11-10 05:53:05 <gmaxwell> Lolcust: it's a fraction of a penny which is applied to a sub minority of transactions. How is that high in human terms? with USD you use lose more than our txn fee from rounding on prices. :)
 74 2011-11-10 05:55:07 <Lolcust> gmaxwell what I meant in "high in human terms" is that "Oh I will spam and loose 100 BTC on sheer fees" would mean me loosing 300USD on fees, which is quite...discouraging. At a lower price, loosing 100, or even 1000 BTC on just being a dick to the network might not sound that gravely loosing a proposition
 75 2011-11-10 05:55:20 <Lolcust> especially for "do it for the lulz" attacker
 76 2011-11-10 05:57:03 <Lolcust> justmoon rules are already - and always - made by the developers. Min. tx fee   specifically are being hardcoded right now. Since I am not economically fundamentallist, I don't mind that (even if it makes it slightly like euro ;-) ) and plenty of difference remains (decentralized transaction processing and emission, pseudonymity, easy transaction over TCP/IP, etc.)
 77 2011-11-10 05:57:38 <theymos> It would be not terribly expensive to raise network-wide fees for a while, which is another reason I'd like to see the ability to cancel stuck transactions.
 78 2011-11-10 05:57:53 <gmaxwell> Lolcust: if 1x your attack would not be problematic than making it 10x larger should also not be substantially problematic. Which is my core point. The anti-dos goal here is mostly to slow premature chain bloat, otherwise priority order is fine. .. The anti-anti-dos goal is more complicated because for that the minimum needs to be high enough to get txn processed in a timely fashion.
 79 2011-11-10 05:58:43 <theymos> Lolcust: Miners won't follow rules that they don't like. Eligius already has very different fee rules than the default client.
 80 2011-11-10 05:59:14 <gmaxwell> theymos: correction: the evidence suggests that most miners simply won't update their software. Actual preferences don't seem to matter much.
 81 2011-11-10 05:59:31 <Lolcust> theymos that requires them to dislike the rules strongly enough to make a mod out of it. also, what gmaxwell said
 82 2011-11-10 05:59:49 <gmaxwell> Luke is about the only person with more than a few hundred MH under his belt who actually expresses preferences in public, and we all know he's crazy. :)
 83 2011-11-10 06:00:50 <Lolcust> gmaxwell, I do realize that it is probably a petty concern and unless btc crashes to 0.009 USD (or lower) current fee is more than enough to keep any significant chain bloat / tx dos attack at bay.
 84 2011-11-10 06:01:14 <gmaxwell> okay, given that condition I agree with you, but if that were to happen I don't care that much
 85 2011-11-10 06:01:34 <justmoon> Lolcust, is your proposal meant only for current fee concerns or would you use the same system once coin generation stops?
 86 2011-11-10 06:01:38 <gmaxwell> if btc gets down to that either everyone will have given up for some bigger reason, or it will take a long time to get there, in which case we'd adapt.
 87 2011-11-10 06:02:12 <gmaxwell> justmoon: don't assume generation stops. I mean it technically does right now, but that actual stopping point isn't important.
 88 2011-11-10 06:02:27 <Lolcust> gmaxwell  point was more or less "if one is managing minimum fees centrally (which is status quo) one can at least manage it more elegantly than via whole full-blown software update"
 89 2011-11-10 06:02:28 <gmaxwell> The maximum amount of coins doesn't arise because generation stops.
 90 2011-11-10 06:02:49 <gmaxwell> Lolcust: the inelegance is one of the reasons the central control is acceptable.
 91 2011-11-10 06:03:01 <Lolcust> justmoon well, that actually depends on how price will behave when second subsidy cut hits
 92 2011-11-10 06:03:05 <phantomcircuit> gmaxwell, personally i would like to see the tx relay rules changed
 93 2011-11-10 06:03:19 <Lolcust> I expect the second to be far far more...bizzare than the first
 94 2011-11-10 06:03:33 <gmaxwell> there were a couple fruitcakes a while back arguing that the developers were making it rich off the omg fees. (always great to see one show up with stuck transactions in their modified client a few weeks later)
 95 2011-11-10 06:04:07 <Lolcust> gmaxwell so what ?  You can't satisfy all the mad men on internets
 96 2011-11-10 06:04:08 <gmaxwell> but it was lots easier to dismiss them because the client imposed fees are such a suckass form of central control. :)
 97 2011-11-10 06:04:49 <gmaxwell> Lolcust: as described your system creates a serious centralized vulnerablity.
 98 2011-11-10 06:05:08 <Lolcust> Well, if you don't like mandatory fees you can cut the "version-message updatable mandatory fee" just the same way you would cut out current one (but you'd need a miner to play along)
 99 2011-11-10 06:05:16 <gmaxwell> I get the developer key, send ninjas to kill everyone else with it.. send out a fee update of 10000000 btc .. then bitcoin stops working for most users.
100 2011-11-10 06:05:31 <gmaxwell> yes, but the system is broken until you go and do that.
101 2011-11-10 06:06:03 <gmaxwell> and during that time I also circulate 'fixed' clients.. which contain a backdoor, and I snare lots of suckers.
102 2011-11-10 06:06:16 <Lolcust> I don't think it's any more broken than now. Now, if devs deem fee of X better and some people just don't update, you get worst of both worlds
103 2011-11-10 06:06:58 <Lolcust> Central-ish control is still there, but objectives it tried to achieve with raising / lowering antispam fee are not achieved because people are too lazy to update
104 2011-11-10 06:07:03 <gmaxwell> no, thats not at all the worst of both worlds.
105 2011-11-10 06:07:14 <Lolcust> So you get a "soup"
106 2011-11-10 06:07:21 <gmaxwell> There is no way to achieve that "one guy broke bitcoin today" with the current situation.
107 2011-11-10 06:07:50 <gmaxwell> At _worst_ you can get "people who installed new clients today were unhappy and downgraded" or "stop! the new client breaks the network! don't upgrade!"
108 2011-11-10 06:08:04 <gmaxwell> This is also why bitcoin should _never_ have a simplistic autoupdater.
109 2011-11-10 06:08:43 <gmaxwell> (the system the tor folks proposed with time delays and vetos might be tolerable, but if then only if its opt-in)
110 2011-11-10 06:08:45 <rphlx> you can do an incremental rollout with an autoupdater
111 2011-11-10 06:09:47 <Lolcust> gmaxwell well, given human update behavior (and sustained prevalence of oldtimer clients), I'd say that "old cruft" accumulation is far more likely to cause pains than "guy broke it" scenario
112 2011-11-10 06:09:49 <theymos> Yeah, I would be absolutely opposed to an autoupdator.
113 2011-11-10 06:09:56 <gmaxwell> Some folks related to the tor project proposed a system where updates are queued for a while after they are published, and any of the keys that can sign the release can also veto them to prevent their autoinstall)
114 2011-11-10 06:10:32 <theymos> I still don't like it. Too centralized. Tor itself is centralized, though, so it doesn't matter as much for them.
115 2011-11-10 06:10:40 <gmaxwell> Lolcust: it's not about likely. It's about the available failure modes. Central control abused to break things becomes an attractive attack vector when it's available.
116 2011-11-10 06:11:31 <Lolcust> gmaxwell then developer key used for binary signing is as attractive as the key that would be used to sign "fee updates" in my proposal
117 2011-11-10 06:11:47 <Lolcust> and given that majority of userbase uses binaries, just as destructive
118 2011-11-10 06:11:49 <gmaxwell> E.g. right now, even if you're willing to kill people there is basically no way for you to just go shut bitcoin off. With what you're proposing, it's simple: get in a plane, fly to wherever gavin (or theymos is), put a gun to their head and tell them to set the fee to 21m bitcoin.
119 2011-11-10 06:12:03 <gmaxwell> Lolcust: no, because there is no autoupdate.
120 2011-11-10 06:12:14 <gmaxwell> Also, 99.9999% of people don't check the signatures.
121 2011-11-10 06:12:42 <gmaxwell> Also, gavin's key is not connected to the pgp strongset, so it's unlikely that people who check signatures can actually verify the validity of _his_ signature.
122 2011-11-10 06:12:43 <theymos> And the weight of any signatures would be nullified if like 20 other trusted people signed that they were compromised.
123 2011-11-10 06:13:05 <gmaxwell> theymos: yea, right, thats the point of the queue-and-veto approach.
124 2011-11-10 06:13:48 <Lolcust> well, it becomes notably harder to tell the "poisoned" binaries from real thing if the signatures are okay, and other complexity (now we have to withdraw signatures) would start piling up.
125 2011-11-10 06:14:22 <gmaxwell> yes, but since no one checks it doesn't matter. :) And again, poisoned binaries are still only a slowly spreading problem.
126 2011-11-10 06:14:41 <Lolcust> Methinks that if you already have to manage the anti-spam fee centrally (for now at least), then you can at least be efficient about it ;-)
127 2011-11-10 06:14:42 <gmaxwell> (though something that we should be strengthened against)
128 2011-11-10 06:15:14 <gmaxwell> Lolcust: in any case, I recommend you table your idea until its time to change the fee again. Right now its a solution looking for a problem. The next time the fee needs to be changed people might find the idea more attractive.
129 2011-11-10 06:15:55 <gmaxwell> regardless of what the minfee stuff does, we still do need a way to cancel transactions as theymos says. So if we get that the design of the minfee thing might change.
130 2011-11-10 06:17:02 <Lolcust> gmaxwell I was primarily looking for people to comment if it has grievous omissions of the technological kind (can't be done because *programmer issue No 22 ;-) ) not ideological kind (centralization is evil) (that's why I outright admited the central management thing in the begining)
131 2011-11-10 06:17:42 <gmaxwell> well he boom-network-dead is a security flaw which could be improved by technical means.
132 2011-11-10 06:19:15 <gmaxwell> (e.g. using quorum and veto, requring the update to get mined (a check and balance), or using a hashpower decision instead of developer signatures)
133 2011-11-10 06:19:50 <Lolcust> Maybe an upper limit on fee being hardcoded (no point in setting minimum fee above 1 coin, even when BTC was pennyworth, smaller fees worked fine)
134 2011-11-10 06:20:34 <Lolcust> Hm, classic "51 hashpower" would be kind of neat as fee-update "canonizations" vector
135 2011-11-10 06:21:53 <Lolcust> Though methinks that having it mined, multi-signed and having a sane-ish hardcoded upper limit (we know for a fact that a fee well below 0.5 works even when price is dirt low) would be enough
136 2011-11-10 06:22:34 <Lolcust> veto seems rather pointless in a system with very fast update propagation (which is what is proposed)
137 2011-11-10 06:22:46 <Lolcust> anyway, as re: transaction cancelation
138 2011-11-10 06:22:48 <Lolcust> Canceling transactions by the sender before they get "mined", I assume ?
139 2011-11-10 06:23:24 <Lolcust> Can't we already do that with pywallet, more or less ?
140 2011-11-10 06:29:46 <justmoon> Lolcust, you can cancel it being rebroadcasted, but it can still be included by a miner who already has it
141 2011-11-10 06:30:28 <Lolcust> well, you wait reasonabl-ish time and -rescan. if it does not pop up, then it is successfully canceled ^__~
142 2011-11-10 06:30:38 <justmoon> yes, if you wanted to resend it with a higher fee, you'd need to wait a bit for some of the network to forget about it
143 2011-11-10 06:30:57 <Lolcust> I find the idea of a saner cancelation process...interesting
144 2011-11-10 06:31:19 <Lolcust> Anywhere I can familiarize myself with relevant discussion ?
145 2011-11-10 06:31:21 <justmoon> the cancel message itself could be a DoS vector though - that's why there is none I believe
146 2011-11-10 06:31:55 <justmoon> or you could send a transaction with a reasonable, cancel it, send it again etc.
147 2011-11-10 06:32:01 <justmoon> reasonable fee*
148 2011-11-10 06:34:10 <theymos> When cancelling, Bitcoin should always send a conflicting transaction so no miner includes the old version and surprises you.
149 2011-11-10 06:37:30 <Lolcust> theymos couldn't I trivially spam the network with send/cancel cycles ? Also, what would happen if a cancel message arrives "too late" ?
150 2011-11-10 06:39:19 <theymos> You can only send cancellations after the network has forgotten about your old transaction or your new transaction will be rejected by everyone.
151 2011-11-10 06:40:42 <CFSworks> (Unless the node doing the cancellation happens to have enough hashing power behind it that it finds the next block.)
152 2011-11-10 06:47:37 <gmaxwell> theymos: what it should do is show a cancel pending... and keep showing it until the conflicting txn makes it through.
153 2011-11-10 06:48:39 <CFSworks> gmaxwell, "cancellation attempt pending" :)
154 2011-11-10 06:50:16 <theymos> gmaxwell: Yes. A special "increase fee" feature would also be nice to immediately replace the old transaction with one with increased fees.
155 2011-11-10 06:56:26 <Lolcust> theymos well, there was also that patch which allowed to "precook" transactions so that you can check what fees will be like... But I suspect it caused trouble (otherwise, why isn't it in main ;-) )...
156 2011-11-10 06:57:20 <gmaxwell> Lolcust: fees aren't determinstic.
157 2011-11-10 06:57:43 <gmaxwell> just getting a new input or an additional block landing on the chain will totally invalidate the results.
158 2011-11-10 06:57:58 <Lolcust> I am aware of that
159 2011-11-10 06:58:09 <gmaxwell> And sometimes they'll make the fees go _up_ because the selection doesn't minimize fees.
160 2011-11-10 07:01:19 <Lolcust> well, that I know, still, being able to tell what fee will be for sending 200 BTC given current state of your wallet, and then either agreeing or declining, would be neat. https://github.com/TheBlueMatt/bitcoin/commit/5350a907a57b88bd86827c1f3e41b571cf130401 <- this was what I meant
161 2011-11-10 07:02:16 <doublec> I'd like a way to send specifying the max fee I want to fail and if it fails it returns the fee it wanted. Then it can be repeated with the new max if needed.
162 2011-11-10 07:03:02 <doublec> or something like that -to make it easier for a merchant to pass the fee on
163 2011-11-10 07:03:09 <gmaxwell> doublec: that seems like a pretty simple request.
164 2011-11-10 07:03:32 <Lolcust> Oh, and gmaxwell , not to beat an old hypothetical horse, but it didn't cross my mind right away... being able to centrally set the minimum "antispam" fee size to "stupid_value" would not totally destroy the network, just significantly inconvenience it (I, for one, do my best to ensure that I always get away with fee of 0. Because I am greedy like that ^__^ _
165 2011-11-10 07:03:44 <doublec> I should probably write it myself and submit the patch :)
166 2011-11-10 07:07:16 <gmaxwell> Lolcust: part of any sane update would also need to say when they get required, not just the value.
167 2011-11-10 07:11:53 <phantomcircuit> so i find myself reading the bitcoin buildmerkleroot function
168 2011-11-10 07:12:16 <phantomcircuit> and i can honestly say i have no idea how it's handling transaction lists of odd length
169 2011-11-10 07:13:08 <phantomcircuit> it's actually buildmerkletree btw
170 2011-11-10 07:13:43 <theymos> The last one is hashed twice.
171 2011-11-10 07:14:11 <phantomcircuit> im not so sure
172 2011-11-10 07:14:19 <phantomcircuit> it might promote them
173 2011-11-10 07:14:41 <phantomcircuit> if you have one transaction the transaction hash is the merkle root
174 2011-11-10 07:14:52 <phantomcircuit> which is actually wrong behaviour but whatever
175 2011-11-10 07:15:35 <justmoon> maybe this code is a bit clearer? https://github.com/bitcoinjs/node-bitcoin-p2p/blob/master/lib/schema/block.js#L122
176 2011-11-10 07:16:21 <phantomcircuit> https://privatepaste.com/1de0f73923
177 2011-11-10 07:16:34 <phantomcircuit> the mainline code is impressively obtuse
178 2011-11-10 07:16:59 <phantomcircuit> / This function is a direct translation of CBlock::BuildMerkleTree().
179 2011-11-10 07:17:04 <phantomcircuit> justmoon, not particularly :P
180 2011-11-10 07:17:27 <theymos> I'm pretty sure the last hash is hashed twice except when there's only one hash.
181 2011-11-10 07:18:41 <justmoon> theymos, correct the key line is: int i2 = std::min(i+1, nSize-1);
182 2011-11-10 07:19:14 <justmoon> i.e. for the second hash use the same hash again if there is no last hash (which would be the case for an uneven number of hashes)
183 2011-11-10 07:19:21 <CFSworks> Speaking of hashes... Does anybody know why Bitcoin uses SHA256(SHA256(...))?
184 2011-11-10 07:20:21 <justmoon> CFSworks, I only recall a discussion that it was a bad idea because all it does is reduce the total possible number of hashes
185 2011-11-10 07:21:14 <phantomcircuit> there is a specific class of attacks it prevents
186 2011-11-10 07:21:17 <CFSworks> Potentially. We're not sure if it does.
187 2011-11-10 07:21:24 <phantomcircuit> although it's the least likely class to actually be an issue
188 2011-11-10 07:22:53 <theymos> Satoshi never gave a straight answer about it. Probably he didn't think it through much. It doesn't do much harm, in any case.
189 2011-11-10 07:29:08 <Lolcust> gmaxwell hmmmm.... well, on one hand, updating the minimum fees does not seem that sensitive an issue for abscence of nHeight trick to do much  (the network as of now is already nonhomogenous in terms of min antispam fee policy), on the other hand distributing  (update timestamp + new min antispam value + nHeight at which it has to kick in) does not seem that hard compared to naive version
190 2011-11-10 07:30:15 <iddo> there's length extension attack on sha2, doing sha2(sha2()) prevents it
191 2011-11-10 07:31:08 <phantomcircuit> what iddo said
192 2011-11-10 07:33:14 <iddo> i wonder if the concern was that someone could replace old block in the chain with block that contains more transactions
193 2011-11-10 07:33:21 <iddo> seems far fetched
194 2011-11-10 07:35:13 <phantomcircuit> there is something funny about this algorithm
195 2011-11-10 07:35:17 <phantomcircuit> i think it's wrong actually
196 2011-11-10 07:36:02 <phantomcircuit> ah
197 2011-11-10 07:36:13 <phantomcircuit> it doubles up on the last hash in odd length rows
198 2011-11-10 07:37:35 <phantomcircuit> http://codepad.org/xB3uSSAP
199 2011-11-10 07:37:38 <phantomcircuit> a nice visualization
200 2011-11-10 07:39:14 <theymos> Here's an ASCII tree with the hash doubling: https://en.bitcoin.it/wiki/Dump_format#CBlock
201 2011-11-10 07:40:06 <phantomcircuit> stuffing a tree into an array is a neat trick
202 2011-11-10 07:40:12 <phantomcircuit> but it leads to completely dense code
203 2011-11-10 11:32:12 <nathan7> bc,gen 6000
204 2011-11-10 11:32:26 <nathan7> Well damnit
205 2011-11-10 11:32:32 <nathan7> ;;bc,gen 6000
206 2011-11-10 11:32:33 <gribble> The expected generation output, at 6000 Khps, given current difficulty of 1203461.92638 , is 0.00501467487356 BTC per day and 0.000208944786398 BTC per hour.
207 2011-11-10 12:07:28 <shadders> anyone know how I can dump  blk0001.dat to a text file of hex?
208 2011-11-10 12:10:03 <sipa> it's just a binary concatenation of serialized blocks
209 2011-11-10 12:10:33 <shadders> I know I just want a hex char version of it
210 2011-11-10 12:10:53 <shadders> hexdump adds extra stuff...
211 2011-11-10 12:11:23 <sipa> not if you don't want it
212 2011-11-10 12:11:47 <shadders> man isn't very helpful...
213 2011-11-10 12:12:01 <shadders> man hexdump
214 2011-11-10 12:14:18 <cjdelisle> isn't blk0001 actually a database file?
215 2011-11-10 12:14:45 <sipa> no
216 2011-11-10 12:14:47 <sipa> hexdump -v -e '16/1 "%02X " "\n"' <~/.bitcoin/blk0001.dat
217 2011-11-10 12:14:49 <sipa> try that
218 2011-11-10 12:15:04 <sipa> cjdelisle: blkindex.dat is a database file
219 2011-11-10 12:15:10 <cjdelisle> hmm learn something everyday
220 2011-11-10 12:17:24 <shadders> better... any way to get rid of the spaces and linefeeds?
221 2011-11-10 12:18:51 <sipa> hexdump -v -e '16/1 "%02X"' <~/.bitcoin/blk0001.dat
222 2011-11-10 12:19:36 <shadders> derp... thank sipa :)
223 2011-11-10 12:30:07 <diki> After a hard day of working
224 2011-11-10 12:30:42 <diki> i created a program which will monitor the temps, kill the miner if it gets too hot, wait a bit and check if the temps are normal to start it up again
225 2011-11-10 12:30:49 <diki> It has a few flaws, but it should work nicely
226 2011-11-10 12:31:06 <diki> The reason i am not using cgminer which has this feature is just preference
227 2011-11-10 13:01:53 <Disposition> ThomasV: any luck with that bitcoinandroid app?
228 2011-11-10 13:02:23 <ThomasV> Disposition: I do not have the file you mentioned
229 2011-11-10 13:03:24 <ThomasV> Disposition: what I have is "/sdcard/Android/data/com.bitcoinandroid/files/prodnet.blockchain"
230 2011-11-10 13:03:29 <ThomasV> that's all
231 2011-11-10 13:03:58 <ThomasV> or is the file somewhere else?
232 2011-11-10 13:04:09 <Disposition> there's no folder named .android_secure?
233 2011-11-10 13:04:20 <ThomasV> at which path?
234 2011-11-10 13:04:26 <Disposition> /sdcard/
235 2011-11-10 13:04:41 <ThomasV> no, there's none
236 2011-11-10 13:04:59 <Disposition> weird, did you plugin your phone as a drive on linux with show hidden folders?
237 2011-11-10 13:05:04 <ThomasV> (and I do display hidden folders)
238 2011-11-10 13:05:15 <ThomasV> no, I did not plus it
239 2011-11-10 13:05:19 <ThomasV> *plug*
240 2011-11-10 13:05:41 <Disposition> odd, but file manager should able to see it too
241 2011-11-10 13:05:55 <Disposition> can you plug it in to check? ( i know it sounds stupid)
242 2011-11-10 13:06:27 <Disposition> since a lot of other app uses .android_secure too
243 2011-11-10 13:06:29 <Disposition> like gmail
244 2011-11-10 13:09:00 <ThomasV> I don't think I have a cable...
245 2011-11-10 13:10:24 <ThomasV> Disposition: oh yes I found it
246 2011-11-10 13:12:58 <Disposition> what is it named?
247 2011-11-10 13:13:01 <ThomasV> hmm, it's not mounting it
248 2011-11-10 13:13:05 <Disposition> oh also you gonna need a cable.
249 2011-11-10 13:13:12 <Disposition> ThomasV: yeah the apps is using it lol
250 2011-11-10 13:13:16 <ThomasV> yes I have the cable
251 2011-11-10 13:13:18 <Disposition> cool
252 2011-11-10 13:13:26 <Disposition> you also need the SDK
253 2011-11-10 13:13:29 <Disposition> or at least ADB
254 2011-11-10 13:13:29 <ThomasV> but my laptop does not see it
255 2011-11-10 13:13:44 <Disposition> why can't you just mount the sd card the normal way?
256 2011-11-10 13:13:46 <ThomasV> I tried to use the sdk yesterday (for electrum)
257 2011-11-10 13:14:01 <Disposition> you have an android client in the works? :)
258 2011-11-10 13:14:03 <ThomasV> but it wasnt working well
259 2011-11-10 13:14:31 <Disposition> mmm the only way I know how to pull wallets file out of the phone is through adb though
260 2011-11-10 13:14:36 <ThomasV> no, I have not, but Android apps can be written in python, so it would be straightforward
261 2011-11-10 13:15:25 <Disposition> cool, Yifu and I were looking into writing/updating bitcoin wallet by schildbash but yours is appealing as well, the whole thin client not need to download bkc thing
262 2011-11-10 13:15:37 <Disposition> anyhow you would need to do something like
263 2011-11-10 13:16:21 <Disposition> adb pull /data/data/com.bitcoinandroind-1/files/prodnet.wallet
264 2011-11-10 13:16:33 <Disposition> the com.xxxxx might be different on your phone
265 2011-11-10 13:16:52 <Disposition> and the rest of the path is far as I can tell from reading the source
266 2011-11-10 13:16:54 <Disposition> lmk if it works
267 2011-11-10 13:24:23 <CIA-89> poolserverj: shadders * 89dd7f3d4223 r224 / (5 files in 5 dirs):
268 2011-11-10 13:24:24 <CIA-89> poolserverj: shadders * 871f6b243f9e r225 / (4 files in 3 dirs): make p2p broadcast optional.
269 2011-11-10 13:31:14 <ThomasV> Disposition: I can mount it now
270 2011-11-10 13:31:56 <ThomasV> hmm, no, it sucks
271 2011-11-10 13:32:14 <Disposition> huh?
272 2011-11-10 13:32:26 <ThomasV> it mounts it in .gvfs, and only photos are shown
273 2011-11-10 13:33:19 <ThomasV> it is mounted by gvfs-fuse-daemon
274 2011-11-10 13:33:39 <Disposition> wut? what distro are you on
275 2011-11-10 13:34:05 <Disposition> and why the hell
276 2011-11-10 13:34:05 <ThomasV> ubuntu
277 2011-11-10 13:34:19 <Disposition> can't just do a fdisk -l the mount /dev/sdx /mnt/
278 2011-11-10 13:34:20 <Disposition> ?
279 2011-11-10 13:34:24 <Disposition> then*
280 2011-11-10 13:34:48 <Disposition> i don't recall connecting android units to be such as pia
281 2011-11-10 13:35:28 <ThomasV> what do you want me to do with fdisk?
282 2011-11-10 13:38:31 <ThomasV> I don't get it. I unmounted it (using the icon menu), and it still shows up in /etc/mtab
283 2011-11-10 13:39:08 <ThomasV> oh it's a real pain
284 2011-11-10 13:43:57 <ThomasV> "Samsung uses it???s own software to sync and update the phone called Kies. Kies is only available for Windows (naturally), not Mac or Linux. But you can still use the USB storage and USB tethering, you just have to enable USB debug mode."
285 2011-11-10 13:44:14 <ThomasV> from http://www.craig-russell.co.uk/samsung-galaxy-s2-usb-storage-and-tethering-with-ubuntu/
286 2011-11-10 13:44:20 <ThomasV> seems to be related
287 2011-11-10 13:58:31 <Disposition> yeah
288 2011-11-10 13:58:40 <Disposition> i ran into something like that with the nexus s frome a friend too
289 2011-11-10 13:58:45 <ThomasV> Disposition: I followed the instructions, and now I have /dev/sdb and /dev/sdc that show up when I plug the phone. I tried to mount them, but it does not recognize them. what should the filesystem be? (I tried vfat)
290 2011-11-10 13:58:47 <Disposition> you should be able to mount it regularly.
291 2011-11-10 13:59:02 <Disposition> open gpart and see
292 2011-11-10 13:59:06 <Disposition> you should mount the fat32 one
293 2011-11-10 13:59:19 <ThomasV> whats gpart?
294 2011-11-10 13:59:34 <Disposition> gparted*
295 2011-11-10 13:59:41 <Disposition> alt +f2 and type gparted
296 2011-11-10 14:02:56 <ThomasV> oh it works now
297 2011-11-10 14:04:29 <ThomasV> Disposition: I could mount it. I confirm that the file you mention is not there
298 2011-11-10 14:05:22 <Disposition> com.xxx? or the whole .android_secure folder
299 2011-11-10 14:05:30 <ThomasV> the whole folder
300 2011-11-10 14:05:43 <ThomasV> there is no such folder
301 2011-11-10 14:05:44 <Disposition> what does the other folders include? we have Android in there?
302 2011-11-10 14:05:58 <ThomasV> yes there's Android, as I already told you
303 2011-11-10 14:06:25 <Disposition> that's gay
304 2011-11-10 14:06:29 <Disposition> still try
305 2011-11-10 14:06:39 <ThomasV> try what?
306 2011-11-10 14:06:50 <Disposition> adb pull /data/data/com.bitcoinandroid-1/files/prodnet.wallet
307 2011-11-10 14:07:13 <Disposition> once you get adb reading your device
308 2011-11-10 14:10:12 <ThomasV> Disposition: ok, I just need to learn how to use the sdk...
309 2011-11-10 14:10:35 <ThomasV> btw, how can I know what is my version of Android?
310 2011-11-10 14:11:56 <[eval]> in the home screen, hit the menu button, then tap "settings" and then "about phone"
311 2011-11-10 14:12:07 <[eval]> it'll have "android version" toward the bottom of the screen
312 2011-11-10 14:12:52 <ThomasV> oh I see it
313 2011-11-10 14:12:58 <ThomasV> version 2.3.3
314 2011-11-10 14:13:57 <Disposition> yeah, I unfortunately has to run off to work now, leave a message on the thread/pm if you run into anything else.
315 2011-11-10 14:15:40 <ThomasV> Disposition: but I do not have the file, so I guess it deleted it
316 2011-11-10 14:16:43 <Disposition> balls. what about adb pull /data/data/com.bitcoinandroid-1/files/prodnet.blockchain?
317 2011-11-10 14:17:03 <ThomasV> Disposition: what is "adb pull" ?
318 2011-11-10 14:17:10 <Disposition> wait keychain
319 2011-11-10 14:17:17 <Disposition> adb pulls data from your phone
320 2011-11-10 14:17:23 <Disposition> the command
321 2011-11-10 14:17:34 <ThomasV> is that a function provided by the sdk?
322 2011-11-10 14:17:37 <Disposition> ./adb pull
323 2011-11-10 14:17:43 <Disposition> adb is a exec provided by the SDK yes
324 2011-11-10 14:18:40 <Disposition> but yea if you can't find prodnet.keychain or prodnet.wallet in that path
325 2011-11-10 14:18:44 <Disposition> it might be problematic
326 2011-11-10 14:19:23 <ThomasV> Disposition: I started to download android 2.3.3. do I need to wait for it in order to use adb, or can I use it without android?
327 2011-11-10 14:19:28 <Disposition> I won't suggest reinstalling yet, I'm gonna see Yifu later this afternoon at OWS hopfully so I'll run it through it
328 2011-11-10 14:19:42 <Disposition> you should be able to use adb without the SDK really.
329 2011-11-10 14:19:49 <Disposition> it's a lower level function
330 2011-11-10 14:19:58 <ThomasV> k
331 2011-11-10 14:20:02 <[eval]> i think adb installs USB drivers
332 2011-11-10 14:20:12 <[eval]> or rather the SDK does... that are needed for adb to work properly
333 2011-11-10 14:20:14 <Disposition> usb drivers is a sperate package on the tools.
334 2011-11-10 14:20:15 <[eval]> depending on the phone
335 2011-11-10 14:20:20 <Disposition> under*
336 2011-11-10 14:20:43 <Disposition> anyhow, I'll look at it personally on the Nexus One later this afternoon with Yifu
337 2011-11-10 14:21:34 <ThomasV> Disposition: so I do adb pull with the math that I mounted, not with what you wrote above?
338 2011-11-10 14:21:37 <ThomasV> I guess
339 2011-11-10 14:21:55 <ThomasV> s/math/path
340 2011-11-10 14:24:38 <sipa> adb pull/push do direct interaction with the device
341 2011-11-10 14:24:43 <sipa> you don't need to mount anything
342 2011-11-10 14:25:00 <sipa> the path you give on the command line is the path on the device
343 2011-11-10 14:25:11 <Disposition> ^
344 2011-11-10 14:25:20 <ThomasV> it says "no such file or directory"
345 2011-11-10 14:26:00 <ThomasV> oh sorry, did not read all sipa
346 2011-11-10 14:27:22 <Disposition> k ig2g
347 2011-11-10 14:27:27 <ThomasV> no, bur adb does not work at all, no matter how I call it
348 2011-11-10 14:27:40 <ThomasV> thanks, ttyl
349 2011-11-10 14:27:49 <CIA-89> bitcoin: Gavin Andresen master * r145b2d0 / (25 files in 7 dirs):
350 2011-11-10 14:29:47 <CIA-89> bitcoin: Gavin Andresen master * r5efee7d / doc/release-process.txt : Release process doc fixes - http://git.io/HyE7HA
351 2011-11-10 14:40:24 <luke-jr> wtf @ that
352 2011-11-10 14:40:49 <luke-jr> why does bitcoin-qt need a wrapper script for debian, to do something it looks like bitcoin-qt should be doing itself?
353 2011-11-10 14:41:18 <gavinandresen> "Just Because."
354 2011-11-10 14:41:23 <luke-jr> bad reason :p
355 2011-11-10 14:41:38 <luke-jr> if bitcoin-qt should configure it, bitcoin-qt should do it itself, on all platforms&
356 2011-11-10 14:42:13 <b4epoche> So, I'm giving this bitcoin-based TEDx talk on Sunday&  I'd like to thank people here for helping with ideas for it.
357 2011-11-10 14:42:15 <gavinandresen> ... Matt said (iirc) the original ppa creator did it that way, so it's just legacy...
358 2011-11-10 14:42:38 <luke-jr> so he's committing someone else's work under his own name? -.-
359 2011-11-10 14:42:58 <gavinandresen> ... I don't know nuthin about ppas, but am pulling together the 0.5 rc4, and the debian pull isn't going to add any bugs, so I pulled it.
360 2011-11-10 14:43:21 <b4epoche> anyone not want their name mentioned?
361 2011-11-10 14:43:44 <gavinandresen> luke-jr: iirc, the person who was doing the bitcoin ppa doohickey is MIA
362 2011-11-10 14:44:04 <luke-jr> gavinandresen: doesn't stop --author
363 2011-11-10 14:44:09 <gavinandresen> (but I probably don't recall correctly)
364 2011-11-10 14:44:59 <gavinandresen> And the pull request would have been a better place to ask about all that.
365 2011-11-10 14:45:16 <luke-jr> except I don't look at every little pull request
366 2011-11-10 14:45:23 <gavinandresen> okey doke
367 2011-11-10 14:45:23 <luke-jr> maybe those should be announced on IRC too :p
368 2011-11-10 14:45:47 <luke-jr> the license violation override is probably a concern to the Debian project FWIW
369 2011-11-10 14:46:10 <b4epoche> sipa = pieter?
370 2011-11-10 14:46:53 <gavinandresen> luke-jr: contrib/debian/changelog looks clear on who did what
371 2011-11-10 14:47:04 <gavinandresen> luke-jr: what license violation override?
372 2011-11-10 14:47:16 <luke-jr> +  * Don't set rpcpassword for bitcoin-qt. <-- probably a bug
373 2011-11-10 14:47:20 <luke-jr> +bitcoind: possible-gpl-code-linked-with-openssl
374 2011-11-10 14:47:50 <luke-jr> apparently Debian's Expat is GPL-infected, and somehow we link to both it and OpenSSL?
375 2011-11-10 14:48:10 <gavinandresen> what is expat?
376 2011-11-10 14:48:14 <luke-jr> some XML lib
377 2011-11-10 14:48:29 <gavinandresen> mmm.  Maybe Qt brings it in.
378 2011-11-10 14:48:44 <luke-jr> maybe.
379 2011-11-10 14:48:47 <gavinandresen> What's the licensing issue?
380 2011-11-10 14:48:59 <luke-jr> OpenSSL isn't GPL-compatible
381 2011-11-10 14:49:08 <gavinandresen> What's the OpenSSL license?
382 2011-11-10 14:49:12 <gavinandresen> (I thought it was MIT)
383 2011-11-10 14:49:29 <BlueMatt> arg, qt licensing is a pita...
384 2011-11-10 14:49:36 <luke-jr> OpenSSL is dual licensed, both custom
385 2011-11-10 14:49:39 <denisx> Apache-style licence
386 2011-11-10 14:49:59 <luke-jr> BlueMatt: I see no reason bitcoin-qt shouldn't get a random rpcpassword by default
387 2011-11-10 14:50:12 <BlueMatt> because it isnt a server by default?
388 2011-11-10 14:50:17 <luke-jr> so? then it gets ignored
389 2011-11-10 14:50:33 <luke-jr> example bitcoind has '4way', which is long gone
390 2011-11-10 14:51:19 <sipa> b4epoche: yes
391 2011-11-10 14:51:33 <luke-jr> manpage looks like it needs updating; in particular, getwork's part shouldn't list midstate/hash1 since they're deprecated
392 2011-11-10 14:51:34 <gavinandresen> bitcoind still has a -4way switch?  That aught to get removed....
393 2011-11-10 14:51:45 <luke-jr> gavinandresen: I don't think so, but the example config in the Debian package does
394 2011-11-10 14:51:58 <BlueMatt> well then it needs updated
395 2011-11-10 14:52:02 <BlueMatt> its just out of date then
396 2011-11-10 14:52:09 <luke-jr> contrib/debian/patches/1001_use_system_json-spirit.patch <-- fail
397 2011-11-10 14:52:22 <gavinandresen> (speaking of which... anybody know of a good c++ static analysis for finding methods/members that look like they're never called?)
398 2011-11-10 14:52:31 <gavinandresen> ... analysis tool....
399 2011-11-10 14:52:33 <luke-jr> gavinandresen: please don't :P
400 2011-11-10 14:52:42 <BlueMatt> luke-jr: its disabled by default because we modify json-spirit
401 2011-11-10 14:52:50 <BlueMatt> (which we shouldnt really do...)
402 2011-11-10 14:52:53 <luke-jr> gavinandresen: removing "unused stuff" has a tendency to break 3rd party patches/modules
403 2011-11-10 14:53:27 <luke-jr> BlueMatt: I decided to stick to the embedded json-spirit for Gentoo only because json-spirit doesn't seem to support shared lib
404 2011-11-10 14:53:29 <gavinandresen> luke-jr: But there cannot be bugs or security exploits in code that isn't there.
405 2011-11-10 14:53:40 <BlueMatt> luke-jr: well thats retarded...
406 2011-11-10 14:54:13 <AliciaC> bugs or security issues are also irrelevant if the code never runs <.<
407 2011-11-10 14:54:36 <copumpkin> really?
408 2011-11-10 14:54:45 <gavinandresen> AliciaC: Less code means less code to review if you're looking for security vulnerabilities.  Which is a good thing
409 2011-11-10 14:54:55 <AliciaC> you have a point there
410 2011-11-10 14:54:56 <copumpkin> I guess that's a philosophical stance
411 2011-11-10 14:55:35 <cjdelisle> +1 for less code
412 2011-11-10 14:56:10 <gavinandresen> ... so nobody has a good static analysis tool for finding unused methods in C++ applications?  Anybody?  Beuller?
413 2011-11-10 14:56:49 <b4epoche> will clang++ do that?
414 2011-11-10 14:56:58 <gavinandresen> sed sucks.  awk rules.   (....  I love starting pointless religious wars....)
415 2011-11-10 14:57:06 <cjdelisle> :)
416 2011-11-10 14:57:55 <imsaguy2> "I'm a Mac." "I'm a PC."
417 2011-11-10 14:58:26 <BlueMatt> heh
418 2011-11-10 14:58:38 <luke-jr> gavinandresen: sed and awk both suck. perl ftw.
419 2011-11-10 14:58:41 <gavinandresen> Just for the record:  Mac.  Emacs.  Little Endian.
420 2011-11-10 14:58:49 <gavinandresen> Oh, and Python.
421 2011-11-10 14:58:59 <luke-jr> Little endian is broken by design.
422 2011-11-10 14:59:13 <gavinandresen> (lol, I knew one of those would get somebody to bite....)
423 2011-11-10 14:59:14 <luke-jr> hopefully Apple will die now that Jobs is gone
424 2011-11-10 14:59:44 <BlueMatt> gavinandresen: if you want a bite go with: Solaris, nano, little edian
425 2011-11-10 14:59:51 <BlueMatt> oh, and perl
426 2011-11-10 15:00:08 <gavinandresen> All righty, seriously, is there an issue with Expat/OpenSSL licensing that might actually cause a problem?  We can't be the only Qt project that uses OpenSSL
427 2011-11-10 15:01:43 <BlueMatt> http://people.gnome.org/~markmc/openssl-and-the-gpl.html
428 2011-11-10 15:01:56 <luke-jr> gavinandresen: not for PPA, but for Debian maybe
429 2011-11-10 15:02:14 <BlueMatt> not for either since they are dynamically linked, but for static release maybe
430 2011-11-10 15:02:39 <gavinandresen> luke-jr: Cool.  I don't think bitcoin should be part of the Official Debian Distribution until we hit version 1.0 anyway....
431 2011-11-10 15:02:47 <BlueMatt> too late
432 2011-11-10 15:03:22 <BlueMatt> also, there is an exception for os-shipped libraries to the problematic clause
433 2011-11-10 15:03:35 <BlueMatt> so it specifically does not apply to debian packages
434 2011-11-10 15:03:39 <BlueMatt> or ppa
435 2011-11-10 15:03:46 <BlueMatt> static linked release binary...
436 2011-11-10 15:03:48 <BlueMatt> not so sure
437 2011-11-10 15:03:54 <luke-jr> BlueMatt: the law doesn't care *how* you link
438 2011-11-10 15:04:07 <BlueMatt> if we arent shipping the library it does
439 2011-11-10 15:04:20 <luke-jr> BlueMatt: Debian *is* shipping the library
440 2011-11-10 15:04:30 <luke-jr> and I'm pretty sure the "OS exception" doesn't apply to the OS itself
441 2011-11-10 15:04:32 <gmaxwell> Sounds like a problem for debian.
442 2011-11-10 15:04:40 <luke-jr> that's what i said :p
443 2011-11-10 15:04:45 <BlueMatt> the way I read it, its not a problem
444 2011-11-10 15:04:49 <gmaxwell> Bitcoin is also not calling expat, no. So it just sounds like a linking accident, and not an actual issue.
445 2011-11-10 15:05:07 <cjdelisle> also sounds like a case of "what re they going to do? sue?"
446 2011-11-10 15:05:09 <gmaxwell> (at least not as far as I can tell)
447 2011-11-10 15:05:10 <BlueMatt> luke-jr: actually read the exception
448 2011-11-10 15:05:37 <gmaxwell> BlueMatt: I'm pretty sure you're off in space on that one. :)
449 2011-11-10 15:05:43 <cjdelisle> 99% of all software license issues are all in your head
450 2011-11-10 15:05:52 <BlueMatt> gmaxwell: has to be "major components of the os"
451 2011-11-10 15:06:14 <BlueMatt> cjdelisle: its a legal issue, but yea neither openssl nor nokia are going to sue us
452 2011-11-10 15:06:50 <gmaxwell> BlueMatt: it's the GPLed work who's license is being 'violated'. I can promise you don't moot the gpl by say "no no it's okay I put it in an OS"
453 2011-11-10 15:07:01 <gmaxwell> (see readline as an example)
454 2011-11-10 15:07:19 <gavinandresen> Danger would be somebody takes the code, repackages it into some commercial product, and then THEY get sued.
455 2011-11-10 15:07:30 <BlueMatt> debian's actual policy: http://lists.debian.org/debian-legal/2002/10/msg00113.html
456 2011-11-10 15:07:36 <gmaxwell> But its stupid. Just stop the idiot overlinking. If we're staticly linking then its just getting pulled in via the pkgconfig.
457 2011-11-10 15:08:13 <BlueMatt> from that, yea its a problem on debian but it appears that the writer doesnt seem to think its a legal problem, just debain being careful
458 2011-11-10 15:08:46 <BlueMatt> http://www.openssl.org/support/faq.html#LEGAL2
459 2011-11-10 15:08:54 <BlueMatt> openssl pretty much says no its not an issue
460 2011-11-10 15:09:19 <gmaxwell> Thats not what it says.
461 2011-11-10 15:09:30 <BlueMatt> "On many systems including the major Linux and BSD distributions, yes"
462 2011-11-10 15:09:49 <BlueMatt> so...no its not an issue, but debian takes the stance that it could be, so they wont allow it
463 2011-11-10 15:09:50 <gmaxwell> BlueMatt: the exception doesn't apply to the OS distributor themselves.
464 2011-11-10 15:11:09 <gmaxwell> (the point of the exception is to not create a pointless license violation, e.g. from linking libc on windows but you don't enjoy the excemption if you're distributing both the GPLed work and the non-free work)
465 2011-11-10 15:11:23 <gmaxwell> But this is a dumb tangent.
466 2011-11-10 15:11:27 <cjdelisle> ^
467 2011-11-10 15:11:41 <BlueMatt> yea, doesnt matter here
468 2011-11-10 15:11:57 <BlueMatt> all we need to care about is whether or not we can distribute static binaries with openssl+qt linked in
469 2011-11-10 15:11:57 <gmaxwell> Since, AFAIK, bitcoin is not using the library in question this is just a stupid linking accident.
470 2011-11-10 15:12:36 <BlueMatt> what library is that?
471 2011-11-10 15:12:46 <BlueMatt> I thought it was a openssl+qt issue
472 2011-11-10 15:12:52 <luke-jr> expat
473 2011-11-10 15:13:00 <luke-jr> Qt is LGPL, not GPL
474 2011-11-10 15:13:09 <BlueMatt> m
475 2011-11-10 15:13:13 <gmaxwell> Expat.
476 2011-11-10 15:13:21 <gavinandresen> Expat is MIT
477 2011-11-10 15:13:26 <BlueMatt> yes
478 2011-11-10 15:13:27 <gavinandresen> (as far as I can tell... right?)
479 2011-11-10 15:13:42 <gmaxwell> wtf. why are we having this discussion then?
480 2011-11-10 15:13:43 <luke-jr> O.o
481 2011-11-10 15:14:00 <BlueMatt> what discussion are we having?
482 2011-11-10 15:14:02 <luke-jr> ok, so I'm going with "the comment in BlueMatt's merge is totally bogus" now
483 2011-11-10 15:14:25 <luke-jr> https://github.com/bitcoin/bitcoin/commit/145b2d078e411ab0e49e70e5c6cd7ceca2f4e3c6#diff-7
484 2011-11-10 15:14:53 <BlueMatt> luke-jr: that is a OVERRIDE
485 2011-11-10 15:15:07 <BlueMatt> ie lintian thinks its an issue, but it is being overriden
486 2011-11-10 15:15:19 <luke-jr> why does lintian think it's an issue?
487 2011-11-10 15:15:25 <luke-jr> that's the bigger questoin
488 2011-11-10 15:15:30 <BlueMatt> because it looks for gpl linking against openssl
489 2011-11-10 15:15:39 <luke-jr> &
490 2011-11-10 15:15:40 <BlueMatt> I wasnt the person who added the override
491 2011-11-10 15:15:44 <BlueMatt> jonas did
492 2011-11-10 15:15:53 <luke-jr> I see your name as "Author"
493 2011-11-10 15:16:05 <BlueMatt> on the commit, not the files
494 2011-11-10 15:16:10 <luke-jr> same thing.
495 2011-11-10 15:16:14 <BlueMatt> not even close
496 2011-11-10 15:16:22 <luke-jr> if you didn't write it, set Author correct
497 2011-11-10 15:16:45 <BlueMatt> ...
498 2011-11-10 15:16:53 <gmaxwell> 08:15 <@BlueMatt> because it looks for gpl linking against openssl
499 2011-11-10 15:17:12 <gmaxwell> but there appears to be no gpl linking against openssl
500 2011-11-10 15:17:12 <sipa> why does it think expat in GPL
501 2011-11-10 15:17:18 <luke-jr> I wonder if we'd get more info if we took out that override
502 2011-11-10 15:17:19 <sipa> if it's MIT?
503 2011-11-10 15:17:31 <BlueMatt> the issue is the debian package files are gpl so there is gpl references in the debian license description files
504 2011-11-10 15:17:37 <BlueMatt> the code is mit
505 2011-11-10 15:17:40 <BlueMatt> thus the override
506 2011-11-10 15:18:02 <BlueMatt> (read the comments)
507 2011-11-10 15:18:03 <luke-jr> no GPL in Debian's patch to expat
508 2011-11-10 15:18:50 <luke-jr> no GPL mention in Debian's expat pkg info
509 2011-11-10 15:19:09 <BlueMatt> specifically read the debian/copyright file which gives the copyright for each file in bitcoin's src tree
510 2011-11-10 15:19:12 <luke-jr> the comment is bogus. someone should find out what the real problem it's overriding is
511 2011-11-10 15:19:33 <BlueMatt> wtf are you talking about?
512 2011-11-10 15:19:55 <BlueMatt> the problem: lintian sees gpl in debian/copyright and sees a link against openssl: complains
513 2011-11-10 15:20:08 <BlueMatt> the reality: only the debian/ dir and some images are gpl so its not an issue
514 2011-11-10 15:20:10 <BlueMatt> thus the override
515 2011-11-10 15:20:22 <luke-jr> of course it's an issue
516 2011-11-10 15:20:25 <gmaxwell> oh, _we_ have the GPLed code? That should be removed.
517 2011-11-10 15:20:25 <luke-jr> why are any of those GPL?
518 2011-11-10 15:20:44 <BlueMatt> we have gpl images and the debian manpage, etc are gpl
519 2011-11-10 15:20:49 <luke-jr> why?
520 2011-11-10 15:21:10 <luke-jr> arguably the manpage isn't a *real* issue, but icons could be
521 2011-11-10 15:21:21 <BlueMatt> I was just about to ask about icons
522 2011-11-10 15:21:23 <luke-jr> as well as the debian dir
523 2011-11-10 15:21:27 <BlueMatt> those were added with bitcoin-qt
524 2011-11-10 15:21:33 <BlueMatt> debian dir is build scripts
525 2011-11-10 15:21:43 <BlueMatt> you can license those under whatever the hell you want, they arent part of bitcoin's src
526 2011-11-10 15:21:50 <gmaxwell> It's all stupid. Find the author(s) and ask them to please relicense in common with bitcoin.
527 2011-11-10 15:22:01 <BlueMatt> there are a ton of authors
528 2011-11-10 15:22:08 <BlueMatt> (of images we use)
529 2011-11-10 15:22:49 <gmaxwell> How do we know the images are GPLed?
530 2011-11-10 15:22:53 <luke-jr> so find properly licensed images to replace them with
531 2011-11-10 15:22:59 <BlueMatt> because the site they were originally found on says GPL
532 2011-11-10 15:23:07 <BlueMatt> see: https://github.com/bitcoin/bitcoin/commit/145b2d078e411ab0e49e70e5c6cd7ceca2f4e3c6#diff-12
533 2011-11-10 15:23:13 <luke-jr> using GPL for images is IMO stupid, but still an issue
534 2011-11-10 15:23:24 <BlueMatt> not a choice anyone here made
535 2011-11-10 15:23:31 <gmaxwell> Well, that needs to go unless we're planning on making bitcoin a GPLed package.
536 2011-11-10 15:23:39 <luke-jr> plenty of other icons to choose from
537 2011-11-10 15:23:41 <luke-jr> they can be replaced
538 2011-11-10 15:23:46 <BlueMatt> then replace them
539 2011-11-10 15:23:47 <luke-jr> gmaxwell: then OpenSSL has to go
540 2011-11-10 15:23:51 <gmaxwell> also crap like
541 2011-11-10 15:23:52 <gmaxwell> "+License: Freeware Non-commercial"
542 2011-11-10 15:23:59 <luke-jr> <<!
543 2011-11-10 15:24:11 <BlueMatt> hey, Im not the one who merged bitcoin-qt
544 2011-11-10 15:24:24 <BlueMatt> In fact, Ive brought the issue up before and people said its not an issue
545 2011-11-10 15:24:28 <luke-jr> CC-BY-3 is GPL-incompatible too; not sure if it's an issue for OpenSSL or not
546 2011-11-10 15:24:41 <sipa> what do you use from openssl?
547 2011-11-10 15:24:46 <sipa> EC and AES?
548 2011-11-10 15:24:48 <gmaxwell> no, the openssl license is just a bsd with advertising clause.
549 2011-11-10 15:24:52 <luke-jr> sipa: ECDSA, AES, SHA256 I think
550 2011-11-10 15:25:05 <cjdelisle> also base58
551 2011-11-10 15:25:08 <gmaxwell> we have our own sha256 but we still use the openssl one.
552 2011-11-10 15:25:14 <gmaxwell> cjdelisle: no, thats silly.
553 2011-11-10 15:25:14 <sipa> cjdelisle: base58 is custom bitcoin
554 2011-11-10 15:25:21 <luke-jr> in fact, I suspect CC-BY-3 is non-free
555 2011-11-10 15:25:24 <luke-jr> let me review my notes
556 2011-11-10 15:25:25 <cjdelisle> read it
557 2011-11-10 15:25:25 <sipa> it's not even the same base58 as flickr uses
558 2011-11-10 15:25:36 <cjdelisle> base58 pulls in openssl
559 2011-11-10 15:25:43 <gmaxwell> luke-jr: who cares about by-3
560 2011-11-10 15:25:44 <gmaxwell> +License: CC-BY-ND-3
561 2011-11-10 15:25:49 <cjdelisle> try and compile it without openssl
562 2011-11-10 15:25:56 <luke-jr> ugh
563 2011-11-10 15:26:03 <sipa> cjdelisle: oh right, it uses openssl's bignum lib
564 2011-11-10 15:26:07 <cjdelisle> yes
565 2011-11-10 15:26:11 <BlueMatt> also: Ive said repeatedly that the about menu for bitcoin-qt needs changed to not violate the 20 licenses of images we use...
566 2011-11-10 15:26:23 <luke-jr> gmaxwell: I think the NonCommercial is the worst part in there, since all Bitcoin is commercial
567 2011-11-10 15:26:53 <gmaxwell> cjdelisle: just because of #include <openssl/bn.h> in bignum.h..
568 2011-11-10 15:27:03 <luke-jr> PUB-DOM is an issue as well, since various jurisdictions don't recognize public domain
569 2011-11-10 15:27:54 <cjdelisle> I don't see why license issues even matter, it's not like btc is closed source.
570 2011-11-10 15:28:01 <gmaxwell> cjdelisle: ...
571 2011-11-10 15:28:06 <edcba> lol
572 2011-11-10 15:28:10 <BlueMatt> hahaha
573 2011-11-10 15:28:12 <cjdelisle> who is going to sue and who would they sue?
574 2011-11-10 15:28:18 <sipa> cjdelisle: you believe that open source means no license issues?
575 2011-11-10 15:28:30 <BlueMatt> oss just means more license issues
576 2011-11-10 15:28:30 <gmaxwell> cjdelisle: because any of the copyright holders can troll and create fud about these inconsequential license violations.
577 2011-11-10 15:28:40 <luke-jr> so anyhow, what files are 'Expat' license even? :P
578 2011-11-10 15:28:49 <cjdelisle> *cough* ecdsa
579 2011-11-10 15:28:53 <cjdelisle> patents
580 2011-11-10 15:29:04 <cjdelisle> if you are afraid of trolls then you have already Lost
581 2011-11-10 15:29:22 <upb> yes
582 2011-11-10 15:29:28 <gmaxwell> cjdelisle: Not so, http://tools.ietf.org/html/rfc6090
583 2011-11-10 15:29:40 <gmaxwell> cjdelisle: there is no ambiguity on the patent situation with the ECC we use.
584 2011-11-10 15:29:44 <gmaxwell> _none_
585 2011-11-10 15:29:56 <edcba> especially in europe o/
586 2011-11-10 15:30:25 <gmaxwell> cjdelisle: and the licensing here isn't disputable. It's real if fucking stupid.
587 2011-11-10 15:30:43 <cjdelisle> has anyone threatened to sue you?
588 2011-11-10 15:31:19 <BlueMatt> cjdelisle: not relevant
589 2011-11-10 15:31:35 <BlueMatt> cjdelisle: if bitcoin *does* get big, we dont want to have the issue appear then
590 2011-11-10 15:32:10 <ThomasV> https://bitcointalk.org/index.php?topic=51474.0;topicseen    wtf?
591 2011-11-10 15:32:27 <gmaxwell> Moreover it may never be _us_ anyone threatens to sue. Presumably we've chosen the fairly liberal mit style license for a reason equally we should avoid clouding it without a good reason.
592 2011-11-10 15:33:28 <cjdelisle> this is like redhat neutering openssl because they are afraid of patents
593 2011-11-10 15:33:45 <gmaxwell> No, it's not.
594 2011-11-10 15:33:48 <sipa> ThomasV: i think that's a real issue
595 2011-11-10 15:34:06 <ThomasV> sipa: so it is true?
596 2011-11-10 15:34:10 <BlueMatt> ThomasV: yep, looks quite possible, dont think theres really much of a way to fix it though
597 2011-11-10 15:34:16 <sipa> i haven't tested it but it sounds reasonable
598 2011-11-10 15:34:21 <sipa> bdb not overwriting enough data when encryption is done
599 2011-11-10 15:34:26 <BlueMatt> except going back to the drawing board and creating new wallets, etc
600 2011-11-10 15:34:37 <ThomasV> what is bdb?
601 2011-11-10 15:34:48 <BlueMatt> the lib we use to write to wallet.dat
602 2011-11-10 15:34:50 <BlueMatt> among other files
603 2011-11-10 15:35:13 <ThomasV> oh it has a fixed size, and it writes chunks in that space?
604 2011-11-10 15:35:18 <sipa> no
605 2011-11-10 15:35:30 <BlueMatt> no, but it doesnt feel like overwriting old data...
606 2011-11-10 15:35:32 <wumpus> only solution would be to use a different db backend for the private keys
607 2011-11-10 15:35:47 <ThomasV> hmm
608 2011-11-10 15:35:49 <gmaxwell> Thats not the only soluition.
609 2011-11-10 15:35:55 <sipa> we *could*, after encryption, iterate the key/val pairs, write those to a new file, and then move+overwrite
610 2011-11-10 15:35:57 <BlueMatt> anyone feel like digging through bdb's src to figure out if there is a way to ensure it overwrites stuff?
611 2011-11-10 15:35:59 <wumpus> gmaxwell: then what do you propose?
612 2011-11-10 15:36:01 <gmaxwell> Just provide a wallet washer that uses dbdump to rebuild the wallet.
613 2011-11-10 15:36:04 <BlueMatt> ie if we replace will it overwrite?
614 2011-11-10 15:36:17 <sipa> but the issue remains (though less seriously) at the disk level
615 2011-11-10 15:36:32 <BlueMatt> and what can we do about that?
616 2011-11-10 15:36:41 <gmaxwell> BlueMatt: need wallets to be born encrypted for that.
617 2011-11-10 15:36:41 <sipa> i mean, a "ResilverWalletFile()" routine is pretty easy and safe to implement
618 2011-11-10 15:36:44 <cjdelisle> should be able to shred the file
619 2011-11-10 15:36:44 <wumpus> at the disk level is arguably less serious
620 2011-11-10 15:36:50 <BlueMatt> gmaxwell: exactly
621 2011-11-10 15:37:12 <wumpus> now you can still steal the file... thats what wallet encryption was supposed to stop
622 2011-11-10 15:37:20 <sipa> wumpus: agree, that is serious
623 2011-11-10 15:37:35 <BlueMatt> yep, so whos gonna volunteer?
624 2011-11-10 15:38:08 <BlueMatt> and silence
625 2011-11-10 15:38:25 <wumpus> but yeah rebuilding the db when enabling wallet encryption could work too, it's already re-writing all the keys
626 2011-11-10 15:38:31 <gmaxwell> BlueMatt: everyone is hard at work working on it! yep. yep.
627 2011-11-10 15:38:47 <BlueMatt> gmaxwell: heh, thats always how it happens around here...
628 2011-11-10 15:39:35 <sipa> you could provide a ResilverFile() method in CDB in general
629 2011-11-10 15:39:53 <sipa> that locks, iterates, rewrites, closes, moves, reopens, unlocks :)
630 2011-11-10 15:40:04 <BlueMatt> ;)
631 2011-11-10 15:40:42 <cjdelisle> IMO create new, shred old with urandom, delete old, copy new would be the easiest thing to do.
632 2011-11-10 15:41:00 <BlueMatt> easiest not the cleanest
633 2011-11-10 15:41:26 <BlueMatt> check bdb src first and note the relevant files so that it can be checked on future bdb versions as well
634 2011-11-10 15:41:29 <gmaxwell> cjdelisle: new will have unencrypted keys in it too.
635 2011-11-10 15:41:36 <cjdelisle> there might be a flush()/compact()/etc trick with bdb but it certainly doesn't make any security guarantees since bdb is not a security app.
636 2011-11-10 15:41:36 <wumpus> cleanest would be to use a database/file format that supports security in the first place... but yeah, does such a thing exist
637 2011-11-10 15:41:53 <BlueMatt> bdb supports it
638 2011-11-10 15:42:05 <BlueMatt> bdb supports aes encryption of the whole file
639 2011-11-10 15:42:14 <wumpus> right, that sounds good
640 2011-11-10 15:42:16 <cjdelisle> if bdb supports a secureCompact() then that makes sense to use
641 2011-11-10 15:42:29 <cjdelisle> but just a compact() that happens to work is asking for trouble
642 2011-11-10 15:43:25 <wumpus> and then split up the wallet in a private key and public key db file, and use encrypted settings for the private one
643 2011-11-10 15:44:31 <gmaxwell> wumpus: and then they get out of sync because you can't do atomic operations across files or because the user copied one and not the other.
644 2011-11-10 15:45:01 <cjdelisle> if bdb supported seeking to a position in a file before opening it as a database then we could make a wallet2.0 which had the key at the beginning then the db following the key.
645 2011-11-10 15:45:13 <wumpus> well in the private file you could store the public info as wel
646 2011-11-10 15:45:42 <phantomcircuit> wumpus, it's impossible not to
647 2011-11-10 15:45:46 <cjdelisle> then if you enable encryption, it's easy to shred the first 32 bytes of the file
648 2011-11-10 15:46:11 <gmaxwell> 'easy'
649 2011-11-10 15:46:25 <gmaxwell> cjdelisle: many file systems don't let you reliably overwrite anything.
650 2011-11-10 15:46:37 <wumpus> I don think we should worry about the file system here
651 2011-11-10 15:46:38 <cjdelisle> aka crypto is on all the time but usually the key is at the beginning of the wallet file.
652 2011-11-10 15:46:42 <cjdelisle> indeed
653 2011-11-10 15:46:44 <wumpus> the problem is that the file doesn't clean itselfup
654 2011-11-10 15:47:00 <wumpus> file system is a wholly different problem
655 2011-11-10 15:47:01 <gavinandresen> Hmmm.  Seems to me safest/easiest is for an encrypted wallet to be 'born encrypted.'
656 2011-11-10 15:47:08 <cjdelisle> if the user is using a flash drive, there is no way you can make them safe from an attack.
657 2011-11-10 15:47:11 <gmaxwell> wumpus: well don't say " it's easy to shred".. it's easy to run compact too.
658 2011-11-10 15:47:17 <sipa> gavinandresen: agree we need that functionality
659 2011-11-10 15:47:24 <gavinandresen> So Encrypt Wallet would:   Create new encrypted wallet.  Send all coins to new address(es).  Erase old wallet.
660 2011-11-10 15:47:40 <wumpus> gmaxwell: yes, that's easy, if it guarantees that all the unused space is squashed it's enough
661 2011-11-10 15:47:41 <sipa> people might want to keep using their old addresses
662 2011-11-10 15:47:45 <gmaxwell> gavinandresen: I want to keep using my old addresses.
663 2011-11-10 15:47:49 <BlueMatt> problem is you cant just erase old wallet, people need their old addrs
664 2011-11-10 15:48:06 <sipa> if we have a "encrypt wallet" functionality, it should guarantee the file doesn't retain a trace of the unencrypted keys
665 2011-11-10 15:48:07 <wumpus> if a compact solves our worries that'd be great
666 2011-11-10 15:48:09 <gavinandresen> Ok, so import the old keypairs.  But don't use them for new transactions
667 2011-11-10 15:48:12 <cjdelisle> gmaxwell: the problem with a compact() function is it makes no guarantees at all, it's not mean for security so it could just as well decide that it's not worth the effort for the saved space and just do nothing.
668 2011-11-10 15:48:12 <sipa> about the disk we can't do anything
669 2011-11-10 15:48:26 <gavinandresen> (mark all the keys in the old keypool as used)
670 2011-11-10 15:48:46 <gmaxwell> cjdelisle: fine. Then htere is the simple option of resilvering.
671 2011-11-10 15:48:54 <sipa> gavinandresen: grave enough to break 0.5.0 release?
672 2011-11-10 15:49:06 <gmaxwell> gavinandresen: yes, thats an improvement.
673 2011-11-10 15:49:13 <luke-jr> gavinandresen: btw, while you were gone, we learned that the licensing issues are much more involved and affect Bitcoin-Qt itself, even without involving any dependencies&
674 2011-11-10 15:49:23 <cjdelisle> I gather by resilver you mean replace, shred, delete, move...
675 2011-11-10 15:49:46 <sipa> yes
676 2011-11-10 15:49:55 <gmaxwell> cjdelisle: yes, lock, create a new one, copy the data.. fill with crap.. delete.. move.. unlock as was said above.
677 2011-11-10 15:49:56 <luke-jr> gavinandresen: in particular, it's using stuff licensed "noncommercial use only", "no derived works", and GPL all at the same time
678 2011-11-10 15:49:58 <sipa> resilvering is really not hard to implement - but i don't have the time right now
679 2011-11-10 15:50:20 <wumpus> gavinandresen: you could do that, but also make sure that the non-encrypted keys are flushed from the file, that remains important
680 2011-11-10 15:50:24 <CIA-89> bitcoin: Luke Dashjr * r843365393d70 gentoo/net-p2p/ (23 files in 3 dirs): net-p2p/{bitcoind,wxbitcoin,bitcoin-qt}: Update LICENSE to include everything :/
681 2011-11-10 15:50:25 <CIA-89> bitcoin: Luke Dashjr * rb3eee5344040 gentoo/net-p2p/bitcoind/ (4 files): net-p2p/bitcoind: remove obsolete FIXME
682 2011-11-10 15:50:43 <gavinandresen> wumpus: ???  what non-encrypted keys in what file???
683 2011-11-10 15:50:45 <gmaxwell> cjdelisle: that plus gavin's proposed handling of the keypool. would be as close as we can probably get.
684 2011-11-10 15:50:54 <BlueMatt> fuck it: lets require wallets stored on partitions in a format we control, or even better: every must have a smart card to use bitcoin
685 2011-11-10 15:50:55 <cjdelisle> /nod
686 2011-11-10 15:50:55 <gmaxwell> gavinandresen: :( https://bitcointalk.org/index.php?topic=51474.0;topicseen
687 2011-11-10 15:51:01 <wumpus> gavinandresen: berkelydb keeps around old stuff
688 2011-11-10 15:51:24 <wumpus> gavinandresen: that's the problem, not  so much bitcoin itself
689 2011-11-10 15:51:32 <gavinandresen> wumpus: right, I'm saying write wallet_enc.dat, delete wallet.dat, move wallet_enc.dat to wallet.dat ....
690 2011-11-10 15:51:48 <wumpus> gavinandresen: yes, resilvering
691 2011-11-10 15:51:58 <gavinandresen> (ideally, secure-delete wallet.dat-- could just be a write-random-before erase)
692 2011-11-10 15:52:05 <sipa> gavinandresen: it could be a separate operation from the encryption process itself
693 2011-11-10 15:52:16 <gavinandresen> (probably have to shut down all database operations and remove all the log files, too...)
694 2011-11-10 15:52:17 <sipa> just iterate the keys in a file, dump them to a new one
695 2011-11-10 15:52:37 <wumpus> sipa: yes, it is a separate operation, it needs ot be invoked by the encryption process of course
696 2011-11-10 15:52:43 <sipa> wumpus: yes
697 2011-11-10 15:52:51 <wumpus> I wonder if bdb has something built-in like this, we can't be the first...
698 2011-11-10 15:53:13 <luke-jr> can't we just write a wallet.db.new, and move it over the old file?
699 2011-11-10 15:53:33 <sipa> luke-jr: exactly what we're discussing
700 2011-11-10 15:53:35 <gmaxwell> luke-jr: thats what sipa was suggesting with 'resilvering'
701 2011-11-10 15:53:39 <wumpus> yes
702 2011-11-10 15:53:49 <sipa> but the problem with the log files remains
703 2011-11-10 15:53:56 <sipa> slightly less bad than the wallet file issue
704 2011-11-10 15:54:11 <luke-jr> sipa: that Debian patch BlueMatt just merged seems to delete log files on clean exit
705 2011-11-10 15:54:13 <gmaxwell> sipa: we already clean up the logs on start, no? so clean up during resilver?
706 2011-11-10 15:54:19 <sipa> gmaxwell: oh, good
707 2011-11-10 15:54:23 <wumpus> luke-jr: it's only the icons that have different licenses, if that's a problem they can be easily replaced
708 2011-11-10 15:54:34 <luke-jr> wumpus: yes, but someone still needs to do it
709 2011-11-10 15:54:44 <BlueMatt> luke-jr: thats not a patch, thats a script
710 2011-11-10 15:54:44 <sipa> then just some message box "please close and restart bitcoin now, to make sure all traces of your all keys are deleted from temporary files"
711 2011-11-10 15:54:49 <sipa> ah
712 2011-11-10 15:54:52 <BlueMatt> luke-jr: that starts bitcoin
713 2011-11-10 15:55:01 <luke-jr> BlueMatt: irrelevant. the point is it can (and should?) be done
714 2011-11-10 15:55:05 <sipa> well it should be part of bitcoin itself, no?
715 2011-11-10 15:55:17 <BlueMatt> luke-jr: yep, I brought that up a few days ago
716 2011-11-10 15:55:22 <BlueMatt> dont remember where...
717 2011-11-10 15:55:26 <wumpus> luke-jr: feel free to do that, I don't have any artistic skills as such
718 2011-11-10 15:55:28 <BlueMatt> think it might have been the pull req discussion
719 2011-11-10 15:57:30 <wumpus> problem with log files? do we write private keys to log files?
720 2011-11-10 15:57:40 <BlueMatt> because they are log files of a db
721 2011-11-10 15:57:45 <BlueMatt> and we write privkeys to the db
722 2011-11-10 15:58:08 <wumpus> right ... ouch
723 2011-11-10 15:58:11 <gmaxwell> wumpus: these are transaction logs used to recover from unclean shutdown, not the kind of logs you're thinking of.
724 2011-11-10 15:58:27 <wumpus> it's leaking on all sides
725 2011-11-10 15:58:34 <gavinandresen> Unencrypted private keys left on disk IS a 0.5 release show-stopper, in my opinion
726 2011-11-10 15:58:35 <BlueMatt> yep
727 2011-11-10 15:58:41 <sipa> gavinandresen: agree
728 2011-11-10 15:58:42 <gmaxwell> Well the logs already get cleaned up on start.
729 2011-11-10 15:58:44 <BlueMatt> also the copyright stuff...
730 2011-11-10 15:59:16 <BlueMatt> we're probably a couple weeks away from a solution to the both of those...
731 2011-11-10 15:59:16 <cjdelisle> IMO best answer to the copyright stuff is to allow the json port to support a persistent connection and split the UI from the core.
732 2011-11-10 15:59:24 <gmaxwell> Yea. I actually had an encrypted copy of my wallet on a less secure machine... with privkeys in it. :-/
733 2011-11-10 15:59:25 <BlueMatt> cjdelisle: hahahaha
734 2011-11-10 15:59:33 <gmaxwell> cjdelisle: ... just .. stop.
735 2011-11-10 15:59:43 <gavinandresen> Copyright stuff is not a show-stopper, in my opinion.  We're as open as we can possibly be, we are certainly abiding by the spirit of all the open source licenses if not the exact annoying legal letter
736 2011-11-10 15:59:43 <wumpus> right...
737 2011-11-10 15:59:51 <wumpus> gavinandresen: +1
738 2011-11-10 15:59:58 <cjdelisle> agreed there
739 2011-11-10 16:00:01 <BlueMatt> gavinandresen: and when mtgox gets sued?
740 2011-11-10 16:00:08 <wumpus> we need to solve the encryption stuff, replacing icons can wait for another time...
741 2011-11-10 16:00:13 <BlueMatt> or bitcoinconsultancy
742 2011-11-10 16:00:14 <gmaxwell> gavinandresen: I think you missed the later discussion there.
743 2011-11-10 16:00:33 <gmaxwell> gavinandresen: the icons have non-commercial use only licenses, non-derivs licenses, etc.
744 2011-11-10 16:00:47 <wumpus> replace the icons with black squares for all I care
745 2011-11-10 16:00:59 <gavinandresen> gmaxwell: okey doke.  Mtgox isn't using bitcoin-qt....
746 2011-11-10 16:01:03 <luke-jr> gavinandresen: as-is right now, Bitcoin-Qt is NOT free software, and CANNOT BE USED FOR COMMERCIAL PURPOSES
747 2011-11-10 16:01:08 <BlueMatt> the original response I got on that was "meh, the code is mit, so just use bitcoind and you are fine"
748 2011-11-10 16:01:14 <gmaxwell> gavinandresen: come on now.
749 2011-11-10 16:01:47 <wumpus> yes the bitcoind code does not use the icons
750 2011-11-10 16:01:50 <BlueMatt> but seriously, who gives a shit if bitcoin-qt's icons are free software or not?
751 2011-11-10 16:02:10 <gmaxwell> In any case, you don't need to worry about it. Let people who care fix it.
752 2011-11-10 16:02:11 <pickett> i'm sure there's people that do
753 2011-11-10 16:02:18 <sipa> does using an icon in a program count as "deriving work" ?
754 2011-11-10 16:02:27 <luke-jr> sipa: clearly
755 2011-11-10 16:02:33 <gavinandresen> luke-jr: .... so don't use bitcoin-qt for commercial purposes.  That seems like a README issue.
756 2011-11-10 16:02:43 <gmaxwell> sipa: don't waste your time trying to have an argument.
757 2011-11-10 16:02:52 <wumpus> you could replace just the non-commercial icons
758 2011-11-10 16:02:59 <gmaxwell> gavinandresen: That seems like a PR disaster. BITCOIN THE CRYPTOCURRENCY YOU CAN'T USE FOR COMMERCE.