1 2011-11-21 00:00:00 <phantomcircuit> Edward_Black, people forge manufacturer coupons all the time
   2 2011-11-21 00:00:08 <phantomcircuit> the stores basically just eat the expense
   3 2011-11-21 00:00:18 <Edward_Black> Well, I never really bothered to look up statistics )
   4 2011-11-21 00:01:29 gjs278 has joined
   5 2011-11-21 00:01:39 <Edward_Black> coupons have to possess uncanny ability to drive the plebes into the store though
   6 2011-11-21 00:01:42 <gmaxwell> 'relatively' .. I mean it's not even compariable to bitcoin. The liquidity of large volumes of diamonds seems hardly better that bitcoin... they can't be transfered electronicaly, they require costly assestment to be distingished from cut glass. They can't be efficiently divided (or combined except by mere aggregation which doesn't help the cost of valuation).
   7 2011-11-21 00:02:46 <Edward_Black> I think that it depends on how you measure liquidity
   8 2011-11-21 00:05:33 <gmaxwell> well, in this case— lets say I give you half a million dollars which you must buy diamonds with— and then 24 hours later you must sell them (to different parties) within 48 hours and get dollars back. How many dollars would you have at the end of this activity? I expect you'd lose a lot (for both bitcoins and diamonds).
   9 2011-11-21 00:06:52 <Edward_Black> Well,  I doubt one could dump $200 000 worth of bitcoins into the market over 48 hours without causing a major disturbance
  10 2011-11-21 00:08:32 <Edward_Black> Diamonds would be hobbled with red tape and / or need for criminal involvement (and related payoff) but I do think that "converting $500 000 worth of shinies into USD over 48 hours" is doable if one is savvy in relevant circles, and won't cause the market to get a stroke
  11 2011-11-21 00:09:05 <gmaxwell> oh you can do it, but the parties that will deal with you will demand you take a bath.
  12 2011-11-21 00:09:12 <gmaxwell> (in both cases)
  13 2011-11-21 00:09:40 <gmaxwell> vs if you gave me $500k in coal I could totally move that in a couple days.
  14 2011-11-21 00:09:53 <gmaxwell> (or at least the contracts for it! the coal itself is hard to move!)
  15 2011-11-21 00:10:05 <gmaxwell> (well, slow to move.. barges don't go fast)
  16 2011-11-21 00:10:51 <Eliel> the amount of bitcoins that's mobile on the exchanges is actually surprisingly low considering how many there are.
  17 2011-11-21 00:12:19 <Edward_Black> Hm, I am somewhat doubtfull in respect to selling off 500 000 btc without inducing a panic while only halfway through, at least as long as we're talking exchanges and not OTC with really trusted (honestly!) individuals
  18 2011-11-21 00:12:46 <cocktopus> -otc ftw
  19 2011-11-21 00:13:28 <Edward_Black> My gut instinct would set the minimum time frame for bleeding off that kind of "bitfortune" at about 3 weeks or so, maybe more
  20 2011-11-21 00:14:12 <gmaxwell> Edward_Black: yea, you'd have to be OTC in _either_ case. Diamonds, they're not commodity enough to be able to use a public market for that kind of thing.  Coal— you can actually move that much trially on the open markets without blowing them up.
  21 2011-11-21 00:14:52 <Eliel> yes... coal tends to be burned.
  22 2011-11-21 00:15:02 <Edward_Black> Depends on how you got the diamonds and what your paperwork is like
  23 2011-11-21 00:15:22 <Edward_Black> If it is just a sack handled to me by a Tall Dark Man
  24 2011-11-21 00:15:32 <Edward_Black> Then yeah
  25 2011-11-21 00:15:56 <Edward_Black> It would be a pretty hard pickle
  26 2011-11-21 00:17:03 <Edward_Black> But then, people without proper companies and paperwork set up rarely deal with diamonds, so it is a bit like asking someone with no computer to sell off bitcoins
  27 2011-11-21 00:17:38 <Edward_Black> "where do I plug the hard-drive thingy ?" :~)
  28 2011-11-21 00:18:03 eueueue has quit (Ping timeout: 265 seconds)
  29 2011-11-21 00:19:09 <Edward_Black> Anyway, diamonds look like a neat analogy for bitcoins. They are somewhat nontrivial to convert into cash, and they have distinct benefits that set them apart from other types of tradeable goods.
  30 2011-11-21 00:19:16 theorb has joined
  31 2011-11-21 00:19:33 <cocktopus> most of the valuable ones are quite traceable too
  32 2011-11-21 00:19:41 <Edward_Black> I mentioned that
  33 2011-11-21 00:19:42 <cocktopus> serial numbers micro-etched, etc
  34 2011-11-21 00:19:56 theorbtwo has quit (Ping timeout: 276 seconds)
  35 2011-11-21 00:20:00 <Edward_Black> Bitcoins are relatively traceable too :~(
  36 2011-11-21 00:20:10 theorb is now known as theorbtwo
  37 2011-11-21 00:22:01 asuk has quit (Quit: Leaving.)
  38 2011-11-21 00:23:06 <gmaxwell> They're quite tracable. I don't personally consider this a big disadvantage.
  39 2011-11-21 00:23:34 <gmaxwell> Giving law enforcement something to spin their wheels on will help discourage annoying regulatory actions.
  40 2011-11-21 00:23:48 caedes has quit (Read error: Operation timed out)
  41 2011-11-21 00:23:52 <Edward_Black> Bitcoins are quite more versatile than diamonds, especially in their native environment (and will aquire more "built-in services" as nonstrandard transactions mature, which is good for "money" of any kind) , but  are still more like "magical rocks that can go over TCP/IP" than Eur or USD or GBP
  42 2011-11-21 00:24:27 caedes has joined
  43 2011-11-21 00:24:29 dissipate has quit (Ping timeout: 276 seconds)
  44 2011-11-21 00:24:46 <Edward_Black> And sadly, unlike physical rocks, they do not have uses in jewelry or industry, which significantly increases the importance of speculative shenanigans in bitcoin trade
  45 2011-11-21 00:24:47 BlueMatt has joined
  46 2011-11-21 00:24:59 TheZimm has joined
  47 2011-11-21 00:25:08 <Edward_Black> Also, sadly, bitcoins are unlikely to aquire Veblen properties
  48 2011-11-21 00:25:53 <Edward_Black> At least until it becomes "geek fashion" to flaunt huge-ass bitcoin address balances
  49 2011-11-21 00:26:00 <gmaxwell> jewlery diamons have ~no use in industry.. and the market for the goods in jewelry is highly distorted through cartelish control of the useful distribution chain.
  50 2011-11-21 00:26:08 <gmaxwell> you mean it isn't yet? ;)
  51 2011-11-21 00:27:06 <gmaxwell> it only costs about 15k to get onto the bitcoin rich list.. if you want to aggregate your funds on a single address like a fool.
  52 2011-11-21 00:27:35 <sipa> roconnor: seems it worked
  53 2011-11-21 00:28:01 <Edward_Black> You have answered your own question :~( we, sadly, are unlikely to develop a "flaunt your bitcoins" mentality needed for BTC to be come veblens
  54 2011-11-21 00:30:18 traviscj has joined
  55 2011-11-21 00:31:11 <roconnor> sipa: which transaction?
  56 2011-11-21 00:31:50 iocor has quit (Quit: Computer has gone to sleep.)
  57 2011-11-21 00:33:08 <sipa> http://blockexplorer.com/testnet/address/mwUyUCWRp9WqyNgrGAbghs7KjTL8zjFNKN
  58 2011-11-21 00:33:17 <sipa> that is a 'compressed' address
  59 2011-11-21 00:33:53 <sipa> i've sent coins back and forth between that one and mrAGDGMQkSGNGxYEF2p4WKVysdtT2Xs6YR
  60 2011-11-21 00:34:16 <roconnor> sipa: so this is more or less reproducing my test
  61 2011-11-21 00:34:22 <roconnor> (not that that is bad)
  62 2011-11-21 00:34:28 <roconnor> (it is in fact very good)
  63 2011-11-21 00:37:05 <sipa> roconnor: yes, it's just about making the wallet and key code deal with both compressed and uncompressed keys correctly
  64 2011-11-21 00:37:22 <sipa> nothing cryptographically interesting :)
  65 2011-11-21 00:37:51 <sipa> .... transaction creation failed
  66 2011-11-21 00:37:52 <sipa> what?
  67 2011-11-21 00:38:12 <gmaxwell> Can't validate its own transaction?
  68 2011-11-21 00:40:54 <sipa> yes, but not when using an encrypted wallet, which is what i was testing now
  69 2011-11-21 00:50:13 <roconnor> sipa: ah, that is good!  I test a wallet with only compressed keys
  70 2011-11-21 00:50:19 <roconnor> *tested
  71 2011-11-21 00:52:23 <sipa> roconnor: fixed, it seems now
  72 2011-11-21 00:52:31 * sipa waits for next block
  73 2011-11-21 01:00:06 Sedra has quit (Ping timeout: 258 seconds)
  74 2011-11-21 01:01:35 TheZimm has quit (Quit: Computer has gone to sleep.)
  75 2011-11-21 01:06:43 karnac has joined
  76 2011-11-21 01:13:02 Guest25541 has joined
  77 2011-11-21 01:13:04 Guest25541 is now known as jgarzik
  78 2011-11-21 01:19:11 asuk has joined
  79 2011-11-21 01:21:50 Kolky has quit (Quit: Bye bye!)
  80 2011-11-21 01:22:14 ahbritto_ has joined
  81 2011-11-21 01:22:14 ahbritto_ has quit (Changing host)
  82 2011-11-21 01:22:14 ahbritto_ has joined
  83 2011-11-21 01:27:06 traviscj has quit (Remote host closed the connection)
  84 2011-11-21 01:27:45 crazy_imp has quit (Ping timeout: 240 seconds)
  85 2011-11-21 01:27:55 asuk has quit (Quit: Leaving.)
  86 2011-11-21 01:29:52 crazy_imp has joined
  87 2011-11-21 01:31:35 riush has quit (Remote host closed the connection)
  88 2011-11-21 01:33:03 riush has joined
  89 2011-11-21 01:38:43 knotwork has quit (Read error: Connection reset by peer)
  90 2011-11-21 01:38:43 NickelBot has quit (Read error: Connection reset by peer)
  91 2011-11-21 01:39:04 TheZimm has joined
  92 2011-11-21 01:39:48 knotwork has joined
  93 2011-11-21 01:39:49 knotwork has quit (Read error: Connection reset by peer)
  94 2011-11-21 01:40:32 karnac has quit (Quit: karnac)
  95 2011-11-21 01:40:50 knotwork has joined
  96 2011-11-21 01:41:02 wasabi has joined
  97 2011-11-21 01:41:40 NickelBot has joined
  98 2011-11-21 01:42:01 wasabi2 has quit (Ping timeout: 252 seconds)
  99 2011-11-21 01:56:37 coingenuity has joined
 100 2011-11-21 01:58:26 <roconnor> sipa: block!
 101 2011-11-21 01:58:43 <sipa> roconnor: saw it :D
 102 2011-11-21 02:01:58 <cocktopus> duck duck duck duck duck BLOCK you're out
 103 2011-11-21 02:02:08 wolfspraul has joined
 104 2011-11-21 02:02:28 bodom has quit (Remote host closed the connection)
 105 2011-11-21 02:09:45 <sipa> roconnor: https://github.com/bitcoin/bitcoin/pull/649
 106 2011-11-21 02:12:15 <roconnor> sipa: nice
 107 2011-11-21 02:12:29 <roconnor> sipa: will it ever make it into mainline?
 108 2011-11-21 02:13:18 <BlueMatt> its kinda a lot of code change for such a small gain...
 109 2011-11-21 02:13:32 <BlueMatt> but the disk space saved might make a strong enough arguemnt...
 110 2011-11-21 02:13:37 <sipa> not immediately, it will need quite some testing
 111 2011-11-21 02:13:51 <sipa> and we need to be certain that all full client implementations support it
 112 2011-11-21 02:14:29 maqr has quit (Read error: Connection reset by peer)
 113 2011-11-21 02:20:20 maqr has joined
 114 2011-11-21 02:24:12 Cusipzzz has joined
 115 2011-11-21 02:24:21 <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. ;)
 116 2011-11-21 02:25:17 <sipa> gmaxwell: we'll see :)
 117 2011-11-21 02:27:33 <sipa> it will interfere with import/export private key, though
 118 2011-11-21 02:28:13 <sipa> so maybe secrets for compressed pubkey-addresses need an extra byte tucked on to identify them as such
 119 2011-11-21 02:32:12 sneak has quit (Ping timeout: 244 seconds)
 120 2011-11-21 02:34:30 sneak has joined
 121 2011-11-21 02:40:06 <roconnor> sipa: do you know where the elliptic curve parameters are specified in bitcoin?
 122 2011-11-21 02:41:19 caedes has quit (Ping timeout: 258 seconds)
 123 2011-11-21 02:42:11 <sipa> roconnor: in key.h
 124 2011-11-21 02:42:17 <sipa> in the CKey constructor
 125 2011-11-21 02:44:35 devrandom has quit (Remote host closed the connection)
 126 2011-11-21 02:51:49 TheZimm has quit (Quit: Computer has gone to sleep.)
 127 2011-11-21 02:53:46 BlueMatt has quit (Quit: Ex-Chat)
 128 2011-11-21 02:55:33 <luke-jr> sipa: why not intentionally use private keys multiple times? :P
 129 2011-11-21 02:55:41 <luke-jr> that'd save even more space
 130 2011-11-21 02:56:21 <luke-jr> or is there a way to tell that they're the same one?
 131 2011-11-21 02:57:00 FellowTraveler1 has left ()
 132 2011-11-21 02:58:03 <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
 133 2011-11-21 02:58:19 <luke-jr> i c
 134 2011-11-21 02:58:49 eueueue has joined
 135 2011-11-21 02:58:50 <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
 136 2011-11-21 02:59:00 <sipa> they won't get it
 137 2011-11-21 02:59:28 <luke-jr> what if their client supports compressed keys, but it generated it as a non-compressed one? :P
 138 2011-11-21 02:59:34 <sipa> they won't get it
 139 2011-11-21 02:59:49 <luke-jr> lame
 140 2011-11-21 03:00:09 <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
 141 2011-11-21 03:00:39 <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
 142 2011-11-21 03:01:11 <gmaxwell> sipa: told you. ;)
 143 2011-11-21 03:01:47 <luke-jr> gmaxwell: :P
 144 2011-11-21 03:02:31 <sipa> well, that's exactly the reason why i chose to keep them separated
 145 2011-11-21 03:02:37 <luke-jr> sipa: how about supporting it, so that annoying services can say "to receive funds from us, you need to upgrade" :P
 146 2011-11-21 03:02:53 <sipa> that doesn't make sense
 147 2011-11-21 03:03:16 <luke-jr> yes it does
 148 2011-11-21 03:03:20 BlueMatt has joined
 149 2011-11-21 03:03:31 <sipa> they can't send to your compressed pubkey unless you give them an address that corresponds to a compressed pubkey
 150 2011-11-21 03:03:42 <gmaxwell> people don't usually give out pubkeys in any case.
 151 2011-11-21 03:03:48 <sipa> in fact, they can't even know whether they are sending to compressed pubkey's address or not
 152 2011-11-21 03:03:59 <luke-jr> until you redeem it
 153 2011-11-21 03:04:07 <sipa> yes
 154 2011-11-21 03:04:14 <luke-jr> "the first time we send you will always work, but after that you need version 0.6+"
 155 2011-11-21 03:05:09 <sipa> i'm a firm believer that only the receiver should determine how he accepts funds :)
 156 2011-11-21 03:06:04 <gmaxwell> otherwise why not send people funds via cloud writing?
 157 2011-11-21 03:07:01 <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."
 158 2011-11-21 03:07:09 <luke-jr> sipa: too bad. I'm still generating them.
 159 2011-11-21 03:07:33 <gmaxwell> luke-jr: they're not shorter than send to address.
 160 2011-11-21 03:07:53 <luke-jr> ?
 161 2011-11-21 03:08:03 <luke-jr> the pubkey is. less space when spent.
 162 2011-11-21 03:08:32 <gmaxwell> Yes, not when sent though. And the pubkey could be _zero_ when spent if we used recovery.
 163 2011-11-21 03:09:19 <sipa> luke-jr: "i'm still generating them" -> generating what?
 164 2011-11-21 03:09:25 <luke-jr> payouts
 165 2011-11-21 03:09:45 <luke-jr> gmaxwell: that isn't backward compatible
 166 2011-11-21 03:10:06 <sipa> you're going to do send-to-(compressed)-pubkey for payouts?
 167 2011-11-21 03:10:11 <gmaxwell> sipa: sounds like luke is saying he's going to start doing his pool payouts to compressed pubkeys.
 168 2011-11-21 03:10:26 <luke-jr> sipa: no, but generation is already a "you have to do this to receive" thing
 169 2011-11-21 03:10:32 <luke-jr> mainly due to bitcoind special-casing it
 170 2011-11-21 03:10:50 <sipa> true - but the script is still something the receiver determines, right?
 171 2011-11-21 03:11:04 <luke-jr> not really.
 172 2011-11-21 03:11:10 <luke-jr> they give me an address.
 173 2011-11-21 03:11:14 <sipa> you won't be using non-standard scripts for payouts, if you don't know whether the receiver's client supports it
 174 2011-11-21 03:11:23 <luke-jr> true
 175 2011-11-21 03:11:28 <sipa> and an address is a template for a txout script
 176 2011-11-21 03:11:34 <luke-jr> if you say so
 177 2011-11-21 03:12:09 <sipa> well, it is also an identifier for a key
 178 2011-11-21 03:12:29 <sipa> but i don't like looking at them like that
 179 2011-11-21 03:14:35 Turingi has quit (Read error: Connection reset by peer)
 180 2011-11-21 03:25:39 eueueue has quit (Quit: Page closed)
 181 2011-11-21 03:25:55 BlueMatt has quit (Quit: Ex-Chat)
 182 2011-11-21 03:26:22 denisx has joined
 183 2011-11-21 03:35:05 num1 has joined
 184 2011-11-21 03:42:03 wasabi2 has joined
 185 2011-11-21 03:43:56 wasabi has quit (Ping timeout: 252 seconds)
 186 2011-11-21 03:44:38 gjs278 has quit (Remote host closed the connection)
 187 2011-11-21 03:45:03 gjs278 has joined
 188 2011-11-21 03:53:05 Beremat has quit (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
 189 2011-11-21 03:56:56 sytse has quit (Ping timeout: 244 seconds)
 190 2011-11-21 03:57:54 sytse has joined
 191 2011-11-21 04:01:04 TheSeven has quit (Disconnected by services)
 192 2011-11-21 04:01:18 [7] has joined
 193 2011-11-21 04:03:43 magn3ts has quit (Quit: Leaving)
 194 2011-11-21 04:03:50 ForceMajeure has quit (Read error: Connection reset by peer)
 195 2011-11-21 04:09:18 wolfspraul has quit (Quit: Lost terminal)
 196 2011-11-21 04:14:04 denisx has quit (Quit: denisx)
 197 2011-11-21 04:15:14 osmosis has joined
 198 2011-11-21 04:21:25 underscor has quit (Ping timeout: 240 seconds)
 199 2011-11-21 04:30:15 underscor has joined
 200 2011-11-21 04:37:12 traviscj has joined
 201 2011-11-21 04:41:20 wasabi1 has quit (Read error: Connection reset by peer)
 202 2011-11-21 04:58:04 dan__ has joined
 203 2011-11-21 05:03:25 iddo has quit (Ping timeout: 240 seconds)
 204 2011-11-21 05:03:31 iddo has joined
 205 2011-11-21 05:03:51 RobinPKR_ has joined
 206 2011-11-21 05:06:04 RobinPKR has quit (Ping timeout: 248 seconds)
 207 2011-11-21 05:06:05 RobinPKR_ is now known as RobinPKR
 208 2011-11-21 05:13:29 [Tycho] has joined
 209 2011-11-21 05:17:50 [Tycho] has quit (Remote host closed the connection)
 210 2011-11-21 05:32:40 <cjdelisl1> anyone know anything about endienness of integers in bitfields?
 211 2011-11-21 05:33:00 <cjdelisl1> I have this:
 212 2011-11-21 05:33:00 <cjdelisl1>         uint32_t messageType : 4;
 213 2011-11-21 05:33:01 <cjdelisl1>         uint32_t fragmentNumber : 4;
 214 2011-11-21 05:33:16 <cjdelisl1> and there's an #ifdef to check for big endian and reverse them
 215 2011-11-21 05:33:32 <cjdelisl1> when I read messageType, do I need to call ntohl()?
 216 2011-11-21 05:36:35 <copumpkin> fucking bitfields
 217 2011-11-21 05:39:17 <bd_> cjdelisl1: bitfield representation is not portable, period
 218 2011-11-21 05:39:36 <bd_> even on the same OS, different compilers handle it differently, and ntohl won't save you
 219 2011-11-21 05:39:50 <cjdelisl1> ok, I'll just do it all manually then
 220 2011-11-21 05:39:52 <cjdelisl1> thanks
 221 2011-11-21 05:40:02 <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 :)
 222 2011-11-21 05:40:05 Cusipzzz has quit (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/)
 223 2011-11-21 05:40:06 <bd_> that's probably best yeha
 224 2011-11-21 05:40:08 <cjdelisl1> it seems so nice and easy
 225 2011-11-21 05:42:55 wasabi has joined
 226 2011-11-21 05:44:56 wasabi2 has quit (Ping timeout: 252 seconds)
 227 2011-11-21 05:45:53 WakiMiko_ has joined
 228 2011-11-21 05:46:13 dan__ has quit (Remote host closed the connection)
 229 2011-11-21 05:46:25 dissipate has joined
 230 2011-11-21 05:46:33 dan__ has joined
 231 2011-11-21 05:47:01 RazielZ has joined
 232 2011-11-21 05:49:10 WakiMiko has quit (Ping timeout: 258 seconds)
 233 2011-11-21 05:50:02 magn3ts has joined
 234 2011-11-21 05:53:19 underscor has quit (Remote host closed the connection)
 235 2011-11-21 05:54:08 eoss has quit (Quit: Leaving)
 236 2011-11-21 05:54:31 underscor has joined
 237 2011-11-21 05:58:28 dissipate has quit (Read error: Connection reset by peer)
 238 2011-11-21 06:00:42 BurtyBB has quit (Read error: No route to host)
 239 2011-11-21 06:01:04 BurtyBB has joined
 240 2011-11-21 06:13:59 Sedra has joined
 241 2011-11-21 06:15:15 localhost has quit (Remote host closed the connection)
 242 2011-11-21 06:18:51 localhost has joined
 243 2011-11-21 06:19:04 magn3ts has quit (Ping timeout: 258 seconds)
 244 2011-11-21 06:19:19 BurtyBB has quit (Ping timeout: 260 seconds)
 245 2011-11-21 06:19:36 merde has joined
 246 2011-11-21 06:21:50 magn3ts has joined
 247 2011-11-21 06:23:24 BurtyB has joined
 248 2011-11-21 06:26:56 osmosis has quit (Quit: Leaving)
 249 2011-11-21 06:30:51 grubles has joined
 250 2011-11-21 06:34:19 hazdb has joined
 251 2011-11-21 06:34:30 <hazdb> I need a coder for a project. where do I go?
 252 2011-11-21 06:34:33 <hazdb> a bitcoin project
 253 2011-11-21 06:37:04 <phantomcircuit> hazdb, right here
 254 2011-11-21 06:37:06 <Eliel> this is probably the place :)
 255 2011-11-21 06:37:09 <phantomcircuit> hazdb, what do you need
 256 2011-11-21 06:39:11 BurtyB has quit (Ping timeout: 244 seconds)
 257 2011-11-21 06:42:07 BurtyB has joined
 258 2011-11-21 06:47:28 dan__ has quit (Quit: dan__)
 259 2011-11-21 06:49:53 AStove has joined
 260 2011-11-21 07:11:53 osmosis has joined
 261 2011-11-21 07:22:37 larsivi has quit (Ping timeout: 240 seconds)
 262 2011-11-21 07:43:35 wasabi1 has joined
 263 2011-11-21 07:45:44 wasabi has quit (Ping timeout: 244 seconds)
 264 2011-11-21 07:58:08 dan__ has joined
 265 2011-11-21 08:03:42 abragin has joined
 266 2011-11-21 08:03:42 abragin has quit (Changing host)
 267 2011-11-21 08:03:42 abragin has joined
 268 2011-11-21 08:06:29 dan__ has quit (Quit: dan__)
 269 2011-11-21 08:24:02 danbri has joined
 270 2011-11-21 08:24:05 copumpkin has quit (Ping timeout: 244 seconds)
 271 2011-11-21 08:24:30 copumpkin has joined
 272 2011-11-21 08:30:55 SomeoneWeird is now known as SomeoneWeirdAFK
 273 2011-11-21 08:34:13 enquirer has quit (Ping timeout: 240 seconds)
 274 2011-11-21 08:35:02 molecular has quit (Ping timeout: 240 seconds)
 275 2011-11-21 08:43:41 dvide has quit ()
 276 2011-11-21 08:44:14 wasabi has joined
 277 2011-11-21 08:44:27 benne has quit (Changing host)
 278 2011-11-21 08:44:27 benne has joined
 279 2011-11-21 08:46:18 wasabi1 has quit (Ping timeout: 276 seconds)
 280 2011-11-21 08:47:49 molecular has joined
 281 2011-11-21 08:52:30 RazielZ has quit (Ping timeout: 252 seconds)
 282 2011-11-21 08:57:48 RazielZ has joined
 283 2011-11-21 09:04:35 iddo has quit (Changing host)
 284 2011-11-21 09:04:35 iddo has joined
 285 2011-11-21 09:06:46 larsivi has joined
 286 2011-11-21 09:09:37 runasand has joined
 287 2011-11-21 09:14:39 gjs278 has quit (Remote host closed the connection)
 288 2011-11-21 09:15:02 gjs278 has joined
 289 2011-11-21 09:17:14 ThomasV has joined
 290 2011-11-21 09:25:04 larsivi_ has joined
 291 2011-11-21 09:26:54 <CIA-89> bitcoin: Luke Dashjr master * raa1ed92 / contrib/debian/copyright : update debian copyright file for MIT icon relicensing - http://git.io/I1HoFA
 292 2011-11-21 09:26:54 <CIA-89> bitcoin: Wladimir J. van der Laan master * rc968b68 / contrib/debian/copyright :
 293 2011-11-21 09:26:54 <CIA-89> bitcoin: Merge pull request #646 from luke-jr/bugfix_MIT_icons
 294 2011-11-21 09:26:54 <CIA-89> bitcoin: update debian copyright file for MIT icon relicensing - http://git.io/wwCYkw
 295 2011-11-21 09:26:55 bobke has quit (Quit: No Ping reply in 180 seconds.)
 296 2011-11-21 09:26:56 rcorreia has quit (Quit: No Ping reply in 180 seconds.)
 297 2011-11-21 09:26:56 bobke_ has joined
 298 2011-11-21 09:26:56 AAA_awright has quit (Quit: No Ping reply in 180 seconds.)
 299 2011-11-21 09:26:56 larsivi has quit (Quit: No Ping reply in 180 seconds.)
 300 2011-11-21 09:26:56 rcorreia_ has joined
 301 2011-11-21 09:26:56 stalled has quit (Ping timeout: 244 seconds)
 302 2011-11-21 09:26:57 nanotube has quit (Quit: Something is wrong...)
 303 2011-11-21 09:26:58 zyb_ has quit (Ping timeout: 244 seconds)
 304 2011-11-21 09:27:00 zyb has joined
 305 2011-11-21 09:27:21 AAA_awright has joined
 306 2011-11-21 09:27:48 Guest70619 has joined
 307 2011-11-21 09:31:15 stalled has joined
 308 2011-11-21 09:31:29 Sedra- has joined
 309 2011-11-21 09:32:35 RazielZ has quit (Ping timeout: 260 seconds)
 310 2011-11-21 09:34:21 Sedra has quit (Ping timeout: 244 seconds)
 311 2011-11-21 09:35:32 Sedra has joined
 312 2011-11-21 09:37:16 RazielZ has joined
 313 2011-11-21 09:38:29 Sedra- has quit (Ping timeout: 244 seconds)
 314 2011-11-21 09:40:55 danbri has quit (Ping timeout: 276 seconds)
 315 2011-11-21 09:44:34 wasabi1 has joined
 316 2011-11-21 09:45:23 t3a has quit (Ping timeout: 258 seconds)
 317 2011-11-21 09:47:25 wasabi has quit (Ping timeout: 276 seconds)
 318 2011-11-21 09:58:56 erus` has joined
 319 2011-11-21 10:01:04 SomeoneWeirdAFK is now known as SomeoneWeird
 320 2011-11-21 10:04:40 erle- has joined
 321 2011-11-21 10:13:44 erle- has quit (Quit: erle-)
 322 2011-11-21 10:19:20 iocor has joined
 323 2011-11-21 10:21:12 chrisb__ has joined
 324 2011-11-21 10:21:19 danbri has joined
 325 2011-11-21 10:22:27 oww has quit (Remote host closed the connection)
 326 2011-11-21 10:24:57 wolfspraul has joined
 327 2011-11-21 10:28:35 chrisb__ has quit (Quit: Ex-Chat)
 328 2011-11-21 10:33:42 dissipate has joined
 329 2011-11-21 10:36:44 iocor has quit (Quit: Computer has gone to sleep.)
 330 2011-11-21 10:38:44 osmosis has quit (Quit: Leaving)
 331 2011-11-21 10:39:58 RazielZ has quit ()
 332 2011-11-21 10:45:08 wasabi has joined
 333 2011-11-21 10:46:38 wasabi1 has quit (Ping timeout: 240 seconds)
 334 2011-11-21 10:47:41 batouzo has joined
 335 2011-11-21 10:47:45 ThomasV has quit (Quit: Leaving)
 336 2011-11-21 10:47:57 <batouzo> !seen genjix
 337 2011-11-21 10:47:57 <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 "{}".
 338 2011-11-21 10:47:57 <gribble> genjix was last seen in #bitcoin-dev 2 weeks, 0 days, 13 hours, 22 minutes, and 15 seconds ago: <genjix> :)
 339 2011-11-21 10:48:17 <batouzo> !tell genjix Congratulations on your Slashdot article, my god!! :)
 340 2011-11-21 10:48:58 <batouzo> I fail at tell-later
 341 2011-11-21 10:52:10 <batouzo> http://politics.slashdot.org/story/11/11/21/0230217/swedish-pirate-party-member-to-be-eus-youngest-mp
 342 2011-11-21 10:55:15 <grubles> it's later tell
 343 2011-11-21 10:56:04 <batouzo> !later tell satoshi where are you when we need you
 344 2011-11-21 10:56:05 <gribble> The operation succeeded.
 345 2011-11-21 10:56:29 <grubles> :D
 346 2011-11-21 10:56:39 <coingenuity> ;;seen satoshi
 347 2011-11-21 10:56:39 <gribble> satoshi was last seen in #bitcoin-dev 39 weeks, 4 days, 10 hours, 40 minutes, and 56 seconds ago: <satoshi> satoshi is here!
 348 2011-11-21 10:57:11 rdponticelli_ has quit (Read error: Connection reset by peer)
 349 2011-11-21 10:57:26 <batouzo> coingenuity: how's your site going? :)
 350 2011-11-21 10:58:03 <coingenuity> well batouzo :)
 351 2011-11-21 10:58:22 <coingenuity> been working on automated shipping all of last week :S
 352 2011-11-21 10:58:34 <coingenuity> not very fun, but got it taken care of ;)
 353 2011-11-21 10:59:05 <coingenuity> do you have any projects in the works batouzo ?
 354 2011-11-21 10:59:08 rdponticelli has joined
 355 2011-11-21 10:59:14 <batouzo> coingenuity: well lets see
 356 2011-11-21 10:59:22 <batouzo> Open Transactions thing for the conference
 357 2011-11-21 11:00:01 <coingenuity> cool, glad to see OT is gaining some recognition :D
 358 2011-11-21 11:00:07 <coingenuity> lots of projects about it these days
 359 2011-11-21 11:02:03 <batouzo> lots of project using OT nowdays?
 360 2011-11-21 11:03:01 <coingenuity> yeah, I see a good bit of buzz about it
 361 2011-11-21 11:03:32 <coingenuity> what does your OT project do?
 362 2011-11-21 11:03:47 <batouzo> yeap. Though I think there are no other yet existing projects actually using OT other then some drafts?
 363 2011-11-21 11:04:03 <batouzo> you will find out on friday's conference ;)
 364 2011-11-21 11:04:34 <coingenuity> lol, maybe: i dont follow news all that much
 365 2011-11-21 11:04:51 <coingenuity> i'll let you keep it to yourself for now :P
 366 2011-11-21 11:05:04 <coingenuity> and yep, projects using OT that are beyond draft stages is what i'm referring to lol
 367 2011-11-21 11:06:12 <batouzo> cool, do you know of any? Where are they located?
 368 2011-11-21 11:07:07 <coingenuity> yeh, gotta keep my mouth shut for now though sorry :(
 369 2011-11-21 11:07:15 <coingenuity> i can tell you, europe
 370 2011-11-21 11:07:37 <batouzo> you will announce on European conference?
 371 2011-11-21 11:07:51 <coingenuity> it's not my project heh
 372 2011-11-21 11:09:04 danbri has quit (Read error: Connection reset by peer)
 373 2011-11-21 11:16:10 danbri has joined
 374 2011-11-21 11:17:37 batouzo has quit (Read error: Operation timed out)
 375 2011-11-21 11:20:16 sytse has quit (Ping timeout: 244 seconds)
 376 2011-11-21 11:20:42 RazielZ has joined
 377 2011-11-21 11:21:03 sytse has joined
 378 2011-11-21 11:29:17 [Tycho] has joined
 379 2011-11-21 11:29:34 darkskiez has quit (Ping timeout: 244 seconds)
 380 2011-11-21 11:35:18 danbri has quit (Remote host closed the connection)
 381 2011-11-21 11:38:52 aleod has joined
 382 2011-11-21 11:44:36 sacarlson has quit (Ping timeout: 258 seconds)
 383 2011-11-21 11:44:45 AStove has quit ()
 384 2011-11-21 11:45:35 wasabi1 has joined
 385 2011-11-21 11:47:17 wasabi has quit (Ping timeout: 245 seconds)
 386 2011-11-21 11:47:55 bobke_ is now known as bobke
 387 2011-11-21 11:51:16 <epscy>  aleod | are the devs aware that bitcoin.org is broken?
 388 2011-11-21 11:53:31 wolfspraul has quit (Ping timeout: 260 seconds)
 389 2011-11-21 11:53:56 Beremat has joined
 390 2011-11-21 11:54:10 darkskiez has joined
 391 2011-11-21 11:54:22 wolfspraul has joined
 392 2011-11-21 11:58:46 sacarlson has joined
 393 2011-11-21 12:05:22 <sipa> epscy: thanks for reporting - i reverted it
 394 2011-11-21 12:06:02 <tcatm> looks like my daily update script failed. I'm going to debug it
 395 2011-11-21 12:06:04 <sipa> ;;later tell tcatm seems the jekyll build failed and pushed an empty directory to github
 396 2011-11-21 12:06:04 <gribble> The operation succeeded.
 397 2011-11-21 12:08:05 rdponticelli has quit (Read error: Connection reset by peer)
 398 2011-11-21 12:10:35 <[Tycho]> Finally someone on the forum noticed my TXes :)
 399 2011-11-21 12:10:43 <coingenuity> HA
 400 2011-11-21 12:10:52 <coingenuity> bullshit [Tycho] people noticed long ago
 401 2011-11-21 12:11:03 MobiusL has quit (Quit: Leaving)
 402 2011-11-21 12:11:09 <[Tycho]> Where ?
 403 2011-11-21 12:11:16 <coingenuity> like, hours after you transmitted
 404 2011-11-21 12:11:33 <coingenuity> someone posted about it in private :P
 405 2011-11-21 12:11:38 <coingenuity> i was loling
 406 2011-11-21 12:11:41 rdponticelli has joined
 407 2011-11-21 12:11:45 <[Tycho]> Why loling ?
 408 2011-11-21 12:12:03 <coingenuity> it was something along the lines of "where is this strange TX from??"
 409 2011-11-21 12:12:08 <coingenuity> i found it amusing
 410 2011-11-21 12:14:59 <[Tycho]> Theymos guessed the salt part, he's smart :)
 411 2011-11-21 12:16:15 Beremat has quit (Read error: Connection reset by peer)
 412 2011-11-21 12:17:23 <coingenuity> ya, i noticed that when i looked at the tx
 413 2011-11-21 12:17:37 <coingenuity> hash of anything interesting?
 414 2011-11-21 12:22:12 <[Tycho]> No, just a fragment of bitcoind source.
 415 2011-11-21 12:22:38 <[Tycho]> Actually in THIS case it's not salt, but was intended to be.
 416 2011-11-21 12:23:02 <[Tycho]> I will try to redeem one and see if someone will redeem another.
 417 2011-11-21 12:23:30 aleod has quit (Quit: Leaving.)
 418 2011-11-21 12:25:50 [Tycho] has quit (Remote host closed the connection)
 419 2011-11-21 12:28:51 Guest70619 is now known as nanotube
 420 2011-11-21 12:41:35 oww has joined
 421 2011-11-21 12:45:44 danbri has joined
 422 2011-11-21 12:47:00 danbri has quit (Remote host closed the connection)
 423 2011-11-21 12:55:20 MobiusL has joined
 424 2011-11-21 12:57:19 num1 has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
 425 2011-11-21 12:58:36 dissipate has quit (Read error: Connection reset by peer)
 426 2011-11-21 12:58:40 tower has quit (Disconnected by services)
 427 2011-11-21 12:58:55 tower has joined
 428 2011-11-21 12:59:41 marf_away has joined
 429 2011-11-21 13:00:30 BurtyBB has joined
 430 2011-11-21 13:03:27 BurtyB has quit (Ping timeout: 240 seconds)
 431 2011-11-21 13:05:39 Tritonio has joined
 432 2011-11-21 13:15:35 CryptoX has quit (Read error: Connection reset by peer)
 433 2011-11-21 13:17:03 CryptoX has joined
 434 2011-11-21 13:17:51 Litt has quit (Ping timeout: 240 seconds)
 435 2011-11-21 13:23:35 Litt has joined
 436 2011-11-21 13:26:36 sneak has quit (Ping timeout: 240 seconds)
 437 2011-11-21 13:31:29 sneak has joined
 438 2011-11-21 13:41:17 datagutt has joined
 439 2011-11-21 13:46:30 wasabi has joined
 440 2011-11-21 13:48:27 wasabi1 has quit (Ping timeout: 244 seconds)
 441 2011-11-21 13:49:41 [Tycho] has joined
 442 2011-11-21 13:50:19 iocor has joined
 443 2011-11-21 13:50:29 erus`_ has joined
 444 2011-11-21 13:50:31 <[Tycho]> Hello, bitcoin people.
 445 2011-11-21 13:51:24 roconnor has quit (Ping timeout: 240 seconds)
 446 2011-11-21 13:53:01 erus` has quit (Ping timeout: 258 seconds)
 447 2011-11-21 13:53:07 erus`_ is now known as erus`
 448 2011-11-21 13:53:30 da2ce7 has joined
 449 2011-11-21 13:53:30 da2ce7 has quit (Changing host)
 450 2011-11-21 13:53:30 da2ce7 has joined
 451 2011-11-21 13:54:35 eoss has joined
 452 2011-11-21 13:54:35 eoss has quit (Changing host)
 453 2011-11-21 13:54:35 eoss has joined
 454 2011-11-21 13:57:25 agricocb has quit (Remote host closed the connection)
 455 2011-11-21 14:00:57 gavinandresen has joined
 456 2011-11-21 14:06:53 eueueue has joined
 457 2011-11-21 14:08:07 danbri has joined
 458 2011-11-21 14:08:08 <tcatm> who knows how to setup a dnsseed?
 459 2011-11-21 14:09:45 <nanotube> jgarzik and bluematt do :)
 460 2011-11-21 14:11:28 erus`_ has joined
 461 2011-11-21 14:13:47 <sipa> tcatm: just a DNS seed is easy: have a certain domain name resolve to a bunch of IP addresses
 462 2011-11-21 14:13:51 erus` has quit (Ping timeout: 240 seconds)
 463 2011-11-21 14:14:06 erus`_ is now known as erus`
 464 2011-11-21 14:14:11 <sipa> but you probably want some setup that automatically populates it with a (subset of) known good nodes on the network
 465 2011-11-21 14:14:21 <sipa> i believe bluematt has his setup for that somewhere on github
 466 2011-11-21 14:16:51 agricocb has joined
 467 2011-11-21 14:22:19 <gavinandresen> I'm thinking of promoting rc7 to The 0.5.0 Release today.  Anybody see any reason not to?
 468 2011-11-21 14:24:31 <eueueue> yes
 469 2011-11-21 14:24:49 <eueueue> the popup black on linux on hover transactions
 470 2011-11-21 14:25:20 <eueueue> https://github.com/bitcoin/bitcoin/issues/613
 471 2011-11-21 14:25:43 <eueueue> the popup should be removed or fixed
 472 2011-11-21 14:27:09 larsivi_ has quit (Ping timeout: 258 seconds)
 473 2011-11-21 14:28:06 t3a has joined
 474 2011-11-21 14:38:12 AlexWaters has quit (Ping timeout: 240 seconds)
 475 2011-11-21 14:39:31 <gavinandresen> eueueue: not a show-stopper bug
 476 2011-11-21 14:39:48 <eueueue> ok so
 477 2011-11-21 14:41:09 <eueueue> gavinandresen: Why not remove this tooltip as doesn't work as expected?
 478 2011-11-21 14:41:20 <gavinandresen> Because it does work as expected on most systems.
 479 2011-11-21 14:41:33 <eueueue> ok
 480 2011-11-21 14:41:34 <riush> what exactly is it supposed to show? ;)
 481 2011-11-21 14:44:22 <[Tycho]> What minimum bitcoin version supports checkmultysig ?
 482 2011-11-21 14:44:24 <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)
 483 2011-11-21 14:45:24 <wumpus> eueueue: it works fine for me on all systems
 484 2011-11-21 14:46:18 <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
 485 2011-11-21 14:47:00 <eueueue> wumpus: I reproduce it on debian wheezy. Devs say is a qt bug. So ok
 486 2011-11-21 14:47:04 <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
 487 2011-11-21 14:47:34 <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
 488 2011-11-21 14:49:09 <gavinandresen> [Tycho]: all versions of bitcoin support checkmultisig
 489 2011-11-21 14:49:29 <gavinandresen> [Tycho]: ... but no versions consider it a 'standard' transaction type
 490 2011-11-21 14:50:21 <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
 491 2011-11-21 14:51:04 <[Tycho]> So we just need to allow it in IsStandard ?
 492 2011-11-21 14:51:13 <eueueue> wumpus: ok, thanks for explaing. So let the 0.5 be released
 493 2011-11-21 14:52:25 <sipa> gavinandresen: i can't reproduce it, so i'll assume it was indeed related to deleting those log files
 494 2011-11-21 14:53:33 <gavinandresen> riush eueueue : here's what the popup looks like on my mac:  http://imageshack.us/photo/my-images/833/screenshot20111121at935.jpg/
 495 2011-11-21 14:54:13 <wumpus> gavinandresen: huh, it's transparent?
 496 2011-11-21 14:54:17 <gavinandresen> yup
 497 2011-11-21 14:54:41 iocor has quit (Quit: Computer has gone to sleep.)
 498 2011-11-21 14:54:41 <gavinandresen> Isn't it supposed to be?
 499 2011-11-21 14:54:51 <wumpus> well it's supposed to be like all the other tooltips
 500 2011-11-21 14:55:03 <wumpus> if those are transparent on a mac, it's as it's supposed to be :p
 501 2011-11-21 14:55:16 <helo> on my linux machine last week it was showing random parts of my virtualbox windows behind the text heh
 502 2011-11-21 14:55:18 <riush> ah
 503 2011-11-21 14:55:25 <gavinandresen> The other ones are yellow
 504 2011-11-21 14:55:35 <wumpus> in that case it should be yellow
 505 2011-11-21 14:55:47 <wumpus> so it seems the background is not getting initialized...
 506 2011-11-21 14:55:48 <riush> i think it's supposed to look like the tooltip in the transactions list
 507 2011-11-21 14:56:07 <riush> it's been showing random other stuff from my x session too
 508 2011-11-21 14:56:35 <wumpus> yes, uninitialized means it can be anything
 509 2011-11-21 14:56:38 <gavinandresen> All the rest of the tooltips are yellow boxes
 510 2011-11-21 14:57:07 <wumpus> I'll take a look at it soon -- still I don't think it's a release-blocker
 511 2011-11-21 14:57:15 <sipa> it's not
 512 2011-11-21 14:57:15 <gavinandresen> yes, definitely not a release-blocker
 513 2011-11-21 14:58:17 <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
 514 2011-11-21 15:00:26 <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.
 515 2011-11-21 15:00:42 <sipa> you mean - moving away from bdb?
 516 2011-11-21 15:00:45 ThomasV has joined
 517 2011-11-21 15:01:19 <wumpus> or somehow using bdb its own encyption
 518 2011-11-21 15:01:27 <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."
 519 2011-11-21 15:01:36 <sipa> gavinandresen: i'd love that
 520 2011-11-21 15:01:38 <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)
 521 2011-11-21 15:01:41 <wumpus> multi-wallet support would be nice in any case
 522 2011-11-21 15:01:54 <etotheipi_> you manually seek to that part of the file to overwrite the keys
 523 2011-11-21 15:01:58 <gavinandresen> The real issue is the old, previously-unencrypted private keys leaking
 524 2011-11-21 15:02:41 <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
 525 2011-11-21 15:02:54 <etotheipi_> with the exception of filesystem magic
 526 2011-11-21 15:03:02 gp5st has left ()
 527 2011-11-21 15:03:05 <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...
 528 2011-11-21 15:03:08 gp5st has joined
 529 2011-11-21 15:03:33 <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
 530 2011-11-21 15:03:56 <sipa> the philosophical question is: does the wallet manage its own wallet(s), and have decent import/export functions to interact with files
 531 2011-11-21 15:03:57 <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
 532 2011-11-21 15:04:07 <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
 533 2011-11-21 15:04:16 <wumpus> NIH*
 534 2011-11-21 15:04:17 <sipa> or are wallets files the user can open/close, with the bitcoin application an 'editor' for those wallets
 535 2011-11-21 15:04:52 <gavinandresen> What is dangerous is writing unencrypted keys, or assuming that keys that were at one time written unencrypted are still secure
 536 2011-11-21 15:04:56 <sipa> it seems bitcoin so far was developed from the first perspective, but people are using it according it to the second
 537 2011-11-21 15:04:58 <wumpus> especially as we want the key store to be really, really reliable
 538 2011-11-21 15:05:23 <sipa> but bdb does fail - how often do you read about corrupted wallets?
 539 2011-11-21 15:05:41 <sipa> that is probably caused by malfunctions like crashes or power loss
 540 2011-11-21 15:05:42 <etotheipi_> keys never have to be written unencrypted, but they can be if the user chooses to do so...
 541 2011-11-21 15:05:58 <sipa> but still, i don't like bdb too much anymore for such an easy store
 542 2011-11-21 15:06:14 <etotheipi_> I think, for data this is so simple as this, manual file management is the way to go
 543 2011-11-21 15:06:14 <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
 544 2011-11-21 15:06:15 <sipa> especially as it is read into memory entirely anyway
 545 2011-11-21 15:07:14 <wumpus> but should it be read into memory entirely? or is that just a stop-gap until more scalability is needed?
 546 2011-11-21 15:07:32 <sipa> it was clearly designed to be able to not read it in memory
 547 2011-11-21 15:07:48 <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
 548 2011-11-21 15:08:15 <etotheipi_> unlike a DB format which might instead lead to a corrupted DB and the problems we have now
 549 2011-11-21 15:08:21 <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
 550 2011-11-21 15:08:47 <sipa> currently that's not possible anymore, by the way
 551 2011-11-21 15:08:53 <etotheipi_> if you have one million keys, you're looking at maybe 100 MB of RAM
 552 2011-11-21 15:08:58 <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...
 553 2011-11-21 15:09:05 <sipa> the core indexes keys by address, but the wallet file stores it indexed by pubkey
 554 2011-11-21 15:09:20 <wumpus> bdb can't support secondary indexes?
 555 2011-11-21 15:09:29 <gmaxwell> etotheipi_: I was going to point out a million keys too... but you were faster because I was actually adding up the size. :)
 556 2011-11-21 15:09:29 <etotheipi_> the entire blockchain is written manually
 557 2011-11-21 15:09:33 <gavinandresen> The only issues I've seen with "corrupted wallets" have actually been blkindex/addr.dat files that wouldn't load.
 558 2011-11-21 15:09:52 <sipa> gavinandresen: well, there is a known issue there actually
 559 2011-11-21 15:10:16 <sipa> when the best chain is written to the file, but not marked as current best chain
 560 2011-11-21 15:10:17 <etotheipi_> we are doing fine with a manually written blk0001.dat file without a database engine behind it
 561 2011-11-21 15:10:39 <etotheipi_> are there problems with that getting corrupted?
 562 2011-11-21 15:10:44 <wumpus> yes
 563 2011-11-21 15:11:06 <gmaxwell> etotheipi_: our use of that is append only, however.
 564 2011-11-21 15:11:30 iocor has joined
 565 2011-11-21 15:11:32 <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
 566 2011-11-21 15:11:38 <wumpus> sometiems
 567 2011-11-21 15:11:41 <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
 568 2011-11-21 15:11:41 <sipa> wumpus: indeed
 569 2011-11-21 15:11:43 <etotheipi_> you can make the wallet append-only, too
 570 2011-11-21 15:11:54 <wumpus> gavinandresen: +1
 571 2011-11-21 15:12:02 <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?
 572 2011-11-21 15:12:02 <etotheipi_> fair enough...
 573 2011-11-21 15:12:09 <etotheipi_> I'm on my own with this one, that's fine :)
 574 2011-11-21 15:12:10 <sipa> helo: no
 575 2011-11-21 15:12:11 <gavinandresen> (fixing the power-failure-during-blockchain-download problem should be done also, of course)
 576 2011-11-21 15:12:18 <CryptoX> Crypto X Change API is now ready http://www.cryptoxchange.com/t/cryptoapi
 577 2011-11-21 15:12:32 <wumpus> gavinandresen: yes, even if it would be with 're-download the block chain' 
 578 2011-11-21 15:12:58 <sipa> it's not hard to fix that problem, actually
 579 2011-11-21 15:13:19 <sipa> i believe we came up with an easy solution here on IRC, but i don't remember the details
 580 2011-11-21 15:13:38 <gavinandresen> if only we had an issue tracker to remember things like that for us.....
 581 2011-11-21 15:13:44 <sipa> :D
 582 2011-11-21 15:14:40 <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
 583 2011-11-21 15:14:45 <gavinandresen> Actually, is there an issue about wallet backups?
 584 2011-11-21 15:15:56 <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
 585 2011-11-21 15:16:14 <etotheipi_> it will seek back to every 64-byte private key, and overwrite with the new encrypted key, in place
 586 2011-11-21 15:16:33 <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
 587 2011-11-21 15:16:33 <etotheipi_> but otherwise, every new piece of data that is added is append-only
 588 2011-11-21 15:16:58 <etotheipi_> wumpus, why?
 589 2011-11-21 15:17:16 <wumpus> etotheipi_: because you want to back up your address book/settings as well as the crypto keys ...
 590 2011-11-21 15:18:28 HaltingState2 has quit (Quit: Leaving)
 591 2011-11-21 15:18:38 <gavinandresen> (there is already an issue about making it easier to backup your wallet: https://github.com/bitcoin/bitcoin/issues/370)
 592 2011-11-21 15:18:51 copumpkin has quit (Quit: Computer has gone to sleep.)
 593 2011-11-21 15:19:37 <wumpus> gavinandresen: yes that's a good idea, there should be a file > backup option
 594 2011-11-21 15:19:44 <sipa> i've been using my export wallet function for backups
 595 2011-11-21 15:20:00 <sipa> i trust a human readable file more than bdb files, actually
 596 2011-11-21 15:20:11 <wumpus> it would be the export wallet function, it'd only require some extra UI code
 597 2011-11-21 15:20:45 <wumpus> human readable and encrypted do not go together though :p
 598 2011-11-21 15:21:08 <sipa> only the secret keys are encrypted :)
 599 2011-11-21 15:21:39 <wumpus> well the advantage of backing it up in bdb format is that it's easy to restore it
 600 2011-11-21 15:21:40 <gavinandresen> I think a simple backup wallet.dat function in the GUI would be a great feature for the 0.5.1 release
 601 2011-11-21 15:22:02 <sipa> true, but it also means that if it is corrupted, you're out of luck
 602 2011-11-21 15:22:04 <wumpus> you could export it in json, xml, whatever but it'd require a conversion step also to go back to a wallet.dat
 603 2011-11-21 15:22:20 <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.
 604 2011-11-21 15:22:23 <wumpus> nah some forensics go a long way as etotheipi_ proved :P
 605 2011-11-21 15:22:41 <sipa> gavinandresen: i hope key import/export...?
 606 2011-11-21 15:22:46 <etotheipi_> :)
 607 2011-11-21 15:22:52 btc_novice has joined
 608 2011-11-21 15:23:51 HaltingState has joined
 609 2011-11-21 15:23:51 HaltingState has quit (Changing host)
 610 2011-11-21 15:23:51 HaltingState has joined
 611 2011-11-21 15:24:29 <wumpus> ui-wise: caps check for askpassphrasedialog, qrcode generation
 612 2011-11-21 15:25:09 <gavinandresen> sipa:  removeprivkey still makes me nervous, but straight import/export seems ok.  Then again wallet encryption seemed ok.....
 613 2011-11-21 15:25:31 <gavinandresen> wumpus: ack on both of those
 614 2011-11-21 15:25:47 <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?
 615 2011-11-21 15:26:19 <sipa> hmm... that can still interfere with account balances
 616 2011-11-21 15:26:27 <gavinandresen> yup
 617 2011-11-21 15:26:33 <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
 618 2011-11-21 15:28:01 <sipa> gavinandresen: frankly, i think that a warning text should suffice - RPC users should not be idiots
 619 2011-11-21 15:29:01 <wumpus> is there any use in removing private keys?
 620 2011-11-21 15:29:10 <riush> or a compile-time flag?
 621 2011-11-21 15:29:16 <wumpus> doesn't it open a ton of security issues?
 622 2011-11-21 15:29:30 <wumpus> you almost can't be sure you've really purged the key from existence
 623 2011-11-21 15:29:48 <wumpus> so it's dangerous in more than one way
 624 2011-11-21 15:30:02 <gavinandresen> you almost certainly haven't, there will be copies of it in the wallet.dat and transaction log....
 625 2011-11-21 15:30:11 <sipa> but not in your wallet
 626 2011-11-21 15:30:26 <wumpus> it's dangerous to rely on it to be secure and it's dangerous for accidental damage
 627 2011-11-21 15:30:38 <sipa> use case: creating redeemable vouchers, like bitbills and casascius' coins
 628 2011-11-21 15:30:58 <gavinandresen> they can run a patched bitcoind, like they are now.
 629 2011-11-21 15:31:01 <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
 630 2011-11-21 15:31:26 <sipa> but in fact, those should be done on an off-line computer, using a wallet that never touches internet-connected hardware
 631 2011-11-21 15:31:56 <wumpus> yeah let's hope they are ...
 632 2011-11-21 15:32:01 <sipa> they are, afaik
 633 2011-11-21 15:32:18 <sipa> not having this RPC would force them to use a wallet that is destroyed afterwards
 634 2011-11-21 15:32:25 <sipa> and that is probably what should be done anyway
 635 2011-11-21 15:32:28 <gavinandresen> yup
 636 2011-11-21 15:32:29 <wumpus> sounds good
 637 2011-11-21 15:32:30 <wumpus> yeah
 638 2011-11-21 15:32:34 * luke-jr agrees keys shouldn't be deletable :P
 639 2011-11-21 15:32:43 <sipa> so, ok, i'll remove removeprivkey from the pull request
 640 2011-11-21 15:33:33 <wumpus> great
 641 2011-11-21 15:33:33 <gavinandresen> speaking of private keys in wallets... the wallet should be rewritten when the passphrase changes
 642 2011-11-21 15:34:11 <wumpus> oh good point otherwise there will be keys left behind encrypted with the old key
 643 2011-11-21 15:34:16 <gavinandresen> yup
 644 2011-11-21 15:34:41 <gavinandresen> I don't think that is a show-stopper bug, but it should be fixed for 0.5.1
 645 2011-11-21 15:34:44 <sipa> that should be easy - just call Rewrite again from the change passphase code?
 646 2011-11-21 15:35:15 <wumpus> I guess so, but it'd require a new round of testing, so I agree we can postpone it to 0.5.1
 647 2011-11-21 15:35:25 <sipa> agree
 648 2011-11-21 15:35:29 <gavinandresen> It'd be nice if it didn't require a client shutdown/restart
 649 2011-11-21 15:35:56 <sipa> if you can block until all db handles are released, you can stop/start cycle the dbenv
 650 2011-11-21 15:35:57 <gavinandresen> I'll open an issue...
 651 2011-11-21 15:36:08 <gmaxwell> but.. wait, how will users with currently screwed up wallets get fixed if it doesn't do this now?
 652 2011-11-21 15:36:40 <sipa> gmaxwell: it rewrites upon encryption and on startup on loading a non-rewritten encrypted wallet
 653 2011-11-21 15:36:50 <sipa> gmaxwell: but not when changing the passphrase
 654 2011-11-21 15:36:54 <luke-jr> gavinandresen: features should be 0.6, not 0.5.1 :P
 655 2011-11-21 15:37:12 <gmaxwell> ah, okay, one way to handle the passphrase change would just be setting the non-rewritten encrypted wallet flag.
 656 2011-11-21 15:37:32 <sipa> the only thing that can leak when changing the passphrase is the old mkey record, by the way
 657 2011-11-21 15:37:36 <sipa> as the keys themselves aren't changed
 658 2011-11-21 15:37:49 <gavinandresen> there is no such flag any more-- I change the code to check to see what version wrote the wallet.
 659 2011-11-21 15:37:50 <wumpus> ahh the keys are not reencrypted?
 660 2011-11-21 15:37:56 <gmaxwell> luke-jr: not leaking old encrypted keying materials.. is a bugfix.
 661 2011-11-21 15:38:18 <sipa> wumpus: no, there is a master key record, derived from the passphrase and salt
 662 2011-11-21 15:38:36 <sipa> but the master key is generated once, at random
 663 2011-11-21 15:38:50 <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.
 664 2011-11-21 15:38:53 <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.
 665 2011-11-21 15:39:02 <gmaxwell> luke-jr: sorry, I fail at reading.
 666 2011-11-21 15:39:09 danbri has quit (Remote host closed the connection)
 667 2011-11-21 15:39:17 <wumpus> gmaxwell: yes it makes sense
 668 2011-11-21 15:39:26 <sipa> it was inspired by LUKS, indeed :)
 669 2011-11-21 15:39:48 <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 ?
 670 2011-11-21 15:40:08 <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
 671 2011-11-21 15:40:11 <wumpus> yes let's not get caught up in version number politics
 672 2011-11-21 15:41:09 <gmaxwell> luke-jr: that would be a good feature... (it should compact the darn thing first too)
 673 2011-11-21 15:41:37 * sipa mentions he has a compact export-to-json feature
 674 2011-11-21 15:41:56 <wumpus> nah if you want to encrypt/compact it makes sense to use another export format
 675 2011-11-21 15:41:59 <wumpus> exaclty sipa
 676 2011-11-21 15:42:29 <luke-jr> [09:24:20] <gavinandresen> eueueue: not a show-stopper bug <-- what's the rush to release 0.5? :P
 677 2011-11-21 15:42:38 <[Tycho]> Did someone tried that getmemorypool patch ?
 678 2011-11-21 15:42:39 <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 
 679 2011-11-21 15:42:49 <sipa> wumpus: also exists
 680 2011-11-21 15:42:54 <luke-jr> [Tycho]: working fine here.
 681 2011-11-21 15:43:02 <luke-jr> [Tycho]: interested in collaborating on my new pool server? :P
 682 2011-11-21 15:43:12 <sipa> wumpus: see my showwallet branch
 683 2011-11-21 15:43:21 <wumpus> sipa: you can also import the json files?
 684 2011-11-21 15:43:25 <sipa> yes
 685 2011-11-21 15:43:26 <[Tycho]> luke-jr: does it exports the entire pool or only those TXes that are really going into the next block ?
 686 2011-11-21 15:43:33 <sipa> (it doesn't include the actual transactions, it uses rescanning to find those)
 687 2011-11-21 15:43:33 copumpkin has joined
 688 2011-11-21 15:43:34 <wumpus> what happens if the user already has keys in the wallet and does import?
 689 2011-11-21 15:43:39 <luke-jr> [Tycho]: huh?
 690 2011-11-21 15:43:46 <sipa> wumpus: works perfectly
 691 2011-11-21 15:43:49 <wumpus> good
 692 2011-11-21 15:43:50 <[Tycho]> luke-jr: what collaboration do you mean ?
 693 2011-11-21 15:43:52 <sipa> you just get a merged wallet
 694 2011-11-21 15:43:53 <luke-jr> [Tycho]: oh, getmemorypool just lists tx accepted for the block
 695 2011-11-21 15:43:54 <wumpus> so they're merged?
 696 2011-11-21 15:43:55 <wumpus> right
 697 2011-11-21 15:44:14 <wumpus> what about labels/address book?
 698 2011-11-21 15:44:26 <gavinandresen> https://github.com/bitcoin/bitcoin/issues/651
 699 2011-11-21 15:44:26 <luke-jr> [Tycho]: I wrote a Python pool server using it; it could use some improvements, so I'm planning to AGPL it
 700 2011-11-21 15:44:37 <luke-jr> [Tycho]: http://eligius.st/~luke-jr/.eloipool.git
 701 2011-11-21 15:44:44 <sipa> wumpus: it's not really a "Satoshi client wallet dump to json" function, but more a "export to wallet interchange format"
 702 2011-11-21 15:44:49 <[Tycho]> Python pool server using what ?
 703 2011-11-21 15:44:50 <wumpus> sipa: if that all already works and exists, I suppose we should use your code 
 704 2011-11-21 15:45:05 <luke-jr> [Tycho]: using getmemorypool
 705 2011-11-21 15:45:16 <luke-jr> [Tycho]: it builds the blocks itself
 706 2011-11-21 15:45:26 <[Tycho]> Oh, I don't know Python.
 707 2011-11-21 15:45:30 <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)
 708 2011-11-21 15:45:37 <wumpus> sipa: well as long as it can represent anything the user can possibly do in satoshi client, it's fine with me
 709 2011-11-21 15:45:47 <wumpus> the labels are *really* important
 710 2011-11-21 15:46:11 <wumpus> I wouldn't even recognize my own wallet if it didn't have the labels anymore
 711 2011-11-21 15:46:16 <sipa> wumpus: https://github.com/bitcoin/bitcoin/pull/220
 712 2011-11-21 15:46:20 <sipa> it supports labels
 713 2011-11-21 15:46:25 <[Tycho]> I think I should create a new client...
 714 2011-11-21 15:46:32 <luke-jr> [Tycho]: it's not that complicated ;p
 715 2011-11-21 15:46:44 <wumpus> oh no ,not another client, just work on improving one of the existing ones
 716 2011-11-21 15:47:03 <[Tycho]> There are no existing ones except for gavin's
 717 2011-11-21 15:47:20 <[Tycho]> Also there is still no light clients.
 718 2011-11-21 15:47:24 <sipa> there are many projects underway that are creating new ones
 719 2011-11-21 15:47:27 <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
 720 2011-11-21 15:47:57 <luke-jr> [Tycho]: for pool purposes, my Python poolserver mostly replaces bitcoind
 721 2011-11-21 15:48:01 <sipa> wumpus: if we go that way, maybe it should contain the transactions themselves too
 722 2011-11-21 15:48:11 <sipa> (at least optionally)
 723 2011-11-21 15:48:16 <wumpus> sipa: maybe.. but all user-entered stuff should be in there
 724 2011-11-21 15:48:20 <wumpus> that's what a backup is for :-)
 725 2011-11-21 15:48:34 <sipa> well, it wasn't really intended as backup (though that is how i use it myself)
 726 2011-11-21 15:48:47 <wumpus> well it's a good starting point
 727 2011-11-21 15:48:53 <wumpus> we can make it into a backup solution
 728 2011-11-21 15:48:57 <[Tycho]> luke-jr: why your generation TX sends most outputs do addresses and just one output to pubkey ?
 729 2011-11-21 15:48:58 <sipa> true
 730 2011-11-21 15:49:02 <[Tycho]> *to
 731 2011-11-21 15:49:20 <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?
 732 2011-11-21 15:49:39 <luke-jr> [Tycho]: because I only have addresses for miners
 733 2011-11-21 15:49:48 <gavinandresen> luke-jr: what bugs?
 734 2011-11-21 15:49:58 <luke-jr> gavinandresen: the black box tooltip, for example
 735 2011-11-21 15:50:09 <[Tycho]> luke-jr: that one pubkey is for your pool fees ?
 736 2011-11-21 15:50:37 <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.
 737 2011-11-21 15:50:45 <luke-jr> [Tycho]: no, for reward that has no pending payout
 738 2011-11-21 15:50:47 <gavinandresen> ... and I'm tired of spinning release candidates.
 739 2011-11-21 15:50:50 ThomasV has quit (Quit: Leaving)
 740 2011-11-21 15:51:03 <luke-jr> gavinandresen: unusable black box != imperfect
 741 2011-11-21 15:51:38 <luke-jr> wumpus: any leads on that bug btw?
 742 2011-11-21 15:52:43 <[Tycho]> How the Old Ones knew the pubkey for their destination ? Or it's sending to self ? http://blockexplorer.com/tx/150e5423ef17f319edcebb2a2e9e1c9dff8313b21cdc1c14bfc6da19e09869db
 743 2011-11-21 15:53:53 <luke-jr> [Tycho]: first output is always "self"
 744 2011-11-21 15:53:56 <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
 745 2011-11-21 15:54:15 <wumpus> luke-jr: scroll back a bit, that's all I know about it
 746 2011-11-21 15:54:34 <[Tycho]> luke-jr: I don't think so.
 747 2011-11-21 15:54:45 <[Tycho]> Look at the link.
 748 2011-11-21 15:55:25 p0s has joined
 749 2011-11-21 15:55:35 <wumpus> sipa: if you have two wallets open, do they share address book? if so, where is it stored? etc
 750 2011-11-21 15:55:45 <sipa> wumpus: good questions
 751 2011-11-21 15:56:03 <sipa> having wallet-specifiek address books is definitely easier
 752 2011-11-21 15:56:17 <wumpus> yes I think that's fine actually
 753 2011-11-21 15:56:23 <sipa> but that will probably mean a "copy address book from X to Y" function in the GUI
 754 2011-11-21 15:56:31 <wumpus> and allow drag and drop to copy contacts between wallets
 755 2011-11-21 15:56:52 <sipa> that'd be very nice
 756 2011-11-21 15:57:01 <wumpus> ok, so the address book *is* part of the wallet, nice to clear that up...
 757 2011-11-21 15:57:04 danbri has joined
 758 2011-11-21 15:57:09 <wumpus> I've wondered about that before
 759 2011-11-21 15:57:37 <wumpus> that leaves program configuration
 760 2011-11-21 15:57:47 <wumpus> that should be in a separate file probably
 761 2011-11-21 15:57:55 <sipa> yes, i agree
 762 2011-11-21 15:58:21 <wumpus> it's also not really important to backup that :-)
 763 2011-11-21 15:58:29 <[Tycho]> wumpus: what is your project ?
 764 2011-11-21 15:58:36 Turingi has joined
 765 2011-11-21 15:58:36 Turingi has quit (Changing host)
 766 2011-11-21 15:58:36 Turingi has joined
 767 2011-11-21 15:58:45 <wumpus> [Tycho]: bitcoin-qt
 768 2011-11-21 15:59:25 Tritonio has quit (Quit: Leaving.)
 769 2011-11-21 16:01:10 <wumpus> luke-jr: I agree the black box should be solved, but we should be realistic as to our priorities
 770 2011-11-21 16:01:50 <wumpus> luke-jr: if we worry about small license changes, icons, and little rendering issues all day we'll get nowhere
 771 2011-11-21 16:02:22 <wumpus> at least with the limited development resources we have now...
 772 2011-11-21 16:02:42 <luke-jr> wumpus: afaik the bigger issue is solved
 773 2011-11-21 16:03:03 <wumpus> yep
 774 2011-11-21 16:03:34 <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
 775 2011-11-21 16:03:36 <[Tycho]> luke-jr: what "first" output ? There is only one in that TX
 776 2011-11-21 16:03:40 darkmethod has joined
 777 2011-11-21 16:04:21 <[Tycho]> And it's not a generation.
 778 2011-11-21 16:05:37 iocor has quit (Quit: Computer has gone to sleep.)
 779 2011-11-21 16:06:40 <luke-jr> [Tycho]: oh, then I don't know what it has to do with me
 780 2011-11-21 16:07:23 <[Tycho]> The initial question wasn't addresses to you :)
 781 2011-11-21 16:07:26 <luke-jr> o
 782 2011-11-21 16:08:12 <luke-jr> wumpus: btw, you're both "John Smith" and Wladimir, right?
 783 2011-11-21 16:08:15 <[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 ?
 784 2011-11-21 16:08:55 <luke-jr> [Tycho]: it's probably "change". and probably uses an address now to make it harder to identify which one is change
 785 2011-11-21 16:09:21 <sipa> [Tycho]: the official client only sends to pubkeys for generations and (earlier) for send-to-IP
 786 2011-11-21 16:09:37 <[Tycho]> Oh, so it was possibly send-to-IP !
 787 2011-11-21 16:09:41 <[Tycho]> Mystery solved.
 788 2011-11-21 16:10:46 eueueue has quit (Ping timeout: 265 seconds)
 789 2011-11-21 16:11:30 eueueue has joined
 790 2011-11-21 16:17:24 wasabi1 has joined
 791 2011-11-21 16:18:54 <wumpus> luke-jr: I'm known by many names :-)
 792 2011-11-21 16:19:34 <sipa> wumpus: so, nice project for 0.6.0: multi-wallet support :)
 793 2011-11-21 16:20:32 <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
 794 2011-11-21 16:20:46 Diablo-D3 has quit (Ping timeout: 255 seconds)
 795 2011-11-21 16:20:48 * luke-jr thinks Bitcoin-Qt might be making enough traction to adopt a more Linux-style release pattern
 796 2011-11-21 16:21:18 <luke-jr> ie, once 0.5.0 is done, we have quite a few features ready to merge for 0.6
 797 2011-11-21 16:21:39 <sipa> we need something like a linux-next repo
 798 2011-11-21 16:21:41 <luke-jr> so 0.6rc1 could probably be literally a week after 0.5.0 is out
 799 2011-11-21 16:21:51 <wumpus> yes I think that's the case, my bitcoin-qt branch already contains some ui improvements for testing
 800 2011-11-21 16:23:56 asuk has joined
 801 2011-11-21 16:24:34 <luke-jr> fwiw, setting QT_X11_NO_MITSHM=1 makes that black box sometimes greenish
 802 2011-11-21 16:24:45 <luke-jr> why are those different from every other tooltip?
 803 2011-11-21 16:25:17 <luke-jr> wumpus: what version of Qt does it work right on?
 804 2011-11-21 16:25:49 <wumpus> the tooltip is the same as any other tooltip
 805 2011-11-21 16:26:02 <wumpus> it's  rendered by qt, not by custom code
 806 2011-11-21 16:26:22 <luke-jr> every other tooltip works…
 807 2011-11-21 16:26:26 <luke-jr> where is the code for that tooltip?
 808 2011-11-21 16:26:37 <luke-jr> I couldn't find it (though I could find every other one on that page)
 809 2011-11-21 16:27:10 <wumpus> overviewpage.cpp contains the rendering delegate for the transactions onthe overview page
 810 2011-11-21 16:27:29 <luke-jr> but not the tooltip…
 811 2011-11-21 16:27:40 <wumpus> that's what I said
 812 2011-11-21 16:27:55 <wumpus> there is no code for rendering that tooltip
 813 2011-11-21 16:27:56 <luke-jr> so where is the tooltip? :P
 814 2011-11-21 16:28:10 <luke-jr> the tooltip content has to be assigned *somewhere*
 815 2011-11-21 16:28:10 eueueue has quit (Ping timeout: 265 seconds)
 816 2011-11-21 16:28:13 <wumpus> it simply uses the qt item view
 817 2011-11-21 16:28:18 <wumpus> yes the content comes from the model
 818 2011-11-21 16:28:30 <luke-jr> doesn't the Transactions page use the qt item view?
 819 2011-11-21 16:28:38 <wumpus> the same tooltip content is used in the transactions page
 820 2011-11-21 16:28:39 <wumpus> yes
 821 2011-11-21 16:28:39 coingenuity has quit (Ping timeout: 240 seconds)
 822 2011-11-21 16:28:50 * luke-jr peers
 823 2011-11-21 16:29:07 <luke-jr> wumpus: any idea if I can pass Qt command line options to bitcoin-qt?
 824 2011-11-21 16:29:16 <wumpus> qt calls data() on the model with TooltipRole
 825 2011-11-21 16:29:29 <wumpus> yes you should be able to
 826 2011-11-21 16:29:38 <wumpus> qt gets first shot at the command line arguments
 827 2011-11-21 16:31:47 <luke-jr> hmm
 828 2011-11-21 16:31:54 <wumpus> but yeah it must be some rendering operation *before* the tooltip drawing that messes up the painter state
 829 2011-11-21 16:32:41 <wumpus> but txviewdelegate::paint does save and restore the painter state properly, so I don't see the problem
 830 2011-11-21 16:34:10 <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)
 831 2011-11-21 16:38:47 <luke-jr> something is forcing the tooltip bg to black
 832 2011-11-21 16:40:18 <wumpus>  not neccesarily black, it makes that the tooltip background is not initialized
 833 2011-11-21 16:40:35 <wumpus> which means transparent on mac, and black on linux sometimes and sometimes random buffer patterns
 834 2011-11-21 16:41:55 <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
 835 2011-11-21 16:43:44 <wumpus> if there is no bug in there it must be a qt issue
 836 2011-11-21 16:44:23 <wumpus> (ie, tooltip does not draw succesfully with a custom delegate on certain version of qt)
 837 2011-11-21 16:45:32 <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/
 838 2011-11-21 16:46:20 <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....
 839 2011-11-21 16:47:33 BlueMatt has joined
 840 2011-11-21 16:47:36 <gavinandresen> ... hmm, no, changed my mind, I'll upload binaries to 0.4.1 while I'm eating lunch
 841 2011-11-21 16:48:26 <BlueMatt> gavinandresen: so 0.5 is out
 842 2011-11-21 16:48:31 <BlueMatt> ?
 843 2011-11-21 16:48:36 <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/
 844 2011-11-21 16:48:41 <BlueMatt> mmm
 845 2011-11-21 16:49:28 <gavinandresen> I'm saying it is enough better than 0.4.0 to release.
 846 2011-11-21 16:49:33 <luke-jr> wumpus: no, pretty sure it's black
 847 2011-11-21 16:49:56 <wumpus> luke-jr: for gavinandresen it is transparent, scroll back a bit he posted a screenshot...
 848 2011-11-21 16:50:08 <BlueMatt> gavinandresen: mmm, not sure about that as a measurement for release of financial software, but mehj
 849 2011-11-21 16:50:11 <luke-jr> hmm
 850 2011-11-21 16:50:28 <luke-jr> gavinandresen: why am I wasting time trying to help fix this when you're just going to ignore bugs?
 851 2011-11-21 16:50:28 <gavinandresen> BlueMatt: any show-stopper issues on your list?
 852 2011-11-21 16:50:31 ThomasV has joined
 853 2011-11-21 16:50:39 <BlueMatt> gavinandresen: not really
 854 2011-11-21 16:50:40 <gavinandresen> luke-jr: what bugs?
 855 2011-11-21 16:50:46 <helo> i get the same behavior (apparent uninitialized pixmaps) with flash plugins in chrome
 856 2011-11-21 16:50:54 <luke-jr> gavinandresen: tooltips being totally broken on the overview
 857 2011-11-21 16:51:17 <helo> i would not at all be surprised if it is an upstream (library) bug
 858 2011-11-21 16:51:21 <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
 859 2011-11-21 16:51:21 <wumpus> meh, if you want to see the tooltip so bad go to the transaction page it shows the same tooltip...
 860 2011-11-21 16:51:25 <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
 861 2011-11-21 16:51:26 <luke-jr> wumpus: I commented out TxViewDelegate::paint's code, and it still happens
 862 2011-11-21 16:51:37 <helo> luke-jr: are you using compiz?
 863 2011-11-21 16:51:41 <luke-jr> helo: no
 864 2011-11-21 16:51:44 <helo> i am not either :)
 865 2011-11-21 16:51:51 <helo> i bet it works properly with copmiz
 866 2011-11-21 16:51:57 <luke-jr> gavinandresen: doesn't work fine on my PC
 867 2011-11-21 16:52:10 <luke-jr> helo: what DE?
 868 2011-11-21 16:52:13 <helo> fluxbox
 869 2011-11-21 16:52:20 <luke-jr> helo: what Qt ver?
 870 2011-11-21 16:52:24 <gavinandresen> luke-jr: good to know.  what version of windows?
 871 2011-11-21 16:52:31 <luke-jr> gavinandresen: I don't use Windows.
 872 2011-11-21 16:52:48 <wumpus> helo: I wouldn't be surprised if it was an upstream issue either
 873 2011-11-21 16:52:56 <sipa> he obviously means "what version of XWindows" !
 874 2011-11-21 16:52:59 eueueue has joined
 875 2011-11-21 16:53:07 <wumpus> luke-jr: if it still happens with the paint method commented out, then it can't be an issue in the drawing code
 876 2011-11-21 16:53:12 <gavinandresen> luke-jr:         so when I say PC I mean Windows, old habit, hard to break.....
 877 2011-11-21 16:53:18 <wumpus> luke-jr: except if the paint code should do something it currently does not
 878 2011-11-21 16:53:21 <sipa> sure starts to sound like an upstream issue
 879 2011-11-21 16:53:26 Nesetalis has quit (Read error: Connection reset by peer)
 880 2011-11-21 16:53:39 Nesetalis has joined
 881 2011-11-21 16:53:54 <wumpus> luke-jr: but abstractitemdelegate is an abstract class -- so it can't really call the parent class paint method
 882 2011-11-21 16:53:57 <gavinandresen> luke-jr:       and you're SO CLOSE to going on my ignore list... are you TRYING to push my buttons?
 883 2011-11-21 16:54:30 <helo> libQtCore.so.4.7.4
 884 2011-11-21 16:54:42 <wumpus> and afaik item delegates have nothing to do with tooltip drawing
 885 2011-11-21 16:55:10 <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?
 886 2011-11-21 16:55:17 <helo> also, 64-bit
 887 2011-11-21 16:55:22 <luke-jr> otherwise I could just ignore the bug and let someone else fix it in due time
 888 2011-11-21 16:55:23 <wumpus> I'm not *completely* sure about that though
 889 2011-11-21 16:56:08 <helo> has anyone seen the bug not running linux, 64-bit, non-compiz?
 890 2011-11-21 16:56:17 <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
 891 2011-11-21 16:57:00 <helo> it is a platform-specific cosmetic bug at worst
 892 2011-11-21 16:57:04 Raccoon- is now known as Raccoon
 893 2011-11-21 16:57:24 <wumpus> you could safely ignore the bug if you want to or help fixing it, either way it's up to you
 894 2011-11-21 16:57:30 <luke-jr> no reason to rush 0.5.0 out the door
 895 2011-11-21 16:57:30 <wumpus> I don't see what the release schedule has to do with it
 896 2011-11-21 16:57:51 <luke-jr> .0 should be "no known bugs"
 897 2011-11-21 16:58:11 <wumpus> this is really starting to annoy me
 898 2011-11-21 16:58:13 <helo> 0.5.0 includes important bug fixes as-is, so why delay their dissemination because of a non-important bug?
 899 2011-11-21 16:58:24 <luke-jr> helo: those important bug fixes are in 0.4.1
 900 2011-11-21 16:58:37 <wumpus> it's a fricking tooltip
 901 2011-11-21 16:59:02 <luke-jr> whatever, arguing about it is wasting more time than fixing it
 902 2011-11-21 16:59:09 <wumpus> well then fix it
 903 2011-11-21 16:59:11 <helo> heh
 904 2011-11-21 16:59:12 <wumpus> if you think it's so simple
 905 2011-11-21 16:59:29 <BlueMatt> how about someone fix it, then we can get 5.1 out the door in like a day, and everyone will be happy?
 906 2011-11-21 16:59:34 <wumpus> I think we just ran out of possible options to fix it in the scope of bitcoin-qt
 907 2011-11-21 16:59:49 * luke-jr is thinking he can fix it in under an hour, actually
 908 2011-11-21 16:59:54 <BlueMatt> then file it upstream and stop complaining
 909 2011-11-21 17:00:02 <BlueMatt> or fix it, either way stop complaining
 910 2011-11-21 17:00:13 <wumpus> I'm not complaining
 911 2011-11-21 17:01:11 <Lolcust> !seen batouzo
 912 2011-11-21 17:01:11 <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).
 913 2011-11-21 17:01:11 <gribble> batouzo was last seen in #bitcoin-dev 5 hours, 53 minutes, and 31 seconds ago: <batouzo> you will announce on European conference?
 914 2011-11-21 17:01:32 <BlueMatt> why do we have two bots that have the same control sequence, nanotube?
 915 2011-11-21 17:01:41 zyxwvut has joined
 916 2011-11-21 17:03:02 <Lolcust> Redundancy is so redundant
 917 2011-11-21 17:03:16 <sipa> :D
 918 2011-11-21 17:04:33 danbri has quit (Remote host closed the connection)
 919 2011-11-21 17:07:04 <jgarzik> tcatm: yep, if you need any DNS seed details, just ask.  we need more!
 920 2011-11-21 17:07:14 iocor has joined
 921 2011-11-21 17:08:21 <[Tycho]> Lolcust: what is your project ?
 922 2011-11-21 17:08:56 <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
 923 2011-11-21 17:09:00 <cocktopus> jgarzik: what sort of system requirements are necessary for a decent dnsseed (besides good connectivity and uptime of course)?
 924 2011-11-21 17:09:46 erus` has quit (Remote host closed the connection)
 925 2011-11-21 17:10:28 <wumpus> luke-jr: but as I understand it, it should not be needed to override that unless you want to change the behaviour
 926 2011-11-21 17:11:07 Tritonio has joined
 927 2011-11-21 17:11:24 <BlueMatt> cocktopus: nearly nothing
 928 2011-11-21 17:11:40 <BlueMatt> jgarzik: did you ever write that cleaner dnsseed software?
 929 2011-11-21 17:11:59 <BlueMatt> cocktopus: maybe like ~256M ram and good connectivity
 930 2011-11-21 17:12:07 <cocktopus> sounds cool
 931 2011-11-21 17:12:29 <BlueMatt> and plenty of community trust (as there are some theoretical attacks by dnsseed controllers)
 932 2011-11-21 17:12:47 <cocktopus> i've been considering putting one up, but it sounds like it could be subject to ddos
 933 2011-11-21 17:12:51 <cocktopus> which isnt fun
 934 2011-11-21 17:12:52 Tritonio has quit (Client Quit)
 935 2011-11-21 17:13:04 <BlueMatt> I havent seen any ddos on mine (afaik)
 936 2011-11-21 17:13:09 <[Tycho]> BlueMatt: what is your project ?
 937 2011-11-21 17:13:17 <BlueMatt> my project?
 938 2011-11-21 17:13:25 danbri has joined
 939 2011-11-21 17:13:26 <[Tycho]> Yes. Do you have any ?
 940 2011-11-21 17:13:39 <BlueMatt> any projects? I suppose not...
 941 2011-11-21 17:13:40 TD has joined
 942 2011-11-21 17:13:46 <wumpus> cocktopus: yes it would probably be best to a vps with a limited bandwidth/month that cuts off after that
 943 2011-11-21 17:14:17 <BlueMatt> no, if it cuts off you should be able to forward the dns first so that you dont have downtime...
 944 2011-11-21 17:14:29 <wumpus> otherwise I guess a ddos could be really expensive
 945 2011-11-21 17:14:37 <BlueMatt> gavinandresen: when you do the release announce of 0.5, please do mention the ubuntu ppa
 946 2011-11-21 17:14:57 <wumpus> BlueMatt: so it's not robust against one of the dnsseeds going down?
 947 2011-11-21 17:15:13 <gavinandresen> BlueMatt: tell me again what I should say?  I don't think you sent me email last time....
 948 2011-11-21 17:15:46 <luke-jr> this doesn't make sense :/
 949 2011-11-21 17:15:57 <luke-jr> I got rid of TxViewDelegate entirely, and it still breaks
 950 2011-11-21 17:15:59 <wumpus> luke-jr: don't say I didn't tell you so :-)
 951 2011-11-21 17:16:14 <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."
 952 2011-11-21 17:16:15 Lolcust has quit (Quit: Oh shi...)
 953 2011-11-21 17:16:28 <wumpus> luke-jr: so it happens even with the default delegate?
 954 2011-11-21 17:16:29 <luke-jr> wumpus: well, it has to be *something* in Bitcoin-Qt, or else it wouldn't work in the transaction list either… :/
 955 2011-11-21 17:16:34 <luke-jr> wumpus: yes
 956 2011-11-21 17:16:41 Lolcust has joined
 957 2011-11-21 17:16:44 <wumpus> hmm...
 958 2011-11-21 17:16:55 <sipa> does valgrind find any uninitialized memory?
 959 2011-11-21 17:16:59 <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
 960 2011-11-21 17:17:08 <gavinandresen> BlueMatt: "new ppa maintained by Matt Corallo..."  ?  I want to be very careful about letting people know who is responsible for what
 961 2011-11-21 17:17:16 <BlueMatt> gavinandresen: yes, absolutely
 962 2011-11-21 17:17:16 <wumpus> BlueMatt: ooh :(
 963 2011-11-21 17:17:47 <sipa> is there a ticket for that already?
 964 2011-11-21 17:17:54 <sipa> dns seeding should go to a separate thread
 965 2011-11-21 17:18:01 <wumpus> luke-jr: the transaction list is a table view, not a item list view, that's the only difference I can think of
 966 2011-11-21 17:18:24 <BlueMatt> sipa: dont think there is a ticket, but it was discussed briefly here
 967 2011-11-21 17:18:37 <sipa> if not, make sure we have one, so it isn't forgotten
 968 2011-11-21 17:18:53 <BlueMatt> sipa: and yea, it really shouldnt be in AppInit2, should take like 20 secs to whip up a  fix
 969 2011-11-21 17:19:04 devrandom has joined
 970 2011-11-21 17:19:06 <wumpus> that explains why a while ago bitcoin wouldn't start here, appearantly waiting for reply from my router...
 971 2011-11-21 17:19:29 <sipa> dnsseed could also re-run every few hours or so
 972 2011-11-21 17:19:35 <luke-jr> wumpus: making it a table yields very curious output
 973 2011-11-21 17:19:37 <wumpus> which cost me a few hours because I thought it was a problem in my gitian build process :')
 974 2011-11-21 17:19:52 <luke-jr> wumpus: the headings are ALSO black on black
 975 2011-11-21 17:19:55 <BlueMatt> sipa: meh, its a bootstrap mechanism, relying too heavily on it to stay connected to the network isnt so good imho
 976 2011-11-21 17:20:01 <sipa> BlueMatt: agree
 977 2011-11-21 17:20:16 <sipa> the network is better for remaining connected
 978 2011-11-21 17:20:26 <wumpus> yep it starts with 0 connections anyway
 979 2011-11-21 17:20:34 <wumpus> luke-jr: curious
 980 2011-11-21 17:21:42 <luke-jr> wumpus: is there no .ui for the txn list? :/
 981 2011-11-21 17:23:23 <wumpus> luke-jr: there isn't, all the code is in transactionview.cpp
 982 2011-11-21 17:23:27 <luke-jr> i c
 983 2011-11-21 17:23:46 <wumpus> there is very little there that could be initialized from a form file
 984 2011-11-21 17:24:10 chrisb__ has joined
 985 2011-11-21 17:26:08 <luke-jr> AHAHAHAHA
 986 2011-11-21 17:26:10 <luke-jr> OMG
 987 2011-11-21 17:26:26 <wumpus> uh oh, luke-jr has gone mad :)
 988 2011-11-21 17:26:27 <luke-jr> ui->listTransactions->setStyleSheet("background:transparent");
 989 2011-11-21 17:26:42 <luke-jr> there's the culprit
 990 2011-11-21 17:26:45 <wumpus> LOL
 991 2011-11-21 17:26:52 <wumpus> wtf
 992 2011-11-21 17:27:07 <wumpus> why does that apply to the tooltip
 993 2011-11-21 17:27:11 <luke-jr> nfc
 994 2011-11-21 17:27:41 <wumpus> if you comment out that line the background will be white instead of window-background-grey...
 995 2011-11-21 17:27:42 <sipa> near field communication?
 996 2011-11-21 17:27:58 <wumpus> (the background of the list itself)
 997 2011-11-21 17:28:09 <sipa> maybe it inherits that style setting, and you need to re-set it on the tooltip itself?
 998 2011-11-21 17:28:15 <wumpus> stylesheet for the list shouldn't affect the tooltip  :/
 999 2011-11-21 17:29:00 <wumpus> hm I don't think you can set it on the tooltip yourself, QTooltip::showText handles all that
1000 2011-11-21 17:29:43 <wumpus> but maybe there is some other option to tell the list to not draw a white background, apart from a stylesheet
1001 2011-11-21 17:30:11 <wumpus> (or you could cheat and make it draw a background in the same color as the window background)
1002 2011-11-21 17:30:20 danbri has quit (Remote host closed the connection)
1003 2011-11-21 17:31:13 <wumpus> (though that will mess up with kde which has gradient window backgrounds)
1004 2011-11-21 17:32:31 cocktopus has quit (Quit: Over and out)
1005 2011-11-21 17:32:35 <luke-jr> I found a cheat.
1006 2011-11-21 17:32:41 <gavinandresen> 0.5.0 announced:  https://bitcointalk.org/index.php?topic=52480
1007 2011-11-21 17:32:43 cocktopus has joined
1008 2011-11-21 17:32:52 <luke-jr> gavinandresen: too bad we just fixed the last bug in it, eh?
1009 2011-11-21 17:33:00 <wumpus> it's not the last bug
1010 2011-11-21 17:33:06 <gavinandresen> "last bug" ?  Have you seen the issues list?
1011 2011-11-21 17:33:15 <wumpus> the good thing is that we understand it now
1012 2011-11-21 17:33:19 <wumpus> thanks luke-jr
1013 2011-11-21 17:33:47 <wumpus> at least we can scrap scary pointer or unititalized memory issues as a cause
1014 2011-11-21 17:34:11 <luke-jr> https://github.com/bitcoin/bitcoin/pull/653
1015 2011-11-21 17:34:23 <gavinandresen> Who'd I forget on the "Thanks" list?  gmaxwell did a bunch of testing....
1016 2011-11-21 17:34:45 <wumpus> hah nice fix luke-jr
1017 2011-11-21 17:35:15 <luke-jr> gavinandresen: btw, did you ever get the translators to update the "restart bitcoin" message?
1018 2011-11-21 17:35:28 <jgarzik> BlueMatt: nope
1019 2011-11-21 17:35:31 <gavinandresen> luke-jr: nope
1020 2011-11-21 17:35:34 devrandom has quit (Remote host closed the connection)
1021 2011-11-21 17:35:44 <jgarzik> BlueMatt: that's why I was open to checking your example code into contrib/
1022 2011-11-21 17:35:46 <luke-jr> oh well
1023 2011-11-21 17:35:51 <CIA-89> bitcoin: Luke Dashjr master * ra3c675d / src/qt/overviewpage.cpp : Bugfix: only make QListView transparent, not its tooltips - http://git.io/xbEJFQ
1024 2011-11-21 17:35:55 <CIA-89> bitcoin: Wladimir J. van der Laan master * rfe90327 / src/qt/overviewpage.cpp :
1025 2011-11-21 17:35:55 <CIA-89> bitcoin: Merge pull request #653 from luke-jr/bugfix_transparent_tooltip
1026 2011-11-21 17:35:55 <CIA-89> bitcoin: Bugfix: only make QListView transparent, not its tooltips - http://git.io/O7iaQA
1027 2011-11-21 17:35:57 <luke-jr> yet another thing that 0.5.0 should have waited for
1028 2011-11-21 17:36:16 devrandom has joined
1029 2011-11-21 17:36:17 <CIA-89> bitcoin: various bugfix_transparent_tooltip * ra3c675..dead0f bitcoind-personal/ (33 files in 7 dirs): (22 commits)
1030 2011-11-21 17:36:18 <sipa> hindsight is 20/20
1031 2011-11-21 17:36:26 <wumpus> "should have" hehe
1032 2011-11-21 17:36:57 <luke-jr> guess I should tag 0.4.1
1033 2011-11-21 17:37:23 <gavinandresen> luke-jr: 0.4.1 sourceforge binaries are up
1034 2011-11-21 17:37:31 <luke-jr> k
1035 2011-11-21 17:37:32 <gavinandresen> (same binaries as rc7)
1036 2011-11-21 17:37:32 <luke-jr> ty
1037 2011-11-21 17:37:37 devrandom has quit (Remote host closed the connection)
1038 2011-11-21 17:37:38 <luke-jr> how about source tarballs?
1039 2011-11-21 17:37:44 <luke-jr> or are we sticking with autogenerated now?
1040 2011-11-21 17:38:09 <gavinandresen> Is there a good reason to do it manually when github does it automagically?
1041 2011-11-21 17:38:11 <wumpus> yeah you could just link to the autogenerated one from github
1042 2011-11-21 17:38:44 <luke-jr> gavinandresen: GitHub makes weird directory names.
1043 2011-11-21 17:38:47 <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)
1044 2011-11-21 17:38:51 <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...
1045 2011-11-21 17:39:51 iocor has quit (Quit: Computer has gone to sleep.)
1046 2011-11-21 17:40:19 <luke-jr> gavinandresen: GitHub names it bitcoin-bitcoin-f5649b6 instead of bitcoin-0.5.0
1047 2011-11-21 17:40:30 <luke-jr> it also doesn't give it a filename
1048 2011-11-21 17:40:43 <wumpus> btw BlueMatt what is 'expat'? 
1049 2011-11-21 17:41:08 <BlueMatt> wumpus: expat is mit, but a different name for it that debian appears to prefer...
1050 2011-11-21 17:41:10 <BlueMatt> go figure
1051 2011-11-21 17:41:13 <wumpus> hmm
1052 2011-11-21 17:41:34 devrandom has joined
1053 2011-11-21 17:42:06 <wumpus> ahh expat is an xml parser
1054 2011-11-21 17:42:43 <wumpus> thought the name was really strange :-) but yeah it's ok with me to rename the license to that
1055 2011-11-21 17:44:02 <BlueMatt> sipa: how about this instead of a ticket: https://github.com/bitcoin/bitcoin/pull/654
1056 2011-11-21 17:44:21 <sipa> \o/
1057 2011-11-21 17:45:07 <wumpus> lol
1058 2011-11-21 17:47:26 <diki> My program so far
1059 2011-11-21 17:47:26 <diki> http://i.imgur.com/UQDMd.jpg
1060 2011-11-21 17:48:16 wasabi2 has joined
1061 2011-11-21 17:50:23 wasabi has quit (Ping timeout: 244 seconds)
1062 2011-11-21 17:50:34 <luke-jr> wtf wasn't this in 0.5.0? >_< https://github.com/bitcoin/bitcoin/pull/652
1063 2011-11-21 17:50:53 AStove has joined
1064 2011-11-21 17:51:04 <BlueMatt> luke-jr: because it was pull-requested after 0.5 was tagged?
1065 2011-11-21 17:51:09 <luke-jr> it was?
1066 2011-11-21 17:51:13 <luke-jr> oh well
1067 2011-11-21 17:51:20 <luke-jr> maybe we really should have 0.5.1 today :p
1068 2011-11-21 17:51:30 <BlueMatt> luke-jr: and because updating the debian changelog to indicate a release technically has to come after the release, so...
1069 2011-11-21 17:51:33 TD has quit (Quit: TD)
1070 2011-11-21 17:52:13 <BlueMatt> dig #653 fix the tooltip issues?
1071 2011-11-21 17:52:29 <luke-jr> yes
1072 2011-11-21 17:52:48 <gavinandresen> tcatm: Can you update the bitcoin.org homepage to link to 0.5.0 binaries?   I updated the wiki, sourceforge, and forums....
1073 2011-11-21 17:54:12 PK has joined
1074 2011-11-21 17:54:31 <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......
1075 2011-11-21 17:55:13 <BlueMatt> gavinandresen: I was half-joking but if we end up with 2 minor bug fixes that are user-facing, Im not against it
1076 2011-11-21 17:55:36 <CIA-89> bitcoin: Luke Dashjr maintree * r3d5fccff407e gentoo/net-p2p/ (8 files in 2 dirs): Merge branch 'master' into maintree
1077 2011-11-21 17:55:38 <luke-jr> (which is why 0.5.0 would have been better off waiting slightly longer for some easy-but-important fixes)
1078 2011-11-21 17:56:02 <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?
1079 2011-11-21 17:56:48 <BlueMatt> gavinandresen: yes
1080 2011-11-21 17:57:07 <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
1081 2011-11-21 17:57:33 <gavinandresen> BlueMatt: can you update release-process.txt to tell me (in small words :-) which ones to git add?
1082 2011-11-21 17:58:28 <luke-jr> gavinandresen: when master starts merging 0.6 features, is coinbaser on the table?
1083 2011-11-21 17:58:40 <luke-jr> it happens to still merge cleanly
1084 2011-11-21 17:59:08 <gavinandresen> luke-jr: if I recall correctly, there was some controversy over part of coinbaser
1085 2011-11-21 17:59:33 <luke-jr> I don't recall that. Just that it wasn't merged for 0.5.
1086 2011-11-21 18:00:19 <gavinandresen> https://bitcointalk.org/index.php?topic=46927.msg559622#msg559622
1087 2011-11-21 18:02:11 <BlueMatt> gavinandresen: should be something to the effect of 0.5.0/gavinandresen/*
1088 2011-11-21 18:02:39 <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
1089 2011-11-21 18:02:50 <gavinandresen> BlueMatt: thanks
1090 2011-11-21 18:03:13 <luke-jr> but someone making a block can do whatever they want anyway, so trying to artificially add restrictions here is IMO not helpful
1091 2011-11-21 18:03:15 <gavinandresen> luke-jr: ... so resurrect the discussion and get rough consensus that it is a Good Idea.
1092 2011-11-21 18:03:27 <luke-jr> gavinandresen: we had that before 0.5
1093 2011-11-21 18:05:14 <luke-jr> 14 people support coinbaser (notably, only 2 or 3 behind getmemorypool) vs 5 who wouldn't explain why they voted against it
1094 2011-11-21 18:06:12 danbri has joined
1095 2011-11-21 18:11:39 chrisb__ has quit (Remote host closed the connection)
1096 2011-11-21 18:11:50 <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.
1097 2011-11-21 18:12:38 * BlueMatt would like to see an every-increasingly large test suite
1098 2011-11-21 18:12:57 <gavinandresen> I'd like to see every new feature come with a written test plan.
1099 2011-11-21 18:13:34 * BlueMatt also really wants to see https://github.com/gavinandresen/Bitcoin-protocol-test-harness come to life
1100 2011-11-21 18:13:38 <gavinandresen> ... and somebody other than the implementor signing off on the test plan stating that they did, indeed, run all the tests.
1101 2011-11-21 18:14:04 <wumpus> still, automated tests are usually the best because you can effortlessly rerun them after a change
1102 2011-11-21 18:14:14 maqr has quit (Read error: Connection reset by peer)
1103 2011-11-21 18:14:39 <gavinandresen> Automated tests are great, and I agree more of those are a great idea.
1104 2011-11-21 18:14:41 <BlueMatt> most test plans should be largely in the boost test-suite
1105 2011-11-21 18:15:07 <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
1106 2011-11-21 18:15:53 cocktopus has quit (Quit: Over and out)
1107 2011-11-21 18:16:13 <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
1108 2011-11-21 18:16:38 cocktopus_ has joined
1109 2011-11-21 18:16:41 <wumpus> hm android has a monkey for that, don't know about qt
1110 2011-11-21 18:16:41 <BlueMatt> (if they are automated, they are already being run nightly, actually after every commit)
1111 2011-11-21 18:17:13 <wumpus> (the monkey basically injects ui events for testing)
1112 2011-11-21 18:17:40 chrisb__ has joined
1113 2011-11-21 18:17:46 <BlueMatt> bitcoin's ui isnt what needs as rigorous crash testing, its really about the backend
1114 2011-11-21 18:17:56 <BlueMatt> and that can be done much easier
1115 2011-11-21 18:19:40 <wumpus> but yes manual testing makes sense for ui
1116 2011-11-21 18:20:27 <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
1117 2011-11-21 18:21:22 <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
1118 2011-11-21 18:23:26 <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
1119 2011-11-21 18:23:42 <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
1120 2011-11-21 18:23:57 <wumpus> hehe i'm not from the US otherwise i'd sign that
1121 2011-11-21 18:24:07 <BlueMatt> It would be better to spend time on gavin's test harness imho
1122 2011-11-21 18:24:15 <BlueMatt> so that you can test the backend
1123 2011-11-21 18:24:30 <wumpus> hey I've written a few unit tests :p
1124 2011-11-21 18:24:45 <BlueMatt> heh
1125 2011-11-21 18:25:27 <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
1126 2011-11-21 18:25:57 <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 :-)
1127 2011-11-21 18:26:06 <BlueMatt> gavinandresen: yep you are right
1128 2011-11-21 18:26:25 <gavinandresen> Well that's easy, then....
1129 2011-11-21 18:26:45 <BlueMatt> gavinandresen: mustve been forgotten when I (was it me?) added the destination flag to gsign
1130 2011-11-21 18:26:48 <gavinandresen> What about the "upload gitian zips to SourceForge" ?  Where do they go?
1131 2011-11-21 18:27:36 eueueue has quit (Quit: Saindo)
1132 2011-11-21 18:28:00 <BlueMatt> gavinandresen: actually, which lines are you specifically talking about, I dont see it attempting to modify gitiain.sigs, its copying from
1133 2011-11-21 18:28:18 <gavinandresen> Everything under * From a directory containing bitcoin source, gitian.sigs and gitian zips
1134 2011-11-21 18:29:29 <BlueMatt> gavinandresen: ?
1135 2011-11-21 18:30:00 <gavinandresen> BlueMatt: I'm following doc/release-process.txt
1136 2011-11-21 18:30:16 <BlueMatt> gavinandresen: which line was your first question in reference to?
1137 2011-11-21 18:30:48 <gavinandresen> BlueMatt: where, exactly, are the gitian .zips supposed to go at SourceForge?
1138 2011-11-21 18:30:59 cocktopus_ is now known as cocktopus
1139 2011-11-21 18:31:21 <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
1140 2011-11-21 18:31:24 <gavinandresen> BlueMatt: gitian/ subdir of Bitcoin/0.5.0/  ?  Or is there a separate location for gitian zips?   (were they uploaded for previous releases)
1141 2011-11-21 18:31:42 <BlueMatt> gavinandresen: you should have bitcoin-0.5.0-linux-gitian.zip in the same place as all the other zips/tars/binaries/etc
1142 2011-11-21 18:32:36 <gavinandresen> BlueMatt: thanks, that was my question.
1143 2011-11-21 18:34:03 <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
1144 2011-11-21 18:37:05 <BlueMatt> gavinandresen: dont upload the gitian zip yet, you need 3 sigs on it first
1145 2011-11-21 18:38:42 <gavinandresen> .... ok.... I guess I need more information on what, exactly, "Collect enough gitian signatures" means.  Collect where?
1146 2011-11-21 18:39:08 <BlueMatt> gavinandresen: ie wait until me + devrandom/sipa/tcatm all upload their gitian sigs first
1147 2011-11-21 18:39:20 <BlueMatt> gavinandresen: then package the gitian zip with 3 sigs in it and upload
1148 2011-11-21 18:39:29 <gavinandresen> Upload to where?  You mean commit to the gitian.sigs tree?
1149 2011-11-21 18:39:52 <BlueMatt> yea
1150 2011-11-21 18:40:15 <gavinandresen> Ah, so all the instructions about unzipping and then re-zipping is to repackage with the signatures?
1151 2011-11-21 18:40:26 <BlueMatt> yes
1152 2011-11-21 18:40:35 <gavinandresen> Got it.  Those instructions need fixing.....
1153 2011-11-21 18:40:39 <BlueMatt> sorry, should have made that more clear...
1154 2011-11-21 18:41:14 <BlueMatt> more comments, less code
1155 2011-11-21 18:41:39 <gavinandresen> no problem, there's a reason most coders don't write books explaining how to use the code they write....
1156 2011-11-21 18:42:07 <BlueMatt> heh, though coders should be able to write docs for other coders...
1157 2011-11-21 18:42:33 <gavinandresen> mmm.  yeah, no, a professional technical writer will always do a much better job.
1158 2011-11-21 18:42:46 <gavinandresen> (well, a GOOD professional tech writer.....)
1159 2011-11-21 18:43:51 <wumpus> well it's always the best check to make another person follow the instructions :-)
1160 2011-11-21 18:44:31 <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
1161 2011-11-21 18:45:29 <wumpus> also  books are always proofread etc
1162 2011-11-21 18:48:26 <gavinandresen> I'm going to bump version numbers to 0.5.1 so we can start working on the backlog of pull requests
1163 2011-11-21 18:48:39 <tcatm> gavinandresen: should I copy the release announcement from the download page to bitcoin.org, too?
1164 2011-11-21 18:48:57 <gavinandresen> tcatm: good idea, yes
1165 2011-11-21 18:50:00 wasabi has joined
1166 2011-11-21 18:50:20 <nanotube> BlueMatt: dunno what spaola is doing here. neofutur ^ change sequence? or shall i take gribz off ! and leave it just on ;; ?
1167 2011-11-21 18:50:29 <BlueMatt> hey, bitcoin made it into the latest xkcd
1168 2011-11-21 18:50:41 storrgie has joined
1169 2011-11-21 18:50:55 <BlueMatt> nanotube: I dont care I just thought Id bring it to your attention...
1170 2011-11-21 18:51:17 wasabi2 has quit (Ping timeout: 260 seconds)
1171 2011-11-21 18:51:47 <nanotube> BlueMatt: really? /me looks at xkcd.
1172 2011-11-21 18:52:02 copumpkin has quit (Ping timeout: 252 seconds)
1173 2011-11-21 18:52:27 <nanotube> oh wow, capital xkcd!
1174 2011-11-21 18:52:27 <BlueMatt> nanotube: bottom left of millions
1175 2011-11-21 18:52:59 <BlueMatt> god, he spends so much time on some of these
1176 2011-11-21 18:53:06 TD has joined
1177 2011-11-21 18:54:05 <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
1178 2011-11-21 18:54:26 <nanotube> yea i know. serious guy :)
1179 2011-11-21 18:56:06 larsivi has joined
1180 2011-11-21 18:58:09 <luke-jr> gavinandresen: don't forget to bump to 0.6 when it's time to start pulling features :P
1181 2011-11-21 18:58:44 ahbritto has quit (Quit: Ex-Chat)
1182 2011-11-21 18:58:57 <BlueMatt> coke's anual marketing budget is bigger than what it would cost to buy everyone in the world a code
1183 2011-11-21 18:58:58 hazdb has quit (Ping timeout: 265 seconds)
1184 2011-11-21 18:59:03 <BlueMatt> s/code/coke/
1185 2011-11-21 18:59:36 coblee has joined
1186 2011-11-21 18:59:49 zxywvut has joined
1187 2011-11-21 18:59:56 zyxwvut has quit (Ping timeout: 265 seconds)
1188 2011-11-21 19:01:24 iocor has joined
1189 2011-11-21 19:01:47 * luke-jr can't find a 0.5 or 0.4.1 release announcement anywhere
1190 2011-11-21 19:02:26 copumpkin has joined
1191 2011-11-21 19:03:28 AlexWaters has joined
1192 2011-11-21 19:04:13 <nanotube> now why does he make it hard to get the full size image to my disk
1193 2011-11-21 19:04:18 halmug has joined
1194 2011-11-21 19:04:20 <nanotube> stupid js panner/zoomer
1195 2011-11-21 19:05:16 * BlueMatt agrees
1196 2011-11-21 19:06:25 <BlueMatt> gavinandresen: oops, you should also commit gitian.sigs/0.5.0-win32/gavinandresen/*
1197 2011-11-21 19:07:04 halmug has quit ()
1198 2011-11-21 19:09:51 ahbritto has joined
1199 2011-11-21 19:09:51 ahbritto has quit (Changing host)
1200 2011-11-21 19:09:51 ahbritto has joined
1201 2011-11-21 19:12:58 dugdunn has joined
1202 2011-11-21 19:15:32 <nanotube> heh, annual cost of rabbit ownership...
1203 2011-11-21 19:16:00 <BlueMatt> Saudi Armaco...damn
1204 2011-11-21 19:16:21 <nanotube> what about it
1205 2011-11-21 19:16:21 <CIA-89> bitcoin: Luke Dashjr 0.4.x * rd885aba347c2 bitcoind-stable/ (5 files in 4 dirs): Bump version to 0.4.2
1206 2011-11-21 19:16:47 <BlueMatt> tops the largest corporations by market cap by a ton...
1207 2011-11-21 19:19:59 <PK> "Bump version to 0.4.2" was there a 0.4.1 release and no one told me?
1208 2011-11-21 19:20:13 <BlueMatt> today
1209 2011-11-21 19:20:16 da2ce7 has quit (Quit: Konversation terminated!)
1210 2011-11-21 19:20:22 <nanotube> ah wow
1211 2011-11-21 19:20:24 <BlueMatt> 0.4.1 released with 0.5
1212 2011-11-21 19:20:25 <PK> it's not on the bitcoin.org page.
1213 2011-11-21 19:20:41 <sipa> not yet - it soon will be
1214 2011-11-21 19:21:52 <PK> nice. So to which version should the normal mortals update to? 0.4.1 or 0.5 ?
1215 2011-11-21 19:22:00 <BlueMatt> 0.5 probably
1216 2011-11-21 19:22:19 <BlueMatt> 0.4.1 only if you really want great stability - ie are running bitcoind most likely
1217 2011-11-21 19:22:50 <PK> yea, don't want some bugs mess up my wallet -.-
1218 2011-11-21 19:22:55 Kolky has joined
1219 2011-11-21 19:23:15 <BlueMatt> if you are an end-user, 0.5 is probably the way to go, the qt ui is really nice
1220 2011-11-21 19:24:07 <PK> what's the difference between a "end-user" and running bitcoind?
1221 2011-11-21 19:24:36 <BlueMatt> by running bitcoind, I meant ie a pool operator or someone running bitcoind as a backend to another website
1222 2011-11-21 19:25:40 <PK> I see, then 0.5 is mostly gui changes?
1223 2011-11-21 19:26:03 <BlueMatt> largely the new qt ui and a fix for the wallet encryption bug (but that is also in 0.4.1)
1224 2011-11-21 19:26:38 <PK> I see, thanks.
1225 2011-11-21 19:28:48 <CIA-89> bitcoin: Gavin Andresen master * re6389c3 / doc/release-process.txt : Update release process instructions - http://git.io/BELLBg
1226 2011-11-21 19:31:23 [Tycho] has quit (Changing host)
1227 2011-11-21 19:31:23 [Tycho] has joined
1228 2011-11-21 19:31:32 wolfspraul has quit (Ping timeout: 260 seconds)
1229 2011-11-21 19:33:44 wolfspraul has joined
1230 2011-11-21 19:36:01 <luke-jr> PK: I'd go with 0.4.1 for now, tbh
1231 2011-11-21 19:36:15 <luke-jr> but 0.5 is definitely the future
1232 2011-11-21 19:36:41 <luke-jr> that being said, I'm using 0.5 for GUI
1233 2011-11-21 19:37:51 <luke-jr> also note the 0.4.2 is (planned) only for bitcoind, not wxBitcoin
1234 2011-11-21 19:37:54 <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 :)
1235 2011-11-21 19:38:24 <luke-jr> PK: you know you can't "really" run the same wallet on two machines, right? >.>
1236 2011-11-21 19:38:51 <gavinandresen> yes, running "the same" wallet on two different machines is completely unsupported, and, in general, a bad idea.
1237 2011-11-21 19:38:52 <sipa> as long as you synchronize between every 100 transactions, you can
1238 2011-11-21 19:39:07 <sipa> but There be Dragons (tm)
1239 2011-11-21 19:39:08 <luke-jr> sipa: it still won't work "right"
1240 2011-11-21 19:39:19 <luke-jr> ie, you'll get the same addresses on both
1241 2011-11-21 19:39:50 <PK> luke-jr: Let's say I do... after a long time, which one will own the coins?
1242 2011-11-21 19:39:53 * luke-jr wonders if the codebase marks keypool as "used" when it sees a transaction to it
1243 2011-11-21 19:40:05 <wumpus> don't even go there please :)
1244 2011-11-21 19:40:12 <luke-jr> PK: they'll both "own" the older coins, and have distinct newer ones ;)
1245 2011-11-21 19:40:28 <sipa> luke-jr: good question
1246 2011-11-21 19:41:02 <luke-jr> PK: so it depends which one made the address
1247 2011-11-21 19:41:30 <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)
1248 2011-11-21 19:41:41 <luke-jr> PK: no
1249 2011-11-21 19:41:45 <wumpus> PK: was it a lot of hassle to cross-compile to arm?
1250 2011-11-21 19:41:57 <luke-jr> wumpus: it shouldn't be
1251 2011-11-21 19:42:05 <wumpus> I've been thinking as well to move bitcoind and tor to an arm box
1252 2011-11-21 19:42:09 <PK> wumpus: mostly the dependencies, bitcoind was fairly ok to crosscompile.
1253 2011-11-21 19:42:20 <wumpus> PK: nice
1254 2011-11-21 19:42:34 <PK> wumpus: I was thinking about crosscompiling tor too to deploy it on a synology box.
1255 2011-11-21 19:42:41 <CIA-89> bitcoin: Gavin Andresen master * r4ad4f66 / (contrib/debian/changelog contrib/debian/copyright):
1256 2011-11-21 19:42:42 <CIA-89> bitcoin: Merge pull request #652 from TheBlueMatt/master
1257 2011-11-21 19:42:42 <CIA-89> bitcoin: Update contrib/debian/ for 0.5.0 release and fix copyright file. - http://git.io/51_jlA
1258 2011-11-21 19:42:45 * luke-jr personally compiles *on* ARM
1259 2011-11-21 19:42:47 <PK> probably even make a spx package of it.
1260 2011-11-21 19:43:33 * luke-jr should update his N900
1261 2011-11-21 19:43:57 <[Tycho]> Oh, the current system will not allow 0-outputs without fee :(
1262 2011-11-21 19:44:12 <luke-jr> [Tycho]: eh?
1263 2011-11-21 19:44:23 <[Tycho]> My N770 somehow doesn't wants to detect WiFi networks.
1264 2011-11-21 19:44:26 <luke-jr> wtf are you worried about fees for?
1265 2011-11-21 19:44:33 <luke-jr> N770 was lame
1266 2011-11-21 19:45:09 <makomk> What do you want 0 outputs for for that matter?
1267 2011-11-21 19:45:11 <gavinandresen> wumpus:  I won't regret pulling "Add doxygen documentation" will I ?  https://github.com/bitcoin/bitcoin/pull/634
1268 2011-11-21 19:45:20 <luke-jr> I mean sure, it had builtin wifi and webcam, but it was basically the same thing the C760 had in 2004
1269 2011-11-21 19:45:30 <[Tycho]> luke-jr: I was thinking about adding 0-value inputs from "green address" to any TX to make it "signed".
1270 2011-11-21 19:45:42 <[Tycho]> What webcam ?
1271 2011-11-21 19:45:51 <luke-jr> N770 didn't have webcam either? fail
1272 2011-11-21 19:46:06 <makomk> [Tycho]: that's unsafe, I think.
1273 2011-11-21 19:46:09 <luke-jr> [Tycho]: there are much more sane ways to sign it
1274 2011-11-21 19:46:17 <[Tycho]> N770 is really great. I still use it for GPS navigation with offline google maps :)
1275 2011-11-21 19:46:29 <luke-jr> …
1276 2011-11-21 19:46:41 <makomk> Actually, nope, but I expect someone would use it in an unsafe way.
1277 2011-11-21 19:46:44 <luke-jr> [Tycho]: again, C760 had the same specs years earlier :P
1278 2011-11-21 19:46:46 <wumpus> gavinandresen: nope, I was going to pull it myself, but was really busy this week
1279 2011-11-21 19:46:47 <[Tycho]> I have N900 also, but it's completely useless, battery is good barely for a single day.
1280 2011-11-21 19:46:58 <CIA-89> bitcoin: Gavin Andresen master * r0310cd6 / src/bitcoinrpc.cpp :
1281 2011-11-21 19:46:58 <CIA-89> bitcoin: Merge pull request #632 from mndrix/deprecate-getblocknumber
1282 2011-11-21 19:46:58 <CIA-89> bitcoin: Deprecate RPC getblocknumber - http://git.io/z-eqSQ
1283 2011-11-21 19:47:00 <[Tycho]> luke-jr: which ways ?
1284 2011-11-21 19:47:08 <luke-jr> [Tycho]: just sign the transaction with another key
1285 2011-11-21 19:47:12 <CIA-89> bitcoin: Gavin Andresen master * r92979f8 / (31 files in 2 dirs):
1286 2011-11-21 19:47:12 <CIA-89> bitcoin: Merge pull request #634 from laanwj/doxygen
1287 2011-11-21 19:47:12 <CIA-89> bitcoin: Add doxygen documentation - http://git.io/VZc6_A
1288 2011-11-21 19:47:35 <wumpus> I just have to point the doxygen generator at the real master branch now
1289 2011-11-21 19:47:48 <[Tycho]> luke-jr: no, I'm talking about improving "green address" thing.
1290 2011-11-21 19:48:00 <[Tycho]> Why deprecate getblocknumber ?
1291 2011-11-21 19:48:05 <luke-jr> what "green address"?
1292 2011-11-21 19:48:19 traviscj has quit (Remote host closed the connection)
1293 2011-11-21 19:48:29 <CIA-89> bitcoin: Gavin Andresen master * r42eb76a / (src/test/util_tests.cpp src/util.h):
1294 2011-11-21 19:48:29 <CIA-89> bitcoin: Merge pull request #602 from wowus/master
1295 2011-11-21 19:48:29 <CIA-89> bitcoin: Cleaned up critical section code. - http://git.io/As-rIA
1296 2011-11-21 19:50:28 <[Tycho]> luke-jr: you are joking, right ? "Green address" is a scheme proposed by mtgox which may allow accepting unconfirmed TXses by having trust to some specific senders.
1297 2011-11-21 19:50:34 <luke-jr> gavinandresen: you forgot version in contrib/Bitcoin.app/Contents/Info.plist and doc/README*
1298 2011-11-21 19:51:04 <gavinandresen> luke-jr: thanks.  There is no contrib/Bitcoin.app in 0.5, though
1299 2011-11-21 19:51:09 <luke-jr> [Tycho]: I see. Why can't you just sign the txn with the specific sender key?
1300 2011-11-21 19:51:20 <luke-jr> gavinandresen: oh, Mac is different now?
1301 2011-11-21 19:51:24 <sipa> luke-jr: because they want to do it through the block chain
1302 2011-11-21 19:51:32 <luke-jr> sipa: that is…
1303 2011-11-21 19:51:35 <gavinandresen> luke-jr: yes, the App bundle is built by macdeployqt tool
1304 2011-11-21 19:51:58 <gmaxwell> Rephrasing that it's a scheme proposed by mtgox which doubles the blockchain size of regular transactions and conflicts with the regular anti-DDOS hurestics by respending a zero confirm input, to allow a few trusted parties to send coin without waiting for confirmations.
1305 2011-11-21 19:52:01 <luke-jr> sipa: don't all sigs get in the block chain?
1306 2011-11-21 19:52:17 <[Tycho]> I have my own proposed instant accepting scheme which may be implemented later.
1307 2011-11-21 19:52:28 <sipa> luke-jr: ?
1308 2011-11-21 19:52:31 * luke-jr thinks better would be signmessage-based tho
1309 2011-11-21 19:52:43 <gmaxwell> [Tycho]: A key criteria for mtgox as I understand it is that they don't want to have any communication with the recieving side.
1310 2011-11-21 19:52:44 <luke-jr> sipa: if I sign the transaction with an extraneous key, won't that sig hit the blockchain?
1311 2011-11-21 19:52:53 <sipa> luke-jr: where will you put that signature?
1312 2011-11-21 19:52:57 <[Tycho]> gmaxwell: it's not doubles the blockchain. It was just broken implementation.
1313 2011-11-21 19:52:59 <wumpus> why green? you should be able to label them in any color you want :P 
1314 2011-11-21 19:53:04 <luke-jr> sipa: wherever they go now?
1315 2011-11-21 19:53:10 <sipa> luke-jr: in the inputs
1316 2011-11-21 19:53:19 <luke-jr> hmm
1317 2011-11-21 19:53:21 <CIA-89> bitcoin: Gavin Andresen master * r795faa5 / (doc/README doc/README_windows.txt): Bump version numbers to 0.5.1 - http://git.io/ksvn6w
1318 2011-11-21 19:53:24 <sipa> ah right, you could put an extra signature there and OP_DROP it?
1319 2011-11-21 19:53:31 <luke-jr> sure
1320 2011-11-21 19:53:31 <[Tycho]> gmaxwell: currently DeepBit is sending from greenaddresses too, but my transactions are even 10% smaller.
1321 2011-11-21 19:53:48 <sipa> luke-jr: that's 1) non-standard and 2) still doesn't belong in the block chain
1322 2011-11-21 19:53:53 <sipa> but yes, it could work
1323 2011-11-21 19:53:59 <gmaxwell> [Tycho]: but are you doing an extra transaction per payment to move funds into the green address?
1324 2011-11-21 19:54:06 <CIA-89> bitcoin: Gavin Andresen master * r605ca14 / doc/release-process.txt : Don't forget to bump release numbers in READMEs next time - http://git.io/9ZKyrQ
1325 2011-11-21 19:54:13 <gmaxwell> (thats where the doubling comes from)
1326 2011-11-21 19:54:16 <[Tycho]> gmaxwell: NO. It's only mtgox doing this.
1327 2011-11-21 19:54:23 <luke-jr> gmaxwell: read backscroll
1328 2011-11-21 19:54:49 <luke-jr> fwiw, MtGox connects to Eligius over SSH to get us to accept transactions <.<
1329 2011-11-21 19:54:51 <gmaxwell> IIRC They're doing it intentionally— in order to avoid having $all_monies sitting forever at that address.
1330 2011-11-21 19:55:00 <[Tycho]> Example of my green payment: http://blockexplorer.com/tx/a38c95782d02badaf02d13d1478703e7c6baebfe87f9953e9f3313199e8c4cab
1331 2011-11-21 19:55:03 <gmaxwell> luke-jr: you're not silk road.
1332 2011-11-21 19:55:18 <luke-jr> gmaxwell: I prefer to make things as hard as possible for Silk Road.
1333 2011-11-21 19:55:23 <gmaxwell> Likewise.
1334 2011-11-21 19:55:41 <[Tycho]> luke-jr: that strange TX released by me was an experiment for same task :) But I already found better ways to do it.
1335 2011-11-21 19:55:45 <gmaxwell> But not everyone thinks the same... and people would prefer to have no way of knowing where their green funds are going.
1336 2011-11-21 19:55:46 <luke-jr> did Silk Road move off the known GoDaddy IP anywy?
1337 2011-11-21 19:56:17 <luke-jr> [Tycho]: it would be neat if Deepbit adopted Eligius's fee policy btw
1338 2011-11-21 19:56:34 <[Tycho]> Accepting non-standard TXes for a fee ?
1339 2011-11-21 19:56:50 <luke-jr> [Tycho]: no, lower fees, but always require a fee by default
1340 2011-11-21 19:57:03 <luke-jr> 0.00004096 BTC/512 bytes specifically
1341 2011-11-21 19:57:04 <[Tycho]> No, I would prefer NEVER doing that.
1342 2011-11-21 19:57:13 <luke-jr> oh well
1343 2011-11-21 19:57:14 <gavinandresen> luke-jr sipa : you could prepend an extra signature in the scriptSig/TxIn... no need to OP_DROP, it'll just be ignored.  As long as the TxIn is less than 201 bytes big.
1344 2011-11-21 19:57:23 <sipa> gavinandresen: right, indeed
1345 2011-11-21 19:57:37 <sipa> but it still doesn't belong there :)
1346 2011-11-21 19:57:44 * luke-jr would prefer MtGox et al publish a list of txids they're waiting on
1347 2011-11-21 19:57:50 <[Tycho]> If you don't know, my position is to allow free TXes for as long as possible.
1348 2011-11-21 19:57:51 <luke-jr> and if you trust MtGox, you poll their txid list
1349 2011-11-21 19:58:35 <[Tycho]> If I'll stop doing this, current TX queue will grow to hundreds and thousands.
1350 2011-11-21 19:58:39 <gavinandresen> sipa:  .... 200 bytes.... how big are sigs again?  Is there room for 33 bytes of pubkey plus two sigs in 200 bytes?
1351 2011-11-21 19:58:53 <sipa> yes
1352 2011-11-21 19:59:12 <gmaxwell> thats a cute idea but then it still ends up in the blockchain
1353 2011-11-21 19:59:14 <sipa> 71 or 72 bytes for normal signatures
1354 2011-11-21 19:59:47 eueueue has joined
1355 2011-11-21 20:00:06 <[Tycho]> Possibility to send bitcoins for free is one great feature of bitcoin. I don't want to ruin it.
1356 2011-11-21 20:00:08 <gmaxwell> For this I think we'd want to use a rider that gets forwarded but doesn't get saved outside of the memory pools.
1357 2011-11-21 20:00:32 <sipa> gmaxwell: that'd be nice, indeed
1358 2011-11-21 20:00:41 <gavinandresen> gmaxwell: you worried about "catch-up" download time?
1359 2011-11-21 20:01:01 <gavinandresen> gmaxwell: ... because it seems to me we should fix that in any case.
1360 2011-11-21 20:01:15 <gmaxwell> gavinandresen: and long term storage size. Also privacy— it's less than ideal that the green signatures are public, they identify one side of the transaction.
1361 2011-11-21 20:01:20 <luke-jr> gavinandresen: don't need to put the pubkey in, just the sig
1362 2011-11-21 20:01:51 <gmaxwell> luke-jr: I think he meant the normal pubkey.
1363 2011-11-21 20:02:04 Snapman is now known as Snapman[afkers]
1364 2011-11-21 20:02:15 <gavinandresen> yes, sig and then the nomal sig pubkey
1365 2011-11-21 20:02:24 <[Tycho]> luke-jr: you aren't accepting free TXes already ?
1366 2011-11-21 20:02:35 <gavinandresen> (first sig is the 'green' I Approve This Transaction)
1367 2011-11-21 20:02:40 <sipa> also, continuing to promote the bitcoin block chain as communication channel will hinder the adoption of out-of-band communication
1368 2011-11-21 20:02:41 <luke-jr> [Tycho]: only if I can be very sure they're not spam.
1369 2011-11-21 20:03:27 <gmaxwell> It's been pretty impressive to watch the litecoin chain grow 200 mbytes in a few days. We're fortunate that no one is doing that to bitcoin currently.
1370 2011-11-21 20:03:29 <[Tycho]> Currently I'm thinking about adding 0-value input from green address as the proof.
1371 2011-11-21 20:03:31 * luke-jr suggests a separate block chain for the extra sigs, tacked on via merged mining
1372 2011-11-21 20:03:36 <luke-jr> :p
1373 2011-11-21 20:03:58 <gmaxwell> [Tycho]: but then you have to continually mine lots of txns to create the zero value inputs.
1374 2011-11-21 20:03:59 <luke-jr> gmaxwell: they are.
1375 2011-11-21 20:04:01 <[Tycho]> There were flood attempts at bitcoin too.
1376 2011-11-21 20:04:16 <gavinandresen> Wouldn't be hard to implement some code that teaches bitcoin to lookup transaction ids on a list of websites to see which ones were 'green-approved'
1377 2011-11-21 20:04:35 <[Tycho]> gmaxwell: I can make a lot in one TX.
1378 2011-11-21 20:04:37 <gavinandresen> ... either using https or something more efficient
1379 2011-11-21 20:04:43 <luke-jr> [Tycho] could always add change to his transaction for the next one
1380 2011-11-21 20:05:04 <luke-jr> gavinandresen: exactly
1381 2011-11-21 20:05:12 Snapman[afkers] is now known as Snapman
1382 2011-11-21 20:05:16 <gmaxwell> [Tycho]: yes, but absent that behavior we'd be able to prune zero value outputs, and with that it wouldn't be advisable to do so anymore. :(  And it still creates more perpetual storage.
1383 2011-11-21 20:05:18 <[Tycho]> luke-jr: yes, this can even be free if 0 is replaced with 0.01
1384 2011-11-21 20:05:45 <luke-jr> [Tycho]: you run Deepbit. everything is free to you.
1385 2011-11-21 20:05:55 <gmaxwell> Constantly reusing the chain goofs up the anti-dos hurestic.
1386 2011-11-21 20:05:58 <gavinandresen> Actually, that might be a nice spot where you could install arbitrary plugins to do ... something....
1387 2011-11-21 20:06:20 <luke-jr> gmaxwell: well, if [Tycho] starts with a batch of 1000 outputs, it mgiht work
1388 2011-11-21 20:06:25 <[Tycho]> Did anyone knows my proposal for instant-accepting TXes ?
1389 2011-11-21 20:06:53 <sipa> [Tycho]: where did you post it?
1390 2011-11-21 20:06:57 <gavinandresen> E.g. it'd be nice to lookup extra information given a transaction id from trusted sources, so maybe you could be certain a given transaction was from Mt. Gox or 'gavin@acm.org'
1391 2011-11-21 20:07:00 <gmaxwell> luke-jr: yes, it would work, but it's still adding extra storage to the system _forever_ for an exclusively private end... which is extremely unfortunate.
1392 2011-11-21 20:07:00 <luke-jr> gavinandresen: if you add a mere sig to the txn, can miners strip it out when making blocks?
1393 2011-11-21 20:07:09 <gavinandresen> luke-jr: yes, they could
1394 2011-11-21 20:07:13 <[Tycho]> sipa: I was discussing it in IRC.
1395 2011-11-21 20:07:14 <tcatm> mhm, somehow github is broken. it should show the 0.5.0 release on bitcoin.org now
1396 2011-11-21 20:07:20 <gmaxwell> And it also reduces the privacy of those txns since they all end up linked to a widely known address.
1397 2011-11-21 20:07:23 <gavinandresen> luke-jr: ... or nodes could strip it out before relaying....
1398 2011-11-21 20:07:26 <luke-jr> gavinandresen: a common place/system to publish signmessages?
1399 2011-11-21 20:07:34 <luke-jr> gavinandresen: then it won't get to its destination
1400 2011-11-21 20:07:50 <luke-jr> tcatm: and 0.4.1?
1401 2011-11-21 20:08:05 <sipa> what about just sending the transaction, together with any comments you like, in an authenticated way, to the receiver directly?
1402 2011-11-21 20:08:24 <luke-jr> sipa: I implemented that a while back. It was a nusance. :p
1403 2011-11-21 20:08:24 <gmaxwell> sipa: because banks don't want to know where the money is going.
1404 2011-11-21 20:08:40 <[Tycho]> sipa: we can make a little cartel of pools for 51%, then offer doublespending-protection for a small fee for any merchant. That merchant sends us his TX and we fail any blocks that try to doublespend it. Also we post a public list of those TXes so anyone can include them too and avoid failing.
1405 2011-11-21 20:08:44 <luke-jr> gmaxwell: ah, is that the reason? :p
1406 2011-11-21 20:08:47 <gmaxwell> sipa: though a serialized blob "here is a base64 txn, do with it what you will" might be better.
1407 2011-11-21 20:09:07 <gmaxwell> luke-jr: IIRC thats what magicaltux told me, (in here if you look back far enough in your lots)
1408 2011-11-21 20:09:10 <luke-jr> [Tycho]: I like that idea.
1409 2011-11-21 20:09:52 Clipse has joined
1410 2011-11-21 20:09:53 <luke-jr> but the "best" system so far seems like addign a sig, and having miners strip it for blocks
1411 2011-11-21 20:09:54 <luke-jr> IMO
1412 2011-11-21 20:09:56 <sipa> i hate that idea - you're deliberately becoming the monopoly that decides which transactions are valid?
1413 2011-11-21 20:09:56 <gmaxwell> [Tycho]: I suggest you think really carefully about what that would make people conclude about bitcoin.
1414 2011-11-21 20:10:08 marioxcc has joined
1415 2011-11-21 20:10:22 <gmaxwell> (e.g. that post cartel its a centeralized system where you must trust that the cartel is benign)
1416 2011-11-21 20:10:49 <gmaxwell> (and, frankly, no offense— but I think most rational people would rather trust the fed than you guys. ;) )
1417 2011-11-21 20:11:04 <luke-jr> if all the big pools strip extraneous signatures from transactions, would that appease everyone?
1418 2011-11-21 20:11:14 <[Tycho]> luke-jr: current system with green addresses forces users to use online wallets which are so evil. My proposal allows receiving instant TXes from arbitrary addresses.
1419 2011-11-21 20:11:15 <sipa> how can you do that?
1420 2011-11-21 20:11:25 <gmaxwell> luke-jr: If it were strippable that would make me happy.
1421 2011-11-21 20:11:41 <[Tycho]> Everyone knows that I'm not evil.
1422 2011-11-21 20:11:52 <luke-jr> [Tycho]: everyone knows you are :P
1423 2011-11-21 20:12:02 <gmaxwell> I don't think we have a communications bw problem. ..and if they're worried about the flood being missed they can just hand you a base64 seralized version of the txn that you can carry by some other path.
1424 2011-11-21 20:12:03 <luke-jr> gmaxwell: gavinandresen just said it was
1425 2011-11-21 20:12:13 <sipa> [Tycho]: you're basically describing an insurer scenario (where a merchant pays an insurer for possible double spends, and gets immediate credit from incoming transactions via them)
1426 2011-11-21 20:12:22 <gmaxwell> [Tycho]: the widespread rumor is that you're a puppet of the KGB or russian mafia, in fact!
1427 2011-11-21 20:12:33 <sipa> [Tycho]: combined with a 51% attack that makes sure it gets to decide what goes in
1428 2011-11-21 20:12:44 <luke-jr> sipa: it's not an attack in this case, though
1429 2011-11-21 20:12:50 <luke-jr> sipa: it's "how the system was designed"
1430 2011-11-21 20:12:54 <sipa> eh no
1431 2011-11-21 20:13:00 <[Tycho]> gmaxwell: that too, but not evil !
1432 2011-11-21 20:13:03 <gmaxwell> haha!
1433 2011-11-21 20:13:06 <sipa> it's hijacking the system
1434 2011-11-21 20:13:07 <luke-jr> so long as the cartel DOES verify there are no conflicts
1435 2011-11-21 20:13:20 <gmaxwell> luke-jr: The road to hell is paved with good intentions.
1436 2011-11-21 20:13:34 <luke-jr> gmaxwell: I don't really see a problem with this.
1437 2011-11-21 20:13:36 <sipa> what when the cartel decides it's not going to accept your payments anymore, because they don't like you?
1438 2011-11-21 20:13:36 <gmaxwell> Thats exactly the kind of centeralized control level the system was designed to resist (but sadly, it can't prevent it)
1439 2011-11-21 20:13:55 <gmaxwell> sipa: because someone (falsely!) claimed your bitcoins were stolen, for example.
1440 2011-11-21 20:13:58 <luke-jr> sipa: huh?
1441 2011-11-21 20:14:11 <luke-jr> sipa: that's already a problem
1442 2011-11-21 20:14:39 <gmaxwell> It's not, because you crazy pool operators don't coordinate. :)
1443 2011-11-21 20:14:47 <luke-jr> gmaxwell: sure?
1444 2011-11-21 20:14:53 <sipa> there is still a difference between having that possibility, and building an infrastructure that depends on it
1445 2011-11-21 20:14:57 <[Tycho]> Any business can decide which clients he wants to support.
1446 2011-11-21 20:15:15 <luke-jr> sipa: nothing in the insurance infra enables boycotting spenders
1447 2011-11-21 20:15:27 <sipa> 51% cartels do
1448 2011-11-21 20:15:28 <luke-jr> sipa: it strictly deals with recipients AIUI
1449 2011-11-21 20:15:34 <gavinandresen> I'd slightly modify [Tycho]'s proposal-- pools already reject double-spent transactions.  Just let merchants pay to have their transactions published in an "I saw these transactions first" list
1450 2011-11-21 20:15:36 <gmaxwell> [Tycho]: indeed, but once you have >50% you also decide for every other business too.
1451 2011-11-21 20:15:42 RazielZ has quit (Quit: Leaving)
1452 2011-11-21 20:15:58 <luke-jr> gavinandresen: that's backward :P
1453 2011-11-21 20:16:06 datagutt has quit (Quit: kthxbai)
1454 2011-11-21 20:16:09 <luke-jr> gavinandresen: the merchants want to GET a list of "I saw these transactions, with no conflicts"
1455 2011-11-21 20:16:12 <[Tycho]> gavinandresen: this scheme should make sure WHICH ones are legitimate of two.
1456 2011-11-21 20:16:20 <gmaxwell> Coordination has value— you just need to be cautious that you don't undermine trust in bitcoin.
1457 2011-11-21 20:16:50 <luke-jr> I see it as merchants paying for a simple service: "Do you guys know of any reason this transaction is invalid?" "Nope, looks good!"
1458 2011-11-21 20:16:51 <sipa> if you say "oh and bitcoin has this instant-payment-processing ability, but it only actually works because despite all the nice talk, everything is in fact managed by a single cartel that gets to decide everything"
1459 2011-11-21 20:16:52 <gmaxwell> Because if you put in front of people so their evaluation of the value of bitcoin depends on how much they trust you, we'll find they don't trust you at all.
1460 2011-11-21 20:17:07 <[Tycho]> Blocking stolen funds would require real proofs, I don't think anyone is going to implement that anytime soon.
1461 2011-11-21 20:17:15 <sipa> ... i think bitcoin loses its advantage
1462 2011-11-21 20:17:22 <gavinandresen> luke-jr: by "their transactions" I meant "transactions to or from them"
1463 2011-11-21 20:17:33 <BlueMatt> not just its advantage, but its only difference
1464 2011-11-21 20:17:35 <luke-jr> sipa: except all the "cartel" does is answer "Any reason this is bad that you know of?"
1465 2011-11-21 20:18:04 <luke-jr> and if the answer is "I can't guarantee that", you just wait 6 confirmations
1466 2011-11-21 20:18:08 <sipa> BlueMatt: it remains an electronic currency with limited supply
1467 2011-11-21 20:18:17 <[Tycho]> sipa: instant confirmation is only a service, no one forces anyone to use it.
1468 2011-11-21 20:18:25 <gavinandresen> And the real question aught to be: "can you guarantee that 50+% of current hashing power sees THIS as a valid, not-double-spent transaction?"
1469 2011-11-21 20:18:37 <sipa> i think you shouldn't
1470 2011-11-21 20:18:45 <helo> when will miners start putting "OP_EVAL" into their blocks?
1471 2011-11-21 20:18:46 <gmaxwell> gavinandresen: by having them publish their memory pools "on the side"
1472 2011-11-21 20:18:52 <sipa> just calculate the risk, and pay for compensation
1473 2011-11-21 20:18:55 <gmaxwell> then you don't have to have any cartel.. you just *check*
1474 2011-11-21 20:18:58 <BlueMatt> sipa: in other words its another private currency, the only difference is it has limited supply...
1475 2011-11-21 20:19:24 <sipa> BlueMatt: yup
1476 2011-11-21 20:19:43 <gavinandresen> gmaxwell: I can see miners deciding that information has value and deciding to sell it instead of giving it away for free
1477 2011-11-21 20:19:57 <gmaxwell> gavinandresen: you could even use a merged mining style commitment to prove the hash power behind your memory pool snapshot.
1478 2011-11-21 20:20:02 <gavinandresen> gmaxwell: ... and there would be value in automatic aggregation / an easy-to-call API....
1479 2011-11-21 20:20:04 <gmaxwell> gavinandresen: sure, sell access to the feed.
1480 2011-11-21 20:20:16 <[Tycho]> I really want instant POS to be possible.
1481 2011-11-21 20:20:22 <[Tycho]> That coffee machines and so on.
1482 2011-11-21 20:20:34 <gmaxwell> (just like people pay for telechex (check certification), or bloomberg stock feeds)
1483 2011-11-21 20:20:49 <[Tycho]> Well, with coffe you can just insure the value, it's cheap anyway.
1484 2011-11-21 20:21:00 <TD> or don't even insure
1485 2011-11-21 20:21:06 <TD> just swallow the losses, haha
1486 2011-11-21 20:21:07 <gavinandresen> If I had infinite time I'd write some code for the bitcoin client to monitor number of connections into the network and keep track of possible double-spends from peers....
1487 2011-11-21 20:21:20 <sipa> or sell access to an API bool AcceptedTransaction(CTransaction tx)
1488 2011-11-21 20:21:25 <[Tycho]> TD, are you a developer ?
1489 2011-11-21 20:21:27 <TD> yes
1490 2011-11-21 20:21:30 <TD> sort of
1491 2011-11-21 20:21:30 <TD> why?
1492 2011-11-21 20:21:35 <[Tycho]> what's your project ?
1493 2011-11-21 20:21:40 <TD> i'm the maintainer of bitcoinj
1494 2011-11-21 20:21:43 <gmaxwell> gavinandresen: e.g. a pool could sell copies of their best current (not yet valid) block at the current height. to an aggregator that provides double spend protection.
1495 2011-11-21 20:21:46 <TD> it's used in the android wallet and poolserverj
1496 2011-11-21 20:21:53 <gavinandresen> gmaxwell: yup
1497 2011-11-21 20:21:55 <TD> along with some other things like the network status graphs
1498 2011-11-21 20:21:58 <[Tycho]> "swallowing" is kind of insurance.
1499 2011-11-21 20:22:04 <[Tycho]> TD, cool.
1500 2011-11-21 20:22:31 <TD> i wrote the wiki articles on alternative chains, contracts and smart property
1501 2011-11-21 20:22:36 <TD> and, uh, i think that's about it :)
1502 2011-11-21 20:22:40 <gmaxwell> [Tycho]: Supporting instant transactions is good, and important. But it's more important to do it without undermining people's carefully considered trust in the decenteralization of bitcoin.
1503 2011-11-21 20:22:58 <[Tycho]> Smart property is cool, I read about it in wiki a couple of days ago.
1504 2011-11-21 20:23:08 <sipa> gmaxwell: exactly
1505 2011-11-21 20:23:19 <[Tycho]> Yeah, decentralization is cool.
1506 2011-11-21 20:23:24 <gmaxwell> [Tycho]: regardless of how much I trust you and luke, I don't want to have to _think_ about if I really trust you guys to veto all transactions or not. If I'm going to worry about trust, well, I might as well use paypal.
1507 2011-11-21 20:23:45 * TD didn't read the whole conversation
1508 2011-11-21 20:23:57 <gmaxwell> (yes, paypal isn't free— but it has lots of other advantages)
1509 2011-11-21 20:24:01 <TD> but has anyone actually encountered problems with accepting zero conf transactions, except for mybitcoin (questionable?)
1510 2011-11-21 20:24:18 <TD> for most merchants my understanding is, this is still a theoretical problem
1511 2011-11-21 20:24:29 <[Tycho]> Was there a problem with mybitcoin and zero-conf ?
1512 2011-11-21 20:24:40 <gmaxwell> [Tycho]: Probably.
1513 2011-11-21 20:24:43 <TD> that's what they claimed allowed the theft of bitcoins. i was never completely convinced.
1514 2011-11-21 20:24:44 <sipa> i'm not sure whether we should encourage accepting zero-conf transactions
1515 2011-11-21 20:24:48 <TD> their explanation didn't hold water
1516 2011-11-21 20:24:55 <[Tycho]> TD it may become real when bitcoin merchanting takes off.
1517 2011-11-21 20:25:04 <gmaxwell> TD: I'm more convinced now because I found out about a bug that was fixed in .4 that I wasn't previously aware of.
1518 2011-11-21 20:25:10 <gavinandresen> mybitcoin claims 1-conf double-spends...
1519 2011-11-21 20:25:11 <luke-jr> gavinandresen: IMO, two levels of service
1520 2011-11-21 20:25:19 <TD> currently most merchants are either delivering digital goods (not a big deal if there's a reversal), or physical items (delivered slowly anyway)
1521 2011-11-21 20:25:33 <TD> gmaxwell: oh?
1522 2011-11-21 20:25:40 <gmaxwell> TD: and thats that prior to .4 you could send someone a TXN which used the same input twice. And it would show as zero confirmed, but (obviously) never get mined.
1523 2011-11-21 20:25:41 <TD> gmaxwell: something to do with the rpc api?
1524 2011-11-21 20:25:48 <TD> ah, right
1525 2011-11-21 20:25:53 <luke-jr> "Do you guys (>50%) see this as a problem-free txn?" and the same question rephrased if you pay more: "Will you guarantee this txn?"
1526 2011-11-21 20:25:55 <TD> i vaguely recall that
1527 2011-11-21 20:26:01 <gmaxwell> TD: it's a one line change to the code to make such txns. and they got forwarded.. and they'd leave no long lasting record since they don't get mined.
1528 2011-11-21 20:26:03 <[Tycho]> Currently selling goods for bitcoins is still way too small-scale.
1529 2011-11-21 20:26:24 MimeNarrator has quit (Ping timeout: 276 seconds)
1530 2011-11-21 20:26:30 <TD> yes. this will become a bigger issue as more people use thin clients
1531 2011-11-21 20:26:33 <[Tycho]> luke-jr: someone may release a DS TX after this question.
1532 2011-11-21 20:26:45 <[Tycho]> Yes, we need more light clients.
1533 2011-11-21 20:26:52 <luke-jr> [Tycho]: of course, that's probably the key difference.
1534 2011-11-21 20:26:52 <gmaxwell> TD: so, with that in mind— it's perfectly reasonable that they could get screwed by zero-conf txn without having any 'proof' of it (other than their wallet, I guess)
1535 2011-11-21 20:26:58 <sipa> luke-jr: if i'm going to ask that to a group that actively claims to control 50% of the block chain, i can just ask my bank and use dollars
1536 2011-11-21 20:27:08 <TD> gmaxwell: ok. interesting. that sucks
1537 2011-11-21 20:27:34 <luke-jr> [Tycho]: if such a transaction gets confirmed, service A leaves liability with the merchant, and service B reimburses them
1538 2011-11-21 20:27:35 <[Tycho]> Which was that bug in <0.4 ?
1539 2011-11-21 20:27:54 <gmaxwell> [Tycho]:
1540 2011-11-21 20:27:55 <gmaxwell> 12:10 < gmaxwell> TD: and thats that prior to .4 you could send someone a TXN which used the same input twice. And it would show as zero confirmed, but  (obviously) never get mined.
1541 2011-11-21 20:28:00 <luke-jr> sipa: I'm not aware of banks guaranteeing funds won't reverse immediately.
1542 2011-11-21 20:28:13 <gmaxwell> luke-jr: called a casheres check.
1543 2011-11-21 20:28:15 <[Tycho]> Oh, that
1544 2011-11-21 20:28:23 <sipa> luke-jr: neither do you, if you control 51%
1545 2011-11-21 20:28:36 <[Tycho]> luke-jr: just asking is the same as buying insurance for your TX.
1546 2011-11-21 20:28:41 <luke-jr> sipa: if I'm willing to reimburse you in the case that it does, I can guarantee it.
1547 2011-11-21 20:28:59 <TD> i'd still like to think that in the long run, things like p2pool will become more common. having a handful of giant pools is pretty far from satoshis original vision, convenient though they are
1548 2011-11-21 20:29:02 <gmaxwell> You don't have to impose central control on the network to be willing to reimburse.
1549 2011-11-21 20:29:06 <TD> so there'd need to be some other solution
1550 2011-11-21 20:29:08 <sipa> gmaxwell: exactly
1551 2011-11-21 20:29:13 <[Tycho]> Insurance can refund loss, but active supporting "good TX" can prevent it.
1552 2011-11-21 20:29:17 <wumpus> TD: yes let's hope so
1553 2011-11-21 20:29:20 <sipa> luke-jr: i like your idea, but i don't see why it requires a 51% cartel
1554 2011-11-21 20:29:40 <luke-jr> TD: p2pool is not viable.
1555 2011-11-21 20:29:43 <sipa> a 1% guy could do it as well, and ask compensation for the chance that he is wrong and needs to reimburse
1556 2011-11-21 20:30:00 <luke-jr> sipa: under 50%, the cost would be exhorbitant
1557 2011-11-21 20:30:05 <sipa> not at all
1558 2011-11-21 20:30:06 <[Tycho]> sipa: I can do the same without any %. Just take small fee from merchants and be like insurance company.
1559 2011-11-21 20:30:10 <gmaxwell> [Tycho]: yes. But the >50% cartel would prevent good txn too, because it would strongly discourage people from using bitcoin in the first place.
1560 2011-11-21 20:30:23 <luke-jr> gmaxwell: nonsense
1561 2011-11-21 20:30:25 <BlueMatt> gavinandresen: I cant duplicate the boost you used to build
1562 2011-11-21 20:30:27 <gmaxwell> [Tycho]: yes, but you can do it cheaper the more visiblity you have into miners pools.
1563 2011-11-21 20:30:35 <[Tycho]> Why the cartel would prevent any good tx ?
1564 2011-11-21 20:30:36 <luke-jr> Bitcoin would work exactly the same with the insurance services.
1565 2011-11-21 20:30:38 <TD> luke-jr: yes, i know, you've said before, their technique is limited in how much variance it can remove. but i meant in terms of long term goals
1566 2011-11-21 20:31:01 <gmaxwell> [Tycho]: because ninjas sent by the kgb offered you gold bars. who the @#$@# knows. The point is that they can, so you must trust that they won't. ;)
1567 2011-11-21 20:31:04 MimeNarrator has joined
1568 2011-11-21 20:31:33 <[Tycho]> gmaxwell: that is already possible without a cartel. Just send those gold bars to two pools.
1569 2011-11-21 20:31:53 <gmaxwell> [Tycho]: indeed, this is a problem. We'd make it harder to ignore with a formal cartel.
1570 2011-11-21 20:31:54 <gavinandresen> BlueMatt: how can I help debug that?  I've got boost_1_47_0.tar.bz2 and boost-win32-1.47.0-gitian.zip in my gitian-build/inputs directory
1571 2011-11-21 20:31:56 <[Tycho]> Even if one pool declines, you can ask another and still get 50%
1572 2011-11-21 20:32:21 <TD> yeah, that's the problem gmaxwell is talking about. bitcoin is advertised as being decentralized, a solution to needing big trusted institutions (banks)
1573 2011-11-21 20:32:28 <sipa> bitcoin's basic security premise depends on the trust the community has that no 50% conspire against them
1574 2011-11-21 20:32:38 <TD> however, whilst it's dominated by a few giant pools, it's not really much different. though the protocol has some cool features.
1575 2011-11-21 20:32:47 <gmaxwell> [Tycho]: and this has cause people to claim that bitcoin's security model is hopelessly broken because of this. ... at least we can currently answer that miners can easily move, and nothing depends on it being that way— that its just a fluke of market dynamics.
1576 2011-11-21 20:32:57 <TD> ie, why trust deepbit+eligius, when i could trust highly visible and well regulated banks instead?
1577 2011-11-21 20:33:05 <gmaxwell> sipa: exactly. And showing that 50% are conspiring would not bode well.
1578 2011-11-21 20:33:19 <gavinandresen> "well regulated" is very debatable....
1579 2011-11-21 20:33:22 <TD> alright
1580 2011-11-21 20:33:26 <TD> well regulated compared to pools :)
1581 2011-11-21 20:33:38 <gmaxwell> gavinandresen: hah. at least theoretically regulatable. ;)
1582 2011-11-21 20:33:40 <gavinandresen> pools are regulated by the people participating....
1583 2011-11-21 20:33:58 <gmaxwell> I mean pools can be regulated too.. except that they're currently not, and are currently mostly opaque.
1584 2011-11-21 20:34:03 <TD> i question how much attention people pay to the exact behaviors of the pools they're in
1585 2011-11-21 20:34:17 <[Tycho]> If we start stopping some good TXes or allowing govs to control us, people will just leave.
1586 2011-11-21 20:34:22 <gmaxwell> How do I see luke's memory pool? How do I audit deepbits books?
1587 2011-11-21 20:34:31 <gmaxwell> [Tycho]: we can't even tell if you're doing that.
1588 2011-11-21 20:34:38 <gavinandresen> Agreed. I'm sure most miners care only that the pool has 99% uptime and pays out regularly
1589 2011-11-21 20:34:38 <[Tycho]> You can.
1590 2011-11-21 20:34:56 <luke-jr> TD: no pool can issue new Bitcoins at an unlimited rate.
1591 2011-11-21 20:35:10 <gmaxwell> You have less oversight than the crappiest bank in lowest slum of the developing world. And thats fine because the system doesn't require that you be especially trustworthy.
1592 2011-11-21 20:35:24 <[Tycho]> gavinandresen: well, we had a lot of forum topics about deepbit becoming almost 50%. That was scary.
1593 2011-11-21 20:35:28 <luke-jr> gmaxwell: why do you need to see my memory pool?
1594 2011-11-21 20:35:38 <[Tycho]> I was afraid they are really going to leave.
1595 2011-11-21 20:35:41 <gmaxwell> But if you have a functioning >50% cartel, it's actually important that you are not playing bad.
1596 2011-11-21 20:35:57 <TD> luke-jr: that's true now, whilst most people aren't on lightweight clients. remember lightweight clients accept the contents of sufficiently hard blocks as ipso-facto valid, even if they invent coins out of nothing
1597 2011-11-21 20:36:23 <TD> so in some star-trek future where most people are using bitcoin on their phones, or whatever, if there was a 51% cartel, you _could_ print money
1598 2011-11-21 20:36:25 <[Tycho]> gmaxwell: TX queue is public and you can easily see which TXes are going where.
1599 2011-11-21 20:36:36 <luke-jr> gavinandresen: this critical block refactor thing you just merged… is it a bugfix, or?
1600 2011-11-21 20:36:39 <gmaxwell> [Tycho]: you really should have some adaptive fee system that makes your fee tend to 100% as your % approaches 50%. It would have been a good show of good faith.
1601 2011-11-21 20:36:45 <wumpus> well in a star-trek future phones would be powerful enough to run a full client TD:-)
1602 2011-11-21 20:36:45 <ThomasV> gmaxwell: if you are a >50% pool, is it possible to play bad and to hide it?
1603 2011-11-21 20:36:51 <[Tycho]> gmaxwell: no.
1604 2011-11-21 20:37:00 <TD> haha
1605 2011-11-21 20:37:01 <gavinandresen> luke-jr: not a bugfix, just a cleaner-way-of-doing-it change
1606 2011-11-21 20:37:02 <TD> that's true.
1607 2011-11-21 20:37:05 <TD> i have no answer to that
1608 2011-11-21 20:37:26 <gmaxwell> ThomasV: depends on the nature of bad and how bad you play. You can certantly delay txn in a plausable way for a long time.
1609 2011-11-21 20:37:36 <luke-jr> gavinandresen: k, leaving out of 0.4.x then
1610 2011-11-21 20:37:41 <luke-jr> … and 0.5.x I guess
1611 2011-11-21 20:37:42 <ThomasV> gmaxwell:  I mean double spend :)
1612 2011-11-21 20:37:49 <gmaxwell> ThomasV: currently, yes.
1613 2011-11-21 20:37:59 <[Tycho]> gmaxwell: there are lots of other pools which will happily accept that TX. Especially for a fee.
1614 2011-11-21 20:38:10 <gmaxwell> because we don't have any good infrastructure to catch it.. presumably the victim would see it.. but it would be hard to prove who did it.
1615 2011-11-21 20:38:34 <gmaxwell> [Tycho]: a >50% cartel _moots_ what other pools will do.
1616 2011-11-21 20:38:49 <ThomasV> gmaxwell: would the victim be able to tell who mined the block?
1617 2011-11-21 20:39:00 <gmaxwell> Because if they do something that displeases you, you don't extend their blocks. Thats the essential purpose of having >50%.
1618 2011-11-21 20:39:13 <[Tycho]> Oh, you are talking about cartel again.
1619 2011-11-21 20:39:16 <gmaxwell> ThomasV: not if the miner chooses to hide it.
1620 2011-11-21 20:39:35 <gmaxwell> [Tycho]: sorry. Yes. Though if your own pool is >50% you don't need a cartel.
1621 2011-11-21 20:39:59 <wumpus> luke-jr: it's kind of a bugfix -- the old critical section was not exception proof afaik
1622 2011-11-21 20:40:08 <ThomasV> gmaxwell: yes but in order to do a convincing double spend, they have to publish the block at some point...
1623 2011-11-21 20:40:12 <sipa> wumpus: i believe it was
1624 2011-11-21 20:40:18 <gmaxwell> (and in fact bitcoin will automatically split the chain so long as you manage to stay tied).
1625 2011-11-21 20:40:41 <gmaxwell> ThomasV: yes, but there doesn't need to be anything identifyable in the blocks. So you can't _prove_ who did it.
1626 2011-11-21 20:40:47 <wumpus> well it had trouble with break and continue ..
1627 2011-11-21 20:41:12 <sipa> indeed, but not with exceptions, imho
1628 2011-11-21 20:41:23 <wumpus> it was really strange
1629 2011-11-21 20:41:25 <iddo> maybe honest pools could also send to miners the pre-hashed block so the miners can look at the txns and see they aren't fishy? and then hash it themselves to verify they work on good block?
1630 2011-11-21 20:41:26 <[Tycho]> luke-jr: what's the point of having out-of-band comms between you and mtgox ?
1631 2011-11-21 20:41:39 <gmaxwell> [Tycho]: besides, btcguild proved that you can dork the fees substantially and lose ~noone. they went from free to 5% (pps) and didn't lose ~any hashpower.
1632 2011-11-21 20:42:22 <[Tycho]> Well, some pools are completely messed up, but have their own supporters and miners :)
1633 2011-11-21 20:42:50 <gmaxwell> 1TH... :) hardly a fluke.
1634 2011-11-21 20:43:42 <wumpus> maybe they like the pool for some other reason (ie, stats, ui ,etc)
1635 2011-11-21 20:44:06 <ThomasV> gmaxwell: perhaps a good criterion for accepting a confirmation is when the pool has actually sent the generated coins to its miners..? the miners know who they mine for
1636 2011-11-21 20:44:40 <luke-jr> [Tycho]: they don't pay fees
1637 2011-11-21 20:44:45 <TD> iddo: the problem is it's hard to do that
1638 2011-11-21 20:45:00 <[Tycho]> Well, I'm not paying fees too.
1639 2011-11-21 20:45:09 <TD> iddo: if miners double check the blocks, that's ok, but if there's a tx missing they can't assume there's foul play at work ....
1640 2011-11-21 20:45:30 <luke-jr> [Tycho]: sure, but MtGox likes to send transactions that you WOULD require fees for
1641 2011-11-21 20:45:38 <luke-jr> and Eligius almost always would
1642 2011-11-21 20:45:44 <BlueMatt> gavinandresen: is the sha1 of boost_1_47_0.tar.bz2 6e3eb548b9d955c0bc6f71c51042b713b678136a
1643 2011-11-21 20:46:02 <[Tycho]> Soon I will cooperate with a great trading site being currently developed by my mysterious friend.
1644 2011-11-21 20:46:06 d1scordian has joined
1645 2011-11-21 20:46:08 d1scordian has left ()
1646 2011-11-21 20:46:10 marioxcc has left ("ERC Version 5.3 (IRC client for Emacs)")
1647 2011-11-21 20:46:12 <iddo> to detect double-spend attempts maybe it's good enough?
1648 2011-11-21 20:46:13 d1scordian has joined
1649 2011-11-21 20:46:15 <BlueMatt> gavinandresen: can you just rerun the gbuild of boost-win32.yml
1650 2011-11-21 20:46:33 <gmaxwell> ThomasV: any large pool should have a nice balance of old coins.
1651 2011-11-21 20:46:35 <[Tycho]> luke-jr: what TXes ? With less-than-0.01 outputs ?
1652 2011-11-21 20:46:46 <luke-jr> [Tycho]: I don't know.
1653 2011-11-21 20:47:01 <gavinandresen> BlueMatt: yes, that is it's shasum
1654 2011-11-21 20:47:02 <luke-jr> [Tycho]: I don't look at what their txns contain :P
1655 2011-11-21 20:47:18 <[Tycho]> But you said "transactions that you WOULD require fees for" ^)
1656 2011-11-21 20:47:41 <BlueMatt> gavinandresen: ok, can you rerun the gbuild of boost-win32.yml a couple times and see if you get a reliable hash of boost-win32-1.47.0-gitian.zip
1657 2011-11-21 20:47:44 <TD> i wonder if one way to get back to the original distributed vision would be to have some standardized pool protocol, and then have the mainline bitcoin client be able to discover and join pools
1658 2011-11-21 20:47:51 <TD> with some kind of load balancing
1659 2011-11-21 20:47:55 <BlueMatt> gavinandresen: Ill be back in a while and Ill see what kind of hashes I can get...
1660 2011-11-21 20:48:05 <TD> rather than the p2pool approach of distributing the share tracking/payouts
1661 2011-11-21 20:48:14 <luke-jr> [Tycho]: all I know is they're not being included all the time :P
1662 2011-11-21 20:48:55 <gavinandresen> BlueMatt: will do
1663 2011-11-21 20:48:57 <TD> that way people wouldn't choose their pool, exactly
1664 2011-11-21 20:49:43 <helo> the optimal pool size would solve a block every week on average?
1665 2011-11-21 20:49:58 <sipa> ?
1666 2011-11-21 20:50:05 <luke-jr> TD: that'd just be automated pool hopping :P
1667 2011-11-21 20:50:08 <TD> right
1668 2011-11-21 20:50:11 <TD> sure. that's what i mean.
1669 2011-11-21 20:50:16 <luke-jr> everyone would use the pool currently offering the lowest fee
1670 2011-11-21 20:50:35 <TD> yes. an automated free market of pools, ie, similar to existing mining
1671 2011-11-21 20:50:53 wolfspraul has quit (Ping timeout: 260 seconds)
1672 2011-11-21 20:51:22 <TD> it assumes you can verify the pools operation
1673 2011-11-21 20:51:37 <wumpus> I don't see how that'd be better than p2pool
1674 2011-11-21 20:51:47 <wumpus> it'd be kind of the same
1675 2011-11-21 20:51:54 <luke-jr> …
1676 2011-11-21 20:51:54 danbri has quit (Read error: Connection reset by peer)
1677 2011-11-21 20:51:59 <luke-jr> there's a reason pool hopping is a problem
1678 2011-11-21 20:52:07 <luke-jr> multiple, even
1679 2011-11-21 20:52:14 wolfspraul has joined
1680 2011-11-21 20:52:28 <TD> well, i mean obviously there'd need to be something that prevents somebody setting a fee of zero and taking all the mining power automatically
1681 2011-11-21 20:52:36 <[Tycho]> "completely new graphical that uses the Qt" &
1682 2011-11-21 20:52:36 <TD> that's what i meant by automatic load balancing
1683 2011-11-21 20:52:42 EPiSKiNG- has joined
1684 2011-11-21 20:52:47 <TD> not purely a function of charged fee
1685 2011-11-21 20:53:32 <[Tycho]> gavinandresen just accidentally a whole interface ?
1686 2011-11-21 20:53:34 <luke-jr> TD: ok, I mine on the 0-fee pool, and YOU balance the load…
1687 2011-11-21 20:53:45 <luke-jr> [Tycho]: where u see
1688 2011-11-21 20:53:53 <[Tycho]> luke-jr: https://bitcointalk.org/index.php?topic=52480.0
1689 2011-11-21 20:54:14 <[Tycho]> Or it's valid english ?
1690 2011-11-21 20:54:21 <[Tycho]> I'm not sure :)
1691 2011-11-21 20:54:23 <TD> no it's just a thinko
1692 2011-11-21 20:54:32 <gavinandresen> [Tycho]: thanks, fixed
1693 2011-11-21 20:55:02 <gavinandresen> (updating readme on sourceforge now, too)
1694 2011-11-21 20:55:25 * [Tycho] likes native GUI
1695 2011-11-21 20:55:58 <TD> luke-jr: is the reason p2pool can't beat centralized pools variance written up somewhere?
1696 2011-11-21 20:56:05 <TD> it's been ages since i thought about this and i forgot the argument
1697 2011-11-21 20:56:09 <[Tycho]> Qt seems so ugly and slow to me... But that's just me.
1698 2011-11-21 20:56:49 <gmaxwell> TD: p2pool changed and its better now because it uses a merged mining side chain to reach consensus about pool shares.
1699 2011-11-21 20:56:58 <CIA-89> bitcoin: Gavin Andresen 0.4.x * r45593c271a5a bitcoind-stable/doc/release-process.txt: Don't forget to bump release numbers in READMEs next time
1700 2011-11-21 20:56:58 Snapman is now known as Snapman[afkers]
1701 2011-11-21 20:57:00 <TD> oh, it did?
1702 2011-11-21 20:57:05 <gmaxwell> It should be able to get good varience for the average speed members of the pool.
1703 2011-11-21 20:57:17 <gmaxwell> it will not be good for slow members.
1704 2011-11-21 20:57:18 <CIA-89> bitcoin: various 0.5.x * radb9f7..aaa1c3 bitcoind-stable/ (551 files in 73 dirs): (546 commits)
1705 2011-11-21 20:58:04 <TD> gmaxwell: is that inherent in being at the edge of the bell curve? ie could a separate p2pool instance for only slow/fast members solve that issue?
1706 2011-11-21 20:58:18 <gmaxwell> there is a weird tradeoff where a smaller p2pool can give lower varience.. because if the pool is too big it'll solve more bitcoin blocks but your shares will ba more noisy.
1707 2011-11-21 20:58:21 <gmaxwell> TD: yes!
1708 2011-11-21 20:58:32 <TD> hmm
1709 2011-11-21 20:58:41 <gmaxwell> (er yes, a second p2pool with slow members would help)
1710 2011-11-21 20:59:20 <TD> so ideally, p2pool would be integrated with core bitcoin, all miners would point their GPUs at their local instance, and bitcoind would measure that speed then connect to one of a handful of separate p2pool instances
1711 2011-11-21 20:59:49 <TD> it'd all be integrated and that would take us back to the earlier decentralized days
1712 2011-11-21 21:00:20 <gmaxwell> (bascally the tradeoff is that you don't want the p2pool blocks to come too fast or participants can't keep up with the p2pool chain.. but if you make them slow, then they have high difficulty thus high shot noise for miners)
1713 2011-11-21 21:00:38 <TD> right, makes sense
1714 2011-11-21 21:00:42 <luke-jr> https://bitcointalk.org/index.php?topic=52503.0 <-- 0.4.1 release :P
1715 2011-11-21 21:00:57 <[Tycho]> ""Splash" graphics at startup that show address/wallet/blockchain loading progress" - is it modal or non-modal ?
1716 2011-11-21 21:01:11 <luke-jr> [Tycho]: Qt is native.
1717 2011-11-21 21:01:38 <wumpus> I don't think 'modal' has any meaning if the application has no other windows open to block
1718 2011-11-21 21:01:47 <[Tycho]> luke-jr: surely it's not. At least on windows.
1719 2011-11-21 21:01:52 <luke-jr> [Tycho]: sure it is.
1720 2011-11-21 21:01:55 <luke-jr> and who uses Windows?
1721 2011-11-21 21:02:02 <[Tycho]> Everyone.
1722 2011-11-21 21:02:08 <[Tycho]> That's a fact.
1723 2011-11-21 21:02:11 <TD> heh
1724 2011-11-21 21:02:15 <luke-jr> nobody developing Bitcoin clients it seems
1725 2011-11-21 21:02:17 <TD> the new gui is better designed than the old one
1726 2011-11-21 21:02:28 <TD> fully native ui is usually preferable, but win32 programming is not much fun
1727 2011-11-21 21:02:35 <TD> (speaking as somebody who used to work with the windows api for a living)
1728 2011-11-21 21:02:37 <luke-jr> Qt is fully native.
1729 2011-11-21 21:02:42 <TD> so i'm not at all surprised there was a switc
1730 2011-11-21 21:02:45 <wumpus> well, good luck making a fully native ui for every supported platform ...
1731 2011-11-21 21:02:59 PK has quit ()
1732 2011-11-21 21:03:08 wolfspraul has quit (Ping timeout: 260 seconds)
1733 2011-11-21 21:03:15 <TD> gmaxwell: so current status of p2pool is that they are/were waiting for the 0.5 release so they can include transactions
1734 2011-11-21 21:03:21 <[Tycho]> Sometimes you may not want to download the blockchain.
1735 2011-11-21 21:03:32 <luke-jr> [Tycho]: loading, not downloading
1736 2011-11-21 21:03:46 <luke-jr> [Tycho]: downloading is shown in the status bar after it's started
1737 2011-11-21 21:04:06 <wumpus> the splash screen is just there to show that it is doing something, that used to be the time that you didn't see anything and had to wait for the window to pop up
1738 2011-11-21 21:04:15 wolfspraul has joined
1739 2011-11-21 21:04:18 <[Tycho]> Will it show current block number ?
1740 2011-11-21 21:04:24 <luke-jr> [Tycho]: in the tooltip
1741 2011-11-21 21:04:30 <luke-jr> also the timestamp on it
1742 2011-11-21 21:04:36 <[Tycho]> :(
1743 2011-11-21 21:04:36 <luke-jr> (relative)
1744 2011-11-21 21:04:55 <TD> the new ui is much more friendly than the last one, imho
1745 2011-11-21 21:05:00 * luke-jr wonders what the tooltip shows for future timestamps
1746 2011-11-21 21:05:03 <gmaxwell> TD: the code is in for that now (in git) and there are p2pool users mining transactions.
1747 2011-11-21 21:05:11 <TD> gmaxwell: nice. it's all coming together then.
1748 2011-11-21 21:05:47 <gmaxwell> Yea, — well right now I think the biggest issue is that its poorly scalable python code. I pointed 10GH at it and it just kinda hung up. :)
1749 2011-11-21 21:06:05 <TD> hah
1750 2011-11-21 21:06:07 <[Tycho]> I'm used to ask my users if their block count in the statusbar is over X or not
1751 2011-11-21 21:06:07 <TD> yes, that's unfortunate
1752 2011-11-21 21:06:09 <gmaxwell> (but I guess 10GH is the size of the entire p2pool network right now)
1753 2011-11-21 21:06:14 <luke-jr> gmaxwell: fail
1754 2011-11-21 21:06:29 <luke-jr> [Tycho]: tooltip is fine :P
1755 2011-11-21 21:06:29 <TD> i guess it'll have to be replaced with c++ at some point, especially if integrated into the main code
1756 2011-11-21 21:06:43 <wumpus> luke-jr: hehe I think it will show -XXX seconds
1757 2011-11-21 21:06:46 <luke-jr> my Python code can easily do numerous TH/s
1758 2011-11-21 21:07:23 <TD> gmaxwell: i wonder if rather than have an entirely separate p2p network, the pubsub system could be used
1759 2011-11-21 21:07:39 * TD keeps meaning to try that out
1760 2011-11-21 21:07:46 Nesetalis has quit (Read error: Connection reset by peer)
1761 2011-11-21 21:07:53 <gmaxwell> TD: you'd want different topology.
1762 2011-11-21 21:08:10 <gmaxwell> (e.g. the members of the pool should peer rather than carrying that traffic over the normal topology)
1763 2011-11-21 21:08:39 Nesetalis has joined
1764 2011-11-21 21:08:40 <TD> too much noise otherwise? it just seems a shame to not re-use the pre-existing infrastructure
1765 2011-11-21 21:11:31 <gmaxwell> well, poor scale.. the purpose of running multiple p2pools is because nodes couldn't keep up with the half-second block times needed to give stable payouts for a p2pool the size of all bitcoin.
1766 2011-11-21 21:12:08 <gmaxwell> So by running many p2pools you have it so that $some p2pool has a poolblock every half second, but any particular pool will have blocks with a reasonable rate.
1767 2011-11-21 21:12:20 d1scordian_ has joined
1768 2011-11-21 21:12:29 d1scordian_ has quit (Client Quit)
1769 2011-11-21 21:14:24 d1scordian has quit (Ping timeout: 245 seconds)
1770 2011-11-21 21:15:23 <tcatm> gavinandresen: bitcoin.org updated
1771 2011-11-21 21:15:37 <gavinandresen> tcatm: thanks!
1772 2011-11-21 21:16:02 <iddo> another idea is to prevent pool-mining at protocol level
1773 2011-11-21 21:16:22 <iddo> by requiring private key to generate the block
1774 2011-11-21 21:16:28 <[Tycho]> What's that Lightfoot Hosting's node ?
1775 2011-11-21 21:16:30 <iddo> i think it was an idea of luke-jr
1776 2011-11-21 21:16:49 <iddo> should be something like hash(txns,nonce,sign_sk(txn,nonce))
1777 2011-11-21 21:17:18 <gavinandresen> iddo:  and who gets to be in charge of distributing the approved private keys?
1778 2011-11-21 21:17:19 <iddo> and reward can also be spend by the person who has the privkey sk
1779 2011-11-21 21:17:41 <iddo> i mean this will force everyone to do solo-mining
1780 2011-11-21 21:17:42 <wumpus> hm how would that change things... the pool could simply use its own private key, then promise to send out the money to the participants
1781 2011-11-21 21:17:58 <iddo> so it might be good only if some kind of p2pool can be integrated at protocol level
1782 2011-11-21 21:18:45 <wumpus> it'd muck up trust issues a bit but I don't think you can prevent pools
1783 2011-11-21 21:18:54 <iddo> thing is, ECDSA sign_sk(block,nonce) isn't GPU-friendly?
1784 2011-11-21 21:21:08 <gmaxwell> iddo: hey thats a clever idea at least. oh well.
1785 2011-11-21 21:21:51 <iddo> to allow pool-mining it would need something like hash(txns,nonce,sign_sk1(txns,nonce),sign_sk2(txns))
1786 2011-11-21 21:22:00 <iddo> where sk2 is privkey of pool operator
1787 2011-11-21 21:22:13 <gmaxwell> Requring the worker to have access to trusted data creates operational challenges or scaled up mining in any case. I'm very happy that I can have the amd propritary binary drivers on a system which doesn't have a wallet on it.
1788 2011-11-21 21:22:15 <TD> i'm not sure pooled mining should be forbidden, exactly
1789 2011-11-21 21:22:20 <iddo> gmaxwell: do you know if ECDSA is GPU friendly?
1790 2011-11-21 21:22:28 <TD> if it's easier to use a built-in solution that is distributed, that is probably good enough
1791 2011-11-21 21:22:37 <TD> pooling might be a simple way of doing really small micropayments on top of bitcoin
1792 2011-11-21 21:22:52 <TD> ie, rather than pay, you mine to a pool for a few seconds
1793 2011-11-21 21:23:04 ThomasV has quit (Ping timeout: 240 seconds)
1794 2011-11-21 21:23:09 <gmaxwell> iddo: I'm not aware of any very fast implementations of it on the gpu. It's pretty silicon friendly though.
1795 2011-11-21 21:23:12 <TD> that "pool" may itself just be a node in the p2pool
1796 2011-11-21 21:23:35 <gmaxwell> TD: thats really why I morn the loss of casual cpu mining... it totally F@#$@#s up our ability to use tiny fees as anti-dos measures.
1797 2011-11-21 21:23:44 <iddo> but if it's built-in solution that isn't mandatory, some people might prefer more efficient pools and give their hash power to pool operator who might be malicious
1798 2011-11-21 21:24:01 <TD> i suspect you overestimate the dedication of the average miner
1799 2011-11-21 21:24:13 <TD> eventually i guess the era of the pool may come to an end
1800 2011-11-21 21:24:26 <TD> and all miners would be industrial conglomerates with big ASIC filled datacenters
1801 2011-11-21 21:24:37 <TD> it has been speculated upon many times. who knows if bitcoin will ever get that far
1802 2011-11-21 21:24:39 <gmaxwell> TD: e.g. a really boring desktop core could mine enough to do a dozen w/ fee transactions per week. We'd have much more ability to avoid dos if every bitcoin user could have a slight mining income stream.
1803 2011-11-21 21:24:57 <TD> yeah
1804 2011-11-21 21:25:18 <TD> well, that's what an integrated low-speed p2pool could do. make that viable again. cpu mining would never actually make economic sense though, right
1805 2011-11-21 21:26:53 <gmaxwell> Thankfully we serve homosapien not homoeconomicus... though some bitcoiners make me wonder.
1806 2011-11-21 21:27:31 <gmaxwell> (when they scream omg cpu mining is unprofitable! when someone just wants to mine a little on a single desktop— for the $1/month it'll cost you, who gives a @#$#@ about it being slightly negatively profitable)
1807 2011-11-21 21:28:06 <gmaxwell> (having to negoiate with someone to BUY bitcoin is seriously costly even if it's more efficient in a very narrow econonmic analysis)
1808 2011-11-21 21:31:08 <TD> yeah. sigh. so many problems. i guess p2p exchanges would be the next thing, after going back to decentralized mining
1809 2011-11-21 21:31:21 <TD> well maybe not problems. opportunities for optimization
1810 2011-11-21 21:35:13 wolfspraul has quit (Ping timeout: 260 seconds)
1811 2011-11-21 21:35:30 wolfspraul has joined
1812 2011-11-21 21:38:06 Nesetalis has quit (Quit: <+shponka> how does one scissor with four people <+shponka> hypercube tribadism)
1813 2011-11-21 21:44:50 danbri has joined
1814 2011-11-21 21:51:15 d1scordian has joined
1815 2011-11-21 21:52:30 BlueMatt has quit (Quit: Ex-Chat)
1816 2011-11-21 21:53:04 firesign has quit (Ping timeout: 248 seconds)
1817 2011-11-21 21:53:32 iocor has quit (Quit: Computer has gone to sleep.)
1818 2011-11-21 21:54:08 midnightmagic has quit (Ping timeout: 258 seconds)
1819 2011-11-21 21:56:08 midnightmagic has joined
1820 2011-11-21 21:57:24 <luke-jr> iddo's idea would work by forcing every single nonce to be signed by the same key that is used to redeem the reward
1821 2011-11-21 21:58:02 zeiris has joined
1822 2011-11-21 21:58:32 <luke-jr> pools can't distribute the key, cuz then any miner could redeem the reward
1823 2011-11-21 21:59:22 <Edward_Black> gmaxwell having to buy bitcoin is also quite comfortable  if you are a buy-and-send user like myself. Ability to withdraw from gox straight to destination only makes it even more attractive. So buying bitcoin is also more attractive when you extend analysis to things such as comfort for certain user demographics
1824 2011-11-21 22:00:35 <TD> luke-jr: yeah, it makes sense, *if* you want to prevent pooling rather than just discourage it .....
1825 2011-11-21 22:00:52 <luke-jr> the downside is, it makes GPUs less efficient
1826 2011-11-21 22:01:57 iocor has joined
1827 2011-11-21 22:02:08 <iddo> luke-jr: i think you had some idea about how to design scalable p2pool at protocol level for this no-pool-mining scenario?
1828 2011-11-21 22:02:25 <luke-jr> no
1829 2011-11-21 22:04:18 <gmaxwell> iddo: the current solution appears reasonable scalable to me.
1830 2011-11-21 22:04:27 <iddo> maybe if hash() includes ECDSA sign() then better move all the way to scrypt hash instead of sha256, scrypt is supposed to give less advantage to ASICs over regular cpus?
1831 2011-11-21 22:04:46 <luke-jr> iddo: no, scrypt is just as vuln to ASICs
1832 2011-11-21 22:04:52 marf_away has quit (Ping timeout: 258 seconds)
1833 2011-11-21 22:04:54 <luke-jr> iddo: scrypt is just GPU-resistant, which is a bad thing
1834 2011-11-21 22:05:04 <iddo> ok
1835 2011-11-21 22:05:22 Joric has joined
1836 2011-11-21 22:05:42 <gmaxwell> iddo: scrypt is only seriously asic resistant when you use a lot of ram, it's not clear at all to me that they're actually using enough ram to have this effect. In the scrypt papers the authors use 40 megabytes in their 'big' example.
1837 2011-11-21 22:05:47 [7] has quit (Disconnected by services)
1838 2011-11-21 22:05:51 TheSeven has joined
1839 2011-11-21 22:06:20 <iddo> i don't really know how to measure p2pool scalability potential... i think luke-jr thinks it isn't scalable
1840 2011-11-21 22:06:53 <luke-jr> gmaxwell: that doesn't make it ASIC resistant, just more memory needed
1841 2011-11-21 22:06:56 <luke-jr> afaik
1842 2011-11-21 22:06:58 <etotheipi_> for reference, I just implemented a scrypt-like KDF... and 40 MB is about as big as I can go on my Intel i5 CPU within 0.25s...
1843 2011-11-21 22:07:00 <gmaxwell> iddo: I think luke's conclusion is based on the initial version that didn't use a blockchain for share consensus and simply required everyone to be paid in every block.
1844 2011-11-21 22:07:07 <luke-jr> the problem is the goal is wrong
1845 2011-11-21 22:07:20 <Edward_Black> Scrypt coins have to become stupidly expensive to be worth developing an ASIC for mining, and at that point ASIC miners will be competing with various pro-miner conglomerates and botnets, and you can't compete with botnets
1846 2011-11-21 22:07:29 <luke-jr> gmaxwell: no, my conclusion is based on the necessity of only paying large amounts
1847 2011-11-21 22:07:37 <gmaxwell> luke-jr: read the scrypt paper.
1848 2011-11-21 22:07:47 <gmaxwell> luke-jr: it doesn't have to only pay large amounts.
1849 2011-11-21 22:07:48 <luke-jr> Edward_Black: ASIC can compete with botnets
1850 2011-11-21 22:07:53 <luke-jr> gmaxwell: it does.
1851 2011-11-21 22:08:14 <Edward_Black> ASIC has free electricity ?
1852 2011-11-21 22:08:26 <gmaxwell> luke-jr: no, since it has a consensus chain it can have stored debt in the chain and do whatever payouts it wants to do.
1853 2011-11-21 22:08:26 <luke-jr> Edward_Black: it doesn't have to
1854 2011-11-21 22:08:35 <luke-jr> gmaxwell: oh, hmm
1855 2011-11-21 22:09:20 <iddo> in theory it could be possible to follow satoshi's suggestion about upgrading the hash function by adding extra field of new hash that's respected from certain block in the future, so could combine this idea with ecdsa no-pools or scrypt, though i agree it's unclear whether those are good ideas
1856 2011-11-21 22:09:36 <luke-jr> iddo: scrypt is a regression
1857 2011-11-21 22:09:38 <luke-jr> SHA256 is better
1858 2011-11-21 22:09:40 <gmaxwell> All it can't do is maintain an unpaid balance of bitcoins (at least not without introducing trusted escrows for it). Any debt has to be paid by future income.
1859 2011-11-21 22:09:45 <luke-jr> ECDSA has the same problem as scrypt
1860 2011-11-21 22:09:56 <gmaxwell> worse than scrypt, in fact.
1861 2011-11-21 22:10:21 <Edward_Black> also, I suspect that ASICs will have a lot of other costs, which botnets just don't care about (they don't pay rent as well, and taxes)
1862 2011-11-21 22:10:32 <gmaxwell> ecdsa is very fast in dedicated logic. much more so than scrypt or sha256.. point multiplies are a pain on a general purpose processor but easy when xor gates are cheap.
1863 2011-11-21 22:10:46 <luke-jr> Edward_Black: the problem is not the cost
1864 2011-11-21 22:11:32 Turingi has quit (Read error: Connection reset by peer)
1865 2011-11-21 22:11:34 <Edward_Black> So, we're discussing free asics in a vacuum developed for free by altruistic research team ?
1866 2011-11-21 22:11:48 <luke-jr> Edward_Black: no, we're talking about a fixed cost to easily overcome the entire network
1867 2011-11-21 22:12:18 <luke-jr> the problem is people are attacking GPUs
1868 2011-11-21 22:12:24 <luke-jr> as if there's a problem with GPU mining
1869 2011-11-21 22:12:28 <upb> discussing asics developed by theists
1870 2011-11-21 22:12:29 <upb> :)
1871 2011-11-21 22:12:48 <luke-jr> so they're making hash() more complicated
1872 2011-11-21 22:12:53 <Edward_Black> I bet you a bitcoin theists will charge dearly for their R&D
1873 2011-11-21 22:12:56 <luke-jr> when in reality, what is needed is making hash() *simpler*
1874 2011-11-21 22:13:01 <luke-jr> so CPUs can do *as well as* GPUs
1875 2011-11-21 22:13:30 <Edward_Black> Generally, I see scrypt as a differentiation tool, nothing more nothing less
1876 2011-11-21 22:14:12 <etotheipi_> luke-jr, the only way to make CPUs work as well as GPUs is to limit how many GPU cores can run at any given time, either through extraordinarily inefficient operations (GPU-specific), or by requiring a lot of RAM
1877 2011-11-21 22:14:20 <Edward_Black> And I can not see anyone except perhaps Victor von Doom making a TBX / LTC ASIC until one of those coins reaches like a hundred bucks a pop
1878 2011-11-21 22:14:26 <Edward_Black> Which is preposterous
1879 2011-11-21 22:15:00 <luke-jr> etotheipi_: not quite.
1880 2011-11-21 22:15:14 <etotheipi_> any alg that requires less than a few kB of mem per thread is going to get maximum speed up on a GPU
1881 2011-11-21 22:15:27 <luke-jr> etotheipi_: a system with more cores will always perform better. that isn't a problem.
1882 2011-11-21 22:15:28 <etotheipi_> rel to CPUs
1883 2011-11-21 22:15:45 <gmaxwell> etotheipi_: well.. not quite. E.g. use a lot of integer division or some other function that cpus provide more of than gpus. ;)
1884 2011-11-21 22:15:46 chrisb__ has quit (Quit: Ex-Chat)
1885 2011-11-21 22:16:16 <etotheipi_> right, integer division is slow for sure... but I'm not convinced it's slow enough to disarm GPUs of their advantage
1886 2011-11-21 22:16:24 <gmaxwell> but really, with things like the APUs the gap is closing on its own.
1887 2011-11-21 22:17:00 <gmaxwell> also, I'm going to laugh when some dude with 4 knights ferry cards 50% attacks one of the scrypt block chains.
1888 2011-11-21 22:17:05 <z310> gmaxwell: your name always makes me think of the beatles song maxwell's silver hammer
1889 2011-11-21 22:17:21 <luke-jr> lol
1890 2011-11-21 22:17:27 <gmaxwell> z310: it explains my argument style on the internet. bop bop bop
1891 2011-11-21 22:17:49 <z310> haha
1892 2011-11-21 22:18:22 <z310> unfittingly upbeat
1893 2011-11-21 22:18:42 <upb> upbeat is a bad word. as is cupboard and groupby :)
1894 2011-11-21 22:19:22 <z310> o.o
1895 2011-11-21 22:19:26 <iddo> Edward_Black: did you give more thought to the idea of decentralized laundy? instead of millions of pre-mined coins controlled by single person?
1896 2011-11-21 22:19:47 <z310> i ready laundry
1897 2011-11-21 22:19:52 * z310 sips his coffee
1898 2011-11-21 22:20:00 <luke-jr> laundry is bad
1899 2011-11-21 22:20:04 <Edward_Black> iddo I am an econ person, not a programming / sysarch dude
1900 2011-11-21 22:20:09 <iddo> there was a suggestion here about how to do it, i think an idea of cjdelisl1
1901 2011-11-21 22:20:15 peck has quit (Ping timeout: 245 seconds)
1902 2011-11-21 22:20:18 <Edward_Black> MBA here :~)
1903 2011-11-21 22:20:23 <iddo> when wanting to do txn, group of several nodes get together and sum up all their inputs, and randomly choose which one goes to which output
1904 2011-11-21 22:20:26 <z310> iddo: might be worth considering i was an early early adopter
1905 2011-11-21 22:20:31 <z310> cpu mined some 20,000 btc
1906 2011-11-21 22:20:37 BlueMatt has joined
1907 2011-11-21 22:20:39 <z310> made a mere $1,000 off it
1908 2011-11-21 22:20:51 <luke-jr> lol
1909 2011-11-21 22:20:54 <gmaxwell> z310: not atypical.
1910 2011-11-21 22:20:56 <iddo> if police captures the person who spent the btc after several iterations of this, they have no clue if it's stolen coins because of the mixing
1911 2011-11-21 22:21:18 <luke-jr> iddo: they trace it back to the mixer(s)
1912 2011-11-21 22:21:21 <luke-jr> iddo: and arrest all of them
1913 2011-11-21 22:21:31 <Edward_Black> iddo from what I can gather  it is incredibly user-unfriendly amd likely "crypo-tricky"
1914 2011-11-21 22:21:44 <iddo> all = arrest exponential number of people?
1915 2011-11-21 22:21:51 <Edward_Black> luke-jr good luck with the last lol
1916 2011-11-21 22:21:53 <upb> not to mention that mtgox freezes all the coins connected to the mixer for the customers own good
1917 2011-11-21 22:22:07 <z310> apparently i misunderstood
1918 2011-11-21 22:22:13 <Edward_Black> upb source ?
1919 2011-11-21 22:22:16 <luke-jr> Edward_Black: laundry is illegal
1920 2011-11-21 22:22:23 <upb> s/freezes/would freeze/
1921 2011-11-21 22:22:28 <luke-jr> arrest everyone laundering
1922 2011-11-21 22:22:33 <Edward_Black> luke-jr again, good luck with making a case
1923 2011-11-21 22:22:41 <iddo> Edward_Black: it's user-friendly, the client will implement multiparty computation automatically among several nodes
1924 2011-11-21 22:23:05 <luke-jr> Edward_Black: it's either laundered or not
1925 2011-11-21 22:23:12 <Edward_Black> iddo the nodes need to find each other, negotiate sizes of txins (iirc they have to be same size) etc
1926 2011-11-21 22:23:24 <upb> which you could do even in js
1927 2011-11-21 22:23:35 <iddo> but i'm not sure if we want bitcoin to function as laundy, would put bitcoin on goverments radar much more quickly
1928 2011-11-21 22:24:00 <Edward_Black> Also, as far as I can tell from the thread linked from bitcoinfog thread it relies on some pretty nover construct
1929 2011-11-21 22:24:11 <Edward_Black> novel ))
1930 2011-11-21 22:24:24 wolfspraul has quit (Quit: leaving)
1931 2011-11-21 22:24:51 <iddo> Edward_Black: they don't have to be same size, you need secure multiparty computation so the other nodes cannot rat on you, after the nodes decide the output that's all that would be visible in the blockchain
1932 2011-11-21 22:25:26 <iddo> you can think of it as somewhat similar to implementing mental poker
1933 2011-11-21 22:26:16 <gmaxwell> iddo: there is an approach for anonymous loans which is described .. hmmhmm
1934 2011-11-21 22:26:42 stalled has quit (Ping timeout: 244 seconds)
1935 2011-11-21 22:26:45 <TD> it was described by hal finney at some point
1936 2011-11-21 22:26:58 <TD> i didn't find it especially compelling. you still need strongly identified nodes
1937 2011-11-21 22:27:10 <TD> you just don't know the sizes of the loans
1938 2011-11-21 22:27:24 <Edward_Black> iddo like I said, I am TBX econ, not TBX crypto. I can ask Lolcust to forward questions about decentralized laundry ring thing to ArtForz who will hopefully comment on it when he gets time
1939 2011-11-21 22:27:57 <iddo> hmm link to anonymous loans? sounds interesting
1940 2011-11-21 22:28:38 <TD> they're "anonymous" unless you don't repay
1941 2011-11-21 22:28:50 <TD> then your identity is revealed. that's why you need to be strongly identified to take part - so somebody can go break legs
1942 2011-11-21 22:29:04 <Edward_Black> iddo also, doesn't forming a laundry ring impy that all participants (who somehow found each other) need to connect to each other directly ?
1943 2011-11-21 22:29:12 <gmaxwell> td: yea I _thought_ it was hal finney.
1944 2011-11-21 22:29:17 <gmaxwell> but I don't see it on his page.
1945 2011-11-21 22:29:57 <gmaxwell> td: been searching for "kneepcap" because I thought I remembered the kneecap step.
1946 2011-11-21 22:30:05 <iddo> Edward_Black: tbx premise is that you need millions of pre-mined coins controlled by single person for laundy? i'm trying to convince you that decentralized laundy is possible, so tbx isn't good for it
1947 2011-11-21 22:30:28 <TD> it was originally described by wei da, i think
1948 2011-11-21 22:30:48 <gmaxwell> In any case.. in that scheme I think that you have your distributed mixer too.. but mixers are dumb and I think people who obsess about them haven't really contemplated what purpose money laundering actually serves in the world.
1949 2011-11-21 22:30:49 <iddo> Edward_Black: the idea is that in bitcoin all the txns will be anonymous, so cannot have non-laundy txns
1950 2011-11-21 22:31:17 <gmaxwell> Because having your money be part of some pool of criminal money doesn't actually do you much good.
1951 2011-11-21 22:31:53 E-sense has joined
1952 2011-11-21 22:32:03 <gmaxwell> "Okay, we're still digging through your hard drive to determined _what_ crimes you were involved in, but in the meantime while we make our case there is this little tax bill we need to you fill out from your cell"
1953 2011-11-21 22:32:31 <Edward_Black> Well, that's why I insisted that TBX should have a version of GUI client with no explicit "talk to laundry with this button" parts of interface
1954 2011-11-21 22:32:49 <upb> what's TBX
1955 2011-11-21 22:32:49 <Edward_Black> so "I'm in it for the speculation" type of PD is preserved
1956 2011-11-21 22:33:29 <luke-jr> iddo: Bitcoin is not anonymous, and does not facilitate laundry
1957 2011-11-21 22:33:34 <luke-jr> iddo: laundry is illegal
1958 2011-11-21 22:33:39 <Edward_Black> an alt-coin upb, I am involved with its econ and some minor aspect of "strong transaction decorrelator" operation
1959 2011-11-21 22:33:48 <iddo> upb: alt-coin with scrypt hash and infinite inflation, and millions of pre-mined coins...
1960 2011-11-21 22:33:51 <gmaxwell> iddo: the scheme I'm thinking of is mentioned at hte bottom of here: http://webcache.googleusercontent.com/search?q=cache:aCEm8IoaeNAJ:szabo.best.vwh.net/garnishment.html+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a
1961 2011-11-21 22:33:57 <upb> LOL
1962 2011-11-21 22:33:59 <Edward_Black> luke-jr sue my ip :~)
1963 2011-11-21 22:34:00 <iddo> thanks
1964 2011-11-21 22:34:00 <upb> okay
1965 2011-11-21 22:34:16 <luke-jr> Edward_Black: it's not lawsuit-illegal, it's criminal-illegal
1966 2011-11-21 22:34:18 <TD> https://bitcointalk.org/index.php?topic=5027.0
1967 2011-11-21 22:34:21 <gmaxwell> iddo: bitcoin doesn't provide anonymity, it uses the tools of anonymity to provide privacy. But the anonymity it provides as a side effect is very weak.
1968 2011-11-21 22:34:22 <TD> see second post
1969 2011-11-21 22:34:34 <luke-jr> Bitcoin is a good-guy currency.
1970 2011-11-21 22:34:44 <upb> iddo already said everything that needed to be said :)
1971 2011-11-21 22:34:53 <gmaxwell> TD: thanks!
1972 2011-11-21 22:36:08 <Edward_Black> iddo you do realize that there is simply no such thing as "inflation" in *-coins ? At most, you can say that hypothetically, an infini-coin might have an overprodution crisis issue of some sort (the very reason I convinced lolcust to go forward with coin-mass limiting trick) but even that is very elusive, as mpirical observation of alt-coins demonstrates
1973 2011-11-21 22:36:09 <iddo> in a perfect world i guess it's arguable whether this kind of anonymity mixing is a good idea for bitcoin, but in this world it's probably bad, goverments wouldn't like it
1974 2011-11-21 22:36:17 BlueMatt has quit (Ping timeout: 240 seconds)
1975 2011-11-21 22:36:30 <luke-jr> iddo: it's bad.
1976 2011-11-21 22:36:40 <iddo> Edward_Black: i meant monetary inflation
1977 2011-11-21 22:36:52 <Edward_Black> JESUS CHRIST
1978 2011-11-21 22:36:58 <gmaxwell> Yes?
1979 2011-11-21 22:37:04 <iddo> :)
1980 2011-11-21 22:37:17 <Edward_Black> iddo please, tbx can not have monetary inflation because it is not a currency
1981 2011-11-21 22:37:18 <Edward_Black> BUT
1982 2011-11-21 22:37:50 <luke-jr> …
1983 2011-11-21 22:37:55 <luke-jr> /ignore Edward_Black
1984 2011-11-21 22:38:07 <Edward_Black> even if it was (Let's say some insane dictator in Africa declares it his state's currency), the fee-furnace ensures that it will inevitably stabilize
1985 2011-11-21 22:38:12 * luke-jr tires of utter idiocy
1986 2011-11-21 22:39:02 <iddo> Edward_Black: tbx has constant num of new coins reward with each new block, forever... i remember you don't consider this to be infinite monetary inflation, but i failed to understand you
1987 2011-11-21 22:39:21 <luke-jr> iddo: he's an idiot making an invalid argument on semantics
1988 2011-11-21 22:39:45 <luke-jr> iddo: he's trying to redefine "currency"
1989 2011-11-21 22:40:40 <upb> oh, his coinz dont have monetary inflation since the coinz arent currency ?:P
1990 2011-11-21 22:40:43 <upb> good argument. not
1991 2011-11-21 22:40:44 <Edward_Black> iddo my point is two-fold. First, this is not monetary inflation (at most, you can claim an inevitable overproduction crisis of some sort). Second, the infinite "overproduction" issue (as well as some hypothetical inflation issue in an impossible world where inflation would apply) is solved by increasing coin loss in a manner that scales up with adoption
1992 2011-11-21 22:40:46 <luke-jr> and from there redefine "money"
1993 2011-11-21 22:40:53 <gmaxwell> luke-jr: or rather he's adopted a common domain specific usage of the word which isn't consistent with the bitcoin communities consistent. He might argue that his definition is right, but I don't recall any law giving economists control over all the words they use. :)
1994 2011-11-21 22:41:09 <iddo> Edward_Black: i also failed to understand your distinction between currency and money
1995 2011-11-21 22:41:15 <luke-jr> gmaxwell: the legal definition is what matters, and I'm pretty sure it disagrees with his
1996 2011-11-21 22:42:05 <Edward_Black> Currency has properties of universality in a given econ system, while money (when defined permissively) is anything you and me and maybe some other guys can agree to use as exchange medium
1997 2011-11-21 22:42:35 <iddo> currency is fungible and money isn't?
1998 2011-11-21 22:42:59 <Edward_Black> fugibility (to different extent) can be property of both
1999 2011-11-21 22:43:04 <Edward_Black> Let's make it very simple
2000 2011-11-21 22:43:17 <luke-jr> iddo: he's pretending "currency" is only what the king declares to be
2001 2011-11-21 22:43:20 <Edward_Black> Let's say you decide to pay me in gold ingots
2002 2011-11-21 22:43:23 <iddo> Edward_Black: monetary inflation doesn't mean increasing the money supply? what term do you use for increasing the money supply?
2003 2011-11-21 22:43:59 <Edward_Black> *currency* supply under certain assumptions regarding to market
2004 2011-11-21 22:44:24 <Edward_Black> You don't say that diamonds would suffer inflation if DB folks decide to flood the markets with them
2005 2011-11-21 22:44:41 <iddo> DB = ?
2006 2011-11-21 22:44:48 <nanotube> debeers i think
2007 2011-11-21 22:44:55 <Edward_Black> DeBeers. the best cartel ever
2008 2011-11-21 22:45:13 <iddo> so currency is gov fiat money ?
2009 2011-11-21 22:45:16 <nanotube> at any rate, it seems this belongs better in #bitcoin
2010 2011-11-21 22:45:28 <nanotube> best leave the -dev logs full of more dev-y things
2011 2011-11-21 22:46:00 <Edward_Black> iddo I think yes. Lolcust thinks no, and we argue a lot about that )) Also, nanotube is right )
2012 2011-11-21 22:46:30 <sipa> so there was no currency before fiat money existed?
2013 2011-11-21 22:46:38 BlueMatt has joined
2014 2011-11-21 22:46:46 <iddo> if we move to #bitcoin now, someone curious 50 years from now will start reading the logs and wouldn't know how the conversation ends:)
2015 2011-11-21 22:47:00 <BlueMatt> gavinandresen: ping
2016 2011-11-21 22:47:03 <gavinandresen> pong
2017 2011-11-21 22:47:10 <Edward_Black> He wil ask his AI to help, iddo
2018 2011-11-21 22:47:11 <nanotube> iddo: they will, because they'll see people saying conversation is migrating to #bitcoin
2019 2011-11-21 22:47:16 <nanotube> and will move over to #bitcoin logs
2020 2011-11-21 22:47:28 <BlueMatt> gavinandresen: I ran it 3 times with two different settings and still got 7242ba60b103a1e852e6df288cdbf0eb278cdb6adae741181faf0d6e9fcca9c5
2021 2011-11-21 22:47:50 <BlueMatt> gavinandresen: has sipa, tcatm, or devrandom had a chance to run it yet?
2022 2011-11-21 22:47:53 <iddo> there are #bitcoin logs?
2023 2011-11-21 22:47:58 <sipa> BlueMatt: not yet
2024 2011-11-21 22:48:03 <BlueMatt> iddo: yea, same site as the -dev ones
2025 2011-11-21 22:48:19 <iddo> ahh i didn't know, cool
2026 2011-11-21 22:48:28 <upb> Edward_Black: why didnt you call it LOLCOIN btw ?
2027 2011-11-21 22:48:40 <luke-jr> upb :D
2028 2011-11-21 22:49:01 coingenuity has joined
2029 2011-11-21 22:49:25 ThomasV has joined
2030 2011-11-21 22:49:39 peck has joined
2031 2011-11-21 22:50:37 <Edward_Black> upb it wasn't me who picked the name, it was lolcust and artforz
2032 2011-11-21 22:51:21 <Edward_Black> sipa I responded to your question in #bitcoin, to honor nanotube's suggestion
2033 2011-11-21 22:54:41 ForceMajeure has joined
2034 2011-11-21 22:55:50 [Tycho] has quit (Read error: Connection reset by peer)
2035 2011-11-21 22:56:52 eueueue has quit (Quit: Saindo)
2036 2011-11-21 22:57:15 stalled has joined
2037 2011-11-21 22:59:41 Nesetalis has joined
2038 2011-11-21 23:02:13 agricocb has quit (Quit: Leaving.)
2039 2011-11-21 23:09:02 BlueMatt has quit (Ping timeout: 240 seconds)
2040 2011-11-21 23:11:52 somuchwin2 has joined
2041 2011-11-21 23:11:55 <gavinandresen> Hmmm, this makes me worried:  "interestingly, it forced me to use not my current password but my previous and original password for the wallet. "  https://bitcointalk.org/index.php?topic=52480.msg626616#msg626616
2042 2011-11-21 23:12:49 somuchwin has quit (Ping timeout: 276 seconds)
2043 2011-11-21 23:14:19 p0s has quit (Remote host closed the connection)
2044 2011-11-21 23:15:30 marf_away has joined
2045 2011-11-21 23:19:22 abragin has quit ()
2046 2011-11-21 23:26:05 MimeNarrator has quit (Remote host closed the connection)
2047 2011-11-21 23:26:51 SG_Test has joined
2048 2011-11-21 23:26:56 ThomasV has quit (Quit: Quitte)
2049 2011-11-21 23:27:41 TD has quit (Ping timeout: 258 seconds)
2050 2011-11-21 23:28:48 SG_Test is now known as [Tycho]
2051 2011-11-21 23:28:58 danbri has quit (Remote host closed the connection)
2052 2011-11-21 23:29:36 BlueMatt has joined
2053 2011-11-21 23:31:51 Kolky has quit (Quit: Bye bye!)
2054 2011-11-21 23:36:34 traviscj has joined
2055 2011-11-21 23:37:20 Diablo-D3 has joined
2056 2011-11-21 23:37:50 T_X has quit (Ping timeout: 240 seconds)
2057 2011-11-21 23:43:39 [Tycho] has quit (Remote host closed the connection)
2058 2011-11-21 23:44:08 OneFixt has quit (Read error: Connection reset by peer)
2059 2011-11-21 23:44:09 AAA_awright has quit (Read error: Connection reset by peer)
2060 2011-11-21 23:44:09 t3a has quit (Read error: Connection reset by peer)
2061 2011-11-21 23:44:09 OneFixt has joined
2062 2011-11-21 23:44:09 t3a_ has joined
2063 2011-11-21 23:44:21 AAA_awright has joined
2064 2011-11-21 23:44:38 OneFixt is now known as Guest11929
2065 2011-11-21 23:45:09 osmosis has joined
2066 2011-11-21 23:46:23 OneFixt_ has joined
2067 2011-11-21 23:46:24 AAA_awright_ has joined
2068 2011-11-21 23:46:35 Guest11929 has quit (Read error: Connection reset by peer)
2069 2011-11-21 23:46:35 AAA_awright has quit (Read error: Connection reset by peer)
2070 2011-11-21 23:46:36 slush has quit (Read error: Connection reset by peer)
2071 2011-11-21 23:46:59 disq has quit (Quit: Disconnecting from stoned server.)
2072 2011-11-21 23:47:17 spq has quit (Read error: Connection reset by peer)
2073 2011-11-21 23:47:20 disq has joined
2074 2011-11-21 23:47:20 disq has quit (Changing host)
2075 2011-11-21 23:47:20 disq has joined
2076 2011-11-21 23:47:46 spq has joined
2077 2011-11-21 23:47:48 slush has joined
2078 2011-11-21 23:48:28 danbri has joined
2079 2011-11-21 23:48:28 Litt has quit (Remote host closed the connection)
2080 2011-11-21 23:48:37 Litt has joined
2081 2011-11-21 23:50:15 eueueue has joined
2082 2011-11-21 23:50:31 agath has quit (Ping timeout: 244 seconds)
2083 2011-11-21 23:51:31 denisx has joined
2084 2011-11-21 23:52:48 agath has joined
2085 2011-11-21 23:54:53 Beremat has joined
2086 2011-11-21 23:55:47 OneFixt__ has joined
2087 2011-11-21 23:58:03 rdponticelli_ has joined
2088 2011-11-21 23:58:24 OneFixt_ has quit (Ping timeout: 248 seconds)
2089 2011-11-21 23:58:41 rdponticelli has quit (Ping timeout: 240 seconds)