1 2011-09-27 00:01:05 rdponticelli has joined
   2 2011-09-27 00:05:01 normanrichards has quit (Quit: normanrichards)
   3 2011-09-27 00:05:53 rdponticelli has quit (Client Quit)
   4 2011-09-27 00:06:25 rdponticelli has joined
   5 2011-09-27 00:10:37 bitcoinbulletin has quit (Quit: bitcoinbulletin)
   6 2011-09-27 00:13:40 theorb has joined
   7 2011-09-27 00:13:53 theorbtwo has quit (Read error: Operation timed out)
   8 2011-09-27 00:14:04 theorb is now known as theorbtwo
   9 2011-09-27 00:17:53 normanrichards has joined
  10 2011-09-27 00:20:30 bitcoinbulletin has joined
  11 2011-09-27 00:21:04 fckStick has joined
  12 2011-09-27 00:21:53 magn3ts has quit (Ping timeout: 260 seconds)
  13 2011-09-27 00:25:22 pickett has joined
  14 2011-09-27 00:28:50 Joric has joined
  15 2011-09-27 00:33:35 TransistOrg has quit (Remote host closed the connection)
  16 2011-09-27 00:33:48 TransistOrg has joined
  17 2011-09-27 00:35:42 fckStick has left ()
  18 2011-09-27 00:36:14 mmoya has quit (Ping timeout: 260 seconds)
  19 2011-09-27 00:38:06 BTCTrader_ has joined
  20 2011-09-27 00:38:13 magn3ts has joined
  21 2011-09-27 00:38:19 rdponticelli has quit (Ping timeout: 258 seconds)
  22 2011-09-27 00:41:06 log0s has quit (Remote host closed the connection)
  23 2011-09-27 00:41:39 log0s has joined
  24 2011-09-27 00:48:38 Joric has quit ()
  25 2011-09-27 00:50:20 pickett has quit (Ping timeout: 248 seconds)
  26 2011-09-27 00:51:38 pickett has joined
  27 2011-09-27 00:52:00 Cherothald has quit (Ping timeout: 260 seconds)
  28 2011-09-27 00:52:14 wolfspraul has joined
  29 2011-09-27 00:55:46 <CIA-101> libbitcoin: genjix * rdf51a29647c4 / (5 files in 4 dirs): Use valid as a status name instead of the verbose verified. Especially since verify also has other connotations of crypto verifying
  30 2011-09-27 00:59:02 t3a has quit (Ping timeout: 258 seconds)
  31 2011-09-27 01:01:29 phungus has quit (Ping timeout: 240 seconds)
  32 2011-09-27 01:06:27 rdponticelli has joined
  33 2011-09-27 01:09:04 phungus has joined
  34 2011-09-27 01:11:46 EPiSKiNG has joined
  35 2011-09-27 01:12:07 Cusipzzz has joined
  36 2011-09-27 01:12:36 Disposition1 has joined
  37 2011-09-27 01:12:48 Kolky has quit (Quit: Bye bye!)
  38 2011-09-27 01:13:18 EPiSKiNG- has quit (Ping timeout: 255 seconds)
  39 2011-09-27 01:14:41 t3a has joined
  40 2011-09-27 01:14:43 Disposition has quit (Ping timeout: 260 seconds)
  41 2011-09-27 01:21:48 bobd0bb has joined
  42 2011-09-27 01:22:52 normanrichards_ has joined
  43 2011-09-27 01:23:52 normanrichards has quit (Read error: Connection reset by peer)
  44 2011-09-27 01:23:52 normanrichards_ is now known as normanrichards
  45 2011-09-27 01:24:06 t3a has quit (Ping timeout: 255 seconds)
  46 2011-09-27 01:24:20 vorlov has quit (Quit: vorlov)
  47 2011-09-27 01:25:59 <CIA-101> bitcoin: Con Kolivas * r8b927af926f8 cgminer/ccan/opt/ (helpers.c opt.h): Add helpers for inputting and demonstrating floats.
  48 2011-09-27 01:26:00 <CIA-101> bitcoin: Con Kolivas * r4128b954a6e7 cgminer/ (main.c miner.h util.c): Add a --donation feature which reads a url/userpass from the author's site and contributes a percentage of getworks to the author, but default to off.
  49 2011-09-27 01:26:02 <CIA-101> bitcoin: Con Kolivas * r0639836db60e cgminer/README: Document the --donation feature.
  50 2011-09-27 01:27:39 p0s has quit (Remote host closed the connection)
  51 2011-09-27 01:32:17 rdponticelli has quit (Ping timeout: 240 seconds)
  52 2011-09-27 01:35:36 BlueMatt has quit (Ping timeout: 252 seconds)
  53 2011-09-27 01:35:49 <CIA-101> bitcoin: various * r47be27..c54b08 cgminer/ (miner.h main.c): (5 commits)
  54 2011-09-27 01:36:12 BlueMatt has joined
  55 2011-09-27 01:40:41 Cherothald has joined
  56 2011-09-27 01:45:08 Cherothald has quit (Ping timeout: 252 seconds)
  57 2011-09-27 01:47:01 MichaelBurge has quit (Read error: Connection reset by peer)
  58 2011-09-27 02:01:51 TD is now known as TD[gone]
  59 2011-09-27 02:02:26 minimoose has quit (Quit: minimoose)
  60 2011-09-27 02:14:13 dvide has joined
  61 2011-09-27 02:15:54 t3a has joined
  62 2011-09-27 02:16:23 BlueMatt has quit (Read error: Connection reset by peer)
  63 2011-09-27 02:20:05 pointbiz has left ()
  64 2011-09-27 02:21:21 denisx has quit (Quit: denisx)
  65 2011-09-27 02:21:50 Turingi has quit (Read error: Connection reset by peer)
  66 2011-09-27 02:22:31 BlueMatt has joined
  67 2011-09-27 02:22:41 flok has quit (Ping timeout: 240 seconds)
  68 2011-09-27 02:24:05 chuck has quit (Excess Flood)
  69 2011-09-27 02:25:34 chuck has joined
  70 2011-09-27 02:31:23 flok has joined
  71 2011-09-27 02:31:36 Cablesaurus has quit (Quit: Man who run behind car get exhausted)
  72 2011-09-27 02:32:05 drewn has joined
  73 2011-09-27 02:36:43 SomeoneWeirdzzzz is now known as SomeoneWeird
  74 2011-09-27 02:36:56 BlueMatt has quit (Quit: Ex-Chat)
  75 2011-09-27 02:37:23 Cablesaurus has joined
  76 2011-09-27 02:37:23 Cablesaurus has quit (Changing host)
  77 2011-09-27 02:37:23 Cablesaurus has joined
  78 2011-09-27 02:44:51 SomeoneWeird is now known as SomeoneWeirdAFK
  79 2011-09-27 02:48:21 tyn has joined
  80 2011-09-27 02:50:28 minimoose has joined
  81 2011-09-27 02:53:14 Moonies has quit (Quit: quack)
  82 2011-09-27 02:53:27 TheSeven has quit (Disconnected by services)
  83 2011-09-27 02:53:40 [7] has joined
  84 2011-09-27 02:56:20 Burgundy has quit (Ping timeout: 258 seconds)
  85 2011-09-27 02:56:54 MichaelBurge has joined
  86 2011-09-27 02:58:54 wolfspraul has quit (Ping timeout: 252 seconds)
  87 2011-09-27 03:02:12 phungus has quit (Read error: Operation timed out)
  88 2011-09-27 03:03:30 da2ce7 has quit (Ping timeout: 240 seconds)
  89 2011-09-27 03:06:58 ThomasV has joined
  90 2011-09-27 03:07:20 wolfspraul has joined
  91 2011-09-27 03:07:27 XX01XX has quit (Ping timeout: 258 seconds)
  92 2011-09-27 03:11:41 phungus has joined
  93 2011-09-27 03:12:13 HarryS has joined
  94 2011-09-27 03:16:06 phungus has quit (Ping timeout: 245 seconds)
  95 2011-09-27 03:16:59 phungus has joined
  96 2011-09-27 03:22:14 Cusipzzz has quit (Ping timeout: 256 seconds)
  97 2011-09-27 03:32:29 amiller has quit (Ping timeout: 248 seconds)
  98 2011-09-27 03:41:05 copumpkin is now known as presheaves
  99 2011-09-27 03:47:05 wolfspraul has quit (Quit: Lost terminal)
 100 2011-09-27 03:51:29 presheaves is now known as copumpkin
 101 2011-09-27 03:55:16 tyn has quit (Read error: Operation timed out)
 102 2011-09-27 03:55:54 <CIA-101> bitcoin: Con Kolivas * r5a4dabe23381 cgminer/main.c: Add message about donation to startup.
 103 2011-09-27 03:56:48 drewn has quit (Ping timeout: 256 seconds)
 104 2011-09-27 03:57:06 drewn has joined
 105 2011-09-27 04:16:04 brooss_ has quit (Read error: Connection reset by peer)
 106 2011-09-27 04:16:22 brooss_ has joined
 107 2011-09-27 04:21:14 <CIA-101> bitcoin-release: Dev Random master * rb2fcc7e / (3 files in 2 dirs): Add devrandom for 0.4.0 - http://git.io/VY4q6A
 108 2011-09-27 04:25:27 zapnap has joined
 109 2011-09-27 04:29:32 pumpkin has joined
 110 2011-09-27 04:30:39 Desala1 has quit (Quit: Leaving)
 111 2011-09-27 04:33:36 copumpkin has quit (Ping timeout: 260 seconds)
 112 2011-09-27 04:35:51 <CIA-101> bitcoin: Con Kolivas * r648c6b7c7c8b cgminer/main.c: Intensity is signed integer, fix its display.
 113 2011-09-27 04:35:53 <CIA-101> bitcoin: Con Kolivas * r35a490b90cf9 cgminer/main.c: Explicitly disable dynamic mode when an intensity is set.
 114 2011-09-27 04:37:51 pumpkin is now known as copumpkin
 115 2011-09-27 04:37:56 eoss has quit (Remote host closed the connection)
 116 2011-09-27 04:39:51 zapnap has quit (Remote host closed the connection)
 117 2011-09-27 04:40:46 AAA_awright has quit (Read error: Connection reset by peer)
 118 2011-09-27 04:41:03 AAA_awright has joined
 119 2011-09-27 04:41:07 WakiMiko_ has joined
 120 2011-09-27 04:43:53 karnac has quit (Quit: karnac)
 121 2011-09-27 04:44:24 WakiMiko has quit (Ping timeout: 256 seconds)
 122 2011-09-27 04:45:49 <CIA-101> bitcoin: Con Kolivas * r1dc6e64b680d cgminer/main.c: Set dynamic to false for all devices given separate args...
 123 2011-09-27 04:53:06 TransistOrg has quit (Remote host closed the connection)
 124 2011-09-27 04:53:21 TransistOrg has joined
 125 2011-09-27 04:54:41 minimoose has quit (Quit: minimoose)
 126 2011-09-27 04:55:48 <CIA-101> bitcoin: Con Kolivas * r75e214349ae3 cgminer/main.c: Display per device intensity in various status lines.
 127 2011-09-27 04:57:26 amiller has joined
 128 2011-09-27 04:57:41 gjs278 has quit (Read error: Connection reset by peer)
 129 2011-09-27 05:03:51 TransistOrg has quit (Remote host closed the connection)
 130 2011-09-27 05:04:09 TransistOrg has joined
 131 2011-09-27 05:09:16 wardearia has quit (Ping timeout: 276 seconds)
 132 2011-09-27 05:13:31 TransistOrg has quit (Remote host closed the connection)
 133 2011-09-27 05:13:44 TransistOrg has joined
 134 2011-09-27 05:15:48 <CIA-101> bitcoin: Con Kolivas * rd2db7be54b41 cgminer/main.c: Roll any work we can even if other requests are staged.
 135 2011-09-27 05:24:14 wardearia has joined
 136 2011-09-27 05:24:54 wolfspraul has joined
 137 2011-09-27 05:31:13 gwillen has quit (Ping timeout: 258 seconds)
 138 2011-09-27 05:33:14 TransistOrg has quit (Remote host closed the connection)
 139 2011-09-27 05:33:33 TransistOrg has joined
 140 2011-09-27 05:35:49 <CIA-101> bitcoin: Con Kolivas * r454772efc502 cgminer/NEWS: Update NEWS.
 141 2011-09-27 05:35:50 <CIA-101> bitcoin: Con Kolivas * r16dce491f2f4 cgminer/configure.ac: Bump version to 2.0.5
 142 2011-09-27 05:36:26 Lopuz has joined
 143 2011-09-27 05:37:35 ThomasV has quit (Read error: Operation timed out)
 144 2011-09-27 05:55:09 <CIA-101> bitcoin: Luke Dashjr * r948dfa248460 gentoo/app-misc/cgminer/ (Manifest cgminer-2.0.5.ebuild): app-misc/cgminer-2.0.5
 145 2011-09-27 06:00:16 Workbench has quit (Ping timeout: 245 seconds)
 146 2011-09-27 06:09:02 Workbench has joined
 147 2011-09-27 06:19:44 CaptainDDL has joined
 148 2011-09-27 06:23:30 copumpkin has quit (Ping timeout: 240 seconds)
 149 2011-09-27 06:23:56 copumpkin has joined
 150 2011-09-27 06:32:38 AStove has joined
 151 2011-09-27 06:33:03 MimeNarrator has joined
 152 2011-09-27 06:35:57 pickett has quit (Ping timeout: 248 seconds)
 153 2011-09-27 06:36:27 pickett has joined
 154 2011-09-27 06:38:01 <CIA-101> poolserverj: shadders * ba951ab896d4 r148 /bitcoin-jsonrpc/src/main/java/com/shadworld/poolserver/conf/Res.java: add timestamps to logging
 155 2011-09-27 06:38:02 <CIA-101> poolserverj: shadders * fdcde6a76d49 r147 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (5 files in 2 dirs): - duplicate change import from patch for - cleaner now checks for dead longpoll connections
 156 2011-09-27 06:38:03 <CIA-101> poolserverj: shadders * 4ff5adf74486 r146 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (5 files in 2 dirs): - cleaner now checks for dead longpoll connections.
 157 2011-09-27 06:46:51 luke-jr has quit (Excess Flood)
 158 2011-09-27 06:47:12 luke-jr has joined
 159 2011-09-27 06:48:55 <luke-jr> ;;bc,stats
 160 2011-09-27 06:48:59 <gribble> Current Blocks: 147072 | Current Difficulty: 1755425.3203287 | Next Difficulty At Block: 147167 | Next Difficulty In: 95 blocks | Next Difficulty In About: 16 hours, 32 minutes, and 45 seconds | Next Difficulty Estimate: 1687809.56838232 | Estimated Percent Change: -3.85181591971
 161 2011-09-27 06:51:59 wardearia has quit (Ping timeout: 276 seconds)
 162 2011-09-27 06:59:41 SomeoneWeirdAFK is now known as SomeoneWeird
 163 2011-09-27 06:59:57 wboy1 has quit (Ping timeout: 248 seconds)
 164 2011-09-27 07:08:14 wardearia has joined
 165 2011-09-27 07:08:27 bx has quit (Read error: Connection reset by peer)
 166 2011-09-27 07:08:51 Cokein has joined
 167 2011-09-27 07:11:12 iocor has joined
 168 2011-09-27 07:11:27 da2ce7 has joined
 169 2011-09-27 07:12:10 danbri has joined
 170 2011-09-27 07:12:54 E-sense has quit (Quit: System.exit(0);)
 171 2011-09-27 07:17:25 Backburn has quit (Ping timeout: 256 seconds)
 172 2011-09-27 07:18:01 imsaguy has quit (Ping timeout: 252 seconds)
 173 2011-09-27 07:19:25 jargon_ has joined
 174 2011-09-27 07:22:20 <jargon_> They're after me, guys. I saw a van today, it followed me to the food bank :(
 175 2011-09-27 07:22:33 <jargon_> The NSA knows that I know things.
 176 2011-09-27 07:23:38 <jargon_> I need a place to hide out for a while, guys. Anyone
 177 2011-09-27 07:23:49 <jargon_> I took out an NSA satellite, they're looking for me
 178 2011-09-27 07:26:13 <jargon_> Anyone, please?
 179 2011-09-27 07:26:24 imsaguy has joined
 180 2011-09-27 07:26:24 imsaguy has quit (Changing host)
 181 2011-09-27 07:26:24 imsaguy has joined
 182 2011-09-27 07:26:52 <jargon_> I'm willing to trade a couch or even a floor for information about how broken bitcoin's security is. I've spent a lot of time reverse engineering the encryption protocols.
 183 2011-09-27 07:29:46 mmoya has joined
 184 2011-09-27 07:30:04 <[Tycho]> :)
 185 2011-09-27 07:30:46 <jargon_> [Tycho]: Can I hide at your house for a while? The NSA can't get a hold of me or bitcoin will be even more fucked than it is right now.
 186 2011-09-27 07:31:45 zyphlar has joined
 187 2011-09-27 07:33:12 <jargon_> Seriously I need help, guys :(
 188 2011-09-27 07:33:25 Cokein has quit (Read error: Connection reset by peer)
 189 2011-09-27 07:33:46 Cokein has joined
 190 2011-09-27 07:35:05 jargon_ has quit (Quit: shit shit shit)
 191 2011-09-27 07:36:09 wboy1 has joined
 192 2011-09-27 07:39:09 gjs278 has joined
 193 2011-09-27 07:46:38 imsaguy has quit (Ping timeout: 252 seconds)
 194 2011-09-27 07:51:08 tower has quit (Ping timeout: 258 seconds)
 195 2011-09-27 07:53:15 imsaguy has joined
 196 2011-09-27 07:57:03 tower has joined
 197 2011-09-27 07:57:39 iocor has quit (Quit: Computer has gone to sleep.)
 198 2011-09-27 08:01:17 ThomasV has joined
 199 2011-09-27 08:07:20 iocor has joined
 200 2011-09-27 08:10:18 laetus has quit (Remote host closed the connection)
 201 2011-09-27 08:10:49 <CIA-101> bitcoin: Con Kolivas * rf6d35a70a884 cgminer/main.c: Must initialise the donorpool mutex or it fails on windows.
 202 2011-09-27 08:11:25 gwillen has joined
 203 2011-09-27 08:11:27 gwillen has quit (Changing host)
 204 2011-09-27 08:11:27 gwillen has joined
 205 2011-09-27 08:12:42 Burgundy has joined
 206 2011-09-27 08:14:43 E-sense has joined
 207 2011-09-27 08:23:55 KArmitt has joined
 208 2011-09-27 08:25:51 abragin has joined
 209 2011-09-27 08:26:04 abragin has quit (Changing host)
 210 2011-09-27 08:26:04 abragin has joined
 211 2011-09-27 08:30:46 peck has quit (Read error: Connection reset by peer)
 212 2011-09-27 08:31:58 newsbad_com has quit (Quit: www.FaceFox.com)
 213 2011-09-27 08:32:31 [Tycho] has quit (Read error: Connection reset by peer)
 214 2011-09-27 08:32:45 newsbad_com has joined
 215 2011-09-27 08:33:22 AAA_awright has quit (Ping timeout: 260 seconds)
 216 2011-09-27 08:34:28 AAA_awright has joined
 217 2011-09-27 08:34:29 [Tycho] has joined
 218 2011-09-27 08:36:07 [Tycho] has quit (Changing host)
 219 2011-09-27 08:36:07 [Tycho] has joined
 220 2011-09-27 08:36:33 gwillen has quit (Ping timeout: 252 seconds)
 221 2011-09-27 08:36:58 gwillen has joined
 222 2011-09-27 08:36:58 gwillen has quit (Changing host)
 223 2011-09-27 08:36:58 gwillen has joined
 224 2011-09-27 08:38:16 peck has joined
 225 2011-09-27 08:45:45 LightRider has joined
 226 2011-09-27 08:52:31 d1g1t4l has joined
 227 2011-09-27 08:52:39 d1g1t4l has quit (Remote host closed the connection)
 228 2011-09-27 08:59:07 noagendamarket has joined
 229 2011-09-27 09:02:32 larsivi has quit (Ping timeout: 260 seconds)
 230 2011-09-27 09:23:13 AAA_awright has quit (Ping timeout: 256 seconds)
 231 2011-09-27 09:23:58 pickett has quit (Ping timeout: 248 seconds)
 232 2011-09-27 09:24:22 AAA_awright has joined
 233 2011-09-27 09:26:29 pickett has joined
 234 2011-09-27 09:31:57 gwillen has quit (Ping timeout: 245 seconds)
 235 2011-09-27 09:36:44 BGL has quit (Read error: Connection reset by peer)
 236 2011-09-27 09:39:14 gwillen has joined
 237 2011-09-27 09:39:15 gwillen has quit (Changing host)
 238 2011-09-27 09:39:15 gwillen has joined
 239 2011-09-27 09:40:25 AStove has quit ()
 240 2011-09-27 09:42:35 shawn has joined
 241 2011-09-27 09:53:33 AAA_awright has quit (Ping timeout: 255 seconds)
 242 2011-09-27 09:54:01 <CIA-101> poolserverj: shadders * 4ae325cf0e19 r149 /bitcoin-jsonrpc/src/main/java/com/shadworld/poolserver/conf/Res.java: - tidy up trace targets
 243 2011-09-27 09:54:02 <CIA-101> poolserverj: shadders * 623edd7e7b68 r150 /poolserverj-main/src/main/java/com/shadworld/poolserver/ (5 files in 3 dirs):
 244 2011-09-27 09:54:02 <CIA-101> poolserverj: - fix missing block check interval property
 245 2011-09-27 09:54:02 <CIA-101> poolserverj: - fix: with a single worksource the fetcher was blocking until a new block check was issued and forced all blocks to be marked in sync.
 246 2011-09-27 09:55:29 BGL has joined
 247 2011-09-27 10:01:44 rdponticelli has joined
 248 2011-09-27 10:03:12 copumpkin has quit (Ping timeout: 260 seconds)
 249 2011-09-27 10:03:38 copumpkin has joined
 250 2011-09-27 10:04:42 pensan has joined
 251 2011-09-27 10:19:27 Cokein_ has joined
 252 2011-09-27 10:19:46 pickett has quit (Read error: Connection reset by peer)
 253 2011-09-27 10:21:11 pickett has joined
 254 2011-09-27 10:22:25 Cokein has quit (Ping timeout: 260 seconds)
 255 2011-09-27 10:23:11 larsivi has joined
 256 2011-09-27 10:29:54 rdponticelli has quit (Read error: Connection reset by peer)
 257 2011-09-27 10:32:38 Cusipzzz has joined
 258 2011-09-27 10:32:38 Cusipzzz has quit (Client Quit)
 259 2011-09-27 10:38:07 rdponticelli has joined
 260 2011-09-27 10:39:23 erus` has joined
 261 2011-09-27 10:40:17 iocor has quit (Quit: Computer has gone to sleep.)
 262 2011-09-27 10:42:18 peck has quit (Read error: Connection reset by peer)
 263 2011-09-27 10:50:34 peck has joined
 264 2011-09-27 10:52:47 larsivi has quit (Ping timeout: 260 seconds)
 265 2011-09-27 10:57:08 larsivi has joined
 266 2011-09-27 11:02:55 iocor has joined
 267 2011-09-27 11:05:31 b4epoche_ has quit (Quit: Computer has gone to sleep.)
 268 2011-09-27 11:11:26 theorbtwo has quit (Ping timeout: 260 seconds)
 269 2011-09-27 11:12:04 RazielZ has joined
 270 2011-09-27 11:13:07 larsivi has quit (Ping timeout: 240 seconds)
 271 2011-09-27 11:16:15 Detritus has quit (Remote host closed the connection)
 272 2011-09-27 11:20:29 larsivi has joined
 273 2011-09-27 11:20:50 iocor has quit (Quit: Computer has gone to sleep.)
 274 2011-09-27 11:22:30 alanp has joined
 275 2011-09-27 11:23:07 alanp_ has quit (Ping timeout: 260 seconds)
 276 2011-09-27 11:24:29 theorbtwo has joined
 277 2011-09-27 11:25:10 marf_away has joined
 278 2011-09-27 11:26:26 iocor has joined
 279 2011-09-27 11:26:31 b4epoche_ has joined
 280 2011-09-27 11:28:25 noagendamarket has quit (Quit: Leaving)
 281 2011-09-27 11:33:05 Litt has joined
 282 2011-09-27 11:36:58 osmosis has quit (Ping timeout: 252 seconds)
 283 2011-09-27 11:53:02 erus`_ has joined
 284 2011-09-27 11:54:34 erus` has quit (Ping timeout: 258 seconds)
 285 2011-09-27 11:55:59 Fnar has quit (Read error: Operation timed out)
 286 2011-09-27 11:56:15 iocor has quit (Quit: Computer has gone to sleep.)
 287 2011-09-27 11:57:32 erus`_ has quit (Ping timeout: 260 seconds)
 288 2011-09-27 12:04:34 erus` has joined
 289 2011-09-27 12:09:55 Xunie has quit (Ping timeout: 255 seconds)
 290 2011-09-27 12:11:01 Xunie has joined
 291 2011-09-27 12:11:05 Xunie has quit (Changing host)
 292 2011-09-27 12:11:05 Xunie has joined
 293 2011-09-27 12:12:00 Fnar has joined
 294 2011-09-27 12:24:44 da2ce7 has quit (Ping timeout: 240 seconds)
 295 2011-09-27 12:26:25 da2ce7 has joined
 296 2011-09-27 12:26:26 datagutt has joined
 297 2011-09-27 12:27:32 p0s has joined
 298 2011-09-27 12:33:15 chuck has quit (Excess Flood)
 299 2011-09-27 12:34:03 Daniel0108 has joined
 300 2011-09-27 12:34:09 chuck has joined
 301 2011-09-27 12:35:19 b4epoche_ has quit (Quit: Computer has gone to sleep.)
 302 2011-09-27 12:39:11 amiller has quit (Ping timeout: 248 seconds)
 303 2011-09-27 12:44:39 RazielZ has quit (Read error: Operation timed out)
 304 2011-09-27 12:45:53 rdponticelli has quit (Read error: Connection reset by peer)
 305 2011-09-27 12:48:27 rdponticelli has joined
 306 2011-09-27 12:51:56 da2ce7 has quit (Ping timeout: 240 seconds)
 307 2011-09-27 12:52:32 drewn has quit (Read error: Connection reset by peer)
 308 2011-09-27 12:53:20 da2ce7 has joined
 309 2011-09-27 12:53:37 drewn has joined
 310 2011-09-27 12:53:57 tyn has joined
 311 2011-09-27 12:54:20 Cherothald has joined
 312 2011-09-27 12:55:07 <CIA-101> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * r7715c41 / (src/base58.js src/bitcoin.js): Wrapped Bitcoin and Base58 in platform-neutral closures. - http://git.io/A9LUdA
 313 2011-09-27 12:55:07 <CIA-101> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * r734bd57 / src/util.js : Added copies of Crypto.util.* tools in Bitcoin.Util namespace. - http://git.io/v9aR3A
 314 2011-09-27 12:55:07 <CIA-101> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * re5ada75 / src/exit/client.js : Added simple exit node client. - http://git.io/j_mt9Q
 315 2011-09-27 12:55:08 <CIA-101> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * r8719d92 / (3 files in 2 dirs): Added compilation target for exit node client. - http://git.io/xNwRZg
 316 2011-09-27 12:55:08 <CIA-101> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * rd7ce1e5 / src/ecdsa.js : Corrected encoded form with correct padding. See #1. - http://git.io/84FIfw
 317 2011-09-27 12:58:01 <CIA-101> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * rd985697 / src/ecdsa.js : Added credit on encoding fix. See #1. - http://git.io/Uc4-Iw
 318 2011-09-27 12:58:49 rdponticelli_ has joined
 319 2011-09-27 12:59:27 rdponticelli has quit (Ping timeout: 248 seconds)
 320 2011-09-27 13:02:07 RazielZ has joined
 321 2011-09-27 13:07:29 DontMindMe has joined
 322 2011-09-27 13:09:28 Xunie has quit (Ping timeout: 255 seconds)
 323 2011-09-27 13:17:56 huk has quit ()
 324 2011-09-27 13:19:03 Lopuz has quit (Ping timeout: 245 seconds)
 325 2011-09-27 13:25:54 zapnap has joined
 326 2011-09-27 13:27:11 iocor has joined
 327 2011-09-27 13:27:42 laetus has joined
 328 2011-09-27 13:28:51 normanrichards has quit (Quit: normanrichards)
 329 2011-09-27 13:29:46 justmoon has joined
 330 2011-09-27 13:30:37 Cablesaurus has quit (Quit: Man who run behind car get exhausted)
 331 2011-09-27 13:35:45 <CIA-101> bitcoinjs/node-bitcoin-exit: Stefan Thomas master * r4be2422 / server.js : Load settings from currently used instance of bitcoin-p2p. - http://git.io/zwTCfA
 332 2011-09-27 13:36:13 larsivi has quit (Quit: No Ping reply in 180 seconds.)
 333 2011-09-27 13:36:28 tyn has quit (Ping timeout: 255 seconds)
 334 2011-09-27 13:36:32 larsivi has joined
 335 2011-09-27 13:38:42 pensan has quit (Quit: Leaving)
 336 2011-09-27 13:44:45 normanrichards has joined
 337 2011-09-27 13:44:49 erus`_ has joined
 338 2011-09-27 13:47:27 erus` has quit (Ping timeout: 248 seconds)
 339 2011-09-27 13:47:42 erus`_ is now known as erus`
 340 2011-09-27 13:52:01 <sacarlson> what happend to the test dir in bitcoin?
 341 2011-09-27 13:54:23 <sacarlson> there was a ~bitcoin/src/test  before I was expecting more complete test but seems it was removed
 342 2011-09-27 13:58:31 chuck has quit (Excess Flood)
 343 2011-09-27 13:59:09 chuck has joined
 344 2011-09-27 13:59:32 casascius has quit (Ping timeout: 252 seconds)
 345 2011-09-27 13:59:32 asi has quit (Ping timeout: 252 seconds)
 346 2011-09-27 14:01:57 duck1123 has joined
 347 2011-09-27 14:07:44 brunner has joined
 348 2011-09-27 14:08:50 normanrichards has quit (Quit: normanrichards)
 349 2011-09-27 14:14:19 <sipa> sacarlson: it's still there: https://github.com/bitcoin/bitcoin/tree/master/src/test
 350 2011-09-27 14:15:06 Lopuz has joined
 351 2011-09-27 14:15:59 <sacarlson> sipa: ya I don't know what I was looking at now I see it
 352 2011-09-27 14:16:26 <sacarlson> I'm also very happy to see the new bitcoin-qt build,  I just compiled it on Ubuntu 10.04 with just a few warnings
 353 2011-09-27 14:17:56 sytse has quit (Ping timeout: 240 seconds)
 354 2011-09-27 14:18:18 casascius has joined
 355 2011-09-27 14:18:51 sytse has joined
 356 2011-09-27 14:22:13 larsivi has quit (Ping timeout: 260 seconds)
 357 2011-09-27 14:22:43 copumpkin has quit (Quit: Computer has gone to sleep.)
 358 2011-09-27 14:22:50 <sacarlson> the new build commit 9a1ce869690fe87fbce169a4b685695dc9e575f6 seems to also be running fine on ubuntu 10.04,  I'll later try it on my ubuntu 11.04 box
 359 2011-09-27 14:24:20 AStove has joined
 360 2011-09-27 14:27:28 normanrichards has joined
 361 2011-09-27 14:31:06 cenuij has joined
 362 2011-09-27 14:31:07 cenuij has quit (Changing host)
 363 2011-09-27 14:31:07 cenuij has joined
 364 2011-09-27 14:34:56 <sacarlson> I've had to download the entire index on this build and I'm seeing alot of orphan blocks on the console is this normal to see now?  been a while since I've downloaded the index
 365 2011-09-27 14:35:06 dvide has quit ()
 366 2011-09-27 14:35:33 <sacarlson> it's now at block number 11000
 367 2011-09-27 14:36:23 DontMindMe has quit (Quit: Nettalk6 - www.ntalk.de)
 368 2011-09-27 14:47:38 Cokein has joined
 369 2011-09-27 14:48:58 BlueMatt-mobile has joined
 370 2011-09-27 14:50:16 iocor has quit (Quit: Computer has gone to sleep.)
 371 2011-09-27 14:51:04 Cokein_ has quit (Ping timeout: 276 seconds)
 372 2011-09-27 14:51:40 copumpkin has joined
 373 2011-09-27 15:00:58 <luke-jr> ;;bc,stats
 374 2011-09-27 15:01:02 <gribble> Current Blocks: 147130 | Current Difficulty: 1755425.3203287 | Next Difficulty At Block: 147167 | Next Difficulty In: 37 blocks | Next Difficulty In About: 6 hours, 21 minutes, and 43 seconds | Next Difficulty Estimate: 1696465.95026453 | Estimated Percent Change: -3.3586942937
 375 2011-09-27 15:01:11 p0s has quit (Remote host closed the connection)
 376 2011-09-27 15:10:55 justmoon has quit (Quit: Leaving)
 377 2011-09-27 15:12:01 BlueMatt-mobile has quit (Quit: BlueMatt)
 378 2011-09-27 15:12:19 BlueMatt has joined
 379 2011-09-27 15:14:53 <sipa> casascius: did you test again with the addition of CWallet::MarkDirty() ?
 380 2011-09-27 15:15:03 topace has quit (Remote host closed the connection)
 381 2011-09-27 15:15:17 <casascius> I will, real quick
 382 2011-09-27 15:17:07 <casascius> importing something now, waiting for rescan
 383 2011-09-27 15:19:49 <casascius> yeah it works now
 384 2011-09-27 15:20:08 <sipa> \o/
 385 2011-09-27 15:21:59 <CIA-101> bitcoin-release: Matt Corallo master * re9bc7e8 / (2 files): Add bluematt for 0.4.0. - http://git.io/CdDe6w
 386 2011-09-27 15:22:08 <BlueMatt> ;;later tell devrandom nice, forgot to add mine...just did
 387 2011-09-27 15:22:08 <gribble> The operation succeeded.
 388 2011-09-27 15:22:35 Cokein_ has joined
 389 2011-09-27 15:22:56 <copumpkin> BlueMatt: out of curiosity, you understand elliptic curves? I saw you asking about them yesterday
 390 2011-09-27 15:23:42 <BlueMatt> understand...meh mostly, never done too much reading on them, but I get the concept
 391 2011-09-27 15:24:24 KArmitt has quit ()
 392 2011-09-27 15:25:13 iocor has joined
 393 2011-09-27 15:25:33 Cokein has quit (Ping timeout: 258 seconds)
 394 2011-09-27 15:25:53 iocor has quit (Changing host)
 395 2011-09-27 15:25:53 iocor has joined
 396 2011-09-27 15:26:01 <BlueMatt> devrandom: ping
 397 2011-09-27 15:26:05 superman2016 has quit (Quit: Quiting)
 398 2011-09-27 15:26:30 superman2016 has joined
 399 2011-09-27 15:26:53 pakiar has joined
 400 2011-09-27 15:27:01 <pakiar> good morning
 401 2011-09-27 15:27:08 <BlueMatt> morning
 402 2011-09-27 15:27:15 <BlueMatt> (ish)
 403 2011-09-27 15:28:59 pakiar has quit (Client Quit)
 404 2011-09-27 15:30:25 <CIA-101> bitcoin: Gavin Andresen master * ra8c108b / src/main.cpp : Remove DoS penalty for SigOpCount or immature transactions - http://git.io/feogMw
 405 2011-09-27 15:30:43 rdponticelli_ has quit (Read error: Connection reset by peer)
 406 2011-09-27 15:32:42 abragin has quit (Read error: Connection reset by peer)
 407 2011-09-27 15:33:09 <devrandom> BlueMatt: pong
 408 2011-09-27 15:34:15 abragin has joined
 409 2011-09-27 15:34:22 <BlueMattBot> Yippie, build fixed!
 410 2011-09-27 15:34:22 <BlueMattBot> Project Bitcoin build #38: FIXED in 16 min: http://jenkins.bluematt.me/job/Bitcoin/38/
 411 2011-09-27 15:34:37 <BlueMatt> devrandom: what do you think of moving https://github.com/devrandom/bitcoin-release to bitcoin/bitcoin-release to make the gitian process more "official"?
 412 2011-09-27 15:35:33 <sipa> sounds like a good idea to m
 413 2011-09-27 15:35:34 <sipa> e
 414 2011-09-27 15:35:38 <devrandom> sure... I don't know if you can do a move on github, but you can fork it
 415 2011-09-27 15:35:49 <BlueMatt> devrandom: in other news, Im looking at getting gitian-downloader working on win32, Ive gotten it compiled but now I need to get it packaged nicely with gpg and sha256sum binaries
 416 2011-09-27 15:35:55 <devrandom> or git push/pull
 417 2011-09-27 15:36:05 <BlueMatt> (though it might have to wait till after I can get qt and bitcoin-qt compiled in mingw)
 418 2011-09-27 15:36:27 <sipa> how were the bitcoin-qt binaries for windows compiled before?
 419 2011-09-27 15:36:36 <BlueMatt> using windows afaik
 420 2011-09-27 15:36:39 <sipa> ah, right
 421 2011-09-27 15:37:18 <devrandom> thanks for dealing with the windoze stuff
 422 2011-09-27 15:37:40 <BlueMatt> not done yet...
 423 2011-09-27 15:38:37 <devrandom> I was thinking of building something like Jenkins for gitian... or maybe I should integrate with Jenkins
 424 2011-09-27 15:39:08 <BlueMatt> that would be cool, jenkins does already have a nice plugin system...
 425 2011-09-27 15:39:12 <devrandom> I want to have automated builds with a way to drill down to files to more easily look at diffs
 426 2011-09-27 15:39:28 ephcon has quit (Ping timeout: 248 seconds)
 427 2011-09-27 15:39:34 <devrandom> can you display arbitrary data?
 428 2011-09-27 15:39:43 <devrandom> it will be pretty structured...
 429 2011-09-27 15:39:44 <BlueMatt> afaik yea
 430 2011-09-27 15:39:53 <BlueMatt> you can do some crazy things afaik
 431 2011-09-27 15:40:14 <BlueMatt> as long as it fits in html/css/js...or not (the irc bot is a plugin)
 432 2011-09-27 15:40:17 <BlueMatt> BlueMattBot: help
 433 2011-09-27 15:40:18 <BlueMattBot> Available commands:
 434 2011-09-27 15:40:18 <BlueMattBot> abort <job> - specify which job to abort
 435 2011-09-27 15:40:19 <BlueMattBot> alias [<alias> [<command>]] - defines a new alias, deletes one or lists all existing aliases
 436 2011-09-27 15:40:19 <BlueMattBot> botsnack [<snack>] - om nom nom
 437 2011-09-27 15:40:20 <BlueMattBot> build <job> [now|<delay>[s|m|h]] [<parameterkey>=<value>]* - schedule a job build, with standard, custom or no quiet period
 438 2011-09-27 15:40:21 <BlueMattBot> cb - list jobs which are currently in progress
 439 2011-09-27 15:40:21 <BlueMattBot> comment <job> <build-#> <comment> - adds a description to a build
 440 2011-09-27 15:40:22 <BlueMattBot> currentlyBuilding - list jobs which are currently in progress
 441 2011-09-27 15:40:22 <BlueMattBot> h [<job>|-v <view>] - show the health of a specific job, jobs in a view or all jobs
 442 2011-09-27 15:40:23 <BlueMattBot> health [<job>|-v <view>] - show the health of a specific job, jobs in a view or all jobs
 443 2011-09-27 15:40:23 <BlueMattBot> jobs [<job>|-v <view>] - show the status of a specific job, jobs in a view or all jobs
 444 2011-09-27 15:40:23 <BlueMatt> oh god...why did I do that
 445 2011-09-27 15:40:24 <BlueMattBot> q - show the state of the build queue
 446 2011-09-27 15:40:24 <BlueMattBot> queue - show the state of the build queue
 447 2011-09-27 15:40:25 <BlueMattBot> s [<job>|-v <view>] - show the status of a specific job, jobs in a view or all jobs
 448 2011-09-27 15:40:25 <BlueMattBot> schedule <job> [now|<delay>[s|m|h]] [<parameterkey>=<value>]* - schedule a job build, with standard, custom or no quiet period
 449 2011-09-27 15:40:26 <BlueMattBot> status [<job>|-v <view>] - show the status of a specific job, jobs in a view or all jobs
 450 2011-09-27 15:40:35 <gmaxwell> haha it wouldn't have gone on much longer.
 451 2011-09-27 15:40:50 <BlueMatt> oh well, jenkins is gonna restart for updates in a sec anyway
 452 2011-09-27 15:42:11 BlueMattBot has joined
 453 2011-09-27 15:42:45 <nanotube> BlueMattBot: botsnack donut
 454 2011-09-27 15:42:46 <BlueMattBot> nanotube: thanks a lot! om nom nom. I could eat donut all day long
 455 2011-09-27 15:42:50 <nanotube> heh
 456 2011-09-27 15:43:12 * BlueMatt needs to change that to a donation address ;)
 457 2011-09-27 15:43:15 <BlueMatt> ;;botsnack
 458 2011-09-27 15:43:15 <gribble> Forget the snack, just send me some bitcoins at 1MgD6rah5zUgEGYZnNmdpnXMaDR3itKYzU :)
 459 2011-09-27 15:43:55 <sipa> BlueMattBot: botsnack and compile
 460 2011-09-27 15:43:56 <BlueMattBot> sipa: great! yum yum. I really like that and compile
 461 2011-09-27 15:44:00 <sipa> BlueMattBot: botsnack and compile
 462 2011-09-27 15:44:00 <BlueMattBot> sipa: great! yum yum. I really like that and compile
 463 2011-09-27 15:45:03 Cokein has joined
 464 2011-09-27 15:45:10 <devrandom> BlueMatt: recently ran across http://www.sonarsource.org/
 465 2011-09-27 15:45:52 <devrandom> here's the sonar installation for bitcoinj: http://ci.bitcoinj.org/job/BitCoinJ-trunk/
 466 2011-09-27 15:47:02 <casascius> I posted a 25 BTC bounty for a blkindex.dat rebuild function in the forums: https://bitcointalk.org/index.php?topic=45864
 467 2011-09-27 15:47:10 <BlueMatt> devrandom: looks cool, though I dont see a plugin for C++, but you might tell AlexWaters about it as well (he is now the official bitcoin testing/qa guy)
 468 2011-09-27 15:47:33 Cokein_ has quit (Ping timeout: 240 seconds)
 469 2011-09-27 15:47:57 <devrandom> ah, right...
 470 2011-09-27 15:48:01 <devrandom> I haven't compared them yet
 471 2011-09-27 15:48:12 <devrandom> dang, Jenkins has a lot of extension points
 472 2011-09-27 15:48:34 <gmaxwell> The C rules in that are really thin.
 473 2011-09-27 15:49:04 earthmeLon has joined
 474 2011-09-27 15:49:04 earthmeLon has quit (Changing host)
 475 2011-09-27 15:49:04 earthmeLon has joined
 476 2011-09-27 15:49:45 <sipa> casascius: in the discussion of pull #492 rose the idea of a separate tool that would do a full verification of a block chain file
 477 2011-09-27 15:49:50 <devrandom> I'll focus on Jenkins for now
 478 2011-09-27 15:50:13 <casascius> sipa: has anyone done any work on this tool
 479 2011-09-27 15:50:14 <sipa> casascius: it sounds like the right place to allow that tool to perform blkindex.dat rebuilding as well
 480 2011-09-27 15:50:18 <sipa> no
 481 2011-09-27 15:50:38 <sipa> but i don't think it's hard, you can reuse (possibly share) quite some code with bitcoind
 482 2011-09-27 15:50:58 <casascius> sipa: what would be verified?  the full chain structure?  or just that, for example, the file can be walked without any truncated blocks etc.
 483 2011-09-27 15:51:20 <sipa> the same as is done now while downloading the chain
 484 2011-09-27 15:51:30 <sipa> so, full check
 485 2011-09-27 15:51:34 <sipa> including signatures
 486 2011-09-27 15:51:36 <gmaxwell> I was thinking about writing a compressed format for the blockchain which validated it as a side effect (because most invalid things would be unrepresentable)
 487 2011-09-27 15:51:38 <casascius> sipa: can you give me the tl;dr on why this would be desirable as a separate tool rather than as part of the client?
 488 2011-09-27 15:52:06 zhoutong has joined
 489 2011-09-27 15:52:23 <sipa> gmaxwell: what do you mean with compressed format?
 490 2011-09-27 15:53:05 <sipa> casascius: the main client won't be doing signature verification for blocks below the last lock-in
 491 2011-09-27 15:54:33 wpl has quit (Ping timeout: 258 seconds)
 492 2011-09-27 15:54:42 <casascius> sipa: do we need or want such verification to occur?  it seems to me that such verification would be skipped for a pretty good reason
 493 2011-09-27 15:54:53 <gmaxwell> ...
 494 2011-09-27 15:55:42 <sipa> it's certainly useful from a performance perspective
 495 2011-09-27 15:55:49 <casascius> in fact, if it were embedded in the client, a rebuild might also be an opportunity to discard any orphaned blocks below the last checkin point
 496 2011-09-27 15:56:12 wpl has joined
 497 2011-09-27 15:56:25 <gmaxwell> sipa: Smaller files that can be distributed to new full nodes to avoid the need to syncup over the network, which conserves space by omitting data which can be calculated directly (e.g. the prev hash in the header is the hash of the prior block), or which is restricted by the rules e.g. timestamps can be coded as UINT(median of last 11+1,2^31) (or better, with an unequal pdf that favors the real timestamp distribution)
 498 2011-09-27 15:57:20 <sipa> gmaxwell: sounds interesting
 499 2011-09-27 15:58:01 <sipa> but how far will you go
 500 2011-09-27 15:58:18 <casascius> what would really save a lot of space is if those "smaller files" could be stripped of all spent transactions, and the hash of them included in the block chain
 501 2011-09-27 15:58:21 glitch-mod has quit (Ping timeout: 240 seconds)
 502 2011-09-27 15:58:37 <sipa> eg, whether a particular txout is spent, can also be inferred
 503 2011-09-27 15:58:44 <casascius> i realize there's more questions than answers with respect to that, but that's going to become a concern faster than it can be dealt with, i fear
 504 2011-09-27 15:58:52 <sipa> casascius: a full node can't do that
 505 2011-09-27 15:59:19 <gmaxwell> sipa: yes, for TXINs I was expecting to purely code the index of the possible unspent inputs instead of the hash.
 506 2011-09-27 15:59:20 earthmeLon has quit (Quit: Leaving)
 507 2011-09-27 15:59:56 SomeoneWeird is now known as SomeoneWeirdzzzz
 508 2011-09-27 16:00:08 <gmaxwell> Of course, it would recover the hash, and that feeds into the signatures.. so ultimately a single hash will almost prove that the decode from such a tool is a valid rules following blockchain.
 509 2011-09-27 16:00:19 <sipa> gmaxwell: hmm, what about a per-tx bit vector?
 510 2011-09-27 16:01:03 realazthat has joined
 511 2011-09-27 16:03:24 BTCTrader_ has quit (Quit: BTCTrader_)
 512 2011-09-27 16:04:58 erus` has quit (Remote host closed the connection)
 513 2011-09-27 16:06:33 normanrichards has quit (Quit: normanrichards)
 514 2011-09-27 16:06:53 rdponticelli has joined
 515 2011-09-27 16:06:53 Titeuf_87 has joined
 516 2011-09-27 16:08:17 <sacarlson> I've been working on a simple plugin  method for multicoin to enable added and modified features of the core bitcoin system to support testing and prototypes of new chains
 517 2011-09-27 16:08:59 <sacarlson> and modifications of present chains
 518 2011-09-27 16:09:45 <sacarlson> any one else working on such things?
 519 2011-09-27 16:10:30 iocor has quit (Quit: Computer has gone to sleep.)
 520 2011-09-27 16:12:45 <sipa> gmaxwell: if time is a pure poisson process with rate factor 1/600s, you need 10.68 bits :)
 521 2011-09-27 16:12:56 gwillen has quit (Ping timeout: 256 seconds)
 522 2011-09-27 16:14:40 rdponticelli has quit (Ping timeout: 248 seconds)
 523 2011-09-27 16:15:13 rdponticelli has joined
 524 2011-09-27 16:16:04 <sipa> gmaxwell: as the version is fixed, the prevhash is known, the merkle root can be calculated from the transactions, the timestamp doesn't need more than 16 bits, nBits can be derived from the previous blocks, only nonce remains in the block header
 525 2011-09-27 16:16:34 <sipa> so you'd need let's say 6 bytes + #transactions for a block header?
 526 2011-09-27 16:16:41 topace has joined
 527 2011-09-27 16:16:51 <gmaxwell> Yes, and if I want to be totally nuts I can drop 8 bits or so from the nonce and let the decoder solve the block.
 528 2011-09-27 16:17:03 mmoya has quit (Ping timeout: 260 seconds)
 529 2011-09-27 16:17:07 <gmaxwell> (and have a bit coded with very high probablity to signal that the first solution was the right one)
 530 2011-09-27 16:17:25 <sipa> transactions themselves are harder
 531 2011-09-27 16:17:47 <gmaxwell> Use a table of previously used scripts. So almost all scripts cost ~nothing to code.
 532 2011-09-27 16:18:01 <sipa> yup
 533 2011-09-27 16:18:24 <gmaxwell> tx_inputs get coded based on the set of all possible inputs.. but after they're selected the output values are constrained.
 534 2011-09-27 16:18:40 <gmaxwell> I can't do much with the signature, but with it I can recover the public key.
 535 2011-09-27 16:19:00 <sipa> use a reference of the style "N blocks ago, transaction M" instead of txins?
 536 2011-09-27 16:19:22 <sipa> hmm, that's quite expensive
 537 2011-09-27 16:19:29 <gmaxwell> Well I was thinking of simply sorting the inputs most recent to least recent and using a non-uniform coding of the integer.
 538 2011-09-27 16:19:58 <gmaxwell> I'd have to look at the data to pick a good coding scheme.
 539 2011-09-27 16:20:30 <sipa> most recent to least recent, disregarding already spent ones?
 540 2011-09-27 16:20:42 <gmaxwell> Right.
 541 2011-09-27 16:20:47 <gmaxwell> (I assume it would look like a linear ramp down to uniform probably a few hundred blocks back)
 542 2011-09-27 16:22:26 <sipa> i'm very interesting :)
 543 2011-09-27 16:22:29 Cokein_ has joined
 544 2011-09-27 16:23:11 <sipa> *interestED
 545 2011-09-27 16:23:12 <sipa> damn
 546 2011-09-27 16:24:47 rdponticelli has quit (Read error: Connection reset by peer)
 547 2011-09-27 16:24:58 mmoya has joined
 548 2011-09-27 16:25:02 mmoya has quit (Read error: Connection reset by peer)
 549 2011-09-27 16:25:15 mmoya has joined
 550 2011-09-27 16:25:20 Cokein has quit (Ping timeout: 248 seconds)
 551 2011-09-27 16:26:06 <casascius> I have expanded my bounty offering to include a payable bounty for implementing sweepprivkey, and the total bounty is 100 BTC
 552 2011-09-27 16:26:21 <gmaxwell> One possibility is that instead of writing out a block chain (or in addition to) it writes out the final set of open transactions, and a minimal perfect hash for doing lookups against it... and we teach the node software to use that instead of a blockchain for validation prior to the checkpoint.  It would take up a LOT less disk.
 553 2011-09-27 16:26:31 <gmaxwell> (and be a lot faster)
 554 2011-09-27 16:27:02 TheAncientGoat has joined
 555 2011-09-27 16:27:24 Disposition has joined
 556 2011-09-27 16:28:09 Detritus has joined
 557 2011-09-27 16:28:11 pensan has joined
 558 2011-09-27 16:28:16 <sipa> so you need a compact representation for a map txid:outid -> amount, for all unspent outputs?
 559 2011-09-27 16:28:28 <sipa> oh, and script
 560 2011-09-27 16:29:13 <gmaxwell> Well, you just write the actual txns out (perhaps with some compression, e.g. a common script table), and make a compact map to map the txid to byte offset.
 561 2011-09-27 16:29:18 Disposition1 has quit (Ping timeout: 260 seconds)
 562 2011-09-27 16:30:06 <gmaxwell> There are algorithims for writing these tables which produce encodings which are very efficient, much more so than anything that makes incremental updates cheap. :)
 563 2011-09-27 16:30:23 pensan has quit (Client Quit)
 564 2011-09-27 16:30:30 <sipa> casascius: Privkeys appearing in transactions (e.g. coinbase) need to be converted to a binary bitcoin address before being added as keys to this index.
 565 2011-09-27 16:30:36 <sipa> you mean pubkeys, i suppose?
 566 2011-09-27 16:30:40 pensan has joined
 567 2011-09-27 16:32:00 <gmaxwell> I suppose to make casascius happy it could also write out an address lookup structure too... though scanning all the open txn nicely packed would already be a lot cheaper than scanning the whole blockchain.
 568 2011-09-27 16:33:14 <casascius> yep pubkeys, thanks, i will fix ity
 569 2011-09-27 16:34:46 <sipa> gmaxwell: i expect that you're able to reduce the size of the blockchain by a factor, if you do all that
 570 2011-09-27 16:35:52 ephcon has joined
 571 2011-09-27 16:37:58 clr_ has joined
 572 2011-09-27 16:39:15 Cokein_ has quit (Read error: Connection reset by peer)
 573 2011-09-27 16:39:39 Cokein_ has joined
 574 2011-09-27 16:40:55 zhoutong has quit (Read error: Connection reset by peer)
 575 2011-09-27 16:41:13 <gmaxwell> Any idea what the total number of txouts there ever was is?
 576 2011-09-27 16:41:51 zhoutong has joined
 577 2011-09-27 16:43:03 glitch-mod has joined
 578 2011-09-27 16:44:02 erus` has joined
 579 2011-09-27 16:46:08 <gmaxwell> In any case, it would be _much_ smaller than the current data. Possibly small enough that we could just ship the historic chain with the software.
 580 2011-09-27 16:46:40 ephcon has quit (Ping timeout: 248 seconds)
 581 2011-09-27 16:47:45 glitch-mod has quit (Max SendQ exceeded)
 582 2011-09-27 16:48:48 glitch-mod has joined
 583 2011-09-27 16:49:13 iocor has joined
 584 2011-09-27 16:58:32 minimoose has joined
 585 2011-09-27 16:59:02 ephcon has joined
 586 2011-09-27 16:59:36 E-sense has quit (Quit: System.exit(0);)
 587 2011-09-27 17:00:15 mosimo has joined
 588 2011-09-27 17:01:17 <epscy> casascius: i got some coins I ordered from you today, just wanted to say thanks
 589 2011-09-27 17:01:32 <epscy> sorry i meant to priv msg that
 590 2011-09-27 17:02:24 TheAncientGoat has quit (Ping timeout: 245 seconds)
 591 2011-09-27 17:02:49 <epscy> but since i brought up the topic, did you consider translating the the address to a barcode and putting that on the hologram as well as the first 8 chars?
 592 2011-09-27 17:03:30 <epscy> seems like that would make it easy to automatically verify the coin is worth what it says it is
 593 2011-09-27 17:04:52 ThomasV has quit (Quit: Leaving)
 594 2011-09-27 17:07:19 Kolky has joined
 595 2011-09-27 17:08:45 Blitzboom has quit (Remote host closed the connection)
 596 2011-09-27 17:09:57 Cokein_ has quit (Read error: Connection reset by peer)
 597 2011-09-27 17:10:19 Cokein_ has joined
 598 2011-09-27 17:10:36 <sipa> gmaxwell: i'm generating some statistics
 599 2011-09-27 17:11:35 Blitzboom has joined
 600 2011-09-27 17:11:35 Blitzboom has quit (Changing host)
 601 2011-09-27 17:11:35 Blitzboom has joined
 602 2011-09-27 17:12:27 Blitzboom has quit (Remote host closed the connection)
 603 2011-09-27 17:13:02 Blitzboom has joined
 604 2011-09-27 17:13:18 Blitzboom has quit (Client Quit)
 605 2011-09-27 17:13:33 <casascius> thanks for ordering the coins...yeah i consdiered the barcode but chose not to...limited space, and hologram company couldn't do 2d barcodes on them
 606 2011-09-27 17:13:41 pumpkin has joined
 607 2011-09-27 17:14:38 Blitzboom has joined
 608 2011-09-27 17:14:38 Blitzboom has quit (Changing host)
 609 2011-09-27 17:14:38 Blitzboom has joined
 610 2011-09-27 17:14:56 copumpkin has quit (Ping timeout: 248 seconds)
 611 2011-09-27 17:16:02 pumpkin is now known as copumpkin
 612 2011-09-27 17:18:06 <nanotube> casascius: you sure 8 is enough? in the gpg keyid space, there are already known to be collisions at 8digit id level...
 613 2011-09-27 17:18:14 localhost has quit (Remote host closed the connection)
 614 2011-09-27 17:19:35 clr_ is now known as c00w
 615 2011-09-27 17:19:37 <casascius> 8 is not enough to rule out collisions, just enough to make them unlikely for the casual task of verifying the balance.  I have PGP signed a full list of my coins
 616 2011-09-27 17:19:49 <casascius> or at least the addresses I have generated and had printed on stickers
 617 2011-09-27 17:19:51 <epscy> casascius: ahh fair enough, i didn't think i was the first to think of it
 618 2011-09-27 17:20:06 <sipa> gmaxwell: 3608559 txouts, 1032828 unspent txouts
 619 2011-09-27 17:21:36 TheAncientGoat has joined
 620 2011-09-27 17:21:47 localhost has joined
 621 2011-09-27 17:22:43 glitch-mod has quit (Ping timeout: 258 seconds)
 622 2011-09-27 17:25:14 <AlexWaters> sipa: do you have a recommendation for testing #524? Gavin mentioned unit tests, were these added in your 9/20 commit?
 623 2011-09-27 17:25:28 <sipa> no, i didn't write any
 624 2011-09-27 17:26:12 <gmaxwell> sipa: so... maybe on the order of 319 MB for the blockchain, from some fairly conservative numbers based on those counts.
 625 2011-09-27 17:27:33 <AlexWaters> sipa: ok - i'll try some manual tests for now, but I think a unit test will help it get merged faster
 626 2011-09-27 17:27:47 <gmaxwell> almost all of that is from signatures.
 627 2011-09-27 17:29:38 zhoutong has quit (Read error: Connection reset by peer)
 628 2011-09-27 17:29:52 ephcon has quit (Ping timeout: 248 seconds)
 629 2011-09-27 17:29:58 <sipa> gmaxwell: i assume you can encode all scripts using the following trick: extract all constant numbers, match table of 255 most-frequently occuring scripts, if so, output # + constants, otherwise output 0 + original script
 630 2011-09-27 17:30:23 zhoutong has joined
 631 2011-09-27 17:30:36 <sipa> oh wait, you want pubkeys/hash160 using key recovery
 632 2011-09-27 17:32:02 zhoutong has quit (Read error: Connection reset by peer)
 633 2011-09-27 17:32:45 zhoutong has joined
 634 2011-09-27 17:33:21 <sipa> AlexWaters: i'll add a test for base64 encoding/decoding
 635 2011-09-27 17:33:30 <AlexWaters> sipa: awesome, thank you!
 636 2011-09-27 17:34:41 <tcatm> do we have a testsuite that will compile bitcoin on all target platforms?
 637 2011-09-27 17:35:01 <BlueMatt> jenkins does ubuntu+win32
 638 2011-09-27 17:35:04 <BlueMatt> no osx
 639 2011-09-27 17:35:25 <BlueMatt> (and does sanity testing of the binaries - open, download part of chain, make rpc calls, etc)
 640 2011-09-27 17:35:48 <tcatm> hrm. I have replaced all crypto++ calls with openssl but I need to modify all makefiles to remove crypto++ completely
 641 2011-09-27 17:35:54 <BlueMatt> well gui is disabled atm because I have to figure out how to compile qt on mingw on linux...
 642 2011-09-27 17:37:14 <AlexWaters> BlueMatt: very cool, is the bot operational?
 643 2011-09-27 17:37:49 <gmaxwell> sipa: hm. actually thats way high because I was also assuming signatures on the unspent tx.
 644 2011-09-27 17:38:14 TheAncientGoat has quit (Ping timeout: 245 seconds)
 645 2011-09-27 17:38:25 <BlueMatt> it exists, operational...not so much.  Ive got to get qt cross compiling first so jenkins kinda fell to the backburner...that said, you can take a look at jenkins.bluematt.me now (I can give you a login) and can easily clone the bitcoin job to point to any random git repo you like
 646 2011-09-27 17:38:26 <gmaxwell> yea, can't recover pubkey in txout though... because it might never be spent.
 647 2011-09-27 17:41:27 <AlexWaters> BlueMatt: that would be awesome. i'm interested to see what options are available when I log in
 648 2011-09-27 17:41:51 <AlexWaters> which*
 649 2011-09-27 17:43:05 Props is now known as cdubs
 650 2011-09-27 17:43:23 <nanotube> casascius: well, i guess the question is, if you have a cascoin, you check by 8 digits, and you find a collision - is there any alternative to breaking open the coin to check, to verify what you have?
 651 2011-09-27 17:43:49 cdubs has left ("Leaving")
 652 2011-09-27 17:43:52 <casascius> nanotube: yeah I published a pgp-signed pastebin of all the coins i have used so far...and put the link in the forums
 653 2011-09-27 17:43:54 <AlexWaters> bluematt: do you know how many builds can this do simultaneously, and the build time? I'm curious about any performance limitations
 654 2011-09-27 17:44:05 <nanotube> casascius: ah ok
 655 2011-09-27 17:44:11 <casascius> i prepared 11000 addresses and published about the first 3500 of them
 656 2011-09-27 17:44:29 BlueMattBot has quit ()
 657 2011-09-27 17:44:58 <BlueMatt> AlexWaters: in theory as many as the vm can handle, its currently limited to 1 due to the way I originally wrote the test scripts (they collide if you start running a build while testing), but that could be changed
 658 2011-09-27 17:45:19 BlueMattBot has joined
 659 2011-09-27 17:45:23 <BlueMatt> in theory you could even add other vms so that you could do more...
 660 2011-09-27 17:45:53 BlueMattBot has quit (Changing host)
 661 2011-09-27 17:45:53 BlueMattBot has joined
 662 2011-09-27 17:46:02 <casascius> http://pastebin.com/XebW67V4
 663 2011-09-27 17:47:40 <AlexWaters> BlueMatt: this sounds awesome. I'm very excited. When did you add the blockchain download test, and is it public?
 664 2011-09-27 17:48:30 <BlueMatt> AlexWaters: you can take a look at the scripts being run under configure in the side bar of any project
 665 2011-09-27 17:48:40 <BlueMatt> the blockchain download sanity check is in Bitcoind-sanitytest
 666 2011-09-27 17:50:04 <BlueMatt> bbiab
 667 2011-09-27 17:50:07 BlueMatt has quit (Quit: Ex-Chat)
 668 2011-09-27 17:51:21 BlueMatt has joined
 669 2011-09-27 17:52:56 <AlexWaters> BlueMatt: I have a bunch of questions, OK to email them to you?
 670 2011-09-27 17:53:22 BlueMatt has quit (Read error: Operation timed out)
 671 2011-09-27 17:53:57 <tcatm> could someone have a look at https://github.com/tcatm/bitcoin/commit/e1632950ce1202b1cc421041a90715afbcb36521 before I make a pull request and check whether I got all makefiles right?
 672 2011-09-27 17:56:07 BlueMatt has joined
 673 2011-09-27 17:56:09 BlueMatt has quit (Changing host)
 674 2011-09-27 17:56:09 BlueMatt has joined
 675 2011-09-27 17:56:44 ephcon has joined
 676 2011-09-27 17:57:45 <midnightmagic> tcatm: why are you stripping out cryptopp?
 677 2011-09-27 17:58:32 <BlueMatt> midnightmagic: why keep it?
 678 2011-09-27 17:58:55 <tcatm> midnightmagic: there's no good reason to keep it around when the internal mining isn't optimized for speed
 679 2011-09-27 17:59:50 <midnightmagic> Well, the naive answer would be because Wei Dai is a god. But that's just because I don't know why it's going away because I haven't been paying much attention to bitcoin development the last few months.
 680 2011-09-27 18:00:19 <jrmithdobbs> midnightmagic: it's only used in the mining code
 681 2011-09-27 18:00:21 <BlueMatt> mostly because its an extra dep that is (for some reason?) in our src tree and it really isnt used for much of anything
 682 2011-09-27 18:00:42 <midnightmagic> well okay then. :) i suppose all mining is going to be external, even for forks anyway.
 683 2011-09-27 18:01:06 <midnightmagic> just curious really, I'm not challenging the wisdom of it or anything.
 684 2011-09-27 18:01:57 c00w has quit (Ping timeout: 240 seconds)
 685 2011-09-27 18:02:37 <sipa> AlexWaters: simple test case added (RFC4648 test vectors)
 686 2011-09-27 18:05:43 <sipa> AlexWaters: tests for message signing are somewhat harder, as they require a functional wallet with a key in it
 687 2011-09-27 18:05:56 coblee has quit (Quit: coblee)
 688 2011-09-27 18:06:02 mmoya has quit (Ping timeout: 255 seconds)
 689 2011-09-27 18:06:50 coblee has joined
 690 2011-09-27 18:07:11 t3a has quit (Ping timeout: 258 seconds)
 691 2011-09-27 18:07:52 Diablo-D3 has quit (Ping timeout: 252 seconds)
 692 2011-09-27 18:14:52 <AlexWaters> thanks sipa
 693 2011-09-27 18:15:37 <sipa> though i think that would be very interesting, modifying CWallet so that it can manage an in-memory wallet
 694 2011-09-27 18:15:57 <sipa> using a fake clock, and possibly artificially low difficulty
 695 2011-09-27 18:16:05 <sipa> to simulate more complex situations
 696 2011-09-27 18:18:00 Sedra has quit (Remote host closed the connection)
 697 2011-09-27 18:20:01 kish is now known as GLK
 698 2011-09-27 18:22:39 ThomasV has joined
 699 2011-09-27 18:25:34 GLK is now known as glk4
 700 2011-09-27 18:31:27 glk4 is now known as kishy
 701 2011-09-27 18:33:52 ephcon has quit (Ping timeout: 248 seconds)
 702 2011-09-27 18:34:27 osmosis has joined
 703 2011-09-27 18:35:44 datagutt has quit (Quit: kthxbai)
 704 2011-09-27 18:42:52 RazielZ has quit (Quit: Leaving)
 705 2011-09-27 18:43:17 larsivi has joined
 706 2011-09-27 18:47:27 c00w has joined
 707 2011-09-27 18:48:09 E-sense has joined
 708 2011-09-27 18:57:57 luke-jr has quit (Remote host closed the connection)
 709 2011-09-27 18:58:13 luke-jr has joined
 710 2011-09-27 18:58:44 ThomasV has quit (Ping timeout: 260 seconds)
 711 2011-09-27 18:59:33 c00w has quit (Ping timeout: 240 seconds)
 712 2011-09-27 19:00:53 c00w has joined
 713 2011-09-27 19:02:36 zhoutong has quit (Read error: Connection reset by peer)
 714 2011-09-27 19:03:24 zhoutong has joined
 715 2011-09-27 19:11:02 shLONG has joined
 716 2011-09-27 19:11:08 magn3ts has quit (Quit: Leaving)
 717 2011-09-27 19:14:21 c00w has quit (Ping timeout: 240 seconds)
 718 2011-09-27 19:15:37 c00w has joined
 719 2011-09-27 19:17:27 gjs278 has quit (Remote host closed the connection)
 720 2011-09-27 19:23:27 luke-jr has quit (Excess Flood)
 721 2011-09-27 19:23:40 luke-jr has joined
 722 2011-09-27 19:23:55 c00w has quit (Ping timeout: 244 seconds)
 723 2011-09-27 19:24:36 peck has quit (Read error: Connection reset by peer)
 724 2011-09-27 19:27:42 c00w has joined
 725 2011-09-27 19:29:18 p0s has joined
 726 2011-09-27 19:30:54 zhoutong has quit (Read error: Connection reset by peer)
 727 2011-09-27 19:31:34 zhoutong has joined
 728 2011-09-27 19:31:53 flok has quit (Ping timeout: 260 seconds)
 729 2011-09-27 19:32:23 peck has joined
 730 2011-09-27 19:36:19 c00w has quit (Ping timeout: 244 seconds)
 731 2011-09-27 19:36:28 shLONG has quit ()
 732 2011-09-27 19:37:31 flok has joined
 733 2011-09-27 19:38:49 rdponticelli has joined
 734 2011-09-27 19:40:45 ByronJohnson has quit (Ping timeout: 245 seconds)
 735 2011-09-27 19:41:44 Sedra has joined
 736 2011-09-27 19:42:32 ByronJohnson has joined
 737 2011-09-27 19:43:34 clr_ has joined
 738 2011-09-27 19:45:23 duck1123 has left ()
 739 2011-09-27 19:45:24 zhoutong has quit (Read error: Connection reset by peer)
 740 2011-09-27 19:45:43 zhoutong has joined
 741 2011-09-27 19:51:30 YifuGuo has joined
 742 2011-09-27 19:55:58 clr_ has quit (Ping timeout: 240 seconds)
 743 2011-09-27 19:57:29 zamgo has joined
 744 2011-09-27 20:00:03 clr_ has joined
 745 2011-09-27 20:01:01 clr_ is now known as c00w
 746 2011-09-27 20:02:29 da2ce7 has quit (Remote host closed the connection)
 747 2011-09-27 20:02:36 ByteCoin has joined
 748 2011-09-27 20:03:04 da2ce7 has joined
 749 2011-09-27 20:03:18 <ByteCoin> ;;seen copumpkin
 750 2011-09-27 20:03:18 <gribble> copumpkin was last seen in #bitcoin-dev 4 hours, 40 minutes, and 20 seconds ago: <copumpkin> BlueMatt: out of curiosity, you understand elliptic curves? I saw you asking about them yesterday
 751 2011-09-27 20:05:43 <ByteCoin> ;;later tell copumpkin You were talking about ECC and pairing-based stuff. I am reasonably expert if you wish to discuss something.
 752 2011-09-27 20:05:44 <gribble> The operation succeeded.
 753 2011-09-27 20:06:25 <sipa> ByteCoin: did you see i modified the message signature thing to use key recovery?
 754 2011-09-27 20:07:06 clr__ has joined
 755 2011-09-27 20:08:45 Lopuz has quit (Ping timeout: 255 seconds)
 756 2011-09-27 20:08:53 <copumpkin> yo
 757 2011-09-27 20:09:04 <copumpkin> ByteCoin: oh, was just wondering if anyone around here had played with them :) didn't have any particular questions
 758 2011-09-27 20:10:30 <ByteCoin> sipa: I saw it. It's excellent.
 759 2011-09-27 20:10:46 da2ce7 has quit (Ping timeout: 240 seconds)
 760 2011-09-27 20:10:49 <sipa> i hope the implementation is sound
 761 2011-09-27 20:10:50 <ByteCoin> copumpkin: Ok.
 762 2011-09-27 20:11:14 <ByteCoin> sipa: Me too. These things are hard to edge test
 763 2011-09-27 20:11:15 <sipa> it's quite a few steps, and i've always learned you shouldn't implement cryptographic primitives yourself :)
 764 2011-09-27 20:11:56 <copumpkin> unless it's in haskell
 765 2011-09-27 20:12:03 <sipa> even then
 766 2011-09-27 20:12:13 <sipa> agreed, there is less chance for implementation errors
 767 2011-09-27 20:12:17 <ByteCoin> I'm glad we're using base64 too.
 768 2011-09-27 20:12:21 <sipa> but there may be edge cases you need to be aware of
 769 2011-09-27 20:12:27 <copumpkin> well, you'd want an Integer implementation that doesn't have short-circuiting
 770 2011-09-27 20:12:38 <copumpkin> and would probably want to avoid being lazy :)
 771 2011-09-27 20:12:43 <copumpkin> since that is also effectively short-circuiting
 772 2011-09-27 20:12:44 clr__ has quit (Quit: Ex-Chat)
 773 2011-09-27 20:12:51 <copumpkin> (to avoid leaking timing information)
 774 2011-09-27 20:12:53 <ByteCoin> copumpkin: Timing attacks are not an issue
 775 2011-09-27 20:13:04 <copumpkin> I was just talking about implementing crypto in general
 776 2011-09-27 20:13:07 <copumpkin> in haskell
 777 2011-09-27 20:13:10 <ByteCoin> Ok
 778 2011-09-27 20:13:19 <copumpkin> not even sure what you guys are talking about :)
 779 2011-09-27 20:13:29 <sipa> ECDSA key recovery
 780 2011-09-27 20:13:58 <ByteCoin> If you want to avoid timing attacks then changing the curve basis to something like Edwards curves would be better
 781 2011-09-27 20:14:44 <ByteCoin> sipa: When will your signature code go mainline?
 782 2011-09-27 20:14:45 <gmaxwell> sipa: oh you implemented recovery for the signing?   <3
 783 2011-09-27 20:14:53 <gmaxwell> <3 <3 <3
 784 2011-09-27 20:15:07 <gmaxwell> and base 64 too?
 785 2011-09-27 20:15:13 <sipa> yes
 786 2011-09-27 20:15:19 <sipa> i suppose i should submit the ECDSA_SIG_recover_key_GFp function to OpenSSL, though
 787 2011-09-27 20:15:21 huk has joined
 788 2011-09-27 20:15:23 <sipa> :)
 789 2011-09-27 20:15:50 <gmaxwell> sipa: good, you've saved me the trouble of writing recovery for the compressor should I get around to writing it.
 790 2011-09-27 20:16:27 <ByteCoin> gmaxwell: Were you asking about taking advanage of the special format of p for doing the ECC arithmetic?
 791 2011-09-27 20:16:28 <sipa> gmaxwell: i wrote the actual key recovery function months ago
 792 2011-09-27 20:17:11 TbbW has quit (Ping timeout: 256 seconds)
 793 2011-09-27 20:17:11 arowana has joined
 794 2011-09-27 20:17:22 <gmaxwell> ByteCoin: well, in general writing faster validation code specialized for the curve bitcoin uses.
 795 2011-09-27 20:17:51 sprash has joined
 796 2011-09-27 20:18:12 da2ce7 has joined
 797 2011-09-27 20:18:57 BlueMatt has quit (Ping timeout: 248 seconds)
 798 2011-09-27 20:19:27 TbbW has joined
 799 2011-09-27 20:19:42 <ByteCoin> gmaxwell: Ok. I have a noddy implementation which seems to work but is not rigorously tested
 800 2011-09-27 20:20:06 <ByteCoin> I'd also like you to compare your compression idea with https://bitcointalk.org/index.php?topic=505.0
 801 2011-09-27 20:20:29 Tuxavant has quit (Read error: Connection reset by peer)
 802 2011-09-27 20:22:09 <sipa> ByteCoin: with "special format of p", you refer to the koblitz curve we're using?
 803 2011-09-27 20:23:03 <ByteCoin> sipa: I hate the "Koblitz" terminology. It only applies to curves over GF(2^n)
 804 2011-09-27 20:23:13 rdponticelli has quit (Ping timeout: 248 seconds)
 805 2011-09-27 20:23:16 <sipa> really? that explains a lot :D
 806 2011-09-27 20:23:31 <sipa> still, the k in secp256k1 stands for Koblitz, no?
 807 2011-09-27 20:23:32 sprash has quit (Quit: Ex-Chat)
 808 2011-09-27 20:23:53 <ByteCoin> sipa: Only because the namers of the curve were....
 809 2011-09-27 20:23:58 <sipa> ok :)
 810 2011-09-27 20:24:02 <gmaxwell> sipa: damnit this is why I keep thinking that we have a binary field.
 811 2011-09-27 20:24:21 <sipa> i guess the "256" number doesn't help either
 812 2011-09-27 20:24:38 <ByteCoin> ...trying to come up with a short indicator of its special structure
 813 2011-09-27 20:25:06 <gmaxwell> ByteCoin: I independantly proposed a very similar balance sheet committment scheme (taking as inspiration the impossiblity of secure lite nodes in namecoin), I think you even replied to that pointing out you had considered something similar. :)
 814 2011-09-27 20:25:20 <sipa> anyway, ByteCoin, you have any idea what kind of speedup would be possible for signing/verifying by exploiting the special structure?
 815 2011-09-27 20:25:23 <gmaxwell> well I don't know about very similar, at least similar. :)
 816 2011-09-27 20:25:39 <ByteCoin> gmaxwell: I think it's the way forward
 817 2011-09-27 20:25:49 Tuxavant has joined
 818 2011-09-27 20:26:05 <jrmithdobbs> speaking of ... has anyone tested if the locking changes have sped up key generation/signing/verifying?
 819 2011-09-27 20:26:06 <ByteCoin> sipa: No, not offhand. Could be quite substantial though...
 820 2011-09-27 20:26:26 <ByteCoin> I believe openssl uses montgomery reduction
 821 2011-09-27 20:26:31 <gmaxwell> ByteCoin: the new intel CPUs have a carryless multiply instruction that might be useful.
 822 2011-09-27 20:26:51 <sipa> jrmithdobbs: as locking was only made more coarse, i doubt anything sped up
 823 2011-09-27 20:27:03 <jrmithdobbs> oh i thought it was other way around
 824 2011-09-27 20:27:03 <sipa> (sped? speeded?)
 825 2011-09-27 20:27:04 <ByteCoin> So that's good but probably requires about 2x the number of 256 bit multiplies
 826 2011-09-27 20:28:13 <ByteCoin> gmaxwell: Carryless multiplies are not obviously useful.. Proper code would use the FPU
 827 2011-09-27 20:28:19 m00p has joined
 828 2011-09-27 20:28:31 <ByteCoin> See Dan Bernstein's curve25519 for inspiration
 829 2011-09-27 20:28:46 <jrmithdobbs> i was looking at that the other day
 830 2011-09-27 20:28:51 <jrmithdobbs> pretty awesome
 831 2011-09-27 20:28:59 <sipa> i read about it
 832 2011-09-27 20:29:10 <sipa> would it have been a good alternative for secp256k1?
 833 2011-09-27 20:29:13 <ByteCoin> Also if you want speed then there's a brand of fpu assembler he writes which is good
 834 2011-09-27 20:29:15 <gmaxwell> ByteCoin: well, they're super useful on the binary field.
 835 2011-09-27 20:29:26 <ByteCoin> gmaxwell: Correct
 836 2011-09-27 20:29:34 <jrmithdobbs> sipa: i'm honestly not sure
 837 2011-09-27 20:29:46 da2ce7 has quit (Remote host closed the connection)
 838 2011-09-27 20:29:48 <ByteCoin> sipa: It would have been good. Better curves exist now...
 839 2011-09-27 20:29:49 <sipa> i read something about only useful for ECDH, not signing
 840 2011-09-27 20:29:56 <jrmithdobbs> sipa: yes and no as far as better
 841 2011-09-27 20:30:34 <ByteCoin> sipa: Not sure how that would work...
 842 2011-09-27 20:30:40 <gmaxwell> sipa: well djb only implemented ECDH.
 843 2011-09-27 20:30:57 <gmaxwell> But I think other people have implemented signing on that curve.
 844 2011-09-27 20:31:00 da2ce7 has joined
 845 2011-09-27 20:33:58 c00w has quit (Ping timeout: 240 seconds)
 846 2011-09-27 20:33:58 zhoutong has quit (Read error: Connection reset by peer)
 847 2011-09-27 20:34:13 <ByteCoin> gmaxwell: The key point of my "balance sheets" proposal was to turn the block chain on it's head so that you'd download the latest blocks and go backwards.
 848 2011-09-27 20:34:29 <ByteCoin> Let's face it! How useful are blocks 1 - 100000?
 849 2011-09-27 20:34:37 sacarlson has quit (Ping timeout: 252 seconds)
 850 2011-09-27 20:35:05 zhoutong has joined
 851 2011-09-27 20:35:24 <gmaxwell> ByteCoin: yea, my primary concern was making is possible for a node with no transaction history to validate a input with high confidence.
 852 2011-09-27 20:35:27 <iz> ByteCoin: how would you prevent ppl from double spending coins that were spent in block 1 - 100000?
 853 2011-09-27 20:36:16 <gmaxwell> E.g. take a summary hash from N blocks deep before its spending, ask for the tree fragment that connects that open txn from the committed root hash of open txn. And then you're reasonably confident that the txn was actually open at that time.
 854 2011-09-27 20:36:24 <gmaxwell> iz: go read the proposal.
 855 2011-09-27 20:36:38 <iz> yeah, i just read scrollback and i'm reading it now
 856 2011-09-27 20:36:54 <gmaxwell> It's a perfectly reasonable idea.
 857 2011-09-27 20:36:59 arowana has quit (Quit: Ex-Chat)
 858 2011-09-27 20:37:36 <sipa> i like the idea of putting a hash of a hash-tree-of-unspent-txouts in the coinbase someday
 859 2011-09-27 20:37:43 zamgo has left ()
 860 2011-09-27 20:37:56 <sipa> gmaxwell: you came up with that, right?
 861 2011-09-27 20:37:58 <ByteCoin> iz: The "balance sheet" is a current list of unspent transactions. You download that first and its hash is in the block header
 862 2011-09-27 20:38:20 c00w has joined
 863 2011-09-27 20:38:29 <iz> hmm..
 864 2011-09-27 20:38:31 <gmaxwell> sipa: yes, well, so did bytecoin, effectively.
 865 2011-09-27 20:38:36 <sipa> hmm, ok :)
 866 2011-09-27 20:38:39 <iz> but if clients prefer to use the balance sheet to catch up..
 867 2011-09-27 20:38:57 <iz> an attacker only really has to fake 1 block to mess everything up, right?
 868 2011-09-27 20:39:20 <gmaxwell> nope, you use a burried balance sheet.
 869 2011-09-27 20:39:53 <ByteCoin> You need to check enough blocks before and and after
 870 2011-09-27 20:40:21 zyphlar has left ("Leaving...")
 871 2011-09-27 20:40:24 <gmaxwell> e.g. if you use a balance sheet from 100 blocks back an attacker would have to have done a whole heck of a lot of mining to fake you out.
 872 2011-09-27 20:40:42 <ByteCoin> Enough blocks after to make sure the network approves. Enough blocks before to make sure it's the "main chain"
 873 2011-09-27 20:40:45 <sipa> i put a summary of transaction info on http://bitcoin.sipa.be/txstats.txt
 874 2011-09-27 20:40:51 <sipa> well, "summary"
 875 2011-09-27 20:40:52 <iz> yeah, that makes sense
 876 2011-09-27 20:41:12 <iz> i would be careful in the selection of the hash alg used for the balance sheet also
 877 2011-09-27 20:41:16 <sipa> it's a list of block#, txid, #txouts, #(available txouts)
 878 2011-09-27 20:41:23 <gmaxwell> iz it could be strenghtend further by trusted parties signing the balance sheet external to the blockchain, and you could decide to trust them.
 879 2011-09-27 20:41:45 <gmaxwell> E.g. your server at home could create signatures that your mobile device trusts.
 880 2011-09-27 20:42:07 <iz> because if it becomes a large arbitrarily sized table.. there might be opportunities for clever hash collisions
 881 2011-09-27 20:42:25 <ByteCoin> If one could have script that could introspect the block chain then you could have transactions which say "I promise that such and such is true and if it isn't then you can spend these x bitcoins"
 882 2011-09-27 20:42:27 <gmaxwell> nah, this is why you use big cryptographic hashes.
 883 2011-09-27 20:42:37 <iz> yeah, that should be fine then
 884 2011-09-27 20:42:44 amtal has quit (Ping timeout: 276 seconds)
 885 2011-09-27 20:43:28 <iz> well, custom tx scripts like that foil the balance sheet idea, right?
 886 2011-09-27 20:43:30 <gmaxwell> ByteCoin: the lack of chain introspection in scripts has made me sad... on the other hand if it was there it might have annoyingly constrained things like pruning.
 887 2011-09-27 20:43:34 c00w has quit (Ping timeout: 240 seconds)
 888 2011-09-27 20:43:35 <ByteCoin> These scripts wouldn't even hit the block chain unless the fact they were warranting turned out to be false
 889 2011-09-27 20:43:41 <gmaxwell> iz: ... no.
 890 2011-09-27 20:43:42 <sipa> iz: there is no per-address balance kept
 891 2011-09-27 20:43:55 <iz> oh, maybe i misunderstand the balance sheet then
 892 2011-09-27 20:44:05 <gmaxwell> Balance sheet doesn't mean "per-address balance" it just means a set of all open (unspent) transactions.
 893 2011-09-27 20:44:06 <sipa> it's just a list of available txouts
 894 2011-09-27 20:44:14 <ByteCoin> When I wrote balance sheet I misunderstood addresses
 895 2011-09-27 20:44:27 <ByteCoin> gmaxwell is correct
 896 2011-09-27 20:44:34 <ByteCoin> that's the "new" meaning
 897 2011-09-27 20:44:42 <iz> oh, i see
 898 2011-09-27 20:45:29 <ByteCoin> gmaxwell: Re: pruning. I think it's going to be a case of caveat emptor
 899 2011-09-27 20:45:58 <ByteCoin> You can see it already with some people accepting transactions before 6 confirms
 900 2011-09-27 20:46:47 <sipa> there are currently over 2^20 unspent txouts
 901 2011-09-27 20:46:59 <sipa> that means such a table would be at least 20 deep
 902 2011-09-27 20:47:02 <ByteCoin> sipa: thanks to stupid firstbits namesquatting
 903 2011-09-27 20:47:16 <ByteCoin> I suggest forgetting txouts below a certain value
 904 2011-09-27 20:47:22 <ByteCoin> !
 905 2011-09-27 20:47:23 <sipa> haha
 906 2011-09-27 20:47:32 Turingi has joined
 907 2011-09-27 20:48:06 <ByteCoin> The fees should relate to what HAS to be remembered. If you spend lots of txouts you should get a refund!
 908 2011-09-27 20:48:47 <sipa> ByteCoin: i actually took that into account in my proposal for revamping the fee system :)
 909 2011-09-27 20:48:53 <sipa> ... neven finished it though
 910 2011-09-27 20:48:58 <sipa> *never
 911 2011-09-27 20:49:32 sacarlson has joined
 912 2011-09-27 20:49:52 <ByteCoin> The blockchain size is becoming quite a problem especially to first adopters.
 913 2011-09-27 20:50:11 <ByteCoin> I can see things drifting the "balance sheets" way to solve it.
 914 2011-09-27 20:50:32 <gmaxwell> while we're rewriting everything we could also make txn specify their maximum lifetime, after which they'll be pruned.
 915 2011-09-27 20:50:36 <ByteCoin> The current fees system does not reflect real costs or provide correct incentives
 916 2011-09-27 20:50:46 <gmaxwell> And then miners could have fee rules that depend on that value.
 917 2011-09-27 20:51:06 <ByteCoin> gmaxwell: What happens to the coins once pruned?
 918 2011-09-27 20:51:09 <gmaxwell> (make the minimum high enough to prevent stupidity, and make the maximum mean infinity)
 919 2011-09-27 20:51:13 <gmaxwell> Gone for good.
 920 2011-09-27 20:51:23 <gmaxwell> Or perhaps mined again, I don't have a big opinion on that.
 921 2011-09-27 20:51:31 p0s has quit (Remote host closed the connection)
 922 2011-09-27 20:51:39 <ByteCoin> It's a thought...
 923 2011-09-27 20:52:12 <gmaxwell> One interesting economic problem for bitcoin in the far future is that no one will know how much not-recently-moved coins are lost vs waiting to appear and have weird economic effects.
 924 2011-09-27 20:52:20 <sipa> gmaxwell: indeed
 925 2011-09-27 20:52:22 <ByteCoin> Then again, why doesn't everyone have one keypair. There's scope for more space saving that way.
 926 2011-09-27 20:52:50 <sipa> that's the only reason i'd consider some pruning of old coins
 927 2011-09-27 20:52:51 <ByteCoin> I have a scheme for preserving anonymity without introducing lots of new keys.
 928 2011-09-27 20:53:15 <gmaxwell> My comment on this before is that such an expiration scheme could be implemented when bitcoin upgrades cryptosystems. Should ecdsa become effectively crackable in the future then even lost cost may come back, and thats probably undesirable.
 929 2011-09-27 20:53:41 <sipa> ByteCoin: by storing a ephemeral private in the txout script, and multiplying with that?
 930 2011-09-27 20:53:44 <sipa> *key
 931 2011-09-27 20:53:58 da2ce7 has quit (Remote host closed the connection)
 932 2011-09-27 20:54:29 <ByteCoin> gmaxwell: I quite like your idea. Txouts with lower value and a closer expiry could use a smaller curve and hence take less space.
 933 2011-09-27 20:54:45 <ByteCoin> Pay less fees for computation and storage
 934 2011-09-27 20:54:50 <sipa> i guess those are things for a bitcoin 2.0
 935 2011-09-27 20:54:58 da2ce7 has joined
 936 2011-09-27 20:55:18 <lfm> or altcoin
 937 2011-09-27 20:55:31 <gmaxwell> Right it would let miners actually budget for the darn storage.  Because store these 1024 bytes _forever_ is actually rather expensive, but isn't needed for most txn since they'll be respent within a few years.
 938 2011-09-27 20:55:41 <sipa> sure, one can and probably experiment with them beforehand in an alternate chain
 939 2011-09-27 20:55:44 <sipa> *should
 940 2011-09-27 20:55:48 <gmaxwell> lfm: well, we'll need to make an incompatible change someday to upgrade cryptosystems.
 941 2011-09-27 20:56:11 <gmaxwell> So at that point it's reasonable to accept all improvements which don't compromise bitcoin's economic promises.
 942 2011-09-27 20:56:43 <ByteCoin> That discussion will be something!
 943 2011-09-27 20:56:54 <sipa> i guess someone will just have to do iyt
 944 2011-09-27 20:56:59 <sipa> in an altchain
 945 2011-09-27 20:57:05 <gmaxwell> (e.g. the overall economic behavior of the system that everyone trusts can't be changed even if those of us here think some change would be a good idea— but e.g. changing out cryptosystems, encoding schemes, etc should be pretty uncontroversal)
 946 2011-09-27 20:57:19 <gmaxwell> well for some value of pretty.
 947 2011-09-27 20:58:00 <ByteCoin> Well I think that the current mining system is harmfull. I would institute a mining system which rewards all participating nodes.
 948 2011-09-27 20:58:14 <pickett> those things affect miners so it could cause controversy
 949 2011-09-27 20:58:34 <sipa> ByteCoin: were forwarding a tx with a fee allows you to take part of it?
 950 2011-09-27 20:58:38 <sipa> or something like that?
 951 2011-09-27 20:58:46 <Namegduf> ByteCoin: YOu can't do that.
 952 2011-09-27 20:58:48 <gmaxwell> heh... if we can get a better handle on tx storage bitcoin could switch to using QC-safe hash based one time signatures. :)  15kb txouts..... oy..
 953 2011-09-27 20:58:51 <lfm> ya if the crypt is someday compromized. meanwhile a fork could experiment with it even if theyre not serious
 954 2011-09-27 20:58:59 <ByteCoin> That's the general idea... sipa.
 955 2011-09-27 20:59:13 <Namegduf> Sweet, so I route all transactions through ten nodes I run
 956 2011-09-27 20:59:16 <Namegduf> How useless
 957 2011-09-27 20:59:23 <gmaxwell> lfm: well, ideally a switch happens long before its "compromised" but when future compromise starts looking like a real possibility.
 958 2011-09-27 20:59:38 <Namegduf> If you do *anything* based on mere participance or count of nodes
 959 2011-09-27 20:59:55 <Namegduf> It is vulnerable to something called a "sybil attack"
 960 2011-09-27 20:59:56 <sipa> ByteCoin: i believe one of the problems with the current design is that it pays for inclusion, but not for burying, while it is the latter that one wants
 961 2011-09-27 21:00:09 <Namegduf> Where you introduce large numbers of basically do-nothing nodes under your control
 962 2011-09-27 21:00:10 <ByteCoin> Namegduf: If all your nodes are doing useful work then they should be rewarded. See my post "transaction relaying is pointless"
 963 2011-09-27 21:00:19 <gmaxwell> You can pay for burying if you want... I described a crazy way of doing that. :)
 964 2011-09-27 21:00:25 <sipa> transaction relaying is pointless
 965 2011-09-27 21:00:30 <ByteCoin> sipa: Correct.
 966 2011-09-27 21:00:31 <sipa> i don't think it'll survive
 967 2011-09-27 21:00:48 <Namegduf> ByteCoin: The rewards MUST be in proportion to the work done
 968 2011-09-27 21:00:55 <Namegduf> ByteCoin: Or the system is vulnerable
 969 2011-09-27 21:00:57 <Namegduf> Simple as that.
 970 2011-09-27 21:01:07 <sipa> nothing in bitcoin is as simple as that
 971 2011-09-27 21:01:12 <Namegduf> Yes, it is.
 972 2011-09-27 21:01:15 <gmaxwell> Namegduf: bytecoin is no fool, he knows about sybil attacks and such.
 973 2011-09-27 21:01:18 <lfm> so you want to reward nodes somehow for just storing the block chain, not just extending it?
 974 2011-09-27 21:01:27 <Namegduf> gmaxwell: So he's pretending not to or what?
 975 2011-09-27 21:01:43 <ByteCoin> lfm: It would need to be carefully thought out.
 976 2011-09-27 21:01:45 <gmaxwell> Namegduf: he made a _very_ general statement, not a concrete proposal.
 977 2011-09-27 21:01:59 <lfm> ByteCoin: ya no doubt
 978 2011-09-27 21:02:25 <ByteCoin> I imagine the reward for storage could vary against the hashing work in an "open market" fashion
 979 2011-09-27 21:02:46 <sipa> gmaxwell: i also once did a suggestion, where fees are spread over the first few blocks after inclusion
 980 2011-09-27 21:02:47 <ByteCoin> Both hashing and network participation are valuable
 981 2011-09-27 21:02:52 <sipa> instead of only the first one
 982 2011-09-27 21:02:55 <gmaxwell> Namegduf: prior to 1999 you would be yelling "byzantine generals is insoluable!" before satoshi even got a chance to explain bitcoin. ;)
 983 2011-09-27 21:03:04 da2ce7 has quit (Read error: Connection reset by peer)
 984 2011-09-27 21:03:09 <Namegduf> gmaxwell: Now that's going too far.
 985 2011-09-27 21:03:13 <ByteCoin> sipa: Yes that's a good idea.
 986 2011-09-27 21:03:17 <lfm> I think Satoshi figured the reward for storing the block chain is that you get to use it.
 987 2011-09-27 21:03:18 <gmaxwell> sipa: you can construct tx chains involving nlock time that do that, but they create txn activity bloat, of course. :)
 988 2011-09-27 21:03:37 <Namegduf> gmaxwell: He said he would "institute a mining system which rewards all participating nodes"
 989 2011-09-27 21:03:43 <sipa> satoshi intended most of the network to be mining
 990 2011-09-27 21:03:46 <lfm> since in his design all users were also storers
 991 2011-09-27 21:03:53 <sipa> not some GPU- or ASIC-powered elite
 992 2011-09-27 21:04:04 <Namegduf> That is what the current system does, and I was entirely reasonable to assume that the only reasonable meaning was to change the distribution to be more even.
 993 2011-09-27 21:04:08 <gmaxwell> Namegduf: put approximation symbols around rewards, all, and participating  and perhaps you can see that its not completely impossible.
 994 2011-09-27 21:04:13 <Namegduf> i.e, all, not just the ones doing the work.
 995 2011-09-27 21:04:14 rdponticelli has joined
 996 2011-09-27 21:04:20 <ByteCoin> lfm: If block chain introspection were allowed then people could provide guarantees against malicious reorgs
 997 2011-09-27 21:04:25 da2ce7 has joined
 998 2011-09-27 21:04:36 <Namegduf> More than the current system does? I dunno. The current system is pretty perfectly proportional for mining.
 999 2011-09-27 21:04:56 <sipa> yes, but mining is far from the only function the network needs
1000 2011-09-27 21:05:02 <gmaxwell> Namegduf: too bad that mining has become a sad pariody of what it takes to make the bitcoin system healty.
1001 2011-09-27 21:05:12 <Namegduf> gmaxwell: Perhaps, but the *original line I was replying to specifically said mining*.
1002 2011-09-27 21:05:15 <ByteCoin> gmaxwell: Agreed/
1003 2011-09-27 21:05:16 <midnightmagic> sad parody? you mean pools.
1004 2011-09-27 21:05:21 <lfm> and really the cost of staorage is pretty minimal. the bandwidth cost is prolly higher.
1005 2011-09-27 21:05:39 <ByteCoin> lfm: And compute
1006 2011-09-27 21:05:41 <Namegduf> And that is where the error was. Not in my responding to it with "You can't redistribute mining rewards uneveningly, it fucks things up".
1007 2011-09-27 21:05:54 <lfm> ByteCoin: compute without mining?
1008 2011-09-27 21:05:55 m00p has quit (Quit: Leaving)
1009 2011-09-27 21:06:38 <lfm> its not clear to me that the mining rewards are "fucked up"
1010 2011-09-27 21:06:50 <sipa> the current model pays the tax revenue (=money introduced by mining) only to miners
1011 2011-09-27 21:06:52 <gmaxwell> We already have pool operators demanding distortions of the software design because their pool center node is so underpowered compared to their mining capacity.
1012 2011-09-27 21:07:01 <ByteCoin> lfm: Every time you relay you verify. You've done work. At the moment, that work is repeated every relay. You should be able to warrant that what you've verified is correct so that others don't have to do the work again
1013 2011-09-27 21:07:02 <midnightmagic> it requires an enormous amount of input to generate a reward right now.
1014 2011-09-27 21:07:14 <gmaxwell> (luke's complaints about tightening up the time clamping, because he needs his clients to do lots of time rolling)
1015 2011-09-27 21:07:19 <midnightmagic> without an enormous input, there is no reward.
1016 2011-09-27 21:08:00 <lfm> luke demands a lot of things and doesnt get many of them
1017 2011-09-27 21:08:08 <ByteCoin> There's also the fact that for a new currency, it's healthy for it to be widely distributed so that people are incentivised to spend it and use it.
1018 2011-09-27 21:08:16 stalled has quit (Ping timeout: 252 seconds)
1019 2011-09-27 21:08:29 <midnightmagic> ByteCoin: but then there's a trust model involved. How would the warrant be more rapidly verifiable than just re-doing the effort itself?
1020 2011-09-27 21:08:49 <gmaxwell> lfm: I think he's successfully driven us away from that decision— though it doesn't help that other people don't like that solution much either.
1021 2011-09-27 21:09:03 <gmaxwell> midnightmagic: actually verifying is rather costly if you don't already have the complete set of open txn already validated.
1022 2011-09-27 21:09:04 <ByteCoin> midnightmagic: Well the current problem is that signature verification is SLOW. There are much faster secure signatures
1023 2011-09-27 21:09:26 <sipa> ByteCoin: with the same size?
1024 2011-09-27 21:09:46 <ByteCoin> sipa: Not sure... brb looking up a good scheme...
1025 2011-09-27 21:09:52 <gmaxwell> QC-strong hash based signatures are super fast to validate. ... just enormous. ;)
1026 2011-09-27 21:09:52 <midnightmagic> But then there's a trust model involved.
1027 2011-09-27 21:10:03 <sipa> (well, i know you only need 64 bytes for a signature, and we already waste somewhat by using DER encoding)
1028 2011-09-27 21:11:14 <sipa> ByteCoin: did you see my proposal for a payment protocol, btw?
1029 2011-09-27 21:11:42 <ByteCoin> sipa: Funnily enough see Dan Bernstein's "Fast signature scheme"
1030 2011-09-27 21:11:52 <ByteCoin> sipa: I saw it.
1031 2011-09-27 21:12:11 <copumpkin> that's the one with the fast bulk verification, right?
1032 2011-09-27 21:12:32 <copumpkin> http://ed25519.cr.yp.to/index.html
1033 2011-09-27 21:12:39 <lfm> pcu cost of verification is kinda relative too. it still like milliseconds on a pc.
1034 2011-09-27 21:12:53 ahbritto has quit (Read error: Operation timed out)
1035 2011-09-27 21:14:33 <ByteCoin> I saw somewhere a scheme where you construct the signature in a very large group but then you verify it modulo one or more small  random primes <2^32
1036 2011-09-27 21:14:46 <ByteCoin> It's secure because an attacker doesn't know what random primes you're using
1037 2011-09-27 21:15:10 <ByteCoin> It's probably a Dan Bernstein paper too!
1038 2011-09-27 21:15:14 <copumpkin> ah :)
1039 2011-09-27 21:15:21 <gmaxwell> thats cute, you can make it quite secure by using several then...
1040 2011-09-27 21:15:31 <copumpkin> anyone remember the tiny secure signatures (87-bits?)?
1041 2011-09-27 21:15:43 <copumpkin> there was some tiny signature scheme that still achieved decent security
1042 2011-09-27 21:16:05 <jrmithdobbs> copumpkin: several curves can do sigs that small or smallers with ecdsa
1043 2011-09-27 21:16:38 <ByteCoin> copumpkin: Short signature schemes using HFE etc get broken
1044 2011-09-27 21:16:50 <copumpkin> ah
1045 2011-09-27 21:16:53 <copumpkin> I remember this from a few years ago
1046 2011-09-27 21:16:58 <copumpkin> can't even remember where it was
1047 2011-09-27 21:17:10 <ByteCoin> jrmithdobbs: But such curves have easyish discrete logarithm problems
1048 2011-09-27 21:17:50 <jrmithdobbs> We found equations that
1049 2011-09-27 21:17:50 <jrmithdobbs> give experimental evidence that basic HFE can be broken in expected
1050 2011-09-27 21:17:50 <jrmithdobbs> polynomial time for any constant degree d. It has been independently
1051 2011-09-27 21:17:52 <jrmithdobbs> proven by Shamir and Kipnis [Crypto’99].
1052 2011-09-27 21:17:53 <jrmithdobbs> ouch
1053 2011-09-27 21:17:53 <ByteCoin> 87 bit curves are considered "toy"
1054 2011-09-27 21:18:06 <copumpkin> it was on a website by a guy who looked a bit like a crank
1055 2011-09-27 21:18:11 <copumpkin> he went on a lot about AES timing attacks
1056 2011-09-27 21:18:15 <midnightmagic> cryptome? lol
1057 2011-09-27 21:18:30 <jrmithdobbs> scheiner?
1058 2011-09-27 21:18:38 <jrmithdobbs> guessing scheiner
1059 2011-09-27 21:18:47 <jrmithdobbs> or however his name's spelled
1060 2011-09-27 21:19:01 stalled has joined
1061 2011-09-27 21:19:07 ahbritto has joined
1062 2011-09-27 21:19:10 <copumpkin> lol no, not schneier
1063 2011-09-27 21:19:26 <jrmithdobbs> you sure? your description sounds like him
1064 2011-09-27 21:19:56 <copumpkin> yeah
1065 2011-09-27 21:20:15 <midnightmagic> isn't that the beef weiner people?
1066 2011-09-27 21:20:57 <jrmithdobbs> ByteCoin: i can't imagine anything else being any more secure at ~87bit tho
1067 2011-09-27 21:21:24 <ByteCoin> Umm there's some hyperelliptic stuff
1068 2011-09-27 21:21:57 <ByteCoin> There's also some new stuff in non-abelian groups.
1069 2011-09-27 21:22:05 <copumpkin> here we go
1070 2011-09-27 21:22:05 <copumpkin> http://www.nicolascourtois.me.uk/
1071 2011-09-27 21:22:06 <copumpkin> that guy
1072 2011-09-27 21:22:12 <ByteCoin> He's good.
1073 2011-09-27 21:22:54 <copumpkin> pretty sure he has a short signature scheme at 87 bits
1074 2011-09-27 21:22:56 <copumpkin> or something
1075 2011-09-27 21:23:06 <copumpkin> but I can't remember anything else about it
1076 2011-09-27 21:23:59 <copumpkin> oh mceliece signature scheme
1077 2011-09-27 21:24:13 <sipa> ByteCoin: by the way, you're not aware of any patents that may apply to key recovery?
1078 2011-09-27 21:24:14 <ByteCoin> A birthday attack at 87 bits can only take about 2^44 work so how's it secure?
1079 2011-09-27 21:24:20 <gmaxwell> mceliece ... megabyte keys anyone?
1080 2011-09-27 21:24:51 <copumpkin> yeah, that was downside of it :)
1081 2011-09-27 21:24:57 <ByteCoin> sipa: My position would be that recovering the y coordinate from an x coordinate given the curve equation is too obvious
1082 2011-09-27 21:24:58 <sipa> ByteCoin: and the bitcoin network does 2^44 sha256 steps per second
1083 2011-09-27 21:25:01 <copumpkin> http://eprint.iacr.org/2001/010
1084 2011-09-27 21:25:03 <copumpkin> there we go
1085 2011-09-27 21:25:05 <copumpkin> that thing
1086 2011-09-27 21:25:17 <copumpkin> not sure if anything's been done about it (or showing it to be bullshit) since then
1087 2011-09-27 21:25:21 <gmaxwell> ByteCoin: seen the supersingular isogenies key agreement stuff?
1088 2011-09-27 21:28:45 zhoutong has quit (Read error: Connection reset by peer)
1089 2011-09-27 21:29:07 zhoutong has joined
1090 2011-09-27 21:29:22 <ByteCoin> copumpkin: These coding based systems have large keys. The paper you quoted has a >1MB key
1091 2011-09-27 21:29:31 <copumpkin> yep :) never said otherwise
1092 2011-09-27 21:29:57 <ByteCoin> Also signature time 10s verification 1s. Ouch!
1093 2011-09-27 21:30:04 <copumpkin> well, that was in 2001!
1094 2011-09-27 21:30:14 <ByteCoin> I take your point
1095 2011-09-27 21:30:45 c00w has joined
1096 2011-09-27 21:30:56 <ByteCoin> I must admit that I don't understand the coding based stuff. That's probably a good part of the reason I don't like it!
1097 2011-09-27 21:31:43 <copumpkin> the guy really needs to get a new web design
1098 2011-09-27 21:31:43 <ByteCoin> gmaxwell: No. No idea about super
1099 2011-09-27 21:31:44 <copumpkin> :P
1100 2011-09-27 21:32:13 <ByteCoin> gmaxwell: Yes. It's meant to be resistant to quantum computing
1101 2011-09-27 21:32:28 <copumpkin> anyone played with lamport signatures?
1102 2011-09-27 21:32:36 <copumpkin> they're beautifully simple :P
1103 2011-09-27 21:32:56 <ByteCoin> I haven't looked at it. Normally you stay away from supersingular curves as the discrete logarithm problem is a lot easier
1104 2011-09-27 21:33:32 <ByteCoin> They use isogenies rather than diffie-helman in some fashion I think...
1105 2011-09-27 21:33:36 <sipa> that Ed25519 system looks very attractive
1106 2011-09-27 21:34:04 <jrmithdobbs> copumpkin: holy entropy exhaustion batman: To create the private key Alice uses the random number generator to produce 256 pairs of random numbers (2×256 numbers in total), each number being 256 bits in size, that is, a total of 2×256×256 bits = 16 KiB in total. This is her private key and she will store it away in a secure place for later use.
1107 2011-09-27 21:34:07 amiller has joined
1108 2011-09-27 21:34:07 <ByteCoin> I can recommend all of Dan Bernstein's work. It doesn't receive the attention it deseres
1109 2011-09-27 21:34:30 <copumpkin> sipa: yes!
1110 2011-09-27 21:34:34 <copumpkin> bitcoin 2.0 should use it :D
1111 2011-09-27 21:34:38 <copumpkin> ;)
1112 2011-09-27 21:34:49 p0s has joined
1113 2011-09-27 21:34:59 <jrmithdobbs> that's the djb one right?
1114 2011-09-27 21:35:07 <sipa> Ed25518 would allow verifying the entire blockchain in 42 seconds
1115 2011-09-27 21:35:09 <jrmithdobbs> that's used in nacl/dnscurve?
1116 2011-09-27 21:35:21 <sipa> on a 2.4GHz quadcore
1117 2011-09-27 21:35:55 <gmaxwell> sipa: to be fair, a super optimized version for our current setup will probably be a fair bit faster than the code we use now.
1118 2011-09-27 21:36:05 <sipa> yes, i believe so
1119 2011-09-27 21:36:12 <sipa> but it's hard to estimate how much
1120 2011-09-27 21:36:17 <ByteCoin> sipa: About block chain speed problems. I thought we'd established that the bottleneck was not the ECDSA
1121 2011-09-27 21:36:22 <ByteCoin> ?
1122 2011-09-27 21:36:30 <sipa> i'm not sure
1123 2011-09-27 21:36:47 <gmaxwell> Well something is sure slow as hell now.
1124 2011-09-27 21:36:53 <jrmithdobbs> is it?
1125 2011-09-27 21:36:54 <ByteCoin> Wasn't it you who did the tests?
1126 2011-09-27 21:37:03 <copumpkin> jrmithdobbs: :D
1127 2011-09-27 21:37:22 <sipa> i once tried to calculate the cost of "one byte stored forever, using exponentially descreasing disk costs"
1128 2011-09-27 21:37:23 <gmaxwell> jrmithdobbs: do a resync from a local node in tmpfs. It actually takes a fairly long time now. It didn't a few months ago, but does now.
1129 2011-09-27 21:37:38 <copumpkin> it's cause you're using bdb instead of mongodb guys. bdb isn't webscape
1130 2011-09-27 21:37:41 <copumpkin> webscale, even
1131 2011-09-27 21:37:50 <copumpkin> can your blockchain scale to the cloud?
1132 2011-09-27 21:37:51 <ByteCoin> Can someone run a profiler against it already?
1133 2011-09-27 21:38:05 <jrmithdobbs> gmaxwell: oh, ya, it's not really gotten any worse since that initial non-block connect fix though
1134 2011-09-27 21:38:10 <sipa> and using some very rough estimates for the constants involved, i concluded verifying one signature cost +- as much as storing 100 bytes forever
1135 2011-09-27 21:38:12 <jrmithdobbs> that i've noticed
1136 2011-09-27 21:38:22 <gmaxwell> One hint is that when its done there are 1.7 gb of BDB log files sitting there…
1137 2011-09-27 21:38:47 <ByteCoin> sipa: Is your maths for that on the forum
1138 2011-09-27 21:38:53 <sipa> ByteCoin: no
1139 2011-09-27 21:38:55 <jrmithdobbs> 2.3G    /home/bitcoin/database/
1140 2011-09-27 21:38:59 <lfm> sipa using what for the cost of computation?
1141 2011-09-27 21:39:10 <jrmithdobbs> gmaxwell: hadn't noticed that, but ya that's huge
1142 2011-09-27 21:39:14 <sipa> lfm: i used the price of amason ec2's micro instances i believe
1143 2011-09-27 21:39:21 <ByteCoin> sipa: What's the point of doing all this work if you're not going to show it off? ;-)
1144 2011-09-27 21:39:38 <sipa> ByteCoin: i did it for a proposal for revamping the fee system
1145 2011-09-27 21:39:45 <gmaxwell> ByteCoin: because doing it is fun, silly.
1146 2011-09-27 21:39:55 <sipa> however, i never finished it, and lost the draft of the text :)
1147 2011-09-27 21:40:03 <ByteCoin> Bummer!
1148 2011-09-27 21:40:13 <sipa> no worries, i can easily redo it if i find the time
1149 2011-09-27 21:40:16 <gmaxwell> sipa: certantly that wasn't the cost of storing data forever on EC2. ;)
1150 2011-09-27 21:40:33 <jrmithdobbs> i dunno ec2 is pretty damned cheap if you just store it
1151 2011-09-27 21:41:15 <gmaxwell> jrmithdobbs: they haven't been lowering their prices over time though.
1152 2011-09-27 21:41:17 <lfm> current cheapest storage should be something like a 1tb drive I think
1153 2011-09-27 21:41:24 <ByteCoin> I think that the cost of having a 1000MB file is more than twice that of having a 500MB file though
1154 2011-09-27 21:41:27 <jrmithdobbs> gmaxwell: they have a few times
1155 2011-09-27 21:41:43 <ByteCoin> Having large files is a problem.
1156 2011-09-27 21:42:04 <gmaxwell> I'm really skeptical about that claim.
1157 2011-09-27 21:42:13 <lfm> owning your own disk drive will always be cheaper.
1158 2011-09-27 21:42:25 <gmaxwell> The cost of redundancy against failure is actually somewhat sublinear.
1159 2011-09-27 21:42:40 glitch-mod has joined
1160 2011-09-27 21:43:14 <lfm> you dont need redundancy for the block chain, the bitcoin net has that covered
1161 2011-09-27 21:43:22 <sipa> indeed
1162 2011-09-27 21:43:32 <sipa> but if you take that argument further
1163 2011-09-27 21:43:34 <midnightmagic> 1TB drives are cheaper unless you have limited slots, in which case 3TB are currently cheaper per-GB than 2TB drives, here.
1164 2011-09-27 21:43:39 <sipa> why keep the block chain at all?
1165 2011-09-27 21:43:50 <ByteCoin> It's been interesting... got to go! Bwye!
1166 2011-09-27 21:43:53 ByteCoin has left ()
1167 2011-09-27 21:44:10 <lfm> sipa just keep it in ram?
1168 2011-09-27 21:44:39 <gmaxwell> I was just saying that as a general counter point to ByteCoin's suggestion that storage cost wasn't linear.
1169 2011-09-27 21:44:49 <midnightmagic> time to start stemming the blockchain already?
1170 2011-09-27 21:45:04 <lfm> stemming?
1171 2011-09-27 21:45:17 <lfm> pruning you mean?
1172 2011-09-27 21:45:24 <midnightmagic> yes.
1173 2011-09-27 21:45:30 <sipa> i think storage cost is one of the most linear things
1174 2011-09-27 21:45:52 <lfm> ya, it is getting so pruning spent transaction is worthwhile.
1175 2011-09-27 21:46:06 <jrmithdobbs> gmaxwell: oh it's definitely not but last time I was running the numbers storing 60-100TB (which was the dataset i was working with) was cheaper with amazon for a year than any other solution I could find
1176 2011-09-27 21:46:30 <jrmithdobbs> gmaxwell: of course, this was also *before* some of their horrible multihour/day downtimes that would drastically change those numbers these days ;p
1177 2011-09-27 21:47:29 <lfm> jrmithdobbs: did you figure for residual value for the used drives after you were done?
1178 2011-09-27 21:47:34 <jrmithdobbs> gmaxwell: iirc compared to some netapp/hitachi setups it was almost as cheap as just paying for the power for the disks in the facilities we were in, haha
1179 2011-09-27 21:47:40 <jrmithdobbs> lfm: si
1180 2011-09-27 21:47:58 <gmaxwell> hm. a fully pruned chain would hardly be any smaller. :(
1181 2011-09-27 21:48:05 <sipa> gmaxwell: ?
1182 2011-09-27 21:48:21 <lfm> jrmithdobbs: thats kinda surprizing to me but I beleive you
1183 2011-09-27 21:48:35 <jrmithdobbs> lfm: people love that cliche "disks are cheap"
1184 2011-09-27 21:48:47 <gmaxwell> well, 1032828 open tx, 447 bytes average size... 440mbytes.  And thats ignoring the fragment costs.
1185 2011-09-27 21:48:51 Titeuf_87 has quit (Quit: Ex-Chat)
1186 2011-09-27 21:49:01 <sipa> gmaxwell: open tx *outputs*
1187 2011-09-27 21:49:04 <jrmithdobbs> lfm: but it's only true so long as you want consumer disks. the moment your disks actually have to do work and have useful functionality they're no longer cheap
1188 2011-09-27 21:49:08 <gmaxwell> oh durrr.
1189 2011-09-27 21:49:19 <gmaxwell> sipa: any idea how many open txn there are?
1190 2011-09-27 21:49:46 <sipa> gmaxwell: sure, let me decompress the stats file :)
1191 2011-09-27 21:49:59 <lfm> gmaxwell: I figure you could trim out  1153338 out of 1586227 from the block chain
1192 2011-09-27 21:50:51 AStove has quit ()
1193 2011-09-27 21:50:53 <gmaxwell> lfm: okay, thats pretty good then.
1194 2011-09-27 21:51:08 <lfm> ya like 72 %
1195 2011-09-27 21:51:10 c00w has quit (Ping timeout: 244 seconds)
1196 2011-09-27 21:51:42 <sipa> 425474 open txs out of 1560566
1197 2011-09-27 21:51:45 <jrmithdobbs> wow how have i not noticed this?: 3.3G    /home/bitcoin
1198 2011-09-27 21:51:58 <gmaxwell> jrmithdobbs: 1g of that is debug.log
1199 2011-09-27 21:52:02 <lfm> of course thats ignoreing the block headers and merkle tree storage, just the TXN.
1200 2011-09-27 21:52:23 <jrmithdobbs> gmaxwell: it would be 2GB since 32bit host, and no it's 0M of debug.log
1201 2011-09-27 21:52:23 <gmaxwell> The block chain is about 900mb. The bdb index of it is about 250mb. Then there is >1G bdb transaction logs, for what reason I do not know.
1202 2011-09-27 21:52:25 <casascius> Superblock
1203 2011-09-27 21:52:51 <jrmithdobbs> gmaxwell: my logs go to stdout/err and then through svlogd and only ever use 10M of space (10 files of 1M each, aka, ~10 minutes of logs, ha)
1204 2011-09-27 21:53:01 <gmaxwell> lfm: headers is only about 11mb right now.
1205 2011-09-27 21:53:17 <jrmithdobbs> 74M addr.dat
1206 2011-09-27 21:53:50 <jrmithdobbs> o, i have some testnet crap in that dir atm, a whole 17M ... rest is all wallet/blockchain/blockchain index/bdb trash
1207 2011-09-27 21:54:25 <lfm> my whole .bitcoin dir is about 1.08 gb
1208 2011-09-27 21:54:54 da2ce7 has quit (Read error: Connection reset by peer)
1209 2011-09-27 21:55:00 <jrmithdobbs> well, i probably have one of the higher uptimes on a bitcoind on this box, ha
1210 2011-09-27 21:55:00 <lfm> ya testnet 60kb
1211 2011-09-27 21:55:03 gjs278 has joined
1212 2011-09-27 21:55:05 <gmaxwell> $ du -sh .
1213 2011-09-27 21:55:05 <gmaxwell> 2.6G	.
1214 2011-09-27 21:55:06 <jrmithdobbs> bitcoin   2770 18.4 43.6 1035176 901512 ?      SLl  Aug10 12686:40 /usr/local/bin/bitcoind -datadir=/home/bitcoin -printtoconsole -maxconnections=512
1215 2011-09-27 21:55:15 <gmaxwell> on a node which was flushed on the 25th.
1216 2011-09-27 21:55:32 <midnightmagic> 2.8G here.
1217 2011-09-27 21:55:35 <gmaxwell> jrmithdobbs: it mmaps the blockchain, so thats not exciting.
1218 2011-09-27 21:55:42 da2ce7 has joined
1219 2011-09-27 21:55:54 <jrmithdobbs> that  hasn't ever been completely flushed
1220 2011-09-27 21:56:04 <jrmithdobbs> gmaxwell: meant the Aug10 part as the interesting bit, ha
1221 2011-09-27 21:56:10 <lfm> jrmithdobbs: thats a LOT of connections
1222 2011-09-27 21:56:30 <jrmithdobbs> ya and?
1223 2011-09-27 21:56:47 <jrmithdobbs> it sits between 500 and 512 used
1224 2011-09-27 21:56:54 <midnightmagic> i love it. :)
1225 2011-09-27 21:57:08 <lfm> jrmithdobbs: that many connects can exhast certain other resources like stream handles and memory
1226 2011-09-27 21:57:09 <midnightmagic> not worried about fragmentation attacks are you?
1227 2011-09-27 21:57:19 <jrmithdobbs> lfm: no it's fine
1228 2011-09-27 21:57:37 <lfm> jrmithdobbs: ok not for regular users tho.
1229 2011-09-27 21:58:18 <jrmithdobbs> well no
1230 2011-09-27 22:00:30 <jrmithdobbs> gmaxwell: now i'm wondering where the extra gig of crap is coming from
1231 2011-09-27 22:00:36 <jrmithdobbs> gmaxwell: how big's your txn logs?
1232 2011-09-27 22:01:04 <lfm> 624840 blk0001.dat  260704 blkindex.dat
1233 2011-09-27 22:01:19 <lfm> thats 1k units
1234 2011-09-27 22:01:28 <jrmithdobbs> aka 610M 255M
1235 2011-09-27 22:01:33 <jrmithdobbs> lfm: learn some -h
1236 2011-09-27 22:01:58 <gmaxwell> $ du -sh database/
1237 2011-09-27 22:01:58 <gmaxwell> 1.7G	database/
1238 2011-09-27 22:01:59 <casascius> Not that it means much, but I would strongly support and encourage any proposal that ensured that completely spent transactions did not need to be communicated around the network by any nodes other than those who explicitly intend to be archivers of history
1239 2011-09-27 22:02:02 <lfm> oh cool, then 611M blk0001.dat  255M blkindex.dat
1240 2011-09-27 22:02:25 <gmaxwell> and importantly this node was just reset and database was that big as soon as it had synced up again.
1241 2011-09-27 22:02:28 <jrmithdobbs> but ya, that's about how big my chain/index are, 74M addr.dat and then 2.3GB database
1242 2011-09-27 22:02:53 <gmaxwell> In fact, I think database/ was larger than before I completely wiped this node. :-/
1243 2011-09-27 22:02:55 <jrmithdobbs> i think I cleared db txn logs about 2 months ago when i moved bitcoin onto it's own fs
1244 2011-09-27 22:03:21 <casascius> I believe I have an idea that would cleanly solve the dilemma of how can a peer tell if a partially pruned block has been appropriately pruned and that they can trust what's missing
1245 2011-09-27 22:03:22 <lfm> gmaxwell: ya a wipe wil usually give you back some space
1246 2011-09-27 22:03:25 <jrmithdobbs> gmaxwell: i think it cleans logs on restart
1247 2011-09-27 22:03:34 <casascius> (beyond the part of adding a hash to each block of a tree of all unspent txns)
1248 2011-09-27 22:03:35 <gmaxwell> lfm: I'm saying the opposite.
1249 2011-09-27 22:03:38 <jrmithdobbs> dbd logs, anyways
1250 2011-09-27 22:03:43 <gmaxwell> jrmithdobbs: I don't think so.
1251 2011-09-27 22:03:51 <jrmithdobbs> gmaxwell: i'll find out real quick
1252 2011-09-27 22:03:56 <gmaxwell> likewise…
1253 2011-09-27 22:04:10 <gmaxwell> oh sure enough
1254 2011-09-27 22:04:40 <gmaxwell> so here is a funny thing... if you bringup a node you'll get 1.7GB of database logs that go away after the first restart…
1255 2011-09-27 22:04:57 <gmaxwell> that seems really suboptimal to me. :)
1256 2011-09-27 22:05:01 <jrmithdobbs> i hate you for being able to restart that quick
1257 2011-09-27 22:05:01 <jrmithdobbs> haha
1258 2011-09-27 22:05:05 <midnightmagic> arrgh ellipses
1259 2011-09-27 22:05:18 <jrmithdobbs> i'm still waiting on the damned thing to shut down let alone come back up
1260 2011-09-27 22:05:38 <jrmithdobbs> poor 32bit p4 xeon
1261 2011-09-27 22:06:03 <casascius> that idea would go something like this: make blocks prunable in an "all-or-nothing" fashion.  Rather than pruning individual transactions off the block, prune them all off (spent and unspent), and the unspent ones are simply put into a brand new block at the head of the block chain, with a notation that "this block replaces all transactions from blocks x-y".
1262 2011-09-27 22:06:10 <lfm> gmaxwell: ya thats bdb logging design. prolly is some way to better control that
1263 2011-09-27 22:06:38 <gmaxwell> lfm: perhaps it would be possible to close down bdb and purge the logs periodically.
1264 2011-09-27 22:06:45 <gmaxwell> e.g. every N blocks recieved.
1265 2011-09-27 22:07:13 amtal has joined
1266 2011-09-27 22:07:29 Daniel0108 has quit (Ping timeout: 260 seconds)
1267 2011-09-27 22:07:37 <jrmithdobbs> http://pastebin.com/FUS0F8ur
1268 2011-09-27 22:08:01 <gmaxwell> casascius: not sure that I really see the point of that.
1269 2011-09-27 22:08:21 <jrmithdobbs> dropping from 508 connections to 20 makes me sad :(
1270 2011-09-27 22:09:46 <casascius> gmaxwell: the point of it would mainly be so that a peer receiving a partial block can know whether he has received the "correct" set of prunings.  If the protocol allows pruned blocks to be exchanged, and you receive a block that is missing transactions, there isn't a clean way to know on first sight whether the parts that have been selected for "pruning" are actually correct
1271 2011-09-27 22:09:48 <jrmithdobbs> ya there's got to be a better way to handle the bdb logging
1272 2011-09-27 22:10:32 <jrmithdobbs> also
1273 2011-09-27 22:10:33 <gmaxwell> casascius: There are more efficient ways to achieve that goal.
1274 2011-09-27 22:10:43 <jrmithdobbs> while it is nifty that ext4 can now be shrunk with resize2fs
1275 2011-09-27 22:10:49 <gmaxwell> casascius: (the open txn commitments described by bytecoin and I address that completely)
1276 2011-09-27 22:10:59 <jrmithdobbs> it's a fucking useless feature if it takes >24hrs to resize from 650GB to 100GB fs
1277 2011-09-27 22:11:01 danbri has quit (Remote host closed the connection)
1278 2011-09-27 22:11:07 <casascius> If you have received an entire block chain and everything is correct, that can be verified wiht a hash.  If a significant part is not correct, then the hash won't match, and a lot of peer-to-peer interrogation must follow to correct it...and if any peers are lying, the person trying to get blocks gets run around in circles
1279 2011-09-27 22:11:23 <casascius> gmaxwell: I am with you - this would depend on your open txn commitments idea
1280 2011-09-27 22:11:56 <midnightmagic> open txn commitments? is that described somewhere?
1281 2011-09-27 22:12:35 <casascius> My understanding of the open commitments idea is to start putting a hash in each block that represents a tree of all the known open transaction outputs elsewhere in the block chain, so it is possible to confirm that one has all of the unspent outputs without needing the whole chain.
1282 2011-09-27 22:12:43 <gmaxwell> midnightmagic: I described it on the forums.
1283 2011-09-27 22:13:01 <midnightmagic> which forums? the bittalk ones or the weird new developer forum?
1284 2011-09-27 22:13:05 <gmaxwell> casascius: it's possible to confirm that any output you're handed is one of them without needing all the rest eithre.
1285 2011-09-27 22:13:12 <gmaxwell> midnightmagic: the old ones.
1286 2011-09-27 22:13:13 Blitzboom has quit (Remote host closed the connection)
1287 2011-09-27 22:13:18 <midnightmagic> ok
1288 2011-09-27 22:13:31 Blitzboom has joined
1289 2011-09-27 22:13:31 Blitzboom has quit (Changing host)
1290 2011-09-27 22:13:31 Blitzboom has joined
1291 2011-09-27 22:13:34 <gmaxwell> I'll give you a link, one minute
1292 2011-09-27 22:13:51 <casascius> gmaxwell: agreed... the issue is what happens when I want to DoS the network and start handing peers blocks with legit transactions pruned off
1293 2011-09-27 22:13:56 <casascius> I think you had mentioned a tree walking scheme
1294 2011-09-27 22:14:04 <casascius> Somebody did at least
1295 2011-09-27 22:14:36 <casascius> Anyway, the idea I had would make the tree walking unnecessary
1296 2011-09-27 22:15:58 da2ce7 has quit (Ping timeout: 244 seconds)
1297 2011-09-27 22:16:00 iocor has quit (Read error: No route to host)
1298 2011-09-27 22:16:12 <gmaxwell> midnightmagic: https://bitcointalk.org/index.php?topic=21995.0
1299 2011-09-27 22:16:19 da2ce7 has joined
1300 2011-09-27 22:16:29 <midnightmagic> tnx!
1301 2011-09-27 22:16:46 iocor has joined
1302 2011-09-27 22:16:47 <lfm> have separate net requests for 1 the merkle tree and 2 each txn
1303 2011-09-27 22:16:53 <midnightmagic> i got sidetracked reading your suggestion about mybitcoin lol
1304 2011-09-27 22:16:53 <gmaxwell> casascius: If the legit txn aren't represented in the open txn set then the block isn't valid and won't be confirmed.
1305 2011-09-27 22:17:08 <gmaxwell> casascius: nodes could protect themselves by simply requring one header past any block they pull.
1306 2011-09-27 22:17:39 <lfm> gmaxwell: the txn which have been pruned should not be needed for verifying new txn
1307 2011-09-27 22:17:58 <lfm> only for the initial load
1308 2011-09-27 22:18:07 <gmaxwell> lfm: Yes why are you telling me this?
1309 2011-09-27 22:18:24 <lfm> so have a new protocol for the initial load
1310 2011-09-27 22:18:34 <casascius> gmaxwell: The header that follows the block won't tell them anything about whether the pruned set is valid.  Example, block 80001 can't accurately tell me what's open in 80000 if I'm trying not to transmit a transaction that was spent in 90000
1311 2011-09-27 22:18:48 <gmaxwell> lfm: yea, missed the compressed format discussion earlier? :)
1312 2011-09-27 22:19:48 <casascius> or in other words, if block 90000 spends an output that was present in 80000, and it is omitted to save space, the open set as of block 80001 won't help you to know whether or not that transaction deserved to be pruned
1313 2011-09-27 22:19:50 <gmaxwell> casascius: under the proposal open txn proposal, block 80000 include a commitment to the set of open transactions. Block 80001 commits to block 80000 being correct in the normal bitcoin way.
1314 2011-09-27 22:19:57 <lfm> like just exec a bittorrent for the initial load would make a lot of stuff more efficient maybe
1315 2011-09-27 22:20:23 <gmaxwell> lfm: we're not at all network bandwidth limited on the intial load.
1316 2011-09-27 22:20:40 <gmaxwell> It takes the same amount of time to init from the network as it does a local node upto measurement error.
1317 2011-09-27 22:21:18 <lfm> gmaxwell: you saying that downloading hte preformatted block chain doesnt save any time?
1318 2011-09-27 22:21:20 <casascius> So then when block 90000 spends something out of 80000, how does that transaction get removed from the set and not break the open commitment in 80001?
1319 2011-09-27 22:21:34 <gmaxwell> lfm: it does, but only because it totally skips validating it!
1320 2011-09-27 22:21:50 <midnightmagic> gmaxwell: would you be overwriting or using coinbase in a way incompatible with the current merged-mining method that namecoin is going to auto-adopt inside of..  about 80 blocks or so?
1321 2011-09-27 22:23:02 <gmaxwell> midnightmagic: it's an incompatible change in anyways because it would require nodes to actually validate the commitment, it's not exclusive with the merged mining stuff.
1322 2011-09-27 22:23:11 <lfm> I thot it was the database operation were slow, not so much the signature valisation
1323 2011-09-27 22:23:34 <gmaxwell> lfm: And?
1324 2011-09-27 22:23:40 <midnightmagic> okay, just don't screw up my merged mining k. :)
1325 2011-09-27 22:24:05 <lfm> so you can validate a preformatted database quicker than building it yourself
1326 2011-09-27 22:24:13 marf_away has quit (Ping timeout: 255 seconds)
1327 2011-09-27 22:24:17 <gmaxwell> casascius: I don't really follow what you're saying. 90000 includes a new commitment. If you wanted to track something back at 80000 you'd use tree fragments to do so.
1328 2011-09-27 22:25:18 <gmaxwell> lfm: validating the chain requires tons of database _lookups_ and signature validations. I don't know how the breakdown of lookup vs signature matters today. Gavin seemed to think ecdsa was a significant factor.
1329 2011-09-27 22:25:40 <lfm> lookups are much quicker than adds
1330 2011-09-27 22:25:44 Moonies has joined
1331 2011-09-27 22:26:00 <lfm> especially if theyr sequential
1332 2011-09-27 22:27:33 <lfm> well, not sure about the sequential part since theyre keyed with the hashes, it could be close to random
1333 2011-09-27 22:27:54 <casascius> The problem is that, with the proposal as I understand it, I can perpetrate a DoS attack on somebody who is trying to load the block chain for the first time, because all of the commitments are going to be "stale" other than the latest one - something an attacker can take advantage of.
1334 2011-09-27 22:27:57 <gmaxwell> They're not at all sequential.
1335 2011-09-27 22:28:50 <sipa> i begin to think that the db management is the most significant factor in block processng
1336 2011-09-27 22:29:07 <gmaxwell> casascius: ah, thats not the purpose.  If you're actually loading the blockchain then you'll be loading the whole blockchain. If you're using the openset confirmations you're a semi-lite node which never actually has the whole set.
1337 2011-09-27 22:29:47 Fairuser has quit (Ping timeout: 256 seconds)
1338 2011-09-27 22:29:50 <gmaxwell> casascius: You simply can't be a _full_ validing node without wittnessing the whole history of bitcoin.
1339 2011-09-27 22:30:03 <lfm> yup, you could even start with a pre-pruned db
1340 2011-09-27 22:30:15 <lfm> download
1341 2011-09-27 22:30:57 <lfm> "full" validation is only really usefull for auditing an forensics afaik
1342 2011-09-27 22:31:28 <casascius> gmaxwell: Is there room for a "medium" validating node?  In other words, one that maintains the block chain, except pruned for spent transactions.  Seems to me, by the time the cost of becoming a "full" node becomes a 2-3-4-10-20-etc. TB download, nobody's gonna want to do it.
1343 2011-09-27 22:31:37 iocor has quit (Quit: Computer has gone to sleep.)
1344 2011-09-27 22:32:06 <lfm> casascius: ya thats what we're talking about. you would still have a full set of block headers probably
1345 2011-09-27 22:32:44 <sipa> i wonder
1346 2011-09-27 22:32:47 <gmaxwell> casascius: Yes, but then you need a trusted way of becoming one of those nodes.
1347 2011-09-27 22:32:54 <gmaxwell> E.g. a trustworthy peer to give you a snapshot.
1348 2011-09-27 22:33:02 <lfm> casascius: altho I think you might be exagerating the growth factor somewhat
1349 2011-09-27 22:33:10 <sipa> is there a way to prove that one has the full db?
1350 2011-09-27 22:33:29 <gmaxwell> The maximum possible growth rate is ~144MB/day.
1351 2011-09-27 22:33:34 Fairuser has joined
1352 2011-09-27 22:33:37 <gmaxwell> sipa: answer random queries against it.
1353 2011-09-27 22:33:40 <casascius> The suggestion I thought of would negate the need for trust with respect to one of those nodes... and it is really elementary
1354 2011-09-27 22:33:41 <lfm> sipa not really, only by answering random sample queries I spoze
1355 2011-09-27 22:33:59 <casascius> it is basically the same as the "open transactions hash" with only a minor modification
1356 2011-09-27 22:34:04 <lfm> not proof, just evidence that accumulates
1357 2011-09-27 22:34:25 <casascius> it would allow a "lied-to" peer to very quickly reconcile out any "lies" and very quickly correct them without any tree walking
1358 2011-09-27 22:34:30 <gmaxwell> casascius: by trust I meant that you have to trust them to give you the whole thing and not DOS you.
1359 2011-09-27 22:35:30 <gmaxwell> casascius: with the opentxn tree you can find errors with log2(n) operations, but if someone gives you a bunch of garbage that doesn't help.
1360 2011-09-27 22:35:34 <lfm> I been thinking there could be a way to recursivly query for txn which are not stored locally, and just cache them for a while and discard. so long as there is a "core" of full nodes.
1361 2011-09-27 22:35:54 da2ce7 has quit (Remote host closed the connection)
1362 2011-09-27 22:36:08 <sipa> and then eg. do some form of signature on relay
1363 2011-09-27 22:36:11 <casascius> gmaxwell: I believe I have a suggestion that will find errors with o(1) operation and correct them the same way
1364 2011-09-27 22:36:15 <lfm> still not really good for initial loads
1365 2011-09-27 22:37:01 <lfm> if you have the merkle hashes you can verify that you have the "real" txn
1366 2011-09-27 22:37:23 <casascius> and the suggestion is this: instead of offering the possibility of pruning parts of blocks, simply allow blocks to be in exactly two states: unpruned, or completely pruned.  When a block becomes completely pruned, take any open transactions and add them to the newest block so they are still within the set of open transactions.
1367 2011-09-27 22:37:47 <gmaxwell> casascius: I don't see how it does that.
1368 2011-09-27 22:37:53 <lfm> casascius: I dont think that would work
1369 2011-09-27 22:38:10 <casascius> So that if someone downloads the whole pruned chain and finds an anomaly in their version of the set of open transactions, they can simply ask each peer: please give me a bitmap of all the blocks you think should be pruned.
1370 2011-09-27 22:38:11 <gmaxwell> I see how it would create enormous amounts of traffic though by constantly repeating transactions.
1371 2011-09-27 22:38:44 <lfm> if you have the block headers and can at least get the full merkle trees, you can verify any txn
1372 2011-09-27 22:39:16 abragin has quit ()
1373 2011-09-27 22:39:45 <casascius> I agree that you can verify given transaction X that it exists in the block chain, that's not what i'm after...the problem is verifying that the "holes" are valid, and more importantly, correcting any holes received in "error"
1374 2011-09-27 22:39:54 <casascius> "holes" being spaces in blocks where transactions have been removed.
1375 2011-09-27 22:40:20 <casascius> I agree that there would be a bit of repetition, but the growth in repetition would be linear, rather than exponential as it is now
1376 2011-09-27 22:40:53 <gmaxwell> ... no the amount of repetition is linear, so the total data would be geometric instead of linear as it is now.
1377 2011-09-27 22:41:00 mosimo has quit (Read error: Connection reset by peer)
1378 2011-09-27 22:41:08 <lfm> well if you were to just recursivly cache txn you could just start with the block headers and merkle trees and request any txn you need. you wouldnt really even need current active txn
1379 2011-09-27 22:41:53 <casascius> gmaxwell: yes, with respect to the nodes that need to save full copies of everything... you guys have been talking about ways to deduplicate data... i believe that full nodes are going to become less and less popular as time goes on (and the resource cost of running them goes up)... surely if the proposal saves resources for 90+% of the people using bitcoin,
1380 2011-09-27 22:42:04 <gmaxwell> x[n]=x[n-1]+1  now vs x[n]=x[n-1]+1+sum(x[0..n-1])*r_factor
1381 2011-09-27 22:42:08 <casascius> there would be a feasible way to represent this "duplication" in a full node so that it doesn't actually duplicate the resources used.
1382 2011-09-27 22:42:21 <lfm> casascius: yup, you dont need many full nodes tho really
1383 2011-09-27 22:42:21 c00w has joined
1384 2011-09-27 22:42:23 <gmaxwell> casascius: run a lite node then.
1385 2011-09-27 22:42:40 iocor has joined
1386 2011-09-27 22:42:41 <casascius> gmaxwell: I suspect I will when possible, and so will everyone else
1387 2011-09-27 22:42:44 <gmaxwell> We only need some dozens of thousands of full nodes.
1388 2011-09-27 22:42:57 <lfm> casascius: the surrent system would be the "full" nodes.
1389 2011-09-27 22:43:01 <lfm> current
1390 2011-09-27 22:43:21 <gmaxwell> And I have 48TB of storage at home today, and its no big deal.  If you do the math this lasts for bitcoin under fairly reasonable assumptions for a long time.
1391 2011-09-27 22:43:32 <lfm> gmaxwell: huh? why so many you think?
1392 2011-09-27 22:44:03 <casascius> gmaxwell: it's no big deal if we assume that everybody has that at their disposal
1393 2011-09-27 22:44:34 <gmaxwell> casascius: not everybody has to, it was never assumed that all nodes will be full nodes, thus support for lite nodes in the design.
1394 2011-09-27 22:44:42 <lfm> casascius: storage costs really are minor as far as we can forsee.
1395 2011-09-27 22:45:19 <casascius> lfm: storage costs are really minor for me and for you, but the world isn't going to spend what you and I will spend on bitcoin storage to adopt bitcoin
1396 2011-09-27 22:45:53 <lfm> casascius: also storage costs are coming down, I think probably faster than we are using it up.
1397 2011-09-27 22:46:15 <casascius> how about bandwidth costs?
1398 2011-09-27 22:47:20 <lfm> casascius: depends. regular broadband bandwidth is cheap and getting cheaper. some badwidth costs more than others to (ie mobile) so it might be a concern for some
1399 2011-09-27 22:51:36 <lfm> casascius: also there are bitcoin "banks" that can handle user accounts for people unwilling to support a full bitocin node.
1400 2011-09-27 22:52:22 minimoose has quit (Quit: minimoose)
1401 2011-09-27 22:52:43 <casascius> Are there any plans for a "lite" node or is the hope that someone comes along independently and delivers it?
1402 2011-09-27 22:52:55 <casascius> or rather, support for using this bitcoin client as a lite node
1403 2011-09-27 22:53:08 <lfm> casascius: ya thats what we were just discussing, they dont really exist yet.
1404 2011-09-27 22:54:37 <gmaxwell> the java stuff is a lite client.
1405 2011-09-27 22:54:56 <upb> the coin is dead
1406 2011-09-27 22:55:51 da2ce7 has joined
1407 2011-09-27 22:55:54 <sipa>  long live the coin
1408 2011-09-27 22:56:19 <casascius> seems to me this client would do well as a lite node with not too many major changes
1409 2011-09-27 22:56:25 <gmaxwell> ...
1410 2011-09-27 22:56:25 <casascius> (an either/or node)
1411 2011-09-27 22:56:50 <gmaxwell> Sure, only replace 90% of the non-ui software!
1412 2011-09-27 22:57:52 c00w has quit (Quit: Ex-Chat)
1413 2011-09-27 22:58:10 <lfm> I think a "lite" node could just start with downloading the block header chain and the merkle trees. the block header total about 8.8 mb and the merkle trees total about 110 mb I think.
1414 2011-09-27 22:58:18 erus` has quit (Remote host closed the connection)
1415 2011-09-27 22:58:57 <gmaxwell> lfm: you mean 12MB.
1416 2011-09-27 22:59:56 <lfm> 147167 * 80 bytes?
1417 2011-09-27 23:00:28 <gmaxwell> Yes, thats 11.228 MBytes.
1418 2011-09-27 23:00:57 <lfm> oops you're right I typoed 60 in my calc
1419 2011-09-27 23:01:03 da2ce7 has quit (Remote host closed the connection)
1420 2011-09-27 23:02:15 <lfm> then the lite node just needs to be able to request any txn by its hash
1421 2011-09-27 23:02:36 copumpkin has quit (Quit: Computer has gone to sleep.)
1422 2011-09-27 23:02:45 da2ce7 has joined
1423 2011-09-27 23:02:51 karnac has joined
1424 2011-09-27 23:03:02 <lfm> the merkle tree would dominate the download anyway at over 100mb
1425 2011-09-27 23:03:44 <gmaxwell> lfm: why do you want to download that?
1426 2011-09-27 23:03:58 <gmaxwell> the whole point of a merkle tree is so that you can get given fragments efficiently.
1427 2011-09-27 23:04:00 <lfm> so you can look up old txn
1428 2011-09-27 23:04:15 <gmaxwell> Someone who gives you a txn gives you the fragment connecting it to the root where its mined.
1429 2011-09-27 23:04:22 Giel has quit (Ping timeout: 240 seconds)
1430 2011-09-27 23:04:45 <lfm> you dont need the root where its mined, just the input txn(s)
1431 2011-09-27 23:05:03 mortikia has quit (Ping timeout: 244 seconds)
1432 2011-09-27 23:05:46 <lfm> some of them might be root txns but there is no reason they must be
1433 2011-09-27 23:06:22 <gmaxwell> "root txns" what are you talking about?
1434 2011-09-27 23:06:33 Giel has joined
1435 2011-09-27 23:06:34 <lfm> coinbase txns?
1436 2011-09-27 23:07:10 da2ce7 has quit (Ping timeout: 240 seconds)
1437 2011-09-27 23:07:18 <gmaxwell> Okay. First, on a lite node you can only securely deal with mined transactions. Otherwise I could give you a TXN which is an unminable double spend which will never be minded and you'll have no way to know.
1438 2011-09-27 23:07:28 <lfm> also if you are monitoring for an incomming txn, you might request all new txns of new blocks
1439 2011-09-27 23:07:45 alanp has quit (Ping timeout: 256 seconds)
1440 2011-09-27 23:08:20 <gmaxwell> No. By connect to the root I mean connecting it to the merkle root in the block header where a particular txn was mined.
1441 2011-09-27 23:08:35 <lfm> gmax if it isnt in the block chain and merkle trees it isnt valid. if it isn't confirmed by enuf blocks you know.
1442 2011-09-27 23:08:45 Arthur___ has joined
1443 2011-09-27 23:08:52 <gmaxwell> You tell me about TXN X and I want to know if X is in the blockchain. To know that I need a tree fragment connecting it to a blockheader I know about.
1444 2011-09-27 23:08:55 <lfm> oh, ya you need all the merkles tho I think
1445 2011-09-27 23:09:15 Arthur___ has left ()
1446 2011-09-27 23:09:27 disq has quit (Quit: omg)
1447 2011-09-27 23:09:27 <gmaxwell> You don't need all the merkles. You just need the particular fragment connecting the particular txn you want to know about to its particular block header.
1448 2011-09-27 23:09:37 da2ce7 has joined
1449 2011-09-27 23:09:52 mortikia has joined
1450 2011-09-27 23:10:02 <lfm> ok, ya, you dont really need  to look up the input txn I guess.
1451 2011-09-27 23:10:19 <gmaxwell> Right, when the txn is mined you know the input was good.
1452 2011-09-27 23:11:01 ThomasV has joined
1453 2011-09-27 23:12:49 AAA_awright has joined
1454 2011-09-27 23:13:09 <lfm> not sure its worth it to prune a merkle tree tho. seems like you could just get a whole tree cuz you still need a fair proportion of it I think.
1455 2011-09-27 23:13:58 da2ce7 has quit (Ping timeout: 240 seconds)
1456 2011-09-27 23:14:40 wolfspraul has quit (Ping timeout: 260 seconds)
1457 2011-09-27 23:14:59 da2ce7 has joined
1458 2011-09-27 23:15:31 <casascius> If there were ever a scheme where the unspent contents of old blocks could be written into new blocks, no merkle trees would be necessary.  If the "new" block contained some reliable notation that it replaced a certain range of "old" blocks, the only thing anyone the vast majority of nodes would need, would be the block header from the old block.  Such nodes could be fully trusted, could mine, could do everything a full node ca
1459 2011-09-27 23:15:50 <casascius> other than regurgitate historical transactions that have been spent
1460 2011-09-27 23:16:39 <lfm> casascius: but there is millions of outstanding TXN at any given time, you can make copies of all of em in every block.
1461 2011-09-27 23:16:53 <lfm> cant
1462 2011-09-27 23:17:10 minimoose has joined
1463 2011-09-27 23:17:42 disq has joined
1464 2011-09-27 23:17:43 disq has quit (Changing host)
1465 2011-09-27 23:17:43 disq has joined
1466 2011-09-27 23:17:44 <casascius> I don't think I mean copy every transaction into every block.  I just mean use this as a method of stumping old blocks.
1467 2011-09-27 23:18:11 <casascius> I say stumping to mean pruning, but pruning everything off the block so all that's left is 80 bytes
1468 2011-09-27 23:18:46 <lfm> casascius: ya, just wait till all the txn are spent tho. doesnt make sense to make more copies
1469 2011-09-27 23:18:52 <casascius> and this would be on a one block basis.
1470 2011-09-27 23:19:04 <casascius> example, block 100001 would stump block 1
1471 2011-09-27 23:19:10 <casascius> block 100002 would stump block 2
1472 2011-09-27 23:19:25 <casascius> by the time you got to block 200000, blocks 1-100000 would be completely stumped...they'd be 80 bytes each
1473 2011-09-27 23:19:30 <lfm> casascius: you are copyin a lot eventually
1474 2011-09-27 23:20:06 <casascius> lfm: agreed, each time a block is stumped, those spent transactions never need to be relayed again ever by anybody
1475 2011-09-27 23:21:02 <lfm> casascius: you still want to have the whole chain of block headers generally. replacing block 1 with block 100001 doesnt save you anything
1476 2011-09-27 23:21:29 <casascius> lfm: if block 1 has been completely spent, the savings is 100%
1477 2011-09-27 23:21:48 <lfm> you just thro out the txn, thats saving it too
1478 2011-09-27 23:23:25 <lfm> even if all the txn have been spent and dropped for a block, I think you should still keep the block headers
1479 2011-09-27 23:23:40 Giel has quit (Ping timeout: 244 seconds)
1480 2011-09-27 23:23:41 <casascius> that's equivalent to what i'm saying, except that my stumping operation at 100001 would allow clients to account for the missing transaction there
1481 2011-09-27 23:23:58 mortikia has quit (Ping timeout: 240 seconds)
1482 2011-09-27 23:24:26 Giel has joined
1483 2011-09-27 23:24:36 <lfm> huh? if you have the orginal header thats all you need for 6that, why copy them around?
1484 2011-09-27 23:25:01 <casascius> without a clear way to account for what's missing, and without a clear way for nodes to know that only unspent transactions are missing, someone could doublespend by omitting transaction "X spent to Y" and then doublespend on X because the victim won't know about Y
1485 2011-09-27 23:25:47 <gmaxwell> lfm: it's a proposal for full validating nodes which have never seen the whole blockchain.
1486 2011-09-27 23:25:52 <lfm> well the miners will verify that you only use unspent inputs and wont let you double spend
1487 2011-09-27 23:26:21 <gmaxwell> casascius: you're still missing the fact that it makes the communication costs grow geometrically with transactions instead of linearly.
1488 2011-09-27 23:26:46 <gmaxwell> casascius: imagine for a second that no old txns are spent, only new ones are issued.
1489 2011-09-27 23:27:28 <gmaxwell> casascius: and that txn rate is constant across all bocks...   at 100001 you must have 2x the data of block 1.  And 20001 3x, and 30001 4x. and so on.
1490 2011-09-27 23:27:48 <gmaxwell> Of course it's not quite that bad, because some txn are spent, but its still geometric growth.
1491 2011-09-27 23:27:48 <casascius> gmaxwell: if I follow you right, basically every 100000 blocks, every node will have received a repeat copy of the whole blockchain
1492 2011-09-27 23:28:37 <gmaxwell> casascius: right, which is a geometric amount of transmitted data in terms of the number of txn, rather than linear where each txn is only sent once to a node.
1493 2011-09-27 23:28:53 <lfm> ya, even if they already have em, then a 200001 they will have 3 copies of some and 2 copies of others
1494 2011-09-27 23:29:33 <casascius> At 200001 you'd have 3x the data of block 1.  I don't see it that way, am I missing something?  At 200001 you would have the normal block contents, plus the contents of block 100001 (which would already contain the contents of 1, so 1 wouldn't need to be repeated)
1495 2011-09-27 23:29:50 <casascius> at 300001 you would have the normal recent transactions, plus those unspent from 200001 (which are all-inclusive of the ones it included)
1496 2011-09-27 23:30:07 <lfm> casascius: I am saying people that HAVE block 1 will get new copies when they dont need em
1497 2011-09-27 23:30:12 <gmaxwell> casascius: if it also somehow encouraged users to actually close the damn txn then it wouldn't be so terrible. E.g. a system that makes users periodically spend very old txn or they expire, would have a similar data explosion problem to your proposal, but txn fees would actually encourage people to reuse old txn productively rather than keep constantly growing sets of open ones.
1498 2011-09-27 23:31:30 <lfm> out of the first 200 txn I think only about 5 have ever been spent
1499 2011-09-27 23:32:21 <gmaxwell> casascius: lets pretend the period is three.  1,2,3,41,52,63,741,852,963,A741,B852,C963   < see how its growing geometrically?
1500 2011-09-27 23:32:25 <casascius> While it is true that every 100000 blocks of uptime, someone would receive the entire block chain over the course of that time, every 2 years... However I've only been using bitcoin for months and have probably downloaded the block chain a couple dozen times for various reasons.
1501 2011-09-27 23:33:14 <casascius> gmaxwell: Yep, I do understand... every 3 blocks, the entire thing is regurgitated, so by block 12, someone has received 4 copies of something.
1502 2011-09-27 23:33:21 <lfm> casascius: well I suspect you are not doing it the most efficient way then
1503 2011-09-27 23:33:44 mortikia has joined
1504 2011-09-27 23:33:58 <casascius> If we are going to use every 3 blocks, then we should also be "spending" two-thirds of them every period as well though, since, isn't that about the proportion of spent transactions we already have now?
1505 2011-09-27 23:34:06 <luke-jr> ;;bc,stats
1506 2011-09-27 23:34:10 <gribble> Current Blocks: 147169 | Current Difficulty: 1689334.4045971 | Next Difficulty At Block: 149183 | Next Difficulty In: 2014 blocks | Next Difficulty In About: 5 weeks, 5 days, 5 hours, 36 minutes, and 4 seconds | Next Difficulty Estimate: 1174508.34984809 | Estimated Percent Change: -30.4750825738
1507 2011-09-27 23:34:35 <lfm> about 72% spent
1508 2011-09-27 23:34:45 <gmaxwell> casascius: it doesn't matter what your spending rate is. The growth is still geometric.
1509 2011-09-27 23:34:49 b4epoche_ has joined
1510 2011-09-27 23:35:00 <gmaxwell> (well unless its 100%)
1511 2011-09-27 23:35:24 <gmaxwell> you're just taming the asymptote to a later date.
1512 2011-09-27 23:35:31 <lfm> ya, 1% per year compounded is still geometric
1513 2011-09-27 23:35:49 Diablo-D3 has joined
1514 2011-09-27 23:37:05 <lfm> I still dont see why downloading txn x attached to block 100001 is any advantage to downloading txn x attached to block 1
1515 2011-09-27 23:37:06 zhoutong has quit (Read error: Connection reset by peer)
1516 2011-09-27 23:37:31 <casascius> It's geometric growth if you want to aggregate it all together, but you subtract the blocks you are stumping, as well as the transactions that get spent.  What it amounts to is that every 2 years, everyone will have re-downloaded the whole block chain unnecessarily, slowly in a trickle, over that time.  The geometric growth I don't think can be described as requiring 1 more byte than that, am I wrong?
1517 2011-09-27 23:38:03 zhoutong has joined
1518 2011-09-27 23:38:17 <casascius> And what I'm proposing is, is that a worthwhile trade off for making it so that people don't have to download every spent transaction in the history of bitcoin in order to become a full validating node.
1519 2011-09-27 23:38:19 <lfm> and any txn that is NEVER spent you download over and over again every 2 years
1520 2011-09-27 23:38:52 <gmaxwell> No, you're requiring them to instead download a majority of them over and over again!
1521 2011-09-27 23:39:13 <gmaxwell> (well, a plurality at least)
1522 2011-09-27 23:39:32 <gmaxwell> And your goal could be achieved without _any_ repetition!
1523 2011-09-27 23:40:09 <gmaxwell> Start committing to hashes over a set of open transactions in the chain. Ask a peer to give you a set. See if it matches. If it doesn't try another peer. If you have at least one honest peer you will be successful and you'll know it. Fin.
1524 2011-09-27 23:40:21 <lfm> there really is no sense pruning the block headers themselves. you could go for a million years and thats just 80 mb!
1525 2011-09-27 23:40:41 <lfm> million blocks
1526 2011-09-27 23:40:50 <lfm> ok slightly bigger
1527 2011-09-27 23:40:52 <casascius> How do you quantify the repetition when you consider the block chain now gets downloaded by (number of users) * (number of times they install/reinstall bitcoin)?  If average time between reinstalling bitcoin is less than 2 years, even my geometrically increasing proposal will always cost less bandwidth
1528 2011-09-27 23:41:17 <gmaxwell> lfm: 3.8 TB, but they can be compressed.
1529 2011-09-27 23:41:28 <lfm> casascius: you cant look at how we do it NOW cuz we arnt even pruning spent txn at all now!
1530 2011-09-27 23:41:35 copumpkin has joined
1531 2011-09-27 23:41:46 <casascius> even if we did, the math would be the same...right now it just happens to be worse
1532 2011-09-27 23:41:55 <gmaxwell> casascius: You'd still have that repetition, PLUS your repetition.
1533 2011-09-27 23:42:00 <lfm> gmaxwell: all those hashes donw compress well
1534 2011-09-27 23:42:04 <lfm> dont
1535 2011-09-27 23:42:30 <gmaxwell> lfm: yes, but you can drop prev if you actually have prev and you've already checked it and substantially compress the timestamp.
1536 2011-09-27 23:42:44 <gmaxwell> plus you can drop the version
1537 2011-09-27 23:43:32 <lfm> so thats what 16 bytes out of 80 are compressable at all?
1538 2011-09-27 23:43:45 wardearia has quit (Ping timeout: 252 seconds)
1539 2011-09-27 23:44:29 <gmaxwell> lfm: er, no, you can get it to ~38 bytes.
1540 2011-09-27 23:45:20 <casascius> I just see it as a worthwhile tradeoff.  Repeating a block chain slowly over the course of 2 years, so that new users can be up and running in a fraction of the time with less storage, you can practically do that on slow DSL.  However, I'm not one for wasting resources.  I am game for
1541 2011-09-27 23:45:37 <lfm> the merkle tree is 32 bytes and the prev hash is almost 32 just a few leading zeros are compressable
1542 2011-09-27 23:45:40 <gmaxwell> casascius: You're really not thinking this through.
1543 2011-09-27 23:45:41 <casascius> any proposal that prunes the block chain in a way that new users can reliably download it
1544 2011-09-27 23:46:01 <gmaxwell> casascius: if they can afford to wait two years before they're usefully validating anything then they ought to just be a lite node!
1545 2011-09-27 23:46:55 ThomasV has quit (Ping timeout: 260 seconds)
1546 2011-09-27 23:47:03 <casascius> they wouldn't have to wait 2 years to validate, they would be able to validate the moment they got the block chain.  It's just that at T + 2 years, they will have received the unspent portion of their initial block chain twice... assuming they got lucky and found no reason to reinstall Bitcoin in all of two years (I have only experienced about one twentieth of that luck, since i've probably installed that many times =) )
1547 2011-09-27 23:47:37 Turing_i has joined
1548 2011-09-27 23:47:38 <lfm> casascius: we just dont see where the saving is
1549 2011-09-27 23:47:50 <gmaxwell> You're incorrect and now I'm beginning to feel like talking to you is a waste of my time.
1550 2011-09-27 23:47:51 Turingi has quit (Disconnected by services)
1551 2011-09-27 23:47:59 Turing_i is now known as Turingi
1552 2011-09-27 23:48:16 <gmaxwell> If you want nodes to download just the complete set of open txn at startup I already proposed a way to do that which is completely efficient.
1553 2011-09-27 23:48:45 <casascius> OK, I may very well be incorrect, but you've given me a fair shake at hearing me out, so I'll leave it at that
1554 2011-09-27 23:49:11 <gmaxwell> Sorry to be sharp, I'm just getting frustrated at the lack of communication, which is fairly probably my fault. :)
1555 2011-09-27 23:49:19 <gmaxwell> I'm also past due for dinner, I'll ttyl.
1556 2011-09-27 23:49:31 <lfm> k bye
1557 2011-09-27 23:51:50 <lfm> casascius: anyway, you are right that starting up is getting slower and will continue to get slower. rest assured we know it is and are trying to think of ways to speed it up but from what we can gather of your proposal, it wont help. sorry.
1558 2011-09-27 23:52:11 <luke-jr> ;;bc,spotestimate
1559 2011-09-27 23:52:12 <gribble> 1653191.14862
1560 2011-09-27 23:52:17 <luke-jr> ;;bc,stats
1561 2011-09-27 23:52:20 <gribble> Current Blocks: 147169 | Current Difficulty: 1689334.4045971 | Next Difficulty At Block: 149183 | Next Difficulty In: 2014 blocks | Next Difficulty In About: 5 weeks, 5 days, 5 hours, 36 minutes, and 4 seconds | Next Difficulty Estimate: 1174508.34984809 | Estimated Percent Change: -30.4750825738
1562 2011-09-27 23:57:51 Cokein_ has quit (Read error: Connection reset by peer)
1563 2011-09-27 23:59:13 wardearia has joined