1 2012-06-01 00:00:15 codder1 has joined
   2 2012-06-01 00:00:24 <codder1> Hi
   3 2012-06-01 00:00:37 <codder1> Anyone here familliar with bitcoind?
   4 2012-06-01 00:00:49 <BlueMatt> ask a question, dont ask to ask ;)
   5 2012-06-01 00:01:52 wizkid057 has quit (Quit: changing servers)
   6 2012-06-01 00:02:00 <codder1> Ok, I am using bitcoind to accept payments on my site. I would like to know if its possible to get the account address that received the funds
   7 2012-06-01 00:02:15 <codder1> Not the sender's address, but the receiver's address.
   8 2012-06-01 00:02:23 <codder1> Is it possible?
   9 2012-06-01 00:02:24 <sipa> codder1: doesn't listtransactions tell you that?
  10 2012-06-01 00:02:32 <sipa> under "address"
  11 2012-06-01 00:02:49 <codder1> From what I know, it tells the sender's address but not the receiver's address
  12 2012-06-01 00:03:00 <sipa> there is no such thing as a "sender's address" in bitcoin
  13 2012-06-01 00:03:19 <codder1> oh!
  14 2012-06-01 00:03:20 <luke-jr> (rather, bitcoind hides it)
  15 2012-06-01 00:03:48 wizkid057 has joined
  16 2012-06-01 00:03:49 <sipa> luke-jr: there is "optionally, recognizable addresses the input coins were previously sent to"
  17 2012-06-01 00:04:02 <codder1> So I would need to create a loop and check every single address on my site at every single second to see if there is a new transaction?
  18 2012-06-01 00:04:31 <luke-jr> codder1: listtransactions will show all
  19 2012-06-01 00:04:33 <gmaxwell> codder1: no, you create a new payment address for every sale and then you know which one based on which address got paid.
  20 2012-06-01 00:06:28 <codder1> Ok, I am creating a new payment address for every new client on my site. Since its not event based, will need to create a delay loop to check for new payments on all addresses. Assuming I may have over 2000 clients.
  21 2012-06-01 00:06:30 <doublec> you still have to poll though to see if the payment was received
  22 2012-06-01 00:06:58 <codder1> omg, I presume that eats allot of CPU
  23 2012-06-01 00:07:08 <doublec> codder1: you can poll listtransactions
  24 2012-06-01 00:07:13 <doublec> codder1: and look at all new transactions
  25 2012-06-01 00:07:24 <doublec> codder1: and see which ones are for addresses you are execpting payments for
  26 2012-06-01 00:07:36 <doublec> codder1: you could even do this only when a block arrives
  27 2012-06-01 00:07:40 <doublec> codder1: instead of on a timer
  28 2012-06-01 00:07:53 sirk390 has quit (Quit: Leaving.)
  29 2012-06-01 00:07:56 <doublec> codder1: bitcoind has a way of running something when a block arrives iirc
  30 2012-06-01 00:08:59 <doublec> I made the mistake of "poll addresses for payments" in my namecoin exchange. I don't recommend it.
  31 2012-06-01 00:10:13 <luke-jr> codder1: -blocknotify "command"
  32 2012-06-01 00:10:15 <codder1> I am using the NodeJS version. So I assume I can create a delay loop that checks for a new block number, then once it arrives, I simply loop all my addresses for new transactions
  33 2012-06-01 00:10:41 <doublec> codder1: or loop all transactions in that block, looking for payments that belong to you
  34 2012-06-01 00:10:52 <doublec> codder1: that should be more efficient
  35 2012-06-01 00:10:59 <luke-jr> codder1: just use listtransactions to see *all* transactions to you
  36 2012-06-01 00:12:35 <codder1> Ok, I am just finding it crazy to loop 2000 addresses for new transactions at every block. Imagine if it gets to 50 000 users one day!
  37 2012-06-01 00:13:19 <doublec> codder1: using luke-jr or my approach you don't need to
  38 2012-06-01 00:13:33 <doublec> codder1: either one of those only processes the transactions you actually received
  39 2012-06-01 00:13:37 * luke-jr smacks codder1 for not reading
  40 2012-06-01 00:14:09 <doublec> because you are correct, the loop 2000 addresses approach is indeed crazy
  41 2012-06-01 00:14:19 Graet has joined
  42 2012-06-01 00:16:26 <gmaxwell> wow.
  43 2012-06-01 00:16:54 <gmaxwell> codder1: I am impressed by your immunity to assistance.
  44 2012-06-01 00:18:40 <codder1> What if I create a higher bitcoin demmand, I think its not that bad after all.
  45 2012-06-01 00:19:28 <codder1> But thank you very miuch for all your help guys. Once I get the whole concept one day, I will help others all well. I've already introduced plenty of new people ( entrepreneurs ) to this protocol.
  46 2012-06-01 00:20:49 Cryo has quit (Ping timeout: 246 seconds)
  47 2012-06-01 00:21:32 devrandom has quit (Remote host closed the connection)
  48 2012-06-01 00:21:32 MobiusL has quit (Remote host closed the connection)
  49 2012-06-01 00:22:31 devrandom has joined
  50 2012-06-01 00:25:52 d34th has quit (Quit: Leaving)
  51 2012-06-01 00:26:04 d34th has joined
  52 2012-06-01 00:26:04 d34th has quit (Changing host)
  53 2012-06-01 00:26:04 d34th has joined
  54 2012-06-01 00:27:33 d34th has quit (Client Quit)
  55 2012-06-01 00:29:17 d34th has joined
  56 2012-06-01 00:29:18 d34th has quit (Changing host)
  57 2012-06-01 00:29:18 d34th has joined
  58 2012-06-01 00:37:39 <BlueMatt> sipa/gmaxwell: I added an -autoprune to prune during chain download, if you feel like benchmarking...
  59 2012-06-01 00:38:48 <BlueMatt> its not looking terrible, at checkpoint 134444, on tmpfs, with -loadblock, I get pruning taking 7 seconds
  60 2012-06-01 00:39:24 <BlueMatt> anyway...back to cblockstore
  61 2012-06-01 00:41:25 phungi has quit (Quit: leaving)
  62 2012-06-01 00:43:21 random_cat__ has quit (Ping timeout: 276 seconds)
  63 2012-06-01 00:44:15 MobiusL has joined
  64 2012-06-01 00:44:38 danbri has quit (Remote host closed the connection)
  65 2012-06-01 00:45:03 phungus has quit (Remote host closed the connection)
  66 2012-06-01 00:45:19 OneFixt has quit (Ping timeout: 246 seconds)
  67 2012-06-01 00:46:43 p0s is now known as p0s-
  68 2012-06-01 00:46:53 phungi has joined
  69 2012-06-01 00:47:45 phungi_ has joined
  70 2012-06-01 00:48:46 OneFixt has joined
  71 2012-06-01 00:48:54 <Ukto> gmaxwell: does standard bitcoind throw an error when you use RPC send to an address in its own wallet?
  72 2012-06-01 00:49:12 paraipan has quit (Ping timeout: 276 seconds)
  73 2012-06-01 00:49:18 <gmaxwell> No.
  74 2012-06-01 00:49:50 <Ukto> hmm, mine is throwing back an uncaught error from it
  75 2012-06-01 00:49:59 <Ukto> was just gonna work around it, and pre-check before attempting it
  76 2012-06-01 00:50:01 <Ukto> just curious
  77 2012-06-01 00:50:29 darkee has quit (Ping timeout: 276 seconds)
  78 2012-06-01 00:51:26 random_cat__ has joined
  79 2012-06-01 00:55:03 phungi_ has quit (Quit: Reconnecting)
  80 2012-06-01 00:56:27 phungi_ has joined
  81 2012-06-01 01:00:24 ahbritto_ has quit (Remote host closed the connection)
  82 2012-06-01 01:02:13 darkee has joined
  83 2012-06-01 01:03:13 danbri has joined
  84 2012-06-01 01:04:08 danbri has quit (Remote host closed the connection)
  85 2012-06-01 01:04:18 RainbowDashh has joined
  86 2012-06-01 01:07:04 elkingrey has quit (Quit: Leaving)
  87 2012-06-01 01:15:05 d34th has quit (Quit: Leaving)
  88 2012-06-01 01:15:11 paraipan has joined
  89 2012-06-01 01:18:36 D34TH has joined
  90 2012-06-01 01:31:35 balicuzz has joined
  91 2012-06-01 01:33:10 osmosis has quit (Quit: Leaving)
  92 2012-06-01 01:40:57 minimoose has joined
  93 2012-06-01 01:43:11 eoss has quit (Read error: Connection reset by peer)
  94 2012-06-01 01:47:37 agricocb has quit (Ping timeout: 246 seconds)
  95 2012-06-01 01:53:05 balicuzz is now known as stonewalljackson
  96 2012-06-01 01:54:35 Skaag has joined
  97 2012-06-01 01:56:41 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1408 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1408>
  98 2012-06-01 01:58:59 Zarutian has joined
  99 2012-06-01 02:03:08 stonewalljackson has quit ()
 100 2012-06-01 02:04:59 p0s- has quit (Read error: Connection reset by peer)
 101 2012-06-01 02:09:46 andytoshi has joined
 102 2012-06-01 02:13:55 enquirer_ has joined
 103 2012-06-01 02:16:28 enquirer has quit (Ping timeout: 252 seconds)
 104 2012-06-01 02:16:31 enquirer_ is now known as enquirer
 105 2012-06-01 02:16:49 Hasbro has quit (Ping timeout: 245 seconds)
 106 2012-06-01 02:19:43 RainbowDashh has quit (Quit: RainbowDashh)
 107 2012-06-01 02:36:52 RainbowDashh has joined
 108 2012-06-01 02:37:06 MobiusL has quit (Ping timeout: 276 seconds)
 109 2012-06-01 02:37:24 TheSeven has quit (Disconnected by services)
 110 2012-06-01 02:37:32 [7] has joined
 111 2012-06-01 02:38:43 osmosis has joined
 112 2012-06-01 02:57:04 MobiusL has joined
 113 2012-06-01 02:59:25 codder1 has quit (Quit: Page closed)
 114 2012-06-01 03:04:05 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
 115 2012-06-01 03:05:26 Maged has joined
 116 2012-06-01 03:06:44 tower has joined
 117 2012-06-01 03:06:47 tower has quit (Changing host)
 118 2012-06-01 03:06:47 tower has joined
 119 2012-06-01 03:12:58 agricocb has joined
 120 2012-06-01 03:15:45 paraipan has quit (Quit: Saliendo)
 121 2012-06-01 03:17:51 one_zero has joined
 122 2012-06-01 03:20:39 wasabi1 has quit (Read error: Connection reset by peer)
 123 2012-06-01 03:23:30 brwyatt is now known as brwyatt|Away
 124 2012-06-01 03:23:35 brwyatt is now known as Away!~brwyatt@pool-96-226-236-130.dllstx.fios.verizon.net|brwyatt
 125 2012-06-01 03:24:00 da2ce7 has quit (Read error: Connection reset by peer)
 126 2012-06-01 03:24:49 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 127 2012-06-01 03:26:01 da2ce7 has joined
 128 2012-06-01 03:26:16 Guest77323 has joined
 129 2012-06-01 03:26:43 Guest77323 has left ()
 130 2012-06-01 03:27:40 Diablo-D3 has joined
 131 2012-06-01 03:32:17 RainbowDashh has quit (Quit: RainbowDashh)
 132 2012-06-01 03:41:43 Hasbro has joined
 133 2012-06-01 03:44:23 RainbowDashh has joined
 134 2012-06-01 03:45:19 Zarutian has quit (Quit: Zarutian)
 135 2012-06-01 03:48:59 RainbowDashh has quit (Client Quit)
 136 2012-06-01 04:03:00 graingert has quit (Read error: Connection reset by peer)
 137 2012-06-01 04:05:47 minimoose has quit (Quit: minimoose)
 138 2012-06-01 04:15:30 da2ce799 has joined
 139 2012-06-01 04:17:35 da2ce7 has quit (Ping timeout: 252 seconds)
 140 2012-06-01 04:18:22 da2ce799 is now known as da2ce7
 141 2012-06-01 04:19:07 Skaag has quit (Read error: Connection reset by peer)
 142 2012-06-01 04:19:39 Skaag has joined
 143 2012-06-01 04:20:14 RainbowDashh has joined
 144 2012-06-01 04:24:26 da2ce745 has joined
 145 2012-06-01 04:26:03 da2ce7 has quit (Ping timeout: 250 seconds)
 146 2012-06-01 04:27:31 ivan\ has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 147 2012-06-01 04:28:37 ivan\ has joined
 148 2012-06-01 04:33:29 D34TH has quit (Quit: Leaving)
 149 2012-06-01 04:42:18 wladston has quit (Quit: Leaving.)
 150 2012-06-01 04:46:49 RainbowDashh has quit (Quit: RainbowDashh)
 151 2012-06-01 04:46:51 Hasbro has quit (Ping timeout: 250 seconds)
 152 2012-06-01 05:00:41 maqr has quit (Ping timeout: 245 seconds)
 153 2012-06-01 05:04:55 mmoya has joined
 154 2012-06-01 05:05:46 RainbowDashh has joined
 155 2012-06-01 05:13:46 ThomasV has joined
 156 2012-06-01 05:19:10 danbri has joined
 157 2012-06-01 05:20:32 danbri has quit (Read error: Connection reset by peer)
 158 2012-06-01 05:20:36 Joric has quit ()
 159 2012-06-01 05:20:47 danbri has joined
 160 2012-06-01 05:23:19 Maged has quit (Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120420145725])
 161 2012-06-01 05:25:56 danbri_ has joined
 162 2012-06-01 05:26:01 danbri has quit (Read error: Connection reset by peer)
 163 2012-06-01 05:27:40 brwyatt is now known as brwyatt|Away
 164 2012-06-01 05:28:11 danbri has joined
 165 2012-06-01 05:28:34 danbri_ has quit (Read error: Connection reset by peer)
 166 2012-06-01 05:32:23 danbri has quit (Remote host closed the connection)
 167 2012-06-01 05:38:54 danbri has joined
 168 2012-06-01 05:46:42 sytse has quit (Ping timeout: 272 seconds)
 169 2012-06-01 05:47:01 sytse has joined
 170 2012-06-01 05:53:27 da2ce745 is now known as da2ce7
 171 2012-06-01 05:54:39 danbri has quit (Read error: Connection reset by peer)
 172 2012-06-01 05:55:01 danbri has joined
 173 2012-06-01 05:57:30 danbri has quit (Read error: Connection reset by peer)
 174 2012-06-01 05:57:37 danbri has joined
 175 2012-06-01 05:57:53 danbri has quit (Remote host closed the connection)
 176 2012-06-01 06:02:04 TimothyA has quit (Read error: Connection reset by peer)
 177 2012-06-01 06:21:35 dvide has joined
 178 2012-06-01 06:24:25 t7 has joined
 179 2012-06-01 06:25:20 wizkid057 has quit (Ping timeout: 272 seconds)
 180 2012-06-01 06:28:31 Snapman[afkers] is now known as Snapman
 181 2012-06-01 06:29:37 t7_ has joined
 182 2012-06-01 06:31:07 t7 has quit (Ping timeout: 246 seconds)
 183 2012-06-01 06:31:11 t7_ is now known as t7
 184 2012-06-01 06:34:41 Bigpiggy01Mining is now known as NeedzTweezerstoF
 185 2012-06-01 06:36:11 ThomasV has quit (Ping timeout: 252 seconds)
 186 2012-06-01 06:42:53 chrisb__ has joined
 187 2012-06-01 06:44:11 ThomasV has joined
 188 2012-06-01 06:44:25 maqr has joined
 189 2012-06-01 06:46:30 ovidiusoft has joined
 190 2012-06-01 06:47:56 RainbowDashh has quit (Quit: RainbowDashh)
 191 2012-06-01 06:49:46 RainbowDashh has joined
 192 2012-06-01 06:50:32 <gmaxwell> The drm in this is an astonishing waste of effort, http://www.tricone-mining.com/faq.html
 193 2012-06-01 06:50:40 <gmaxwell> It makes me sad.
 194 2012-06-01 06:51:31 ThomasV has quit (Ping timeout: 245 seconds)
 195 2012-06-01 06:51:36 Joric has joined
 196 2012-06-01 06:51:38 <gmaxwell> I'm glad its not bad for bitcoin like some other crazy things people have floated in relation to mining hardware. but geesh.
 197 2012-06-01 06:51:44 Joric has quit (Changing host)
 198 2012-06-01 06:51:44 Joric has joined
 199 2012-06-01 06:52:47 JZavala has quit (Ping timeout: 244 seconds)
 200 2012-06-01 06:54:26 RainbowDashh has quit (Ping timeout: 245 seconds)
 201 2012-06-01 06:54:31 RainbowDashh has joined
 202 2012-06-01 07:01:23 <JFK911> t l d r looks like a scam to me
 203 2012-06-01 07:05:18 <Diablo-D3> JFK911: its not
 204 2012-06-01 07:05:30 <Diablo-D3> he gives you the miner and the bitstream for free
 205 2012-06-01 07:05:44 <Diablo-D3> all it does is shaves a little off the top
 206 2012-06-01 07:05:46 osmosis has quit (Ping timeout: 252 seconds)
 207 2012-06-01 07:06:20 <JFK911> see if he reduced that to "get free miner and get 80% of the btc" that is 9 words
 208 2012-06-01 07:06:34 <weex> it's 20%?
 209 2012-06-01 07:06:44 <JFK911> i didn't read through all the babble to find out
 210 2012-06-01 07:06:51 <JFK911> i saw "signcrypted" and hit the x
 211 2012-06-01 07:07:08 <Diablo-D3> 20%? no.
 212 2012-06-01 07:07:18 <Diablo-D3> whatever 270/258 is
 213 2012-06-01 07:07:27 <Diablo-D3> 5%?
 214 2012-06-01 07:07:28 <Diablo-D3> w/e
 215 2012-06-01 07:07:37 <Diablo-D3> JFK911: heres the big part
 216 2012-06-01 07:07:40 <JFK911> 258/270 is 95%
 217 2012-06-01 07:07:43 RainbowDashh has quit (Quit: RainbowDashh)
 218 2012-06-01 07:07:48 <Diablo-D3> I can take his miner
 219 2012-06-01 07:07:53 <Diablo-D3> and hack it to not send him the 5%.
 220 2012-06-01 07:08:09 <Diablo-D3> so I get 270 mh on a chip that does 200.
 221 2012-06-01 07:08:24 <JFK911> i think i could take his miner and properly power it and load my own code onto it
 222 2012-06-01 07:08:34 Joric has quit (Ping timeout: 246 seconds)
 223 2012-06-01 07:08:36 Joric_ has joined
 224 2012-06-01 07:09:42 <Diablo-D3> power what?
 225 2012-06-01 07:09:46 <Diablo-D3> its a piece of software.
 226 2012-06-01 07:10:03 <JFK911> Xilinx's tools predict that it should achieve 315MH/s; however we have not yet encountered a board that can supply enough power to reach this figure. Typical performance is 270MH/s per chip.
 227 2012-06-01 07:10:16 <JFK911> thats like one of three sentences i read
 228 2012-06-01 07:10:22 RainbowDashh has joined
 229 2012-06-01 07:11:44 phantomcircuit has quit (Read error: Connection reset by peer)
 230 2012-06-01 07:12:38 <Diablo-D3> xilinix's tools are full of shit
 231 2012-06-01 07:12:47 <Diablo-D3> it predicted like 250 on the existing streams
 232 2012-06-01 07:13:50 <Diablo-D3> OH MAN
 233 2012-06-01 07:13:56 <Diablo-D3> Is this like Butterfly Labs' \u201cBuyback Guarantee\u201d?
 234 2012-06-01 07:13:56 <Diablo-D3> Butterwho?
 235 2012-06-01 07:14:02 * Diablo-D3 does victory dance
 236 2012-06-01 07:16:09 molecular has quit (Ping timeout: 252 seconds)
 237 2012-06-01 07:17:18 molecular has joined
 238 2012-06-01 07:18:06 <JFK911> ive found logic simulations to be timing-accurate
 239 2012-06-01 07:18:26 <JFK911> of course i havent tried xilinx
 240 2012-06-01 07:19:16 <JFK911> but i have aldec's simulator
 241 2012-06-01 07:26:52 <Diablo-D3> stil
 242 2012-06-01 07:26:58 <Diablo-D3> it all depends what BFL does now
 243 2012-06-01 07:27:42 <Diablo-D3> because 270 mh is like
 244 2012-06-01 07:27:49 <Diablo-D3> where did I put that chart
 245 2012-06-01 07:29:54 <Diablo-D3> okay so
 246 2012-06-01 07:30:30 <Diablo-D3> okay lets say cairnsmore1s sell for $1000 at full price
 247 2012-06-01 07:30:38 <Diablo-D3> since the $640 was just a pre-order price and thats gone
 248 2012-06-01 07:30:53 <Diablo-D3> thats 1080 mhash for 4 spartan 6s
 249 2012-06-01 07:31:34 <Diablo-D3> thats $1/mh on both a cairnsmore1 and a lancelot (2 spartan 6 for $500)
 250 2012-06-01 07:32:03 <Diablo-D3> err
 251 2012-06-01 07:32:05 <Diablo-D3> 1 mh/$
 252 2012-06-01 07:32:11 <Diablo-D3> and 28nm could beat 2 mh/$
 253 2012-06-01 07:44:45 setkeh has quit (Ping timeout: 245 seconds)
 254 2012-06-01 07:45:12 setkeh has joined
 255 2012-06-01 07:50:53 pjorrit has quit (Remote host closed the connection)
 256 2012-06-01 07:54:46 erle- has joined
 257 2012-06-01 07:55:54 spaola has joined
 258 2012-06-01 07:58:35 pierre` has quit (Ping timeout: 248 seconds)
 259 2012-06-01 08:00:02 wizkid057 has joined
 260 2012-06-01 08:00:35 <MC1984> you guys added a blocks remaining thing in the progress bar, nice
 261 2012-06-01 08:00:47 <MC1984> the text should probably be black though
 262 2012-06-01 08:00:56 <MC1984> white on neon green is a bit hard
 263 2012-06-01 08:01:15 <Diablo-D3> MC1984: no
 264 2012-06-01 08:01:18 <Diablo-D3> thats the qt theme
 265 2012-06-01 08:01:19 <Diablo-D3> change yours.
 266 2012-06-01 08:01:27 <Diablo-D3> mine is happily white on dark blue.
 267 2012-06-01 08:01:39 <MC1984> what
 268 2012-06-01 08:01:53 <Diablo-D3> dont what me.
 269 2012-06-01 08:01:55 <weex> Diablo-D3: people have to change their qt theme?
 270 2012-06-01 08:02:04 <Diablo-D3> weex: normally you do.
 271 2012-06-01 08:02:11 <Diablo-D3> so it blends in with the rest of your desktop
 272 2012-06-01 08:02:16 <MC1984> since when does bitcoin client have themes lol
 273 2012-06-01 08:02:19 <Diablo-D3> unless you already run KDE, then its the same theme
 274 2012-06-01 08:02:21 <Diablo-D3> MC1984: qt.
 275 2012-06-01 08:02:39 <weex> MC1984: you on gnu/linux?
 276 2012-06-01 08:02:44 <MC1984> what the blazez are you on about man
 277 2012-06-01 08:02:51 <Diablo-D3> =|
 278 2012-06-01 08:03:23 <MC1984> im using windows
 279 2012-06-01 08:03:27 <Diablo-D3> oh
 280 2012-06-01 08:03:33 <Diablo-D3> then quit using windows
 281 2012-06-01 08:03:37 <Diablo-D3> because no one gives a fuck about windows.
 282 2012-06-01 08:03:49 <MC1984> lol
 283 2012-06-01 08:04:34 <neofutur> +1 for "quit using windows"
 284 2012-06-01 08:04:46 <neofutur> will be easier to help yourself :p
 285 2012-06-01 08:05:20 <MC1984> il get round to it one day, but for my own reasons not because some software snob prick on the internet told me to
 286 2012-06-01 08:05:38 <MC1984> untill then, this shit is white on lime green
 287 2012-06-01 08:06:27 <Diablo-D3> yes, because windows is lime green
 288 2012-06-01 08:06:35 <Diablo-D3> why the fuck did microsoft ever do that
 289 2012-06-01 08:06:37 <Diablo-D3> that was nuts
 290 2012-06-01 08:06:45 <Diablo-D3> and the fucking fisher price window controls
 291 2012-06-01 08:06:49 <Diablo-D3> WHY DID THEY DO THIS
 292 2012-06-01 08:07:16 <MC1984> cos it used to be grey and marketing dept wanted something cool
 293 2012-06-01 08:07:24 <Diablo-D3> LIME GREEN ISNT COOL
 294 2012-06-01 08:07:31 <Diablo-D3> btw, what windows theme are you using?
 295 2012-06-01 08:07:41 <Diablo-D3> because if you set it to windows classic, I think QT is smart enough to copy the colors
 296 2012-06-01 08:07:58 <MC1984> noir
 297 2012-06-01 08:08:07 <Diablo-D3> er, which one is that?
 298 2012-06-01 08:08:15 <MC1984> the leaked one
 299 2012-06-01 08:08:18 <Diablo-D3> because I only know of the fisher price one, the silver one, and the widows classic one
 300 2012-06-01 08:08:29 <Diablo-D3> oh, and aero
 301 2012-06-01 08:08:44 <Diablo-D3> aero went back to windows blue on that shit I think
 302 2012-06-01 08:09:32 <MC1984> this text has turned black now wtf
 303 2012-06-01 08:10:45 <Diablo-D3> pray bitcoin doesn't alter it any further
 304 2012-06-01 08:11:16 Xunie has quit (Remote host closed the connection)
 305 2012-06-01 08:12:41 <MC1984> gone bak to white now
 306 2012-06-01 08:12:47 <MC1984> dafuq
 307 2012-06-01 08:13:21 <MC1984> oh it turns blak when the window is unfocused
 308 2012-06-01 08:13:24 <MC1984> interdasting
 309 2012-06-01 08:16:08 sirk390 has joined
 310 2012-06-01 08:17:25 <MC1984> bitcoin is not multi threaded rigth
 311 2012-06-01 08:17:38 <Diablo-D3> not in the UI code
 312 2012-06-01 08:17:49 <Diablo-D3> you're looking at QT weirdness
 313 2012-06-01 08:18:16 <MC1984> im trying to work out why hain download is still so shit and how much room for optimization there is there
 314 2012-06-01 08:18:29 <Diablo-D3> you're on 0.6.2 arent you?
 315 2012-06-01 08:18:39 <MC1984> i am now
 316 2012-06-01 08:19:31 <Diablo-D3> its much faster than it was
 317 2012-06-01 08:20:57 <MC1984> avg 1 blok per 5 seconds here
 318 2012-06-01 08:22:05 <MC1984> i still pray there are perhaps massive database structure efficiency gains to be made at some point
 319 2012-06-01 08:22:09 <MC1984> or something
 320 2012-06-01 08:22:43 <MC1984> as if i have a clue what im talking about
 321 2012-06-01 08:22:49 <Diablo-D3> there is
 322 2012-06-01 08:22:54 <Diablo-D3> gmaxwell and sipa have been working on it
 323 2012-06-01 08:23:11 <MC1984> cool
 324 2012-06-01 08:23:30 <MC1984> hopefully that an trim the size of the stored blockchain too maybe
 325 2012-06-01 08:24:09 <MC1984> the speedups so far seem non existent on slightly older hardware from what ive seen and read
 326 2012-06-01 08:24:37 <MC1984> which consigns a lot of people to thin clients only really, certainly anyone outside the west prob
 327 2012-06-01 08:30:49 SomeoneWeird has quit (Ping timeout: 246 seconds)
 328 2012-06-01 08:31:10 MrTiggr has quit (Ping timeout: 246 seconds)
 329 2012-06-01 08:31:22 JZavala has joined
 330 2012-06-01 08:32:23 RazielZ has joined
 331 2012-06-01 08:34:33 MrTiggr has joined
 332 2012-06-01 08:36:33 Guest68995 has joined
 333 2012-06-01 08:38:21 <MC1984> wait is blockchain download and indexing etc limited by ram
 334 2012-06-01 08:38:46 chrisb__ has quit (Quit: Leaving)
 335 2012-06-01 08:40:26 Joric_ has quit ()
 336 2012-06-01 08:45:38 <Eliel> MC1984: I was thinking the other day that instead of just seeking and reading the transaction data as needed, it could be done in batches. First reading the index for a large number of transactions, sorting out the data you need to read and then sorting those to disk order and then reading them all in one go.
 337 2012-06-01 08:53:40 hnz_ has joined
 338 2012-06-01 08:56:03 <MC1984> ok so
 339 2012-06-01 08:56:44 <MC1984> currently txns propagate aroudn the whole network much faster than the time to first confirm them in a block
 340 2012-06-01 08:57:07 <MC1984> but they are only considered secure after 1+ blocks preferrably more
 341 2012-06-01 08:57:10 JZavala has quit (Ping timeout: 260 seconds)
 342 2012-06-01 08:57:30 hnz has quit (Ping timeout: 256 seconds)
 343 2012-06-01 08:58:07 <weex> MC1984: each block adds to the probably amount of work required to double-spend
 344 2012-06-01 08:58:14 <weex> probable*
 345 2012-06-01 08:58:28 <MC1984> would it be possible for a node to mitigate double spends in that 10 minute window by comparing the txns its making/receiving to what its hearing on the network right now?
 346 2012-06-01 08:58:58 <MC1984> like a cursory double spend check until the first conf comes in
 347 2012-06-01 08:59:02 <weex> yes, this is called the observer method
 348 2012-06-01 08:59:20 <MC1984> is it a good idea
 349 2012-06-01 08:59:21 <Diablo-D3> https://bitcointalk.org/index.php?topic=83985.msg934569#msg934569
 350 2012-06-01 09:00:17 mmoya has quit (Ping timeout: 265 seconds)
 351 2012-06-01 09:00:37 <MC1984> what
 352 2012-06-01 09:00:54 <weex> again with the whats
 353 2012-06-01 09:01:33 mmoya has joined
 354 2012-06-01 09:02:09 <Diablo-D3> goddamnit, I read what weex said in the new york jew voice
 355 2012-06-01 09:02:35 <MC1984> i am astounded of your seeminly arbitrary interjection good sir, pray you elucidate the meaning of this hypertextual link?
 356 2012-06-01 09:02:56 <weex> Diablo-D3: fuggedaboutit
 357 2012-06-01 09:03:08 <Diablo-D3> weex: organized crime voice.
 358 2012-06-01 09:03:30 <Diablo-D3> MC1984: less than 50w bfl single 2.0
 359 2012-06-01 09:03:47 <MC1984> is that good
 360 2012-06-01 09:05:26 <Diablo-D3> yes
 361 2012-06-01 09:05:33 <Diablo-D3> I like the single design, but 80w is just too much
 362 2012-06-01 09:06:45 <MC1984> you can passive cool 50w
 363 2012-06-01 09:07:13 <MC1984> needs design better than a cube tho
 364 2012-06-01 09:07:38 <weex> that's just its gorgeous exterior
 365 2012-06-01 09:08:05 <weex> inside i think it's mainly electrical tape and resistors
 366 2012-06-01 09:08:17 <Diablo-D3> weex: erm, they've took photos of the inside
 367 2012-06-01 09:08:32 <Diablo-D3> its a rather plain high density circuit board
 368 2012-06-01 09:08:51 <Diablo-D3> high density as in what video cards and the parts of mobos around the cpu look like
 369 2012-06-01 09:09:06 <Diablo-D3> MC1984: 80w you cant reliably passive cool, and 50 is, eh, too high
 370 2012-06-01 09:09:18 <Diablo-D3> 25 or 33 could do it with a large enough copper heatsink
 371 2012-06-01 09:09:42 hnz_ is now known as hnz
 372 2012-06-01 09:13:36 <MC1984> ok so the thing i said
 373 2012-06-01 09:13:44 <MC1984> i assume someone thought of it before
 374 2012-06-01 09:15:08 <MC1984> seemslike a good idea to me, for instantly securing small txn up to a certain risk threshold
 375 2012-06-01 09:15:19 <MC1984> POS in shops maybe
 376 2012-06-01 09:15:42 <MC1984> if youre buying a car you can wait an hour for the deal to become airtight
 377 2012-06-01 09:16:30 <Diablo-D3> erm
 378 2012-06-01 09:16:37 <Diablo-D3> didnt someone already start working on that?
 379 2012-06-01 09:16:39 <Diablo-D3> MC1984: btw
 380 2012-06-01 09:16:46 <Diablo-D3> bitcoin isnt meant to replace day to day credit card shit
 381 2012-06-01 09:16:57 <Diablo-D3> its meant to replace fedwire and online ordering both
 382 2012-06-01 09:17:20 <MC1984> well thats a shame
 383 2012-06-01 09:17:49 <sipa> for instant payments you want a third-party payment processor on top of bitcoin
 384 2012-06-01 09:17:54 <Diablo-D3> yeah what sipa said
 385 2012-06-01 09:18:01 <Diablo-D3> you need to centralize transaction management
 386 2012-06-01 09:18:09 <Diablo-D3> transactions as in database transactions, not money transactions
 387 2012-06-01 09:18:12 <MC1984> cool added cost
 388 2012-06-01 09:18:43 <sipa> thankfully, because of bitcoin's inherent digital design, setting up such a processor should be trivial compared to setting up paypal
 389 2012-06-01 09:18:47 <Diablo-D3> I could easily do 5 million transactions a second on a single shit computer
 390 2012-06-01 09:19:00 <Diablo-D3> I just cant write them to disk fast enough.
 391 2012-06-01 09:19:15 <MC1984> but why if you dont need to
 392 2012-06-01 09:19:27 <Diablo-D3> MC1984: well I have to account for things
 393 2012-06-01 09:19:49 <Diablo-D3> although maybe a future bitcoin transaction processor will use Lugh
 394 2012-06-01 09:19:57 <Diablo-D3> (my highly parallel C library)
 395 2012-06-01 09:19:59 <MC1984> wouldnt the thing i described provide a seller with a resonable confidence of not getting double spent for a given risk level
 396 2012-06-01 09:20:10 <MC1984> normal everyday purchasing shit risk level
 397 2012-06-01 09:20:14 <Diablo-D3> MC1984: it must be accountable.
 398 2012-06-01 09:20:30 PiZZaMaN2K has quit (Ping timeout: 260 seconds)
 399 2012-06-01 09:20:47 <MC1984> how would it not be accountable
 400 2012-06-01 09:20:58 <Diablo-D3> joe shmoe needs to pay with instantdick and then immediately be able to whip out his cell phone and see the new transaction on instantdick
 401 2012-06-01 09:21:07 <Diablo-D3> the transactions must be recorded.
 402 2012-06-01 09:21:56 <MC1984> its just bitcoin with an extra good enough up to x risk level double pend preventer thing
 403 2012-06-01 09:22:04 <Diablo-D3> nope, its not.
 404 2012-06-01 09:22:12 <Diablo-D3> you have not properly conceptualized the problem.
 405 2012-06-01 09:23:02 <MC1984> the problem is not getting double spent on upto maybe $100 of value or whatever
 406 2012-06-01 09:23:10 <MC1984> and not having to wait 10 mins
 407 2012-06-01 09:23:44 <Diablo-D3> not quite.
 408 2012-06-01 09:23:54 <Diablo-D3> you'd have a reloadable bitcard.
 409 2012-06-01 09:23:59 <MC1984> just a bitcoind that keeps an ear out for double spends as they come over the wire and calls shenanigans if it sees one, not a complex thing
 410 2012-06-01 09:24:34 <sipa> MC1984: i think you want to hide that behind a third party as well
 411 2012-06-01 09:24:35 PiZZaMaN2K has joined
 412 2012-06-01 09:24:50 <MC1984> lemme guess a trusted third party
 413 2012-06-01 09:25:27 <Diablo-D3> yes.
 414 2012-06-01 09:25:31 <Diablo-D3> trust isnt an issue for small amounts
 415 2012-06-01 09:25:37 <sipa> as a merchant you have a deal with a transaction processor; customers send transactions to transaction processor (but transactions to your address; they can't go run away with your money)
 416 2012-06-01 09:26:00 <Diablo-D3> bitcoin is optimized for large transactions, not small ones
 417 2012-06-01 09:26:06 <sipa> you pay the processor a small fee, and in return they insure you against double spends
 418 2012-06-01 09:26:24 <sipa> they do this by for small transactions just not caring
 419 2012-06-01 09:26:24 <MC1984> insurance = added cost
 420 2012-06-01 09:26:27 <sipa> of course
 421 2012-06-01 09:26:30 <sipa> nothing is free
 422 2012-06-01 09:27:00 <MC1984> you guy are talking about something completely different to me
 423 2012-06-01 09:27:17 <Diablo-D3> MC1984: you fail at basic computer science
 424 2012-06-01 09:27:22 pierre` has joined
 425 2012-06-01 09:27:36 <sipa> and for large transactions, they probe for double spends for a short time, before confirming the transaction
 426 2012-06-01 09:27:59 <Diablo-D3> parallel, transactionally safe, or fast. pick two _on a good day_.
 427 2012-06-01 09:28:20 <MC1984> you fail at understanding
 428 2012-06-01 09:28:29 <MC1984> small txn just have to be safe enough
 429 2012-06-01 09:28:32 <MC1984> not total safe
 430 2012-06-01 09:28:48 <MC1984> no payment system is 100% secure
 431 2012-06-01 09:28:50 <sipa> indeed, bitcoin is already far more safe for a merchant than credit cards
 432 2012-06-01 09:28:58 <weex> MC1984: so you have to quantify the risk
 433 2012-06-01 09:29:04 <Diablo-D3> MC1984: no, you're trying to describe the starbucks system
 434 2012-06-01 09:29:14 <Diablo-D3> a few mistakes here and there doesnt cost anything overall
 435 2012-06-01 09:29:47 <Diablo-D3> the payment and product-in-a-cup delivery system are async.
 436 2012-06-01 09:30:07 <MC1984> what the shit are you on about seriously
 437 2012-06-01 09:30:09 <Diablo-D3> problem is bitcoin is NOT a POS payment system and never will be
 438 2012-06-01 09:30:21 <Diablo-D3> MC1984: are you fucking kidding me?
 439 2012-06-01 09:30:48 <Diablo-D3> Googler, motherfucker, do you use it.
 440 2012-06-01 09:30:57 <sipa> please
 441 2012-06-01 09:31:05 <MC1984> yeah everyone seems to have given up and resorted to trusted parties and insurance and god damn bitcoin credit cards
 442 2012-06-01 09:31:16 <Diablo-D3> sipa: you explain this to him, I give up
 443 2012-06-01 09:31:21 <sipa> MC1984: depends what time-fram you're looking at
 444 2012-06-01 09:31:42 <MC1984> POS time frame
 445 2012-06-01 09:31:49 <weex> and what level of risk you're willing to accept
 446 2012-06-01 09:31:53 <MC1984> with acceptable risk of not getting diked on as a merchant
 447 2012-06-01 09:31:55 <Diablo-D3> POS time frame is not the best term
 448 2012-06-01 09:32:02 <Diablo-D3> not all POS systems use the same time frame
 449 2012-06-01 09:32:03 <sipa> but what bitcoin provides imho, is the ability to be completely responsible for your own money, without trusting anyway
 450 2012-06-01 09:32:15 <sipa> that does not mean it can be used for any financial transaction
 451 2012-06-01 09:32:20 <sipa> or that it is free
 452 2012-06-01 09:32:20 <MC1984> say 30 seconds max then
 453 2012-06-01 09:32:26 <Diablo-D3> 30 seconds is very high
 454 2012-06-01 09:32:29 <Diablo-D3> for some.
 455 2012-06-01 09:32:30 <weex> i think mcdonalds has it down to 3 seconds with amex
 456 2012-06-01 09:32:33 <Diablo-D3> for others, thats very low.
 457 2012-06-01 09:32:35 <weex> or 2
 458 2012-06-01 09:32:39 <Diablo-D3> weex: heh
 459 2012-06-01 09:32:43 <Diablo-D3> mcdonalds runs its own processing system
 460 2012-06-01 09:33:05 <weex> of course but they had to reach out to get that speed
 461 2012-06-01 09:33:09 <Diablo-D3> 3 seconds actually sounds high for them
 462 2012-06-01 09:33:17 <sipa> it could well be milliseconds for small transactions, if you calculate the risk for double spending or otherwise failed transactions in, with bitcoin
 463 2012-06-01 09:33:20 <Diablo-D3> walmart is down to like zero.
 464 2012-06-01 09:33:22 <Diablo-D3> I shit you not
 465 2012-06-01 09:33:28 <Diablo-D3> they OWN their own transaction processing network
 466 2012-06-01 09:33:41 <Diablo-D3> theres only one other merchant that does, and thats amazon (which built theirs from the ground up due to their unique needs)
 467 2012-06-01 09:33:49 <MC1984> all i said
 468 2012-06-01 09:34:01 <weex> either way, they must have a copy of at least part of amex db
 469 2012-06-01 09:34:05 <Diablo-D3> mcd and starbucks both built systems for high speed transaction processing, but still meter it out to backends
 470 2012-06-01 09:34:27 <MC1984> was a small addition to bitcoind that would flag and deny double spends as they com in over the wire which would probably always be seconds worldwide max
 471 2012-06-01 09:34:42 <MC1984> instead of waiting for first confm before calling bullshit
 472 2012-06-01 09:34:47 <Diablo-D3> MC1984: except you're doing it wrong.
 473 2012-06-01 09:35:12 <MC1984> that MAY make the risk acceptable to perform direct instant bitcoin sales on smallish value items
 474 2012-06-01 09:35:25 <MC1984> thats all i said
 475 2012-06-01 09:35:27 <Diablo-D3> starbucks already solved the problem
 476 2012-06-01 09:35:28 <Diablo-D3> years ago
 477 2012-06-01 09:35:38 <Diablo-D3> go do your research before spouting you have a new idea.
 478 2012-06-01 09:35:55 <MC1984> what the dicks has this got to do with starbucks
 479 2012-06-01 09:36:08 <weex> MC1984: i think Diablo-D3's trying to say use the best tool for the job
 480 2012-06-01 09:36:30 <MC1984> the 'best' tool is visa.....
 481 2012-06-01 09:36:35 <weex> of course people will build tech on top of bitcoin that will speed it up
 482 2012-06-01 09:36:38 <weex> lower risk
 483 2012-06-01 09:37:01 <MC1984> thats just what i proposed
 484 2012-06-01 09:37:11 <Diablo-D3> MC1984: _starbucks already built a high speed transaction system that takes into account acceptable risk_
 485 2012-06-01 09:37:13 <weex> but eventually they may hit a wall and decide, fuck it, i'm doing my own centralized system
 486 2012-06-01 09:37:25 <Diablo-D3> _they already solved the problem and increased sales several million a year_
 487 2012-06-01 09:37:45 Guest68995 has quit (Changing host)
 488 2012-06-01 09:37:45 Guest68995 has joined
 489 2012-06-01 09:37:45 <MC1984> people would be free to make thier own payment sytem ontop of bitcoin
 490 2012-06-01 09:37:48 <Diablo-D3> weex: well, bitcoin is the fedwire of the bitcoin network.
 491 2012-06-01 09:37:57 <Diablo-D3> weex: its designed to be built on top of.
 492 2012-06-01 09:37:58 Guest68995 is now known as SomeoneWeird
 493 2012-06-01 09:38:16 <MC1984> but perhaps with a few tweaks regular bitcoind might be good enough for smallish merchants who can afford that to deal direct in bitcoin
 494 2012-06-01 09:38:23 <sipa> i doubt it is designed for that - satoshi had plans for advertizing/selling goods directly inside the p2p protocol
 495 2012-06-01 09:38:31 <sipa> but i think it's an inevitable evolution
 496 2012-06-01 09:38:32 <Diablo-D3> MC1984: no, no merchant wants to accept money themselves
 497 2012-06-01 09:38:49 <Diablo-D3> sipa: he had plans to extend the system, thus building on top of what we had
 498 2012-06-01 09:39:08 <weex> i like the idea of being able to easily setup a listener network of say 5 machines
 499 2012-06-01 09:39:10 <Diablo-D3> what he would have proposed is bad engineering
 500 2012-06-01 09:39:10 <sipa> right, but i fundamentally disagree with the idea that that belongs in the bitcoin protocol :)
 501 2012-06-01 09:39:18 <MC1984> he didnt have plans to cloister the network away
 502 2012-06-01 09:39:19 <weex> when 4 of 5 see the incoming txn i'm good
 503 2012-06-01 09:39:21 <Diablo-D3> sipa: exactly
 504 2012-06-01 09:39:27 <Diablo-D3> unix engineering always works
 505 2012-06-01 09:39:46 <weex> right now, it's hard to keep 5 bitcoind's in sync watching for the same txns
 506 2012-06-01 09:40:08 <MC1984> can people not see the value in atleast trying to keep the edge of the network as close to the actual commerce as possible
 507 2012-06-01 09:40:26 <MC1984> my idea might be able to make it actually touch the commernce in many more cases
 508 2012-06-01 09:40:27 <MC1984> maybe
 509 2012-06-01 09:41:04 <weex> MC1984: at a certain point it's about code, i'd like for you to develop the code to make your idea happen
 510 2012-06-01 09:41:35 <MC1984> you have shit like gambling sites totally eating the risk of 1BTC instant confirm right now so you can gamble straight away
 511 2012-06-01 09:41:55 <sipa> MC1984: are you talking about satoshidice?
 512 2012-06-01 09:42:18 <MC1984> with a bit of extra logic that risk eating threshold could rise and thus be more useful
 513 2012-06-01 09:42:28 <MC1984> what is satoshidice
 514 2012-06-01 09:42:37 <sipa> nvm then
 515 2012-06-01 09:43:02 <sipa> because satoshidice does not take the instant confirm risk - their payouts use your inputs, so if you double spend them, your payout becomes invalid as well
 516 2012-06-01 09:43:41 <weex> sipa: how do they specify the input to be coins from a specific transaction?
 517 2012-06-01 09:44:34 <kinlo> by not using the bitcoin software I guess, the official client still needs a lot of work :/
 518 2012-06-01 09:44:40 <MC1984> well, any service that eats instant risk on a small amount, could eat instant risk on larger amounts with some sort of propagation speed double spend flagging patch like i seem to be proposing
 519 2012-06-01 09:44:43 <sipa> weex: they use a heavily modified bitcoinj
 520 2012-06-01 09:44:54 <MC1984> if i could code id have a go myself
 521 2012-06-01 09:44:58 paraipan has joined
 522 2012-06-01 09:45:24 <MC1984> end result you can get better cheaper services @ the equivalent risk level i think
 523 2012-06-01 09:45:26 <sipa> MC1984: i seem to have missed your original proposal - what exactly do you want to have added?
 524 2012-06-01 09:45:57 <sipa> i disagree that it will make merchants want to interact directly with the blockchain, but that doesn't mean it's not useful for others
 525 2012-06-01 09:46:28 <MC1984> bitcoind checks txns as they come in the wire aganst the ones its making, instead of only flagging double spends on the next block
 526 2012-06-01 09:46:40 <MC1984> thats my idea in a sentence
 527 2012-06-01 09:46:51 <sipa> there is no such thing as "flagging double spends"
 528 2012-06-01 09:47:04 <sipa> from the point of view from the blockchain, no double spend exists
 529 2012-06-01 09:47:23 <MC1984> this is nothing to do with the blockchain
 530 2012-06-01 09:47:32 <sipa> well you're talking about blocks
 531 2012-06-01 09:47:41 <MC1984> no im not
 532 2012-06-01 09:47:51 <MC1984> raw txns on the wire
 533 2012-06-01 09:47:54 <sipa> "instead of only flagging double spends on the next block"
 534 2012-06-01 09:47:56 <sipa> <- block
 535 2012-06-01 09:48:05 <MC1984> ffs
 536 2012-06-01 09:48:13 <MC1984> thats the counterexample
 537 2012-06-01 09:48:19 <sipa> sorry, i'm not following
 538 2012-06-01 09:48:29 <weex> MC1984: bitcoind doesn't accept transactions that would be a double-spend
 539 2012-06-01 09:48:34 <weex> but it only knows which one it saw first
 540 2012-06-01 09:48:41 <weex> so it's a race across the network
 541 2012-06-01 09:48:52 <MC1984> guys you are seriously not getting this
 542 2012-06-01 09:48:57 <MC1984> aosu;gdnaWKDUJHVns{oa@LVN'A BMDZ#F
 543 2012-06-01 09:48:58 <sipa> i'm not, no
 544 2012-06-01 09:49:16 <MC1984> the one it saw first is the one it made
 545 2012-06-01 09:49:23 <sipa> yes
 546 2012-06-01 09:49:35 <MC1984> anything coming on the wire after that witht he same inputs is suspicious
 547 2012-06-01 09:49:41 <MC1984> before blocks are made
 548 2012-06-01 09:49:44 <MC1984> just raw txn
 549 2012-06-01 09:49:55 <sipa> sure, but it will not see anything in most cases, as it doesn't get forwarded
 550 2012-06-01 09:50:00 <sipa> but yes, that is suspicious
 551 2012-06-01 09:50:09 <MC1984> yes
 552 2012-06-01 09:50:17 <sipa> so, what do you propose to do with it?
 553 2012-06-01 09:50:31 <MC1984> deny
 554 2012-06-01 09:50:35 <sipa> a second transaction comes in, which conflicts with one that is already in the memory pool
 555 2012-06-01 09:50:39 <sipa> that's what happens
 556 2012-06-01 09:50:45 <sipa> it's simply discarded
 557 2012-06-01 09:50:49 <weex> yes, this happens already
 558 2012-06-01 09:51:14 <MC1984> wat
 559 2012-06-01 09:51:31 <MC1984> so if i tred to double spend
 560 2012-06-01 09:51:48 <MC1984> it would current be cought nearly instantly
 561 2012-06-01 09:51:52 <sipa> incoming transactions are only accepted into the memory pool if they do not conflict with the blockchain + what is already in the memory pool
 562 2012-06-01 09:51:55 <sipa> yes, of course
 563 2012-06-01 09:52:07 <sipa> otherwise 0-conf transactions would be extremely dangerous to accept
 564 2012-06-01 09:52:11 <weex> sipa: is there a list of double spend attempts?
 565 2012-06-01 09:52:21 <MC1984> so my idea already exists
 566 2012-06-01 09:52:28 <sipa> weex: not really, maybe some site tracks them
 567 2012-06-01 09:52:32 <sipa> bitcoind doesn't
 568 2012-06-01 09:53:08 <MC1984> so for the risk in getting shafted for the price of a can of coke or whatever
 569 2012-06-01 09:53:24 <MC1984> the risk in accepting a instant txn is already nearly zero?
 570 2012-06-01 09:53:36 <weex> MC1984: if you accept incoming transactions it's not nearly 0
 571 2012-06-01 09:53:41 <weex> incoming connections i mean
 572 2012-06-01 09:54:00 <MC1984> yes
 573 2012-06-01 09:54:04 <weex> because attacker can send you the less-widely-distributed txn first
 574 2012-06-01 09:54:09 <MC1984> ok assuming you lock down your connections
 575 2012-06-01 09:54:14 <MC1984> the risk is ultra low?
 576 2012-06-01 09:54:26 <weex> i'd say a lot lower than this conversation would merit
 577 2012-06-01 09:54:36 <sipa> MC1984: there is the finney attack
 578 2012-06-01 09:54:41 <weex> and all the other double-spend conversations before it
 579 2012-06-01 09:54:49 <weex> quite a popular topic it is
 580 2012-06-01 09:54:54 <sipa> which is probably the only viable way of exploiting a 0-conf transaction without massive hash power
 581 2012-06-01 09:55:22 <sipa> (though it still requires a ton of hash power)
 582 2012-06-01 09:55:25 <MC1984> is this finney attack worth it for the value of say $50 or whatever
 583 2012-06-01 09:55:30 <sipa> no
 584 2012-06-01 09:55:39 <MC1984> ok
 585 2012-06-01 09:55:48 <MC1984> thats what i was talking about
 586 2012-06-01 09:56:05 <MC1984> acceptable risk to be able to take bitcoins instantly
 587 2012-06-01 09:56:15 <MC1984> without externalities to the network
 588 2012-06-01 09:56:23 <sipa> sure, that's possible
 589 2012-06-01 09:56:37 <weex> MC1984: you can try a 0-conf txn at coindl if you like (my site)
 590 2012-06-01 09:56:47 <MC1984> it seems like you may be able to run a web merchant for smallish sales like this already without getting scammed
 591 2012-06-01 09:57:02 <weex> nothing more than $50 on there
 592 2012-06-01 09:57:18 <MC1984> so you run a site
 593 2012-06-01 09:57:29 <MC1984> and you deal in no more than $50 value sales
 594 2012-06-01 09:57:45 <MC1984> and you are happy with the risk of taking 0 conf txns
 595 2012-06-01 09:57:59 <weex> sure, i'll let you know when i see a double-spend
 596 2012-06-01 09:58:10 <MC1984> because bitcoind will flag any double spend as it comes in off the wire already?
 597 2012-06-01 09:58:15 <weex> when the txns stop confirming
 598 2012-06-01 09:58:25 <weex> no, it'll just not confirm
 599 2012-06-01 09:58:32 <weex> or maybe will confirm once
 600 2012-06-01 09:58:35 <weex> or 3 times
 601 2012-06-01 09:59:21 <MC1984> say someone paid you to you bitcoind and then your bitcoind sees a double spend come in on the wire
 602 2012-06-01 09:59:28 <MC1984> it will just not confirm?
 603 2012-06-01 09:59:42 <weex> MC1984: it's like this, bitcoind sees the first transaction it sees
 604 2012-06-01 09:59:55 <weex> after that the question is, will that one be included in the blockchain?
 605 2012-06-01 10:00:06 <weex> if not, i've been duped
 606 2012-06-01 10:00:35 <weex> but that means the attacker made my system think that txn was going to be accepted into the blockchain
 607 2012-06-01 10:00:49 <weex> and you can get as elaborate as you want with that modeling, observing
 608 2012-06-01 10:01:08 <MC1984> ok
 609 2012-06-01 10:01:10 <MC1984> well
 610 2012-06-01 10:02:25 <MC1984> it seems like i could trade all day with smallish amounts 0 confirms and be very confident of not getting double spend already
 611 2012-06-01 10:03:20 <MC1984> because someone would have to attempt double spend before the next block, and my bitcoind would pick up the dupe txn on the wire almost instantly from anywhere in the world
 612 2012-06-01 10:03:26 <MC1984> thats how i understand it
 613 2012-06-01 10:03:37 <weex> bitcoind drops any dupe it sees
 614 2012-06-01 10:03:49 <MC1984> yes
 615 2012-06-01 10:03:59 <weex> to double spend you must transmit competing transactions pretty much simultaneously
 616 2012-06-01 10:04:23 <MC1984> maybe as a merchant there should be a patch to make bitcoind flag a fraud attempt instead of quietly dropping then
 617 2012-06-01 10:04:25 <MC1984> or somthing
 618 2012-06-01 10:05:01 <weex> MC1984: you have consider potential for abuse
 619 2012-06-01 10:05:14 <weex> i'm fine with txns not confirming as being notice enough
 620 2012-06-01 10:06:03 <MC1984> what other circumstances will a txn not confirm though
 621 2012-06-01 10:06:10 <MC1984> apart from not enough fee
 622 2012-06-01 10:06:45 <weex> well i suppose if one of it's inputs stops confirming
 623 2012-06-01 10:06:48 <weex> its
 624 2012-06-01 10:07:38 <Habbie> can a tx even be confirmed if there are unconfirmed inputs?
 625 2012-06-01 10:08:36 <weex> i don't know the details of what bitcoind will accept in terms of how many confirms an input has
 626 2012-06-01 10:08:40 hnz has quit ()
 627 2012-06-01 10:10:38 <weex> it would be handy if i could tell bitcoind to listen and display txns for addresses i send it
 628 2012-06-01 10:11:09 <weex> instead of it only listening for addresses that have been fully imported or generated by itself
 629 2012-06-01 10:11:23 <sipa> Habbie: no
 630 2012-06-01 10:12:33 <Habbie> sipa, good, just checking
 631 2012-06-01 10:17:02 <MC1984> bitcoin wont move txns on without atleast 1 confirm right
 632 2012-06-01 10:17:23 <sipa> it will relay any transaction that makes it into its own memory pool
 633 2012-06-01 10:17:38 <sipa> if it would only relay at one confirmation, no transaction would ever reach a miner
 634 2012-06-01 10:17:49 <MC1984> no i mean you cant spend unconfirmed txn
 635 2012-06-01 10:18:01 <sipa> the protocol allows that
 636 2012-06-01 10:18:15 <sipa> but the client will not, unless it's an output from yourself (change or explicit send-to-self)
 637 2012-06-01 10:18:55 <MC1984> say there is a custom client
 638 2012-06-01 10:19:32 <MC1984> and an unconfirmed coins gets spent to 5 different people in a row before the next block
 639 2012-06-01 10:19:44 <MC1984> but then the block comes in and its a double spend
 640 2012-06-01 10:20:09 <MC1984> do those 5 people all reverse
 641 2012-06-01 10:20:43 <sipa> depends on whether they received their own transaction in the first place
 642 2012-06-01 10:20:45 <sipa> but if they do, yes
 643 2012-06-01 10:20:58 <sipa> well, they will keep seeing those transactions, but they will remain at 0 conf
 644 2012-06-01 10:23:14 <MC1984> hmm maybe bitcoin should indicate to the user that there is more of a problem than just txns that never confirm
 645 2012-06-01 10:23:22 <MC1984> and presumable are now stuck in your client forever
 646 2012-06-01 10:23:25 <sipa> i agree
 647 2012-06-01 10:23:45 <MC1984> like, indicate to the user that they probably just got defrauded
 648 2012-06-01 10:24:09 <sipa> there are plans for introducing "negative confirmations" for this: if a transaction directly or indirectly conflicts with one that is N deep in the blockchain, it would get -N confirmations
 649 2012-06-01 10:24:24 <MC1984> i like it
 650 2012-06-01 10:24:28 <sipa> and at -6 or something, you could choose to give up and delete the transaction or something
 651 2012-06-01 10:24:40 <MC1984> make it red text too
 652 2012-06-01 10:24:49 * sipa doesn't touch GUI code
 653 2012-06-01 10:24:49 <MC1984> red always means bad
 654 2012-06-01 10:25:11 <weex> unless your QT theme is messed up, then it might be green :P
 655 2012-06-01 10:25:14 <sipa> but yes, sure, it should be clearly marked "rejected"
 656 2012-06-01 10:25:46 O2made has joined
 657 2012-06-01 10:26:40 <MC1984> could it give a reason for rejection too
 658 2012-06-01 10:27:03 <MC1984> like double spend, too low fee etc
 659 2012-06-01 10:27:22 <MC1984> those are the only two i know of that would make a txn not confirm
 660 2012-06-01 10:27:29 <sipa> too low fee only influences whether it may end up in the blockchain or not
 661 2012-06-01 10:27:41 <sipa> that doesn't make it rejected
 662 2012-06-01 10:28:10 <sipa> (read: it's something you as a sender of a transaction can't know for sure)
 663 2012-06-01 10:28:50 <MC1984> so only double spend would cause an outright rejection
 664 2012-06-01 10:29:22 <sipa> it's just "attempted double spend" really, double spends don't exist from the point of a blockchain
 665 2012-06-01 10:29:32 <sipa> and they can occur without malicious intent as well
 666 2012-06-01 10:30:27 <MC1984> how, you have to send the same inputs to 2 different addresses at the samet time
 667 2012-06-01 10:31:02 <sipa> for example if you copy a wallet.dat file to two systems
 668 2012-06-01 10:31:08 <sipa> and send from them simultaneously
 669 2012-06-01 10:31:33 <sipa> if one sends before hearing the other's transaction, there is a chance it uses a same input
 670 2012-06-01 10:31:42 <MC1984> that doesnt seem like an accident
 671 2012-06-01 10:32:01 <sipa> it has happened before :)
 672 2012-06-01 10:32:10 <sipa> it doesn't have to be exactly simultaneously
 673 2012-06-01 10:32:31 <MC1984> oh
 674 2012-06-01 10:32:35 <sipa> for example one system can be offline while the other sends, and the second transaction is done before the first transaction made it into a block
 675 2012-06-01 10:32:56 <sipa> so the normal tx propagation doesn't work
 676 2012-06-01 10:33:18 <MC1984> well the recipients will still detect it very quick
 677 2012-06-01 10:33:37 <sipa> the recipients will most likely only receive the first one
 678 2012-06-01 10:40:12 _Fireball has joined
 679 2012-06-01 10:41:28 DamascusVG has joined
 680 2012-06-01 10:41:44 DamascusVG has quit (Changing host)
 681 2012-06-01 10:41:44 DamascusVG has joined
 682 2012-06-01 10:42:28 toffoo has quit ()
 683 2012-06-01 10:45:46 MobiusL has quit (Remote host closed the connection)
 684 2012-06-01 10:46:12 RainbowDashh has quit (Quit: RainbowDashh)
 685 2012-06-01 10:47:41 knotwork has quit (Read error: Connection reset by peer)
 686 2012-06-01 10:48:03 MobiusL has joined
 687 2012-06-01 10:53:15 wizkid057 has quit (Remote host closed the connection)
 688 2012-06-01 10:53:37 wizkid057 has joined
 689 2012-06-01 10:58:47 RainbowDashh has joined
 690 2012-06-01 11:00:44 knotwork has joined
 691 2012-06-01 11:01:14 <sipa> ;;bc,tslb
 692 2012-06-01 11:01:29 <gribble> Time since last block: 18 minutes and 57 seconds
 693 2012-06-01 11:03:50 <drizztbsd> sipa: do you use bitvps.com? :P
 694 2012-06-01 11:06:06 <sipa> no
 695 2012-06-01 11:13:18 Turingi has quit (Read error: Connection reset by peer)
 696 2012-06-01 11:18:22 darkee has quit (Quit: Verlassend)
 697 2012-06-01 11:32:04 graingert has joined
 698 2012-06-01 11:40:10 egecko has joined
 699 2012-06-01 11:42:35 erle- has quit (Quit: erle-)
 700 2012-06-01 11:46:26 rdponticelli has joined
 701 2012-06-01 11:48:20 sytse has quit (Ping timeout: 272 seconds)
 702 2012-06-01 11:48:43 sytse has joined
 703 2012-06-01 11:51:42 agricocb has quit (Quit: Leaving.)
 704 2012-06-01 12:06:34 comboy_ is now known as comboy
 705 2012-06-01 12:10:29 Diapolo has joined
 706 2012-06-01 12:14:18 erle- has joined
 707 2012-06-01 12:19:48 Diapolo has left ()
 708 2012-06-01 12:25:13 datagutt has joined
 709 2012-06-01 12:28:35 _flow_ has quit (Ping timeout: 248 seconds)
 710 2012-06-01 12:31:46 minimoose has joined
 711 2012-06-01 12:32:51 O2made has quit (Ping timeout: 252 seconds)
 712 2012-06-01 12:34:41 <sipa> BlueMatt: how much is there left to reimplement in cblockstore?
 713 2012-06-01 12:35:08 <BlueMatt> sipa: before pull, Im just gonna do EmitTransaction/CommitTransaction and remove the wallet callbacks at the top of main.cpp, the rest can come in later pulls
 714 2012-06-01 12:37:05 <BlueMatt> sipa: shouldnt take me more than a few hours after I finish breakfast
 715 2012-06-01 12:39:50 <BlueMatt> sipa: oh, and rename to CHub again
 716 2012-06-01 12:39:55 <sipa> BlueMatt: i hope we can encapsulate the actual blockstore (just the blocks database interface) and network node code afterwards
 717 2012-06-01 12:39:55 mcorlette is now known as mcorlett
 718 2012-06-01 12:40:09 <BlueMatt> sipa: thats my hope
 719 2012-06-01 12:40:19 <BlueMatt> or, thats next
 720 2012-06-01 12:40:46 <sipa> right, i was just about to mention that again; cblockstore is what you use to interact with the blockchain, but it's not the blockchain itself
 721 2012-06-01 12:41:10 <BlueMatt> yea, I just forgot I was gonna rename when I started this branch
 722 2012-06-01 12:43:00 <sipa> i do wonder about the node selection algorithm for requesting blocks
 723 2012-06-01 12:43:13 <BlueMatt> not the blockchain itself, but it does encapsulate it
 724 2012-06-01 12:43:30 <BlueMatt> why?
 725 2012-06-01 12:45:03 <BlueMatt> imo net could use an upgrade to request things in general, and if a node doesnt respond, request from someone else
 726 2012-06-01 12:46:01 <sipa> ideally, i'd say the top-level code is something like: CBlockStore store(dbenv); store.load(); CHub hub(store); hub.startthreads(); CNetNode node(hub); node.start(); CWallet wallet(hub, dbenv); wallet.load(); CRPCServer server(hub, wallet); server.start();
 727 2012-06-01 12:46:43 <sipa> oh certainly, much improvement is possible for the block syncing
 728 2012-06-01 12:46:55 danbri has joined
 729 2012-06-01 12:47:44 <sipa> just not sure about your actual approach now, but i'll look at it a bit more closely soon
 730 2012-06-01 12:48:27 <BlueMatt> hm? the only change is pick a random node with the base block instead of picking the node which triggered the orphan chain request
 731 2012-06-01 12:49:17 <sipa> i'll shut up about it for now :)
 732 2012-06-01 12:49:43 <BlueMatt> in terms of connecting a CHub to a CBlockStore, I dunno...to me that looks like a nop, you end up with a bunch of 2-line functions in CHub (call to CBlockStore, emit callback)
 733 2012-06-01 12:51:01 <sipa> hmm, maybe, but it feels cleaner as you could easily put another blockstore in, without needing to change any hub code
 734 2012-06-01 12:51:20 <sipa> if cblockstore becomes a virtual with several implementations
 735 2012-06-01 12:51:23 <BlueMatt> thats true, SPVBlockStore FullBlockStore
 736 2012-06-01 12:51:29 <sipa> exactly
 737 2012-06-01 12:52:19 <BlueMatt> mmm...well yea that may be a bit cleaner...could do that now then
 738 2012-06-01 12:52:40 <sipa> or even a dummyblockstore that accepts everything but stores nothing - nice for when you are already behind a single trusted blockchain
 739 2012-06-01 12:52:45 <BlueMatt> alright, Ill rename CBlockStore->CHub and make a CBlockStore which CHub calls
 740 2012-06-01 12:52:56 agricocb has joined
 741 2012-06-01 12:53:15 <sipa> don't think you need the CBlockStore itself now already
 742 2012-06-01 12:54:41 <sipa> but it won't hurt of course
 743 2012-06-01 12:56:22 gavinandresen has joined
 744 2012-06-01 12:56:34 <BlueMatt> alright, well, for now, it seems a CBlockStore would make CHub entirely just an additional call on the stack trace without doing anything, Ill leave it be for now, until we do a CSPVBlockStore or something
 745 2012-06-01 12:56:48 <BlueMatt> gavinandresen: me and sipa were just discussing CBlockStore (well, CHub)
 746 2012-06-01 12:57:03 <gavinandresen> I'll read the logs...
 747 2012-06-01 12:57:55 <sipa> BlueMatt: static functiin calls are pretty cheap, unless inside a tight algorithmic loop that does millions of iterations :)
 748 2012-06-01 12:58:34 <BlueMatt> true, but why over-complicate if we arent gonna have a CSPVBlockStore for another few months at the minimum anyway?
 749 2012-06-01 12:59:15 <sipa> sure, not arguing that it should be there already, just saying that the argument about an extra stack frame hardly matters
 750 2012-06-01 12:59:37 <BlueMatt> that was a way of putting "its a nop" not an actual argument
 751 2012-06-01 13:00:02 <sipa> ok!, let's stop meta-arguing about something we agree about
 752 2012-06-01 13:00:21 <BlueMatt> ok then
 753 2012-06-01 13:01:31 <sipa> oh, and NetworkProxyBlockStore :)
 754 2012-06-01 13:01:59 <BlueMatt> yea
 755 2012-06-01 13:02:12 <BlueMatt> NetworkProxyHub too
 756 2012-06-01 13:02:15 <sipa> or perhaps that should be CProxyHub
 757 2012-06-01 13:02:16 <sipa> indeed
 758 2012-06-01 13:06:44 tower has quit (Ping timeout: 244 seconds)
 759 2012-06-01 13:10:43 <gavinandresen> BlueMatt: Why rename ProcessBlock->EmitBlock ?  I think "process" is a better name.  Also, I'm still not seeing why you need both boost::signals AND threads; what are the threads for?
 760 2012-06-01 13:11:01 Skaag has quit (Read error: Connection reset by peer)
 761 2012-06-01 13:11:19 Skaag has joined
 762 2012-06-01 13:11:38 TD has joined
 763 2012-06-01 13:12:30 tower has joined
 764 2012-06-01 13:13:30 <BlueMatt> so that you can call the signals without any locks
 765 2012-06-01 13:13:46 <BlueMatt> and without blocking the chain download to callback eg wallet methods
 766 2012-06-01 13:14:38 <BlueMatt> process/emit, meh whatever, I dont care, the commit is to indicate its ProcessMessage->CHub::...
 767 2012-06-01 13:15:03 <BlueMatt> and, depending on the backend blockstore, it may only be emitting, and not actually processing anything
 768 2012-06-01 13:15:05 <gavinandresen> You want the signal notifications to be asynchronous.  Ok, but isn't that just an implementation detail?
 769 2012-06-01 13:15:25 MobiusL has quit (Ping timeout: 276 seconds)
 770 2012-06-01 13:15:35 <BlueMatt> ah, so you are saying launch the threads in the CHub() constructor?
 771 2012-06-01 13:15:52 <gavinandresen> Yes, I don't see any reason to expose that implementation detail in the API
 772 2012-06-01 13:15:55 _Fireball has quit (Read error: No route to host)
 773 2012-06-01 13:16:41 Zarutian has joined
 774 2012-06-01 13:16:42 <BlueMatt> that was just so that you can do if (!CreateThread(...)) return false; in AppInit2
 775 2012-06-01 13:16:50 _Fireball has joined
 776 2012-06-01 13:17:08 <sipa> if that fails, i think you can safely throw a fatal error
 777 2012-06-01 13:17:25 <BlueMatt> fair enough, Ill do that...one sec
 778 2012-06-01 13:17:26 <gavinandresen> yes, throwing an exception from the blockstore constructor should be fine
 779 2012-06-01 13:17:56 <sipa> "woops, kernel has no memory for threads left - let's try to die gracefully!"
 780 2012-06-01 13:18:57 <gavinandresen> Does CWallet need a pointer to the CHub?  Seems to me it aughtn't....
 781 2012-06-01 13:20:57 <BlueMatt> maybe I just hate globals too much...
 782 2012-06-01 13:21:18 <gavinandresen> who said anything about a global?
 783 2012-06-01 13:21:45 <gavinandresen> what will the wallet use the pBlockStoreToCall pointer for?
 784 2012-06-01 13:21:58 <BlueMatt> if it doesnt get a pointer, it has to call (the global) phub->...
 785 2012-06-01 13:22:07 <gavinandresen> to do what?
 786 2012-06-01 13:22:33 <gavinandresen> ... and could it do CHub::static_method(....)   instead ?
 787 2012-06-01 13:22:50 <BlueMatt> later it will need it to call eg EmitTransaction
 788 2012-06-01 13:22:53 <BlueMatt> on new txes
 789 2012-06-01 13:22:59 MobiusL has joined
 790 2012-06-01 13:23:11 <gavinandresen> So:  CHub::SubmitNewTransaction(....)
 791 2012-06-01 13:23:45 <gavinandresen> it doesn't matter which CHub (if you have several) validates and then submits the transaction, does it?
 792 2012-06-01 13:24:17 <BlueMatt> you may have different CHubs that are using different blockstore backends
 793 2012-06-01 13:24:30 <sipa> so how would CHub::SubmitNewTransaction find a CHub, gavinandresen?
 794 2012-06-01 13:24:36 <gavinandresen> implementation detail
 795 2012-06-01 13:24:53 <BlueMatt> and in that case, you may want a wallet connected to the non-checking proxied-behind-good-node blockstore, and one to the fully-checking one
 796 2012-06-01 13:24:57 <gavinandresen> ... maybe it keeps a static vector of constructed CHubs
 797 2012-06-01 13:25:16 <sipa> it seems very natural that every object that interacts with a hub, knows which hub it is interacting with
 798 2012-06-01 13:25:18 <BlueMatt> imho that gets messier than just registering a hub to the wallet on wallet creation
 799 2012-06-01 13:25:41 <sipa> even if there is only one hub in typical applications
 800 2012-06-01 13:26:43 <gavinandresen> BlueMatt: why would the wallet care about which variation of blockstore is being used when it just wants to submit a new wallet transaction?
 801 2012-06-01 13:27:06 <sipa> it definitely does not need to know which type of blockstore is used
 802 2012-06-01 13:27:08 <BlueMatt> Im saying if you have multiple running, the wallet may care which one it connects to
 803 2012-06-01 13:27:13 <gavinandresen> why?
 804 2012-06-01 13:27:25 <BlueMatt> ie the user who created the wallets may care, the wallet itself should not need to know
 805 2012-06-01 13:27:33 <BlueMatt> just that its connected to the one the user wants it connected to
 806 2012-06-01 13:29:12 <sipa> there is a point in splitting the chub core (submit and register stuff) and the interaction layer (emit stuff)
 807 2012-06-01 13:30:17 <sipa> you could for example turn the interaction layer into a virtual base class for for class that does interact with hubs
 808 2012-06-01 13:30:19 <gavinandresen> I'm still trying to think of use-cases where I create a wallet and then care about which CHub it is connected to.
 809 2012-06-01 13:30:47 <gavinandresen> Maybe first you could tell me some (future) use cases where there are multiple CHubs
 810 2012-06-01 13:31:40 <gavinandresen> ?? would there be multiple CHubs if there was some type of dual-stack network implementation, with one CHub connected to the bitcoin p2p network and another to some other network that transmits blocks and transactions ??
 811 2012-06-01 13:32:06 <sipa> meh, that's similar to the c library exposing a random function but hiding the singleton state array it uses, because nobody would need two random states simultaneously
 812 2012-06-01 13:32:45 <BlueMatt> I think those use-cases should be using multiple processes, so, really there arent much of any
 813 2012-06-01 13:32:53 <TD> what does a CHub do again?
 814 2012-06-01 13:33:07 <TD> i tried to design bitcoinj to allow different types of block store, multiple simultaneous wallets, etc
 815 2012-06-01 13:33:21 <BlueMatt> you emit transactions to it, it callsback when you get a new block/tx/etc
 816 2012-06-01 13:33:30 <BlueMatt> s/transactions/transactions, blocks, etc/
 817 2012-06-01 13:33:37 <sipa> TD: blockchain <-> (network, wallet) interactions
 818 2012-06-01 13:33:41 t7_ has joined
 819 2012-06-01 13:33:56 <sipa> the hub is the message dispatcher in between
 820 2012-06-01 13:34:03 <TD> i see
 821 2012-06-01 13:34:15 <TD> so it decides for every tx in a block, for which wallets/arbitrary-listener-things are interested?
 822 2012-06-01 13:34:21 <BlueMatt> gavinandresen: meh, whatever, static method, pointer, doesnt matter /that/ much, just seems more logical to me to throw in a pointer
 823 2012-06-01 13:34:51 <BlueMatt> TD: for now, it lets the listeners decide and just sends them each block, but actually registering what you are interested could be done
 824 2012-06-01 13:35:22 <sipa> i kinda agree with BlueMatt, it doesn't simplify anything to make the method static, and then have it still pick a private global object to dispatch to
 825 2012-06-01 13:35:25 <BlueMatt> (because, for now, all the listeners do care about each block, and want to run AddToWalletIfInvolvingMe on each tx)
 826 2012-06-01 13:35:58 <TD> i see
 827 2012-06-01 13:36:25 <TD> in bitcoinj the BlockChain lets you register Wallets with it and then it tests each transaction for relevance, and sends them to the Wallet class. but i'd like to make it more decoupled.
 828 2012-06-01 13:36:33 <BlueMatt> TD: its really exclusively just a refactor, but it adds some nice possibilities down the road
 829 2012-06-01 13:36:42 <TD> yes
 830 2012-06-01 13:37:30 Skaag has quit (Quit: Is dreams our reality, or is reality our dreams?)
 831 2012-06-01 13:38:26 copumpkin has quit (Quit: Computer has gone to sleep.)
 832 2012-06-01 13:38:42 <gavinandresen> BlueMatt: holding a pointer to another object triggers my "these things might be too tightly coupled" flag.  And makes me nervous because suddenly order of destruction might matter....
 833 2012-06-01 13:39:11 <sipa> gavinandresen: the idea is to make chub one day a virtual base class, with several implementations
 834 2012-06-01 13:39:30 <sipa> e.g. one that interacts with a block database on another system
 835 2012-06-01 13:40:01 <sipa> wallets would interact with the virtual base, but not know which implementation they talk to
 836 2012-06-01 13:40:41 Maccer has quit (Ping timeout: 240 seconds)
 837 2012-06-01 13:41:33 <sipa> the chub interface is just the general abstraction through which they interact, and exactly allows decoupling, imho
 838 2012-06-01 13:41:38 <gavinandresen> TD BlueMatt : if you have time, I'm looking for feedback on some lower-level new RPC commands:  https://gist.github.com/2839617
 839 2012-06-01 13:43:28 <gavinandresen> sipa:  if the only interacting they are doing is submitting (emitting?  why emit?) transactions then I think a static method is better, because if you have more than one CHub then I think you're going to want all of them to know about the new transaction.
 840 2012-06-01 13:44:08 <TD> jgarzik is doing "transaction bloom filter work"? is that the protocol extension i mentioned before?
 841 2012-06-01 13:44:18 <gavinandresen> TD: no, RPC command
 842 2012-06-01 13:44:19 <TD> listunspent might be more useful if you could specify a minimum amount
 843 2012-06-01 13:44:31 <TD> rather than minimum count (they could be random - what is the use case for min count?)
 844 2012-06-01 13:44:41 <Diablo-D3> lol did someone say bloom filter
 845 2012-06-01 13:44:48 <Diablo-D3> I wrote a bloom filter once
 846 2012-06-01 13:44:51 <Diablo-D3> it took about 20 minutes
 847 2012-06-01 13:44:59 <Diablo-D3> I still dont get whats supposed to be so fucking awesome about them
 848 2012-06-01 13:45:08 <BlueMatt> gavinandresen: emitting/submitting same thing, doesnt really matter, emit was used because it fits with the async callback naming stuff
 849 2012-06-01 13:45:14 <sipa> gavinandresen: wallets are inherently registered to a chub already, since they need to receive callbacks from them
 850 2012-06-01 13:45:26 <gavinandresen> TD: ACK on minamount, I think that'd be better.  Failure if there aren't at least minamount unspent?
 851 2012-06-01 13:45:30 <TD> gavinandresen: sure
 852 2012-06-01 13:45:33 <TD> gavinandresen: so what is the RPC for?
 853 2012-06-01 13:45:37 <TD> gavinandresen: jeffs, i mean
 854 2012-06-01 13:46:10 <sipa> gavinandresen: sure you could argue they will want to register to all hubs that exist, but if someone wants more than one hub, let them deal with but make sure they can
 855 2012-06-01 13:46:50 peck has joined
 856 2012-06-01 13:46:52 Skaag has joined
 857 2012-06-01 13:47:07 <TD> gavinandresen: if sendrawtx fails (insufficient fees? no network?) what is the response?
 858 2012-06-01 13:47:11 <gavinandresen> TD: transaction version of -blocknotify
 859 2012-06-01 13:47:23 <gavinandresen> (call an external process when 'interesting' transactions happen)
 860 2012-06-01 13:48:09 <gavinandresen> TD: json error...
 861 2012-06-01 13:48:13 <TD> gavinandresen: i see. it'd be nice if that wasn't an RPC but [also] a regular network message. as a third party program always has the option to talk network to a node to get that data, but other nodes don't have the option to do RPC
 862 2012-06-01 13:48:23 <TD> but the bulk of the work is not wiring up to the network/rpc code anyway
 863 2012-06-01 13:48:26 <TD> so i'm glad it's happening ....
 864 2012-06-01 13:48:31 <Diablo-D3> hey guys
 865 2012-06-01 13:48:35 <Diablo-D3> I want your opinion
 866 2012-06-01 13:48:44 <Diablo-D3> whats the best program to replace gprof
 867 2012-06-01 13:48:48 <sipa> BlueMatt: how about the idea of putting the code for interacting with chub in a separate virtual base class?
 868 2012-06-01 13:49:25 <TD> gavinandresen: it looks very reasonable to me. though the idea of people passing around hex encoded strings is a little bizarre :) i guess the next step is a way to save the transactions to a file and let people email them to each other
 869 2012-06-01 13:49:42 <sipa> BlueMatt: i can write some code to show if you like
 870 2012-06-01 13:50:00 <gavinandresen> TD: sipa and I talked a little about hex-encoded-serialized-format versus something else yesterday
 871 2012-06-01 13:50:34 <Diablo-D3> no one wants to comment?
 872 2012-06-01 13:50:39 <gavinandresen> The advantage of hex-encoded-serialized-format is it is trivial to parse hex, and then once it is in network-serialized-format we can be pretty sure we've got bug-free code to deal with it
 873 2012-06-01 13:50:50 <BlueMatt> sipa: you mean handle the register stuff in a virtual base class and have wallet extend that?
 874 2012-06-01 13:51:05 <sipa> BlueMatt: yes
 875 2012-06-01 13:51:21 <gavinandresen> Diablo-D3: I've been using callgrind the last couple of times I had to figure out what was slow.
 876 2012-06-01 13:51:23 <BlueMatt> sounds good to me, though that is what CHub rev 1 was and everyone hated that...
 877 2012-06-01 13:51:32 <BlueMatt> but CHub rev 1 sucked for other reasons
 878 2012-06-01 13:51:38 <luke-jr> gavinandresen: forrestv was OK with the single-Object-param change, so I implemented it
 879 2012-06-01 13:52:27 <sipa> BlueMatt: so you'd initialize the CHubClient base class with the actual CHub as argument, and you can then just call EmitBlock or SubmitDonkey whatever, and it would get sent to the right chub
 880 2012-06-01 13:52:47 <BlueMatt> sounds good, Ill do that as I rename stuff
 881 2012-06-01 13:52:53 <sipa> great
 882 2012-06-01 13:52:54 <Diablo-D3> gavinandresen: that seems to be my only option but I have to install half of kde to get kcachegrind so I can read the logs
 883 2012-06-01 13:54:09 dw has quit (Ping timeout: 265 seconds)
 884 2012-06-01 13:54:21 dw has joined
 885 2012-06-01 13:54:42 <BlueMatt> Diablo-D3: and those libs totall...less than 1G, get over it ;)
 886 2012-06-01 13:55:04 <Diablo-D3> yeah but its just more trash I dont need =/
 887 2012-06-01 13:55:22 <BlueMatt> if you're using kcachegrind, you do need it
 888 2012-06-01 13:55:34 <Diablo-D3> I dont get why it needs kde though
 889 2012-06-01 13:55:38 <Diablo-D3> it does nothing more than qt
 890 2012-06-01 13:56:55 wasabi1 has joined
 891 2012-06-01 13:58:23 danbri has quit (Remote host closed the connection)
 892 2012-06-01 14:00:05 copumpkin has joined
 893 2012-06-01 14:03:21 Turingi has joined
 894 2012-06-01 14:17:57 blumenkraft has joined
 895 2012-06-01 14:18:36 Maccer has joined
 896 2012-06-01 14:20:40 drizztbsd has quit (Quit: Konversation terminated!)
 897 2012-06-01 14:20:41 NeedzTweezerstoF is now known as Bigpiggy01Mining
 898 2012-06-01 14:20:45 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 899 2012-06-01 14:21:07 drizztbsd has joined
 900 2012-06-01 14:21:23 <luke-jr> FWIW, Mac 10.5 user confirmed my gitian bitcoind works
 901 2012-06-01 14:21:43 <Diablo-D3> fuck all the osxes.
 902 2012-06-01 14:21:59 <TD> luke-jr: awesome!
 903 2012-06-01 14:22:11 <TD> btw, why does it need to be cross-compiled ?
 904 2012-06-01 14:22:23 <Diablo-D3> you're lucky you can compile it at all
 905 2012-06-01 14:22:35 <luke-jr> TD: because only Mac users have Macs?
 906 2012-06-01 14:22:36 blumenkraft has quit (Excess Flood)
 907 2012-06-01 14:22:38 <Diablo-D3> apple has been braindamaging newer xcodes so you cant compile for earlier osxes
 908 2012-06-01 14:23:07 <luke-jr> Diablo-D3: I compiled it on Ubuntu.
 909 2012-06-01 14:23:10 <Diablo-D3> then again, if you're dumb enough to buy a mac, you're dumb enough to get locked into that expensive upgrade cycle
 910 2012-06-01 14:23:33 <Diablo-D3> luke-jr: only because bitcoind doesnt use objc
 911 2012-06-01 14:23:44 <Diablo-D3> and gcc still contains enough to make 10.6 binaries
 912 2012-06-01 14:23:53 <luke-jr> Diablo-D3: 10.5
 913 2012-06-01 14:24:00 <Diablo-D3> thats not the point
 914 2012-06-01 14:24:02 <luke-jr> so you think getting Qt working will be harder
 915 2012-06-01 14:24:05 <luke-jr> I already knew that
 916 2012-06-01 14:24:17 one_zero has quit ()
 917 2012-06-01 14:24:20 <Diablo-D3> osx has basically fucked developers
 918 2012-06-01 14:24:24 <Diablo-D3> s/osx/apple/
 919 2012-06-01 14:24:31 <Diablo-D3> luke-jr: qt "should" work fine
 920 2012-06-01 14:24:33 <Diablo-D3> in theory
 921 2012-06-01 14:24:44 <Diablo-D3> they claim all this wonderful osx support, anyways
 922 2012-06-01 14:24:52 <luke-jr> Diablo-D3: it uses ObjC ;)
 923 2012-06-01 14:25:00 <Diablo-D3> yes but you can use their binaries
 924 2012-06-01 14:25:04 <Diablo-D3> so you dont have to compile it
 925 2012-06-01 14:25:56 <Diablo-D3> man, I wonder why apple hates developers so much
 926 2012-06-01 14:26:59 <BlueMatt> Diablo-D3: not as much as m$ as of windows 8 ;)
 927 2012-06-01 14:27:21 <Diablo-D3> classic apps still work in windows 8
 928 2012-06-01 14:27:25 <BlueMatt> wanna make traditional applications for the desktop environment you know everyone will be using, buy a damn license!
 929 2012-06-01 14:27:31 <Diablo-D3> and no one gives a shit about metro
 930 2012-06-01 14:27:37 <BlueMatt> thats my point
 931 2012-06-01 14:27:51 <BlueMatt> and you cant build non-metro apps using the new visual studios without paying
 932 2012-06-01 14:27:58 <Diablo-D3> yeah
 933 2012-06-01 14:27:58 <BlueMatt> for a professional license
 934 2012-06-01 14:28:09 <Diablo-D3> but you cant build old osx apps on new xcode
 935 2012-06-01 14:28:30 <BlueMatt> thats not hating developers, thought, thats hating users
 936 2012-06-01 14:28:32 <Diablo-D3> you need an old version of xcode to do it, which you cant install side by side and wont install on new osxes
 937 2012-06-01 14:28:40 <sipa> haha
 938 2012-06-01 14:28:49 <Diablo-D3> its hating developers because some devs just dropped osx altogether because of it
 939 2012-06-01 14:28:54 <luke-jr> Diablo-D3: except Qt doesn't provide 32-bit 10.5 binaries anymore -.-
 940 2012-06-01 14:29:06 <Diablo-D3> luke-jr: dont blame them, 10.5's 32 bit support is fucked
 941 2012-06-01 14:29:18 <Diablo-D3> and ppc support in 10.5 is also fucked
 942 2012-06-01 14:29:24 <luke-jr> BlueMatt: don't forget that computers shipping Windows 8 can only run Microsoft-signed OS
 943 2012-06-01 14:29:36 <luke-jr> Diablo-D3: they don't provide 10.5 or 32-bit at all
 944 2012-06-01 14:29:47 <BlueMatt> thats only arm, x86 you can disable it, but, by default, yea
 945 2012-06-01 14:29:47 <Diablo-D3> luke-jr: dont blame them really =/
 946 2012-06-01 14:30:02 <Diablo-D3> 10.5 was a nightmare
 947 2012-06-01 14:30:06 <Diablo-D3> 10.4 was fine, it was ppc only
 948 2012-06-01 14:30:12 <Diablo-D3> 10.6 was fine, it was x86-64 only
 949 2012-06-01 14:30:19 <Diablo-D3> 10.5 is a fucking pile of shit
 950 2012-06-01 14:30:24 <Diablo-D3> they should have never released it
 951 2012-06-01 14:31:48 <Diablo-D3> you know what my official stance is with anything Ive written?
 952 2012-06-01 14:31:58 <Diablo-D3> if you're on a mac, just install linux.
 953 2012-06-01 14:32:05 <Diablo-D3> muuuuch less trouble getting software to run
 954 2012-06-01 14:32:08 <helo> luke-jr: computers shipping windows 8 can run linux just fine, you just have to disable secure boot
 955 2012-06-01 14:32:25 <Diablo-D3> secure boot isnt even the problem
 956 2012-06-01 14:32:42 <luke-jr> helo: ARM?
 957 2012-06-01 14:32:49 <Diablo-D3> linux can be setup to secure boot too
 958 2012-06-01 14:32:56 <helo> luke-jr: x86
 959 2012-06-01 14:32:59 <luke-jr> Diablo-D3: yeah, like Fedora being signed by Microsoft
 960 2012-06-01 14:33:05 <luke-jr> helo: well I want ARM
 961 2012-06-01 14:33:05 <Diablo-D3> yeah exactly
 962 2012-06-01 14:33:16 <Diablo-D3> for security environments, a properly written security hypervisor would be nice
 963 2012-06-01 14:33:29 <helo> my android phone is locked down similarly
 964 2012-06-01 14:33:36 <Diablo-D3> hardware keys, signed security hypervisor, signed kernel, signed binaries
 965 2012-06-01 14:33:41 <Diablo-D3> and no scripting languages
 966 2012-06-01 14:33:53 <Diablo-D3> and no compiler
 967 2012-06-01 14:34:03 <Diablo-D3> sysadmin heaven ;_;
 968 2012-06-01 14:34:17 <luke-jr> helo: I don't like Android either. and in that case it's even illegal.
 969 2012-06-01 14:34:32 <helo> i like me some scripting languges when i admin
 970 2012-06-01 14:34:54 <helo> luke-jr: isn't it only illegal with gpl3?
 971 2012-06-01 14:35:35 * [7] likes the way it works on android, as long as you can opt to boot an unsigned code base if you want to
 972 2012-06-01 14:35:39 <helo> well it's not illegal as far as i know, just a license violation
 973 2012-06-01 14:37:08 <luke-jr> helo: no, GPLv3 makes an *exception*
 974 2012-06-01 14:37:28 <luke-jr> helo: that is, GPLv3 says you can keep signing key sources private iff you allow users to boot unsigned kernels
 975 2012-06-01 14:37:37 <luke-jr> GPLv2 just requires all source code be released period
 976 2012-06-01 14:37:56 <luke-jr> and license violations are illegal by definition
 977 2012-06-01 14:38:42 <helo> the kernel is still gpl2, and the source is released... it just isn't possible to boot an unsigned kernel built from that source
 978 2012-06-01 14:39:21 <luke-jr> helo: a signed kernel's source includes the key signing it
 979 2012-06-01 14:39:27 darkee has joined
 980 2012-06-01 14:39:50 <luke-jr> GPLv2 explicitly states that anything required for building (including compilers) is considered source code
 981 2012-06-01 14:39:59 <[7]> anything for building *what*?
 982 2012-06-01 14:40:04 <luke-jr> [7]: the binary
 983 2012-06-01 14:40:40 <sipa> well, things that are considered commonly available like operating systems and compilers are not source according to GPLv2
 984 2012-06-01 14:40:48 <[7]> is it illegal to take a finished binary from an open source project, sign it, and publish the signed binary without publishing the key?
 985 2012-06-01 14:40:53 <sipa> but that doesn't hold for signing keus of course
 986 2012-06-01 14:41:03 <helo> you can build the kernel binary just fine, just not in a way that can boot on devices with locked bootloaders
 987 2012-06-01 14:41:56 <sipa> so that means you are distributing a binary derived from a source that is GPL, in a way that people receiving the binary do not have the same rights as you
 988 2012-06-01 14:41:57 <[7]> microsoft signing fedora's code would be illegal in that case as well
 989 2012-06-01 14:41:58 Hasbro has joined
 990 2012-06-01 14:42:13 <sipa> that sounds like a GPL violation to me, but IANAL
 991 2012-06-01 14:42:18 <[7]> i.e. only locking out linux on that hardware would be legal if you don't want to drop the secure boot stuff altogether
 992 2012-06-01 14:42:46 <drizztbsd> [7]: only for GPLv3
 993 2012-06-01 14:42:53 <luke-jr> sipa: signing keys aren't commonly available :p
 994 2012-06-01 14:43:04 <sipa> luke-jr:
 995 2012-06-01 14:43:07 <drizztbsd> stallman added that after samba shit agreement
 996 2012-06-01 14:43:07 <sipa> but that doesn't hold for signing keus of course
 997 2012-06-01 14:43:08 <[7]> drizztbsd: I think only for GPLv2, which linux is
 998 2012-06-01 14:43:26 <luke-jr> [7]: it's illegal to take a signed binary from a GPLv2 project, and publish it without publishing the full source including key
 999 2012-06-01 14:43:52 <luke-jr> drizztbsd: GPLv3 makes an exception allowing you to keep the signing key private in specific circumstances
1000 2012-06-01 14:44:14 <helo> luke-jr: as far as i know no kernel developers or the fsf feels that way to the extent that they are willing to litigate
1001 2012-06-01 14:44:32 <drizztbsd> I work for a broadband company and we encrypt anythink
1002 2012-06-01 14:44:36 <drizztbsd> anything*
1003 2012-06-01 14:44:36 <luke-jr> [7]: yes, RedHat having Microsoft sign Fedora's kernel is illegal; but who is going to sue a top sponsor of Linux devs?
1004 2012-06-01 14:44:59 <luke-jr> helo: FSF doesn't have legal standing
1005 2012-06-01 14:45:04 Diapolo has joined
1006 2012-06-01 14:45:09 <luke-jr> helo: and yes, Linux copyright holders are basically cowards
1007 2012-06-01 14:45:19 <luke-jr> they should have been suing nvidia a long time ago
1008 2012-06-01 14:45:22 <luke-jr> instead they just make petitions
1009 2012-06-01 14:45:23 <[7]> "nobody wants to litigate" is not what I call a real solution though
1010 2012-06-01 14:45:24 <drizztbsd> luke-jr: why?
1011 2012-06-01 14:45:29 <luke-jr> drizztbsd: ?
1012 2012-06-01 14:45:47 <drizztbsd> what is the problem with nvidia?
1013 2012-06-01 14:45:54 <Diapolo> hi there
1014 2012-06-01 14:46:30 <helo> has the FSF not been attributed copyright over some parts of the kernel?
1015 2012-06-01 14:47:02 <luke-jr> helo: not afaik
1016 2012-06-01 14:47:19 <luke-jr> drizztbsd: they distribute a derivative work of Linux in violation of the GPL
1017 2012-06-01 14:47:56 <drizztbsd> broadcom too
1018 2012-06-01 14:48:04 <drizztbsd> intel too
1019 2012-06-01 14:49:12 <luke-jr> Intel is pretty good usually
1020 2012-06-01 14:58:08 <luke-jr> wtf
1021 2012-06-01 14:58:20 <luke-jr> why is my debug.log now called: debug.l`
1022 2012-06-01 14:58:21 <luke-jr> ?
1023 2012-06-01 15:01:45 rdponticelli_ has joined
1024 2012-06-01 15:02:08 rdponticelli has quit (Ping timeout: 246 seconds)
1025 2012-06-01 15:06:07 rdponticelli_ has quit (Ping timeout: 245 seconds)
1026 2012-06-01 15:07:31 <gavinandresen> luke-jr: gremlins? or do you have your locale set to federation-klingon ?
1027 2012-06-01 15:07:35 Hasbro has quit (Ping timeout: 260 seconds)
1028 2012-06-01 15:09:47 <luke-jr> gavinandresen: no, but I'm debugging next-eligius now
1029 2012-06-01 15:10:08 <luke-jr> makes me worry there's a buffer overflow or something tho
1030 2012-06-01 15:10:20 m00p has quit (Quit: Leaving)
1031 2012-06-01 15:10:25 <luke-jr> but I guess the whole debug.log filename code's got a redo since 0.6.0
1032 2012-06-01 15:10:55 <luke-jr> and I'm more concerned about this stupid deadlock
1033 2012-06-01 15:11:25 <luke-jr> gavinandresen: btw, gmp_bip look good now?
1034 2012-06-01 15:14:11 <gavinandresen> I'm OK with the RPC interface now, can't comment on the BIP (other than saying I think it has too much optional stuff in it) or on the details of what the pull actually does.
1035 2012-06-01 15:15:50 <gavinandresen> how many lines of code does it add to bitcoinrpc.cpp ?  If it is more than 100 then I think maybe moving getwork/getmemorypool to a mining.cpp might make sense.
1036 2012-06-01 15:16:14 <gavinandresen> (bitcoinrpc.cpp is getting way too big, in my humble opinion)
1037 2012-06-01 15:16:19 <luke-jr> under 100
1038 2012-06-01 15:16:34 Skaag has quit (Remote host closed the connection)
1039 2012-06-01 15:16:54 Skaag has joined
1040 2012-06-01 15:17:15 <luke-jr> but probably a good idea to clean up bitcoinrpc later anyway
1041 2012-06-01 15:17:29 <luke-jr> I don't like mixing cleanup with code changes, though, as it makes it harder to see what happened
1042 2012-06-01 15:19:07 <gavinandresen> agreed, either cleanup before or after.
1043 2012-06-01 15:21:13 Hasbro has joined
1044 2012-06-01 15:22:20 _flow_ has joined
1045 2012-06-01 15:24:07 andytoshi has quit (Ping timeout: 276 seconds)
1046 2012-06-01 15:29:17 t7_ has quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120528154913])
1047 2012-06-01 15:34:32 gribble has quit (Quit: brb)
1048 2012-06-01 15:37:30 vigilyn has quit (Quit: Leaving)
1049 2012-06-01 15:37:34 RainbowDashh has quit (Quit: RainbowDashh)
1050 2012-06-01 15:37:37 gribble has joined
1051 2012-06-01 15:41:21 RainbowDashh has joined
1052 2012-06-01 16:13:26 rdponticelli has joined
1053 2012-06-01 16:16:22 Bigpiggy01Mining has quit ()
1054 2012-06-01 16:34:31 t7 has quit (Remote host closed the connection)
1055 2012-06-01 16:35:46 RainbowDashh has quit (Quit: RainbowDashh)
1056 2012-06-01 16:36:38 Detritus has quit (Ping timeout: 246 seconds)
1057 2012-06-01 16:37:04 Detritus has joined
1058 2012-06-01 16:38:21 t7 has joined
1059 2012-06-01 16:43:17 RainbowDashh has joined
1060 2012-06-01 16:43:28 Diapolo has left ()
1061 2012-06-01 16:43:48 silp has joined
1062 2012-06-01 16:44:09 <silp> test
1063 2012-06-01 16:47:19 RainbowDashh has quit (Client Quit)
1064 2012-06-01 16:48:58 erle- has quit (Quit: erle-)
1065 2012-06-01 16:49:17 RainbowDashh has joined
1066 2012-06-01 16:49:40 mmoya has quit (Ping timeout: 260 seconds)
1067 2012-06-01 16:51:50 RainbowDashh has quit (Disconnected by services)
1068 2012-06-01 16:51:50 Rabbit67890 has joined
1069 2012-06-01 16:51:57 <GTRsdk> silp: succeeded
1070 2012-06-01 16:54:08 ThomasV has joined
1071 2012-06-01 16:54:23 <sipa> if this was a test whether IRC could wash your clothes, it presumably failed
1072 2012-06-01 16:56:58 osmosis has joined
1073 2012-06-01 16:58:44 TD has quit (Quit: TD)
1074 2012-06-01 16:59:07 drizztbsd has quit (Quit: Konversation terminated!)
1075 2012-06-01 17:00:41 RainbowDashh has joined
1076 2012-06-01 17:01:33 <nanotube> sipa: mine succeeded. >_> :)
1077 2012-06-01 17:01:43 <nanotube> you must be using an old irc client or something.
1078 2012-06-01 17:02:24 <BlueMatt> nanotube: wait, where do I get this clothes-washing irc client, I really need that
1079 2012-06-01 17:02:47 <nanotube> sorry i'm under an NDA, can't disclose that. >_>
1080 2012-06-01 17:02:55 <BlueMatt> damn
1081 2012-06-01 17:03:11 Rabbit67890 has quit (Ping timeout: 240 seconds)
1082 2012-06-01 17:06:09 _W_ has quit (Excess Flood)
1083 2012-06-01 17:06:14 drizztbsd has joined
1084 2012-06-01 17:06:18 _W_ has joined
1085 2012-06-01 17:06:32 rdponticelli has quit (Ping timeout: 245 seconds)
1086 2012-06-01 17:08:46 MobiusL has quit (Ping timeout: 276 seconds)
1087 2012-06-01 17:14:45 RainbowDashh has quit (Quit: RainbowDashh)
1088 2012-06-01 17:16:31 topi`_ has quit (Quit: leaving)
1089 2012-06-01 17:19:45 gavinandresen has quit (Quit: gavinandresen)
1090 2012-06-01 17:23:58 Diapolo has joined
1091 2012-06-01 17:25:08 RainbowDashh has joined
1092 2012-06-01 17:25:53 D34TH has joined
1093 2012-06-01 17:31:44 hnz has joined
1094 2012-06-01 17:35:00 mmoya has joined
1095 2012-06-01 17:35:07 [7] has quit (Disconnected by services)
1096 2012-06-01 17:35:14 TheSeven has joined
1097 2012-06-01 17:39:59 mmoya has quit (Ping timeout: 256 seconds)
1098 2012-06-01 17:45:38 TheSeven has quit (Disconnected by services)
1099 2012-06-01 17:45:47 [7] has joined
1100 2012-06-01 17:47:32 spiborg has joined
1101 2012-06-01 17:47:58 maqr has quit (Quit: :/)
1102 2012-06-01 17:49:34 MobiusL has joined
1103 2012-06-01 17:50:47 danbri has joined
1104 2012-06-01 18:00:03 TD has joined
1105 2012-06-01 18:01:36 Diapolo has quit (Quit: Leaving.)
1106 2012-06-01 18:05:24 [7] has quit (Disconnected by services)
1107 2012-06-01 18:05:30 TheSeven has joined
1108 2012-06-01 18:10:38 drizztbsd has quit (Remote host closed the connection)
1109 2012-06-01 18:16:37 rdponticelli has joined
1110 2012-06-01 18:19:32 spiborg has quit (Quit: Nettalk6 - www.ntalk.de)
1111 2012-06-01 18:19:46 spiborg has joined
1112 2012-06-01 18:30:11 danbri has quit (Remote host closed the connection)
1113 2012-06-01 18:31:50 Z0rZ0rZ0r has joined
1114 2012-06-01 18:38:46 <BlueMatt> sipa: finally got around to implementing the stuff we talked about this morning in CHub, if you've got a chance, is the CWallet/CHubListener stuff roughly what you were thinking of?
1115 2012-06-01 18:44:52 rdponticelli has quit (Ping timeout: 245 seconds)
1116 2012-06-01 18:45:11 osmosis has quit (Ping timeout: 240 seconds)
1117 2012-06-01 18:48:55 talso has joined
1118 2012-06-01 18:50:41 sgornick has quit (Ping timeout: 240 seconds)
1119 2012-06-01 18:51:15 ahihi2 has quit (Read error: Connection reset by peer)
1120 2012-06-01 18:55:19 ahihi2 has joined
1121 2012-06-01 18:58:10 osmosis has joined
1122 2012-06-01 18:59:06 Turingi has quit (Read error: Connection reset by peer)
1123 2012-06-01 19:02:42 danbri has joined
1124 2012-06-01 19:04:32 sgornick has joined
1125 2012-06-01 19:09:39 darkee has joined
1126 2012-06-01 19:12:16 darkee has quit (Ping timeout: 276 seconds)
1127 2012-06-01 19:12:48 _W_ has quit (Excess Flood)
1128 2012-06-01 19:12:55 MobiusL has quit (Ping timeout: 276 seconds)
1129 2012-06-01 19:12:55 pickett has quit (Ping timeout: 276 seconds)
1130 2012-06-01 19:12:59 _W_ has joined
1131 2012-06-01 19:16:02 tower has quit (Disconnected by services)
1132 2012-06-01 19:16:16 tower has joined
1133 2012-06-01 19:17:50 graingert has quit (Read error: Connection reset by peer)
1134 2012-06-01 19:18:10 Joric has joined
1135 2012-06-01 19:18:11 Joric has quit (Changing host)
1136 2012-06-01 19:18:11 Joric has joined
1137 2012-06-01 19:24:49 p0s has joined
1138 2012-06-01 19:25:14 pickett has joined
1139 2012-06-01 19:26:04 MobiusL has joined
1140 2012-06-01 19:26:37 setkeh` has joined
1141 2012-06-01 19:26:39 setkeh has quit (Read error: No route to host)
1142 2012-06-01 19:27:37 phantomcircuit has joined
1143 2012-06-01 19:28:55 kjj_ has quit (Ping timeout: 260 seconds)
1144 2012-06-01 19:31:34 MC1984 has quit (Quit: Leaving)
1145 2012-06-01 19:34:15 Dyaheon has quit (Ping timeout: 244 seconds)
1146 2012-06-01 19:36:32 Skaag_ has joined
1147 2012-06-01 19:38:56 Skaag has quit (Ping timeout: 245 seconds)
1148 2012-06-01 19:38:56 Skaag_ is now known as Skaag
1149 2012-06-01 19:41:40 kjj_ has joined
1150 2012-06-01 19:41:48 graingert has joined
1151 2012-06-01 19:46:22 Dyaheon has joined
1152 2012-06-01 19:56:18 spaola has quit (Remote host closed the connection)
1153 2012-06-01 19:56:48 <nanotube> hey, would anyone fill me in on what differences there are between keys generated in old wallets, and ones generated in a fresh wallet created with the latest bitcoin client? i recall there being something about key compression, at least. and possibly something else?
1154 2012-06-01 19:57:23 egecko has joined
1155 2012-06-01 19:58:00 spaola has joined
1156 2012-06-01 19:58:59 O2made has joined
1157 2012-06-01 20:00:53 <gmaxwell> nanotube: newly generated keys use the compressed public keys.
1158 2012-06-01 20:01:17 RazielZ has quit (Ping timeout: 252 seconds)
1159 2012-06-01 20:01:20 <gmaxwell> (well keys generated in wallets which have been updated to the latest wallet version)
1160 2012-06-01 20:03:37 Detritus has quit (Ping timeout: 245 seconds)
1161 2012-06-01 20:03:38 <nanotube> gmaxwell: hm, would that affect the verifymessage functionality? specifically, seems electrum's verify_message fails on new-style addresses
1162 2012-06-01 20:03:44 Detritus has joined
1163 2012-06-01 20:03:45 RazielZ has joined
1164 2012-06-01 20:18:40 p0s has quit (Remote host closed the connection)
1165 2012-06-01 20:27:01 guruvan has quit (Ping timeout: 276 seconds)
1166 2012-06-01 20:30:02 MC1984 has joined
1167 2012-06-01 20:35:04 <ThomasV> gmaxwell: indeed this seems to be the issue
1168 2012-06-01 20:35:46 Diablo-D3 has quit (Remote host closed the connection)
1169 2012-06-01 20:36:26 <gmaxwell> nanotube: yes most likely— you need to know if the address you're matching was generated from the compressed public key or the non-compressed one.
1170 2012-06-01 20:39:57 <ThomasV> what exactly is a compressed pubkey?
1171 2012-06-01 20:41:07 Detritus has quit (Ping timeout: 245 seconds)
1172 2012-06-01 20:41:16 Detritus has joined
1173 2012-06-01 20:47:29 <freewil> is there a wiki page with the different formats
1174 2012-06-01 20:48:01 phantomcircuit has quit (Remote host closed the connection)
1175 2012-06-01 20:49:16 toffoo has joined
1176 2012-06-01 20:51:09 <helo> ThomasV: http://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key
1177 2012-06-01 20:51:14 _W_ has quit (Excess Flood)
1178 2012-06-01 20:51:20 _W_ has joined
1179 2012-06-01 20:51:22 <helo> good analogy in the top response
1180 2012-06-01 20:52:03 <freewil> does the rpc command validateaddress accept compressed formats?
1181 2012-06-01 20:53:03 Turingi has joined
1182 2012-06-01 20:53:03 Turingi has quit (Changing host)
1183 2012-06-01 20:53:03 Turingi has joined
1184 2012-06-01 20:53:07 <gmaxwell> freewil: There no difference from the address side.
1185 2012-06-01 20:53:18 <gmaxwell> You can't tell by looking at an address if it reflects a compressed public key or not.
1186 2012-06-01 20:53:57 <freewil> hmm explain that
1187 2012-06-01 20:55:12 t7 has quit (Remote host closed the connection)
1188 2012-06-01 21:01:08 <ThomasV> gmaxwell: why are bitcoin addresses affected by this? it would have been possible to hash the noncompressed representation in both cases
1189 2012-06-01 21:04:52 <helo> a compressed address is just stored more compactly. the address seen by a user will look the same
1190 2012-06-01 21:05:43 rdponticelli has joined
1191 2012-06-01 21:06:01 <Eliel> but the address for a compressed public key is not the same address as for the same key in uncompressed form.
1192 2012-06-01 21:06:30 <ThomasV> hence my question
1193 2012-06-01 21:06:31 guruvan has joined
1194 2012-06-01 21:06:34 <helo> i think it is
1195 2012-06-01 21:06:41 <ThomasV> no it is not
1196 2012-06-01 21:06:57 <helo> in that case, disregard what i said Oo
1197 2012-06-01 21:07:07 <ThomasV> oh wait, no
1198 2012-06-01 21:07:51 <ThomasV> well, this is how I interpret what gmaxwell said above
1199 2012-06-01 21:08:00 <ThomasV> <gmaxwell> nanotube: yes most likely— you need to know if the address you're matching was generated from the compressed public key or the non-compressed one.
1200 2012-06-01 21:09:09 <ThomasV> and the stackexchange page too says that
1201 2012-06-01 21:10:48 <helo> maybe he means you just have to know whether to "decompress" the public key before proceeding
1202 2012-06-01 21:11:03 <ThomasV> yes that's what he means
1203 2012-06-01 21:11:15 <ThomasV> but that does not answer my question
1204 2012-06-01 21:12:31 pickett has quit (Ping timeout: 276 seconds)
1205 2012-06-01 21:12:39 <gmaxwell> ThomasV: becaues it's already in the protocol.
1206 2012-06-01 21:13:01 <gmaxwell> ThomasV: the validation of compressed public keys was not added by anyone it was there from the start.
1207 2012-06-01 21:13:26 <gmaxwell> And the way you describe couldn't be added without a hard fork.
1208 2012-06-01 21:13:55 <gmaxwell> The addres has to be the hash of whatever public key (compressed or not) you'll send over the wire, because thats how the bitcoin protocol works.
1209 2012-06-01 21:14:01 <gmaxwell> s/addres/address/
1210 2012-06-01 21:14:17 <ThomasV> I see... but that's still a strange design decision
1211 2012-06-01 21:14:40 pickett has joined
1212 2012-06-01 21:16:00 <gmaxwell> E.g. look at the standard output script.. "check that the hash of the provided data matches X, check that the signature validates using that data". It's not "normalize the provided data into a pubkey ... hash that.. check ... checksig"
1213 2012-06-01 21:16:07 <gmaxwell> ThomasV: it wasn't designed it was an accident.
1214 2012-06-01 21:16:26 <ThomasV> gmaxwell: were uncompressed addresses used in the blockchain before 0.6 ?
1215 2012-06-01 21:16:30 <gmaxwell> OpenSSL supported compressed pubkeys without being asked to do so.
1216 2012-06-01 21:16:46 <gmaxwell> ThomasV: yes. They got used before anyone got to comment on them.
1217 2012-06-01 21:17:07 <ThomasV> lol. bitcoin really is a strange ecosystem
1218 2012-06-01 21:17:09 <gmaxwell> Otherwise I might have argued for instead forbidding them instead of using them ourselves, but since we were stuck with them, might as well enjoy the space savings.
1219 2012-06-01 21:17:56 <ThomasV> it saves no space in the blockchain since we use addresses
1220 2012-06-01 21:19:28 <Joric> using OpenSSL you just have to set point conversion via EC_KEY_set_conv_form()
1221 2012-06-01 21:19:43 <gmaxwell> ThomasV: ...
1222 2012-06-01 21:19:51 <gmaxwell> ThomasV: the redepitions are smaller.
1223 2012-06-01 21:20:09 <gmaxwell> redemptions*
1224 2012-06-01 21:20:13 <gmaxwell> By quite a bit in fact.
1225 2012-06-01 21:20:13 <Joric> compressed pubkeys are 32 bytes smaller
1226 2012-06-01 21:20:36 <gmaxwell> It makes the scriptsig about 25% smaller in total IIRC.
1227 2012-06-01 21:20:40 <ThomasV> oh sure
1228 2012-06-01 21:21:31 <Eliel> gmaxwell: you only need a signature to spend the compresse pubkey version but both pubkey and signature to spend a regular one?
1229 2012-06-01 21:21:42 <gmaxwell> paytopubkey even more so— it makes paytopubkey almost competitive with key recovery.
1230 2012-06-01 21:22:19 <gmaxwell> Eliel: no, you still need pubkey and signature but the pubkey is half the size.  Key recovery lets you spend with only the signature.
1231 2012-06-01 21:22:43 <gmaxwell> But we can't do that without a BIP16 style half-fork change or a hardfork.
1232 2012-06-01 21:23:04 <gmaxwell> Verifymessage uses key recovery though.
1233 2012-06-01 21:23:47 <Eliel> gmaxwell: so, the pubkey and signature stay but the hashed address goes and that's what saves the space?
1234 2012-06-01 21:24:48 <nanotube> ThomasV: so now electrum needs to learn how to do key recovery from a compressed pubkey :)
1235 2012-06-01 21:25:44 <ThomasV> nanotube: it sucks, doesn't it?
1236 2012-06-01 21:26:45 <ThomasV> gmaxwell: how does verifymessage know which type of pubkey it should use? does it try both?
1237 2012-06-01 21:29:15 <ThomasV> or does it get a clue from the signature?
1238 2012-06-01 21:35:38 <nanotube> Old clients can validate transactions with compressed public keys because Bitcoin sends public keys to OpenSSL without checking their format and OpenSSL automatically processes the public key according to the leading byte (0x04 for uncompressed, 0x02/0x03 for compressed). – theymos
1239 2012-06-01 21:35:43 <nanotube> ThomasV: ^ from stackexchange
1240 2012-06-01 21:36:18 <nanotube> and yes, it does suck :)
1241 2012-06-01 21:36:40 <ThomasV> nanotube: yes, but verifymessage cannot rely on that; it does not have the pubkey
1242 2012-06-01 21:37:31 <gmaxwell> ThomasV: the signature has a key.
1243 2012-06-01 21:37:42 <ThomasV> ok
1244 2012-06-01 21:37:45 <gmaxwell> (there is an extra bit stuffed iirc)
1245 2012-06-01 21:38:04 <gmaxwell> Eliel: the pubkey itself becomes smaller.
1246 2012-06-01 21:38:45 <Joric> that verifymessage is it supposed mostly for signing oneliners?
1247 2012-06-01 21:39:48 <Joric> i tried to sign a long letter with it doesn't seem reliable to verify (cr/lf etc)
1248 2012-06-01 21:42:18 <Joric> i mean rpc interface / signmessage GUI
1249 2012-06-01 21:42:22 <gmaxwell> Joric: it's reliable if you actually can manage to get the data to it reliably. It doesn't mangle anyting on its own. Though for that sort of thing perhaps you're better off signing a hash.
1250 2012-06-01 21:42:28 silpee has joined
1251 2012-06-01 21:42:48 <gmaxwell> hm. well dunno what the gui does perhaps it does something non-transparent/consistent with cr/lr.
1252 2012-06-01 21:42:54 silp has quit (Ping timeout: 244 seconds)
1253 2012-06-01 21:44:02 <Joric> also why theres a signmessage GUI but no verifymessage GUI ? =)
1254 2012-06-01 21:44:17 Diapolo has joined
1255 2012-06-01 21:44:23 TD has quit (Quit: TD)
1256 2012-06-01 21:48:54 RainbowDashh has quit (Quit: RainbowDashh)
1257 2012-06-01 21:49:18 _Fireball has quit (Quit:  HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC)
1258 2012-06-01 21:52:08 <luke-jr> Joric: because verifymessage is more of a merchant function
1259 2012-06-01 21:52:12 <luke-jr> Joric: but someone added it for 0.7
1260 2012-06-01 21:54:35 tsche has quit (Ping timeout: 252 seconds)
1261 2012-06-01 21:54:54 RainbowDashh has joined
1262 2012-06-01 21:55:43 ThomasV has quit (Quit: Quitte)
1263 2012-06-01 21:56:01 RainbowDashh has quit (Remote host closed the connection)
1264 2012-06-01 21:56:23 RainbowDashh has joined
1265 2012-06-01 21:58:32 <luke-jr> holy crap
1266 2012-06-01 21:58:36 <luke-jr> bitcoind core dumps are 6.1 GB?
1267 2012-06-01 21:59:44 <D34TH> dafuq
1268 2012-06-01 22:01:30 <luke-jr> so… I dumped the contents of the memorypool that breaks txn_prio
1269 2012-06-01 22:01:39 <luke-jr> what's the best way to debug it? >.>
1270 2012-06-01 22:02:02 <luke-jr> I'd prefer to make a unit test, but it doesn't seem practical, since it probably depends on the blockchain
1271 2012-06-01 22:03:16 Skaag has quit (Read error: Connection reset by peer)
1272 2012-06-01 22:03:18 agricocb has quit (Remote host closed the connection)
1273 2012-06-01 22:03:35 Skaag has joined
1274 2012-06-01 22:04:58 welterde has quit (Ping timeout: 264 seconds)
1275 2012-06-01 22:06:40 RainbowDashh has quit (Quit: RainbowDashh)
1276 2012-06-01 22:09:49 <gmaxwell> luke-jr: hopefully that dump is a sparse file or something? 0_o
1277 2012-06-01 22:09:55 minimoose has quit (Quit: minimoose)
1278 2012-06-01 22:10:12 datagutt has quit (Quit: Computer has gone to sleep.)
1279 2012-06-01 22:12:24 <Joric> ThomasV has escaped
1280 2012-06-01 22:12:45 dvide has quit ()
1281 2012-06-01 22:13:30 <Joric> what do you guys thing about electrum? does it have future? it's semi-centralized atm there's like only 3 (well, 5) working servers
1282 2012-06-01 22:15:03 O2made has quit (Ping timeout: 244 seconds)
1283 2012-06-01 22:15:35 <luke-jr> gmaxwell: nope
1284 2012-06-01 22:16:04 <luke-jr> I suspect it doesn't compress well too
1285 2012-06-01 22:16:51 welterde has joined
1286 2012-06-01 22:18:43 <luke-jr> 89368e02d9bd17b74c2bd14b5296fcd713f7b7a0e5fd71f0f45783a1b63d8d59 is the txn it was having trouble with it seems
1287 2012-06-01 22:20:48 <luke-jr> hmm
1288 2012-06-01 22:21:03 <luke-jr> it had 17 levels deep of unconfirmed inputs
1289 2012-06-01 22:21:22 <gmaxwell> dicedos.
1290 2012-06-01 22:21:32 <luke-jr> :/
1291 2012-06-01 22:21:42 <luke-jr> gmaxwell: think caching the size of each individual txn would help?
1292 2012-06-01 22:21:50 <luke-jr> perhaps scoped to the GMP call
1293 2012-06-01 22:22:05 <luke-jr> it doesn't help the ordinary use case, but maybe it will fix this DoS
1294 2012-06-01 22:22:57 * luke-jr ponders how practical it would be to precalculate all this stuff as transactions come in and get put in blocks, rather than every CreateNewBlock call
1295 2012-06-01 22:23:30 <luke-jr> (maybe including the whole dependency tree and priority orders…)
1296 2012-06-01 22:24:23 <luke-jr> I suppose I'd need a flag to enable it, so it doesn't kill performance for non-miners
1297 2012-06-01 22:26:04 Diapolo has left ()
1298 2012-06-01 22:31:24 danbri has quit (Read error: Connection reset by peer)
1299 2012-06-01 22:31:33 danbri has joined
1300 2012-06-01 22:34:34 danbri has quit (Remote host closed the connection)
1301 2012-06-01 22:34:43 spiborg has quit (Ping timeout: 265 seconds)
1302 2012-06-01 22:37:26 RazielZ has quit (Quit: Leaving)
1303 2012-06-01 22:39:55 Diablo-D3 has joined
1304 2012-06-01 22:49:21 spiborg has joined
1305 2012-06-01 22:50:55 erle- has joined
1306 2012-06-01 22:52:10 imsaguy is now known as imsaguyat40
1307 2012-06-01 22:55:52 imsaguyat40 is now known as imsaguy
1308 2012-06-01 22:57:23 ciscoftw has joined
1309 2012-06-01 22:58:26 <ciscoftw> if you were to send .001 bitcoin and not include a transaction fee, is it possible that it never (...or for a long time) gets included into the blockchain?
1310 2012-06-01 22:58:49 <luke-jr> ciscoftw: pretty likely
1311 2012-06-01 22:58:59 <luke-jr> the long time bit anyhow
1312 2012-06-01 22:59:51 <ciscoftw> i send .05 btc from an andorid wallet app and my receiving address never got it (i did NOT send a trans fee)... was curious if that was a possibility
1313 2012-06-01 23:00:09 <luke-jr> how long ago?
1314 2012-06-01 23:00:16 <gmaxwell> .001 is not 0.05 though.
1315 2012-06-01 23:00:16 <ciscoftw> eh? maybe a week or so
1316 2012-06-01 23:00:24 <ciscoftw> it was .05
1317 2012-06-01 23:00:30 <ciscoftw> ...poor example to use .001
1318 2012-06-01 23:00:33 <luke-jr> which Android wallet app?
1319 2012-06-01 23:00:45 <gmaxwell> TXN without otputs under .01 are special and are MUCH less likely to get mined without a fee.
1320 2012-06-01 23:00:48 <ciscoftw> 'bitcoin wallet' 2.1
1321 2012-06-01 23:00:56 <ciscoftw> by andreas schildbach
1322 2012-06-01 23:01:26 <luke-jr> has it been running the whole week?
1323 2012-06-01 23:02:03 <ciscoftw> not the android app... just figured after it was broadcast to network i could shut it down
1324 2012-06-01 23:02:16 <ciscoftw> shut it down 20secs after sending
1325 2012-06-01 23:04:21 <ciscoftw> any doc you would suggest that details how miner choose what tx's to include into their block?
1326 2012-06-01 23:04:45 ovidiusoft has quit (Read error: Operation timed out)
1327 2012-06-01 23:06:10 <luke-jr> ciscoftw: arbitrarily.
1328 2012-06-01 23:06:31 <luke-jr> ciscoftw: you probably need to rebroadcast it at this point
1329 2012-06-01 23:07:18 <luke-jr> ciscoftw: fees are the main incentive for miners to include transactions, FWIW
1330 2012-06-01 23:08:24 <ciscoftw> ?but a txt doenst make a block any more difficult to solve, why not just incldue it?
1331 2012-06-01 23:09:38 <gmaxwell> For example, if someone is jerk they could easily create thousands of low value transactions per second to flood bitcoin... so by default miners have rules to not mine txn that look like a dos attack.
1332 2012-06-01 23:11:41 <luke-jr> ciscoftw: anti-spam, plus if miners always include feeless txns then there's no incentive for people to pay fees
1333 2012-06-01 23:11:49 <luke-jr> and without fees, miners might lose money mining
1334 2012-06-01 23:11:51 maqr has joined
1335 2012-06-01 23:12:08 <ciscoftw> incentive for solving the block isnt enough?
1336 2012-06-01 23:12:19 <luke-jr> ciscoftw: not in the fall, no
1337 2012-06-01 23:12:29 <ciscoftw> i mean fee's arent shit comparded to block solve award
1338 2012-06-01 23:12:39 <luke-jr> when the subsidy halves to 25 BTC, GPU miners cease to be profitable without significant fees
1339 2012-06-01 23:13:07 <ciscoftw> ascii ftw?
1340 2012-06-01 23:13:14 <luke-jr> it seems reasonable that some (many?) of those miners are trying hard to encourage fees to build up by then, so they don't go out of business
1341 2012-06-01 23:13:37 <ciscoftw> thanx for your input too luke-jr/gmaxwell
1342 2012-06-01 23:14:00 Turingi has quit (Read error: Connection reset by peer)
1343 2012-06-01 23:14:36 danbri has joined
1344 2012-06-01 23:14:39 <luke-jr> also, for a more concrete example on risks: Eligius has been crashing lately when there are a lot of txns to process
1345 2012-06-01 23:14:54 <luke-jr> (I'm working on fixing it, of course)
1346 2012-06-01 23:15:16 erle- has quit (Quit: erle-)
1347 2012-06-01 23:15:23 hnz has quit ()
1348 2012-06-01 23:15:46 erle- has joined
1349 2012-06-01 23:15:46 erle- has quit (Client Quit)
1350 2012-06-01 23:16:24 danbri has quit (Remote host closed the connection)
1351 2012-06-01 23:17:26 <luke-jr> and to get a feel for the level of spam, hang out in #bitcoin-watch for a few days ;)
1352 2012-06-01 23:18:05 <sipa> BlueMatt: that's pretty much what i was thinking about
1353 2012-06-01 23:19:03 <sipa> BlueMatt: though connecting to multiple hubs is overkill imho, and it is not only a listener
1354 2012-06-01 23:21:19 <sipa> luke-jr: it probably comtains the entire allocated region of virtual memory
1355 2012-06-01 23:21:52 <sipa> doesn't mean that all of it belongs (or belonged) to the working set at some point
1356 2012-06-01 23:21:54 <luke-jr> probably
1357 2012-06-01 23:25:51 sacredchao has joined
1358 2012-06-01 23:27:41 agricocb has joined
1359 2012-06-01 23:29:02 <BlueMatt> sipa: oops, calling it Listener was stupid, yea
1360 2012-06-01 23:29:04 <BlueMatt> sipa: multiple hubs is probably overkill, yea, but why not support it, its not like its extra code
1361 2012-06-01 23:29:08 <BlueMatt> what if I dont trust any of the blockstores and want to connect to 5 untrusted network proxy hubs?
1362 2012-06-01 23:29:10 <BlueMatt>  obviously thats no where near supported atm
1363 2012-06-01 23:29:47 ciscoftw has quit ()
1364 2012-06-01 23:31:07 rdponticelli has quit (Ping timeout: 245 seconds)
1365 2012-06-01 23:33:28 Apexseals has joined
1366 2012-06-01 23:33:49 copumpkin has quit (Quit: Computer has gone to sleep.)
1367 2012-06-01 23:35:35 <sipa> BlueMatt: then you connect the hub to 5 network nodes :)
1368 2012-06-01 23:35:46 <sipa> will certainly be more efficieny
1369 2012-06-01 23:36:38 salitron has joined
1370 2012-06-01 23:37:34 <BlueMatt> sipa: I was thinking I dont wanna run a hub, I connect to 5 web-service hubs that I only marginally trust
1371 2012-06-01 23:37:46 <sipa> right
1372 2012-06-01 23:37:58 <BlueMatt> oh, you mean run 1 hub connected to 5 network blockstores or?
1373 2012-06-01 23:38:29 <sipa> not really, as hub is really a job queue for (one) blockstore for now
1374 2012-06-01 23:39:37 <BlueMatt> thats my point?
1375 2012-06-01 23:40:08 <gmaxwell> you've now spent more time talking about it then it would take to switch from one behavior to the other in the future. :)
1376 2012-06-01 23:40:23 <BlueMatt> gmaxwell: Im coding in the background...
1377 2012-06-01 23:40:40 <sipa> yes, so: no that was not what i was talking about, and that does indeed sound like a reasonable though very futuristic use case
1378 2012-06-01 23:40:44 <gmaxwell> (I agree with bluematt's notion of the future where you might have one wallet talking to multiple blockstores in the future— but there is so much code between then and now that I don't think it matters much)
1379 2012-06-01 23:40:55 <sipa> agree
1380 2012-06-01 23:41:28 <BlueMatt> alright, Ill remove the set for now, doesnt matter in the slightest to me
1381 2012-06-01 23:41:28 <sipa> maybe rather for reliability than for reason of trust
1382 2012-06-01 23:42:08 <sipa> since the hub communication isn't really intended to be used in an untrusted environment
1383 2012-06-01 23:42:29 <BlueMatt> yea, thats probably a better use-case
1384 2012-06-01 23:43:20 <luke-jr> maybe require under 20ms latency to hub, just to prevent public hubs?
1385 2012-06-01 23:43:26 <sipa> though i think there you rather want a failoverproxyhub than multihub support in the wallet
1386 2012-06-01 23:44:03 <sipa> luke-jr: right now, hubs are c++ interfaces and not a network protocol, so that's not really a problem :p
1387 2012-06-01 23:44:03 <gmaxwell> an important use case is semi-trusted. E.g. a VPS provider runs one blockstore, multiple wallets connect. Zero trust isn't relevant because the vps provider could still root you... but you don't want gratuitous insecurity.
1388 2012-06-01 23:44:08 <luke-jr> (by "require" I mean "force users to manually set a commandline/config option to override it")
1389 2012-06-01 23:44:16 <luke-jr> sipa: ah, true :P
1390 2012-06-01 23:44:56 <sipa> gmaxwell: good point
1391 2012-06-01 23:46:17 osmosis has quit (Quit: Leaving)
1392 2012-06-01 23:46:42 <sipa> i was thinking
1393 2012-06-01 23:47:00 <sipa> what if my crawler wouldn't only request getaddr's
1394 2012-06-01 23:47:17 <sipa> but also push some addr's to nodes it connects to
1395 2012-06-01 23:47:51 <gmaxwell> seems like a prudent payment for the cost of being crawled in fact.
1396 2012-06-01 23:48:32 <sipa> nice thing: it adds free seeding capability to onion nodes
1397 2012-06-01 23:49:00 <gmaxwell> How so?
1398 2012-06-01 23:49:02 <sipa> bad thing: it only works for nodes that are known to be reachable, so who don't really need it
1399 2012-06-01 23:49:13 <gmaxwell> Right. okay.
1400 2012-06-01 23:49:33 <luke-jr> XD
1401 2012-06-01 23:51:01 <gmaxwell> I think it's generally a fine idea. Along those lines, nodes doing the node hopping thing in the future should probably prefer to relay the nodes they just disconnected.  "Sorry it didn't work out, but I'll set you up on a date with my friend!"
1402 2012-06-01 23:51:26 <sipa> gmaxwell: good idea
1403 2012-06-01 23:52:40 copumpkin has joined
1404 2012-06-01 23:53:00 da2ce7 has quit (Read error: Connection reset by peer)
1405 2012-06-01 23:54:06 <sipa> i'd also to like the seeder reachable via P2P (though disconnecting after sending addr's, or silence of 10s)
1406 2012-06-01 23:54:35 da2ce7 has joined
1407 2012-06-01 23:55:34 <sipa> DoS is then just about the corner, probably though
1408 2012-06-01 23:58:29 rdponticelli has joined