1 2011-11-21 00:43:18 <roconnor> sipa: block!
  2 2011-11-21 00:43:35 <sipa> roconnor: saw it :D
  3 2011-11-21 00:46:50 <cocktopus> duck duck duck duck duck BLOCK you're out
  4 2011-11-21 00:54:37 <sipa> roconnor: https://github.com/bitcoin/bitcoin/pull/649
  5 2011-11-21 00:57:07 <roconnor> sipa: nice
  6 2011-11-21 00:57:21 <roconnor> sipa: will it ever make it into mainline?
  7 2011-11-21 00:58:10 <BlueMatt> its kinda a lot of code change for such a small gain...
  8 2011-11-21 00:58:24 <BlueMatt> but the disk space saved might make a strong enough arguemnt...
  9 2011-11-21 00:58:29 <sipa> not immediately, it will need quite some testing
 10 2011-11-21 00:58:43 <sipa> and we need to be certain that all full client implementations support it
 11 2011-11-21 01:09:13 <gmaxwell> sipa: may you not suffer the flamefest on the list when someone observes that two addresses for the same backing private key material breaks a bijection they imagined existing. ;)
 12 2011-11-21 01:10:08 <sipa> gmaxwell: we'll see :)
 13 2011-11-21 01:12:24 <sipa> it will interfere with import/export private key, though
 14 2011-11-21 01:13:05 <sipa> so maybe secrets for compressed pubkey-addresses need an extra byte tucked on to identify them as such
 15 2011-11-21 01:24:57 <roconnor> sipa: do you know where the elliptic curve parameters are specified in bitcoin?
 16 2011-11-21 01:27:02 <sipa> roconnor: in key.h
 17 2011-11-21 01:27:09 <sipa> in the CKey constructor
 18 2011-11-21 01:40:25 <luke-jr> sipa: why not intentionally use private keys multiple times? :P
 19 2011-11-21 01:40:33 <luke-jr> that'd save even more space
 20 2011-11-21 01:41:13 <luke-jr> or is there a way to tell that they're the same one?
 21 2011-11-21 01:42:55 <sipa> luke-jr: not from an address, but as soon as an address is used, and either its compressed or normal pubkey is revealed, everyone can compute the other address that corresponds to it
 22 2011-11-21 01:43:11 <luke-jr> i c
 23 2011-11-21 01:43:42 <luke-jr> sipa: what happens if I compute someone's compressed key, and send to it, even though their client only supports full keys? :P
 24 2011-11-21 01:43:52 <sipa> they won't get it
 25 2011-11-21 01:44:20 <luke-jr> what if their client supports compressed keys, but it generated it as a non-compressed one? :P
 26 2011-11-21 01:44:26 <sipa> they won't get it
 27 2011-11-21 01:44:41 <luke-jr> lame
 28 2011-11-21 01:45:01 <sipa> just like they won't get anything if you create a fancy one-out-of-three script that sends to three pubkeys that are all theirs
 29 2011-11-21 01:45:31 <sipa> the address corresponds to a certain txout script template, and you shouldn't expect anyone to accept that txout as valid, unless they gave it to you themselves
 30 2011-11-21 01:46:02 <gmaxwell> sipa: told you. ;)
 31 2011-11-21 01:46:39 <luke-jr> gmaxwell: :P
 32 2011-11-21 01:47:23 <sipa> well, that's exactly the reason why i chose to keep them separated
 33 2011-11-21 01:47:28 <luke-jr> sipa: how about supporting it, so that annoying services can say "to receive funds from us, you need to upgrade" :P
 34 2011-11-21 01:47:45 <sipa> that doesn't make sense
 35 2011-11-21 01:48:08 <luke-jr> yes it does
 36 2011-11-21 01:48:22 <sipa> they can't send to your compressed pubkey unless you give them an address that corresponds to a compressed pubkey
 37 2011-11-21 01:48:34 <gmaxwell> people don't usually give out pubkeys in any case.
 38 2011-11-21 01:48:39 <sipa> in fact, they can't even know whether they are sending to compressed pubkey's address or not
 39 2011-11-21 01:48:51 <luke-jr> until you redeem it
 40 2011-11-21 01:48:59 <sipa> yes
 41 2011-11-21 01:49:06 <luke-jr> "the first time we send you will always work, but after that you need version 0.6+"
 42 2011-11-21 01:50:01 <sipa> i'm a firm believer that only the receiver should determine how he accepts funds :)
 43 2011-11-21 01:50:56 <gmaxwell> otherwise why not send people funds via cloud writing?
 44 2011-11-21 01:51:52 <gmaxwell> "what do you mean you didn't get it? it was above moscow, most populus city of russia, for two hours! Not our problem. The funds are lost now, too bad for you."
 45 2011-11-21 01:52:01 <luke-jr> sipa: too bad. I'm still generating them.
 46 2011-11-21 01:52:24 <gmaxwell> luke-jr: they're not shorter than send to address.
 47 2011-11-21 01:52:45 <luke-jr> ?
 48 2011-11-21 01:52:55 <luke-jr> the pubkey is. less space when spent.
 49 2011-11-21 01:53:24 <gmaxwell> Yes, not when sent though. And the pubkey could be _zero_ when spent if we used recovery.
 50 2011-11-21 01:54:10 <sipa> luke-jr: "i'm still generating them" -> generating what?
 51 2011-11-21 01:54:17 <luke-jr> payouts
 52 2011-11-21 01:54:36 <luke-jr> gmaxwell: that isn't backward compatible
 53 2011-11-21 01:54:58 <sipa> you're going to do send-to-(compressed)-pubkey for payouts?
 54 2011-11-21 01:55:03 <gmaxwell> sipa: sounds like luke is saying he's going to start doing his pool payouts to compressed pubkeys.
 55 2011-11-21 01:55:18 <luke-jr> sipa: no, but generation is already a "you have to do this to receive" thing
 56 2011-11-21 01:55:23 <luke-jr> mainly due to bitcoind special-casing it
 57 2011-11-21 01:55:42 <sipa> true - but the script is still something the receiver determines, right?
 58 2011-11-21 01:55:56 <luke-jr> not really.
 59 2011-11-21 01:56:02 <luke-jr> they give me an address.
 60 2011-11-21 01:56:06 <sipa> you won't be using non-standard scripts for payouts, if you don't know whether the receiver's client supports it
 61 2011-11-21 01:56:15 <luke-jr> true
 62 2011-11-21 01:56:19 <sipa> and an address is a template for a txout script
 63 2011-11-21 01:56:26 <luke-jr> if you say so
 64 2011-11-21 01:57:00 <sipa> well, it is also an identifier for a key
 65 2011-11-21 01:57:20 <sipa> but i don't like looking at them like that
 66 2011-11-21 04:17:31 <cjdelisl1> anyone know anything about endienness of integers in bitfields?
 67 2011-11-21 04:17:51 <cjdelisl1> I have this:
 68 2011-11-21 04:17:52 <cjdelisl1> uint32_t fragmentNumber : 4;
 69 2011-11-21 04:18:07 <cjdelisl1> and there's an #ifdef to check for big endian and reverse them
 70 2011-11-21 04:18:23 <cjdelisl1> when I read messageType, do I need to call ntohl()?
 71 2011-11-21 04:21:26 <copumpkin> fucking bitfields
 72 2011-11-21 04:24:09 <bd_> cjdelisl1: bitfield representation is not portable, period
 73 2011-11-21 04:24:27 <bd_> even on the same OS, different compilers handle it differently, and ntohl won't save you
 74 2011-11-21 04:24:41 <cjdelisl1> ok, I'll just do it all manually then
 75 2011-11-21 04:24:43 <cjdelisl1> thanks
 76 2011-11-21 04:24:53 <bd_> the contents of messageType and fragmentNumber might be swapped, or they might vanish entirely because some other compiler used that part of the structure as padding :)
 77 2011-11-21 04:24:57 <bd_> that's probably best yeha
 78 2011-11-21 04:24:59 <cjdelisl1> it seems so nice and easy
 79 2011-11-21 05:19:20 <hazdb> I need a coder for a project. where do I go?
 80 2011-11-21 05:19:23 <hazdb> a bitcoin project
 81 2011-11-21 05:21:55 <phantomcircuit> hazdb, right here
 82 2011-11-21 05:21:57 <Eliel> this is probably the place :)
 83 2011-11-21 05:21:59 <phantomcircuit> hazdb, what do you need
 84 2011-11-21 08:07:27 <CIA-89> bitcoin: Luke Dashjr master * raa1ed92 / contrib/debian/copyright : update debian copyright file for MIT icon relicensing - http://git.io/I1HoFA
 85 2011-11-21 08:07:28 <CIA-89> bitcoin: Wladimir J. van der Laan master * rc968b68 / contrib/debian/copyright :
 86 2011-11-21 09:32:47 <batouzo> !seen genjix
 87 2011-11-21 09:32:47 <gribble> genjix was last seen in #bitcoin-dev 2 weeks, 0 days, 13 hours, 22 minutes, and 15 seconds ago: <genjix> :)
 88 2011-11-21 09:32:47 <spaola> genjix (genjix@31-222-176-99.static.cloud-ips.co.uk) was last seen parting #bitcoin-dev 14 days, 12 hours, 21 minutes ago stating "{}".
 89 2011-11-21 09:33:07 <batouzo> !tell genjix Congratulations on your Slashdot article, my god!! :)
 90 2011-11-21 09:33:48 <batouzo> I fail at tell-later
 91 2011-11-21 09:37:00 <batouzo> http://politics.slashdot.org/story/11/11/21/0230217/swedish-pirate-party-member-to-be-eus-youngest-mp
 92 2011-11-21 09:40:05 <grubles> it's later tell
 93 2011-11-21 09:40:54 <batouzo> !later tell satoshi where are you when we need you
 94 2011-11-21 09:40:55 <gribble> The operation succeeded.
 95 2011-11-21 09:41:18 <grubles> :D
 96 2011-11-21 09:41:29 <coingenuity> ;;seen satoshi
 97 2011-11-21 09:41:29 <gribble> satoshi was last seen in #bitcoin-dev 39 weeks, 4 days, 10 hours, 40 minutes, and 56 seconds ago: <satoshi> satoshi is here!
 98 2011-11-21 09:42:16 <batouzo> coingenuity: how's your site going? :)
 99 2011-11-21 09:42:53 <coingenuity> well batouzo :)
100 2011-11-21 09:43:12 <coingenuity> been working on automated shipping all of last week :S
101 2011-11-21 09:43:24 <coingenuity> not very fun, but got it taken care of ;)
102 2011-11-21 09:43:54 <coingenuity> do you have any projects in the works batouzo ?
103 2011-11-21 09:44:04 <batouzo> coingenuity: well lets see
104 2011-11-21 09:44:12 <batouzo> Open Transactions thing for the conference
105 2011-11-21 09:44:51 <coingenuity> cool, glad to see OT is gaining some recognition :D
106 2011-11-21 09:44:56 <coingenuity> lots of projects about it these days
107 2011-11-21 09:46:53 <batouzo> lots of project using OT nowdays?
108 2011-11-21 09:47:51 <coingenuity> yeah, I see a good bit of buzz about it
109 2011-11-21 09:48:22 <coingenuity> what does your OT project do?
110 2011-11-21 09:48:37 <batouzo> yeap. Though I think there are no other yet existing projects actually using OT other then some drafts?
111 2011-11-21 09:48:53 <batouzo> you will find out on friday's conference ;)
112 2011-11-21 09:49:24 <coingenuity> lol, maybe: i dont follow news all that much
113 2011-11-21 09:49:41 <coingenuity> i'll let you keep it to yourself for now :P
114 2011-11-21 09:49:54 <coingenuity> and yep, projects using OT that are beyond draft stages is what i'm referring to lol
115 2011-11-21 09:51:02 <batouzo> cool, do you know of any? Where are they located?
116 2011-11-21 09:51:57 <coingenuity> yeh, gotta keep my mouth shut for now though sorry :(
117 2011-11-21 09:52:05 <coingenuity> i can tell you, europe
118 2011-11-21 09:52:27 <batouzo> you will announce on European conference?
119 2011-11-21 09:52:41 <coingenuity> it's not my project heh
120 2011-11-21 10:36:06 <epscy> aleod | are the devs aware that bitcoin.org is broken?
121 2011-11-21 10:50:12 <sipa> epscy: thanks for reporting - i reverted it
122 2011-11-21 10:50:52 <tcatm> looks like my daily update script failed. I'm going to debug it
123 2011-11-21 10:50:53 <sipa> ;;later tell tcatm seems the jekyll build failed and pushed an empty directory to github
124 2011-11-21 10:50:54 <gribble> The operation succeeded.
125 2011-11-21 10:55:25 <[Tycho]> Finally someone on the forum noticed my TXes :)
126 2011-11-21 10:55:32 <coingenuity> HA
127 2011-11-21 10:55:42 <coingenuity> bullshit [Tycho] people noticed long ago
128 2011-11-21 10:55:59 <[Tycho]> Where ?
129 2011-11-21 10:56:06 <coingenuity> like, hours after you transmitted
130 2011-11-21 10:56:22 <coingenuity> someone posted about it in private :P
131 2011-11-21 10:56:28 <coingenuity> i was loling
132 2011-11-21 10:56:34 <[Tycho]> Why loling ?
133 2011-11-21 10:56:52 <coingenuity> it was something along the lines of "where is this strange TX from??"
134 2011-11-21 10:56:58 <coingenuity> i found it amusing
135 2011-11-21 10:59:48 <[Tycho]> Theymos guessed the salt part, he's smart :)
136 2011-11-21 11:02:13 <coingenuity> ya, i noticed that when i looked at the tx
137 2011-11-21 11:02:27 <coingenuity> hash of anything interesting?
138 2011-11-21 11:07:01 <[Tycho]> No, just a fragment of bitcoind source.
139 2011-11-21 11:07:28 <[Tycho]> Actually in THIS case it's not salt, but was intended to be.
140 2011-11-21 11:07:51 <[Tycho]> I will try to redeem one and see if someone will redeem another.
141 2011-11-21 12:35:20 <[Tycho]> Hello, bitcoin people.
142 2011-11-21 12:52:57 <tcatm> who knows how to setup a dnsseed?
143 2011-11-21 12:54:34 <nanotube> jgarzik and bluematt do :)
144 2011-11-21 12:58:36 <sipa> tcatm: just a DNS seed is easy: have a certain domain name resolve to a bunch of IP addresses
145 2011-11-21 12:59:00 <sipa> but you probably want some setup that automatically populates it with a (subset of) known good nodes on the network
146 2011-11-21 12:59:10 <sipa> i believe bluematt has his setup for that somewhere on github
147 2011-11-21 13:07:08 <gavinandresen> I'm thinking of promoting rc7 to The 0.5.0 Release today.  Anybody see any reason not to?
148 2011-11-21 13:09:20 <eueueue> yes
149 2011-11-21 13:09:38 <eueueue> the popup black on linux on hover transactions
150 2011-11-21 13:10:09 <eueueue> https://github.com/bitcoin/bitcoin/issues/613
151 2011-11-21 13:10:33 <eueueue> the popup should be removed or fixed
152 2011-11-21 13:24:20 <gavinandresen> eueueue: not a show-stopper bug
153 2011-11-21 13:24:37 <eueueue> ok so
154 2011-11-21 13:25:58 <eueueue> gavinandresen: Why not remove this tooltip as doesn't work as expected?
155 2011-11-21 13:26:09 <gavinandresen> Because it does work as expected on most systems.
156 2011-11-21 13:26:22 <eueueue> ok
157 2011-11-21 13:26:23 <riush> what exactly is it supposed to show? ;)
158 2011-11-21 13:29:11 <[Tycho]> What minimum bitcoin version supports checkmultysig ?
159 2011-11-21 13:29:13 <sipa> gavinandresen: are we definitely sure that no wallet-corrupting / exception-causing things occur anymore? i had a few times a corrupted wallet yesterday when testing compact pubkeys (not sure i was using the latest code, though)
160 2011-11-21 13:30:13 <wumpus> eueueue: it works fine for me on all systems
161 2011-11-21 13:31:21 <wumpus> eueueue: I only experienced it once on an old version of qt on windows xp, so that points in the direction of a qt bug
162 2011-11-21 13:31:49 <eueueue> wumpus: I reproduce it on debian wheezy. Devs say is a qt bug. So ok
163 2011-11-21 13:31:53 <gavinandresen> sipa: I'm pretty confident that even if there is an exception-causing thing it will be recoverable, now that we're not removing the datbase/log.* file
164 2011-11-21 13:32:23 <wumpus> eueueue: but if you can isolate it to a ui code bug that's ok too -- just none of the devs has a system capable of reproducing it
165 2011-11-21 13:33:58 <gavinandresen> [Tycho]: all versions of bitcoin support checkmultisig
166 2011-11-21 13:34:13 <gavinandresen> [Tycho]: ... but no versions consider it a 'standard' transaction type
167 2011-11-21 13:35:10 <wumpus> eueueue: the only thing I can think of, if it's ui-code related, is that the painter handle somehow left in a bad state... but it's no release blocker as far as I'm concerned
168 2011-11-21 13:35:53 <[Tycho]> So we just need to allow it in IsStandard ?
169 2011-11-21 13:36:02 <eueueue> wumpus: ok, thanks for explaing. So let the 0.5 be released
170 2011-11-21 13:37:14 <sipa> gavinandresen: i can't reproduce it, so i'll assume it was indeed related to deleting those log files
171 2011-11-21 13:38:22 <gavinandresen> riush eueueue : here's what the popup looks like on my mac:  http://imageshack.us/photo/my-images/833/screenshot20111121at935.jpg/
172 2011-11-21 13:39:02 <wumpus> gavinandresen: huh, it's transparent?
173 2011-11-21 13:39:06 <gavinandresen> yup
174 2011-11-21 13:39:30 <gavinandresen> Isn't it supposed to be?
175 2011-11-21 13:39:40 <wumpus> well it's supposed to be like all the other tooltips
176 2011-11-21 13:39:52 <wumpus> if those are transparent on a mac, it's as it's supposed to be :p
177 2011-11-21 13:40:05 <helo> on my linux machine last week it was showing random parts of my virtualbox windows behind the text heh
178 2011-11-21 13:40:07 <riush> ah
179 2011-11-21 13:40:14 <gavinandresen> The other ones are yellow
180 2011-11-21 13:40:25 <wumpus> in that case it should be yellow
181 2011-11-21 13:40:36 <wumpus> so it seems the background is not getting initialized...
182 2011-11-21 13:40:37 <riush> i think it's supposed to look like the tooltip in the transactions list
183 2011-11-21 13:40:56 <riush> it's been showing random other stuff from my x session too
184 2011-11-21 13:41:24 <wumpus> yes, uninitialized means it can be anything
185 2011-11-21 13:41:27 <gavinandresen> All the rest of the tooltips are yellow boxes
186 2011-11-21 13:41:56 <wumpus> I'll take a look at it soon -- still I don't think it's a release-blocker
187 2011-11-21 13:42:04 <gavinandresen> yes, definitely not a release-blocker
188 2011-11-21 13:42:04 <sipa> it's not
189 2011-11-21 13:43:05 <sipa> gavinandresen: maybe the earlier bug (when deleting the log file), was caused by not creating a new db checkpoint after copying data to the wallet-copy file
190 2011-11-21 13:45:15 <gavinandresen> sipa:  maybe...  I'm not planning on spending more time on that-- I think it would be better to figure out a better approach to encrypted wallets.
191 2011-11-21 13:45:31 <sipa> you mean - moving away from bdb?
192 2011-11-21 13:46:08 <wumpus> or somehow using bdb its own encyption
193 2011-11-21 13:46:16 <gavinandresen> sipa:  not necessarily.  Perhaps multi-wallet support, with operations like 'Create a new, encrypted wallet' and 'Transfer funds from THIS wallet to THAT wallet."
194 2011-11-21 13:46:25 <sipa> gavinandresen: i'd love that
195 2011-11-21 13:46:27 <etotheipi_> gavinandresen, why not just use a manual serialization (this is what I'm planning on doing)... each address has a specific location in the wallet file to be stored, and the private key has exactly 64 bytes to be stored (32 bytes for Priv key, and 32 bytes for IV, if it's encrypted)
196 2011-11-21 13:46:31 <wumpus> multi-wallet support would be nice in any case
197 2011-11-21 13:46:43 <etotheipi_> you manually seek to that part of the file to overwrite the keys
198 2011-11-21 13:46:47 <gavinandresen> The real issue is the old, previously-unencrypted private keys leaking
199 2011-11-21 13:47:30 <etotheipi_> there's no way there can be a leak ... any previously unencrypted keys will be guaranteed to be overwritten by the new encrypted data
200 2011-11-21 13:47:43 <etotheipi_> with the exception of filesystem magic
201 2011-11-21 13:47:54 <wumpus> I don't think going from bdb to a manual database format is better, yes you have more control, but you have more manual sparsely tested code which means morepotential bugs...
202 2011-11-21 13:48:22 <etotheipi_> well, no one suggested it was going to be a trivial change... but I think if you want to be safe, you gotta do it yourself
203 2011-11-21 13:48:45 <sipa> the philosophical question is: does the wallet manage its own wallet(s), and have decent import/export functions to interact with files
204 2011-11-21 13:48:46 <etotheipi_> that was precisely the issue with bdb:  we left the memory/file management to a black-box piece of code, and it did stuff we weren't expecting
205 2011-11-21 13:48:56 <wumpus> I don't think that's neccesarily the case, there might be solutions to privately storing keys already available... with security code, NIY syndrome is very dangerous
206 2011-11-21 13:49:06 <sipa> or are wallets files the user can open/close, with the bitcoin application an 'editor' for those wallets
207 2011-11-21 13:49:06 <wumpus> NIH*
208 2011-11-21 13:49:41 <gavinandresen> What is dangerous is writing unencrypted keys, or assuming that keys that were at one time written unencrypted are still secure
209 2011-11-21 13:49:45 <sipa> it seems bitcoin so far was developed from the first perspective, but people are using it according it to the second
210 2011-11-21 13:49:47 <wumpus> especially as we want the key store to be really, really reliable
211 2011-11-21 13:50:12 <sipa> but bdb does fail - how often do you read about corrupted wallets?
212 2011-11-21 13:50:29 <sipa> that is probably caused by malfunctions like crashes or power loss
213 2011-11-21 13:50:31 <etotheipi_> keys never have to be written unencrypted, but they can be if the user chooses to do so...
214 2011-11-21 13:50:47 <sipa> but still, i don't like bdb too much anymore for such an easy store
215 2011-11-21 13:51:03 <etotheipi_> I think, for data this is so simple as this, manual file management is the way to go
216 2011-11-21 13:51:03 <wumpus> I'm not saying bdb is perfect but at least it's well tested by many users over the years, a self-rolled format will probably have even more issues
217 2011-11-21 13:51:04 <sipa> especially as it is read into memory entirely anyway
218 2011-11-21 13:52:03 <wumpus> but should it be read into memory entirely? or is that just a stop-gap until more scalability is needed?
219 2011-11-21 13:52:20 <sipa> it was clearly designed to be able to not read it in memory
220 2011-11-21 13:52:37 <etotheipi_> the user is never given an address until the key is successfully written to file, and if the file gets a partial-write due to a power failure, you can still read everything that was written up to that point because it's an easy binary format
221 2011-11-21 13:53:04 <etotheipi_> unlike a DB format which might instead lead to a corrupted DB and the problems we have now
222 2011-11-21 13:53:10 <wumpus> if you have a lot of keys, for example on a shop/exchange, it may eventually be nice to be able to not have all keys in memory
223 2011-11-21 13:53:36 <sipa> currently that's not possible anymore, by the way
224 2011-11-21 13:53:42 <etotheipi_> if you have one million keys, you're looking at maybe 100 MB of RAM
225 2011-11-21 13:53:47 <wumpus> and if you go with a hand-rolled format it means you have to write a fully-fledged database,  well good luck with that...
226 2011-11-21 13:53:54 <sipa> the core indexes keys by address, but the wallet file stores it indexed by pubkey
227 2011-11-21 13:54:10 <wumpus> bdb can't support secondary indexes?
228 2011-11-21 13:54:18 <etotheipi_> the entire blockchain is written manually
229 2011-11-21 13:54:18 <gmaxwell> etotheipi_: I was going to point out a million keys too... but you were faster because I was actually adding up the size. :)
230 2011-11-21 13:54:22 <gavinandresen> The only issues I've seen with "corrupted wallets" have actually been blkindex/addr.dat files that wouldn't load.
231 2011-11-21 13:54:41 <sipa> gavinandresen: well, there is a known issue there actually
232 2011-11-21 13:55:05 <sipa> when the best chain is written to the file, but not marked as current best chain
233 2011-11-21 13:55:06 <etotheipi_> we are doing fine with a manually written blk0001.dat file without a database engine behind it
234 2011-11-21 13:55:27 <etotheipi_> are there problems with that getting corrupted?
235 2011-11-21 13:55:33 <wumpus> yes
236 2011-11-21 13:55:55 <gmaxwell> etotheipi_: our use of that is append only, however.
237 2011-11-21 13:56:21 <wumpus> there's an issue about that... if there is a power failure or such during the initial block chain download, bitcoin refuses to start the next time
238 2011-11-21 13:56:28 <wumpus> sometiems
239 2011-11-21 13:56:30 <gavinandresen> And I would much rather figure out a good, automatic backup/disaster-recovery strategy rather than spend a lot of time coming up with Yet Another Scheme for where to put the private keys
240 2011-11-21 13:56:30 <sipa> wumpus: indeed
241 2011-11-21 13:56:32 <etotheipi_> you can make the wallet append-only, too
242 2011-11-21 13:56:43 <wumpus> gavinandresen: +1
243 2011-11-21 13:56:51 <etotheipi_> fair enough...
244 2011-11-21 13:56:51 <helo> does the process to go from an unencrypted wallet to an encrypted wallet involve creating a new private key, and sending all coin from the unencrypted wallet to an address from the new key?
245 2011-11-21 13:56:58 <etotheipi_> I'm on my own with this one, that's fine :)
246 2011-11-21 13:56:59 <gavinandresen> (fixing the power-failure-during-blockchain-download problem should be done also, of course)
247 2011-11-21 13:56:59 <sipa> helo: no
248 2011-11-21 13:57:07 <CryptoX> Crypto X Change API is now ready http://www.cryptoxchange.com/t/cryptoapi
249 2011-11-21 13:57:21 <wumpus> gavinandresen: yes, even if it would be with 're-download the block chain'
250 2011-11-21 13:57:47 <sipa> it's not hard to fix that problem, actually
251 2011-11-21 13:58:08 <sipa> i believe we came up with an easy solution here on IRC, but i don't remember the details
252 2011-11-21 13:58:27 <gavinandresen> if only we had an issue tracker to remember things like that for us.....
253 2011-11-21 13:58:33 <sipa> :D
254 2011-11-21 13:59:30 <wumpus> etotheipi_: hm making the wallet append-only does sound pretty interesting, though it'd mean that you can no longer store mutable metadata (such as the address book) in there
255 2011-11-21 13:59:34 <gavinandresen> Actually, is there an issue about wallet backups?
256 2011-11-21 14:00:45 <etotheipi_> wumpus, my implementation is that the wallet is basically append-only, and the only time you need to go back and change anything is when you change your encryption key
257 2011-11-21 14:01:03 <etotheipi_> it will seek back to every 64-byte private key, and overwrite with the new encrypted key, in place
258 2011-11-21 14:01:22 <etotheipi_> but otherwise, every new piece of data that is added is append-only
259 2011-11-21 14:01:22 <wumpus> etotheipi_: yes there is no reason why that couldn't be a separate file/db, but it means the user would have to back up multiple files
260 2011-11-21 14:01:47 <etotheipi_> wumpus, why?
261 2011-11-21 14:02:05 <wumpus> etotheipi_: because you want to back up your address book/settings as well as the crypto keys ...
262 2011-11-21 14:03:27 <gavinandresen> (there is already an issue about making it easier to backup your wallet: https://github.com/bitcoin/bitcoin/issues/370)
263 2011-11-21 14:04:27 <wumpus> gavinandresen: yes that's a good idea, there should be a file > backup option
264 2011-11-21 14:04:32 <sipa> i've been using my export wallet function for backups
265 2011-11-21 14:04:49 <sipa> i trust a human readable file more than bdb files, actually
266 2011-11-21 14:05:00 <wumpus> it would be the export wallet function, it'd only require some extra UI code
267 2011-11-21 14:05:34 <wumpus> human readable and encrypted do not go together though :p
268 2011-11-21 14:05:57 <sipa> only the secret keys are encrypted :)
269 2011-11-21 14:06:28 <gavinandresen> I think a simple backup wallet.dat function in the GUI would be a great feature for the 0.5.1 release
270 2011-11-21 14:06:29 <wumpus> well the advantage of backing it up in bdb format is that it's easy to restore it
271 2011-11-21 14:06:51 <sipa> true, but it also means that if it is corrupted, you're out of luck
272 2011-11-21 14:06:53 <wumpus> you could export it in json, xml, whatever but it'd require a conversion step also to go back to a wallet.dat
273 2011-11-21 14:07:09 <gavinandresen> Speaking of which.... what features do we think are ready for 0.5.1?   I'd like to get the OP_EVAL internal changes in.
274 2011-11-21 14:07:12 <wumpus> nah some forensics go a long way as etotheipi_ proved :P
275 2011-11-21 14:07:30 <sipa> gavinandresen: i hope key import/export...?
276 2011-11-21 14:07:35 <etotheipi_> :)
277 2011-11-21 14:09:18 <wumpus> ui-wise: caps check for askpassphrasedialog, qrcode generation
278 2011-11-21 14:09:58 <gavinandresen> sipa:  removeprivkey still makes me nervous, but straight import/export seems ok.  Then again wallet encryption seemed ok.....
279 2011-11-21 14:10:20 <gavinandresen> wumpus: ack on both of those
280 2011-11-21 14:10:36 <sipa> gavinandresen: what about i add a check to removeprivkey that it only removes txouts that are fully redeemed, unless a 'force' option is passed along?
281 2011-11-21 14:11:08 <sipa> hmm... that can still interfere with account balances
282 2011-11-21 14:11:16 <gavinandresen> yup
283 2011-11-21 14:11:22 <wumpus> bluematt's browser-url support could also go in ( https://github.com/bitcoin/bitcoin/pull/593 ), but we need to be really sure about this one that it's safe
284 2011-11-21 14:12:50 <sipa> gavinandresen: frankly, i think that a warning text should suffice - RPC users should not be idiots
285 2011-11-21 14:13:50 <wumpus> is there any use in removing private keys?
286 2011-11-21 14:13:59 <riush> or a compile-time flag?
287 2011-11-21 14:14:05 <wumpus> doesn't it open a ton of security issues?
288 2011-11-21 14:14:19 <wumpus> you almost can't be sure you've really purged the key from existence
289 2011-11-21 14:14:37 <wumpus> so it's dangerous in more than one way
290 2011-11-21 14:14:51 <gavinandresen> you almost certainly haven't, there will be copies of it in the wallet.dat and transaction log....
291 2011-11-21 14:15:00 <sipa> but not in your wallet
292 2011-11-21 14:15:15 <wumpus> it's dangerous to rely on it to be secure and it's dangerous for accidental damage
293 2011-11-21 14:15:27 <sipa> use case: creating redeemable vouchers, like bitbills and casascius' coins
294 2011-11-21 14:15:47 <gavinandresen> they can run a patched bitcoind, like they are now.
295 2011-11-21 14:15:50 <wumpus> if you really want to remove keys from your wallet you should rewrite the wallet file, and an external python script could do this better than bitcoin
296 2011-11-21 14:16:15 <sipa> but in fact, those should be done on an off-line computer, using a wallet that never touches internet-connected hardware
297 2011-11-21 14:16:45 <wumpus> yeah let's hope they are ...
298 2011-11-21 14:16:50 <sipa> they are, afaik
299 2011-11-21 14:17:07 <sipa> not having this RPC would force them to use a wallet that is destroyed afterwards
300 2011-11-21 14:17:14 <sipa> and that is probably what should be done anyway
301 2011-11-21 14:17:16 <gavinandresen> yup
302 2011-11-21 14:17:18 <wumpus> sounds good
303 2011-11-21 14:17:19 <wumpus> yeah
304 2011-11-21 14:17:32 <sipa> so, ok, i'll remove removeprivkey from the pull request
305 2011-11-21 14:18:22 <gavinandresen> speaking of private keys in wallets... the wallet should be rewritten when the passphrase changes
306 2011-11-21 14:18:24 <wumpus> great
307 2011-11-21 14:19:00 <wumpus> oh good point otherwise there will be keys left behind encrypted with the old key
308 2011-11-21 14:19:05 <gavinandresen> yup
309 2011-11-21 14:19:30 <gavinandresen> I don't think that is a show-stopper bug, but it should be fixed for 0.5.1
310 2011-11-21 14:19:33 <sipa> that should be easy - just call Rewrite again from the change passphase code?
311 2011-11-21 14:20:04 <wumpus> I guess so, but it'd require a new round of testing, so I agree we can postpone it to 0.5.1
312 2011-11-21 14:20:14 <sipa> agree
313 2011-11-21 14:20:18 <gavinandresen> It'd be nice if it didn't require a client shutdown/restart
314 2011-11-21 14:20:45 <gavinandresen> I'll open an issue...
315 2011-11-21 14:20:45 <sipa> if you can block until all db handles are released, you can stop/start cycle the dbenv
316 2011-11-21 14:20:57 <gmaxwell> but.. wait, how will users with currently screwed up wallets get fixed if it doesn't do this now?
317 2011-11-21 14:21:29 <sipa> gmaxwell: it rewrites upon encryption and on startup on loading a non-rewritten encrypted wallet
318 2011-11-21 14:21:39 <sipa> gmaxwell: but not when changing the passphrase
319 2011-11-21 14:21:43 <luke-jr> gavinandresen: features should be 0.6, not 0.5.1 :P
320 2011-11-21 14:22:01 <gmaxwell> ah, okay, one way to handle the passphrase change would just be setting the non-rewritten encrypted wallet flag.
321 2011-11-21 14:22:20 <sipa> the only thing that can leak when changing the passphrase is the old mkey record, by the way
322 2011-11-21 14:22:25 <sipa> as the keys themselves aren't changed
323 2011-11-21 14:22:37 <gavinandresen> there is no such flag any more-- I change the code to check to see what version wrote the wallet.
324 2011-11-21 14:22:39 <wumpus> ahh the keys are not reencrypted?
325 2011-11-21 14:22:44 <gmaxwell> luke-jr: not leaking old encrypted keying materials.. is a bugfix.
326 2011-11-21 14:23:06 <sipa> wumpus: no, there is a master key record, derived from the passphrase and salt
327 2011-11-21 14:23:24 <sipa> but the master key is generated once, at random
328 2011-11-21 14:23:39 <luke-jr> [10:07:09] <gavinandresen> Speaking of which&. what features do we think are ready for 0.5.1?   I'd like to get the OP_EVAL internal changes in.
329 2011-11-21 14:23:42 <gmaxwell> wumpus: it uses a similar scheme to disk encryption.. encrypt a master key that encrypts the other keys.. so you don't have to do a costly and dangerous operation on change.
330 2011-11-21 14:23:50 <gmaxwell> luke-jr: sorry, I fail at reading.
331 2011-11-21 14:24:06 <wumpus> gmaxwell: yes it makes sense
332 2011-11-21 14:24:15 <sipa> it was inspired by LUKS, indeed :)
333 2011-11-21 14:24:37 <gavinandresen> luke-jr: fine, then: what do we want in the next release?  And are there any major new features that would mean the next release is 0.6 instead of 0.5.1 ?
334 2011-11-21 14:24:57 <luke-jr> [10:06:29] <gavinandresen> I think a simple backup wallet.dat function in the GUI would be a great feature for the 0.5.1 release <-- first, I think backup should have the option to encrypt (everything) builtin :P
335 2011-11-21 14:25:00 <wumpus> yes let's not get caught up in version number politics
336 2011-11-21 14:25:58 <gmaxwell> luke-jr: that would be a good feature... (it should compact the darn thing first too)
337 2011-11-21 14:26:45 <wumpus> nah if you want to encrypt/compact it makes sense to use another export format
338 2011-11-21 14:26:48 <wumpus> exaclty sipa
339 2011-11-21 14:27:18 <luke-jr> [09:24:20] <gavinandresen> eueueue: not a show-stopper bug <-- what's the rush to release 0.5? :P
340 2011-11-21 14:27:27 <[Tycho]> Did someone tried that getmemorypool patch ?
341 2011-11-21 14:27:28 <wumpus> it would need an "import" feature as well, as you can't just copy back the wallet.dat file, but that might be ok (and more user friendly) too
342 2011-11-21 14:27:38 <sipa> wumpus: also exists
343 2011-11-21 14:27:43 <luke-jr> [Tycho]: working fine here.
344 2011-11-21 14:27:50 <luke-jr> [Tycho]: interested in collaborating on my new pool server? :P
345 2011-11-21 14:28:01 <sipa> wumpus: see my showwallet branch
346 2011-11-21 14:28:10 <wumpus> sipa: you can also import the json files?
347 2011-11-21 14:28:13 <sipa> yes
348 2011-11-21 14:28:15 <[Tycho]> luke-jr: does it exports the entire pool or only those TXes that are really going into the next block ?
349 2011-11-21 14:28:22 <sipa> (it doesn't include the actual transactions, it uses rescanning to find those)
350 2011-11-21 14:28:23 <wumpus> what happens if the user already has keys in the wallet and does import?
351 2011-11-21 14:28:28 <luke-jr> [Tycho]: huh?
352 2011-11-21 14:28:35 <sipa> wumpus: works perfectly
353 2011-11-21 14:28:38 <wumpus> good
354 2011-11-21 14:28:39 <[Tycho]> luke-jr: what collaboration do you mean ?
355 2011-11-21 14:28:41 <sipa> you just get a merged wallet
356 2011-11-21 14:28:42 <luke-jr> [Tycho]: oh, getmemorypool just lists tx accepted for the block
357 2011-11-21 14:28:43 <wumpus> so they're merged?
358 2011-11-21 14:28:44 <wumpus> right
359 2011-11-21 14:29:03 <wumpus> what about labels/address book?
360 2011-11-21 14:29:14 <gavinandresen> https://github.com/bitcoin/bitcoin/issues/651
361 2011-11-21 14:29:15 <luke-jr> [Tycho]: I wrote a Python pool server using it; it could use some improvements, so I'm planning to AGPL it
362 2011-11-21 14:29:26 <luke-jr> [Tycho]: http://eligius.st/~luke-jr/.eloipool.git
363 2011-11-21 14:29:32 <sipa> wumpus: it's not really a "Satoshi client wallet dump to json" function, but more a "export to wallet interchange format"
364 2011-11-21 14:29:38 <[Tycho]> Python pool server using what ?
365 2011-11-21 14:29:39 <wumpus> sipa: if that all already works and exists, I suppose we should use your code
366 2011-11-21 14:29:54 <luke-jr> [Tycho]: using getmemorypool
367 2011-11-21 14:30:05 <luke-jr> [Tycho]: it builds the blocks itself
368 2011-11-21 14:30:15 <[Tycho]> Oh, I don't know Python.
369 2011-11-21 14:30:19 <sipa> wumpus: it doesn't include the address book - if you want that, i think you need another export function (i don't consider that part of the wallet)
370 2011-11-21 14:30:26 <wumpus> sipa: well as long as it can represent anything the user can possibly do in satoshi client, it's fine with me
371 2011-11-21 14:30:36 <wumpus> the labels are *really* important
372 2011-11-21 14:31:00 <wumpus> I wouldn't even recognize my own wallet if it didn't have the labels anymore
373 2011-11-21 14:31:05 <sipa> wumpus: https://github.com/bitcoin/bitcoin/pull/220
374 2011-11-21 14:31:09 <sipa> it supports labels
375 2011-11-21 14:31:14 <[Tycho]> I think I should create a new client...
376 2011-11-21 14:31:20 <luke-jr> [Tycho]: it's not that complicated ;p
377 2011-11-21 14:31:33 <wumpus> oh no ,not another client, just work on improving one of the existing ones
378 2011-11-21 14:31:52 <[Tycho]> There are no existing ones except for gavin's
379 2011-11-21 14:32:09 <[Tycho]> Also there is still no light clients.
380 2011-11-21 14:32:13 <sipa> there are many projects underway that are creating new ones
381 2011-11-21 14:32:16 <wumpus> sipa: so I think we should add the address book in the file as well.. doesn't hurt if it's an interchange formats, clients can just ignore that part if they don't care
382 2011-11-21 14:32:45 <luke-jr> [Tycho]: for pool purposes, my Python poolserver mostly replaces bitcoind
383 2011-11-21 14:32:49 <sipa> wumpus: if we go that way, maybe it should contain the transactions themselves too
384 2011-11-21 14:33:00 <sipa> (at least optionally)
385 2011-11-21 14:33:05 <wumpus> sipa: maybe.. but all user-entered stuff should be in there
386 2011-11-21 14:33:09 <wumpus> that's what a backup is for :-)
387 2011-11-21 14:33:23 <sipa> well, it wasn't really intended as backup (though that is how i use it myself)
388 2011-11-21 14:33:36 <wumpus> well it's a good starting point
389 2011-11-21 14:33:42 <wumpus> we can make it into a backup solution
390 2011-11-21 14:33:45 <[Tycho]> luke-jr: why your generation TX sends most outputs do addresses and just one output to pubkey ?
391 2011-11-21 14:33:47 <sipa> true
392 2011-11-21 14:33:51 <[Tycho]> *to
393 2011-11-21 14:34:09 <luke-jr> gavinandresen: if there's still bugs in 0.5, how about I tag 0.4.1 and you guys can take your time on making 0.5 stable?
394 2011-11-21 14:34:28 <luke-jr> [Tycho]: because I only have addresses for miners
395 2011-11-21 14:34:37 <gavinandresen> luke-jr: what bugs?
396 2011-11-21 14:34:46 <luke-jr> gavinandresen: the black box tooltip, for example
397 2011-11-21 14:34:58 <[Tycho]> luke-jr: that one pubkey is for your pool fees ?
398 2011-11-21 14:35:25 <gavinandresen> luke-jr: we will never have another release if we hold up the release for every "things don't look perfect on every platform" bug.
399 2011-11-21 14:35:34 <luke-jr> [Tycho]: no, for reward that has no pending payout
400 2011-11-21 14:35:36 <gavinandresen> ... and I'm tired of spinning release candidates.
401 2011-11-21 14:35:52 <luke-jr> gavinandresen: unusable black box != imperfect
402 2011-11-21 14:36:27 <luke-jr> wumpus: any leads on that bug btw?
403 2011-11-21 14:37:32 <[Tycho]> How the Old Ones knew the pubkey for their destination ? Or it's sending to self ? http://blockexplorer.com/tx/150e5423ef17f319edcebb2a2e9e1c9dff8313b21cdc1c14bfc6da19e09869db
404 2011-11-21 14:38:42 <luke-jr> [Tycho]: first output is always "self"
405 2011-11-21 14:38:45 <wumpus> sipa: I do agree that in a pure sense, the address book (and program configuration) is not part of a wallet.. it's going to bite us a bit when implementing multi-wallet support
406 2011-11-21 14:39:04 <wumpus> luke-jr: scroll back a bit, that's all I know about it
407 2011-11-21 14:39:23 <[Tycho]> luke-jr: I don't think so.
408 2011-11-21 14:39:34 <[Tycho]> Look at the link.
409 2011-11-21 14:40:24 <wumpus> sipa: if you have two wallets open, do they share address book? if so, where is it stored? etc
410 2011-11-21 14:40:34 <sipa> wumpus: good questions
411 2011-11-21 14:40:52 <sipa> having wallet-specifiek address books is definitely easier
412 2011-11-21 14:41:06 <wumpus> yes I think that's fine actually
413 2011-11-21 14:41:12 <sipa> but that will probably mean a "copy address book from X to Y" function in the GUI
414 2011-11-21 14:41:20 <wumpus> and allow drag and drop to copy contacts between wallets
415 2011-11-21 14:41:41 <sipa> that'd be very nice
416 2011-11-21 14:41:50 <wumpus> ok, so the address book *is* part of the wallet, nice to clear that up...
417 2011-11-21 14:41:58 <wumpus> I've wondered about that before
418 2011-11-21 14:42:26 <wumpus> that leaves program configuration
419 2011-11-21 14:42:36 <wumpus> that should be in a separate file probably
420 2011-11-21 14:42:44 <sipa> yes, i agree
421 2011-11-21 14:43:10 <wumpus> it's also not really important to backup that :-)
422 2011-11-21 14:43:18 <[Tycho]> wumpus: what is your project ?
423 2011-11-21 14:43:34 <wumpus> [Tycho]: bitcoin-qt
424 2011-11-21 14:45:59 <wumpus> luke-jr: I agree the black box should be solved, but we should be realistic as to our priorities
425 2011-11-21 14:46:39 <wumpus> luke-jr: if we worry about small license changes, icons, and little rendering issues all day we'll get nowhere
426 2011-11-21 14:47:11 <wumpus> at least with the limited development resources we have now...
427 2011-11-21 14:47:31 <luke-jr> wumpus: afaik the bigger issue is solved
428 2011-11-21 14:47:52 <wumpus> yep
429 2011-11-21 14:48:23 <wumpus> but hopefully you get my point, I'm not saying they are unimportant or such, but we shouldn't get caught up in them and let them determine the release schedule
430 2011-11-21 14:48:25 <[Tycho]> luke-jr: what "first" output ? There is only one in that TX
431 2011-11-21 14:49:10 <[Tycho]> And it's not a generation.
432 2011-11-21 14:51:29 <luke-jr> [Tycho]: oh, then I don't know what it has to do with me
433 2011-11-21 14:52:12 <[Tycho]> The initial question wasn't addresses to you :)
434 2011-11-21 14:52:15 <luke-jr> o
435 2011-11-21 14:53:00 <luke-jr> wumpus: btw, you're both "John Smith" and Wladimir, right?
436 2011-11-21 14:53:04 <[Tycho]> I just asked where they get that pubkey ? And if the "official" client was sending TXes to pubkeys before - why did it stopped doing this now ?
437 2011-11-21 14:53:44 <luke-jr> [Tycho]: it's probably "change". and probably uses an address now to make it harder to identify which one is change
438 2011-11-21 14:54:10 <sipa> [Tycho]: the official client only sends to pubkeys for generations and (earlier) for send-to-IP
439 2011-11-21 14:54:26 <[Tycho]> Oh, so it was possibly send-to-IP !
440 2011-11-21 14:54:30 <[Tycho]> Mystery solved.
441 2011-11-21 15:03:43 <wumpus> luke-jr: I'm known by many names :-)
442 2011-11-21 15:04:22 <sipa> wumpus: so, nice project for 0.6.0: multi-wallet support :)
443 2011-11-21 15:05:21 <wumpus> sipa: yes I think we should keep that for a major release, though the basic support is already there, it probably has a lot of unexpected corner cases
444 2011-11-21 15:06:07 <luke-jr> ie, once 0.5.0 is done, we have quite a few features ready to merge for 0.6
445 2011-11-21 15:06:27 <sipa> we need something like a linux-next repo
446 2011-11-21 15:06:29 <luke-jr> so 0.6rc1 could probably be literally a week after 0.5.0 is out
447 2011-11-21 15:06:40 <wumpus> yes I think that's the case, my bitcoin-qt branch already contains some ui improvements for testing
448 2011-11-21 15:09:23 <luke-jr> fwiw, setting QT_X11_NO_MITSHM=1 makes that black box sometimes greenish
449 2011-11-21 15:09:33 <luke-jr> why are those different from every other tooltip?
450 2011-11-21 15:10:05 <luke-jr> wumpus: what version of Qt does it work right on?
451 2011-11-21 15:10:37 <wumpus> the tooltip is the same as any other tooltip
452 2011-11-21 15:10:51 <wumpus> it's  rendered by qt, not by custom code
453 2011-11-21 15:11:10 <luke-jr> every other tooltip works&
454 2011-11-21 15:11:15 <luke-jr> where is the code for that tooltip?
455 2011-11-21 15:11:25 <luke-jr> I couldn't find it (though I could find every other one on that page)
456 2011-11-21 15:11:59 <wumpus> overviewpage.cpp contains the rendering delegate for the transactions onthe overview page
457 2011-11-21 15:12:17 <luke-jr> but not the tooltip&
458 2011-11-21 15:12:29 <wumpus> that's what I said
459 2011-11-21 15:12:44 <luke-jr> so where is the tooltip? :P
460 2011-11-21 15:12:44 <wumpus> there is no code for rendering that tooltip
461 2011-11-21 15:12:58 <luke-jr> the tooltip content has to be assigned *somewhere*
462 2011-11-21 15:13:01 <wumpus> it simply uses the qt item view
463 2011-11-21 15:13:07 <wumpus> yes the content comes from the model
464 2011-11-21 15:13:18 <luke-jr> doesn't the Transactions page use the qt item view?
465 2011-11-21 15:13:27 <wumpus> the same tooltip content is used in the transactions page
466 2011-11-21 15:13:28 <wumpus> yes
467 2011-11-21 15:13:56 <luke-jr> wumpus: any idea if I can pass Qt command line options to bitcoin-qt?
468 2011-11-21 15:14:05 <wumpus> qt calls data() on the model with TooltipRole
469 2011-11-21 15:14:18 <wumpus> yes you should be able to
470 2011-11-21 15:14:27 <wumpus> qt gets first shot at the command line arguments
471 2011-11-21 15:16:35 <luke-jr> hmm
472 2011-11-21 15:16:42 <wumpus> but yeah it must be some rendering operation *before* the tooltip drawing that messes up the painter state
473 2011-11-21 15:17:30 <wumpus> but txviewdelegate::paint does save and restore the painter state properly, so I don't see the problem
474 2011-11-21 15:18:59 <wumpus> if you have a system that experiences the issue you could use shotgun debugging on the paint() function (ie, comment out lines to see if the problem goes away)
475 2011-11-21 15:23:35 <luke-jr> something is forcing the tooltip bg to black
476 2011-11-21 15:25:07 <wumpus> not neccesarily black, it makes that the tooltip background is not initialized
477 2011-11-21 15:25:24 <wumpus> which means transparent on mac, and black on linux sometimes and sometimes random buffer patterns
478 2011-11-21 15:26:43 <wumpus> I think if there is a bug it can be only in TxViewDelegate::paint.. it's the only place bitcoin-qt uses manual rendering
479 2011-11-21 15:28:32 <wumpus> if there is no bug in there it must be a qt issue
480 2011-11-21 15:29:12 <wumpus> (ie, tooltip does not draw succesfully with a custom delegate on certain version of qt)
481 2011-11-21 15:30:20 <gavinandresen> Pushed  * [new tag]         v0.5.0 -> v0.5.0  And uploaded binaries to https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/
482 2011-11-21 15:31:09 <gavinandresen> I'm going to eat lunch, then, assuming I don't come back to anybody besides luke telling me I'm an idiot, continue with release process....
483 2011-11-21 15:32:25 <gavinandresen> ... hmm, no, changed my mind, I'll upload binaries to 0.4.1 while I'm eating lunch
484 2011-11-21 15:33:14 <BlueMatt> gavinandresen: so 0.5 is out
485 2011-11-21 15:33:19 <BlueMatt> ?
486 2011-11-21 15:33:24 <sipa> 17:30:31 < gavinandresen> Pushed  * [new tag]         v0.5.0 -> v0.5.0  And uploaded binaries to https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/
487 2011-11-21 15:33:30 <BlueMatt> mmm
488 2011-11-21 15:34:17 <gavinandresen> I'm saying it is enough better than 0.4.0 to release.
489 2011-11-21 15:34:22 <luke-jr> wumpus: no, pretty sure it's black
490 2011-11-21 15:34:45 <wumpus> luke-jr: for gavinandresen it is transparent, scroll back a bit he posted a screenshot...
491 2011-11-21 15:34:56 <BlueMatt> gavinandresen: mmm, not sure about that as a measurement for release of financial software, but mehj
492 2011-11-21 15:35:00 <luke-jr> hmm
493 2011-11-21 15:35:16 <gavinandresen> BlueMatt: any show-stopper issues on your list?
494 2011-11-21 15:35:16 <luke-jr> gavinandresen: why am I wasting time trying to help fix this when you're just going to ignore bugs?
495 2011-11-21 15:35:28 <BlueMatt> gavinandresen: not really
496 2011-11-21 15:35:28 <gavinandresen> luke-jr: what bugs?
497 2011-11-21 15:35:34 <helo> i get the same behavior (apparent uninitialized pixmaps) with flash plugins in chrome
498 2011-11-21 15:35:42 <luke-jr> gavinandresen: tooltips being totally broken on the overview
499 2011-11-21 15:36:06 <helo> i would not at all be surprised if it is an upstream (library) bug
500 2011-11-21 15:36:10 <BlueMatt> gavinandresen: I would like to have seen the tooltips thing and the about menu copyright text updated, but I suppose neither are too terrible
501 2011-11-21 15:36:10 <wumpus> meh, if you want to see the tooltip so bad go to the transaction page it shows the same tooltip...
502 2011-11-21 15:36:14 <gavinandresen> first, they're not totally broken (they're transparent on my machine, I believe they work fine on PCs).  ANd second, it is not being ignored
503 2011-11-21 15:36:15 <luke-jr> wumpus: I commented out TxViewDelegate::paint's code, and it still happens
504 2011-11-21 15:36:25 <helo> luke-jr: are you using compiz?
505 2011-11-21 15:36:29 <luke-jr> helo: no
506 2011-11-21 15:36:33 <helo> i am not either :)
507 2011-11-21 15:36:40 <helo> i bet it works properly with copmiz
508 2011-11-21 15:36:46 <luke-jr> gavinandresen: doesn't work fine on my PC
509 2011-11-21 15:36:58 <luke-jr> helo: what DE?
510 2011-11-21 15:37:01 <helo> fluxbox
511 2011-11-21 15:37:09 <luke-jr> helo: what Qt ver?
512 2011-11-21 15:37:12 <gavinandresen> luke-jr: good to know.  what version of windows?
513 2011-11-21 15:37:19 <luke-jr> gavinandresen: I don't use Windows.
514 2011-11-21 15:37:37 <wumpus> helo: I wouldn't be surprised if it was an upstream issue either
515 2011-11-21 15:37:44 <sipa> he obviously means "what version of XWindows" !
516 2011-11-21 15:37:55 <wumpus> luke-jr: if it still happens with the paint method commented out, then it can't be an issue in the drawing code
517 2011-11-21 15:38:00 <gavinandresen> luke-jr:         so when I say PC I mean Windows, old habit, hard to break.....
518 2011-11-21 15:38:07 <wumpus> luke-jr: except if the paint code should do something it currently does not
519 2011-11-21 15:38:10 <sipa> sure starts to sound like an upstream issue
520 2011-11-21 15:38:43 <wumpus> luke-jr: but abstractitemdelegate is an abstract class -- so it can't really call the parent class paint method
521 2011-11-21 15:38:45 <gavinandresen> luke-jr:       and you're SO CLOSE to going on my ignore list... are you TRYING to push my buttons?
522 2011-11-21 15:39:18 <helo> libQtCore.so.4.7.4
523 2011-11-21 15:39:31 <wumpus> and afaik item delegates have nothing to do with tooltip drawing
524 2011-11-21 15:39:59 <luke-jr> gavinandresen: no, you are. why would I be wasting my time on trying to get this fixed, if not for 0.5.0?
525 2011-11-21 15:40:06 <helo> also, 64-bit
526 2011-11-21 15:40:11 <luke-jr> otherwise I could just ignore the bug and let someone else fix it in due time
527 2011-11-21 15:40:12 <wumpus> I'm not *completely* sure about that though
528 2011-11-21 15:40:57 <helo> has anyone seen the bug not running linux, 64-bit, non-compiz?
529 2011-11-21 15:41:06 <luke-jr> it's like if you're carefully trying to fix up a house and the city came along and condemned it and said you had to tear it all down
530 2011-11-21 15:41:49 <helo> it is a platform-specific cosmetic bug at worst
531 2011-11-21 15:42:13 <wumpus> you could safely ignore the bug if you want to or help fixing it, either way it's up to you
532 2011-11-21 15:42:18 <luke-jr> no reason to rush 0.5.0 out the door
533 2011-11-21 15:42:19 <wumpus> I don't see what the release schedule has to do with it
534 2011-11-21 15:42:40 <luke-jr> .0 should be "no known bugs"
535 2011-11-21 15:42:59 <wumpus> this is really starting to annoy me
536 2011-11-21 15:43:02 <helo> 0.5.0 includes important bug fixes as-is, so why delay their dissemination because of a non-important bug?
537 2011-11-21 15:43:13 <luke-jr> helo: those important bug fixes are in 0.4.1
538 2011-11-21 15:43:26 <wumpus> it's a fricking tooltip
539 2011-11-21 15:43:50 <luke-jr> whatever, arguing about it is wasting more time than fixing it
540 2011-11-21 15:43:58 <wumpus> well then fix it
541 2011-11-21 15:43:59 <helo> heh
542 2011-11-21 15:44:01 <wumpus> if you think it's so simple
543 2011-11-21 15:44:18 <BlueMatt> how about someone fix it, then we can get 5.1 out the door in like a day, and everyone will be happy?
544 2011-11-21 15:44:22 <wumpus> I think we just ran out of possible options to fix it in the scope of bitcoin-qt
545 2011-11-21 15:44:42 <BlueMatt> then file it upstream and stop complaining
546 2011-11-21 15:44:50 <BlueMatt> or fix it, either way stop complaining
547 2011-11-21 15:45:01 <wumpus> I'm not complaining
548 2011-11-21 15:45:59 <Lolcust> !seen batouzo
549 2011-11-21 15:46:00 <gribble> batouzo was last seen in #bitcoin-dev 5 hours, 53 minutes, and 31 seconds ago: <batouzo> you will announce on European conference?
550 2011-11-21 15:46:00 <spaola> batouzo (~batouzo@ip-1-141.gemini.net.pl) was last seen quitting from #bitcoin-dev 5 hours, 43 minutes ago stating (Read error: Operation timed out).
551 2011-11-21 15:46:20 <BlueMatt> why do we have two bots that have the same control sequence, nanotube?
552 2011-11-21 15:47:50 <Lolcust> Redundancy is so redundant
553 2011-11-21 15:48:05 <sipa> :D
554 2011-11-21 15:51:52 <jgarzik> tcatm: yep, if you need any DNS seed details, just ask.  we need more!
555 2011-11-21 15:53:10 <[Tycho]> Lolcust: what is your project ?
556 2011-11-21 15:53:45 <wumpus> luke-jr: QAbstractItemDelegate::helpEvent  is where the tooltip code is, see http://www.koders.com/cpp/fid3DD68FEBC0C9B981592059BA2C6FAC8066F32DAD.aspx?s=mdef%3Atree    ... so it inherits that code and draws the tooltip using QToolTip::showTex
557 2011-11-21 15:53:48 <cocktopus> jgarzik: what sort of system requirements are necessary for a decent dnsseed (besides good connectivity and uptime of course)?
558 2011-11-21 15:55:16 <wumpus> luke-jr: but as I understand it, it should not be needed to override that unless you want to change the behaviour
559 2011-11-21 15:56:13 <BlueMatt> cocktopus: nearly nothing
560 2011-11-21 15:56:28 <BlueMatt> jgarzik: did you ever write that cleaner dnsseed software?
561 2011-11-21 15:56:47 <BlueMatt> cocktopus: maybe like ~256M ram and good connectivity
562 2011-11-21 15:56:56 <cocktopus> sounds cool
563 2011-11-21 15:57:18 <BlueMatt> and plenty of community trust (as there are some theoretical attacks by dnsseed controllers)
564 2011-11-21 15:57:35 <cocktopus> i've been considering putting one up, but it sounds like it could be subject to ddos
565 2011-11-21 15:57:40 <cocktopus> which isnt fun
566 2011-11-21 15:57:53 <BlueMatt> I havent seen any ddos on mine (afaik)
567 2011-11-21 15:57:58 <[Tycho]> BlueMatt: what is your project ?
568 2011-11-21 15:58:05 <BlueMatt> my project?
569 2011-11-21 15:58:15 <[Tycho]> Yes. Do you have any ?
570 2011-11-21 15:58:27 <BlueMatt> any projects? I suppose not...
571 2011-11-21 15:58:35 <wumpus> cocktopus: yes it would probably be best to a vps with a limited bandwidth/month that cuts off after that
572 2011-11-21 15:59:05 <BlueMatt> no, if it cuts off you should be able to forward the dns first so that you dont have downtime...
573 2011-11-21 15:59:17 <wumpus> otherwise I guess a ddos could be really expensive
574 2011-11-21 15:59:25 <BlueMatt> gavinandresen: when you do the release announce of 0.5, please do mention the ubuntu ppa
575 2011-11-21 15:59:45 <wumpus> BlueMatt: so it's not robust against one of the dnsseeds going down?
576 2011-11-21 16:00:01 <gavinandresen> BlueMatt: tell me again what I should say?  I don't think you sent me email last time....
577 2011-11-21 16:00:34 <luke-jr> this doesn't make sense :/
578 2011-11-21 16:00:45 <luke-jr> I got rid of TxViewDelegate entirely, and it still breaks
579 2011-11-21 16:00:48 <wumpus> luke-jr: don't say I didn't tell you so :-)
580 2011-11-21 16:01:03 <BlueMatt> gavinandresen: might have forgotten, just say something to the effect of "For Ubuntu users, there is a new ppa which you can add to your system so that it will automatically keep bitcoin up-to-date.  Just type "sudo apt-add-repository ppa:bitcoin/bitcoin" in your terminal, then install the bitcoin-qt package."
581 2011-11-21 16:01:17 <luke-jr> wumpus: well, it has to be *something* in Bitcoin-Qt, or else it wouldn't work in the transaction list either& :/
582 2011-11-21 16:01:17 <wumpus> luke-jr: so it happens even with the default delegate?
583 2011-11-21 16:01:22 <luke-jr> wumpus: yes
584 2011-11-21 16:01:32 <wumpus> hmm...
585 2011-11-21 16:01:44 <sipa> does valgrind find any uninitialized memory?
586 2011-11-21 16:01:48 <BlueMatt> wumpus: it is, but there is currently a bug by which bitcoin will delay opening until it gets a response from all of the dnsseeds built-in, also its generally better just to be up
587 2011-11-21 16:01:56 <gavinandresen> BlueMatt: "new ppa maintained by Matt Corallo..."  ?  I want to be very careful about letting people know who is responsible for what
588 2011-11-21 16:02:04 <BlueMatt> gavinandresen: yes, absolutely
589 2011-11-21 16:02:05 <wumpus> BlueMatt: ooh :(
590 2011-11-21 16:02:35 <sipa> is there a ticket for that already?
591 2011-11-21 16:02:43 <sipa> dns seeding should go to a separate thread
592 2011-11-21 16:02:49 <wumpus> luke-jr: the transaction list is a table view, not a item list view, that's the only difference I can think of
593 2011-11-21 16:03:13 <BlueMatt> sipa: dont think there is a ticket, but it was discussed briefly here
594 2011-11-21 16:03:25 <sipa> if not, make sure we have one, so it isn't forgotten
595 2011-11-21 16:03:42 <BlueMatt> sipa: and yea, it really shouldnt be in AppInit2, should take like 20 secs to whip up a  fix
596 2011-11-21 16:03:54 <wumpus> that explains why a while ago bitcoin wouldn't start here, appearantly waiting for reply from my router...
597 2011-11-21 16:04:18 <sipa> dnsseed could also re-run every few hours or so
598 2011-11-21 16:04:23 <luke-jr> wumpus: making it a table yields very curious output
599 2011-11-21 16:04:26 <wumpus> which cost me a few hours because I thought it was a problem in my gitian build process :')
600 2011-11-21 16:04:41 <luke-jr> wumpus: the headings are ALSO black on black
601 2011-11-21 16:04:43 <BlueMatt> sipa: meh, its a bootstrap mechanism, relying too heavily on it to stay connected to the network isnt so good imho
602 2011-11-21 16:04:50 <sipa> BlueMatt: agree
603 2011-11-21 16:05:04 <sipa> the network is better for remaining connected
604 2011-11-21 16:05:14 <wumpus> yep it starts with 0 connections anyway
605 2011-11-21 16:05:22 <wumpus> luke-jr: curious
606 2011-11-21 16:06:30 <luke-jr> wumpus: is there no .ui for the txn list? :/
607 2011-11-21 16:08:11 <wumpus> luke-jr: there isn't, all the code is in transactionview.cpp
608 2011-11-21 16:08:16 <luke-jr> i c
609 2011-11-21 16:08:34 <wumpus> there is very little there that could be initialized from a form file
610 2011-11-21 16:10:56 <luke-jr> AHAHAHAHA
611 2011-11-21 16:10:58 <luke-jr> OMG
612 2011-11-21 16:11:15 <wumpus> uh oh, luke-jr has gone mad :)
613 2011-11-21 16:11:16 <luke-jr> ui->listTransactions->setStyleSheet("background:transparent");
614 2011-11-21 16:11:30 <luke-jr> there's the culprit
615 2011-11-21 16:11:34 <wumpus> LOL
616 2011-11-21 16:11:41 <wumpus> wtf
617 2011-11-21 16:11:56 <wumpus> why does that apply to the tooltip
618 2011-11-21 16:11:59 <luke-jr> nfc
619 2011-11-21 16:12:30 <sipa> near field communication?
620 2011-11-21 16:12:30 <wumpus> if you comment out that line the background will be white instead of window-background-grey...
621 2011-11-21 16:12:47 <wumpus> (the background of the list itself)
622 2011-11-21 16:12:58 <sipa> maybe it inherits that style setting, and you need to re-set it on the tooltip itself?
623 2011-11-21 16:13:03 <wumpus> stylesheet for the list shouldn't affect the tooltip  :/
624 2011-11-21 16:13:49 <wumpus> hm I don't think you can set it on the tooltip yourself, QTooltip::showText handles all that
625 2011-11-21 16:14:31 <wumpus> but maybe there is some other option to tell the list to not draw a white background, apart from a stylesheet
626 2011-11-21 16:14:59 <wumpus> (or you could cheat and make it draw a background in the same color as the window background)
627 2011-11-21 16:16:02 <wumpus> (though that will mess up with kde which has gradient window backgrounds)
628 2011-11-21 16:17:24 <luke-jr> I found a cheat.
629 2011-11-21 16:17:30 <gavinandresen> 0.5.0 announced:  https://bitcointalk.org/index.php?topic=52480
630 2011-11-21 16:17:40 <luke-jr> gavinandresen: too bad we just fixed the last bug in it, eh?
631 2011-11-21 16:17:48 <wumpus> it's not the last bug
632 2011-11-21 16:17:54 <gavinandresen> "last bug" ?  Have you seen the issues list?
633 2011-11-21 16:18:04 <wumpus> the good thing is that we understand it now
634 2011-11-21 16:18:07 <wumpus> thanks luke-jr
635 2011-11-21 16:18:36 <wumpus> at least we can scrap scary pointer or unititalized memory issues as a cause
636 2011-11-21 16:18:59 <luke-jr> https://github.com/bitcoin/bitcoin/pull/653
637 2011-11-21 16:19:12 <gavinandresen> Who'd I forget on the "Thanks" list?  gmaxwell did a bunch of testing....
638 2011-11-21 16:19:34 <wumpus> hah nice fix luke-jr
639 2011-11-21 16:20:04 <luke-jr> gavinandresen: btw, did you ever get the translators to update the "restart bitcoin" message?
640 2011-11-21 16:20:16 <jgarzik> BlueMatt: nope
641 2011-11-21 16:20:19 <gavinandresen> luke-jr: nope
642 2011-11-21 16:20:33 <jgarzik> BlueMatt: that's why I was open to checking your example code into contrib/
643 2011-11-21 16:20:34 <luke-jr> oh well
644 2011-11-21 16:20:39 <CIA-89> bitcoin: Luke Dashjr master * ra3c675d / src/qt/overviewpage.cpp : Bugfix: only make QListView transparent, not its tooltips - http://git.io/xbEJFQ
645 2011-11-21 16:20:43 <CIA-89> bitcoin: Wladimir J. van der Laan master * rfe90327 / src/qt/overviewpage.cpp :
646 2011-11-21 16:20:45 <luke-jr> yet another thing that 0.5.0 should have waited for
647 2011-11-21 16:21:06 <CIA-89> bitcoin: various bugfix_transparent_tooltip * ra3c675..dead0f bitcoind-personal/ (33 files in 7 dirs): (22 commits)
648 2011-11-21 16:21:07 <sipa> hindsight is 20/20
649 2011-11-21 16:21:14 <wumpus> "should have" hehe
650 2011-11-21 16:21:45 <luke-jr> guess I should tag 0.4.1
651 2011-11-21 16:22:12 <gavinandresen> luke-jr: 0.4.1 sourceforge binaries are up
652 2011-11-21 16:22:19 <luke-jr> k
653 2011-11-21 16:22:21 <gavinandresen> (same binaries as rc7)
654 2011-11-21 16:22:21 <luke-jr> ty
655 2011-11-21 16:22:27 <luke-jr> how about source tarballs?
656 2011-11-21 16:22:32 <luke-jr> or are we sticking with autogenerated now?
657 2011-11-21 16:22:57 <gavinandresen> Is there a good reason to do it manually when github does it automagically?
658 2011-11-21 16:22:59 <wumpus> yeah you could just link to the autogenerated one from github
659 2011-11-21 16:23:32 <luke-jr> gavinandresen: GitHub makes weird directory names.
660 2011-11-21 16:23:35 <wumpus> no reason I think, except if you want to add some otherwise autogenerated files for convenience of the builder (but as we have no autoconf/automake system I doubht we need that)
661 2011-11-21 16:23:39 <BlueMatt> jgarzik: ahh, well I havent updated that code in a long time, but if someone feels like cleaning it up and making it easy to read, I wouldnt mind it being checked in either...
662 2011-11-21 16:25:07 <luke-jr> gavinandresen: GitHub names it bitcoin-bitcoin-f5649b6 instead of bitcoin-0.5.0
663 2011-11-21 16:25:18 <luke-jr> it also doesn't give it a filename
664 2011-11-21 16:25:31 <wumpus> btw BlueMatt what is 'expat'?
665 2011-11-21 16:25:56 <BlueMatt> wumpus: expat is mit, but a different name for it that debian appears to prefer...
666 2011-11-21 16:25:58 <BlueMatt> go figure
667 2011-11-21 16:26:02 <wumpus> hmm
668 2011-11-21 16:26:54 <wumpus> ahh expat is an xml parser
669 2011-11-21 16:27:31 <wumpus> thought the name was really strange :-) but yeah it's ok with me to rename the license to that
670 2011-11-21 16:28:51 <BlueMatt> sipa: how about this instead of a ticket: https://github.com/bitcoin/bitcoin/pull/654
671 2011-11-21 16:29:10 <sipa> o/
672 2011-11-21 16:29:56 <wumpus> lol
673 2011-11-21 16:32:14 <diki> My program so far
674 2011-11-21 16:35:23 <luke-jr> wtf wasn't this in 0.5.0? >_< https://github.com/bitcoin/bitcoin/pull/652
675 2011-11-21 16:35:52 <BlueMatt> luke-jr: because it was pull-requested after 0.5 was tagged?
676 2011-11-21 16:35:58 <luke-jr> it was?
677 2011-11-21 16:36:01 <luke-jr> oh well
678 2011-11-21 16:36:08 <luke-jr> maybe we really should have 0.5.1 today :p
679 2011-11-21 16:36:18 <BlueMatt> luke-jr: and because updating the debian changelog to indicate a release technically has to come after the release, so...
680 2011-11-21 16:37:02 <BlueMatt> dig #653 fix the tooltip issues?
681 2011-11-21 16:37:17 <luke-jr> yes
682 2011-11-21 16:37:36 <gavinandresen> tcatm: Can you update the bitcoin.org homepage to link to 0.5.0 binaries?   I updated the wiki, sourceforge, and forums....
683 2011-11-21 16:39:20 <gavinandresen> RE: 0.5.1 :  minor releases more often is OK with me, but it is a significant amount of effort to compile all the releases, upload them, write release notes, update the wiki/forum/homepage......
684 2011-11-21 16:40:01 <BlueMatt> gavinandresen: I was half-joking but if we end up with 2 minor bug fixes that are user-facing, Im not against it
685 2011-11-21 16:40:24 <CIA-89> bitcoin: Luke Dashjr maintree * r3d5fccff407e gentoo/net-p2p/ (8 files in 2 dirs): Merge branch 'master' into maintree
686 2011-11-21 16:40:26 <luke-jr> (which is why 0.5.0 would have been better off waiting slightly longer for some easy-but-important fixes)
687 2011-11-21 16:40:50 <gavinandresen> BlueMatt: after I follow the "release gitian-signed gitian archives" instructions in doc/release-process.txt, do I need to commit something to the gitian-sigs tree?
688 2011-11-21 16:41:37 <BlueMatt> gavinandresen: yes
689 2011-11-21 16:41:56 <BlueMatt> gavinandresen: iirc it should set up the files in the git tree properly, you should have to just git add the ones for you and git commit, push
690 2011-11-21 16:42:21 <gavinandresen> BlueMatt: can you update release-process.txt to tell me (in small words :-) which ones to git add?
691 2011-11-21 16:43:16 <luke-jr> gavinandresen: when master starts merging 0.6 features, is coinbaser on the table?
692 2011-11-21 16:43:28 <luke-jr> it happens to still merge cleanly
693 2011-11-21 16:43:56 <gavinandresen> luke-jr: if I recall correctly, there was some controversy over part of coinbaser
694 2011-11-21 16:44:22 <luke-jr> I don't recall that. Just that it wasn't merged for 0.5.
695 2011-11-21 16:45:07 <gavinandresen> https://bitcointalk.org/index.php?topic=46927.msg559622#msg559622
696 2011-11-21 16:46:59 <BlueMatt> gavinandresen: should be something to the effect of 0.5.0/gavinandresen/*
697 2011-11-21 16:47:27 <luke-jr> gavinandresen: as it ended, the only remaining "complaint" was that perhaps we ought to have it limit what you're allowed to do with it
698 2011-11-21 16:47:38 <gavinandresen> BlueMatt: thanks
699 2011-11-21 16:48:01 <luke-jr> but someone making a block can do whatever they want anyway, so trying to artificially add restrictions here is IMO not helpful
700 2011-11-21 16:48:03 <gavinandresen> luke-jr: ... so resurrect the discussion and get rough consensus that it is a Good Idea.
701 2011-11-21 16:48:15 <luke-jr> gavinandresen: we had that before 0.5
702 2011-11-21 16:50:02 <luke-jr> 14 people support coinbaser (notably, only 2 or 3 behind getmemorypool) vs 5 who wouldn't explain why they voted against it
703 2011-11-21 16:56:38 <gavinandresen> Speaking of new features...   I'd like to be more rigorous in testing.  QA is an even bigger problem, since Alex isn't getting paid to be a full-time tester.
704 2011-11-21 16:57:45 <gavinandresen> I'd like to see every new feature come with a written test plan.
705 2011-11-21 16:58:26 <gavinandresen> ... and somebody other than the implementor signing off on the test plan stating that they did, indeed, run all the tests.
706 2011-11-21 16:58:53 <wumpus> still, automated tests are usually the best because you can effortlessly rerun them after a change
707 2011-11-21 16:59:27 <gavinandresen> Automated tests are great, and I agree more of those are a great idea.
708 2011-11-21 16:59:29 <BlueMatt> most test plans should be largely in the boost test-suite
709 2011-11-21 16:59:56 <wumpus> sure you could force someone to execute all the test plans for all prior features before adding a new one, but I think that's unrealistic
710 2011-11-21 17:01:01 <gavinandresen> If they're automated, we can run them nightly.  But there will be new UI features (for example) that aren't easy or worthwhile to automate
711 2011-11-21 17:01:29 <BlueMatt> (if they are automated, they are already being run nightly, actually after every commit)
712 2011-11-21 17:01:29 <wumpus> hm android has a monkey for that, don't know about qt
713 2011-11-21 17:02:02 <wumpus> (the monkey basically injects ui events for testing)
714 2011-11-21 17:02:34 <BlueMatt> bitcoin's ui isnt what needs as rigorous crash testing, its really about the backend
715 2011-11-21 17:02:44 <BlueMatt> and that can be done much easier
716 2011-11-21 17:04:28 <wumpus> but yes manual testing makes sense for ui
717 2011-11-21 17:05:16 <wumpus> as long as you make sure the backend is well-tested using automated functionality you'd only have to manually test that the UI sends the right commands to the backend at the right time
718 2011-11-21 17:06:10 <BlueMatt> if the ui crashes once in a blue moon (as long as they dont cause any lost coins, etc) I dont care too much, if bitcoind crashes ever, its too much
719 2011-11-21 17:08:14 <BlueMatt> also, if you havent signed it, this petition is particularly funny: https://wwws.whitehouse.gov/petitions#!/petition/we-demand-vapid-condescending-meaningless-politically-safe-response-petition/gCZfn86x
720 2011-11-21 17:08:30 <wumpus> I've thought about making a 'mock' core so that the UI can be tested without actually having to do anything in the backend like send coins around
721 2011-11-21 17:08:45 <wumpus> hehe i'm not from the US otherwise i'd sign that
722 2011-11-21 17:08:55 <BlueMatt> It would be better to spend time on gavin's test harness imho
723 2011-11-21 17:09:03 <BlueMatt> so that you can test the backend
724 2011-11-21 17:09:18 <wumpus> hey I've written a few unit tests :p
725 2011-11-21 17:09:33 <BlueMatt> heh
726 2011-11-21 17:10:15 <gavinandresen> BlueMatt: .... so I think the last section of release-process.txt is wrong-- after gitian building, I already have a gitian.sigs/$VERSION/gavinandresen/ with .assert and .assert.sig files in it
727 2011-11-21 17:10:45 <wumpus> but I have a difficult time with some of the code, seems really hard to isolate things to test without setting up the whole shebang... so I settled with some of the utility functions :-)
728 2011-11-21 17:10:54 <BlueMatt> gavinandresen: yep you are right
729 2011-11-21 17:11:13 <gavinandresen> Well that's easy, then....
730 2011-11-21 17:11:33 <BlueMatt> gavinandresen: mustve been forgotten when I (was it me?) added the destination flag to gsign
731 2011-11-21 17:11:36 <gavinandresen> What about the "upload gitian zips to SourceForge" ?  Where do they go?
732 2011-11-21 17:12:48 <BlueMatt> gavinandresen: actually, which lines are you specifically talking about, I dont see it attempting to modify gitiain.sigs, its copying from
733 2011-11-21 17:13:07 <gavinandresen> Everything under * From a directory containing bitcoin source, gitian.sigs and gitian zips
734 2011-11-21 17:14:17 <BlueMatt> gavinandresen: ?
735 2011-11-21 17:14:48 <gavinandresen> BlueMatt: I'm following doc/release-process.txt
736 2011-11-21 17:15:04 <BlueMatt> gavinandresen: which line was your first question in reference to?
737 2011-11-21 17:15:36 <gavinandresen> BlueMatt: where, exactly, are the gitian .zips supposed to go at SourceForge?
738 2011-11-21 17:16:09 <wumpus> btw imo https://github.com/bitcoin/bitcoin/pull/602 should also go in for next release, I'm much more comfortable with the new code , it's exception-safe etc
739 2011-11-21 17:16:12 <gavinandresen> BlueMatt: gitian/ subdir of Bitcoin/0.5.0/  ?  Or is there a separate location for gitian zips?   (were they uploaded for previous releases)
740 2011-11-21 17:16:30 <BlueMatt> gavinandresen: you should have bitcoin-0.5.0-linux-gitian.zip in the same place as all the other zips/tars/binaries/etc
741 2011-11-21 17:17:24 <gavinandresen> BlueMatt: thanks, that was my question.
742 2011-11-21 17:18:51 <BlueMatt> gavinandresen: ok, I just didnt get <gavinandresen> BlueMatt: .... so I think the last section of release-process.txt is wrong-- after gitian building, I already have a gitian.sigs/$VERSION/gavinandresen/ with .assert and .assert.sig files in it then
743 2011-11-21 17:21:53 <BlueMatt> gavinandresen: dont upload the gitian zip yet, you need 3 sigs on it first
744 2011-11-21 17:23:30 <gavinandresen> .... ok.... I guess I need more information on what, exactly, "Collect enough gitian signatures" means.  Collect where?
745 2011-11-21 17:23:56 <BlueMatt> gavinandresen: ie wait until me + devrandom/sipa/tcatm all upload their gitian sigs first
746 2011-11-21 17:24:08 <BlueMatt> gavinandresen: then package the gitian zip with 3 sigs in it and upload
747 2011-11-21 17:24:17 <gavinandresen> Upload to where?  You mean commit to the gitian.sigs tree?
748 2011-11-21 17:24:41 <BlueMatt> yea
749 2011-11-21 17:25:03 <gavinandresen> Ah, so all the instructions about unzipping and then re-zipping is to repackage with the signatures?
750 2011-11-21 17:25:14 <BlueMatt> yes
751 2011-11-21 17:25:23 <gavinandresen> Got it.  Those instructions need fixing.....
752 2011-11-21 17:25:28 <BlueMatt> sorry, should have made that more clear...
753 2011-11-21 17:26:02 <BlueMatt> more comments, less code
754 2011-11-21 17:26:27 <gavinandresen> no problem, there's a reason most coders don't write books explaining how to use the code they write....
755 2011-11-21 17:26:55 <BlueMatt> heh, though coders should be able to write docs for other coders...
756 2011-11-21 17:27:23 <gavinandresen> mmm.  yeah, no, a professional technical writer will always do a much better job.
757 2011-11-21 17:27:34 <gavinandresen> (well, a GOOD professional tech writer.....)
758 2011-11-21 17:28:39 <wumpus> well it's always the best check to make another person follow the instructions :-)
759 2011-11-21 17:29:20 <wumpus> it's very hard to write instructions that are completely clear to everyone on first try, there's very few people that can do that without other's input
760 2011-11-21 17:30:17 <wumpus> also  books are always proofread etc
761 2011-11-21 17:33:14 <gavinandresen> I'm going to bump version numbers to 0.5.1 so we can start working on the backlog of pull requests
762 2011-11-21 17:33:27 <tcatm> gavinandresen: should I copy the release announcement from the download page to bitcoin.org, too?
763 2011-11-21 17:33:45 <gavinandresen> tcatm: good idea, yes
764 2011-11-21 17:35:08 <nanotube> BlueMatt: dunno what spaola is doing here. neofutur ^ change sequence? or shall i take gribz off ! and leave it just on ;; ?
765 2011-11-21 17:35:17 <BlueMatt> hey, bitcoin made it into the latest xkcd
766 2011-11-21 17:35:43 <BlueMatt> nanotube: I dont care I just thought Id bring it to your attention...
767 2011-11-21 17:36:35 <nanotube> BlueMatt: really? /me looks at xkcd.
768 2011-11-21 17:37:15 <BlueMatt> nanotube: bottom left of millions
769 2011-11-21 17:37:15 <nanotube> oh wow, capital xkcd!
770 2011-11-21 17:37:47 <BlueMatt> god, he spends so much time on some of these
771 2011-11-21 17:38:53 <CIA-89> bitcoin: Gavin Andresen master * r67c454c / (bitcoin-qt.pro share/setup.nsi src/serialize.h): Bump version to 0.5.1 - http://git.io/ACXPnA
772 2011-11-21 17:39:14 <nanotube> yea i know. serious guy :)
773 2011-11-21 17:42:58 <luke-jr> gavinandresen: don't forget to bump to 0.6 when it's time to start pulling features :P
774 2011-11-21 17:43:45 <BlueMatt> coke's anual marketing budget is bigger than what it would cost to buy everyone in the world a code
775 2011-11-21 17:43:51 <BlueMatt> s/code/coke/
776 2011-11-21 17:49:01 <nanotube> now why does he make it hard to get the full size image to my disk
777 2011-11-21 17:49:08 <nanotube> stupid js panner/zoomer
778 2011-11-21 17:51:13 <BlueMatt> gavinandresen: oops, you should also commit gitian.sigs/0.5.0-win32/gavinandresen/*
779 2011-11-21 18:00:20 <nanotube> heh, annual cost of rabbit ownership...
780 2011-11-21 18:00:48 <BlueMatt> Saudi Armaco...damn
781 2011-11-21 18:01:08 <nanotube> what about it
782 2011-11-21 18:01:09 <CIA-89> bitcoin: Luke Dashjr 0.4.x * rd885aba347c2 bitcoind-stable/ (5 files in 4 dirs): Bump version to 0.4.2
783 2011-11-21 18:01:35 <BlueMatt> tops the largest corporations by market cap by a ton...
784 2011-11-21 18:04:48 <PK> "Bump version to 0.4.2" was there a 0.4.1 release and no one told me?
785 2011-11-21 18:05:01 <BlueMatt> today
786 2011-11-21 18:05:10 <nanotube> ah wow
787 2011-11-21 18:05:12 <BlueMatt> 0.4.1 released with 0.5
788 2011-11-21 18:05:13 <PK> it's not on the bitcoin.org page.
789 2011-11-21 18:05:29 <sipa> not yet - it soon will be
790 2011-11-21 18:06:40 <PK> nice. So to which version should the normal mortals update to? 0.4.1 or 0.5 ?
791 2011-11-21 18:06:48 <BlueMatt> 0.5 probably
792 2011-11-21 18:07:07 <BlueMatt> 0.4.1 only if you really want great stability - ie are running bitcoind most likely
793 2011-11-21 18:07:38 <PK> yea, don't want some bugs mess up my wallet -.-
794 2011-11-21 18:08:03 <BlueMatt> if you are an end-user, 0.5 is probably the way to go, the qt ui is really nice
795 2011-11-21 18:08:55 <PK> what's the difference between a "end-user" and running bitcoind?
796 2011-11-21 18:09:24 <BlueMatt> by running bitcoind, I meant ie a pool operator or someone running bitcoind as a backend to another website
797 2011-11-21 18:10:28 <PK> I see, then 0.5 is mostly gui changes?
798 2011-11-21 18:10:51 <BlueMatt> largely the new qt ui and a fix for the wallet encryption bug (but that is also in 0.4.1)
799 2011-11-21 18:11:26 <PK> I see, thanks.
800 2011-11-21 18:13:36 <CIA-89> bitcoin: Gavin Andresen master * re6389c3 / doc/release-process.txt : Update release process instructions - http://git.io/BELLBg
801 2011-11-21 18:20:49 <luke-jr> PK: I'd go with 0.4.1 for now, tbh
802 2011-11-21 18:21:03 <luke-jr> but 0.5 is definitely the future
803 2011-11-21 18:21:28 <luke-jr> that being said, I'm using 0.5 for GUI
804 2011-11-21 18:22:39 <luke-jr> also note the 0.4.2 is (planned) only for bitcoind, not wxBitcoin
805 2011-11-21 18:22:42 <PK> I'll probably keep 0.4 running on my NAS for a while and try 0.5 on my desktop wallet. Both wallets are the same, just different copies. I need to motivate myself into crosscompiling 0.4.1 for arm first :)
806 2011-11-21 18:23:12 <luke-jr> PK: you know you can't "really" run the same wallet on two machines, right? >.>
807 2011-11-21 18:23:39 <gavinandresen> yes, running "the same" wallet on two different machines is completely unsupported, and, in general, a bad idea.
808 2011-11-21 18:23:40 <sipa> as long as you synchronize between every 100 transactions, you can
809 2011-11-21 18:23:55 <sipa> but There be Dragons (tm)
810 2011-11-21 18:23:56 <luke-jr> sipa: it still won't work "right"
811 2011-11-21 18:24:07 <luke-jr> ie, you'll get the same addresses on both
812 2011-11-21 18:24:38 <PK> luke-jr: Let's say I do... after a long time, which one will own the coins?
813 2011-11-21 18:24:53 <wumpus> don't even go there please :)
814 2011-11-21 18:25:00 <luke-jr> PK: they'll both "own" the older coins, and have distinct newer ones ;)
815 2011-11-21 18:25:16 <sipa> luke-jr: good question
816 2011-11-21 18:25:49 <luke-jr> PK: so it depends which one made the address
817 2011-11-21 18:26:18 <PK> luke-jr: do I need to change the bitcoin address I gave to the pool every once in a while? o.O Right now both wallets "made" the address (before I copied it)
818 2011-11-21 18:26:29 <luke-jr> PK: no
819 2011-11-21 18:26:33 <wumpus> PK: was it a lot of hassle to cross-compile to arm?
820 2011-11-21 18:26:45 <luke-jr> wumpus: it shouldn't be
821 2011-11-21 18:26:53 <wumpus> I've been thinking as well to move bitcoind and tor to an arm box
822 2011-11-21 18:26:57 <PK> wumpus: mostly the dependencies, bitcoind was fairly ok to crosscompile.
823 2011-11-21 18:27:08 <wumpus> PK: nice
824 2011-11-21 18:27:22 <PK> wumpus: I was thinking about crosscompiling tor too to deploy it on a synology box.
825 2011-11-21 18:27:29 <CIA-89> bitcoin: Gavin Andresen master * r4ad4f66 / (contrib/debian/changelog contrib/debian/copyright):
826 2011-11-21 18:27:30 <CIA-89> bitcoin: Merge pull request #652 from TheBlueMatt/master
827 2011-11-21 18:27:35 <PK> probably even make a spx package of it.
828 2011-11-21 18:28:44 <[Tycho]> Oh, the current system will not allow 0-outputs without fee :(
829 2011-11-21 18:29:00 <luke-jr> [Tycho]: eh?
830 2011-11-21 18:29:11 <[Tycho]> My N770 somehow doesn't wants to detect WiFi networks.
831 2011-11-21 18:29:14 <luke-jr> wtf are you worried about fees for?
832 2011-11-21 18:29:21 <luke-jr> N770 was lame
833 2011-11-21 18:29:57 <makomk> What do you want 0 outputs for for that matter?