1 2012-06-13 00:04:05 <luke-jr> Db::get: Cannot allocate memory
   2 2012-06-13 00:04:10 <luke-jr> I have plenty of memory :/
   3 2012-06-13 00:06:54 BitByBit has joined
   4 2012-06-13 00:08:08 BitByBit has quit (Client Quit)
   5 2012-06-13 00:15:35 null_radix has quit (Ping timeout: 256 seconds)
   6 2012-06-13 00:19:39 JZavala has joined
   7 2012-06-13 00:26:34 t7 has quit (Quit: ChatZilla 0.9.88.2 [Firefox 13.0/20120601045813])
   8 2012-06-13 00:26:42 da2ce710 has joined
   9 2012-06-13 00:28:31 da2ce7 has quit (Ping timeout: 240 seconds)
  10 2012-06-13 00:30:25 toffoo has joined
  11 2012-06-13 00:32:18 Turingi has quit (Read error: Connection reset by peer)
  12 2012-06-13 00:34:30 midnightmagic has joined
  13 2012-06-13 00:38:25 maaku has quit (Quit: maaku)
  14 2012-06-13 00:39:01 mmoya has quit (Ping timeout: 240 seconds)
  15 2012-06-13 00:40:34 tyn has joined
  16 2012-06-13 00:40:34 tyn has quit (Client Quit)
  17 2012-06-13 00:47:20 minimoose has joined
  18 2012-06-13 00:55:36 knotwork has quit (Read error: Connection reset by peer)
  19 2012-06-13 01:13:33 Aetitiae_ has quit (Quit: Leaving)
  20 2012-06-13 01:13:38 null_radix has joined
  21 2012-06-13 01:14:16 Zarutian has joined
  22 2012-06-13 01:17:43 rdponticelli has quit (Ping timeout: 244 seconds)
  23 2012-06-13 01:23:25 DaQatz has quit (Ping timeout: 245 seconds)
  24 2012-06-13 01:27:19 DaQatz has joined
  25 2012-06-13 01:28:08 agricocb has joined
  26 2012-06-13 01:28:19 <luke-jr> sipa: is there any harm in setting bdb max locks/objects higher to reorg leaps without d68dcf7?
  27 2012-06-13 01:30:35 DaQatz_ has joined
  28 2012-06-13 01:34:38 rdponticelli has joined
  29 2012-06-13 01:34:51 brwyatt is now known as brwyatt|Away
  30 2012-06-13 01:44:04 skeledrew1 has quit (Quit: Instantbird 1.2a1pre -- http://www.instantbird.com)
  31 2012-06-13 01:44:34 skeledrew has joined
  32 2012-06-13 01:55:24 imsaguy has quit ()
  33 2012-06-13 02:00:07 brwyatt is now known as Away!~brwyatt@pool-71-244-54-5.dllstx.fios.verizon.net|brwyatt
  34 2012-06-13 02:11:20 <bayleef> And of course, another bitcoind on another network gave not but a passing glance at block 176948 before admitting it. Was kinda hoping it wouldn't work
  35 2012-06-13 02:11:27 rdponticelli has quit (Ping timeout: 244 seconds)
  36 2012-06-13 02:13:55 m00p has quit (Ping timeout: 244 seconds)
  37 2012-06-13 02:16:24 <bayleef> wonder what would happen if I deleted the blockchain, and resynched it just from that one machine
  38 2012-06-13 02:20:05 chao has joined
  39 2012-06-13 02:20:14 chao has quit (Client Quit)
  40 2012-06-13 02:21:12 <luke-jr> bayleef:
  41 2012-06-13 02:21:13 <luke-jr> ?
  42 2012-06-13 02:24:08 imsaguy has joined
  43 2012-06-13 02:25:07 <bayleef> luke-jr: I have a server, just stuck bitcoind 0.6.2 on it and watched it go right on past the block I'm stuck on.
  44 2012-06-13 02:25:21 <luke-jr> bayleef: what version do you use?
  45 2012-06-13 02:26:23 <bayleef> locally I've tried with 0.6.0, 0.6.2 and latest from bitcoin master. Currently on master
  46 2012-06-13 02:27:13 one_zero has joined
  47 2012-06-13 02:31:12 knotwork has joined
  48 2012-06-13 02:34:01 JZavala has quit (Ping timeout: 240 seconds)
  49 2012-06-13 02:34:25 llama has joined
  50 2012-06-13 02:35:35 llama has quit (Client Quit)
  51 2012-06-13 02:35:54 llama has joined
  52 2012-06-13 02:38:43 llama has quit (Client Quit)
  53 2012-06-13 02:44:17 minimoose has quit (Quit: minimoose)
  54 2012-06-13 02:45:29 da2ce710 is now known as da2ce7
  55 2012-06-13 02:46:24 [7] has quit (Disconnected by services)
  56 2012-06-13 02:46:30 TheSeven has joined
  57 2012-06-13 02:48:31 Guest9804 is now known as jarpiain
  58 2012-06-13 02:53:52 Cory has quit (Ping timeout: 252 seconds)
  59 2012-06-13 02:54:25 Cory has joined
  60 2012-06-13 02:58:11 m00p has joined
  61 2012-06-13 03:07:26 Z0rZ0rZ0r has quit (Ping timeout: 245 seconds)
  62 2012-06-13 03:08:05 Z0rZ0rZ0r has joined
  63 2012-06-13 03:12:20 eoss has quit (Remote host closed the connection)
  64 2012-06-13 03:14:38 maaku has joined
  65 2012-06-13 03:29:48 skeledrew1 has joined
  66 2012-06-13 03:30:18 Tycale has quit (Read error: Operation timed out)
  67 2012-06-13 03:31:05 skeledrew has quit (Ping timeout: 256 seconds)
  68 2012-06-13 03:31:39 xorgate has quit (Ping timeout: 256 seconds)
  69 2012-06-13 03:31:49 xorgate has joined
  70 2012-06-13 03:32:13 phungi has quit (Ping timeout: 256 seconds)
  71 2012-06-13 03:32:43 phungi has joined
  72 2012-06-13 03:32:48 Internet13 has quit (Ping timeout: 256 seconds)
  73 2012-06-13 03:32:48 BGL has quit (Ping timeout: 256 seconds)
  74 2012-06-13 03:33:25 Tycale has joined
  75 2012-06-13 03:36:22 Internet13 has joined
  76 2012-06-13 03:37:05 coblee has quit (Remote host closed the connection)
  77 2012-06-13 03:37:26 coblee has joined
  78 2012-06-13 03:44:26 eoss has joined
  79 2012-06-13 03:44:26 eoss has quit (Changing host)
  80 2012-06-13 03:44:26 eoss has joined
  81 2012-06-13 03:44:30 eoss has quit (Read error: Connection reset by peer)
  82 2012-06-13 03:51:22 Tycale has quit (Read error: Operation timed out)
  83 2012-06-13 03:54:05 BGL has joined
  84 2012-06-13 03:54:59 Tycale has joined
  85 2012-06-13 03:57:58 maaku has left ("wIRC")
  86 2012-06-13 03:58:22 minimoose has joined
  87 2012-06-13 03:59:36 _flow_ has quit (Ping timeout: 248 seconds)
  88 2012-06-13 04:03:03 sytse has quit (Ping timeout: 272 seconds)
  89 2012-06-13 04:04:37 sytse has joined
  90 2012-06-13 04:06:42 RainbowDashh has joined
  91 2012-06-13 04:08:06 _flow_ has joined
  92 2012-06-13 04:10:03 fpgaminer has quit (Remote host closed the connection)
  93 2012-06-13 04:10:20 fpgaminer has joined
  94 2012-06-13 04:10:35 RainbowDashh has quit (Client Quit)
  95 2012-06-13 04:10:42 Zarutian has quit (Quit: Zarutian)
  96 2012-06-13 04:15:37 mologie has quit (Ping timeout: 245 seconds)
  97 2012-06-13 04:16:32 mologie has joined
  98 2012-06-13 04:18:34 imsaguy has quit (Ping timeout: 244 seconds)
  99 2012-06-13 04:27:11 imsaguy has joined
 100 2012-06-13 04:27:18 brocktice has joined
 101 2012-06-13 04:27:18 brocktice has quit (Changing host)
 102 2012-06-13 04:27:18 brocktice has joined
 103 2012-06-13 04:29:48 fpgaminer has quit (Remote host closed the connection)
 104 2012-06-13 04:30:10 fpgaminer has joined
 105 2012-06-13 04:38:43 fpgaminer has quit (Read error: Connection reset by peer)
 106 2012-06-13 04:40:13 Hasbro has quit (Ping timeout: 256 seconds)
 107 2012-06-13 04:40:14 fpgaminer has joined
 108 2012-06-13 04:46:10 OneFixt has quit (Read error: Connection reset by peer)
 109 2012-06-13 04:50:37 OneFixt has joined
 110 2012-06-13 04:55:03 OneFixt_ has joined
 111 2012-06-13 04:55:31 OneFixt has quit (Ping timeout: 256 seconds)
 112 2012-06-13 04:58:59 OneFixt_ is now known as OneFixt
 113 2012-06-13 05:06:15 Zarutian has joined
 114 2012-06-13 05:08:33 da2ce7 has quit (Ping timeout: 256 seconds)
 115 2012-06-13 05:13:03 egecko has quit (Ping timeout: 276 seconds)
 116 2012-06-13 05:19:39 Cory has quit (Read error: Connection reset by peer)
 117 2012-06-13 05:23:00 Detritus has quit (Read error: Operation timed out)
 118 2012-06-13 05:23:06 da2ce7 has joined
 119 2012-06-13 05:23:39 Cory has joined
 120 2012-06-13 05:25:23 m00p has quit (Quit: Leaving)
 121 2012-06-13 05:27:52 da2ce7 has quit (Ping timeout: 252 seconds)
 122 2012-06-13 05:44:39 Zarutian has quit (Quit: Zarutian)
 123 2012-06-13 05:47:18 null_radix has quit (Ping timeout: 252 seconds)
 124 2012-06-13 05:51:32 RazielZ has joined
 125 2012-06-13 05:52:20 da2ce7 has joined
 126 2012-06-13 05:58:02 minimoose has quit (Quit: minimoose)
 127 2012-06-13 06:00:21 Apexseals has quit (Ping timeout: 244 seconds)
 128 2012-06-13 06:03:00 ovidiusoft has joined
 129 2012-06-13 06:16:30 D34TH has quit (Quit: Brains on Keyboard)
 130 2012-06-13 06:28:49 bayleef has quit (Ping timeout: 248 seconds)
 131 2012-06-13 06:40:28 meLon has quit (Ping timeout: 252 seconds)
 132 2012-06-13 06:41:31 kjj_ has quit (Ping timeout: 240 seconds)
 133 2012-06-13 06:46:49 brwyatt is now known as brwyatt|Away
 134 2012-06-13 06:48:03 meLon has joined
 135 2012-06-13 06:48:03 meLon has quit (Changing host)
 136 2012-06-13 06:48:03 meLon has joined
 137 2012-06-13 06:50:57 Z0rZ0rZ0r has quit (Quit: Leaving)
 138 2012-06-13 06:55:15 kjj_ has joined
 139 2012-06-13 06:55:44 random_cat__ has quit (Remote host closed the connection)
 140 2012-06-13 06:56:57 random_cat__ has joined
 141 2012-06-13 07:01:23 Joric has joined
 142 2012-06-13 07:01:23 Joric has quit (Changing host)
 143 2012-06-13 07:01:23 Joric has joined
 144 2012-06-13 07:05:31 Detritus has joined
 145 2012-06-13 07:07:11 erle- has joined
 146 2012-06-13 07:08:45 random_cat__ has quit (Ping timeout: 276 seconds)
 147 2012-06-13 07:09:54 random_cat__ has joined
 148 2012-06-13 07:12:00 gfinn has quit (Ping timeout: 276 seconds)
 149 2012-06-13 07:17:31 yellowhat has joined
 150 2012-06-13 07:22:52 frirden has quit (Read error: Connection reset by peer)
 151 2012-06-13 07:24:20 gfinn has joined
 152 2012-06-13 07:24:57 gjs278 has quit (Remote host closed the connection)
 153 2012-06-13 07:25:26 gjs278 has joined
 154 2012-06-13 07:43:36 _flow_ has quit (Ping timeout: 248 seconds)
 155 2012-06-13 07:50:51 gjs278 has quit (Remote host closed the connection)
 156 2012-06-13 07:51:51 _flow_ has joined
 157 2012-06-13 07:52:18 gjs278 has joined
 158 2012-06-13 07:53:07 _flow_ has quit (Excess Flood)
 159 2012-06-13 07:54:24 _flow_ has joined
 160 2012-06-13 07:56:37 copumpkin has quit (Ping timeout: 245 seconds)
 161 2012-06-13 07:57:10 copumpkin has joined
 162 2012-06-13 08:01:28 OneFixt_ has joined
 163 2012-06-13 08:01:58 OneFixt has quit (Ping timeout: 256 seconds)
 164 2012-06-13 08:02:59 t7 has joined
 165 2012-06-13 08:06:17 OneFixt_ is now known as OneFixt
 166 2012-06-13 08:14:07 molecular has quit (Ping timeout: 245 seconds)
 167 2012-06-13 08:14:24 molecular has joined
 168 2012-06-13 08:39:40 MobiusL has quit (Remote host closed the connection)
 169 2012-06-13 08:40:49 MobiusL has joined
 170 2012-06-13 08:46:53 Motest031 has joined
 171 2012-06-13 08:47:14 Motest003 has quit (Ping timeout: 265 seconds)
 172 2012-06-13 08:48:12 MBS has quit (Ping timeout: 276 seconds)
 173 2012-06-13 08:49:16 hnz has quit (Ping timeout: 245 seconds)
 174 2012-06-13 08:54:10 hnz has joined
 175 2012-06-13 09:00:11 t7 has quit (Ping timeout: 252 seconds)
 176 2012-06-13 09:03:07 kjj_ has quit (Read error: Operation timed out)
 177 2012-06-13 09:05:50 ThomasV has joined
 178 2012-06-13 09:06:30 Guest56545 has joined
 179 2012-06-13 09:09:54 kjj_ has joined
 180 2012-06-13 09:17:25 hnz has quit (Ping timeout: 246 seconds)
 181 2012-06-13 09:18:00 _flow_ has quit (Ping timeout: 248 seconds)
 182 2012-06-13 09:22:45 hnz has joined
 183 2012-06-13 09:24:18 _flow_ has joined
 184 2012-06-13 09:24:49 tower has quit (Ping timeout: 248 seconds)
 185 2012-06-13 09:26:17 Apexseals has joined
 186 2012-06-13 09:26:34 tower has joined
 187 2012-06-13 09:30:31 Apexseals has quit (Ping timeout: 244 seconds)
 188 2012-06-13 09:33:27 drizztbsd has joined
 189 2012-06-13 09:42:22 da2ce794 has joined
 190 2012-06-13 09:43:27 da2ce7 has quit (Ping timeout: 252 seconds)
 191 2012-06-13 09:50:13 one_zero has quit ()
 192 2012-06-13 09:51:22 lukys has joined
 193 2012-06-13 09:52:11 <lukys> Is there any way I can change the working directory of Bitcoin-qt?
 194 2012-06-13 09:52:12 iBrutus has joined
 195 2012-06-13 09:53:49 <sipa> lukys: -datadir=x
 196 2012-06-13 09:54:12 iBrutus has left ()
 197 2012-06-13 09:55:02 <lukys> Of course. It only just occurred to me to use the terminal.
 198 2012-06-13 09:56:47 <lukys> Does that set it permanently?
 199 2012-06-13 09:58:12 <sipa> no
 200 2012-06-13 09:59:14 ThomasV has quit (Quit: Leaving)
 201 2012-06-13 10:01:53 <lukys> Well, I'll add the argument to the launcher then, but is there no way I can set it permanently in the config file or anything?
 202 2012-06-13 10:02:15 <lukys> I don't have the space on this filesystem.
 203 2012-06-13 10:03:20 <sipa> yes, you can set it permanently using datadir=X in ~/.bitcoin/bitcoin.conf
 204 2012-06-13 10:04:01 datagutt has joined
 205 2012-06-13 10:06:52 <lukys> When I've set that, I presume it's then safe to delete the wallet and everything else from the original directory?
 206 2012-06-13 10:07:00 <lukys> Apart from the config files.
 207 2012-06-13 10:07:01 <SomeoneWeird> no
 208 2012-06-13 10:07:05 <SomeoneWeird> dont delete your wallet
 209 2012-06-13 10:07:16 <SomeoneWeird> you'll lose all yours coins then
 210 2012-06-13 10:07:28 <lukys> But the wallet is in the new directory.
 211 2012-06-13 10:07:36 <SomeoneWeird> did you copy it over?
 212 2012-06-13 10:07:43 <SomeoneWeird> like, the exact same one?
 213 2012-06-13 10:07:54 <lukys> It copied automatically when I set the new directory.
 214 2012-06-13 10:08:14 <SomeoneWeird> it might've created a new one
 215 2012-06-13 10:08:20 <SomeoneWeird> not sure, you'll have to check
 216 2012-06-13 10:08:27 <SomeoneWeird> but i wouldn't delete it quite yet
 217 2012-06-13 10:09:01 <sipa> it created a new one
 218 2012-06-13 10:09:25 <lukys> Hmm, interesting. The new wallet is 73.7 kB, whereas the old one is 49.2 kB.
 219 2012-06-13 10:09:29 <SomeoneWeird> yep
 220 2012-06-13 10:09:41 <sipa> bdb has strange ways
 221 2012-06-13 10:09:43 <SomeoneWeird> so, copy the old one and overwrite the new one (backup the new one if you want to)
 222 2012-06-13 10:10:06 gfinn has quit (Ping timeout: 276 seconds)
 223 2012-06-13 10:10:39 <sipa> it certainly did not copy anything
 224 2012-06-13 10:14:45 <lukys> Ok, copied and deleted old files.
 225 2012-06-13 10:17:01 <lukys> Just so you know, I don't have any coins yet, so this is all safe for the moment.
 226 2012-06-13 10:23:57 xorgate has quit (Read error: Connection reset by peer)
 227 2012-06-13 10:25:21 xorgate has joined
 228 2012-06-13 10:25:43 gfinn has joined
 229 2012-06-13 10:26:03 superjames has quit (Remote host closed the connection)
 230 2012-06-13 10:32:19 sirk390 has joined
 231 2012-06-13 10:38:46 xorgate has quit (Quit: Take it easy)
 232 2012-06-13 10:40:39 xorgate has joined
 233 2012-06-13 10:57:35 t7 has joined
 234 2012-06-13 10:58:05 RainbowDashh has joined
 235 2012-06-13 11:05:06 superjames has joined
 236 2012-06-13 11:15:31 imsaguy has quit (Ping timeout: 240 seconds)
 237 2012-06-13 11:17:17 imsaguy has joined
 238 2012-06-13 11:19:13 sgornick has quit (Quit: Ex-Chat)
 239 2012-06-13 11:19:43 pickett has quit (Remote host closed the connection)
 240 2012-06-13 11:25:25 rdponticelli has joined
 241 2012-06-13 11:26:24 pickett has joined
 242 2012-06-13 11:45:38 username57913 has quit (Ping timeout: 246 seconds)
 243 2012-06-13 11:48:33 egecko has joined
 244 2012-06-13 11:49:56 username57913 has joined
 245 2012-06-13 11:52:50 Maccer has quit (Ping timeout: 265 seconds)
 246 2012-06-13 11:53:37 Zarutian has joined
 247 2012-06-13 11:58:50 _Fireball has joined
 248 2012-06-13 12:06:44 ThomasV has joined
 249 2012-06-13 12:08:25 lukys has quit (Ping timeout: 245 seconds)
 250 2012-06-13 12:09:31 agricocb has quit (Quit: Leaving.)
 251 2012-06-13 12:13:01 torsthaldo has joined
 252 2012-06-13 12:15:37 O2made has quit (Ping timeout: 252 seconds)
 253 2012-06-13 12:17:45 da2ce794 is now known as da2ce7
 254 2012-06-13 12:19:46 O2made has joined
 255 2012-06-13 12:32:29 minimoose has joined
 256 2012-06-13 12:33:48 PiZZaMaN2K has joined
 257 2012-06-13 12:35:05 banshee12 has joined
 258 2012-06-13 12:51:32 erle- has quit (Quit: erle-)
 259 2012-06-13 12:54:12 setkeh has quit (Read error: No route to host)
 260 2012-06-13 12:54:49 setkeh has joined
 261 2012-06-13 12:59:27 p0s has joined
 262 2012-06-13 13:00:03 sacredchao has quit (Disconnected by services)
 263 2012-06-13 13:00:25 tower is now known as tow
 264 2012-06-13 13:00:34 tow is now known as toweros
 265 2012-06-13 13:00:53 toweros is now known as t0w
 266 2012-06-13 13:01:28 t0w is now known as rewot
 267 2012-06-13 13:01:53 rewot is now known as twr
 268 2012-06-13 13:02:08 twr is now known as XYRCE
 269 2012-06-13 13:02:20 XYRCE is now known as again
 270 2012-06-13 13:02:33 again is now known as xepace
 271 2012-06-13 13:02:57 xepace is now known as yebok
 272 2012-06-13 13:03:10 yebok is now known as abtower
 273 2012-06-13 13:03:17 abtower is now known as tower
 274 2012-06-13 13:05:56 phantomcircuit has quit (Ping timeout: 245 seconds)
 275 2012-06-13 13:06:18 Facefox has quit (Ping timeout: 250 seconds)
 276 2012-06-13 13:06:43 agricocb has joined
 277 2012-06-13 13:07:38 Facefox has joined
 278 2012-06-13 13:07:39 Facefox has quit (Max SendQ exceeded)
 279 2012-06-13 13:08:08 Facefox has joined
 280 2012-06-13 13:08:09 Facefox has quit (Max SendQ exceeded)
 281 2012-06-13 13:08:39 phantomcircuit has joined
 282 2012-06-13 13:09:14 Facefox has joined
 283 2012-06-13 13:09:15 Facefox has quit (Max SendQ exceeded)
 284 2012-06-13 13:09:42 Facefox has joined
 285 2012-06-13 13:09:43 Facefox has quit (Max SendQ exceeded)
 286 2012-06-13 13:10:49 Facefox has joined
 287 2012-06-13 13:10:50 Facefox has quit (Max SendQ exceeded)
 288 2012-06-13 13:11:21 Facefox has joined
 289 2012-06-13 13:18:51 Eleuthria has joined
 290 2012-06-13 13:18:58 Eleuthria has left ()
 291 2012-06-13 13:21:18 ahihi2 has quit ()
 292 2012-06-13 13:21:40 Guest56545 is now known as MBS
 293 2012-06-13 13:21:46 MBS has quit (Changing host)
 294 2012-06-13 13:21:46 MBS has joined
 295 2012-06-13 13:21:55 ahihi2 has joined
 296 2012-06-13 13:24:10 OneFixt_ has joined
 297 2012-06-13 13:25:22 <jgarzik> so, stupid question
 298 2012-06-13 13:25:31 <jgarzik> sipa: where is CTxDestination defined?
 299 2012-06-13 13:26:07 OneFixt has quit (Ping timeout: 256 seconds)
 300 2012-06-13 13:26:38 tcatm has quit (Quit: No Ping reply in 180 seconds.)
 301 2012-06-13 13:26:47 <sipa> jgarzik: script.h
 302 2012-06-13 13:26:54 tcatm has joined
 303 2012-06-13 13:27:08 tcatm has quit (Changing host)
 304 2012-06-13 13:27:08 tcatm has joined
 305 2012-06-13 13:28:07 OneFixt_ is now known as OneFixt
 306 2012-06-13 13:30:22 <jgarzik> sipa: where did CBitcoinAddress::GetHash160 go?
 307 2012-06-13 13:31:15 <sipa> jgarzik: decode it, and get the hash from the CTxDestination
 308 2012-06-13 13:32:31 <jgarzik> sipa: I have what is returned from ExtractDestinations()...  so a list of CTxDestination.  how to get hash160 from each of those?
 309 2012-06-13 13:32:32 <sipa> oh, you can use GetKeyID directly
 310 2012-06-13 13:33:18 <sipa> if the string encodes a key id instead of a destination
 311 2012-06-13 13:33:30 [Tycho] has joined
 312 2012-06-13 13:33:53 <sipa> the few times where there was actual need to write cases for each of the destinations i used a visitor
 313 2012-06-13 13:34:51 <jgarzik> sipa: see FilterMatchTxOut(), https://github.com/bitcoin/bitcoin/pull/1386/files
 314 2012-06-13 13:34:58 <jgarzik> sipa: have to rewrite that
 315 2012-06-13 13:35:00 gfinn has quit (Remote host closed the connection)
 316 2012-06-13 13:35:30 bost has joined
 317 2012-06-13 13:35:49 <bost> hi
 318 2012-06-13 13:35:50 <sipa> jgarzik: i wonder if it isn't better to write a filter that filters the hash of the scriptOut directory
 319 2012-06-13 13:35:51 <jgarzik> sipa: it grabs possible match data from the CTxOut, and scans for matches
 320 2012-06-13 13:35:58 <sipa> jgarzik: without trying to decide it for addresses
 321 2012-06-13 13:36:25 <sipa> the other way around is easier: you can still specify an address to match on, turn that into a script, and add its hash to the filter
 322 2012-06-13 13:36:49 <sipa> s/directory/directly/
 323 2012-06-13 13:37:00 <sipa> s/decide/decode/
 324 2012-06-13 13:37:13 t7_ has joined
 325 2012-06-13 13:37:20 <bost> guys 'bout a 15 minutes ago I launched 'bitcoind -upgradewallet' but the process is still not finished...
 326 2012-06-13 13:37:26 <jgarzik> sipa: well the main use cases are (a) watching for activity on a bitcoin address or (b) watching for activity on a script hash.  I'm not sure the current code even gets (a) correct...  what is the best way to do (a) in current codebase?
 327 2012-06-13 13:37:28 <bost> do you have any idea why?
 328 2012-06-13 13:37:44 <sipa> bost: it should be instantaneous
 329 2012-06-13 13:37:48 <jgarzik> "current code" == #filter, "current codebase" == #master, to be clear
 330 2012-06-13 13:37:54 <jgarzik> that was a bit confusing
 331 2012-06-13 13:37:56 <sipa> bost: but you won't see any output from that
 332 2012-06-13 13:38:03 <bost> sipa: yea, I expected the same
 333 2012-06-13 13:38:07 sacredchao has joined
 334 2012-06-13 13:38:10 <bost> sipa: but... :(
 335 2012-06-13 13:38:15 <sipa> bost: how do you infer it hasn't finished?
 336 2012-06-13 13:38:20 sacredchao is now known as chao
 337 2012-06-13 13:38:59 <sipa> jgarzik: would my suggestion not cover all cases, and be more efficient as well?
 338 2012-06-13 13:39:04 imsaguy is now known as [\\\]
 339 2012-06-13 13:39:09 t7 has quit (Ping timeout: 256 seconds)
 340 2012-06-13 13:39:12 [\\\] is now known as [\\\\\\\\\\\\\\]
 341 2012-06-13 13:39:12 <bost> bost@desktop-64:~$ ps -ef | grep bitcoin
 342 2012-06-13 13:39:13 <bost> bost     12301  2074  2 14:55 pts/1    00:01:09 /usr/lib/bitcoin/bitcoind -upgradewallet
 343 2012-06-13 13:39:22 <sipa> bost: it doesn't exit after upgrading
 344 2012-06-13 13:39:28 <sipa> bost: it just does that at startup
 345 2012-06-13 13:40:05 [\\\\\\\\\\\\\\] is now known as \_\_\
 346 2012-06-13 13:40:09 <bost> sipa: ?? it exits at startup ?? what means that? is't it a contradiction?
 347 2012-06-13 13:40:10 \_\_\ is now known as `0
 348 2012-06-13 13:40:13 `0 is now known as imsaguy
 349 2012-06-13 13:40:32 p0s has quit (Remote host closed the connection)
 350 2012-06-13 13:40:32 <sipa> bost: -upgradewallet just means you allow bitcoin to upgrade the wallet to the latest format
 351 2012-06-13 13:40:43 <sipa> bost: for the rest it just runs the bitcoin daemon as usual
 352 2012-06-13 13:40:55 <bost> sipa: oh, you mean it simply stops before doing the job, right?
 353 2012-06-13 13:40:59 <sipa> no
 354 2012-06-13 13:41:14 <sipa> it just upgrades the wallet and then continues whatever it would do if -upgradewallet wasn't specified
 355 2012-06-13 13:41:33 <sipa> jgarzik: address -> script is easy; script -> address requires using extractaddresses; so i'd say just match on the scriptPubKey's hash in your bloom filter
 356 2012-06-13 13:41:57 <sipa> jgarzik: and when someone asks for a match on a particular address, turn that address into a scriptPubKey, hash it, and add that to your filter
 357 2012-06-13 13:41:59 <bost> sipa: uff! so it means the upgrade went (hopefully) ok, and now it just runs, right?
 358 2012-06-13 13:42:06 <sipa> bost: yes
 359 2012-06-13 13:42:24 <sipa> bost: the upgrade really is just writing "wallet version is X" really
 360 2012-06-13 13:42:31 * bost grrrrrr! :( whata meaningfull behaviour
 361 2012-06-13 13:42:46 chao has left ()
 362 2012-06-13 13:42:52 t7_ has quit (Ping timeout: 245 seconds)
 363 2012-06-13 13:42:57 <sipa> is it unclear? the help says "upgrade wallet at startup" - it doesn't say it will exit after upgrading
 364 2012-06-13 13:43:20 <sipa> use getinfo if you want to see whether it's running
 365 2012-06-13 13:43:36 <jgarzik> sipa: the filter must do both
 366 2012-06-13 13:43:46 <jgarzik> sipa: the first when adding hashes to the filter, and the second when matching
 367 2012-06-13 13:44:06 <sipa> jgarzik: under "address" i understand both pubkeyhash addresses and scripthash addresses
 368 2012-06-13 13:44:07 <jgarzik> sipa: the branch no longer builds due to the Extract* changes
 369 2012-06-13 13:44:09 <bost> sipa: uhm.. it's like with taking credit 1.000.000 $
 370 2012-06-13 13:44:23 <sipa> jgarzik: i don't see the problem
 371 2012-06-13 13:44:29 TD has joined
 372 2012-06-13 13:44:31 <jgarzik> sipa: your idea is fine, but does not address the build problem
 373 2012-06-13 13:44:36 <bost> sipe: and then just to say 'but I didnt say I gonna pay it back'
 374 2012-06-13 13:44:41 Maccer has joined
 375 2012-06-13 13:44:46 <sipa> jgarzik: it would mean you don't call extractaddresses at all
 376 2012-06-13 13:44:59 <jgarzik> sipa: the match must extract hashes somehow from the script
 377 2012-06-13 13:45:00 <sipa> jgarzik: you just do Hash(scriptPubKey) and match on that
 378 2012-06-13 13:45:14 * bost just reads an article about Greece
 379 2012-06-13 13:45:27 phantomcircuit has quit (Ping timeout: 265 seconds)
 380 2012-06-13 13:45:31 <sipa> the script's hash != the script's destination (which also happens to be a hash)
 381 2012-06-13 13:45:40 <jgarzik> clearly
 382 2012-06-13 13:47:30 <bost> sipa: ok, thank you anyway
 383 2012-06-13 13:48:20 <sipa> jgarzik: not sure if you're with me now, or if there's something i'm missing?
 384 2012-06-13 13:49:28 Diapolo has joined
 385 2012-06-13 13:51:00 phantomcircuit has joined
 386 2012-06-13 13:51:58 sacredchao has joined
 387 2012-06-13 13:56:26 null_radix has joined
 388 2012-06-13 13:58:49 copumpkin has quit (Quit: Computer has gone to sleep.)
 389 2012-06-13 13:58:51 _Fireball has quit (Quit:  HydraIRC -> http://www.hydrairc.com <- Like it?  Visit #hydrairc on EFNet)
 390 2012-06-13 14:01:20 talpan has joined
 391 2012-06-13 14:04:32 gavinandresen has joined
 392 2012-06-13 14:06:40 <gavinandresen> Anybody willing to help me make up my mind on a 'signrawtx' RCP call detail?  sipa or gmaxwell ?
 393 2012-06-13 14:06:42 Zarutian has quit (Quit: Zarutian)
 394 2012-06-13 14:07:17 <sipa> gavinandresen: i'll have a look
 395 2012-06-13 14:07:46 <gavinandresen> Cool, here's what I'm waffling over:  You've got   signrawtx "hex-encoded serialized transaction to be partially signed"
 396 2012-06-13 14:08:10 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 397 2012-06-13 14:08:18 <gavinandresen> (sorry, interrupted...)
 398 2012-06-13 14:08:56 <sipa> remind me: could you start from an unsigned raw tx, add a signature for the last txin, and then add signatures for the previous txins?
 399 2012-06-13 14:09:26 <sipa> or does the signing replace-magic require the earlier txins?
 400 2012-06-13 14:09:27 <gavinandresen> signrawtx adds as many signatures as it can
 401 2012-06-13 14:09:54 <gavinandresen> If you call it twice, it'll replace earlier signatures it made with new ones
 402 2012-06-13 14:10:11 <kinlo> will it submit the transaction too?
 403 2012-06-13 14:10:13 <gavinandresen> (or if you had the same private key in two wallets)
 404 2012-06-13 14:10:19 <sipa> i'm just talking about the message signature semantics
 405 2012-06-13 14:10:19 <gavinandresen> No, sendrawtx sends it
 406 2012-06-13 14:10:23 <kinlo> good
 407 2012-06-13 14:10:31 <sipa> not about signrawtx now
 408 2012-06-13 14:10:42 <kinlo> I'd really like commands to do just one command and one command only
 409 2012-06-13 14:11:01 <gavinandresen> sipa: hmm?
 410 2012-06-13 14:11:32 <sipa> gavinandresen: i remember the hash being signed is calculated from some post-processed version of the serialized transaction
 411 2012-06-13 14:11:45 <sipa> gavinandresen: what i'm wondering about is whether the signatures depend on one another
 412 2012-06-13 14:12:28 <gavinandresen> No, the scriptSig's for the transaction being signed are cleared, and the one being signed is replaced by the previous scriptPubKey to compute the hash
 413 2012-06-13 14:12:45 <sipa> ok, good
 414 2012-06-13 14:13:00 <gavinandresen> And that actually gets to what I'm waffling over
 415 2012-06-13 14:13:01 <sipa> so it's even independent from the other txins entirely
 416 2012-06-13 14:13:05 <sipa> ?
 417 2012-06-13 14:13:20 <sipa> oh, no, only the scriptSigs are cleared
 418 2012-06-13 14:13:25 <sipa> pity
 419 2012-06-13 14:13:36 <gavinandresen> So:  imagine you've created a raw transaction that depends on another transaction that isn't yet in the blockchain
 420 2012-06-13 14:13:52 UukGoblin has quit (Changing host)
 421 2012-06-13 14:13:52 UukGoblin has joined
 422 2012-06-13 14:14:08 <sipa> right, i suppose the serialization would need to contain its dependencies?
 423 2012-06-13 14:14:15 <gavinandresen> sipa:  other stuff is cleared for signature hash modes, I'm concentrating on SIGHASH_ALL right now....
 424 2012-06-13 14:14:22 <sipa> right
 425 2012-06-13 14:14:26 <sipa> ok, go on
 426 2012-06-13 14:15:05 <gavinandresen> So, I want signrawtx to be:   signrawtx  "hex of tx being signed"   [ "previous transaction", "previous transcation" ]
 427 2012-06-13 14:15:32 <gavinandresen> In other words, you can pass in the previous transactions in case bitcoind doesn't know about them yet (because they're not in the blockchain or are other, not-yet-sent raw txns)
 428 2012-06-13 14:16:03 <gavinandresen> The question is what the format of that second param should be.  Easiest might be to just have the full, previous raw transaction
 429 2012-06-13 14:16:24 <gavinandresen> ... but that's more data than is strictly necessary.  You really just need to know   (hash, output, scriptPubKey)
 430 2012-06-13 14:16:37 <kinlo> no intermediate format like bip 10 describes?
 431 2012-06-13 14:17:01 <gavinandresen> kinlo: in the RPC interface?  No, why would we write more possibly-buggy code for Yet Another Encoding?
 432 2012-06-13 14:17:46 <sipa> hmmm
 433 2012-06-13 14:17:49 <kinlo> I feel there is a place for some kind of generic transaction format that can be used in many places
 434 2012-06-13 14:18:09 copumpkin has joined
 435 2012-06-13 14:18:14 <gavinandresen> kinlo: okey doke, feel free to build that on top of the RPC interface
 436 2012-06-13 14:18:20 <sipa> i agree there, actually; but let's talk about that later
 437 2012-06-13 14:18:56 <sipa> so, assume i have in my wallet a transaction that is not in the blockchain
 438 2012-06-13 14:19:07 <sipa> i want to create a raw transaction that spends one of its outputs
 439 2012-06-13 14:19:28 <sipa> i believe there should be an interface that gives both the created raw transaction, plus its unconfirmed dependencies
 440 2012-06-13 14:19:53 <gavinandresen> yup.  ./bitcoind gettransaction <txid>     .... gets you .... stuff.... but not the entire raw tx.
 441 2012-06-13 14:20:28 <sipa> sec, brb
 442 2012-06-13 14:20:38 sacredchao has quit (Remote host closed the connection)
 443 2012-06-13 14:20:50 Turingi has joined
 444 2012-06-13 14:20:50 Turingi has quit (Changing host)
 445 2012-06-13 14:20:50 Turingi has joined
 446 2012-06-13 14:21:07 sacredchao has joined
 447 2012-06-13 14:24:22 <jgarzik> sipa: sorry, had to disappear due to baby, in middle of conversation.  poo-us interruptus
 448 2012-06-13 14:24:28 <gavinandresen> For reference:  https://gist.github.com/2839617    (Proposed listunspent / createrawtx / signrawtx / sendrawtx commands, I've implemented list/create, am in the middle if sign)
 449 2012-06-13 14:25:10 bost has left ("ERC Version 5.3 (IRC client for Emacs)")
 450 2012-06-13 14:25:11 <jgarzik> Let me first ask the audience the dumb question, to verify my knowledge:  is the following the standard transaction most often used?   OP_DUP OP_HASH160 b5cd7aaed869cd5ccb45868e8666e7e934a23736 OP_EQUALVERIFY OP_CHECKSIG  And what is that a hash of?
 451 2012-06-13 14:25:30 <gavinandresen> yes.  Hash of the full public key
 452 2012-06-13 14:25:32 phantomcircuit has quit (Ping timeout: 244 seconds)
 453 2012-06-13 14:26:10 <sipa> that hex value is the hex encoding of the 160-bit hash of the public key, which is also encoded in base58 in the normal address that corresponds to that key
 454 2012-06-13 14:26:12 Prattler has joined
 455 2012-06-13 14:26:15 <gavinandresen> That hash is different from the transaction id (hash of the entire transaction) and different yet again from the hash used by OP_CHECKSIG
 456 2012-06-13 14:26:36 phantomcircuit has joined
 457 2012-06-13 14:27:28 <sipa> gavinandresen: just a short comment; if you're creating such a low-level interface, i feel you should have the ability to add arbitrary txout scripts (not just those that have well-defined addresses)
 458 2012-06-13 14:27:50 Maccer has quit (Ping timeout: 246 seconds)
 459 2012-06-13 14:27:58 <gavinandresen> sipa: sure, but the signrawtx won't know how to sign non-standard inputs
 460 2012-06-13 14:28:20 <jgarzik> I just want to make sure the filter is properly matching on p2sh destination or bitcoin address destination, and nothing else
 461 2012-06-13 14:28:26 <luke-jr> gavinandresen: maybe a generic interface to get any data at all signed?
 462 2012-06-13 14:28:36 <gavinandresen> sipa:  it will leave non-standard inputs, or inputs that it doesn't have previous transactions for, alone.
 463 2012-06-13 14:28:47 <sipa> gavinandresen: it's your responsibility to only add outputs that the other party understands
 464 2012-06-13 14:28:50 * jgarzik is trying to figure out gavinandresen's OP_CHECKSIG comment in the pull req (and here)
 465 2012-06-13 14:29:10 <jgarzik> vis a vis code and sipa's comments
 466 2012-06-13 14:29:11 <gavinandresen> jgarzik: which pull request?
 467 2012-06-13 14:29:15 <jgarzik> gavinandresen: filter*
 468 2012-06-13 14:29:15 Zarutian has joined
 469 2012-06-13 14:29:28 <sipa> jgarzik: why only match those two? you'll run into troubles when another address type is added which doesn't have a nicely-packaged 160-bit value in it
 470 2012-06-13 14:29:38 <luke-jr> gavinandresen: your interface supports adding inputs that the client doesn't have in its wallet, no?
 471 2012-06-13 14:29:47 Diapolo has left ()
 472 2012-06-13 14:29:56 <sipa> just matching on the scriptPubKey's hash is easier, faster and more flexible
 473 2012-06-13 14:30:22 <sipa> luke-jr: i suppose those are supposed to already be in the raw transaction?
 474 2012-06-13 14:31:33 <gavinandresen> (catching up, page-swapping the filter* RPC stuff into my brain....)
 475 2012-06-13 14:32:59 <gavinandresen> luke-jr: sure, createrawtx creates inputs by refererring to (txid, n), so as long as you know the previous transactions txid ....
 476 2012-06-13 14:34:36 <gavinandresen> jgarzik:  RE: filter:   my comment was just that if somebody used the uncommon <pubkey> OP_CHECKSIG form of transaction then the filter* API can't trigger when it is spent.
 477 2012-06-13 14:35:32 <gavinandresen> jgarzik: that's probably OK... although <pubkey> OP_CHECKSIG is the common form for coinbase transactions, so if you want to trigger when you spend generated coins you'd be out of luck.
 478 2012-06-13 14:35:41 sacredchao has quit (Quit: leaving)
 479 2012-06-13 14:35:46 <sipa> my point is this: addresses are in essence a shorthand notation for a particular subset of scriptPubKey's
 480 2012-06-13 14:36:03 <sipa> i believe the receiver is always the one who gets to decide which scriptPubKey is used for payments to him
 481 2012-06-13 14:36:11 sacredchao has joined
 482 2012-06-13 14:36:23 <sipa> so it shouldn't be a problem to just match on the scriptPubKey directly
 483 2012-06-13 14:36:52 <sipa> if someone wants to be informed about payments to a particular address, just expand that address to its corresponding scriptPubKey, and add that to your filter rule set
 484 2012-06-13 14:37:26 <gavinandresen> sipa:  but the filter won't trigger if you pay to DUP HASH160 <hash> ....
 485 2012-06-13 14:37:37 <gavinandresen> ... because the scriptPubKey isn't revealed until the spend
 486 2012-06-13 14:37:46 <gavinandresen> excuse me, the full pubkey
 487 2012-06-13 14:37:55 <sipa> i'm not talking about the pubkey
 488 2012-06-13 14:38:06 <sipa> s/scriptPubKey/the script in the txout/
 489 2012-06-13 14:38:20 <gavinandresen> Sorry, misinterpreted
 490 2012-06-13 14:38:49 <sipa> if you accept payments to you using some weird non-standard script, and your payers and miners have no problem with that, no problem
 491 2012-06-13 14:39:02 <gavinandresen> I think in general people will want to be informed of payments both to AND from
 492 2012-06-13 14:39:09 <sipa> sure, sure
 493 2012-06-13 14:39:20 <sipa> i was just simplifying to just send case here
 494 2012-06-13 14:39:51 darkskiez has joined
 495 2012-06-13 14:39:52 darkskiez has quit (Changing host)
 496 2012-06-13 14:39:52 darkskiez has joined
 497 2012-06-13 14:40:57 <sipa> gavinandresen: could your createrawtx be used to not specify any txin at all (or too few txins for the specified output) ?
 498 2012-06-13 14:41:02 phantomcircuit has quit (Ping timeout: 244 seconds)
 499 2012-06-13 14:41:16 <ThomasV> 0.6.2 does not seem to delete old unprocessed transactions from its memory pool..
 500 2012-06-13 14:41:17 <jgarzik> sipa: I am fine with filter matching based on Hash(scriptPubKey)
 501 2012-06-13 14:41:17 <luke-jr> gavinandresen: FWIW, the BIP16 backports bugged on block 178118; I found the fix in the original OP_EVAL commit >_<
 502 2012-06-13 14:41:31 <jgarzik> sipa: but it is a user interface issue, that some users will want to say "filter <bitcoinaddress>"
 503 2012-06-13 14:41:46 <luke-jr> (the semantics of IsPushOnly changed: the older clients checked the 200 byte size in there too!)
 504 2012-06-13 14:41:47 <gavinandresen> luke-jr: could you send me email about that?
 505 2012-06-13 14:41:49 <jgarzik> so maybe we need 'filteraddhash' and 'filteraddaddress'
 506 2012-06-13 14:41:53 <sipa> jgarzik: so, when they do, you expand that address into a script, hash it, and add it to the filter set
 507 2012-06-13 14:41:56 <luke-jr> gavinandresen: sure
 508 2012-06-13 14:42:00 <jgarzik> and 'filteraddaddress' would generate scripts
 509 2012-06-13 14:42:04 <jgarzik> and add their hashes
 510 2012-06-13 14:42:17 <jgarzik> 'filteraddhash' just directly adds the hash
 511 2012-06-13 14:42:21 <ThomasV> bitcoincharts's list of unprocessed transactions shows "There are 8976 unconfirmed transactions "
 512 2012-06-13 14:42:29 <ThomasV> is that normal?
 513 2012-06-13 14:42:43 <ThomasV> I am having the same issue with my own bitcoind
 514 2012-06-13 14:42:53 <ThomasV> about 6000 tx after a few days
 515 2012-06-13 14:42:59 <sipa> jgarzik: or even filteraddscript (filteraddscripthash is more flexible, but you can't accept funds to unknown scripts anyway)
 516 2012-06-13 14:43:59 <jgarzik> sipa: I think if they can generate a script, they can do the hash
 517 2012-06-13 14:44:06 <sipa> agree
 518 2012-06-13 14:44:15 <jgarzik> sipa: OTOH, a formal bitcoin address is most likely to be available to dumb, text-based programs
 519 2012-06-13 14:44:25 <sipa> jgarzik: i think the UI/RPC implementation can safely be limited to just filteraddaddress for now
 520 2012-06-13 14:44:38 <jgarzik> hmmm, ok
 521 2012-06-13 14:45:07 <gavinandresen> ... but filteraddaddress won't detect spends FROM that address, will it?
 522 2012-06-13 14:45:21 <jgarzik> gavinandresen: it looks at CTxOut
 523 2012-06-13 14:45:24 <ThomasV> tcatm: ping
 524 2012-06-13 14:45:38 <gavinandresen> jgarzik: previous transaction's CTxOut ?
 525 2012-06-13 14:45:53 <jgarzik> gavinandresen: no, just current tx's CTxOut.
 526 2012-06-13 14:46:03 <sipa> i don't like the phrase "from an address" ;)
 527 2012-06-13 14:46:17 <gavinandresen> Right, current tx's CTxOut is only where the funds are going, not where they're from
 528 2012-06-13 14:46:59 <jgarzik> block logic: for each tx { for each txout { check for match } }
 529 2012-06-13 14:47:08 <jgarzik> obvious reduction, for TX memory pool match check
 530 2012-06-13 14:47:30 t7 has joined
 531 2012-06-13 14:47:34 <gavinandresen> It doesn't just match against the entire serialized transaction ?
 532 2012-06-13 14:47:51 <gavinandresen> (can I match against the txins ?)
 533 2012-06-13 14:48:46 <sipa> if you want to observe spends from things that are yours, i think you want a trigger generated by your wallet when one of its coins gets marked spent
 534 2012-06-13 14:49:13 Detritus has quit (Quit: Konversation terminated!)
 535 2012-06-13 14:49:29 Detritus has joined
 536 2012-06-13 14:49:46 <sipa> rather than a manual check on spends from particular addresses - that's logic wallets already have
 537 2012-06-13 14:49:46 <gavinandresen> If it matched against the entire transaction, then I could filter on the txid and get triggered when any output of that txid was spent
 538 2012-06-13 14:50:37 <gavinandresen> (because the txins are (txid, n, scriptSig))
 539 2012-06-13 14:50:47 rdponticelli_ has joined
 540 2012-06-13 14:50:57 <sipa> right, but if you want that you'll need special cases for all potential matches
 541 2012-06-13 14:51:07 <sipa> as the bloom filter needs a hash to lookup
 542 2012-06-13 14:51:16 rdponticelli has quit (Read error: Connection reset by peer)
 543 2012-06-13 14:51:29 <sipa> so you need to extract data from the serialized tx, hash it, and ask the filter for a match
 544 2012-06-13 14:51:40 <sipa> i think only a few things are worth matching for
 545 2012-06-13 14:52:02 <gavinandresen> ah, right.....
 546 2012-06-13 14:52:37 <sipa> but matching on an txid sounds like a useful extension
 547 2012-06-13 14:52:37 <gavinandresen> I forgot it's not full matching
 548 2012-06-13 14:52:59 <sipa> but far less useful than matching on a txout script
 549 2012-06-13 14:54:22 <jgarzik> hmmm
 550 2012-06-13 14:54:33 <gavinandresen> ok, I like filteraddaddress.     Maybe filteraddtxid  later
 551 2012-06-13 14:54:52 <jgarzik> people might use txid match for exchanging offline/OOB transactions, indeed
 552 2012-06-13 14:55:09 <ThomasV> can someone please enlighten me? the memory pool of my bitcoind seems to keep growing day after day
 553 2012-06-13 14:55:22 <jgarzik> I think filteraddhash, too.  it is easy to do, and can be used by power users
 554 2012-06-13 14:55:25 <ThomasV> is that normal?
 555 2012-06-13 14:55:41 Maccer has joined
 556 2012-06-13 14:55:44 <sipa> ThomasV: satoshidice...?
 557 2012-06-13 14:56:09 <gavinandresen> ThomasV: either satoshidice or somebody might be mounting a slow "try to fill up your memory" attack.  Restarting will flush the pool.
 558 2012-06-13 14:56:33 <gavinandresen> ThomasV: ... or git HEAD has code to keep the pool from growing forever
 559 2012-06-13 14:56:47 <ThomasV> what is new in git head?
 560 2012-06-13 14:57:28 <ThomasV> I don't think I am a target for attack
 561 2012-06-13 14:57:47 gfinn has joined
 562 2012-06-13 14:57:47 <gavinandresen> IPv6 support, gettransaction showing non-wallet transactions, debug console in the GUI (right?), bug fixes....
 563 2012-06-13 14:58:05 * luke-jr wonders if bitcoind needs a -miner option to disable things that only miners care about (like the memorypool)
 564 2012-06-13 14:58:12 <ThomasV> and satoshi dice tx eventually make it in the chain, so there's no reason to have 6000 of them in the mempool
 565 2012-06-13 14:58:36 <sipa> ThomasV: they tend to create very long chains of unconfirmed transactions
 566 2012-06-13 14:58:45 <sipa> luke-jr: the memory pool is useful for non-miner!
 567 2012-06-13 14:58:57 <luke-jr> sipa: is it?
 568 2012-06-13 14:59:27 <sipa> well, maybe not actually
 569 2012-06-13 14:59:33 <ThomasV> gavinandresen: I mean, what is the specific change that keeps the pool from growing? what was changed?
 570 2012-06-13 14:59:41 <ThomasV> how was it addressed?
 571 2012-06-13 14:59:50 fpgaminer has quit (Remote host closed the connection)
 572 2012-06-13 15:00:07 fpgaminer has joined
 573 2012-06-13 15:00:15 <sipa> luke-jr: i wanted to say observing 0-conf transactions
 574 2012-06-13 15:00:16 <gavinandresen> There's now a maximum pool size, and a random transaction is evicted from the pool to make room if that maximum is hit
 575 2012-06-13 15:00:34 <luke-jr> sipa: ok, that's a corner case that could use -miner :p
 576 2012-06-13 15:00:36 rdponticelli_ is now known as rdponticelli
 577 2012-06-13 15:00:38 <ThomasV> how much is the max?
 578 2012-06-13 15:00:47 <sipa> luke-jr: but it's not even true
 579 2012-06-13 15:01:09 <sipa> gavinandresen: i wonder, do we evict depending transactions in the memory pool too?
 580 2012-06-13 15:01:15 <ThomasV> why not evict the older tx?
 581 2012-06-13 15:01:21 <gavinandresen> static const unsigned int MAX_ORPHAN_TRANSACTIONS = MAX_BLOCK_SIZE/100;
 582 2012-06-13 15:01:21 RainbowDashh has quit (Ping timeout: 252 seconds)
 583 2012-06-13 15:02:07 <gribble> New news from bitcoinrss: sgaltsev opened issue 1447 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1447>
 584 2012-06-13 15:02:13 <gavinandresen> ThomasV: random makes it harder for an attacker to manipulate the pool for some attack
 585 2012-06-13 15:02:27 <ThomasV> ic
 586 2012-06-13 15:02:58 RainbowDashh has joined
 587 2012-06-13 15:03:02 <gavinandresen> No memory pool if you're not mining is an interesting idea....
 588 2012-06-13 15:03:20 <luke-jr> gavinandresen: I share sipa's concern about evicting transactions the new one depends on
 589 2012-06-13 15:03:35 * jgarzik of course argues that TXs in memory pool that fail to make it into the chain after X blocks (144 *2, or so) should be dropped, thereby capping age
 590 2012-06-13 15:03:54 <gavinandresen> wait, hang on, memory pool != orphan pool ....
 591 2012-06-13 15:04:10 <sipa> oh
 592 2012-06-13 15:04:24 <ThomasV> I would think that 144*2 is indeed long enough
 593 2012-06-13 15:05:51 <gavinandresen> yeah, strike everything I just said
 594 2012-06-13 15:05:59 <ThomasV> k
 595 2012-06-13 15:06:14 phantomcircuit has joined
 596 2012-06-13 15:07:22 <gavinandresen> Size of the mempool is limited only by transaction fees and the "free transaction rate limiter"
 597 2012-06-13 15:07:41 <ThomasV> what's that?
 598 2012-06-13 15:08:04 <TD> jgarzik: this is the RPCs you are adding for bloom filtering?
 599 2012-06-13 15:08:09 * TD tries to catch up
 600 2012-06-13 15:08:24 <TD> jgarzik: are you going to add p2p protocol commands for filtering connections too? we need that for the last chunk of SPV client scalability work
 601 2012-06-13 15:08:36 <gavinandresen> -limitfreerelay option will limit the number of "free" (less than MIN_RELAY_TX_FEE) transactions added to the pool or relayed to other peers
 602 2012-06-13 15:09:13 <jgarzik> TD: not sure what you mean
 603 2012-06-13 15:09:53 <TD> jgarzik: you were talking about what to filter on (tx outs, etc)
 604 2012-06-13 15:09:54 <jgarzik> TD: yeah, 'filter{addaddress,clear,clearall}' is for bloom filtering, matching on CTxOut (or, proposed, txid)
 605 2012-06-13 15:09:54 <sipa> jgarzik: the ability to tell a peer "only send me transactions that interact with scripts/addresses in <bloom data>"
 606 2012-06-13 15:10:08 <TD> jgarzik: right but are these RPCs or p2p commands or both?
 607 2012-06-13 15:10:17 <jgarzik> sipa: c.f. "filtering connections"
 608 2012-06-13 15:10:23 <jgarzik> TD: RPCs
 609 2012-06-13 15:10:29 <TD> jgarzik: what about txins? otherwise you cannot find transactions that spend your own coins
 610 2012-06-13 15:10:41 <TD> ok. would it be much harder to add p2p support too?
 611 2012-06-13 15:10:41 <jgarzik> TD: gavinandresen raised that point, yes
 612 2012-06-13 15:10:47 <ThomasV> that does not sound like a strong constraint
 613 2012-06-13 15:10:49 <TD> ok great. now i'm caught up :)
 614 2012-06-13 15:11:02 <sipa> right, for the connection filtering you also need matching on prevout's scripts
 615 2012-06-13 15:11:21 <sipa> for RPC notifications, maybe there are better solutions
 616 2012-06-13 15:11:24 <jgarzik> ahhhh, connection between txs
 617 2012-06-13 15:11:32 <jgarzik> I thought TD meant network connections via TCP/IP
 618 2012-06-13 15:11:34 <TD> it might be easier to match on txins rather than txouts
 619 2012-06-13 15:11:43 <TD> jgarzik: i do. for mobile clients, i don't want to download whole blocks
 620 2012-06-13 15:11:58 <TD> jgarzik: but rather get sent a header + filtered transactions + merkle branches linking them to the header, based on a filter
 621 2012-06-13 15:11:59 <sipa> TD: you mean filtering based on prevout txid's, basically?
 622 2012-06-13 15:12:20 <jgarzik> sipa: that's a good idea, hmmm
 623 2012-06-13 15:12:29 <TD> sipa: i mean the input scripts. like, i want to say "send me any transaction that contains my public keys in the inputs" as well. filtering on prevtx outs might be equivalent
 624 2012-06-13 15:12:33 <TD> didn't think about it
 625 2012-06-13 15:13:22 <sipa> filtering on prevout txid's is certainly easier than filtering on prevout scripts
 626 2012-06-13 15:13:35 <sipa> as you don't need to have the prevout script present
 627 2012-06-13 15:14:37 <yellowhat> is there any push/callback in the RPC API to be notified of various events? or is it all request-response based?
 628 2012-06-13 15:14:41 phantomcircuit has quit (Ping timeout: 248 seconds)
 629 2012-06-13 15:14:56 <sipa> you could even define some implicit bahaviour that any transaction relayed from the SPV peer gets added to the watch-txid set
 630 2012-06-13 15:15:58 <TD> sipa: but that doesn't help me find transactions spending my keys. i don't know the hashes of the transactions of interest
 631 2012-06-13 15:15:59 <jgarzik> for P2P, you'd want 'filteraddblah', 'filterclear' ... to magically apply to existing P2P commands like getblock/getdata?  or create a new 'getfiltereddata' P2P command?
 632 2012-06-13 15:16:15 <sipa> TD: you have a list of your own 'coins', no?
 633 2012-06-13 15:16:28 <ThomasV> gavinandresen: what is the typical 'steady state' number of tx in a daemon's pool, assuming it's always on?
 634 2012-06-13 15:16:39 <TD> jgarzik: hmm, good question. i guess magically apply. i don't want to hear about broadcast transactions that are irrelevant to me too
 635 2012-06-13 15:17:15 <sipa> TD: if you have a list of your own coins, you know their txids, so you could build an initial bloom filter for those, and send it to the peer
 636 2012-06-13 15:17:25 <TD> sipa: yeah, i guess so, i was thinking in the case where you want to download broadcast transactions whilst still catching up with the chain
 637 2012-06-13 15:17:42 <TD> you know your keys then but not every transaction. at least not right away.
 638 2012-06-13 15:18:02 <sipa> right
 639 2012-06-13 15:18:30 <sipa> everytime you hear about a transaction, if it's a spend to yourself, you'd want to have it retroactively added to the peer's txid filter set
 640 2012-06-13 15:19:09 <gavinandresen> the "catching up" case is definitely the tricky bit
 641 2012-06-13 15:20:30 someone42 has joined
 642 2012-06-13 15:21:18 <jgarzik> create a new mempool P2P command, which serves up the current mempool, and make sure filter* P2P commands apply to it
 643 2012-06-13 15:21:43 <sipa> seems we're going to need matching on prevout scripts anyway
 644 2012-06-13 15:21:58 <gavinandresen> So: bitcoind DOES fetch the previous scriptPubKeys to validate signatures, so matching against them shouldn't be too much of a burden
 645 2012-06-13 15:22:13 <jgarzik> thanks to bdb cache :)
 646 2012-06-13 15:22:28 <sipa> ... hopefully
 647 2012-06-13 15:22:43 <jgarzik> thanks to bdb cache and satoshidice :)  </edit>
 648 2012-06-13 15:22:43 phantomcircuit has joined
 649 2012-06-13 15:23:53 <jgarzik> more seriously, both mempool and block checks, for filtering, already hit the database for TX validation, so it should be already in-cache for both those cases
 650 2012-06-13 15:24:51 <sipa> yes, indeed
 651 2012-06-13 15:25:04 PiZZaMaN2K has quit (Ping timeout: 244 seconds)
 652 2012-06-13 15:25:09 <gavinandresen> Lemme think... if bitcoind was catching up before a checkpoint I don't think it would need to fetch previous transaction scriptPubKeys.
 653 2012-06-13 15:25:34 <sipa> it always needs to fetch the prevout
 654 2012-06-13 15:25:35 <jgarzik> I'm pretty sure filtering is skipped for IBD
 655 2012-06-13 15:25:48 <sipa> as there is no way to know prevout's amount otherwise
 656 2012-06-13 15:25:58 <sipa> even during IBD
 657 2012-06-13 15:27:37 <jgarzik> quick vote on RPC/P2P UI minor issue:  (a) filterclearall or (b) filterclear '*'
 658 2012-06-13 15:27:42 <gavinandresen> sipa: I'd have to stare at the code, but it seems rearranging the valid-transaction-checks and skipping the "ins > outs" check if before a checkpoint could optimize that away
 659 2012-06-13 15:27:50 <jgarzik> filter names are limited to [a-zA-Z0-9_]
 660 2012-06-13 15:28:08 <sipa> gavinandresen: that would speed up block download a lot
 661 2012-06-13 15:28:31 RainbowD_ has joined
 662 2012-06-13 15:28:31 RainbowDashh has quit (Disconnected by services)
 663 2012-06-13 15:28:34 <sipa> jgarzik: i wouldn't use filter names in P2P
 664 2012-06-13 15:28:41 <sipa> for RPC, sure
 665 2012-06-13 15:29:15 <jgarzik> sipa: limit P2P to a single filter?  fair enough
 666 2012-06-13 15:29:20 <gavinandresen> jgarzik: filterclear '*'   is my vote.
 667 2012-06-13 15:29:21 <sipa> jgarzik: hell no
 668 2012-06-13 15:29:27 <wumpus> yellowhat: currently it is all request/response based, async notifications with jsonrpc are not obvious, I guess longpolling would be the simplest
 669 2012-06-13 15:29:38 <jgarzik> sipa: single filter per connection, I mean
 670 2012-06-13 15:29:45 RainbowD_ is now known as RainbowDashh
 671 2012-06-13 15:29:48 <sipa> jgarzik: just send a bloom set
 672 2012-06-13 15:30:19 <jgarzik> sipa: right...  "filter" == "bloom set" here.  does an individual P2P connection get more than one bloom set, like RPC?
 673 2012-06-13 15:30:23 <sipa> i thought that was the point, to be able to compactly represent a filter, without compromising all privacy
 674 2012-06-13 15:30:29 <Diablo-D3> yay bloomfilters
 675 2012-06-13 15:30:31 <sipa> ooh, ok
 676 2012-06-13 15:30:32 <wumpus> just one bloom set of a fixed size... otherwise, the amount of data per connection could be arbitrary
 677 2012-06-13 15:30:35 <Diablo-D3> the stupidest thing ever invented them
 678 2012-06-13 15:30:41 <jgarzik> it can be useful to know _which_ set is matched
 679 2012-06-13 15:30:44 <Diablo-D3> yet Im already using them in lugh
 680 2012-06-13 15:30:49 <jgarzik> but maybe for P2P that is overdesign
 681 2012-06-13 15:30:59 <wumpus> you could check that on your own side
 682 2012-06-13 15:31:12 <sipa> you should always be checking on your side anyway
 683 2012-06-13 15:31:17 <wumpus> right
 684 2012-06-13 15:31:18 <sipa> as bloom filters can have false positives
 685 2012-06-13 15:31:22 <jgarzik> yes
 686 2012-06-13 15:31:33 <Diablo-D3> false positives yes, false negatives no
 687 2012-06-13 15:31:45 <sipa> and fixed size... unsure; ideal bloom filters have 50% of bits set
 688 2012-06-13 15:31:56 <Diablo-D3> sipa: theres a mathematical formula for that
 689 2012-06-13 15:31:57 <sipa> fixed maximum size maybe
 690 2012-06-13 15:32:00 <wumpus> at least severly limited size
 691 2012-06-13 15:32:01 <sipa> Diablo-D3: i know
 692 2012-06-13 15:32:15 <Diablo-D3> I need to fix my bloom filter impl though
 693 2012-06-13 15:32:21 <Diablo-D3> its only setting one bit
 694 2012-06-13 15:32:51 <sipa> i implemented a bloom filter that had a weird extra requirement that you could not set a single bit; you always had to set two subsequent ones
 695 2012-06-13 15:32:59 <sipa> doing the math for that was fun :)
 696 2012-06-13 15:33:50 <TD> jgarzik: yes, being able to read the peers mempool would be awesome
 697 2012-06-13 15:33:59 <yellowhat> i was thinking about bloomfilters - i understand that you could easily check all incoming transactions with them but are there even good data structures to index the existing blockchain for bloom filter queries?
 698 2012-06-13 15:34:01 <TD> jgarzik: but being able to stay connected and only see invs for transactions of interest would also be helpful
 699 2012-06-13 15:34:02 <wumpus> but a fixed size would give the least hassle with memory, no dynamic on the fly allocation based on connection state etc...
 700 2012-06-13 15:34:06 <gavinandresen> http://code.google.com/p/bloom/  looks like a nice implementation, by the way
 701 2012-06-13 15:34:19 <jgarzik> gavinandresen: license probs
 702 2012-06-13 15:34:21 <TD> not the biggest deal right now but in future, it'd help reduce power usage and make bitcoin apps more responsive as they can stay connected to the p2p network permanently
 703 2012-06-13 15:34:22 <jgarzik> IMO
 704 2012-06-13 15:34:26 <TD> (or to aggregating proxies)
 705 2012-06-13 15:34:29 <sipa> bloom filters are not hard to implement
 706 2012-06-13 15:35:03 <sipa> yes, a getmemorypool *P2P* command would be nice
 707 2012-06-13 15:35:13 <sipa> that just replies with a set of invs
 708 2012-06-13 15:36:16 <jgarzik> TD: steps would be (1) sync up blocks, (2) filter* to set up bloom filter (3) getmemorypool P2P command to notice missed TX's [if they pass the filter], and (4) new network TXs are sent as usual [if they pass the filter]
 709 2012-06-13 15:36:19 <jgarzik> sipa: ^^
 710 2012-06-13 15:36:39 <jgarzik> maybe switch #2 and #1 for race reasons
 711 2012-06-13 15:36:50 <wumpus> not hard to implement, however for a project like bitcoin it'd be preferable to use a well-tested implementation, if available with the right license of course
 712 2012-06-13 15:37:12 <sipa> wumpus: if possible, sure
 713 2012-06-13 15:37:13 <gavinandresen> RE: p2p or rpc bloom filters:  are there fixed params for the bloom filters that will work "good enough" for all applications, or do we need to specify the filter params in the p2p/rpc calls?
 714 2012-06-13 15:37:36 Quaix has joined
 715 2012-06-13 15:37:59 RainbowDashh has quit (Quit: Textual IRC Client: www.textualapp.com)
 716 2012-06-13 15:38:01 <jgarzik> well ultimately you are just building the initial size of the filter, after which it is set in stone until reset
 717 2012-06-13 15:38:14 <jgarzik> the bit accuracy etc. falls out from that guesstimate
 718 2012-06-13 15:38:21 RainbowDashh has joined
 719 2012-06-13 15:38:48 <gavinandresen> who is "you" ?  bitcoind or the caller ?
 720 2012-06-13 15:38:49 <sipa> there are two parameters to be decided initially: number of hashes and number of bits in the filter
 721 2012-06-13 15:39:21 <sipa> there exist some sort of cascading bloom filters that are somewhat more dynamic, iirc
 722 2012-06-13 15:39:55 <gavinandresen> I'm looking at the params at http://code.google.com/p/bloom/source/browse/trunk/bloom_filter.hpp    :   projected_element_count and false_positive_probability
 723 2012-06-13 15:40:16 <sipa> right - number of hashes and bits in the filter follow from those
 724 2012-06-13 15:40:33 <wumpus> bloom filter is small, so why not send the entire filter anew on changes instead of trying to make it dynamic
 725 2012-06-13 15:40:35 <gavinandresen> right, I'm just asking whether the caller can set them in the RPC/p2p
 726 2012-06-13 15:40:48 <sipa> i think he should
 727 2012-06-13 15:40:56 <sipa> with a max on the filter size
 728 2012-06-13 15:41:22 gjs278 has quit (Remote host closed the connection)
 729 2012-06-13 15:41:33 <sipa> but depending on whether you have few or many things in the filter, or want low or high false positive chance, the parameters can vary
 730 2012-06-13 15:41:45 gjs278 has joined
 731 2012-06-13 15:41:47 <wumpus> and a max on the number of hashes... I suppose that affects CPU usage?
 732 2012-06-13 15:41:57 <sipa> true
 733 2012-06-13 15:42:07 <sipa> but more hashes is not always better
 734 2012-06-13 15:42:16 <sipa> while a larger filter is
 735 2012-06-13 15:42:18 <wumpus> a server with a large amount of peers might run into problems otherwise, or it might even be used as ddos
 736 2012-06-13 15:42:21 <wumpus> right
 737 2012-06-13 15:43:54 <sipa> but false positive change may be very high in our case
 738 2012-06-13 15:44:12 <sipa> even 50% false positives means only a x2 factor in throughput
 739 2012-06-13 15:45:47 Joric has quit ()
 740 2012-06-13 15:46:34 <yellowhat> i even think the number of hashes should not be a parameter, it should be fixed.
 741 2012-06-13 15:47:51 Hasbro has joined
 742 2012-06-13 15:48:10 <sipa> if we set the filter size to 64KiB
 743 2012-06-13 15:48:37 <sipa> then the optimal number of hashes is 360000 / n, with n the expected number of elements in the set
 744 2012-06-13 15:48:47 <wumpus> if parameters can be fixed, they should be
 745 2012-06-13 15:50:41 <gavinandresen> fewer knobs are better, that's why I asked if there's one set of params that could reasonably handle all the use cases we can think up.
 746 2012-06-13 15:51:36 <TD> jgarzik: LGTM
 747 2012-06-13 15:52:00 <TD> gavinandresen: clients will want to adjust the FP rate themselves for privacy
 748 2012-06-13 15:52:19 <TD> wumpus: checking a bloom filter is very fast
 749 2012-06-13 15:52:28 <TD> wumpus: i don't think it's a DoS risk
 750 2012-06-13 15:52:43 <wumpus> I know, I think they're a great idea for this
 751 2012-06-13 15:52:48 <sipa> it requires N hashes
 752 2012-06-13 15:52:55 <sipa> but those hashes don't need to be cryptographic
 753 2012-06-13 15:54:24 <gavinandresen> TD: agreed, false-positive rate should be exposed
 754 2012-06-13 15:54:39 <sipa> is 64 KiB a reasonable max size for a filter?
 755 2012-06-13 15:55:13 <BlueMatt> TD: is boom FP deterministic? how does FP rate provide privacy?
 756 2012-06-13 15:55:57 <yellowhat> if you send only a small bloom filter you get lots of false positives and the bitcoind does not know which ones you are going to filter client-side
 757 2012-06-13 15:55:58 <TD> BlueMatt: you don't want the peer to know your addresses. so you can make an inaccurate bloom filter and maybe get sent some stuff you don't care about
 758 2012-06-13 15:56:00 <TD> which you throw awy
 759 2012-06-13 15:56:03 <TD> exactly
 760 2012-06-13 15:56:10 <TD> it lets you precisely trade off bandwidth vs privacy
 761 2012-06-13 15:56:22 giftfrosch has joined
 762 2012-06-13 15:56:28 <wumpus> which is very neat
 763 2012-06-13 15:56:30 <TD> for a mobile app, maybe on 3G you pick very precise filters, and when you're on wifi you pick very vague filters
 764 2012-06-13 15:56:39 <sipa> a 64 KiB bloom filter with 300000 elements and 1 hash function has a false positive change of 43%
 765 2012-06-13 15:57:03 <yellowhat> the number of elements = the number of addresses the cleint is interested in, right?
 766 2012-06-13 15:57:04 <jgarzik> I suppose for P2P they are simply uploading a prebuilt filter, yes?
 767 2012-06-13 15:57:05 <TD> 3G is encrypted and heavily NATd already, so realistically the privacy loss is limited to your carrier, who (at this point in time) certainly does not care about bitcoin. on open wifi at a bitcoin conference maybe you do care :)
 768 2012-06-13 15:57:14 <jgarzik> vs. RPC, which exposes individual element addition
 769 2012-06-13 15:57:15 <sipa> note that that is 43% of *all* transactions coming through
 770 2012-06-13 15:57:17 <TD> jgarzik: yeah
 771 2012-06-13 15:57:32 <BlueMatt> TD: obviously, sorry, I clearly dont know how bloom works, give me a few minutes
 772 2012-06-13 15:57:50 <wumpus> the precise filters *themselves* are marginally bigger to send
 773 2012-06-13 15:58:27 <jgarzik> as its a prebuilt filter, that might expose some implementation details, I'm guessing
 774 2012-06-13 15:58:40 <TD> BlueMatt: np. they're a somewhat obscure data structure. i first encountered them when learning about bigtable. before that i'd never heard of them
 775 2012-06-13 15:58:44 <wumpus> just an array of bits
 776 2012-06-13 15:59:39 <BlueMatt> trying to learn about bloom filters while trying to listen to Jamie Dimon testifying isnt easy...
 777 2012-06-13 16:00:01 <TD> BlueMatt: executive summary is this
 778 2012-06-13 16:00:02 <sipa> with a 64 KiB filter and 16 hash functions, you could store up to 10000 elements with negligable FP
 779 2012-06-13 16:00:17 <TD> BlueMatt: a filter is just a large array of bits. you build them up by switching bits on in particular patterns
 780 2012-06-13 16:00:41 <TD> once built, you can in constant time test if an element was inserted into the filter, where "element" is defined by some hash function
 781 2012-06-13 16:00:44 <TD> it can have false positives
 782 2012-06-13 16:00:46 <TD> but not false negative
 783 2012-06-13 16:01:10 <BlueMatt> ahh...ok, so its pretty simple...
 784 2012-06-13 16:01:12 <TD> by choosing the size of the filter and other things, you can select your preferred FP / size tradeoff
 785 2012-06-13 16:01:33 <sipa> but if you have a 64 KiB filter, and want to store 100000 elements, 16 hash functions will kill it
 786 2012-06-13 16:01:45 Karmaon has joined
 787 2012-06-13 16:01:45 Karmaon has quit (Changing host)
 788 2012-06-13 16:01:45 Karmaon has joined
 789 2012-06-13 16:01:51 <TD> eg, BigTable uses them to optimize out disk seeks. to read a bit of data you need to find which file it's in. it could be in one of several tablets. each tablet has a bloom filter associated with it. if you get an FP it means an unneeded disk seek but otherwise it's a fast way to avoid checking every file
 790 2012-06-13 16:02:01 <TD> because the bloom filter can be stored in memory
 791 2012-06-13 16:02:57 <sipa> if you want to store 100k elements in a 64KiB filter, you want only 4 hash functions (8% FP) and not 16 (46% FP)
 792 2012-06-13 16:05:53 <Diablo-D3> hrm
 793 2012-06-13 16:06:02 <Diablo-D3> sipa: btw, more hash functions doesnt improve performance
 794 2012-06-13 16:06:04 <Diablo-D3> you only need two
 795 2012-06-13 16:06:15 <gavinandresen> Seems to me we want two params: false positive rate and expected number of items, and derive everything else from those.  With reasonable limits on those, so I can't say "I'm going to store 10 million items and I want a 0% false positive rate, please"
 796 2012-06-13 16:06:15 <Diablo-D3> and the second one can be an extra weak one that just continues processing from the first one one additional step
 797 2012-06-13 16:07:01 <jgarzik> gavinandresen: the main limit is final allocated size.  you can limit FP rate / number of items via that.
 798 2012-06-13 16:07:17 <gavinandresen> jgarzik: ACK
 799 2012-06-13 16:07:18 <jgarzik> probably just need nitems inside 32-bit integer.
 800 2012-06-13 16:07:30 D34TH has joined
 801 2012-06-13 16:09:03 toffoo has quit ()
 802 2012-06-13 16:09:17 <Diablo-D3> td, blueMatt, sipa: whats the math on a 64 bit filter with 2 functions, how many entries can I have until I hit, say, 50% failure
 803 2012-06-13 16:09:21 <jgarzik> filterinit <nitems> <FP rate from 0.0 to 1.0> ; returns byte (not bit) size, as a verification check
 804 2012-06-13 16:09:28 <jgarzik> filterload <data>
 805 2012-06-13 16:09:41 <jgarzik> filterclear
 806 2012-06-13 16:10:20 <jgarzik> maybe 'filteradd <hash data>' for manual building
 807 2012-06-13 16:12:27 <sipa> Diablo-D3: 64 bit, not kilobit?
 808 2012-06-13 16:12:28 <gavinandresen> jgarzik: ACK.  I think.  what is   the <data> in filterload ?   set of bit-masks, hex-encoded ?
 809 2012-06-13 16:12:45 <jgarzik> bits in the bloom filter
 810 2012-06-13 16:12:58 da2ce708 has joined
 811 2012-06-13 16:13:05 <jgarzik> a big chunk of data (64k as sipa was saying, for example)
 812 2012-06-13 16:13:15 <Diablo-D3> sipa: bit.
 813 2012-06-13 16:13:17 <gribble> New news from bitcoinrss: Diapolo opened pull request 1448 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1448>
 814 2012-06-13 16:13:41 <Diablo-D3> sipa: using only two hashes
 815 2012-06-13 16:14:20 <gavinandresen> jgarzik: right, set of bits, padded to 8-bit-length?   And somewhere the hash functions used will be defined?
 816 2012-06-13 16:14:45 <jgarzik> gavinandresen: yeah they would certainly have to be fixed in stone, for everybody to generate and understand the same data
 817 2012-06-13 16:14:54 <jgarzik> on client and server side both
 818 2012-06-13 16:15:10 <wumpus> yes, better get that decision right in one go :)
 819 2012-06-13 16:15:12 <sipa> i wonder whether setting a nonce to be used for the hash functions is useful
 820 2012-06-13 16:15:33 da2ce7 has quit (Ping timeout: 256 seconds)
 821 2012-06-13 16:16:32 <sipa> Diablo-D3: 1 element: 0.1% FP; 2: 0.4%, 4: 2%, 8: 5%, 16: 15%, 32: 40%
 822 2012-06-13 16:17:15 <Diablo-D3> wow 32? better than I thought
 823 2012-06-13 16:17:17 <sipa> jgarzik: what if the size or hashes limit is reached when filterinit is called?
 824 2012-06-13 16:17:29 <BlueMatt> http://upload.wikimedia.org/wikipedia/commons/e/ef/Bloom_filter_fp_probability.svg
 825 2012-06-13 16:17:40 <sipa> jgarzik: best-effort, or failure?
 826 2012-06-13 16:17:41 <BlueMatt> #bits defined per line, n == numer of items
 827 2012-06-13 16:17:55 <jgarzik> sipa: failure.  client must know how to match server bit-for-bit here.
 828 2012-06-13 16:18:05 <BlueMatt> Diablo-D3: ^
 829 2012-06-13 16:18:08 O2made has quit (Read error: Connection reset by peer)
 830 2012-06-13 16:18:14 <jgarzik> IMHO:)
 831 2012-06-13 16:18:18 <sipa> jgarzik: wow no - the filter itself should encode its parameters
 832 2012-06-13 16:18:35 <sipa> filter init calculation requires floating point math
 833 2012-06-13 16:18:42 <sipa> you cannot expect others to redo that correctly
 834 2012-06-13 16:18:45 <Diablo-D3> p is bits, n is items?
 835 2012-06-13 16:18:51 <jgarzik> sipa: that's why it returns size (see above)
 836 2012-06-13 16:18:54 <BlueMatt> Diablo-D3: p is prob, n is items
 837 2012-06-13 16:18:59 O2made has joined
 838 2012-06-13 16:19:04 <Diablo-D3> oh
 839 2012-06-13 16:19:14 <sipa> jgarzik: not what i mean
 840 2012-06-13 16:19:14 <BlueMatt> Diablo-D3: first line is 8 bits, second 12, third 16...
 841 2012-06-13 16:19:19 <jgarzik> sipa: but given size, client must bit-for-bit create the binary bloom filter bits properly, for loading via filterload
 842 2012-06-13 16:19:19 <Diablo-D3> oh wtf
 843 2012-06-13 16:19:23 <Diablo-D3> that only goes up to 36 bits?!
 844 2012-06-13 16:19:48 <sipa> Diablo-D3: 36 bits filter = half a gigabyte
 845 2012-06-13 16:19:50 <BlueMatt> yea and with 1*10^9 items it has prob < 1*10^-10
 846 2012-06-13 16:19:56 <sipa> Diablo-D3: your use case is 6 bits
 847 2012-06-13 16:20:10 <Diablo-D3> sipa: erm
 848 2012-06-13 16:20:13 <sipa> (it's the size of the *indices* in the table)
 849 2012-06-13 16:20:17 <sipa> not the size of the table
 850 2012-06-13 16:20:22 <Diablo-D3> maybe I described my problem wrong
 851 2012-06-13 16:20:31 <sipa> ok, how large is your filter?
 852 2012-06-13 16:20:47 <Diablo-D3> 2 hashes, filter is 64 bits, input of each item is 64 bits
 853 2012-06-13 16:21:04 <sipa> do you mean the filter data structure uses 64 bits of memory?
 854 2012-06-13 16:21:17 <Diablo-D3> yes, its a uint64_t.
 855 2012-06-13 16:21:35 <sipa> ok, so the indices in your table are 6 bits large
 856 2012-06-13 16:21:58 <sipa> as in, you will calculate a hash, and use the 6 lower bits of that hash to find an entry in the 64-bit vector
 857 2012-06-13 16:22:20 <sipa> jgarzik: the serialized filter should encode its own size, number of hashes, and nonce (maybe)
 858 2012-06-13 16:22:29 <Diablo-D3> sipa: actually, I was %ing that.
 859 2012-06-13 16:22:56 <sipa> jgarzik: if you calculate size and number of hashes from expected number of elements and FP chance, you'll always get rounding errors (obviously)
 860 2012-06-13 16:23:02 <sipa> jgarzik: that's not a problem
 861 2012-06-13 16:23:05 <Diablo-D3> filter |= 1L << (hash % 64)
 862 2012-06-13 16:23:18 <sipa> jgarzik: but after a certain point you cannot approximate the requested parameters anymore
 863 2012-06-13 16:23:40 <sipa> Diablo-D3: yes, m=64 in your case, so log_2(m) is 6
 864 2012-06-13 16:23:48 <Diablo-D3> sipa: ahh, I get it now
 865 2012-06-13 16:23:49 <sipa> Diablo-D3: and k=2
 866 2012-06-13 16:24:08 <Diablo-D3> and also I lied
 867 2012-06-13 16:24:14 <Diablo-D3> 	*filter |= 1L << ((h5 % 32) + 32);
 868 2012-06-13 16:24:14 <Diablo-D3> 	*filter |= 1L << (h6 % 32);
 869 2012-06-13 16:24:16 <Diablo-D3> thats what Im doing
 870 2012-06-13 16:24:27 <sipa> Diablo-D3: don't do that
 871 2012-06-13 16:24:43 <Diablo-D3> why not? it seems to generate far less false positives
 872 2012-06-13 16:24:47 <sipa> using the entire 64 bits for both hashes has better performance
 873 2012-06-13 16:25:30 <sipa> Diablo-D3: you're just implementing two k=1 m=32 filters instead of one k=2 m=64 one
 874 2012-06-13 16:25:47 <sipa> gtg
 875 2012-06-13 16:25:57 <Diablo-D3> with what I wrote, two threads that try to maximally conflict are doing 15-16 million tx/sec on one or two threads
 876 2012-06-13 16:26:23 <Diablo-D3> doing % 64 on both does...
 877 2012-06-13 16:26:46 <Diablo-D3> 15-16 on single thread, 14-15 on two thread
 878 2012-06-13 16:26:53 <Diablo-D3> due to false positives
 879 2012-06-13 16:27:11 <sipa> how many elements do you put in it?
 880 2012-06-13 16:27:16 <Diablo-D3> very few
 881 2012-06-13 16:27:25 <sipa> how many, typically?
 882 2012-06-13 16:27:40 <Diablo-D3> well, lets say Im writing to one memory location in each thread, and I have two cores (ergo two threads)
 883 2012-06-13 16:27:45 <Diablo-D3> thats two items
 884 2012-06-13 16:28:02 TD has quit (Quit: TD)
 885 2012-06-13 16:28:07 <Diablo-D3> so its memory locations * threads running txes at any given moment in that process
 886 2012-06-13 16:28:23 <sipa> you could easily use more hash functions and that would reduce false positives further
 887 2012-06-13 16:28:24 <gribble> New news from bitcoinrss: laanwj opened pull request 1449 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1449>
 888 2012-06-13 16:28:37 <Diablo-D3> yeah, but then I just fill it up with bits
 889 2012-06-13 16:28:43 <sipa> you should
 890 2012-06-13 16:28:52 <sipa> bloom filters work best when they're half full
 891 2012-06-13 16:29:00 <Diablo-D3> yeah, but what if someone breaks out a 64 core machine?
 892 2012-06-13 16:29:12 <Diablo-D3> or writes to a lot of seperate memory locations
 893 2012-06-13 16:29:26 <sipa> then you should use less hash functions
 894 2012-06-13 16:29:31 <Diablo-D3> !#%QEARTFDSVCX
 895 2012-06-13 16:29:32 <gribble> Error: "#%QEARTFDSVCX" is not a valid command.
 896 2012-06-13 16:29:34 <Diablo-D3> but you just said use more!
 897 2012-06-13 16:29:46 <sipa> if you're only putting in two elements, yes, definitely
 898 2012-06-13 16:29:56 <Diablo-D3> I dont know what the user is going to do
 899 2012-06-13 16:30:02 <Diablo-D3> I just know what the typical and worst cases are
 900 2012-06-13 16:30:04 <sipa> the optimal number is 44/n, with n the number of elements in it
 901 2012-06-13 16:30:14 * sipa gone
 902 2012-06-13 16:31:11 ThomasV has quit (Quit: Leaving)
 903 2012-06-13 16:31:34 <Diablo-D3> btw, one hash, 15-16 on single thread, 12 on two :<
 904 2012-06-13 16:34:55 gfinn has quit (Ping timeout: 276 seconds)
 905 2012-06-13 16:38:56 sirk390 has quit (Read error: Connection reset by peer)
 906 2012-06-13 16:40:11 skeledrew1 has quit (Remote host closed the connection)
 907 2012-06-13 16:40:31 skeledrew has joined
 908 2012-06-13 16:41:36 <BlueMatt> is there a bip for bloom filters in p2p, or is someone gonna write one?
 909 2012-06-13 16:41:42 <BlueMatt> jgarzik: I guess?
 910 2012-06-13 16:43:04 sirk390 has joined
 911 2012-06-13 16:43:18 Karmaon has quit (Read error: Connection reset by peer)
 912 2012-06-13 16:43:37 <gribble> New news from bitcoinrss: Diapolo opened pull request 1451 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1451> || Asrael opened issue 1450 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1450>
 913 2012-06-13 16:44:13 PiZZaMaN2K has joined
 914 2012-06-13 16:48:44 <gribble> New news from bitcoinrss: Diapolo opened issue 1452 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1452>
 915 2012-06-13 16:49:31 Ukto has joined
 916 2012-06-13 16:49:51 Ukto is now known as Guest77913
 917 2012-06-13 16:50:28 Guest77913 has quit (Client Quit)
 918 2012-06-13 16:50:38 Guest77913 has joined
 919 2012-06-13 16:53:12 Guest77913 has quit (Client Quit)
 920 2012-06-13 16:53:22 Guest77913 has joined
 921 2012-06-13 16:53:26 Guest77913 is now known as Ukto
 922 2012-06-13 16:54:02 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
 923 2012-06-13 16:56:23 Maccer has quit (Ping timeout: 265 seconds)
 924 2012-06-13 16:57:33 maaku has joined
 925 2012-06-13 16:57:51 <Habbie> hi - my testnet-in-a-box connects to IRC and finds the rest of the testnet, even though irc=0 is set in 1/bitcoin.conf; is this a known issue?
 926 2012-06-13 16:58:19 <Habbie> nevermind - my bitcoin binaries are very old
 927 2012-06-13 17:02:06 [7] has joined
 928 2012-06-13 17:02:11 TheSeven has quit (Disconnected by services)
 929 2012-06-13 17:04:02 RainbowDashh has joined
 930 2012-06-13 17:07:59 DBordello has quit (Quit: ZNC - http://znc.in)
 931 2012-06-13 17:08:07 RainbowDashh has quit (Ping timeout: 246 seconds)
 932 2012-06-13 17:08:45 DBordello has joined
 933 2012-06-13 17:11:08 RainbowDashh has joined
 934 2012-06-13 17:14:14 RainbowDashh has quit (Client Quit)
 935 2012-06-13 17:15:18 upb has quit (Remote host closed the connection)
 936 2012-06-13 17:15:46 upb has joined
 937 2012-06-13 17:15:46 upb has quit (Changing host)
 938 2012-06-13 17:15:46 upb has joined
 939 2012-06-13 17:17:11 Maccer has joined
 940 2012-06-13 17:20:53 upb has quit (Remote host closed the connection)
 941 2012-06-13 17:21:31 upb has joined
 942 2012-06-13 17:21:31 upb has quit (Changing host)
 943 2012-06-13 17:21:31 upb has joined
 944 2012-06-13 17:21:59 t7 has quit (Remote host closed the connection)
 945 2012-06-13 17:25:36 gfinn has joined
 946 2012-06-13 17:27:47 Quaix has quit ()
 947 2012-06-13 17:29:55 Karmaon has joined
 948 2012-06-13 17:31:56 paraipan has quit (Remote host closed the connection)
 949 2012-06-13 17:33:07 paraipan has joined
 950 2012-06-13 17:36:00 <Habbie> my testnet-in-a-box is not generating blocks - i am mining at approx 3 mhash/sec; how often should i expect a block, on average?
 951 2012-06-13 17:36:43 <D34TH> 3 mhash?
 952 2012-06-13 17:36:46 <Habbie> or well, i have one block, that was generated half an hour ago, apparently - but the tx in it is marked immature (obviously)
 953 2012-06-13 17:36:58 dvide has quit ()
 954 2012-06-13 17:37:01 <D34TH> well the network speed is a bit quicker
 955 2012-06-13 17:37:02 <D34TH> so
 956 2012-06-13 17:37:11 <D34TH> if your solo you wont find any
 957 2012-06-13 17:37:31 <Habbie> if i can't find any, what's the point of testnet in a box?
 958 2012-06-13 17:37:42 sgornick has joined
 959 2012-06-13 17:37:49 <Habbie>     "difficulty" : 0.06249911,
 960 2012-06-13 17:37:59 <D34TH> your not synced up
 961 2012-06-13 17:38:07 <Habbie> testnet in a box is not supposed to sync up
 962 2012-06-13 17:38:09 <D34TH> "difficulty":16.0000000,
 963 2012-06-13 17:38:10 upb has quit (Ping timeout: 248 seconds)
 964 2012-06-13 17:38:31 <D34TH> oh your on your own, it will be a while at 3 mh/s
 965 2012-06-13 17:38:41 <Habbie> do you know how to calculate how long?
 966 2012-06-13 17:38:47 upb has joined
 967 2012-06-13 17:38:47 upb has quit (Changing host)
 968 2012-06-13 17:38:47 upb has joined
 969 2012-06-13 17:39:42 <Habbie> according to the online (non-testnet) difficulty calculator i should be getting a block every 1-2 minutes
 970 2012-06-13 17:39:45 <Habbie> obviously, that isn't happening :)
 971 2012-06-13 17:39:53 <D34TH> unlucky?
 972 2012-06-13 17:39:58 <Habbie> could be
 973 2012-06-13 17:40:04 <Habbie> but i've been at it for 30 minutes ;)
 974 2012-06-13 17:41:36 <Habbie> i've done setgenerate true on the daemon now; 1 mhash/sec there
 975 2012-06-13 17:42:06 <Habbie> should yield a block every 5 minutes according to non-testnet rules
 976 2012-06-13 17:46:12 ThomasV has joined
 977 2012-06-13 17:47:15 justmoon has joined
 978 2012-06-13 17:47:15 justmoon has quit (Changing host)
 979 2012-06-13 17:47:15 justmoon has joined
 980 2012-06-13 17:47:17 <Habbie> ah!
 981 2012-06-13 17:47:19 <Habbie> generated a block
 982 2012-06-13 17:47:22 <Habbie> with the 3mhash/sec miner
 983 2012-06-13 17:53:25 Karmaon has quit (Ping timeout: 265 seconds)
 984 2012-06-13 17:53:59 <someone42> does anyone know of any non-testnet blocks which contain P2SH transactions?
 985 2012-06-13 17:58:26 osmosis has joined
 986 2012-06-13 17:59:08 drizztbsd has quit (Remote host closed the connection)
 987 2012-06-13 18:04:03 Maccer has quit (Ping timeout: 265 seconds)
 988 2012-06-13 18:06:08 <luke-jr> someone42: 178118 has one that breaks 0.4 and 0.5
 989 2012-06-13 18:06:47 MobiusL is now known as linuxkernel
 990 2012-06-13 18:07:02 linuxkernel is now known as MobiusL
 991 2012-06-13 18:11:36 rdponticelli_ has joined
 992 2012-06-13 18:12:16 rdponticelli has quit (Ping timeout: 265 seconds)
 993 2012-06-13 18:12:55 MobiusL is now known as linuxkernel
 994 2012-06-13 18:13:08 linuxkernel is now known as MobiusL
 995 2012-06-13 18:15:43 [7] has quit (Disconnected by services)
 996 2012-06-13 18:15:50 TheSeven has joined
 997 2012-06-13 18:22:08 TD has joined
 998 2012-06-13 18:23:11 Maccer has joined
 999 2012-06-13 18:25:13 _flow_ has quit (Ping timeout: 248 seconds)
1000 2012-06-13 18:29:44 _flow_ has joined
1001 2012-06-13 18:32:03 kram__ has joined
1002 2012-06-13 18:32:21 talpan has quit (Quit: Verlassend)
1003 2012-06-13 18:32:42 TD has quit (Quit: TD)
1004 2012-06-13 18:33:21 bayleef has joined
1005 2012-06-13 18:34:03 kram__ has quit (Client Quit)
1006 2012-06-13 18:35:54 mxmxmx has quit (Ping timeout: 260 seconds)
1007 2012-06-13 18:38:23 <someone42> luke-jr: i can't seem to find any P2SH transactions in block 178118
1008 2012-06-13 18:40:02 ForceMajeure has quit (Read error: Connection reset by peer)
1009 2012-06-13 18:40:54 <luke-jr> 177618 sorry
1010 2012-06-13 18:41:02 da2ce708 has quit (Ping timeout: 240 seconds)
1011 2012-06-13 18:41:05 <luke-jr> http://blockchain.info/tx-index/4530401/968a692ab98b1f275c635c76be003ab1db9740d0b62f338b270115342ca42f5b
1012 2012-06-13 18:42:43 rdponticelli_ has quit (Ping timeout: 265 seconds)
1013 2012-06-13 18:43:23 <someone42> thanks
1014 2012-06-13 18:45:25 mtve has quit (Quit: Terminated with extreme prejudice - dircproxy 1.0.5)
1015 2012-06-13 18:47:51 t7 has joined
1016 2012-06-13 18:49:59 mxmxmx has joined
1017 2012-06-13 18:50:49 <Habbie> bah, 120 confirms to mature a block
1018 2012-06-13 18:50:51 <Habbie> this will take a while ;)
1019 2012-06-13 18:53:01 <gavinandresen> Habbie: do you need new blocks?  the first testnet-in-a-box node has a wallet with a few thousand coins in it
1020 2012-06-13 18:58:33 rdponticelli has joined
1021 2012-06-13 19:05:38 datagutt has quit (Quit: kthxbai)
1022 2012-06-13 19:08:12 Joric has joined
1023 2012-06-13 19:08:12 Joric has quit (Changing host)
1024 2012-06-13 19:08:12 Joric has joined
1025 2012-06-13 19:10:41 PK has joined
1026 2012-06-13 19:12:34 m00p has joined
1027 2012-06-13 19:12:47 Karmaon has joined
1028 2012-06-13 19:18:31 MobiusL has quit (Quit: Ex-Chat)
1029 2012-06-13 19:20:10 DaQatz has quit (Quit: leaving)
1030 2012-06-13 19:20:10 DaQatz_ has quit (Quit: leaving)
1031 2012-06-13 19:20:35 DaQatz has joined
1032 2012-06-13 19:20:56 bushing has left ("Leaving...")
1033 2012-06-13 19:22:09 Karmaon has quit (Ping timeout: 246 seconds)
1034 2012-06-13 19:22:24 ssfd has joined
1035 2012-06-13 19:24:55 <ssfd> anyone buying
1036 2012-06-13 19:27:03 Karmaon has joined
1037 2012-06-13 19:27:48 _W_ has quit (Excess Flood)
1038 2012-06-13 19:27:59 _W_ has joined
1039 2012-06-13 19:32:35 erle- has joined
1040 2012-06-13 19:36:32 RazielZ has quit (Ping timeout: 240 seconds)
1041 2012-06-13 19:38:21 RazielZ has joined
1042 2012-06-13 19:38:33 devrandom has quit (Quit: leaving)
1043 2012-06-13 19:39:18 devrandom has joined
1044 2012-06-13 19:41:17 <Habbie> gavinandresen, i downloaded testnet3-box.zip from http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/ and the balance for both datadir=1 and =2 is 0, and the only block i see is the genesis block
1045 2012-06-13 19:41:39 <gavinandresen> Habbie: are you running git HEAD ?
1046 2012-06-13 19:41:52 MobiusL has joined
1047 2012-06-13 19:42:09 <Habbie> gavinandresen, 0.6.2 from the ubuntu ppa
1048 2012-06-13 19:42:31 <gavinandresen> For 0.6.2 you'll need the old testnet-box.zip
1049 2012-06-13 19:42:43 <Habbie> ah!
1050 2012-06-13 19:42:58 <gavinandresen> (we're resetting testnet for the 0.7 release, please excuse the mess)
1051 2012-06-13 19:43:42 <Habbie> that's what testnet is for ;)
1052 2012-06-13 19:44:01 <Habbie> 3650 BTC
1053 2012-06-13 19:44:04 <Habbie> thanks!
1054 2012-06-13 19:46:23 <Habbie> gavinandresen, just for my curiosity, would testnet3-box + git head also have given me a bunch of BTC?
1055 2012-06-13 19:46:33 <gavinandresen> Habbie: yes
1056 2012-06-13 19:46:36 <Habbie> thanks
1057 2012-06-13 19:54:30 Maccer has quit (Excess Flood)
1058 2012-06-13 19:57:57 PK has quit ()
1059 2012-06-13 20:01:27 gavinandresen has quit (Quit: gavinandresen)
1060 2012-06-13 20:14:56 rdponticelli has quit (Ping timeout: 244 seconds)
1061 2012-06-13 20:19:17 <jgarzik> heavy TX day?
1062 2012-06-13 20:19:21 <jgarzik> 2400 tx's in pool right now
1063 2012-06-13 20:20:55 <Joric> fucking satoshidice!
1064 2012-06-13 20:21:07 ForceMajeure has joined
1065 2012-06-13 20:23:45 <sipa> i wonder... i suppose transfer size for bloom filters is more of a problem than memory size?
1066 2012-06-13 20:24:28 <sipa> i believe you can create a very sparsely used filter, but use a compressed encoding
1067 2012-06-13 20:25:52 <BlueMatt> if you're looking for low fp %, Id think so
1068 2012-06-13 20:26:39 <sipa> sounds like a fun experiment :)
1069 2012-06-13 20:26:48 <BlueMatt> but I wouldnt think you always want a low fp % here, 50% or more for some more privacy-conscious clients seems reasonable...
1070 2012-06-13 20:27:09 <sipa> then just use a smaller one
1071 2012-06-13 20:27:20 <sipa> high is strictly easier
1072 2012-06-13 20:27:26 Zarutian has quit (Quit: Zarutian)
1073 2012-06-13 20:27:29 <sipa> high fp, i mean
1074 2012-06-13 20:27:42 <BlueMatt> well Im saying if you use a smaller one, making a fancy encoding scheme isnt worth it
1075 2012-06-13 20:27:59 <sipa> of course
1076 2012-06-13 20:28:13 <sipa> but sometimes you want low fp
1077 2012-06-13 20:28:26 <BlueMatt> and even a fancy encoding scheme may not be worth anything for high fp
1078 2012-06-13 20:28:49 <BlueMatt> though for mobiles (who are probably the ones who will want low fp) saving bw may be worth it...
1079 2012-06-13 20:29:04 Apexseals has joined
1080 2012-06-13 20:29:33 <sipa> my point is this: bloom filters are intended to minimize memory usage, not to minimize an encoded representation of it
1081 2012-06-13 20:30:48 <BlueMatt> yea, for mobiles who want low fp, you may be able to save significant transfer space
1082 2012-06-13 20:32:09 <Habbie> what's fp?
1083 2012-06-13 20:32:14 <sipa> false positive rate
1084 2012-06-13 20:32:15 <BlueMatt> false positive rate
1085 2012-06-13 20:32:48 <sipa> and those who want low fp, are exactly those for whom a small transfer size matters
1086 2012-06-13 20:32:54 <BlueMatt> yep
1087 2012-06-13 20:32:57 <Habbie> ah, right
1088 2012-06-13 20:33:50 <sipa> i have some errands first, but i'll do the math on how small they can theoretically get later
1089 2012-06-13 20:41:12 Maccer has joined
1090 2012-06-13 20:45:40 Motest031 has quit (Ping timeout: 252 seconds)
1091 2012-06-13 20:47:00 Motest003 has joined
1092 2012-06-13 20:52:24 Joric_ has joined
1093 2012-06-13 20:52:24 Joric_ has quit (Changing host)
1094 2012-06-13 20:52:24 Joric_ has joined
1095 2012-06-13 20:53:18 Joric has quit (Ping timeout: 245 seconds)
1096 2012-06-13 20:53:22 Joric_ is now known as Joric
1097 2012-06-13 20:55:04 danieldaniel has joined
1098 2012-06-13 20:55:06 <BlueMatt> jgarzik: so I get this right, filter* will filter out blocks and send only block headers + individual CMerkleTxs (or similar encoding)
1099 2012-06-13 20:55:09 null_radix has quit (Ping timeout: 265 seconds)
1100 2012-06-13 20:55:09 <BlueMatt> ?
1101 2012-06-13 20:55:12 BTCHero has joined
1102 2012-06-13 20:55:56 <BTCHero> I just created a new receive addy and it shows transactions from months ago that I am sure I didn't do.  Could anyone lend some insight as to what is happening here?
1103 2012-06-13 21:04:32 meLon has quit (Ping timeout: 240 seconds)
1104 2012-06-13 21:05:28 Ferroh has quit (Ping timeout: 252 seconds)
1105 2012-06-13 21:07:27 TuxBlackEdo has quit (Read error: Connection timed out)
1106 2012-06-13 21:13:07 <nanotube> BTCHero: can you check if 1FYoNrSGDeAEFq9AqjLJuPn32in1L56U3o , 1Lh7MxCnVCv2c52hpXUzrHN3ridc9nc11e, or 1M9L4XWBxLihmiVsqio1cNaatWYoEFYB9G any of them are yours also?
1107 2012-06-13 21:13:27 <danieldaniel> nanotube: Lol@telling him to come here, then answering him here :D
1108 2012-06-13 21:13:46 <BTCHero> yeah just a sec, wallet is on other comp
1109 2012-06-13 21:14:14 <nanotube> danieldaniel: just had an idea :)
1110 2012-06-13 21:14:19 <danieldaniel> nanotube: :)
1111 2012-06-13 21:15:04 darkee has quit (Ping timeout: 276 seconds)
1112 2012-06-13 21:15:50 <BTCHero> Yeah the first one is, it must have just used it as a temp and then gave it to me anyway
1113 2012-06-13 21:15:57 <BTCHero> I haven't checked the others
1114 2012-06-13 21:15:58 TuxBlackEdo has joined
1115 2012-06-13 21:16:04 <sipa> jgarzik: i don't see how filterinit can be P2P command
1116 2012-06-13 21:16:37 <BlueMatt> win32 auto-update anyone? https://github.com/bitcoin/bitcoin/pull/1453
1117 2012-06-13 21:16:42 <sipa> BlueMatt: that's the idea
1118 2012-06-13 21:16:46 <nanotube> BTCHero: ye if the first one is yours, that means it was one of your change addrs or something. because first one plus your 'mystery' addr both used as inputs in the same tx. http://blockexplorer.com/tx/be9316945b10203021ca50bed84f010d5a0f0fc2736f1680ac9dc31abccc13f7#i4991862
1119 2012-06-13 21:17:00 danieldaniel has left ()
1120 2012-06-13 21:17:32 <BlueMatt> oh, oops need to change path-specs...
1121 2012-06-13 21:18:28 <BTCHero> Thanks for clearing that up... But they should implement something to avoid this.  I'm glad it wasn't really acollision.  Also, the wallet should report when the txn actually occurred instead of when it saw it.
1122 2012-06-13 21:18:35 <BTCHero> but i don't really know what I am talking about
1123 2012-06-13 21:19:24 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1453 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1453>
1124 2012-06-13 21:19:57 <sipa> what is http://localhost:8080/latestversion.txt ?
1125 2012-06-13 21:20:08 <nanotube> BTCHero: well i dunno what really happened - see if you can get one of the real devs to figure it out :)
1126 2012-06-13 21:20:10 <sipa> does gitian have a http interface...?
1127 2012-06-13 21:21:28 Apexseals has quit (Ping timeout: 244 seconds)
1128 2012-06-13 21:21:33 egecko has joined
1129 2012-06-13 21:21:41 <BlueMatt> oops...should be bitcoin.org/latestversion.txt
1130 2012-06-13 21:21:45 <BTCHero> nanotube: hopefully they see this and do something. It freaked me out a little, and I sort of understand how it works
1131 2012-06-13 21:21:50 rdponticelli has joined
1132 2012-06-13 21:21:52 <BlueMatt> guess I pulled the trigger on the pull a few minutes too early
1133 2012-06-13 21:22:20 <BTCHero> AND if it reported when a txn actually occurd I would have seen that I did a txn at the exact same time and not been too worried and assumed it was a recycled addy
1134 2012-06-13 21:23:02 <nanotube> well, maybe BlueMatt will take a look </ping> :)
1135 2012-06-13 21:23:38 <sipa> BlueMatt: ... it doesn't use gitian?
1136 2012-06-13 21:23:41 <BlueMatt> it does
1137 2012-06-13 21:23:50 <sipa> but just for updating, not for checking?
1138 2012-06-13 21:23:55 <BlueMatt> just for updating, yea
1139 2012-06-13 21:23:59 <sipa> hmmm
1140 2012-06-13 21:24:05 <BlueMatt> because otherwise we download the latest-zip every time we launch...
1141 2012-06-13 21:24:11 <BTCHero> BlueMatt: are there any plans to not use previously used addys?
1142 2012-06-13 21:24:26 <BlueMatt> nanotube/BTCHero: whats up?
1143 2012-06-13 21:24:28 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 38 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/38>
1144 2012-06-13 21:24:39 <sipa> nanotube: can you explain BTCHero's problem?
1145 2012-06-13 21:24:50 <nanotube> BlueMatt: he hit newaddress, and the address apparently was one that was already used in a transaction a few months ago.
1146 2012-06-13 21:24:53 <nanotube> sipa: ^
1147 2012-06-13 21:25:02 <nanotube> seems like it was one of the change addresses or something
1148 2012-06-13 21:25:04 <BTCHero> I made a new receive addy and it was already used, it freaked me out a little because my wallet didn't have the real time of the txn in it
1149 2012-06-13 21:25:11 <nanotube> so the question is, is that normal behavior?
1150 2012-06-13 21:25:13 <sipa> a change address is never reused
1151 2012-06-13 21:25:16 <nanotube> that 'new address' would give you a used one?
1152 2012-06-13 21:25:17 <BlueMatt> thats...odd...
1153 2012-06-13 21:25:32 <sipa> it shouldn't ever give you an address it has used itself before
1154 2012-06-13 21:25:33 <BTCHero> I thought so
1155 2012-06-13 21:25:51 <sipa> if you would dump your wallet.dat file, extract addresses in it, and manually use a keypool address from it
1156 2012-06-13 21:25:53 <nanotube> (i did ask him if he's sure that he didn't make a mistake and clicked on an addr than was not the one that was freshly generated..>)
1157 2012-06-13 21:26:04 <sipa> in that case, i suppose you'll later reuse the same address
1158 2012-06-13 21:26:07 minimoose has quit (Quit: minimoose)
1159 2012-06-13 21:26:33 <BTCHero> no, I do nothing out of the ordinary
1160 2012-06-13 21:26:44 <BTCHero> and I am very confident that I clicked new address
1161 2012-06-13 21:27:09 <sipa> bitcoin-qt doesn't hilight or jump to the newly added address, afaik
1162 2012-06-13 21:27:27 darkee has joined
1163 2012-06-13 21:28:03 <BTCHero> entered the label and everything then checked it on blockchain.info to see if a txn came through I was expecting and saw one from months ago
1164 2012-06-13 21:28:34 m00p has quit (Ping timeout: 252 seconds)
1165 2012-06-13 21:28:49 <BTCHero> If I search the address at the top, nothing appears either so I didn't change the name of a previous receive addy
1166 2012-06-13 21:29:44 <BTCHero> I don't know how interested you are, if at all.  But if you want more info let me know.
1167 2012-06-13 21:29:59 <BlueMatt> sipa: there, bit better now, just have to add the (binary :( ) gitian-updater.exe and double-check the like 5 licenses to make sure we can redist
1168 2012-06-13 21:30:42 <BTCHero> Oh another thing that might be the cause, This was a backup wallet that I moved to this computer
1169 2012-06-13 21:30:55 <BTCHero> that must be what happened?
1170 2012-06-13 21:35:12 <justmoon> is there a blockexplorer yet for testnet3?
1171 2012-06-13 21:36:18 <nanotube> hey justmoon :) not that i know of.
1172 2012-06-13 21:36:36 <nanotube> BTCHero: is that the only address with that label?
1173 2012-06-13 21:37:06 <justmoon> nanotube: hey, how's it goin'? I had to think of you the other day about when you introduced yourself at the new york conference and everyone was cheering :D
1174 2012-06-13 21:37:38 <BTCHero> yep, it was very specific
1175 2012-06-13 21:37:56 <sipa> hey there justmoon :)
1176 2012-06-13 21:38:11 <BlueMatt> sipa: updated the list of deps on https://github.com/bitcoin/bitcoin/pull/1453 including the list of binaries that it depends on, is that list unreasonable, should time be spent trying to gitian-ify some of those?
1177 2012-06-13 21:38:23 <justmoon> sipa: I fixed the microphone stand - drilled a hole, put a bolt through, rock solid now
1178 2012-06-13 21:38:31 <sipa> justmoon: hahah!
1179 2012-06-13 21:38:34 Apexseals has joined
1180 2012-06-13 21:40:50 <nanotube> justmoon: haha cool. :) what happened the other day?
1181 2012-06-13 21:43:27 <justmoon> nothing special, I was just at a meeting where they went through and people introduced themselves
1182 2012-06-13 21:43:36 <justmoon> are you going to be at the london conference by any chance?
1183 2012-06-13 21:47:19 <sipa> BTCHero: that's the explanation
1184 2012-06-13 21:47:48 Joric has quit ()
1185 2012-06-13 21:47:55 <sipa> BTCHero: the wallet contains a pool of 100 pregenerated addresses; they are not revealed, but when you generate a new one, the oldest from that pool is used, and a new one is added to the pool
1186 2012-06-13 21:48:28 <sipa> BTCHero: but if the backup was made before the last transaction on the old system, you'll get the same address a second time
1187 2012-06-13 21:48:43 <BTCHero> ok, that makes sense.  Thanks
1188 2012-06-13 21:48:47 <sipa> BTCHero: that's something that will probably be fixed the same time as deterministic wallets are introduced
1189 2012-06-13 21:49:00 <sipa> because it's possible to detect that even if it's in the key pool, it is already used
1190 2012-06-13 21:49:28 <BTCHero> It was just strange because my wallet has been on this computer for a long time so I forgot that the backup could be the issue
1191 2012-06-13 21:51:31 <BTCHero> and now that I go back through and check my other addys, they all have the same issue I just didn't check them on blockchain.info
1192 2012-06-13 21:51:47 <BTCHero> So mystery solved, sorry for bothering you
1193 2012-06-13 21:51:54 epscy has quit (Ping timeout: 260 seconds)
1194 2012-06-13 21:52:46 O2made has quit (Quit: Leaving)
1195 2012-06-13 21:53:35 <nanotube> justmoon: not sure yet, if i can come up with a good talk maybe. :)
1196 2012-06-13 21:54:25 <BTCHero>  < sipa> if you would dump your wallet.dat file, extract addresses in it, and manually use a keypool address from it -- does this mean there is a way to extract addys and make a new wallet with only the ones you want in it?  Is there a program to do this?  Link?
1197 2012-06-13 21:54:50 <nanotube> BTCHero: probably bitcointools
1198 2012-06-13 21:55:22 ThomasV has quit (Quit: Quitte)
1199 2012-06-13 21:56:55 <BTCHero> google search came up with readme for fixwallet.py "Only half-baked because to be really useful I'd have to write serialize routines to re-pack data after modifying it..."
1200 2012-06-13 21:57:04 <BTCHero> Does this mean it isn't possible yet?
1201 2012-06-13 21:57:37 <justmoon> nanotube: awesome! I hope you find a topic!
1202 2012-06-13 21:57:49 <jgarzik> sipa: if you include filter metadata in serialized 'filterload', then filterinit would only be needed for filteraddhash
1203 2012-06-13 21:59:00 <nanotube> justmoon: so do i :) you gonna be there too?
1204 2012-06-13 21:59:04 <jgarzik> 06/13/12 21:55:33 CTxMemPool::accept() : accepted b5f5f6ed75 (poolsz 6531)
1205 2012-06-13 21:59:05 gavinandresen has joined
1206 2012-06-13 21:59:06 <jgarzik> yowza
1207 2012-06-13 21:59:07 * BlueMatt wonders if jgarzik has him on /ignore
1208 2012-06-13 21:59:19 <jgarzik> BlueMatt: it sounded like sipa answered your question
1209 2012-06-13 21:59:26 <justmoon> jgarzik: I came across some irc messages from you from late may where you were wondering why a lot of testnet clients got stuck on block 47476 - don't know if you ever investigated further, the answer is (I'm pretty sure) those clients didn't have the new testnet special difficulty rules
1210 2012-06-13 21:59:32 <jgarzik> 6,500 transactions in the memory pool
1211 2012-06-13 21:59:44 <BlueMatt> nvm
1212 2012-06-13 22:00:39 <BlueMatt> jgarzik: can you dump? are they satoshidice?
1213 2012-06-13 22:01:16 <jgarzik> this is #master, which I don't think can dump mempool
1214 2012-06-13 22:01:24 <BlueMatt> darn
1215 2012-06-13 22:01:29 <BlueMatt> wait, cant it?
1216 2012-06-13 22:01:39 <BlueMatt> you can gettransaction, and use debug.log
1217 2012-06-13 22:01:53 <BlueMatt> but for 6k txes, meh
1218 2012-06-13 22:02:40 RazielZ has quit (Quit: Leaving)
1219 2012-06-13 22:03:24 <jgarzik> BlueMatt: yeah it is always -possible-
1220 2012-06-13 22:03:34 <jgarzik> BlueMatt: but is it easy for lazy programmers?  that is the question :)
1221 2012-06-13 22:03:46 <justmoon> BlueMatt: you can look at them on blockchain.info, can't you?
1222 2012-06-13 22:03:47 rdponticelli has quit (Ping timeout: 265 seconds)
1223 2012-06-13 22:06:09 <BlueMatt> justmoon: yea but, again, for 6ktxes...mainly I was wondering if jgarzik had (SATOSHIDICE) in his debug.log when he gets a 1dice tx yet ;)
1224 2012-06-13 22:07:13 * Eliel wonders if it would be a good idea to treat very common addresses as low priority transactions (at least if they lack fees)
1225 2012-06-13 22:07:23 <justmoon> using the random sampling method I conclude that most of the current transaction flood is indeed satoshidice :)
1226 2012-06-13 22:07:26 <BlueMatt> I know a few people who do that
1227 2012-06-13 22:07:40 <BlueMatt> Eliel: ^
1228 2012-06-13 22:07:56 <Eliel> satoshidice txs don't need speedy inclusion in the blockchain really.
1229 2012-06-13 22:08:12 <jgarzik> well
1230 2012-06-13 22:08:31 <jgarzik> it is notable not just due to raw number, but how many are sitting around unconfirmed, block after block
1231 2012-06-13 22:08:55 <Eliel> are they perfectly valid though?
1232 2012-06-13 22:09:19 JZavala has joined
1233 2012-06-13 22:10:03 <Eliel> although, having them sit around unconfirmed sounds like easy pickings for poolowners who want to doublespend cheat a bit :P
1234 2012-06-13 22:10:04 <jgarzik> Eliel: they are not accepted into the main tx mempool if invalid
1235 2012-06-13 22:10:29 <jgarzik> Eliel: if you double-spend satoshidice, then you lose
1236 2012-06-13 22:10:53 <Eliel> jgarzik: just doublespend the losses, no need to touch the wins.
1237 2012-06-13 22:11:13 copumpkin has quit (Quit: Computer has gone to sleep.)
1238 2012-06-13 22:11:37 <Eliel> am I missing a reason that won't work?
1239 2012-06-13 22:11:52 <BlueMatt> usually double-spends dont win...
1240 2012-06-13 22:12:28 <Eliel> umm, I mean picking what to doublespend based on whether it won or not.
1241 2012-06-13 22:12:44 <Eliel> if they sit around unconfirmed for long times, it's a perfect opportunity.
1242 2012-06-13 22:12:48 <BlueMatt> oh, poolowner
1243 2012-06-13 22:13:04 <BlueMatt> may work, yea
1244 2012-06-13 22:13:16 <BlueMatt> or do the to-satoshidice txes get confirmed quick?
1245 2012-06-13 22:13:19 <BlueMatt> they probably do
1246 2012-06-13 22:13:36 <Eliel> we might get rid of satoshidice if people do that enough :)
1247 2012-06-13 22:14:01 <BlueMatt> na, the to-satoshidice tx will probably beat your double-spend though you can double-spend the from-satoshidice txes
1248 2012-06-13 22:14:07 <BlueMatt> (if you're satoshidice)
1249 2012-06-13 22:14:11 meLon has joined
1250 2012-06-13 22:14:11 <jgarzik> BlueMatt: don't seem to be confirmed quickly at all... that's the problem
1251 2012-06-13 22:14:27 <BlueMatt> jgarzik: even the ones to satoshidice, not the ones from?
1252 2012-06-13 22:14:41 <Eliel> BlueMatt: I don't see why there'd be a difference?
1253 2012-06-13 22:14:41 <BlueMatt> or do they accept 1-deep txins? in which case, you probably could
1254 2012-06-13 22:14:52 <Eliel> BlueMatt: they accept 0-conf
1255 2012-06-13 22:14:57 <jgarzik> BlueMatt: dunno.  all that is easily visible is the per-block transaction count, versus the rate of mempool size increase
1256 2012-06-13 22:14:58 Maccer has quit (Ping timeout: 248 seconds)
1257 2012-06-13 22:15:03 <justmoon> up to 7200 unconfirmed now
1258 2012-06-13 22:15:15 <jgarzik> occasional block will have 500-1000 tx's, but many are <100
1259 2012-06-13 22:15:20 <BlueMatt> if you purposely use 1-deep txouts, it would work, if you use regular txes, your to-satoshidice txes should get confirmed quick
1260 2012-06-13 22:15:33 <BlueMatt> Id think, at least
1261 2012-06-13 22:15:47 <Eliel> I think their accepting 0-conf is part of the reason there's so much txspam going to them.
1262 2012-06-13 22:15:48 <BlueMatt> [Tycho]: wanna put your mining power to good use ;) ?
1263 2012-06-13 22:15:59 <jgarzik> BlueMatt: some miners (like [Tycho]?) have weird rules where fees < 0.01 are deprioritized as spam, IIUC
1264 2012-06-13 22:15:59 <BlueMatt> Eliel: 0-conf has nothing to do with how deep your txouts are
1265 2012-06-13 22:16:12 <BlueMatt> jgarzik: everyone has that (free tx area)
1266 2012-06-13 22:16:16 <[Tycho]> What use can be better than creating blocks ?
1267 2012-06-13 22:16:21 ovidiusoft has quit (Ping timeout: 244 seconds)
1268 2012-06-13 22:16:28 <BlueMatt> [Tycho]: stealing tons of cash from satoshidice?
1269 2012-06-13 22:16:36 <jgarzik> BlueMatt: well clients are usually < 0.0005 today, not 0.01
1270 2012-06-13 22:16:42 <BlueMatt> oh, sorry
1271 2012-06-13 22:16:42 <[Tycho]> Cool, but I'm good, so I can't steal.
1272 2012-06-13 22:17:02 <BlueMatt> thats a shame
1273 2012-06-13 22:17:28 <[Tycho]> I heard that 1dice takes up to a 50% of all TXes, so this is somehow good for me. Takes unwanted attention away from 1VayNert
1274 2012-06-13 22:17:49 <BlueMatt> also, whats up with multisend?
1275 2012-06-13 22:17:52 <BlueMatt> ;)
1276 2012-06-13 22:18:23 <Eliel> [Tycho]: I think the satoshidice txs are around 80-90% of total transactions by now.
1277 2012-06-13 22:18:44 <[Tycho]> Oh, ewww.
1278 2012-06-13 22:19:00 <[Tycho]> May be they are doing something wrong ?
1279 2012-06-13 22:19:02 <jgarzik> mempool of 7453 is enough to start triggering some of the block size limits too
1280 2012-06-13 22:19:07 Ukto has quit (Read error: Connection reset by peer)
1281 2012-06-13 22:19:11 gjs278 has quit (Remote host closed the connection)
1282 2012-06-13 22:19:35 gjs278 has joined
1283 2012-06-13 22:21:12 <[Tycho]> jgarzik: not as spam, just as free.
1284 2012-06-13 22:22:18 gjs278 has quit (Remote host closed the connection)
1285 2012-06-13 22:22:48 gjs278 has joined
1286 2012-06-13 22:23:02 Ferroh has joined
1287 2012-06-13 22:23:57 TD has joined
1288 2012-06-13 22:24:46 <[Tycho]> I would prefer including manmade transactions over autogenerated ones.
1289 2012-06-13 22:25:20 eoss has joined
1290 2012-06-13 22:25:20 eoss has quit (Changing host)
1291 2012-06-13 22:25:20 eoss has joined
1292 2012-06-13 22:25:34 meLon has quit (Quit: leaving)
1293 2012-06-13 22:25:50 meLon has joined
1294 2012-06-13 22:25:50 meLon has quit (Changing host)
1295 2012-06-13 22:25:50 meLon has joined
1296 2012-06-13 22:25:56 meLon has quit (Client Quit)
1297 2012-06-13 22:26:54 <luke-jr> [Tycho]: so you won't complain if all the other pools start filtering out Deepbit payouts? :P
1298 2012-06-13 22:28:25 <[Tycho]> I wouldn't like that, but I accept the right of choosing what to include.
1299 2012-06-13 22:29:13 <luke-jr> :p
1300 2012-06-13 22:29:25 <luke-jr> [Tycho]: would it get you to upgrade to sendmany sooner?
1301 2012-06-13 22:29:46 <[Tycho]> I can mine them all anyway, and b) I can use random addresses too.
1302 2012-06-13 22:30:13 <[Tycho]> I don't think it will affect my decision on sendmany. I already know that sendmany may be nicer.
1303 2012-06-13 22:30:42 imsaguy has quit (Ping timeout: 256 seconds)
1304 2012-06-13 22:31:30 copumpkin has joined
1305 2012-06-13 22:32:13 <[Tycho]> We should unite and fix the Evil Dice.
1306 2012-06-13 22:32:48 imsaguy has joined
1307 2012-06-13 22:34:11 <luke-jr> [Tycho]: hey, at least Dice pays their way into blocks :P
1308 2012-06-13 22:34:21 <luke-jr> well, Dice users anyhow
1309 2012-06-13 22:34:47 <[Tycho]> How this payment changes their effect on the blockchain ?
1310 2012-06-13 22:36:38 agricocb has quit (Quit: Leaving.)
1311 2012-06-13 22:37:07 rdponticelli has joined
1312 2012-06-13 22:38:43 tsche has quit ()
1313 2012-06-13 22:39:54 meLon has joined
1314 2012-06-13 22:40:00 brwyatt is now known as Away!~brwyatt@pool-71-244-54-5.dllstx.fios.verizon.net|brwyatt
1315 2012-06-13 22:40:25 <gribble> New news from bitcoinrss: slothbag opened issue 1454 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1454>
1316 2012-06-13 22:41:23 giftfrosch has quit (Quit: giftfrosch)
1317 2012-06-13 22:41:57 epscy has joined
1318 2012-06-13 22:42:25 <sipa> jgarzik: sending an empty filter sounds like a bad idea
1319 2012-06-13 22:42:50 <Eliel> sipa: well, that's basically what the clients do now.
1320 2012-06-13 22:43:14 <sipa> you'd miss transactions being relayed between the filter init and adding your addresses
1321 2012-06-13 22:43:30 <sipa> Eliel: empty filter = relay nothing
1322 2012-06-13 22:43:41 <Eliel> oh ok, misunderstood then :)
1323 2012-06-13 22:45:20 Joric has joined
1324 2012-06-13 22:46:32 JZavala has quit (Ping timeout: 240 seconds)
1325 2012-06-13 22:55:23 justmoon has quit (Quit: Leaving)
1326 2012-06-13 22:56:11 Maccer has joined
1327 2012-06-13 22:57:26 theorbtwo has quit (Ping timeout: 265 seconds)
1328 2012-06-13 22:58:40 ivan\ has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
1329 2012-06-13 22:59:59 ivan\ has joined
1330 2012-06-13 23:00:10 <DBordello> Is there any disadvantage to running keypoolsize 0?  Even with an encrypted wallet, will getaddressbyaccount still work?
1331 2012-06-13 23:00:16 <DBordello> (assuming the wallet is still locked)
1332 2012-06-13 23:01:30 <jgarzik> 9,000 unconfirmed transactions in the mempool
1333 2012-06-13 23:01:46 <jgarzik> 130 transactions in last block
1334 2012-06-13 23:01:57 <BlueMatt> DBordello: if you backup your wallet, and then create a new address, then your drive crashes, you will lose your new address (including all coins to it), note that bitcoin creates new addresses on pretty much every action (and often sends coins to it automatically)
1335 2012-06-13 23:02:24 <[Tycho]> jgarzik: does your memorypool flushes old or expired TXes ?
1336 2012-06-13 23:02:41 <DBordello> BlueMatt, yeah, I am weighing the risk of 1) having my wallet stolen/copied versus backup
1337 2012-06-13 23:03:00 <jgarzik> [Tycho]: it does what the standard bitcoin client does... this is bitcoin/bitcoin.git #master as of an hour or two ago
1338 2012-06-13 23:03:17 <BlueMatt> DBordello: a. encrypt it, b. practice sane security measures (which should bring the risk of getting your wallet stolen down very low), c. BACKUP YOUR WALLET
1339 2012-06-13 23:03:22 <jgarzik> [Tycho]: satoshi client does not flush old TX's AFAIK
1340 2012-06-13 23:03:42 <[Tycho]> jgarzik: were your proposing something to solve this backlog ?
1341 2012-06-13 23:04:08 <jgarzik> [Tycho]: my long time proposal is to drop all TX's that do not make it into a block within 144*2 blocks after TX is received
1342 2012-06-13 23:04:19 * BlueMatt wonders if someone is trying the p2pool attack discussed here a few days ago...
1343 2012-06-13 23:04:19 <DBordello> BlueMatt, alright, something to think about
1344 2012-06-13 23:04:23 <jgarzik> [Tycho]: that would not solve today's problem, with thousands of TX's per hour
1345 2012-06-13 23:04:39 <[Tycho]> Which p2pool attack ?
1346 2012-06-13 23:04:42 maaaa has joined
1347 2012-06-13 23:05:02 <luke-jr> BlueMatt: hmm
1348 2012-06-13 23:05:34 <BlueMatt> jgarzik: my seednode poolsz is 8857
1349 2012-06-13 23:05:50 <BlueMatt> (and growing disturbingly constantly...)
1350 2012-06-13 23:06:29 <jgarzik> 8939 here, ATM
1351 2012-06-13 23:06:33 theorbtwo has joined
1352 2012-06-13 23:06:39 <jgarzik> last block flushed out 544
1353 2012-06-13 23:07:09 <BlueMatt> annndddd.... ITS OVER NINE THOUSAND!!!
1354 2012-06-13 23:07:30 <BlueMatt> and every tx showing on blockchain.info I click is 1dice
1355 2012-06-13 23:07:34 <luke-jr> it seems that at some point during blockchain download, my peer sends the latest block, and that interrupts the linear blockchain download and makes it very slow
1356 2012-06-13 23:07:56 <BlueMatt> luke-jr: thats standard on master, maybe 0.6.2 too
1357 2012-06-13 23:07:59 <luke-jr> BlueMatt: sounds like someone's trying to double-spend Dice
1358 2012-06-13 23:08:06 <luke-jr> BlueMatt: seems like a gaping bug
1359 2012-06-13 23:08:09 <[Tycho]> My monitoring node shows about 3666 TX in last day. Looks like some of those TXes are filtered on the way
1360 2012-06-13 23:08:11 <BlueMatt> luke-jr: nope, they are all mempool accept
1361 2012-06-13 23:08:19 <luke-jr> BlueMatt: they would be
1362 2012-06-13 23:08:27 <jgarzik> orphan mapsz 714
1363 2012-06-13 23:08:28 <BlueMatt> luke-jr: not a bug, workaround for a stuck node thinggy, theres a comment for it
1364 2012-06-13 23:08:33 <jgarzik> poolsz 9084
1365 2012-06-13 23:08:42 <luke-jr> BlueMatt: more like it makes nodes semi-stuck
1366 2012-06-13 23:08:42 <BlueMatt> luke-jr: double-spend means its not accepted to mempool
1367 2012-06-13 23:08:59 <luke-jr> BlueMatt: to resume the linear blockchain download, I need to restart my client
1368 2012-06-13 23:09:05 <luke-jr> and it stops again after a bit
1369 2012-06-13 23:09:19 <BlueMatt> luke-jr: hmm? no it shouldnt stop it, just give it another block to think about
1370 2012-06-13 23:09:21 <luke-jr> BlueMatt: you wouldn't see the double-spends
1371 2012-06-13 23:09:25 <luke-jr> BlueMatt: it stops it
1372 2012-06-13 23:09:26 <BlueMatt> luke-jr: it stopping is a bug
1373 2012-06-13 23:09:30 <BlueMatt> (on your end)
1374 2012-06-13 23:09:34 <Karmaon> Why are you guys worrying about satoshi dice spam when an attacker could cheaply send spam at .00050001 each?
1375 2012-06-13 23:09:47 <luke-jr> Karmaon: same thing
1376 2012-06-13 23:10:01 <luke-jr> BlueMatt: you mean 0.6.2/master don't do that?
1377 2012-06-13 23:10:01 <BlueMatt> Karmaon: for all intents and purposes satoshidice is an attacker
1378 2012-06-13 23:10:17 <BlueMatt> luke-jr: it wont stop when it gets that block, no, it will send another getblocks in response
1379 2012-06-13 23:10:25 <gmaxwell> Not just an attacker but one with a snazzy funding strategy for the attack.
1380 2012-06-13 23:10:28 <luke-jr> BlueMatt: any idea when it was fixed?
1381 2012-06-13 23:10:29 <Karmaon> last time i calculated, it takes around 123 bitcoins (or around?) to spam 1gb into the blockchain
1382 2012-06-13 23:10:35 erle- has quit (Quit: erle-)
1383 2012-06-13 23:10:48 <BlueMatt> luke-jr: I dont think any version should ever have stopped when getting the best block
1384 2012-06-13 23:10:56 <BlueMatt> luke-jr: maybe a backport issue?
1385 2012-06-13 23:11:14 <luke-jr> BlueMatt: unlikely, but I'll have to test with master when I'm done with this
1386 2012-06-13 23:11:47 <BlueMatt> hmm...I can see this huge jump in tx processing in the CPU% on my vm...started around tue at midnight, .de time
1387 2012-06-13 23:11:51 <gmaxwell> Basically that site has harnessed people's inability to do math (apparently some people think that they can come out ahead) in order to finance bloating the chain. Brillant hack.
1388 2012-06-13 23:12:28 <BlueMatt> gmaxwell: s/inability to do mat/addition to gambling and insistence on illogical thinking, despite their better nature/
1389 2012-06-13 23:12:31 <Karmaon> I see no problem if the network allows it, they pay fees.
1390 2012-06-13 23:12:58 <luke-jr> Karmaon: OK, then we'll stop allowing it
1391 2012-06-13 23:13:42 <gmaxwell> Everything you can get away with is OKAY is a broken way of thinking about things which results in poor outcomes.
1392 2012-06-13 23:13:55 <Karmaon> Or you could offer paying miners 100+% to mine at your pool, and purposly accept 1mb of transaction spam when you solve a block.
1393 2012-06-13 23:14:25 <gmaxwell> Karmaon: Yes and?
1394 2012-06-13 23:15:01 <Karmaon> Well thats most likely the outcome if you guys disallow it.
1395 2012-06-13 23:15:09 <Karmaon> but it will severely migitate the spam.
1396 2012-06-13 23:15:18 <gmaxwell> Huh? thats not a likely outcome _at all_.
1397 2012-06-13 23:16:00 <gmaxwell> And people are already disallowing it. So, ::shrugs::
1398 2012-06-13 23:16:10 <Karmaon> Depends if miners are more into 5% extra earnings than keeping the blockchain clean :P
1399 2012-06-13 23:17:50 <[Tycho]> Do some legitimate users experience problems caused by this backlog ?
1400 2012-06-13 23:18:10 <luke-jr> IMO no
1401 2012-06-13 23:18:23 <BlueMatt> yea, their .bitcoin becomes huge, removing the possibility of having full nodes for most of the network
1402 2012-06-13 23:18:24 <[Tycho]> Why ?
1403 2012-06-13 23:18:30 <BlueMatt> which is really nice for overall network security
1404 2012-06-13 23:18:42 <luke-jr> users who can't afford confirmation delays, pay a fee or they aren't legitimate :P
1405 2012-06-13 23:18:55 <[Tycho]> BlueMatt: no, I was asking about the transaction sending/receiving.
1406 2012-06-13 23:19:01 <gmaxwell> [Tycho]: It does result in users getting surprisingly long delays for boring transactions.
1407 2012-06-13 23:19:06 Prattler has quit (Read error: Connection reset by peer)
1408 2012-06-13 23:19:15 <luke-jr> gmaxwell: even with txn_prio? ;)
1409 2012-06-13 23:19:16 <BlueMatt> [Tycho]: it makes blocks huge, #include "previous comment"
1410 2012-06-13 23:19:20 <[Tycho]> luke-jr: their fee is the same as 1dice's
1411 2012-06-13 23:19:35 <luke-jr> [Tycho]: then not likely to get a delay, at least on Eligius
1412 2012-06-13 23:19:42 <[Tycho]> gmaxwell: was this measured ?
1413 2012-06-13 23:19:45 <luke-jr> gmaxwell: perhaps this is the push txn_prio needs :D
1414 2012-06-13 23:20:02 <gmaxwell> [Tycho]: People have been showing up complaining about it in #bitcoin. Not exactly a fair sampling.
1415 2012-06-13 23:20:03 <[Tycho]> Should I filter out 1dice TXes from my blocks completely ?
1416 2012-06-13 23:20:18 <luke-jr> gmaxwell: people paying fees?
1417 2012-06-13 23:20:24 <luke-jr> [Tycho]: please
1418 2012-06-13 23:20:41 <luke-jr> [Tycho]: but I say this as someone who will profit from mining more of their fees
1419 2012-06-13 23:20:46 <[Tycho]> Actually this is not a good solution since they can use random addresses too.
1420 2012-06-13 23:20:56 <luke-jr> they can't, actually
1421 2012-06-13 23:21:18 platorin has joined
1422 2012-06-13 23:21:20 <BlueMatt> here's a puzzle: why does satoshidice's site not show nearly the tx volume in their log that they are sending?
1423 2012-06-13 23:21:35 <BlueMatt> does anyone have any way to contact the satoshidice people?
1424 2012-06-13 23:21:37 BrightSky has joined
1425 2012-06-13 23:21:48 <DBordello> Despite all the spam, SatoshiDice is down 600 BTC
1426 2012-06-13 23:21:54 <luke-jr> BlueMatt: yes, they're on the forums
1427 2012-06-13 23:22:03 <gmaxwell> luke-jr: I've been seeing zero fee dice txn mined ahead of base fee txn. I think some miners are (quite reasonably) treating 0.0005 btc as zero.
1428 2012-06-13 23:22:14 <luke-jr> gmaxwell: but all dice txn have fees
1429 2012-06-13 23:22:18 <[Tycho]> Where did they got 600 BTC ?
1430 2012-06-13 23:22:31 <[Tycho]> gmaxwell: I do.
1431 2012-06-13 23:22:47 <imsaguy> [2012/06/13 18:13:53] <imsaguy> 5349 pending transactions on satoshidice site  with an average received amount of .117398, sum is 627.9598
1432 2012-06-13 23:24:34 <gmaxwell> [Tycho]: might have been some of your blocks I was looking at.
1433 2012-06-13 23:24:57 <Eliel> there's one good effect the pools are having though. The pool system pretty much ensures that majority of hashpower has people who care about the system behind it.
1434 2012-06-13 23:25:15 <gmaxwell> Eliel: eeehhh maybe.
1435 2012-06-13 23:25:18 <Eliel> fully decentralized system would not react nearly as fast.
1436 2012-06-13 23:25:22 platorin has left ()
1437 2012-06-13 23:25:54 tsche has joined
1438 2012-06-13 23:25:56 <[Tycho]> 0.0005 fee was set when USD/BTC was like $22, so at least one USD cent per TX
1439 2012-06-13 23:26:04 <Eliel> (for example, filtering satoshidice transactions)
1440 2012-06-13 23:26:06 <gmaxwell> Eliel: I mean there were non-trivial (hundreds of GH) pools after the bip16 rollout who got every block orphaned for weeks. Perhaps they pay more attention than regular users but it's not great.
1441 2012-06-13 23:26:07 <DBordello> [Tycho], I am sure they funded the operation with that
1442 2012-06-13 23:26:28 <gmaxwell> [Tycho]: right, it's too low now but there wasn't much motivation to move it back.
1443 2012-06-13 23:26:57 t7 has quit (Remote host closed the connection)
1444 2012-06-13 23:27:05 <[Tycho]> Fee income was quite noticeable when client started forcing it :)
1445 2012-06-13 23:27:39 <[Tycho]> I think BTCguild gets 0.3-0.5 BTC of fees from 1dice
1446 2012-06-13 23:28:38 <Eliel> gmaxwell: the half-life of a pool whose owner cares that little is not too big.
1447 2012-06-13 23:28:46 <[Tycho]> May me 1dice was created by the Spirit of Satoshi to force people into paying fees :)
1448 2012-06-13 23:30:13 <[Tycho]> *be
1449 2012-06-13 23:30:55 <DBordello> They have paid 176BTC in fees
1450 2012-06-13 23:31:30 <gmaxwell> DBordello: They and their suckers, I believe.
1451 2012-06-13 23:32:03 TD has quit (Quit: TD)
1452 2012-06-13 23:32:05 <DBordello> gmaxwell, i believe that is correct
1453 2012-06-13 23:32:20 <Eliel> if we can somehow force satoshidice into waiting for confirmations and/or using new addresses each time, that should reduce the impact greatly.
1454 2012-06-13 23:32:39 <luke-jr> Dice doesn't pay fees
1455 2012-06-13 23:32:42 <luke-jr> their victims do
1456 2012-06-13 23:33:00 <DBordello> luke-jr, that is true.
1457 2012-06-13 23:33:04 <luke-jr> Eliel: no.
1458 2012-06-13 23:33:10 <Eliel> a big part of the pull is that it's easy. both of those would reduce how easy and instant it is
1459 2012-06-13 23:33:32 <luke-jr> Eliel: they're not going to make a chance that harms their profit
1460 2012-06-13 23:33:46 <luke-jr> and using new addresses doesn't help us at all
1461 2012-06-13 23:33:48 <BlueMatt> someone should chart the # of open pulls over time, i think it would be kinda disturbing
1462 2012-06-13 23:33:59 <luke-jr> BlueMatt: no kidding
1463 2012-06-13 23:34:17 <gmaxwell> BlueMatt: half of them are rebroad.
1464 2012-06-13 23:34:19 <[Tycho]> Eliel: how using new addresses is better ?
1465 2012-06-13 23:34:21 <BlueMatt> Eliel: if we did, they would lose most of their customers, so I doubt they would...
1466 2012-06-13 23:34:24 <luke-jr> BlueMatt: I think part of the problem is, number of devs grows faster than the number of pullers can handle us
1467 2012-06-13 23:34:26 <BlueMatt> gmaxwell: even ignoring rebroad
1468 2012-06-13 23:34:53 <BlueMatt> luke-jr: I think the problem is, pullers have a life, where they really shouldnt and should spend more time pulling!
1469 2012-06-13 23:35:07 <BlueMatt> gmaxwell: Im looking at you
1470 2012-06-13 23:35:11 <luke-jr> BlueMatt: that would work too, but let's be slightly realistic :p
1471 2012-06-13 23:35:11 <gmaxwell> luke-jr: I don't think so, rather we get a backlog because there is a bunch of Eeeeeh stuff that no one is eager to pull.
1472 2012-06-13 23:35:28 <luke-jr> gmaxwell: that doesn't explain the huge delays on my pullreqs :p
1473 2012-06-13 23:35:30 <gmaxwell> BlueMatt: sorry, had other projects take priority for a short term.
1474 2012-06-13 23:35:31 <BlueMatt> luke-jr: well...ok
1475 2012-06-13 23:35:56 sirk390 has quit (Quit: Leaving.)
1476 2012-06-13 23:36:00 <BlueMatt> gmaxwell: heh, all goodd
1477 2012-06-13 23:36:01 <Eliel> luke-jr: well, there are ways to make the current situation less profitable thant that :P
1478 2012-06-13 23:36:13 <luke-jr> Eliel: feel free to double spend them
1479 2012-06-13 23:36:52 <BlueMatt> Eliel: I think they're gonna find with this huge increase in tx volume over the past day that their users are gonna have long delays and start to be alienated from satoshidice (I really, really hope so, at least)
1480 2012-06-13 23:37:12 <Eliel> yes, hopefully that'll be enough.
1481 2012-06-13 23:37:12 <gmaxwell> BlueMatt: if the users are doing nothing but dice they don't notice or care about the delays.
1482 2012-06-13 23:37:39 <BlueMatt> maybe we should force users to wait for 1 conf before spending in Bitcoin-Qt
1483 2012-06-13 23:37:42 <maaaa> they do dice, look at blockchain.info, and come here and complain when the tx isn't confirmed
1484 2012-06-13 23:37:47 <luke-jr> BlueMatt: we already do
1485 2012-06-13 23:37:52 <BlueMatt> oh...
1486 2012-06-13 23:38:08 <luke-jr> BlueMatt: at least, that's how we fixed CVE-2010-5140
1487 2012-06-13 23:38:52 <gmaxwell> luke-jr: hm? I thought it would use unconfirmed txn when it has no other options.
1488 2012-06-13 23:39:01 <luke-jr> gmaxwell: only if they were send-to-self
1489 2012-06-13 23:39:45 <Eliel> I think a bit part of the problem is people running bots that do satoshidice.
1490 2012-06-13 23:39:49 <Eliel> *big
1491 2012-06-13 23:39:53 <gmaxwell> Eliel: sure.
1492 2012-06-13 23:40:06 <gmaxwell> This is what I was thinking of before when I said math failure.
1493 2012-06-13 23:40:10 <luke-jr> I wish gmaxwell's hack worked
1494 2012-06-13 23:42:04 <TuxBlackEdo> you do know that if you go to satsohidice and click on any full txn, on that page it has a blue HMAC link which will allow you to put any input txid you want and get the resulting hmac hash, so all you gotta do is generate a txn and not announce it and plug it into hmac.php and you get the result before even sending the transaction
1495 2012-06-13 23:42:18 <luke-jr> wizkid made a bot to double-spend Dice
1496 2012-06-13 23:42:28 <luke-jr> if sendrawtx were fixed, he could do it I think
1497 2012-06-13 23:42:39 <Eliel> I think that if satoshidice is forced to give up the permanent addresses, it will also cease making sense to use transactions as a betting device directly.
1498 2012-06-13 23:42:46 <BlueMatt> TuxBlackEdo: so...in other words you can find out if you will win before you try?
1499 2012-06-13 23:42:51 <TuxBlackEdo> yep
1500 2012-06-13 23:42:53 * BlueMatt goes to play satoshidice
1501 2012-06-13 23:42:57 <luke-jr> lol
1502 2012-06-13 23:43:00 <gmaxwell> haha
1503 2012-06-13 23:43:03 <TuxBlackEdo> using this: http://satoshidice.com/hmac.php?secret=hidden&data=1a2c6b363391599e6df6be8e28add5f3c5cbd85eeb0ede59bc8658ccaeb8ac40
1504 2012-06-13 23:43:16 <TuxBlackEdo> just change data var to your txid
1505 2012-06-13 23:43:19 <BlueMatt> I see no win/loss there?
1506 2012-06-13 23:43:28 <TuxBlackEdo> if it is a win, announce the txn
1507 2012-06-13 23:43:37 <luke-jr> is their algo published? :P
1508 2012-06-13 23:43:39 <TuxBlackEdo> well you take the first 4 bytes and convert that to decimal
1509 2012-06-13 23:43:49 <gmaxwell> luke-jr: they're using HMAC with some secret we don't know.
1510 2012-06-13 23:43:50 <Eliel> luke-jr: it is
1511 2012-06-13 23:44:12 <Eliel> they change the secret daily and publish the old ones
1512 2012-06-13 23:44:13 <luke-jr> i c
1513 2012-06-13 23:44:14 <BlueMatt> gmaxwell: the secret is secret
1514 2012-06-13 23:44:23 <gmaxwell> but they provided an oracle!
1515 2012-06-13 23:44:23 <BlueMatt> according to that url
1516 2012-06-13 23:44:51 <[Tycho]> Cool.
1517 2012-06-13 23:44:51 <luke-jr> [23:41:15] <wizkid057> its actually hashing the word "hidden" when it hasnt released the secret yet
1518 2012-06-13 23:45:02 <gmaxwell> aw.
1519 2012-06-13 23:45:03 wizkid057 has joined
1520 2012-06-13 23:45:04 <TuxBlackEdo> aw
1521 2012-06-13 23:45:06 <TuxBlackEdo> you are right
1522 2012-06-13 23:45:07 <BlueMatt> darn, what a shame
1523 2012-06-13 23:45:10 <gmaxwell> So it's not an oracle.
1524 2012-06-13 23:45:11 <TuxBlackEdo> or at least wizkid057 is right
1525 2012-06-13 23:45:11 <sipa> haha :D
1526 2012-06-13 23:45:17 <[Tycho]> So you can win any sum ?
1527 2012-06-13 23:45:17 <wizkid057> lol
1528 2012-06-13 23:45:32 <wizkid057> if you knew the secret hash, sure, you could win every time
1529 2012-06-13 23:45:37 <luke-jr> [Tycho]: no, limit 5 BTC bet
1530 2012-06-13 23:45:42 <wizkid057> with a minimal amount of hash power
1531 2012-06-13 23:45:42 <luke-jr> hmm
1532 2012-06-13 23:45:58 <luke-jr> gmaxwell: your proposed attack would work if you did 10 bets?
1533 2012-06-13 23:46:01 <TuxBlackEdo> well might as well take a look at their secretlist.php and see if you can see if they used a flawed random number generator
1534 2012-06-13 23:46:17 <wizkid057> TuxBlackEdo: been down that road also
1535 2012-06-13 23:46:23 <luke-jr> lol
1536 2012-06-13 23:46:24 <wizkid057> either no, or, not enough data yet
1537 2012-06-13 23:46:36 <gmaxwell> luke-jr: they don't win/lose independently.  But I think you could just do low odds of winning bets every time.
1538 2012-06-13 23:47:06 <wizkid057> honestly, i dont like satoshidice
1539 2012-06-13 23:47:14 <TuxBlackEdo> oh fine, then send like 100 txs back to yourself and make 100txs to satoshidice, and send them when you find a block, only include transactions that are losers in your block (when you find one)
1540 2012-06-13 23:47:28 <wizkid057> their method is seriously flawed and bloats the hell out of the blockchain, makes pools work harder to make work, etc etc
1541 2012-06-13 23:47:32 <luke-jr> TuxBlackEdo++
1542 2012-06-13 23:47:33 <TuxBlackEdo> classic double spend attack
1543 2012-06-13 23:47:41 <TuxBlackEdo> luke-jr++ i <3 u too
1544 2012-06-13 23:47:56 <Eliel> since the transactions confirm so slowly, any pool owner should be able to easily do several plays at once and then just double spend the lost ones in the pool's next block.
1545 2012-06-13 23:48:07 <gmaxwell> luke-jr: e.g. you bet 1btc with 1:100 odds and only finney them when you lose (most of the time)
1546 2012-06-13 23:48:10 <wizkid057> satoshidice isnt doublespendable without control over what goes into a block
1547 2012-06-13 23:48:16 <wizkid057> since they use your input as output
1548 2012-06-13 23:48:18 <luke-jr> TuxBlackEdo: but you can't choose txns in the block after finding it :/
1549 2012-06-13 23:48:23 <wizkid057> ^^
1550 2012-06-13 23:48:24 <wizkid057> that too
1551 2012-06-13 23:48:29 <TuxBlackEdo> luke-jr, that's right x_x
1552 2012-06-13 23:48:54 <wizkid057> i kinda hope someone exploits and destroys satoshidice
1553 2012-06-13 23:49:01 <Eliel> wizkid057: me too :P
1554 2012-06-13 23:49:12 <luke-jr> TuxBlackEdo: the easy way is to make a transaction to Dice that only Eligius will accept
1555 2012-06-13 23:49:14 <gmaxwell> wizkid057: setup a prediction market?
1556 2012-06-13 23:49:19 <wizkid057> gmaxwell: lol
1557 2012-06-13 23:49:22 <luke-jr> TuxBlackEdo: then if you lose, send a conflict to the other pools
1558 2012-06-13 23:50:12 <Eliel> luke-jr: I think satoshidice won't accept such transaction themselves :P
1559 2012-06-13 23:50:23 <luke-jr> Eliel: TIAS
1560 2012-06-13 23:50:43 <[Tycho]> Wow, they can really be doublespended :)
1561 2012-06-13 23:50:58 <BlueMatt> https://bitcointalk.org/index.php?topic=77870.msg961107#msg961107
1562 2012-06-13 23:51:01 <TuxBlackEdo> [Tycho], max bets are too small :(
1563 2012-06-13 23:51:11 <[Tycho]> TuxBlackEdo: 5 btc each ?
1564 2012-06-13 23:51:15 <luke-jr> maybe us poolops should add a special doublespend-dice feature
1565 2012-06-13 23:51:19 <wizkid057> [Tycho]: they can, because one of the winning payouts of mine was a doublespend of someone elses that lost that never confirmed, so, I got screwed
1566 2012-06-13 23:51:24 <TuxBlackEdo> yeah you wouldn't want to risk 50btc on a 5btc bet
1567 2012-06-13 23:51:36 <[Tycho]> wizkid057: how you did it ?
1568 2012-06-13 23:51:45 <wizkid057> [Tycho]: i didnt, someone else did
1569 2012-06-13 23:51:58 <luke-jr> [Tycho]: you and I accept higher fee txns to 1dice over conflicts, what ya say?
1570 2012-06-13 23:52:03 <gmaxwell> Basically that site makes their customers take all the double spending risk.
1571 2012-06-13 23:52:04 <[Tycho]> TuxBlackEdo: how this can be a risk if you don't broadcast "wrong" ones ?
1572 2012-06-13 23:52:17 <wizkid057> someone else lost, dice used that money to pay my win, they double spent their loss, i never get paid
1573 2012-06-13 23:52:21 <TuxBlackEdo> because you can't pick and chose the txns you want after finding a block
1574 2012-06-13 23:52:29 <[Tycho]> Oh, after
1575 2012-06-13 23:52:33 Matt_von_Mises has joined
1576 2012-06-13 23:52:48 <[Tycho]> May be I should finally read what this satoshidice is...
1577 2012-06-13 23:53:12 <luke-jr> [Tycho]: illegal gambling ring using Bitcoin AFAICT
1578 2012-06-13 23:53:13 <[Tycho]> Is there a faq ?
1579 2012-06-13 23:53:21 <wizkid057> my idea was to broadcast a TXN that would generally be rejected due to low fee to dice and eligius, then if I lost, broadcast a higher fee normal tx to myself with the same input to the rest of the pools/network and then bet against eligius finding the next block... lol
1580 2012-06-13 23:53:23 <TuxBlackEdo> you need to find a block that includes a txn back to yourself, after you do that, you send the txn on the main network to see if it is a win, if it is a win you don't announce your block, if it is a loss you announce your block which has the inputs back to yourself
1581 2012-06-13 23:53:35 <luke-jr> wizkid057: do it :P
1582 2012-06-13 23:53:38 <wizkid057> and if I did win, just let eligius eventually mine it
1583 2012-06-13 23:53:39 <TuxBlackEdo> wizkid057, nice
1584 2012-06-13 23:53:41 BrightSky has left ()
1585 2012-06-13 23:53:51 <[Tycho]> So any TX should reach them first ?
1586 2012-06-13 23:53:55 <wizkid057> luke-jr: fix sendrawtx... lol
1587 2012-06-13 23:54:14 <[Tycho]> Won't they retransmit it to another pools ?
1588 2012-06-13 23:54:23 <Eliel> wizkid057: satoshidice ignores txs with under 0.0005 fee unless they get one confirm.
1589 2012-06-13 23:54:37 <wizkid057> Eliel: know this for sure?
1590 2012-06-13 23:54:37 <TuxBlackEdo> http://satoshidice.com/full.php?tx=047bb988b484ece0f5b8165b1b1ffd66af33f23e49eab7521d869a23b2d03e9a
1591 2012-06-13 23:54:42 <Matt_von_Mises> Let me get this right. Script push data operations use little endian (eg. OP_PUSHDATA2 0x0100 0x01 0x01) but the arithmetic operations use big endian?
1592 2012-06-13 23:54:43 <TuxBlackEdo> don't get scared ^^^
1593 2012-06-13 23:54:56 <Eliel> wizkid057: https://bitcointalk.org/index.php?topic=77870.msg961076#msg961076
1594 2012-06-13 23:54:58 <wizkid057> Eliel: because i've sent pleaty of 0 fee tx's to them before and they were instant
1595 2012-06-13 23:55:09 <Eliel> wizkid057: probably a recent change.
1596 2012-06-13 23:55:16 <gmaxwell> wizkid057: I believe they started doing it later after they were attacked.
1597 2012-06-13 23:55:21 <BlueMatt> cpu graph of bitcoin node: http://oi45.tinypic.com/29az58p.jpg
1598 2012-06-13 23:55:23 <BlueMatt> thats disturbing
1599 2012-06-13 23:55:34 <wizkid057> well that complicates things
1600 2012-06-13 23:55:34 <wizkid057> lol
1601 2012-06-13 23:55:37 <TuxBlackEdo> did everyone see that satoshidice txn with the lucky number = 0?
1602 2012-06-13 23:56:07 Turingi has quit (Quit: Leaving)
1603 2012-06-13 23:56:14 null_radix has joined
1604 2012-06-13 23:56:16 <wizkid057> honestly, i dont understand why satoshidice uses this method of betting when any other btc bet site does the bets locally
1605 2012-06-13 23:56:18 <TuxBlackEdo> happens once every 65535 times
1606 2012-06-13 23:56:22 <wizkid057> why bloat the blockchain?
1607 2012-06-13 23:56:36 <xorgate> 30k bets today wow
1608 2012-06-13 23:56:43 <[Tycho]> So we need a TX that can be mined but not included by any other pools ? Are they accepting only standard TXes or what ?
1609 2012-06-13 23:56:45 <Eliel> wizkid057: the creator probably thought it's cool. :P
1610 2012-06-13 23:56:57 <Matt_von_Mises> The way bitcoin scripts get endianess confused is silly.
1611 2012-06-13 23:57:02 <wizkid057> can pool ops vote to never mine 1dice transactions? slow them down enough so people stop using it
1612 2012-06-13 23:57:35 <Eliel> [Tycho]: I think they probably accept standard transactions.
1613 2012-06-13 23:57:39 <TuxBlackEdo> all the pools need to cooperate to not include losing 1dice txns
1614 2012-06-13 23:57:45 <TuxBlackEdo> how about that?
1615 2012-06-13 23:57:58 <TuxBlackEdo> have a script parse full.php to see if it is a winning txn or not
1616 2012-06-13 23:58:10 <[Tycho]> Eliel: sadly they are possibly using stock bitcoind :(
1617 2012-06-13 23:58:21 <TuxBlackEdo> if it is a losing txn then don't include
1618 2012-06-13 23:58:23 <[Tycho]> TuxBlackEdo: how we can detect losing bet internally ?
1619 2012-06-13 23:58:29 <Eliel> [Tycho]: I heard bitcoinjs
1620 2012-06-13 23:58:40 <wizkid057> TuxBlackEdo: why bother parsing when you can just see the low payout?
1621 2012-06-13 23:58:40 <TuxBlackEdo> you can't without knowing their secret key
1622 2012-06-13 23:58:41 <Eliel> or was it bitcoinj
1623 2012-06-13 23:59:09 <sipa> Matt_von_Mises: endianness in bitcoin is a mess, but we can't do much about that now
1624 2012-06-13 23:59:17 <TuxBlackEdo> double spends would be easier if the major pools didn't include losing satoshidice txns
1625 2012-06-13 23:59:23 <wizkid057> lol
1626 2012-06-13 23:59:27 <Eliel> yeah, just avoid mining any without seeing the return transaction :)
1627 2012-06-13 23:59:39 <Eliel> then only mine the ones where return transaction is bigger than the bet transaction :P
1628 2012-06-13 23:59:52 <wizkid057> although, i dont think it would go over very well if big players in bitcoin decided to attack a bitcoin-based service...
1629 2012-06-13 23:59:56 <wizkid057> for PR sake