1 2011-10-02 00:00:16 BurtyB has quit (Read error: Connection reset by peer)
   2 2011-10-02 00:00:30 BurtyB has joined
   3 2011-10-02 00:03:19 LobsterMan has left ()
   4 2011-10-02 00:05:19 stalled has joined
   5 2011-10-02 00:06:11 realazthat has quit (Quit: Ex-Chat)
   6 2011-10-02 00:10:21 zhoutong has quit (Read error: Connection reset by peer)
   7 2011-10-02 00:11:22 zhoutong has joined
   8 2011-10-02 00:14:33 theorb has joined
   9 2011-10-02 00:14:58 theorbtwo has quit (Ping timeout: 260 seconds)
  10 2011-10-02 00:15:11 theorb is now known as theorbtwo
  11 2011-10-02 00:20:49 zhoutong has quit (Read error: Connection reset by peer)
  12 2011-10-02 00:21:45 zhoutong has joined
  13 2011-10-02 00:22:33 mmoya has quit (Ping timeout: 260 seconds)
  14 2011-10-02 00:23:58 zhoutong has quit (Read error: Connection reset by peer)
  15 2011-10-02 00:24:00 Diablo-D3 has joined
  16 2011-10-02 00:24:43 zhoutong has joined
  17 2011-10-02 00:28:52 zhoutong has quit (Read error: Connection reset by peer)
  18 2011-10-02 00:29:25 zhoutong has joined
  19 2011-10-02 00:29:59 MobiusL has quit (Quit: Leaving)
  20 2011-10-02 00:30:30 MobiusL has joined
  21 2011-10-02 00:30:35 MobiusL has quit (Changing host)
  22 2011-10-02 00:30:35 MobiusL has joined
  23 2011-10-02 00:41:31 zhoutong has quit (Read error: Connection reset by peer)
  24 2011-10-02 00:42:14 iocor has quit (Quit: Computer has gone to sleep.)
  25 2011-10-02 00:42:25 zhoutong has joined
  26 2011-10-02 00:44:10 zhoutong has quit (Read error: Connection reset by peer)
  27 2011-10-02 00:44:13 Joric has joined
  28 2011-10-02 00:45:09 zhoutong has joined
  29 2011-10-02 00:45:17 TransistOrg has quit (Remote host closed the connection)
  30 2011-10-02 00:45:35 TransistOrg has joined
  31 2011-10-02 00:47:39 zhoutong has quit (Read error: Connection reset by peer)
  32 2011-10-02 00:48:41 zhoutong has joined
  33 2011-10-02 00:52:38 zhoutong has quit (Read error: Connection reset by peer)
  34 2011-10-02 00:53:37 zhoutong has joined
  35 2011-10-02 00:54:58 zhoutong has quit (Read error: Connection reset by peer)
  36 2011-10-02 00:55:20 TransistOrg has quit (Remote host closed the connection)
  37 2011-10-02 00:55:36 TransistOrg has joined
  38 2011-10-02 00:56:08 zhoutong has joined
  39 2011-10-02 00:57:09 ahbritto has joined
  40 2011-10-02 00:57:09 ahbritto has quit (Changing host)
  41 2011-10-02 00:57:09 ahbritto has joined
  42 2011-10-02 00:58:26 zhoutong has quit (Read error: Connection reset by peer)
  43 2011-10-02 00:59:23 zhoutong has joined
  44 2011-10-02 01:00:19 AlexWaters has quit (Read error: Connection reset by peer)
  45 2011-10-02 01:01:15 AlexWaters has joined
  46 2011-10-02 01:04:04 AlexWaters has quit (Read error: Connection reset by peer)
  47 2011-10-02 01:05:08 clr_ has quit (Ping timeout: 252 seconds)
  48 2011-10-02 01:08:29 AlexWaters has joined
  49 2011-10-02 01:08:46 Turingi has quit (Read error: Connection reset by peer)
  50 2011-10-02 01:13:45 AlexWaters1 has joined
  51 2011-10-02 01:13:45 zhoutong has quit (Read error: Connection reset by peer)
  52 2011-10-02 01:14:13 zhoutong has joined
  53 2011-10-02 01:14:23 AlexWaters has quit (Read error: Connection reset by peer)
  54 2011-10-02 01:17:14 AlexWaters has joined
  55 2011-10-02 01:17:38 AlexWaters1 has quit (Read error: Connection reset by peer)
  56 2011-10-02 01:18:43 AlexWaters has quit (Remote host closed the connection)
  57 2011-10-02 01:19:55 zhoutong has quit (Read error: Connection reset by peer)
  58 2011-10-02 01:20:53 zhoutong has joined
  59 2011-10-02 01:21:58 Joric has quit ()
  60 2011-10-02 01:22:11 AlexWaters has joined
  61 2011-10-02 01:22:30 genjix has joined
  62 2011-10-02 01:22:47 <genjix> why is this block in the block-chain?
  63 2011-10-02 01:22:48 <genjix> http://blockexplorer.com/block/00000000000a4d0a398161ffc163c503763b1f4360639393e0e4c8e300e0caec
  64 2011-10-02 01:25:15 TransistOrg has quit (Remote host closed the connection)
  65 2011-10-02 01:25:34 TransistOrg has joined
  66 2011-10-02 01:25:36 AlexWaters has quit (Remote host closed the connection)
  67 2011-10-02 01:26:01 AlexWaters has joined
  68 2011-10-02 01:27:09 zhoutong has quit (Read error: Connection reset by peer)
  69 2011-10-02 01:27:24 Beremat has joined
  70 2011-10-02 01:28:12 zhoutong has joined
  71 2011-10-02 01:29:52 AlexWaters has quit (Remote host closed the connection)
  72 2011-10-02 01:30:22 AlexWaters has joined
  73 2011-10-02 01:31:41 zhoutong has quit (Read error: Connection reset by peer)
  74 2011-10-02 01:32:35 zhoutong has joined
  75 2011-10-02 01:32:51 AlexWaters has quit (Read error: Connection reset by peer)
  76 2011-10-02 01:33:42 AlexWaters has joined
  77 2011-10-02 01:34:42 erus` has quit (Remote host closed the connection)
  78 2011-10-02 01:35:06 clr_ has joined
  79 2011-10-02 01:35:09 Detritus has quit (Ping timeout: 244 seconds)
  80 2011-10-02 01:35:57 <luke-jr> genjix: because the network rules don't prohibit it
  81 2011-10-02 01:35:59 <ForceMajeure> genjix: coinbase tx id is the same as in other block (somebody used the same bitcoin address and extranonce). 0.4.0 includes juke-jr's patch to avoid this situation in the future
  82 2011-10-02 01:36:29 <luke-jr> ForceMajeure: fwiw, the old block genjix linked was not caused by the same issue
  83 2011-10-02 01:36:40 kreal has joined
  84 2011-10-02 01:37:12 kreal has left ()
  85 2011-10-02 01:38:19 K0lky has quit (Quit: Bye bye!)
  86 2011-10-02 01:38:26 <ForceMajeure> luke-jr: interesting. i'll have a closer look but do you know what caused this?
  87 2011-10-02 01:38:58 <genjix> someone created exactly the same coinbase transaction in 2 blocks
  88 2011-10-02 01:39:03 <luke-jr> ForceMajeure: no, that was before my time
  89 2011-10-02 01:39:06 <luke-jr> genjix: yes
  90 2011-10-02 01:39:10 <genjix> it's really old
  91 2011-10-02 01:39:25 <genjix> im surprised this isn't illegal though
  92 2011-10-02 01:39:32 AlexWaters has quit (Remote host closed the connection)
  93 2011-10-02 01:39:40 <luke-jr> genjix: you can also take less than 50 BTC
  94 2011-10-02 01:39:46 Detritus has joined
  95 2011-10-02 01:40:01 AlexWaters has joined
  96 2011-10-02 01:40:52 <genjix> yeah i know
  97 2011-10-02 01:40:55 <genjix> that's fine
  98 2011-10-02 01:43:46 AlexWaters has quit (Remote host closed the connection)
  99 2011-10-02 01:44:36 AlexWaters has joined
 100 2011-10-02 01:44:40 rdponticelli has quit (Ping timeout: 248 seconds)
 101 2011-10-02 01:46:39 shLONG has joined
 102 2011-10-02 01:48:16 <lfm> those duplicate coinbase txns happened twice.
 103 2011-10-02 01:48:47 <lfm> duplicate txn hash in blocks 91842 and 91812
 104 2011-10-02 01:48:51 <lfm> duplicate txn hash in blocks 91880 and 91722
 105 2011-10-02 01:49:47 AlexWaters1 has joined
 106 2011-10-02 01:50:23 AlexWaters has quit (Read error: Connection reset by peer)
 107 2011-10-02 01:51:10 Beremat has quit (Ping timeout: 244 seconds)
 108 2011-10-02 01:51:22 Beremat has joined
 109 2011-10-02 01:52:20 Beremat has quit (Client Quit)
 110 2011-10-02 01:52:21 AlexWaters has joined
 111 2011-10-02 01:52:39 ByteCoin has joined
 112 2011-10-02 01:53:00 AlexWaters1 has quit (Read error: Connection reset by peer)
 113 2011-10-02 01:55:16 AlexWaters has quit (Read error: Connection reset by peer)
 114 2011-10-02 01:57:15 <nanotube> so that means we actually have 100 fewer bitcoins than 50*blockcount eh?
 115 2011-10-02 01:57:16 zhoutong has quit (Read error: Connection reset by peer)
 116 2011-10-02 01:57:28 <nanotube> zomg deflation, buy your bitcoins while you still can!!111one! :)
 117 2011-10-02 01:57:48 zhoutong has joined
 118 2011-10-02 01:57:51 <lfm> well there is also the coins sent to the zero addresses and the "1" addresses.
 119 2011-10-02 01:58:01 AlexWaters has joined
 120 2011-10-02 01:58:06 <nanotube> heh
 121 2011-10-02 01:58:21 <nanotube> in that case, let me add a few more !!1s at the end there
 122 2011-10-02 01:58:57 <lfm> 1111111111111111111114oLvT2                 0.07210007
 123 2011-10-02 01:59:02 <lfm> 11111111111111111111BZbvjr                  0.01000000
 124 2011-10-02 01:59:15 <lfm> are afaik unrecoverable coins also
 125 2011-10-02 01:59:31 <genjix> thanks for telling me the other block lfm
 126 2011-10-02 01:59:33 <genjix> noted it
 127 2011-10-02 02:00:08 <lfm> any time
 128 2011-10-02 02:00:48 <nanotube> lfm: how did you find it?
 129 2011-10-02 02:01:00 <nanotube> (the other duplicate coinbase block, that is)
 130 2011-10-02 02:01:02 <lfm> I have a program that checks that
 131 2011-10-02 02:01:12 <nanotube> ah heh cool
 132 2011-10-02 02:01:23 <luke-jr> nanotube: 100.00000001
 133 2011-10-02 02:01:28 <genjix> libbitcoin crashed at that block :)
 134 2011-10-02 02:01:36 <genjix> i thought it was a bug on my part
 135 2011-10-02 02:01:41 <genjix> heart attack moment
 136 2011-10-02 02:01:42 <lfm> hehe
 137 2011-10-02 02:01:50 delson has joined
 138 2011-10-02 02:02:06 <nanotube> heh
 139 2011-10-02 02:02:15 <lfm> I was looking for double spend attemps and that poped up first but it wasnt what I thought
 140 2011-10-02 02:02:32 <nanotube> luke-jr: ah right, midnightmagic's 49.9999999 coinbase :)
 141 2011-10-02 02:02:41 <nanotube> +9
 142 2011-10-02 02:02:44 <delson> I have a question that I posted up on the forum....does anyone know if the debug log supports timestamps, and is there a way to filter out certain information (I only need transaction time stamps, block download timestamps, and that is it).
 143 2011-10-02 02:03:17 <lfm> delson: its open source. It should be easy to do
 144 2011-10-02 02:04:05 clr_ has quit (Read error: Operation timed out)
 145 2011-10-02 02:04:11 <delson> More or less, I was more curious if such a function already exists so I don't have to write one in.
 146 2011-10-02 02:04:18 <lfm> I think there is already a few timestamps in the log
 147 2011-10-02 02:04:40 <lfm> but its mostly what you see is what you get
 148 2011-10-02 02:06:14 zhoutong has quit (Read error: Connection reset by peer)
 149 2011-10-02 02:06:33 <lfm> ya there is the dicarded fee/reward of 0.01000001 also
 150 2011-10-02 02:06:53 zhoutong has joined
 151 2011-10-02 02:07:23 <lfm> plus there are a couple oddball output scrips I think were bugs and I think they are unrecoverable bitcoins also
 152 2011-10-02 02:08:03 <lfm> for another 0.00100001
 153 2011-10-02 02:08:14 AlexWaters has quit (Read error: Connection reset by peer)
 154 2011-10-02 02:09:13 Moonies has joined
 155 2011-10-02 02:09:19 AlexWaters has joined
 156 2011-10-02 02:09:33 <genjix> delson: i have an sql dump of the blockchain
 157 2011-10-02 02:09:39 <genjix> one sec
 158 2011-10-02 02:10:31 <genjix> delson: https://bitcointalk.org/index.php?topic=38246
 159 2011-10-02 02:11:02 <lfm> if you want the block numbers for those others I can find them too.
 160 2011-10-02 02:14:01 AlexWaters1 has joined
 161 2011-10-02 02:14:14 <delson> I am messing about with the idea of an alternate algorithm for the way transactions are processed...
 162 2011-10-02 02:14:22 AlexWaters has quit (Ping timeout: 240 seconds)
 163 2011-10-02 02:14:25 <delson> so these logs would essentially be based on an alternative bitcoin chain
 164 2011-10-02 02:14:41 AlexWaters1 has quit (Read error: Connection reset by peer)
 165 2011-10-02 02:15:12 AlexWaters has joined
 166 2011-10-02 02:17:12 zhoutong has quit (Read error: Connection reset by peer)
 167 2011-10-02 02:17:17 AlexWaters has quit (Remote host closed the connection)
 168 2011-10-02 02:17:49 AlexWaters has joined
 169 2011-10-02 02:18:20 zhoutong has joined
 170 2011-10-02 02:18:24 <genjix> lfm: btw is that only for coinbase transactions?
 171 2011-10-02 02:18:36 <genjix> or can it be for other transactions theoretically
 172 2011-10-02 02:19:06 <genjix> it seems so
 173 2011-10-02 02:22:41 zhoutong has quit (Read error: Connection reset by peer)
 174 2011-10-02 02:23:56 zhoutong has joined
 175 2011-10-02 02:25:46 zhoutong has quit (Read error: Connection reset by peer)
 176 2011-10-02 02:25:58 ahbritto has quit (Remote host closed the connection)
 177 2011-10-02 02:26:20 zhoutong has joined
 178 2011-10-02 02:26:40 ByteCoin has left ()
 179 2011-10-02 02:30:56 zhoutong has quit (Read error: Connection reset by peer)
 180 2011-10-02 02:31:04 crazy_imp has quit (Ping timeout: 260 seconds)
 181 2011-10-02 02:32:02 zhoutong has joined
 182 2011-10-02 02:32:55 crazy_imp has joined
 183 2011-10-02 02:34:41 ahbritto has joined
 184 2011-10-02 02:34:41 ahbritto has quit (Changing host)
 185 2011-10-02 02:34:42 ahbritto has joined
 186 2011-10-02 02:34:46 osmosis has quit (Quit: Leaving)
 187 2011-10-02 02:36:44 zhoutong has quit (Read error: Connection reset by peer)
 188 2011-10-02 02:37:19 zhoutong has joined
 189 2011-10-02 02:42:12 clr_ has joined
 190 2011-10-02 02:45:19 zhoutong has quit (Read error: Connection reset by peer)
 191 2011-10-02 02:46:00 Beremat has joined
 192 2011-10-02 02:46:20 zhoutong has joined
 193 2011-10-02 02:48:16 BlueMatt-mobile has joined
 194 2011-10-02 02:48:17 zhoutong has quit (Read error: Connection reset by peer)
 195 2011-10-02 02:48:21 TheSeven has quit (Disconnected by services)
 196 2011-10-02 02:48:23 BlueMatt-mobile has quit (Client Quit)
 197 2011-10-02 02:48:32 zhoutong has joined
 198 2011-10-02 02:48:33 [7] has joined
 199 2011-10-02 02:50:23 Moonies has quit (Quit: quack)
 200 2011-10-02 02:50:46 Beremat has quit (Ping timeout: 240 seconds)
 201 2011-10-02 02:50:53 Beremat has joined
 202 2011-10-02 02:59:26 Joric has joined
 203 2011-10-02 03:13:45 Xunie has quit (Ping timeout: 248 seconds)
 204 2011-10-02 03:14:43 gjs278 has quit (Remote host closed the connection)
 205 2011-10-02 03:18:10 zhoutong has quit (Read error: Connection reset by peer)
 206 2011-10-02 03:18:44 Beremat has quit (Read error: Connection reset by peer)
 207 2011-10-02 03:18:57 zhoutong has joined
 208 2011-10-02 03:19:42 Beremat has joined
 209 2011-10-02 03:21:13 zhoutong has quit (Read error: Connection reset by peer)
 210 2011-10-02 03:21:57 zhoutong has joined
 211 2011-10-02 03:24:26 delson has quit (Ping timeout: 252 seconds)
 212 2011-10-02 03:24:53 Beremat has quit (Ping timeout: 256 seconds)
 213 2011-10-02 03:24:57 Beremat has joined
 214 2011-10-02 03:26:46 _Burgundy has quit (Ping timeout: 245 seconds)
 215 2011-10-02 03:27:37 Xunie has joined
 216 2011-10-02 03:28:17 skeledrew has joined
 217 2011-10-02 03:30:03 Beremat has quit (Ping timeout: 258 seconds)
 218 2011-10-02 03:36:31 rdponticelli has joined
 219 2011-10-02 03:41:27 sshc has joined
 220 2011-10-02 03:42:33 toffoo has quit ()
 221 2011-10-02 03:55:36 osmosis has joined
 222 2011-10-02 04:05:53 zhoutong has quit (Read error: Connection reset by peer)
 223 2011-10-02 04:06:03 toffoo has joined
 224 2011-10-02 04:06:43 zhoutong has joined
 225 2011-10-02 04:13:36 copumpkin has quit (Quit: Computer has gone to sleep.)
 226 2011-10-02 04:17:58 copumpkin has joined
 227 2011-10-02 04:18:27 clr_ has quit (Ping timeout: 276 seconds)
 228 2011-10-02 04:19:42 zhoutong has quit (Read error: Connection reset by peer)
 229 2011-10-02 04:20:52 t3a has joined
 230 2011-10-02 04:21:00 zhoutong has joined
 231 2011-10-02 04:29:49 zhoutong has quit (Read error: Connection reset by peer)
 232 2011-10-02 04:30:52 zhoutong has joined
 233 2011-10-02 04:33:10 zhoutong has quit (Read error: Connection reset by peer)
 234 2011-10-02 04:33:21 minimoose has quit (Quit: minimoose)
 235 2011-10-02 04:33:49 zhoutong has joined
 236 2011-10-02 04:35:00 t3a_ has joined
 237 2011-10-02 04:37:09 zhoutong has quit (Read error: Connection reset by peer)
 238 2011-10-02 04:38:05 zhoutong has joined
 239 2011-10-02 04:39:06 t3a has quit (Ping timeout: 258 seconds)
 240 2011-10-02 04:39:44 clr_ has joined
 241 2011-10-02 04:44:10 TransistOrg has quit (Remote host closed the connection)
 242 2011-10-02 04:44:25 WakiMiko has quit (Ping timeout: 258 seconds)
 243 2011-10-02 04:44:33 TransistOrg has joined
 244 2011-10-02 04:47:09 zhoutong has quit (Read error: Connection reset by peer)
 245 2011-10-02 04:47:31 zhoutong has joined
 246 2011-10-02 04:48:38 magn3ts has quit (Ping timeout: 258 seconds)
 247 2011-10-02 04:49:32 copumpkin has quit (Quit: Computer has gone to sleep.)
 248 2011-10-02 04:51:51 ahbritto has quit (Quit: Ex-Chat)
 249 2011-10-02 04:54:48 shLONG has quit ()
 250 2011-10-02 04:58:17 Xunie has quit (Ping timeout: 248 seconds)
 251 2011-10-02 04:58:51 Zarutian has quit (Quit: Zarutian)
 252 2011-10-02 05:01:11 zhoutong has quit (Read error: Connection reset by peer)
 253 2011-10-02 05:02:20 zhoutong has joined
 254 2011-10-02 05:02:39 clr_ has quit (Ping timeout: 276 seconds)
 255 2011-10-02 05:03:06 Cusipzzz has quit (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/)
 256 2011-10-02 05:04:30 magn3ts has joined
 257 2011-10-02 05:08:54 toffoo has quit ()
 258 2011-10-02 05:08:54 zhoutong has quit (Read error: Connection reset by peer)
 259 2011-10-02 05:09:09 t3a_ has quit (Ping timeout: 276 seconds)
 260 2011-10-02 05:09:31 drewn has quit (Read error: Connection reset by peer)
 261 2011-10-02 05:10:01 zhoutong has joined
 262 2011-10-02 05:12:30 zhoutong has quit (Read error: Connection reset by peer)
 263 2011-10-02 05:12:38 drewn has joined
 264 2011-10-02 05:13:27 wolfspra1l has joined
 265 2011-10-02 05:13:35 zhoutong has joined
 266 2011-10-02 05:14:46 wolfspra1l has quit (Client Quit)
 267 2011-10-02 05:14:46 zhoutong has quit (Read error: Connection reset by peer)
 268 2011-10-02 05:14:57 osmosis has quit (Quit: Leaving)
 269 2011-10-02 05:15:08 wolfspra1l has joined
 270 2011-10-02 05:15:45 zhoutong has joined
 271 2011-10-02 05:16:15 wolfspraul has quit (Ping timeout: 258 seconds)
 272 2011-10-02 05:18:10 zhoutong has quit (Read error: Connection reset by peer)
 273 2011-10-02 05:18:59 zhoutong has joined
 274 2011-10-02 05:19:51 toffoo has joined
 275 2011-10-02 05:21:15 zhoutong has quit (Read error: Connection reset by peer)
 276 2011-10-02 05:21:59 BurtyB has quit (Ping timeout: 244 seconds)
 277 2011-10-02 05:22:00 zhoutong has joined
 278 2011-10-02 05:22:03 BurtyB has joined
 279 2011-10-02 05:23:53 zhoutong has quit (Read error: Connection reset by peer)
 280 2011-10-02 05:24:48 zhoutong has joined
 281 2011-10-02 05:25:39 <AlexWaters> anyone have a pull they want tested tonight? i'll trade some manual testing time for a unit test writeup for your pull
 282 2011-10-02 05:25:58 ahbritto has joined
 283 2011-10-02 05:25:59 ahbritto has quit (Changing host)
 284 2011-10-02 05:25:59 ahbritto has joined
 285 2011-10-02 05:26:04 ThomasV has joined
 286 2011-10-02 05:27:38 <diki> just to ask but...how does one mine a block and not broadcast it?
 287 2011-10-02 05:27:52 <diki> i've heard of stuff like that happen
 288 2011-10-02 05:27:54 <diki> but how?
 289 2011-10-02 05:27:59 <AlexWaters> you could mine while connected to one peer i believe
 290 2011-10-02 05:28:06 <Diablo-D3> just make your bitcoind not do it
 291 2011-10-02 05:28:13 <Diablo-D3> I dont see the point unless you're attempting a 51% attack
 292 2011-10-02 05:28:14 <AlexWaters> and make that one peer your other node
 293 2011-10-02 05:28:34 <AlexWaters> Diablo-D3: yeah i don't see any point to it other than that as well
 294 2011-10-02 05:29:52 <diki> jist
 295 2011-10-02 05:29:54 <diki> oops
 296 2011-10-02 05:30:10 <diki> just asking, i mean, basically anyone can do it as long as he mines two consecutive blocks
 297 2011-10-02 05:34:57 <AlexWaters> anyone know where I can download the Jenkins builds?
 298 2011-10-02 05:38:41 wolfspra1l has quit (Ping timeout: 252 seconds)
 299 2011-10-02 05:39:39 <nanotube> AlexWaters: bluematt might ;)
 300 2011-10-02 05:39:52 LightRider has joined
 301 2011-10-02 05:40:23 <nanotube> http://jenkins.bluematt.me/ <- maybe?
 302 2011-10-02 05:40:37 wolfspraul has joined
 303 2011-10-02 05:41:21 <AlexWaters> nanotube: I have looked in there, I don't see a way to download the binaries - I guess I could write a script that has jenkins push them to my repo
 304 2011-10-02 05:41:32 SomeoneWeirdzzzz is now known as SomoneWeird
 305 2011-10-02 05:42:44 zhoutong has quit (Read error: Connection reset by peer)
 306 2011-10-02 05:42:50 <nanotube> http://jenkins.bluematt.me/job/Bitcoin/ws/
 307 2011-10-02 05:42:52 <nanotube> try that
 308 2011-10-02 05:43:00 WakiMiko has joined
 309 2011-10-02 05:43:42 zhoutong has joined
 310 2011-10-02 05:44:34 <nanotube> AlexWaters: ^ (you get that by clicking the 'workspace' link
 311 2011-10-02 05:44:36 <nanotube> )
 312 2011-10-02 05:44:56 <Joric> http://jenkins.bluematt.me/job/Bitcoin/ws/ oh cool looks like it's a qt build
 313 2011-10-02 05:45:06 <Joric> does it have upnp enabled
 314 2011-10-02 05:45:44 <nanotube> dunno...
 315 2011-10-02 05:48:57 <Joric> it's not a qt build.... what the hell did i just launch? does it steal my wallet currently?
 316 2011-10-02 05:48:59 <AlexWaters> the bitcoin.exe file in there looks like WX i think
 317 2011-10-02 05:49:06 <Joric> it's wx yeah
 318 2011-10-02 05:49:14 <AlexWaters> Joric: I don't think so, haha
 319 2011-10-02 05:49:59 <nanotube> look for "STEAL_WALLET=1" in the makefile :)
 320 2011-10-02 05:50:02 <Joric> i've built my own qt version there was some problems with upnp 1.6 i recommend include it into the deps archive
 321 2011-10-02 05:50:16 <AlexWaters> in windowns?
 322 2011-10-02 05:50:23 <Joric> yeah mingw
 323 2011-10-02 05:50:40 <Joric> because, you know, without upnp it damages network and such
 324 2011-10-02 05:50:41 <AlexWaters> did you follow a guide, and do you mind posting it?
 325 2011-10-02 05:50:58 <AlexWaters> and I will try to build it that way to see what happens
 326 2011-10-02 05:51:36 <Joric> AlexWaters, i don't remember what i did linking problems probably wrong linking order
 327 2011-10-02 05:51:51 <Joric> got _imp_ instead of _
 328 2011-10-02 05:51:55 <AlexWaters> symlinking issues? I have the same problem last time I tried in windows
 329 2011-10-02 05:52:04 <AlexWaters> which is why i just download the binaries usually =P
 330 2011-10-02 05:52:46 <AlexWaters> bluematt does have a good guide somewhere though
 331 2011-10-02 05:54:53 TransistOrg has quit (Remote host closed the connection)
 332 2011-10-02 05:54:53 zhoutong has quit (Read error: Connection reset by peer)
 333 2011-10-02 05:55:14 TransistOrg has joined
 334 2011-10-02 05:55:23 zhoutong has joined
 335 2011-10-02 05:55:49 <genjix> what is the point of jenkins?
 336 2011-10-02 05:55:55 <genjix> i never understood CI
 337 2011-10-02 05:56:32 <genjix> or is it just that there's nightlies?
 338 2011-10-02 05:57:41 zhoutong has quit (Read error: Connection reset by peer)
 339 2011-10-02 05:57:42 <Joric> genjix, the whole point of CI is to provide regular automated builds
 340 2011-10-02 05:58:40 zhoutong has joined
 341 2011-10-02 05:58:54 <Joric> funny there's no qt build though
 342 2011-10-02 05:59:22 <genjix> why?
 343 2011-10-02 05:59:37 <genjix> for people to test, or simply to see if it builds?
 344 2011-10-02 05:59:56 <Joric> i guess, the latter
 345 2011-10-02 06:00:17 BTCTrader_ has joined
 346 2011-10-02 06:00:37 BTCTrader_ has quit (Changing host)
 347 2011-10-02 06:00:37 BTCTrader_ has joined
 348 2011-10-02 06:00:38 <genjix> weird. i would've thought it's for people to test (nightly builds) but then why it's called CI eludes me
 349 2011-10-02 06:02:40 ThomasV has quit (Ping timeout: 258 seconds)
 350 2011-10-02 06:02:40 zhoutong has quit (Read error: Connection reset by peer)
 351 2011-10-02 06:03:36 zhoutong has joined
 352 2011-10-02 06:04:52 pickett has quit (Remote host closed the connection)
 353 2011-10-02 06:04:52 zhoutong has quit (Read error: Connection reset by peer)
 354 2011-10-02 06:05:45 zhoutong has joined
 355 2011-10-02 06:08:18 zhoutong has quit (Read error: Connection reset by peer)
 356 2011-10-02 06:08:38 zhoutong has joined
 357 2011-10-02 06:09:11 ThomasV has joined
 358 2011-10-02 06:09:38 pickett has joined
 359 2011-10-02 06:12:26 zhoutong has quit (Read error: Connection reset by peer)
 360 2011-10-02 06:13:12 zhoutong has joined
 361 2011-10-02 06:14:30 zhoutong has quit (Read error: Connection reset by peer)
 362 2011-10-02 06:15:32 zhoutong has joined
 363 2011-10-02 06:15:36 <AlexWaters> i think one of the goals is to get it to be a more efficient test builder
 364 2011-10-02 06:16:04 <AlexWaters> it can run testing scripts against a repo, which is valuable to me
 365 2011-10-02 06:17:44 zhoutong has quit (Read error: Connection reset by peer)
 366 2011-10-02 06:18:48 zhoutong has joined
 367 2011-10-02 06:20:58 zhoutong has quit (Read error: Connection reset by peer)
 368 2011-10-02 06:21:48 zhoutong has joined
 369 2011-10-02 06:22:01 SomoneWeird is now known as SomeoneWeirdAFK
 370 2011-10-02 06:22:52 <genjix> ic
 371 2011-10-02 06:30:23 zhoutong has quit (Read error: Connection reset by peer)
 372 2011-10-02 06:31:20 zhoutong has joined
 373 2011-10-02 06:33:55 amtal has quit (Ping timeout: 255 seconds)
 374 2011-10-02 06:35:35 zhoutong has quit (Read error: Connection reset by peer)
 375 2011-10-02 06:35:37 amtal has joined
 376 2011-10-02 06:36:34 zhoutong has joined
 377 2011-10-02 06:38:28 zhoutong has quit (Read error: Connection reset by peer)
 378 2011-10-02 06:39:20 zhoutong has joined
 379 2011-10-02 06:40:27 zhoutong has quit (Read error: Connection reset by peer)
 380 2011-10-02 06:41:35 zhoutong has joined
 381 2011-10-02 06:42:48 zhoutong has quit (Read error: Connection reset by peer)
 382 2011-10-02 06:43:45 zhoutong has joined
 383 2011-10-02 06:45:50 zhoutong has quit (Read error: Connection reset by peer)
 384 2011-10-02 06:46:20 zhoutong has joined
 385 2011-10-02 06:48:08 zhoutong has quit (Read error: Connection reset by peer)
 386 2011-10-02 06:49:13 zhoutong has joined
 387 2011-10-02 06:50:22 noagendamarket has joined
 388 2011-10-02 06:51:05 ThomasV has quit (Ping timeout: 260 seconds)
 389 2011-10-02 06:51:21 <CIA-101> libbitcoin: genjix * r3ef9a341e162 / (include/bitcoin/script.hpp src/script.cpp): SIGHASH_SINGLE SIGHASH_NONE SIGHASH_ANYONECANPAY
 390 2011-10-02 06:51:22 <CIA-101> libbitcoin: genjix * r82ebcfd9925c / (bitcoin.sql src/storage/postgresql_storage.cpp): Handle duplicate transactions being in multiple blocks in the same chain.
 391 2011-10-02 06:51:24 <CIA-101> libbitcoin: genjix * r497e668216d3 /src/ (3 files in 2 dirs): VALIDATE BLOCKS COMPLETED!!! (search for double spends)
 392 2011-10-02 06:51:28 paul0 has quit (Quit: paul0)
 393 2011-10-02 06:55:03 zhoutong has quit (Read error: Connection reset by peer)
 394 2011-10-02 06:56:10 zhoutong has joined
 395 2011-10-02 07:02:37 zhoutong has quit (Read error: Connection reset by peer)
 396 2011-10-02 07:03:50 zhoutong has joined
 397 2011-10-02 07:07:34 RazielZ has joined
 398 2011-10-02 07:07:34 zhoutong has quit (Read error: Connection reset by peer)
 399 2011-10-02 07:08:28 zhoutong has joined
 400 2011-10-02 07:12:50 zhoutong has quit (Read error: Connection reset by peer)
 401 2011-10-02 07:13:55 zhoutong has joined
 402 2011-10-02 07:18:19 zhoutong has quit (Read error: Connection reset by peer)
 403 2011-10-02 07:19:25 zhoutong has joined
 404 2011-10-02 07:20:02 mmoya has joined
 405 2011-10-02 07:26:06 zhoutong has quit (Read error: Connection reset by peer)
 406 2011-10-02 07:27:01 zhoutong has joined
 407 2011-10-02 07:27:23 mmoya has quit (Ping timeout: 258 seconds)
 408 2011-10-02 07:28:51 zhoutong has quit (Read error: Connection reset by peer)
 409 2011-10-02 07:29:31 zhoutong has joined
 410 2011-10-02 07:36:12 zhoutong has quit (Read error: Connection reset by peer)
 411 2011-10-02 07:36:26 zhoutong has joined
 412 2011-10-02 07:38:18 pickett has quit (Ping timeout: 248 seconds)
 413 2011-10-02 07:39:00 dvide has joined
 414 2011-10-02 07:39:45 pickett has joined
 415 2011-10-02 07:42:43 TransistOrg has quit (Ping timeout: 258 seconds)
 416 2011-10-02 07:47:01 mrb_ has quit (Remote host closed the connection)
 417 2011-10-02 07:58:11 zhoutong has quit (Read error: Connection reset by peer)
 418 2011-10-02 07:59:08 zhoutong has joined
 419 2011-10-02 08:02:43 zhoutong has quit (Read error: Connection reset by peer)
 420 2011-10-02 08:03:21 zhoutong has joined
 421 2011-10-02 08:11:36 zhoutong has quit (Read error: Connection reset by peer)
 422 2011-10-02 08:11:59 zhoutong has joined
 423 2011-10-02 08:14:02 dsg has quit (Ping timeout: 244 seconds)
 424 2011-10-02 08:16:15 <sipa> the finney aattack depends on not jmmediately broadcasting
 425 2011-10-02 08:17:02 enquirer has joined
 426 2011-10-02 08:18:56 zhoutong has quit (Read error: Connection reset by peer)
 427 2011-10-02 08:19:00 AStove has joined
 428 2011-10-02 08:19:13 zhoutong has joined
 429 2011-10-02 08:21:00 dsg has joined
 430 2011-10-02 08:21:01 dsg has quit (Changing host)
 431 2011-10-02 08:21:01 dsg has joined
 432 2011-10-02 08:22:12 gjs278 has joined
 433 2011-10-02 08:22:31 zomtec has joined
 434 2011-10-02 08:23:36 Veladon has joined
 435 2011-10-02 08:23:36 zhoutong has quit (Read error: Connection reset by peer)
 436 2011-10-02 08:23:45 Veladon has quit (Client Quit)
 437 2011-10-02 08:24:09 Joric has quit ()
 438 2011-10-02 08:24:38 zhoutong has joined
 439 2011-10-02 08:28:10 zhoutong has quit (Read error: Connection reset by peer)
 440 2011-10-02 08:28:43 ajp6 has quit (Ping timeout: 276 seconds)
 441 2011-10-02 08:29:34 zhoutong has joined
 442 2011-10-02 08:32:10 zhoutong has quit (Read error: Connection reset by peer)
 443 2011-10-02 08:33:00 zhoutong has joined
 444 2011-10-02 08:35:52 Rabbit67890 has joined
 445 2011-10-02 08:37:12 zhoutong has quit (Read error: Connection reset by peer)
 446 2011-10-02 08:38:05 zhoutong has joined
 447 2011-10-02 08:38:35 marf_away has joined
 448 2011-10-02 08:39:49 b4epoche_ has quit (Ping timeout: 252 seconds)
 449 2011-10-02 08:42:47 BurtyB has quit (Read error: Connection reset by peer)
 450 2011-10-02 08:43:00 BurtyB has joined
 451 2011-10-02 08:44:36 zhoutong has quit (Read error: Connection reset by peer)
 452 2011-10-02 08:44:36 abragin has joined
 453 2011-10-02 08:44:37 abragin has quit (Changing host)
 454 2011-10-02 08:44:37 abragin has joined
 455 2011-10-02 08:45:30 zhoutong has joined
 456 2011-10-02 08:50:47 zhoutong has quit (Read error: Connection reset by peer)
 457 2011-10-02 08:51:43 zhoutong has joined
 458 2011-10-02 08:51:48 pensan has joined
 459 2011-10-02 08:53:46 zhoutong has quit (Read error: Connection reset by peer)
 460 2011-10-02 08:55:14 zhoutong has joined
 461 2011-10-02 08:56:45 zhoutong has quit (Read error: Connection reset by peer)
 462 2011-10-02 08:57:08 pensan has quit (Quit: Leaving)
 463 2011-10-02 08:57:45 zhoutong has joined
 464 2011-10-02 08:57:58 huk has quit (Ping timeout: 276 seconds)
 465 2011-10-02 08:58:58 coblee_ has joined
 466 2011-10-02 08:59:47 SomeoneWeirdAFK is now known as SomeoneWeird
 467 2011-10-02 09:02:56 iocor has joined
 468 2011-10-02 09:03:05 coblee has quit (Ping timeout: 260 seconds)
 469 2011-10-02 09:03:05 coblee_ is now known as coblee
 470 2011-10-02 09:04:15 zhoutong has quit (Read error: Connection reset by peer)
 471 2011-10-02 09:05:36 zhoutong has joined
 472 2011-10-02 09:07:46 zhoutong has quit (Read error: Connection reset by peer)
 473 2011-10-02 09:08:13 zhoutong has joined
 474 2011-10-02 09:12:04 zhoutong has quit (Read error: Connection reset by peer)
 475 2011-10-02 09:12:50 zhoutong has joined
 476 2011-10-02 09:25:27 Burgundy has joined
 477 2011-10-02 09:25:27 zhoutong has quit (Read error: Connection reset by peer)
 478 2011-10-02 09:26:32 zhoutong has joined
 479 2011-10-02 09:28:08 zhoutong has quit (Read error: Connection reset by peer)
 480 2011-10-02 09:28:43 zhoutong has joined
 481 2011-10-02 09:30:31 zhoutong has quit (Read error: Connection reset by peer)
 482 2011-10-02 09:30:56 zhoutong has joined
 483 2011-10-02 09:32:43 QueryTom3000 has joined
 484 2011-10-02 09:33:11 QueryTom3000 has left ()
 485 2011-10-02 09:38:28 zhoutong has quit (Read error: Connection reset by peer)
 486 2011-10-02 09:39:26 zhoutong has joined
 487 2011-10-02 09:40:36 zhoutong has quit (Read error: Connection reset by peer)
 488 2011-10-02 09:41:41 zhoutong has joined
 489 2011-10-02 09:41:46 toffoo has quit ()
 490 2011-10-02 09:44:23 Lopuz has joined
 491 2011-10-02 09:45:58 zhoutong has quit (Read error: Connection reset by peer)
 492 2011-10-02 09:46:36 zhoutong has joined
 493 2011-10-02 09:47:44 zhoutong has quit (Read error: Connection reset by peer)
 494 2011-10-02 09:48:25 wasabi1 has quit (Read error: Connection reset by peer)
 495 2011-10-02 09:48:51 zhoutong has joined
 496 2011-10-02 09:49:59 zhoutong has quit (Read error: Connection reset by peer)
 497 2011-10-02 09:51:01 zhoutong has joined
 498 2011-10-02 09:52:18 Turingi has joined
 499 2011-10-02 09:52:18 Turingi has quit (Changing host)
 500 2011-10-02 09:52:18 Turingi has joined
 501 2011-10-02 09:55:23 wasabi1 has joined
 502 2011-10-02 09:55:58 peck has quit (Ping timeout: 255 seconds)
 503 2011-10-02 10:00:40 peck has joined
 504 2011-10-02 10:00:53 ajp6 has joined
 505 2011-10-02 10:02:24 zhoutong has quit (Read error: Connection reset by peer)
 506 2011-10-02 10:03:02 zhoutong has joined
 507 2011-10-02 10:03:12 da2ce7 has quit (Remote host closed the connection)
 508 2011-10-02 10:06:49 da2ce7 has joined
 509 2011-10-02 10:06:50 zhoutong has quit (Read error: Connection reset by peer)
 510 2011-10-02 10:07:46 zhoutong has joined
 511 2011-10-02 10:10:45 marf_away has quit (Ping timeout: 260 seconds)
 512 2011-10-02 10:11:00 marf_away has joined
 513 2011-10-02 10:12:54 Firefly007 has quit (Ping timeout: 260 seconds)
 514 2011-10-02 10:14:24 upb has quit (Ping timeout: 240 seconds)
 515 2011-10-02 10:15:08 BTCTrader_ has quit (Quit: BTCTrader_)
 516 2011-10-02 10:16:01 cenuij has joined
 517 2011-10-02 10:16:01 cenuij has quit (Changing host)
 518 2011-10-02 10:16:01 cenuij has joined
 519 2011-10-02 10:18:56 zhoutong has quit (Read error: Connection reset by peer)
 520 2011-10-02 10:19:36 Rabbit67890 has quit (Quit: Rabbit67890)
 521 2011-10-02 10:19:47 zhoutong has joined
 522 2011-10-02 10:21:46 datagutt has joined
 523 2011-10-02 10:21:46 zhoutong has quit (Read error: Connection reset by peer)
 524 2011-10-02 10:21:47 datagutt has quit (Changing host)
 525 2011-10-02 10:21:47 datagutt has joined
 526 2011-10-02 10:22:21 zhoutong has joined
 527 2011-10-02 10:26:04 zhoutong has quit (Read error: Connection reset by peer)
 528 2011-10-02 10:26:54 zhoutong has joined
 529 2011-10-02 10:29:06 zhoutong has quit (Read error: Connection reset by peer)
 530 2011-10-02 10:29:52 zhoutong has joined
 531 2011-10-02 10:31:29 EPiSKiNG- has quit ()
 532 2011-10-02 10:34:18 peck has quit (Ping timeout: 245 seconds)
 533 2011-10-02 10:34:30 Firefly007 has joined
 534 2011-10-02 10:35:09 Runnigan has joined
 535 2011-10-02 10:36:16 andrew__ has joined
 536 2011-10-02 10:36:17 andrew__ has quit (Client Quit)
 537 2011-10-02 10:38:42 peck has joined
 538 2011-10-02 10:38:43 zhoutong has quit (Read error: Connection reset by peer)
 539 2011-10-02 10:39:28 peck has quit (Read error: Connection reset by peer)
 540 2011-10-02 10:40:00 zhoutong has joined
 541 2011-10-02 10:41:37 theorbtwo has quit (Read error: Connection reset by peer)
 542 2011-10-02 10:43:42 zhoutong has quit (Read error: Connection reset by peer)
 543 2011-10-02 10:44:58 zhoutong has joined
 544 2011-10-02 10:45:56 theorbtwo has joined
 545 2011-10-02 10:47:05 zhoutong has quit (Read error: Connection reset by peer)
 546 2011-10-02 10:47:06 Cokein has joined
 547 2011-10-02 10:48:09 zhoutong has joined
 548 2011-10-02 10:50:52 zomtec has quit (Ping timeout: 255 seconds)
 549 2011-10-02 10:56:12 peck has joined
 550 2011-10-02 10:58:58 zhoutong has quit (Read error: Connection reset by peer)
 551 2011-10-02 11:00:08 zhoutong has joined
 552 2011-10-02 11:01:59 zhoutong has quit (Read error: Connection reset by peer)
 553 2011-10-02 11:02:32 zhoutong has joined
 554 2011-10-02 11:04:12 zhoutong has quit (Read error: Connection reset by peer)
 555 2011-10-02 11:04:42 zhoutong has joined
 556 2011-10-02 11:04:47 t3a has joined
 557 2011-10-02 11:06:52 zhoutong has quit (Read error: Connection reset by peer)
 558 2011-10-02 11:07:58 zhoutong has joined
 559 2011-10-02 11:09:05 t3a has quit (Ping timeout: 260 seconds)
 560 2011-10-02 11:10:14 zhoutong has quit (Read error: Connection reset by peer)
 561 2011-10-02 11:11:16 zhoutong has joined
 562 2011-10-02 11:12:36 zhoutong has quit (Read error: Connection reset by peer)
 563 2011-10-02 11:13:32 zhoutong has joined
 564 2011-10-02 11:14:48 zhoutong has quit (Read error: Connection reset by peer)
 565 2011-10-02 11:15:28 mosimo has joined
 566 2011-10-02 11:15:44 zhoutong has joined
 567 2011-10-02 11:21:11 datagutt has quit (Quit: kthxbai)
 568 2011-10-02 11:23:55 zhoutong has quit (Read error: Connection reset by peer)
 569 2011-10-02 11:24:10 datagutt has joined
 570 2011-10-02 11:24:19 zhoutong has joined
 571 2011-10-02 11:27:07 Burgundy has quit (Ping timeout: 248 seconds)
 572 2011-10-02 11:33:28 zhoutong has quit (Read error: Connection reset by peer)
 573 2011-10-02 11:34:14 zhoutong has joined
 574 2011-10-02 11:35:36 zhoutong has quit (Read error: Connection reset by peer)
 575 2011-10-02 11:36:24 zhoutong has joined
 576 2011-10-02 11:37:10 erus` has joined
 577 2011-10-02 11:40:51 zhoutong has quit (Read error: Connection reset by peer)
 578 2011-10-02 11:42:00 zhoutong has joined
 579 2011-10-02 11:45:34 kish has quit (Quit: leaving)
 580 2011-10-02 11:46:02 kish has joined
 581 2011-10-02 11:54:15 zhoutong has quit (Read error: Connection reset by peer)
 582 2011-10-02 11:54:44 zhoutong has joined
 583 2011-10-02 11:56:02 ThomasV has joined
 584 2011-10-02 11:59:39 zhoutong has quit (Read error: Connection reset by peer)
 585 2011-10-02 12:00:05 zhoutong has joined
 586 2011-10-02 12:01:20 zhoutong has quit (Read error: Connection reset by peer)
 587 2011-10-02 12:02:18 zhoutong has joined
 588 2011-10-02 12:04:15 zhoutong has quit (Read error: Connection reset by peer)
 589 2011-10-02 12:04:50 zhoutong has joined
 590 2011-10-02 12:04:57 iocor has quit (Quit: Computer has gone to sleep.)
 591 2011-10-02 12:06:28 iddo has quit (Ping timeout: 258 seconds)
 592 2011-10-02 12:07:02 mizerydearia has joined
 593 2011-10-02 12:08:11 iddo has joined
 594 2011-10-02 12:11:28 zhoutong has quit (Read error: Connection reset by peer)
 595 2011-10-02 12:12:02 zhoutong has joined
 596 2011-10-02 12:12:39 peck has quit (Read error: Connection reset by peer)
 597 2011-10-02 12:15:09 iddo has quit (Changing host)
 598 2011-10-02 12:15:09 iddo has joined
 599 2011-10-02 12:15:19 peck has joined
 600 2011-10-02 12:18:43 zhoutong has quit (Read error: Connection reset by peer)
 601 2011-10-02 12:19:38 zhoutong has joined
 602 2011-10-02 12:20:43 zhoutong has quit (Read error: Connection reset by peer)
 603 2011-10-02 12:21:54 zhoutong has joined
 604 2011-10-02 12:23:43 ThomasV has quit (Ping timeout: 258 seconds)
 605 2011-10-02 12:25:28 zhoutong has quit (Read error: Connection reset by peer)
 606 2011-10-02 12:26:10 zhoutong has joined
 607 2011-10-02 12:30:34 zhoutong has quit (Read error: Connection reset by peer)
 608 2011-10-02 12:31:05 zhoutong has joined
 609 2011-10-02 12:35:16 eoss has joined
 610 2011-10-02 12:35:16 eoss has quit (Changing host)
 611 2011-10-02 12:35:16 eoss has joined
 612 2011-10-02 12:36:53 zhoutong has quit (Read error: Connection reset by peer)
 613 2011-10-02 12:37:14 ThomasV has joined
 614 2011-10-02 12:37:43 iddo has quit (Read error: Operation timed out)
 615 2011-10-02 12:37:49 iddo has joined
 616 2011-10-02 12:37:55 zhoutong has joined
 617 2011-10-02 12:39:22 zhoutong has quit (Read error: Connection reset by peer)
 618 2011-10-02 12:40:08 zhoutong has joined
 619 2011-10-02 12:40:44 <d33tah> if I arbitrarily change the bitcoin port from 8333 to anything different in protocol.h, will the bitcoin client manage to communicate with other peers?
 620 2011-10-02 12:42:17 zhoutong has quit (Read error: Connection reset by peer)
 621 2011-10-02 12:43:09 cenuij has quit (Remote host closed the connection)
 622 2011-10-02 12:43:21 zhoutong has joined
 623 2011-10-02 12:43:45 cenuij has joined
 624 2011-10-02 12:43:46 cenuij has quit (Changing host)
 625 2011-10-02 12:43:46 cenuij has joined
 626 2011-10-02 12:46:49 iddo has quit (Changing host)
 627 2011-10-02 12:46:49 iddo has joined
 628 2011-10-02 12:53:17 zhoutong has quit (Read error: Connection reset by peer)
 629 2011-10-02 12:53:47 zhoutong has joined
 630 2011-10-02 13:03:19 <Habbie> d33tah, i highly doubt it
 631 2011-10-02 13:04:19 <tcatm> d33tah: it will work but you should avoid changing the port
 632 2011-10-02 13:07:34 <da2ce7> tcatm, how hard would it be to make a version of bitcoin that works on the network that uses a diffent port randomly on every bootup.
 633 2011-10-02 13:08:25 <da2ce7> there is lost of issues with UPNP with using the same port.
 634 2011-10-02 13:08:32 <tcatm> writing the code would be easy
 635 2011-10-02 13:09:35 <tcatm> however, each nodes' address database might get outdated much sooner as not only a nodes IP but also its port can change
 636 2011-10-02 13:13:04 dinox has quit (Ping timeout: 260 seconds)
 637 2011-10-02 13:13:10 Burgundy has joined
 638 2011-10-02 13:13:57 magn3ts has quit (Ping timeout: 258 seconds)
 639 2011-10-02 13:16:03 p0s has joined
 640 2011-10-02 13:19:39 da2ce7 has quit (Ping timeout: 248 seconds)
 641 2011-10-02 13:19:59 dinox has joined
 642 2011-10-02 13:25:51 dinox has quit (Ping timeout: 252 seconds)
 643 2011-10-02 13:28:42 magn3ts has joined
 644 2011-10-02 13:28:43 zhoutong has quit (Read error: Connection reset by peer)
 645 2011-10-02 13:29:07 zhoutong has joined
 646 2011-10-02 13:30:40 zhoutong has quit (Read error: Connection reset by peer)
 647 2011-10-02 13:30:50 eoss has quit (Remote host closed the connection)
 648 2011-10-02 13:31:05 paul0 has joined
 649 2011-10-02 13:31:19 zhoutong has joined
 650 2011-10-02 13:33:38 da2ce7 has joined
 651 2011-10-02 13:39:07 zhoutong has quit (Read error: Connection reset by peer)
 652 2011-10-02 13:39:51 zhoutong has joined
 653 2011-10-02 13:54:26 MobiusL has quit (Quit: Leaving)
 654 2011-10-02 13:55:42 zhoutong has quit (Read error: Connection reset by peer)
 655 2011-10-02 13:56:37 zhoutong has joined
 656 2011-10-02 14:00:45 zhoutong has quit (Read error: Connection reset by peer)
 657 2011-10-02 14:01:03 zhoutong has joined
 658 2011-10-02 14:01:09 dinox has joined
 659 2011-10-02 14:01:09 MobiusL has joined
 660 2011-10-02 14:01:10 MobiusL has quit (Changing host)
 661 2011-10-02 14:01:10 MobiusL has joined
 662 2011-10-02 14:01:12 pickett has quit (Remote host closed the connection)
 663 2011-10-02 14:02:21 wolfspraul has quit (Ping timeout: 260 seconds)
 664 2011-10-02 14:03:11 wolfspraul has joined
 665 2011-10-02 14:03:58 SuprTiggr has joined
 666 2011-10-02 14:03:58 MrTiggr has joined
 667 2011-10-02 14:04:50 pickett has joined
 668 2011-10-02 14:05:14 ThomasV has quit (Ping timeout: 256 seconds)
 669 2011-10-02 14:06:35 dinox has quit (Ping timeout: 248 seconds)
 670 2011-10-02 14:07:48 dinox has joined
 671 2011-10-02 14:07:48 zhoutong has quit (Read error: Connection reset by peer)
 672 2011-10-02 14:08:44 zhoutong has joined
 673 2011-10-02 14:11:23 da2ce7 has quit (Ping timeout: 248 seconds)
 674 2011-10-02 14:12:29 dinox has quit (Ping timeout: 255 seconds)
 675 2011-10-02 14:13:16 p0s has quit (Remote host closed the connection)
 676 2011-10-02 14:15:17 Diablo-D3 has quit (Ping timeout: 260 seconds)
 677 2011-10-02 14:16:45 huk has joined
 678 2011-10-02 14:17:01 ar4s has joined
 679 2011-10-02 14:17:06 dinox has joined
 680 2011-10-02 14:18:41 ar4s has quit (Client Quit)
 681 2011-10-02 14:21:16 TheAncientGoat has joined
 682 2011-10-02 14:22:55 dinox has quit (Ping timeout: 258 seconds)
 683 2011-10-02 14:23:38 iocor has joined
 684 2011-10-02 14:23:39 dinox has joined
 685 2011-10-02 14:25:00 iocor_ has joined
 686 2011-10-02 14:28:26 iocor_ has quit (Read error: Connection reset by peer)
 687 2011-10-02 14:28:28 iocor has quit (Read error: Connection reset by peer)
 688 2011-10-02 14:28:32 iocor has joined
 689 2011-10-02 14:28:49 dinox has quit (Ping timeout: 240 seconds)
 690 2011-10-02 14:29:25 dinox has joined
 691 2011-10-02 14:31:18 zhoutong has quit (Read error: Connection reset by peer)
 692 2011-10-02 14:31:40 Lopuz has quit (Ping timeout: 248 seconds)
 693 2011-10-02 14:32:22 zhoutong has joined
 694 2011-10-02 14:33:57 dinox has quit (Ping timeout: 260 seconds)
 695 2011-10-02 14:34:16 dinox has joined
 696 2011-10-02 14:35:31 zhoutong has quit (Read error: Connection reset by peer)
 697 2011-10-02 14:36:38 zhoutong has joined
 698 2011-10-02 14:43:33 zhoutong has quit (Read error: Connection reset by peer)
 699 2011-10-02 14:43:59 zhoutong has joined
 700 2011-10-02 14:48:44 erle- has joined
 701 2011-10-02 14:49:59 zhoutong has quit (Read error: Connection reset by peer)
 702 2011-10-02 14:50:54 zhoutong has joined
 703 2011-10-02 14:54:54 zhoutong has quit (Read error: Connection reset by peer)
 704 2011-10-02 14:55:42 zhoutong has joined
 705 2011-10-02 14:56:03 theorb has joined
 706 2011-10-02 14:57:19 theorbtwo has quit (Remote host closed the connection)
 707 2011-10-02 14:57:29 theorb is now known as theorbtwo
 708 2011-10-02 14:59:22 skeledrew has quit (Ping timeout: 258 seconds)
 709 2011-10-02 15:01:31 ThomasV has joined
 710 2011-10-02 15:06:48 zhoutong has quit (Read error: Connection reset by peer)
 711 2011-10-02 15:07:40 zhoutong has joined
 712 2011-10-02 15:08:54 copumpkin has joined
 713 2011-10-02 15:08:54 zhoutong has quit (Read error: Connection reset by peer)
 714 2011-10-02 15:09:02 erle- has quit (Read error: Operation timed out)
 715 2011-10-02 15:10:01 zhoutong has joined
 716 2011-10-02 15:10:14 clr_ has joined
 717 2011-10-02 15:10:22 iocor has quit (Quit: Computer has gone to sleep.)
 718 2011-10-02 15:13:16 ThomasV has quit (Ping timeout: 248 seconds)
 719 2011-10-02 15:13:59 Daniel0108 has quit (Quit: Bye! Check out #TouchLay)
 720 2011-10-02 15:17:30 Daniel0108 has joined
 721 2011-10-02 15:19:40 fnord0 has quit (Ping timeout: 248 seconds)
 722 2011-10-02 15:19:40 zhoutong has quit (Read error: Connection reset by peer)
 723 2011-10-02 15:20:39 Daniel0108 has quit (Changing host)
 724 2011-10-02 15:20:39 Daniel0108 has joined
 725 2011-10-02 15:20:39 zhoutong has joined
 726 2011-10-02 15:25:30 Daniel0108 has quit (Quit: Fixing all those problems)
 727 2011-10-02 15:28:36 ThomasV has joined
 728 2011-10-02 15:29:06 Zarutian has joined
 729 2011-10-02 15:31:38 Daniel0108 has joined
 730 2011-10-02 15:34:08 da2ce7 has joined
 731 2011-10-02 15:34:08 abragin has quit (Read error: Connection reset by peer)
 732 2011-10-02 15:35:38 abragin has joined
 733 2011-10-02 15:35:43 abragin has quit (Changing host)
 734 2011-10-02 15:35:43 abragin has joined
 735 2011-10-02 15:37:22 zhoutong has quit (Read error: Connection reset by peer)
 736 2011-10-02 15:37:54 Cusipzzz has joined
 737 2011-10-02 15:37:55 Turingi has quit (Read error: Connection reset by peer)
 738 2011-10-02 15:38:21 zhoutong has joined
 739 2011-10-02 15:39:41 SomeoneWeird is now known as SomeoneWeirdzzzz
 740 2011-10-02 15:40:59 theorbtwo has quit (Ping timeout: 245 seconds)
 741 2011-10-02 15:43:02 gjs278 has quit (Remote host closed the connection)
 742 2011-10-02 15:48:08 eoss has joined
 743 2011-10-02 15:48:08 eoss has quit (Changing host)
 744 2011-10-02 15:48:08 eoss has joined
 745 2011-10-02 15:49:15 clr_ has quit (Ping timeout: 244 seconds)
 746 2011-10-02 15:52:21 wasabi1 has quit (Ping timeout: 256 seconds)
 747 2011-10-02 15:52:37 ThomasV has quit (Ping timeout: 260 seconds)
 748 2011-10-02 15:52:49 fnord0 has joined
 749 2011-10-02 15:52:54 wasabi1 has joined
 750 2011-10-02 15:54:29 karnac has joined
 751 2011-10-02 15:55:18 wpl has quit (Ping timeout: 258 seconds)
 752 2011-10-02 15:55:53 sshc_ has joined
 753 2011-10-02 15:57:00 AStove has quit ()
 754 2011-10-02 15:57:01 wpl has joined
 755 2011-10-02 15:58:36 zhoutong has quit (Read error: Connection reset by peer)
 756 2011-10-02 15:59:08 sshc has quit (Ping timeout: 255 seconds)
 757 2011-10-02 15:59:11 zhoutong has joined
 758 2011-10-02 16:01:54 fnord0 has quit (Read error: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number)
 759 2011-10-02 16:12:28 zhoutong has quit (Read error: Connection reset by peer)
 760 2011-10-02 16:13:05 zhoutong has joined
 761 2011-10-02 16:14:52 zhoutong has quit (Read error: Connection reset by peer)
 762 2011-10-02 16:15:29 zhoutong has joined
 763 2011-10-02 16:17:18 zhoutong has quit (Read error: Connection reset by peer)
 764 2011-10-02 16:18:12 zhoutong has joined
 765 2011-10-02 16:18:29 TheAncientGoat has quit (Ping timeout: 245 seconds)
 766 2011-10-02 16:22:57 zhoutong has quit (Read error: Connection reset by peer)
 767 2011-10-02 16:23:24 zhoutong has joined
 768 2011-10-02 16:26:16 sshc_ is now known as sshc
 769 2011-10-02 16:26:25 erle- has joined
 770 2011-10-02 16:27:25 gavinandresen has joined
 771 2011-10-02 16:43:06 danbri has quit (Remote host closed the connection)
 772 2011-10-02 16:43:07 zhoutong has quit (Read error: Connection reset by peer)
 773 2011-10-02 16:44:05 zhoutong has joined
 774 2011-10-02 16:47:47 danbri has joined
 775 2011-10-02 16:52:09 gjs278 has joined
 776 2011-10-02 16:53:46 clr_ has joined
 777 2011-10-02 16:54:04 noagendamarket has quit (Ping timeout: 248 seconds)
 778 2011-10-02 16:57:33 wasabi2 has joined
 779 2011-10-02 16:59:11 wasabi1 has quit (Ping timeout: 252 seconds)
 780 2011-10-02 17:00:20 skeledrew has joined
 781 2011-10-02 17:04:33 niet_ has joined
 782 2011-10-02 17:04:41 HarryS has quit (Ping timeout: 244 seconds)
 783 2011-10-02 17:05:49 erle- has quit (Quit: CETERVM•AVTEM•CENSEO•FDP•ESSE•DELENDVM)
 784 2011-10-02 17:11:12 zhoutong has quit (Read error: Connection reset by peer)
 785 2011-10-02 17:12:14 genjix has left ()
 786 2011-10-02 17:12:15 zhoutong has joined
 787 2011-10-02 17:15:52 phatsphere has joined
 788 2011-10-02 17:19:00 localhost has quit (Remote host closed the connection)
 789 2011-10-02 17:19:40 da2ce7 has quit (Ping timeout: 248 seconds)
 790 2011-10-02 17:22:34 localhost has joined
 791 2011-10-02 17:23:45 zhoutong has quit (Read error: Connection reset by peer)
 792 2011-10-02 17:24:53 zhoutong has joined
 793 2011-10-02 17:30:32 Lopuz has joined
 794 2011-10-02 17:30:32 zhoutong has quit (Read error: Connection reset by peer)
 795 2011-10-02 17:31:40 zhoutong has joined
 796 2011-10-02 17:37:42 magn3ts has quit (Ping timeout: 258 seconds)
 797 2011-10-02 17:40:25 AStove has joined
 798 2011-10-02 17:43:25 skeledrew1 has joined
 799 2011-10-02 17:43:51 Lopuz has quit (Ping timeout: 276 seconds)
 800 2011-10-02 17:45:09 skeledrew has quit (Ping timeout: 276 seconds)
 801 2011-10-02 17:47:36 zhoutong has quit (Read error: Connection reset by peer)
 802 2011-10-02 17:47:59 zhoutong has joined
 803 2011-10-02 17:48:31 Schematografter has joined
 804 2011-10-02 17:49:30 Schematografter has quit (Read error: Connection reset by peer)
 805 2011-10-02 17:50:59 BTCTrader_ has joined
 806 2011-10-02 17:51:10 BTCTrader_ has quit (Changing host)
 807 2011-10-02 17:51:10 BTCTrader_ has joined
 808 2011-10-02 17:51:42 Schematografter has joined
 809 2011-10-02 17:52:31 Schematografter has quit (Read error: Connection reset by peer)
 810 2011-10-02 17:52:33 magn3ts has joined
 811 2011-10-02 18:03:48 Rabbit67890 has joined
 812 2011-10-02 18:05:38 WakiMiko has quit (Ping timeout: 252 seconds)
 813 2011-10-02 18:06:30 WakiMiko has joined
 814 2011-10-02 18:09:12 phatsphere has quit (Ping timeout: 255 seconds)
 815 2011-10-02 18:11:01 ThomasV has joined
 816 2011-10-02 18:12:56 skeledrew1 has quit (Ping timeout: 258 seconds)
 817 2011-10-02 18:14:16 skeledrew has joined
 818 2011-10-02 18:16:56 TheAncientGoat has joined
 819 2011-10-02 18:18:30 zhoutong has quit (Read error: Connection reset by peer)
 820 2011-10-02 18:19:07 zhoutong has joined
 821 2011-10-02 18:21:13 Zarutian has quit (Ping timeout: 240 seconds)
 822 2011-10-02 18:21:30 phatsphere has joined
 823 2011-10-02 18:22:26 larsivi has joined
 824 2011-10-02 18:24:20 TheAncientGoat has quit (Ping timeout: 245 seconds)
 825 2011-10-02 18:25:48 zhoutong has quit (Read error: Connection reset by peer)
 826 2011-10-02 18:26:34 zhoutong has joined
 827 2011-10-02 18:28:00 zhoutong has quit (Read error: Connection reset by peer)
 828 2011-10-02 18:28:12 niet_ has quit (Quit: Leaving)
 829 2011-10-02 18:28:46 zhoutong has joined
 830 2011-10-02 18:28:47 Zarutian has joined
 831 2011-10-02 18:29:04 copumpkin has quit (Ping timeout: 258 seconds)
 832 2011-10-02 18:29:30 copumpkin has joined
 833 2011-10-02 18:33:06 Sedra has joined
 834 2011-10-02 18:33:51 amtal_ has joined
 835 2011-10-02 18:36:09 Daniel0108 has quit (Quit: Bye! Check out #TouchLay)
 836 2011-10-02 18:37:05 amtal has quit (Ping timeout: 260 seconds)
 837 2011-10-02 18:37:08 MimeNarrator has quit (Read error: Connection reset by peer)
 838 2011-10-02 18:38:40 Daniel0108 has joined
 839 2011-10-02 18:38:57 Beremat has joined
 840 2011-10-02 18:39:58 Daniel0108 has quit (Changing host)
 841 2011-10-02 18:39:58 Daniel0108 has joined
 842 2011-10-02 18:40:39 grbgout has quit (Read error: Operation timed out)
 843 2011-10-02 18:44:25 Beremat has quit (Ping timeout: 260 seconds)
 844 2011-10-02 18:44:34 Beremat has joined
 845 2011-10-02 18:46:58 <sipa> the current bitcoin blockchain contains 179 MB of non-script data, and 467 MB of script data
 846 2011-10-02 18:47:32 <sipa> the non-script data seems extremely compressible (idea by gmaxwell): i implemented a CABAC for it that reduces it to 17 MB
 847 2011-10-02 18:47:42 drewn has quit (Read error: Connection reset by peer)
 848 2011-10-02 18:48:05 drewn has joined
 849 2011-10-02 18:48:21 <sipa> using key recovery, the script data itself should be compressible by a factor 2 at least as well
 850 2011-10-02 18:49:42 Beremat has quit (Ping timeout: 255 seconds)
 851 2011-10-02 18:49:54 Beremat has joined
 852 2011-10-02 18:50:53 <gavinandresen> I'm probably reading the code wrong, but I think OP_EVAL wouldn't cause a blockchain split!
 853 2011-10-02 18:51:29 <sipa> how so? each client that doesn't support it would fail verifying such a transaction
 854 2011-10-02 18:51:49 <sipa> so the first time an OP_EVAL txout is spent, it would cause a blockchain split for those clients
 855 2011-10-02 18:51:54 <gavinandresen> Nope.  They'd look like anybody-can-spend transactions to old clients, assuming we use OP_NOP1 for OP_EVAL
 856 2011-10-02 18:51:59 Blitzboom_ has joined
 857 2011-10-02 18:52:08 <sipa> hmm, nice
 858 2011-10-02 18:52:11 <sipa> didn't know that
 859 2011-10-02 18:52:24 <gavinandresen> Me neither until I started scoping out how much work OP_EVAL would be just now
 860 2011-10-02 18:53:10 <gavinandresen> Counting SigOps looks like it would be trickier.
 861 2011-10-02 18:54:02 Blitzboom has quit (Ping timeout: 252 seconds)
 862 2011-10-02 18:55:03 <sipa> what is still possible though, is an old miner accepting an invalid OP_EVAL-using script
 863 2011-10-02 18:55:14 <sipa> that would cause its blocks to be ignored by newer clients
 864 2011-10-02 18:55:28 <gavinandresen> yes, still need a majority of miners to upgrade
 865 2011-10-02 18:55:40 Blitzboom_ is now known as Blitzboom
 866 2011-10-02 18:55:45 Blitzboom has quit (Changing host)
 867 2011-10-02 18:55:45 Blitzboom has joined
 868 2011-10-02 18:55:50 <sipa> that's indeed only a minor issue if you wait long enough for rolling it out
 869 2011-10-02 18:57:00 Rabbit67890 has quit (Quit: Rabbit67890)
 870 2011-10-02 18:58:05 zhoutong has quit (Read error: Connection reset by peer)
 871 2011-10-02 18:58:20 <ThomasV> is there an option to disable keypool extension?
 872 2011-10-02 18:58:41 <gavinandresen> what do you mean 'keypool extension' ?
 873 2011-10-02 18:58:58 <ThomasV> the creation of new keys
 874 2011-10-02 18:59:11 zhoutong has joined
 875 2011-10-02 18:59:31 <ThomasV> if I use -keypool=n, does it do that?
 876 2011-10-02 18:59:56 <gavinandresen> That just sets the min number of keys in the pool, bitcoin will still create new keys.
 877 2011-10-02 19:00:02 <gavinandresen> What do you need it for?
 878 2011-10-02 19:00:21 <gavinandresen> I've been running the bitcoin faucet with a -noprivacy patch that avoid creating new keys.
 879 2011-10-02 19:00:52 <ThomasV> oh, I think I already talked about that with you ; I would like to have a wallet that I can save once and for all
 880 2011-10-02 19:01:20 <ThomasV> imo this should be the default behaviour,  btw
 881 2011-10-02 19:01:22 paul0 has quit (Ping timeout: 252 seconds)
 882 2011-10-02 19:01:51 <gavinandresen> noprivacy does that, assuming you never explicitly ask for new keys.  It can make the accounts code very confused, though.
 883 2011-10-02 19:02:19 <ThomasV> the accounts code?
 884 2011-10-02 19:02:42 <gavinandresen> Yes, sendfrom, getaccountaddress, etc....
 885 2011-10-02 19:02:58 skeledrew has quit (Ping timeout: 252 seconds)
 886 2011-10-02 19:03:08 <gavinandresen> the RPC api used if you've got a web service that needs to keep track of balances for different users in the same wallet
 887 2011-10-02 19:03:18 <luke-jr> [14:41:17] <gavinandresen> Nope.  They'd look like anybody-can-spend transactions to old clients, assuming we use OP_NOP1 for OP_EVAL
 888 2011-10-02 19:03:29 <luke-jr> so then old clients accept them as valid, and new ones don't…
 889 2011-10-02 19:03:37 <luke-jr> and we have a malicious fork
 890 2011-10-02 19:04:06 <ThomasV> gavinandresen: where is that patch ? is it a pull request ?
 891 2011-10-02 19:04:07 <gavinandresen> luke-jr: right, have to assume that a majority of miners upgrade
 892 2011-10-02 19:04:07 <luke-jr> ah, sipa noted that
 893 2011-10-02 19:04:11 Rabbit67890 has joined
 894 2011-10-02 19:04:14 <gavinandresen> ThomasV: not a pull request:  https://github.com/gavinandresen/bitcoin-git/commit/47e2066ffc9c67de661f1e59ffe65a912fa3c4cc
 895 2011-10-02 19:05:01 skeledrew has joined
 896 2011-10-02 19:05:02 <ThomasV> I see
 897 2011-10-02 19:05:03 <gavinandresen> luke-jr:   ... generate a couple of evil transactions and that should give miners a pretty big incentive to upgrade....
 898 2011-10-02 19:05:33 <luke-jr> gavinandresen: or make OP_EVAL invalid ;)
 899 2011-10-02 19:05:39 <sipa> gavinandresen: i think you're right, a "OP_DUP OP_HASH160 <scriptHash> OP_EQUALVERIFY OP_EVAL" script should evaluate to true if OP_EVAL=OP_NOP1
 900 2011-10-02 19:06:21 <luke-jr> how many OP_NOPs are there?
 901 2011-10-02 19:06:26 casascius has quit (Ping timeout: 252 seconds)
 902 2011-10-02 19:06:27 <luke-jr> ie, will this hack only work once?
 903 2011-10-02 19:06:31 <gavinandresen> sipa:  yes, it will.  luke-jr : see script.h
 904 2011-10-02 19:07:01 <gavinandresen> luke-jr: there are 10 of them.
 905 2011-10-02 19:07:01 <sipa> 10
 906 2011-10-02 19:07:02 skeledrew has quit (Read error: Connection reset by peer)
 907 2011-10-02 19:07:13 <luke-jr> why not start at OP_NOP10?
 908 2011-10-02 19:07:17 skeledrew has joined
 909 2011-10-02 19:07:20 <luke-jr> for reusing
 910 2011-10-02 19:07:38 <gavinandresen> start at the end?  is there a good reason to?
 911 2011-10-02 19:07:48 paul0 has joined
 912 2011-10-02 19:07:51 <luke-jr> so the OP_NOPs are together?
 913 2011-10-02 19:07:59 <luke-jr> or I guess OP_NOP2 doesn't follow OP_NOP anyway
 914 2011-10-02 19:08:15 <sipa> i don't see what you're saying
 915 2011-10-02 19:08:19 <luke-jr> so they go in sequential order, instead of 1 3 4 5 6 7 8 9 10? :P
 916 2011-10-02 19:08:34 <luke-jr> cosmetics
 917 2011-10-02 19:08:37 TheAncientGoat has joined
 918 2011-10-02 19:08:54 <sipa> 2--10 are as sequential as 1--9 is?
 919 2011-10-02 19:09:13 clr_ has quit (Ping timeout: 244 seconds)
 920 2011-10-02 19:09:21 <luke-jr> sipa: if you replace OP_NOP2 with OP_EVAL, then it's 1, 3-10
 921 2011-10-02 19:09:36 <sipa> and why would you do that?
 922 2011-10-02 19:09:40 <luke-jr> if OP_NOP10 is replaced first, then it's 1-9
 923 2011-10-02 19:09:45 <luke-jr> …
 924 2011-10-02 19:09:59 <sipa> why not just use OP_NOP1?
 925 2011-10-02 19:10:34 <luke-jr> I assume OP_NOP(1) is already in existing transactions
 926 2011-10-02 19:11:05 <sipa> ah, that's a good point - no idea if it is, though
 927 2011-10-02 19:11:12 <luke-jr> in fact, I'm certain it is
 928 2011-10-02 19:11:17 <luke-jr> seeing as i've used it
 929 2011-10-02 19:11:19 <luke-jr> :p
 930 2011-10-02 19:11:23 <gavinandresen> that's a good point; will have to interpret as OP_EVAL after a certain date or block number
 931 2011-10-02 19:11:47 <luke-jr> no need to, if you're careful about it
 932 2011-10-02 19:11:56 casascius has joined
 933 2011-10-02 19:12:25 <gavinandresen> luke-jr: how so?  If there is already an OP_NOP1 in the blockchain then interpreting it as OP_EVAL would make the block invalid
 934 2011-10-02 19:12:55 <luke-jr> if.
 935 2011-10-02 19:13:07 <luke-jr> careful implies making sure there's no existing use :P
 936 2011-10-02 19:13:25 <luke-jr> and coordinating the upgrade with the bigger pools before there is
 937 2011-10-02 19:13:32 <sipa> gavinandresen: also, it is possible to create valid OP_EVAL-based scripts that evaluate to false when interpreating it as OP_NOP
 938 2011-10-02 19:13:42 <sipa> hmm, maybe not
 939 2011-10-02 19:13:44 <gavinandresen> sipa: no
 940 2011-10-02 19:14:01 <sipa> i'm quite sure it is
 941 2011-10-02 19:14:04 <luke-jr> sipa: OP_EVAL could simply require the "if I was a NOP, I'd be true" state as a safeguard
 942 2011-10-02 19:14:07 <gavinandresen> I don't think the zero-byte is a valid opcode
 943 2011-10-02 19:14:16 <sipa> it isn't
 944 2011-10-02 19:15:07 <gavinandresen> ... or is it-- OP_0 is 0 ?
 945 2011-10-02 19:15:25 <sipa> wait, let me find an example
 946 2011-10-02 19:15:35 TheAncientGoat has quit (Ping timeout: 245 seconds)
 947 2011-10-02 19:17:08 <sipa> but eg. a "OP_DUP OP_HASH160 <scriptHash> OP_EQUALVERIFY OP_EVAL 0 OP_NUMEQUAL OP_VERIFY" script
 948 2011-10-02 19:17:28 <sipa> and the eval'ed script produces a 0 on the stack
 949 2011-10-02 19:17:42 glitch-mod has quit (Read error: Connection reset by peer)
 950 2011-10-02 19:18:13 <gavinandresen> ... valid on new chain, invalid on old....
 951 2011-10-02 19:18:22 <gavinandresen> ... so blockchain split.
 952 2011-10-02 19:19:11 wasabi2 has quit (Ping timeout: 256 seconds)
 953 2011-10-02 19:19:17 ByteCoin has joined
 954 2011-10-02 19:19:20 <sipa> depending on how strictly you need to prevent that, only let scripts which evaluate both using the old and using the new interpretation to true
 955 2011-10-02 19:19:30 <casascius> Even if the blockchain doesn't get split with OP_EVAL, isn't it going to split eventually shortly after?  I mean, this will delay the blockchain split just enough for someone to spend their funds encumbered with OP_EVAL, which will result in a cascade of new transactions that all look invalid to the existing client base.
 956 2011-10-02 19:19:35 wasabi1 has joined
 957 2011-10-02 19:19:42 glitch-mod has joined
 958 2011-10-02 19:19:46 <gavinandresen> sipa: about to say that.  Feels like a hack....
 959 2011-10-02 19:20:07 <gavinandresen> casascius: no, because old clients accept the OP_EVAL transaction as valid
 960 2011-10-02 19:20:26 <gavinandresen> (interpreting the OP_EVAL as a no-op)
 961 2011-10-02 19:20:27 <casascius> the op_eval transaction is valid, but the one spending it won't be
 962 2011-10-02 19:20:34 <ByteCoin> Gavin: Have you considered casascius' option to use the same number for OP_EVAL as for OP_CHECKSIG?
 963 2011-10-02 19:20:35 RazielZ has quit (Quit: Leaving)
 964 2011-10-02 19:20:38 <gavinandresen> casascius: yes it will
 965 2011-10-02 19:20:54 <sipa> ByteCoin: that sounds even more dangerous
 966 2011-10-02 19:20:59 <gavinandresen> ByteCoin: I don't like that idea
 967 2011-10-02 19:21:14 <ByteCoin> sipa & Gavin: Initially, I didn't like it.
 968 2011-10-02 19:21:26 <ByteCoin> casascius isn't proposing it now.
 969 2011-10-02 19:21:31 <ByteCoin> I've really come round to it
 970 2011-10-02 19:21:38 <ByteCoin> No new addresses needed!
 971 2011-10-02 19:21:53 <ByteCoin> Back compatible
 972 2011-10-02 19:21:57 <ByteCoin> No blockchain split
 973 2011-10-02 19:22:05 <gavinandresen> I think a new bitcoin address would be a selling point:  New and Improved with Better Security!
 974 2011-10-02 19:22:18 <casascius> I believe a blockchain split would be necessary....(I could be wrong)...if one weren't necessary I would totally still be promoting the idea
 975 2011-10-02 19:22:19 <sipa> also, the whole thing feels like one big workaround for the fact that we can't tell someone directly which txout to put in his tx to you
 976 2011-10-02 19:23:01 <ThomasV> casascius: has your deterministic wallet been implemented as a patch for the bitcoin client?
 977 2011-10-02 19:23:05 <sipa> although it is very powerful and there may be advantages to an OP_EVAL beyond overcoming that restriction
 978 2011-10-02 19:23:11 <gavinandresen> sipa: you can't always communicate in real time with whoever you're paying....
 979 2011-10-02 19:23:15 <ByteCoin> sipa: If you think about it. Casascius' implementation is how bitcoin should have handled redemptions right from the start.
 980 2011-10-02 19:23:34 <casascius> I don't think a new bitcoin address would be a selling point.  It would be one more thing that would burden the public with the perceived need to feel the difference. To the public eye, a "longer bunch of gibberish" starting with a 2 isn't better than a "bunch of gibberish" starting with a 1, it is worse
 981 2011-10-02 19:23:39 <sipa> gavinandresen: not even real time
 982 2011-10-02 19:23:42 <ByteCoin> In the same way that you don't send to a public key, you send to a hash of a public key
 983 2011-10-02 19:23:47 <sipa> gavinandresen: you're giving someone an address
 984 2011-10-02 19:23:58 <sipa> gavinandresen: why can't you give him the txout script directly instead?
 985 2011-10-02 19:24:10 <sipa> is size the problem?
 986 2011-10-02 19:24:55 <ByteCoin> sipa; I believe theymos had objections based on the size
 987 2011-10-02 19:24:55 <gavinandresen> sipa: yes, size is the problem.  OP_EVAL lets you give the hash of the txout script, right?
 988 2011-10-02 19:25:21 <sipa> gavinandresen: yes, yes i agree, OP_EVAL allows you to give anyone any script with a fixed size string
 989 2011-10-02 19:25:28 <sipa> that is an advantage
 990 2011-10-02 19:25:33 <sipa> but that's the only one, right?
 991 2011-10-02 19:25:40 <ByteCoin> OP_EVAL let's you provide effectively the hash of what we now would have to put in the sciptSig
 992 2011-10-02 19:26:13 <casascius> Ultimately, these complex transactions should be able to become the norm, rather than a corner case.  If 2-of-3 was just the normal way people held onto bitcoins, and used a third party to control one of their keys, that would solve bitcoin's theft problem dramatically
 993 2011-10-02 19:26:15 <ByteCoin> sipa: It;s future proof and the complexity burden is bourne by the sender
 994 2011-10-02 19:26:22 <ByteCoin> of the address
 995 2011-10-02 19:26:23 <sipa> ByteCoin: agree
 996 2011-10-02 19:26:37 <gavinandresen> sipa: yes, and size matters when it comes to transaction fees
 997 2011-10-02 19:27:04 <gavinandresen> Having the receiver pay the bulk of the fees for big, complicated transaction types is a big plus in my opinion
 998 2011-10-02 19:27:25 <sipa> ok, true
 999 2011-10-02 19:27:57 <sipa> it increases the total load on the block chain a bit, but it shifts who is responsible for most of it
1000 2011-10-02 19:28:30 <sipa> ByteCoin: so, what you suggest is overloading OP_CHECKSIG ?
1001 2011-10-02 19:28:31 <ByteCoin> Gavin: I suggest that when an OP_EVAL executes, you match the resulting output against IsStandard. That would prevent mischief
1002 2011-10-02 19:28:50 skeledrew has quit (Ping timeout: 252 seconds)
1003 2011-10-02 19:29:02 <ByteCoin> sipa: replying to you ... in a  mo
1004 2011-10-02 19:29:32 <sipa> i wonder what TD[gone] thinks about the idea
1005 2011-10-02 19:29:42 <gavinandresen> and genjix
1006 2011-10-02 19:29:49 <casascius> thomasv: I don't think i have a deterministic wallet patch (the only deterministic wallet generator I have made is not patchable into the client, it's not in C++)
1007 2011-10-02 19:30:08 <ThomasV> yes I know
1008 2011-10-02 19:30:19 <ByteCoin> sipa: I'm suggesting, like casascius said to change the name of OP_CHECKSIG to OP_EVAL. Notice how the scriptPubKeys for the OP_EVAL transaction is SO close to the normal scriptPubKey.
1009 2011-10-02 19:30:51 <ByteCoin> Then we;d have to have an opcode which actually DOES check a sig against a public key.
1010 2011-10-02 19:31:09 <ByteCoin> It'd be a bit hacky in ONE situation to ensure back compatibility
1011 2011-10-02 19:31:27 Rabbit67890 has quit (Quit: Rabbit67890)
1012 2011-10-02 19:31:49 <gavinandresen> I don't see how it avoids a chain split, though.
1013 2011-10-02 19:32:00 <ByteCoin> I don't see a split.
1014 2011-10-02 19:32:09 <sipa> so it would be "if the two stack top elements look like a signature and a pubkey, assume we mean ECDSA verification, otherwise assume we mean eval()"
1015 2011-10-02 19:32:10 <ByteCoin> Perhaps I've had too much sun today....
1016 2011-10-02 19:32:12 <sipa> ?
1017 2011-10-02 19:32:14 Turingi has joined
1018 2011-10-02 19:32:20 <gavinandresen> If the signature is <sig> <complicated script>   ... then DUP HASH160 EQUALVERIFY CHECKSIG   will not validate on old clients
1019 2011-10-02 19:32:33 <casascius> Which opcode is 0x04?
1020 2011-10-02 19:32:38 <casascius> all pubkey scripts start with 0x04
1021 2011-10-02 19:32:40 <sipa> casascius: 4
1022 2011-10-02 19:32:42 <gavinandresen> ... because <complicated script> is not a valid pubkey
1023 2011-10-02 19:33:01 <ByteCoin> gavin: Oh I see. I thought the idea was to roll out support for the new transaction before using it
1024 2011-10-02 19:33:24 <ByteCoin> When people start USING it then of course the old clients would be out of the loop
1025 2011-10-02 19:33:29 <sipa> i think ByteCoin missed the possibility of non-backward-compatibility-breaking OP_NOP1
1026 2011-10-02 19:33:34 <gavinandresen> Yes, but if old clients can be blissfully unaware and validate the transactions then there's no forced upgrade
1027 2011-10-02 19:33:49 <ByteCoin> sipa: I think I get the OP_NOP1 problem ,
1028 2011-10-02 19:34:04 <ByteCoin> That;s why I'm proposing to use the OP_CHECKSIG code
1029 2011-10-02 19:34:29 <sipa> ByteCoin: in short: gavinandresen realized that a "OP_DUP OP_HASH160 <scriptHash> OP_EQUALVERIFY OP_EVAL" script will evaluate to true for old client
1030 2011-10-02 19:34:32 <sipa> s
1031 2011-10-02 19:34:34 <gavinandresen> <sig> <complicated_script>  NOP1    validates, because the script code just cares that a non-false value is on the top of the stack
1032 2011-10-02 19:34:46 <ByteCoin> gavin: If you go for a new OP_EVAL then old clients still have to upgrade so it's the same
1033 2011-10-02 19:34:50 <ByteCoin> ?
1034 2011-10-02 19:35:03 <gavinandresen> No, if   OP_EVAL is the same opcode as the existing OP_NOP1
1035 2011-10-02 19:35:13 <gavinandresen> (Satoshi put in 10 NOP codes for expansion)
1036 2011-10-02 19:35:23 <ByteCoin> sipa: That's only true if you use a different code number for OP_EVAL
1037 2011-10-02 19:35:26 <casascius> I am not sure I am clear on how there would be no forced upgrade.  I see the NOP1 would validate, but the block containing the transaction that spent that txout would appear invalid wouldn't it?  Am I misunderstanding the way it works?
1038 2011-10-02 19:35:40 <sipa> casascius: no it wouldn't
1039 2011-10-02 19:35:53 <gavinandresen> The spending transaction and the block would be considered valid.
1040 2011-10-02 19:35:56 <sipa> casascius: txout scripts are only evaluated when they are spent
1041 2011-10-02 19:36:02 <sipa> together with their input script
1042 2011-10-02 19:36:17 <ByteCoin> sipa: Yes it would..
1043 2011-10-02 19:36:26 ymirhotfoot has joined
1044 2011-10-02 19:36:28 <ByteCoin> Wouldn't it?
1045 2011-10-02 19:36:31 <casascius> the evaluation would not succeed though... the hash160 would be that of a script
1046 2011-10-02 19:36:42 <sipa> casascius: yes?
1047 2011-10-02 19:36:43 <ByteCoin> IsStandard checks the scriptPubKey?
1048 2011-10-02 19:36:53 <ByteCoin> Don't make me read the code...
1049 2011-10-02 19:36:56 <sipa> ByteCoin: yes
1050 2011-10-02 19:37:11 <gavinandresen> IsStandard is true for any ScriptSig that just pushes data onto the stack
1051 2011-10-02 19:37:30 <ByteCoin> So if OP_EVAL is implemented usig OP_NOP1 then it'll fail istandard for those clients?
1052 2011-10-02 19:37:52 <sipa> changing IsStandard() will not cause a block chain split
1053 2011-10-02 19:38:01 <gavinandresen> Yes, it won't be IsStandard, so won't be relayed by old clients.
1054 2011-10-02 19:38:03 <sipa> we're talking about changing the block validity rules
1055 2011-10-02 19:38:10 <sipa> not the relaying or mining rules
1056 2011-10-02 19:38:30 <ByteCoin> gavin: If it get's into a block, won't it be rejected as not IsStandard?
1057 2011-10-02 19:38:44 <sipa> ByteCoin: IsStandard() is only a check for relaying
1058 2011-10-02 19:38:48 <ByteCoin> Ok
1059 2011-10-02 19:38:52 <ByteCoin> thanks sipa
1060 2011-10-02 19:38:54 <gavinandresen> yup
1061 2011-10-02 19:39:04 <sipa> a non-standard script that evaluates to true, is valid, if it is in a block
1062 2011-10-02 19:39:13 <ByteCoin> OK So that's another reason for not using OP_NOP1
1063 2011-10-02 19:39:18 <sipa> how so?
1064 2011-10-02 19:39:36 <ByteCoin> because old clients will evaluate any scriptSig as true?
1065 2011-10-02 19:39:37 <casascius> even if an upgrade isn't forced, one would be forced in practice, because anyone emitting an OP_NOP1 transaction would be sending funds that are invisible to the current clients (right?)...
1066 2011-10-02 19:40:04 <casascius> One would be forced to upgrade just to receive funds
1067 2011-10-02 19:40:16 <ByteCoin> With the new scriptPubKey using OP_EVAL where the old one had OP_CHECKSIG
1068 2011-10-02 19:40:16 <sipa> casascius: that's nothing forced
1069 2011-10-02 19:40:32 <sipa> your client can't generate a new style address, you won't ever receive a new-style transaction
1070 2011-10-02 19:40:42 <gavinandresen> casascius: the bitcoin address format would have to be upgraded so new clients knew which transaction template to use to send funds....
1071 2011-10-02 19:41:03 <gavinandresen> So old clients wouldn't be able to send to new clients using new addresses
1072 2011-10-02 19:41:23 <sipa> ByteCoin, casascius: the thing we're trying to prevent is just the fact that any old client will remain on an old chain, and fork
1073 2011-10-02 19:41:23 <gavinandresen> (new address format...)
1074 2011-10-02 19:41:27 <casascius> I suppose that would work.... I would hate to see in people's siglines, "oldcoin address: 1xxxxxx, newcoin address: 2xxxxxxx"
1075 2011-10-02 19:41:38 t3a has joined
1076 2011-10-02 19:41:43 <casascius> but that would probably be not an issue....i believe everyone would upgrade
1077 2011-10-02 19:41:50 <gavinandresen> casascius: agreed
1078 2011-10-02 19:42:00 <sipa> casascius: sure upgrading will be need to use the feature
1079 2011-10-02 19:42:15 <sipa> but you don't want some 10% of clients someone continuing on an old chain, forked
1080 2011-10-02 19:42:26 <sipa> *somewhere
1081 2011-10-02 19:42:35 <ByteCoin> sipa: remind me how in the renaming OP_CHECKSIG to OP_EVAL will be bad with old clients
1082 2011-10-02 19:42:48 ThomasV has quit (Ping timeout: 252 seconds)
1083 2011-10-02 19:43:01 <ByteCoin> They'll just not relay new transactions
1084 2011-10-02 19:43:09 <ByteCoin> Until they update
1085 2011-10-02 19:43:13 <sipa> ByteCoin: because as soon as a new client spends an OP_EVAL script, and is included in a block, that block isn't valid for old clients
1086 2011-10-02 19:43:17 <ByteCoin> Is that such a problem
1087 2011-10-02 19:43:31 <ByteCoin> sipa: wait
1088 2011-10-02 19:43:31 <sipa> it's not really a problem, but it requires planning in advance
1089 2011-10-02 19:43:42 <ByteCoin> Comment out of sequence
1090 2011-10-02 19:44:08 <ByteCoin> sipa: Ok so the old clients start rejecting blcoks
1091 2011-10-02 19:44:25 <ByteCoin> Then they're vulnerable to unscrupulous miners
1092 2011-10-02 19:44:27 <sipa> that is bad, unless you planned it so long in advance that you can be sure there aren't any left
1093 2011-10-02 19:44:32 <casascius> i suppose it can be boiled down to the merits of: should we make 100% of people learn about 2 kinds of bitcoin addresses (and require work on all websites like MtGox to support them)... or accommodate the x% of people who will be running old clients and somehow plan to transact without upgrading.
1094 2011-10-02 19:44:49 <ByteCoin> casascius: Bingp
1095 2011-10-02 19:44:52 <ByteCoin> bingo
1096 2011-10-02 19:44:55 <sipa> ByteCoin: no they just get there own chain
1097 2011-10-02 19:44:59 <sipa> *their
1098 2011-10-02 19:45:07 <ByteCoin> sipa: Nobody mining it
1099 2011-10-02 19:45:17 <ByteCoin> No chain
1100 2011-10-02 19:45:29 <sipa> but i assume there are still old miners left
1101 2011-10-02 19:45:32 <ByteCoin> Difficulty too high
1102 2011-10-02 19:45:38 <casascius> those miners will never ger a block =)
1103 2011-10-02 19:45:43 <sipa> depends
1104 2011-10-02 19:45:47 <sipa> if it's 40%, they do
1105 2011-10-02 19:46:21 groffer has quit (Ping timeout: 248 seconds)
1106 2011-10-02 19:46:21 devrandom has quit (Ping timeout: 248 seconds)
1107 2011-10-02 19:46:49 <ByteCoin> well, I can see both sides. I don't mind so much which one wins as long as the decision is taken without misconceptions
1108 2011-10-02 19:46:58 <gavinandresen> it is a problem for non-miners who reject the main block chain...
1109 2011-10-02 19:47:21 <ByteCoin> gavin: Their transactions never confirm....
1110 2011-10-02 19:47:24 <gavinandresen> yup
1111 2011-10-02 19:47:34 <casascius> This change, as proposed, won't even take effect any time soon.  If it is implemented but not enabled until some later point in the future, all teh current clients will have been upgraded and discarded if for no other reason than slowness downloading the chain
1112 2011-10-02 19:47:37 <sipa> yes they stop seeing the block chain evolution at best
1113 2011-10-02 19:47:44 <ByteCoin> "Oh there's something wrong! Better check the website"
1114 2011-10-02 19:47:58 <sipa> and they see an old forked chain at worse
1115 2011-10-02 19:48:08 <sipa> worst
1116 2011-10-02 19:48:48 <sipa> the thing is that an OP_EVAL == OP_NOP1 can be safely rolled out as soon as 50% of the miners upgraded
1117 2011-10-02 19:48:51 <casascius> example: if implemented to turn itself on at block 200000 on main chain and immediately on testnet
1118 2011-10-02 19:48:55 <sipa> instead of the entire network
1119 2011-10-02 19:49:28 <ByteCoin> sipa: I thought OP_EVAL==OP_NOP1 was a problem as any scriptsig would eval as true
1120 2011-10-02 19:49:32 <casascius> if it were implemented to turn on at 200000, people implementing their own alternate chains would likely turn it on immediately for their new chains, giving it plenty of testing before it turns on for any of us
1121 2011-10-02 19:49:32 <sipa> ByteCoin: btw, did you see my remark on the message signing thread on the foru,s
1122 2011-10-02 19:49:32 <ByteCoin> for old clients
1123 2011-10-02 19:49:50 <sipa> ByteCoin: yes, but if 50% of miners upgraded, no such transaction can get into the chain
1124 2011-10-02 19:49:51 <ByteCoin> sipa: Just back from weekend. Will read.
1125 2011-10-02 19:50:24 <casascius> yeah, having any scriptsig evaluate as true might be a problem too.  Someone could fake unconfirmed payments to a client by "spending" anybody's NOP1 transaction and sending it to a client running an old version
1126 2011-10-02 19:50:32 <ByteCoin> sipa: Won't there be much wailing and gnashing of teeth in the clients nevertheless
1127 2011-10-02 19:50:39 <casascius> the payment would never confirm of course (I believe)
1128 2011-10-02 19:50:50 <sipa> casascius: agree, that may be an issue
1129 2011-10-02 19:50:59 <sipa> 0-confirmation transactons
1130 2011-10-02 19:51:37 <sipa> ByteCoin: https://bitcointalk.org/index.php?topic=6428.msg550175#msg550175
1131 2011-10-02 19:51:46 <ByteCoin> It just seems a waste to burn an address upgrade on something that seems not to need one.
1132 2011-10-02 19:52:15 <casascius> bytecoin: agreed
1133 2011-10-02 19:52:34 <sipa> i *really* don't like reusing OP_CHECKSIG
1134 2011-10-02 19:53:17 <ByteCoin> sipa: Well I'm willing to be persuaded against using it.
1135 2011-10-02 19:53:21 <ByteCoin> reusing
1136 2011-10-02 19:53:58 <ByteCoin> I agree that the behaviour of old clients needs thought
1137 2011-10-02 19:54:23 <ByteCoin> sipa: I need to think about the HMAC stuff. Is it urgernt?
1138 2011-10-02 19:54:30 <sipa> and I'm willing to accept that a full network upgrade it better than trying a non-backward-compatibility-breaking change
1139 2011-10-02 19:54:55 <ByteCoin> well that's what we're thrashing out...
1140 2011-10-02 19:54:58 <sipa> but even then, i wouldn't change the semantics of an existing opcode - some clients may just not have upgraded anyway
1141 2011-10-02 19:55:02 <casascius> If the next release included it but it was switched off for a year's worth of blocks... how many people do we figure will be using current versions of clients a year from now?  especially if there are major advancements in performance or features?
1142 2011-10-02 19:55:16 <sipa> 0.3.19 is still being used...
1143 2011-10-02 19:55:37 <ByteCoin> casascius: I'd be hoping  it would be faster.
1144 2011-10-02 19:55:49 <ByteCoin> sipa: What's so bad about breaking OLD clients
1145 2011-10-02 19:55:52 <ByteCoin> >
1146 2011-10-02 19:55:54 <ByteCoin> ?
1147 2011-10-02 19:55:57 <casascius> how old is 0.3.19?  and how many?  A year from now, the block chain might be 5 terabytes, and bootstrapping a 0.4 system might take a week.
1148 2011-10-02 19:55:59 <ByteCoin> It's a beta!
1149 2011-10-02 19:56:06 <sipa> the fact that they become isolated
1150 2011-10-02 19:56:23 <ByteCoin> What's the worst that could happen?
1151 2011-10-02 19:57:02 <sipa> some miners remaining on old code (perhaps using one of the different alternate implementations, after such a project stalled)
1152 2011-10-02 19:57:37 <sipa> and making a (small) part of the world think they are alone
1153 2011-10-02 19:57:46 <casascius> at worst, those miners would either mine nothing, or mine illusory blocks they can't spend...somebody somewhere who mines themselves into low-difficulty territory might have to be told, "no your 10000 bitcoins you think you mined aren't real...you wasted your electricity"....
1154 2011-10-02 19:57:51 <ByteCoin> In a very real way, they are alone!
1155 2011-10-02 19:57:55 <sipa> allowing transactions to be spent there, that are spent separately in the real chain as well
1156 2011-10-02 19:58:11 <sipa> that's a worst case, imho
1157 2011-10-02 19:58:31 <ByteCoin> sipa: Think of it as a pseudo-self-inflicted network segmentation
1158 2011-10-02 19:58:40 <sipa> yes, that's called a block chain split
1159 2011-10-02 19:58:55 <ByteCoin> Ok. agreed
1160 2011-10-02 19:59:01 <sipa> put this way: a full upgrade of the network may be needed
1161 2011-10-02 19:59:07 amtal_ has quit (Ping timeout: 258 seconds)
1162 2011-10-02 19:59:09 <ByteCoin> Except one chain is VERY shoty
1163 2011-10-02 19:59:13 <ByteCoin> short
1164 2011-10-02 19:59:21 <sipa> so i'm not arguing now for or against using OP_NOP1
1165 2011-10-02 19:59:32 <casascius> Wouldn't someone figure it out quickly?  (Psst - bitcoinmunchies.com is using 0.3.24!  fire up the old client and double-spend for some free munchies, but hurry before they figure it out)
1166 2011-10-02 20:00:09 <ByteCoin> A full upgrade of the network is needed for what? Sorry, I'm having trouble thinking of the answer for you...
1167 2011-10-02 20:00:27 <gavinandresen> OP_NOP1 through 10 were put there for expansion....
1168 2011-10-02 20:00:53 devrandom has joined
1169 2011-10-02 20:00:54 groffer has joined
1170 2011-10-02 20:00:58 <JFK911> i can double spend?
1171 2011-10-02 20:01:06 <ByteCoin> No.
1172 2011-10-02 20:01:09 Rabbit67890 has joined
1173 2011-10-02 20:01:15 <sipa> ByteCoin: full upgrade: add a chance now that will take affect after block 200000, and hope that the whole world has upgraded to versions at least as young as this one by then
1174 2011-10-02 20:01:16 <gavinandresen> groffer:  you see the OP_EVAL discussion on the forums?
1175 2011-10-02 20:01:17 <JFK911> how is this better than my last double spending trick?
1176 2011-10-02 20:01:18 <casascius> also wouldn't it be possible to broadcast a message onto any "short" chain letting people know "ok, you really need to upgrade".... that functionality exists doesn't it?
1177 2011-10-02 20:02:01 <ByteCoin> sipa: thinking...
1178 2011-10-02 20:02:22 <sipa> ByteCoin: that's basically deliberately causing a block chain split, and making sure that it splits 100% (no old client will consider anything from after that point valid)
1179 2011-10-02 20:02:25 <casascius> if at block 200000 it takes any ridiculous amount of time (days+) to initialize the block chain, you can bet people won't be running it
1180 2011-10-02 20:02:36 skeledrew has joined
1181 2011-10-02 20:02:41 <sipa> ByteCoin: and if you do that, i prefer not to reuse an old opcode
1182 2011-10-02 20:03:15 <sipa> ByteCoin: because there may be some clients left, and there may be very hard to find bugs if the semantics change so much
1183 2011-10-02 20:03:23 <sipa> things that may look ok to those clients
1184 2011-10-02 20:03:28 <ByteCoin> sipa: So tell me if I've got this right. Your concern is for clients running old versions correct?
1185 2011-10-02 20:03:29 <ymirhotfoot> The present scxript engine has how many possible bytecodes/commands in total?
1186 2011-10-02 20:03:36 <ymirhotfoot> How many are used today?
1187 2011-10-02 20:03:50 <sipa> ByteCoin: yes, or alternate implementations
1188 2011-10-02 20:04:45 <ymirhotfoot> Is there in the present system a field that specifies which, of several possible, engines, is to be used for interpretation of the script?
1189 2011-10-02 20:04:53 <ByteCoin> sipa: So how does scheduling the change after block 200000 help versus rolling out a version that understands the number of OP_CHECKSIG as the new slightly hacked OP_EVAL?
1190 2011-10-02 20:05:25 <sipa> versus? i thought we were considering doing both?
1191 2011-10-02 20:05:48 <sipa> i.e., implement the change now, but only make it take effect after block 200000
1192 2011-10-02 20:05:48 <ByteCoin> umm....
1193 2011-10-02 20:06:42 <ByteCoin> Ok fine. What's the improvement doing it after 200000? If there are some people running ridiculously old versions now then will they really ever upgrade? What's their incentive?
1194 2011-10-02 20:07:08 <sipa> there are imho 3 possible scenarios
1195 2011-10-02 20:07:21 <sipa> 1) use NOP1==EVAL, and release a client that can create new-style transactions as soon as >>50% of miners have upgraded
1196 2011-10-02 20:07:35 <ByteCoin> As far as I can tell, scheduling it for 200000 means that if the situation is no better then we've just wasted loads of time
1197 2011-10-02 20:07:51 <sipa> 2) use new opcode for EVAL, implement it now, but make it take effect after block 200000
1198 2011-10-02 20:08:06 <sipa> 3) use OP_CHECKSIG for EVAL, implement it now, but make it take effect after block 200000
1199 2011-10-02 20:08:17 <sipa> are you talking about another scenario than 3) ?
1200 2011-10-02 20:08:36 <ByteCoin> sipa: Possibly. thinking...
1201 2011-10-02 20:09:08 <sipa> ByteCoin: btw, regarding HMAC, it's a bit late already as the code is already pulled into git head (but i suppose we can still change it)
1202 2011-10-02 20:09:24 <ByteCoin> 4) OP_CHECKSIG becomes OP_EVAL rollout now ..... what happens? thinking...
1203 2011-10-02 20:09:49 <sipa> -> the first time a new style txout is spent, the network splits
1204 2011-10-02 20:09:53 da2ce7 has joined
1205 2011-10-02 20:10:18 <ByteCoin> sipa: Old clients fall off the network essentially...
1206 2011-10-02 20:10:23 <sipa> not fall off
1207 2011-10-02 20:10:28 <sipa> they create their own network
1208 2011-10-02 20:10:47 <gavinandresen> Getting >50% of hashing power to upgrade will be MUCH easier than getting >50% of clients to upgrade
1209 2011-10-02 20:10:47 <ByteCoin> No mining? We'd have to get the miners on board...
1210 2011-10-02 20:11:06 <sipa> ByteCoin: that is why you say "at 200000", to make sure all miners have upgraded
1211 2011-10-02 20:11:14 <ymirhotfoot> gavinandresen: Thank you for answering part of my question before I asked, with this answer: OP_NOP1 through 10 were put there for expansion....
1212 2011-10-02 20:11:23 <ByteCoin> Miners have a strong incentive to upgrade
1213 2011-10-02 20:11:39 <sipa> the difference is that scenario 1) only requires 50% of miners to upgrade, instead of 100%
1214 2011-10-02 20:11:40 <ByteCoin> \They can be relied on to upgrade quickly once >50%
1215 2011-10-02 20:12:10 <sipa> ByteCoin: so, what's your take on the HMAC issue?
1216 2011-10-02 20:12:13 <ByteCoin> so does 4 no?
1217 2011-10-02 20:12:27 <sipa> 4) will cause an block chain split the second a new tx is spent...
1218 2011-10-02 20:12:29 <ByteCoin> sipa: Do i HAVE to look at it now?
1219 2011-10-02 20:12:49 <ByteCoin> Not in an HMAC mood
1220 2011-10-02 20:13:09 <ByteCoin> not familiar with length extension attacks yet
1221 2011-10-02 20:13:43 <sipa> ok
1222 2011-10-02 20:14:03 <ByteCoin> There's a difference between what's exploitable and what you need to do to stop cryptographers laughing at your noobism.
1223 2011-10-02 20:14:32 <sipa> ByteCoin: in scenario 4, if 10% of miners haven't upgraded at the time the first new style txout is spent, you get a forked network with 10% of the mining power
1224 2011-10-02 20:14:41 <ByteCoin> We should prevent the latter as well but the former suffices
1225 2011-10-02 20:14:54 AnniGONE is now known as AnnihilaT
1226 2011-10-02 20:14:59 <ByteCoin> sipa: Correct. Is that so bad?
1227 2011-10-02 20:15:05 <sipa> that's horrible
1228 2011-10-02 20:15:32 <sipa> you can spend every coin in both networks, if you want to
1229 2011-10-02 20:15:44 <ByteCoin> Perhaps the "detect massive fall of hashing power" is a prerequsiste to ANY changes of this type
1230 2011-10-02 20:16:17 <luke-jr> how about using coinbase for miner upgrades
1231 2011-10-02 20:16:31 <luke-jr> when 50% of the last N coinbases contain "I support FOOFEATURE", it's enabled
1232 2011-10-02 20:16:37 <ByteCoin> sipa: Is 10% realistic? Aren't admins in contact with pretty much ALL the miners. Yay pooled mining on GPU!
1233 2011-10-02 20:17:14 <ByteCoin> luke-jr: Good idea if coinbases were more visible.. this would have had to have been thought of from the start
1234 2011-10-02 20:17:49 <luke-jr> ByteCoin: none of the FOOFEATURE-supporting clients would *actually* accept FOOFEATURE until they saw the 50%
1235 2011-10-02 20:18:17 <ByteCoin> luke-jr: I see! Cunning!
1236 2011-10-02 20:18:27 <sipa> ByteCoin: see http://bitcoinwatch.com/
1237 2011-10-02 20:18:47 <luke-jr> but yes, if the core functions ("block validate", "transaction validate") could be abstracted in a VM and upgraded by block-majority, it would be better
1238 2011-10-02 20:18:58 skeledrew has quit (Ping timeout: 244 seconds)
1239 2011-10-02 20:19:03 <forrestv> they should really wait for 80% or so ... forking right at 50% doesn't sound great
1240 2011-10-02 20:19:08 <luke-jr> then "allow over 1 MB" could have been a mere change to "block validate" function
1241 2011-10-02 20:19:09 <sipa> something like 1/6 is not in any of the major pools
1242 2011-10-02 20:19:16 <sipa> forrestv: agree
1243 2011-10-02 20:19:24 <luke-jr> forrestv: 50% is sufficient to invalidate the other 50% of miners
1244 2011-10-02 20:19:24 <sipa> but the idea sounds doable
1245 2011-10-02 20:19:29 <luke-jr> so anything higher is unreasonable
1246 2011-10-02 20:19:47 <luke-jr> ie, FOOFEATURE-supporting miners can simply ignore non-FOOFEATURE miners to get their 50% into 100%
1247 2011-10-02 20:19:47 <ByteCoin> sipa:Ok now we're on the same page.
1248 2011-10-02 20:19:49 <forrestv> luke-jr, and the network hashrate will instantly halve...
1249 2011-10-02 20:19:49 <casascius> i would vote for going to 80%+
1250 2011-10-02 20:20:23 <casascius> i think if foofeature turned on at 80% it would be fairly certain that it would succeed... at 50% it's likely to turn to chaos
1251 2011-10-02 20:20:25 <luke-jr> if you can think of a reasonable way to require 75%, that seems ideal
1252 2011-10-02 20:20:46 <luke-jr> but like I said, 50% allows them to invalidate their competition, so
1253 2011-10-02 20:20:48 <sipa> i think halving the network hashrate is a bad thing - sure the remaining miners will be very much encouraged to upgrade too, but it seems nicer to just wait until more have upgraded
1254 2011-10-02 20:21:00 <ByteCoin> The admins could see what proportion of the total hashrate they can get in contact with....
1255 2011-10-02 20:21:09 <ByteCoin> Then get back with some numbers...
1256 2011-10-02 20:21:20 <luke-jr> sipa: well, it's not like the other miners won't see that % going up
1257 2011-10-02 20:21:20 <ByteCoin> Othwise we're just guessing
1258 2011-10-02 20:21:33 <gavinandresen> I like putting "I support..." info in coinbase, good idea luke-jr
1259 2011-10-02 20:21:42 <casascius> perhaps even 90-95% is realistic... I think in the event of a major change, all pools and many solo miners will adopt instantly...resulting in an 80% penetration...the 90-95% would be for the benefit of the slow bumpkins we're accommodating
1260 2011-10-02 20:21:43 <luke-jr> perhaps N could be a difficulty period
1261 2011-10-02 20:21:48 <AnnihilaT> 50% i think could be dangerous
1262 2011-10-02 20:21:55 <AnnihilaT> i also think it should be higher
1263 2011-10-02 20:21:56 <luke-jr> so miners have at least a week or two to notice "this change is about to be implemented"
1264 2011-10-02 20:22:07 <ByteCoin> Nobody is seriously sugesting 50%!
1265 2011-10-02 20:22:09 <luke-jr> over 50% is impractical.
1266 2011-10-02 20:22:12 <AnnihilaT> 80% is probabally too high
1267 2011-10-02 20:22:23 <ByteCoin> luke-jr: What?
1268 2011-10-02 20:22:24 <sipa> ByteCoin: but what is the problem with using OP_NOP1, just the fact that addresses change? you need an new client to create a new style address anyway, whether it looks compatible with the old ones or not
1269 2011-10-02 20:22:38 <luke-jr> ByteCoin: there is no practical way to distinguish between 50% and 100%
1270 2011-10-02 20:23:02 <ByteCoin> luke-jr: You are surely wrong. Will talk to you later.
1271 2011-10-02 20:23:05 <forrestv> luke-jr, of course there is ... just look at the fraction of the last n blocks that have the flag in their coinbase
1272 2011-10-02 20:23:11 <luke-jr> ByteCoin: miners with 50% can easily collude to put the other 50% out of mining
1273 2011-10-02 20:23:22 <luke-jr> forrestv: so my 50% will invalidate all your blocks
1274 2011-10-02 20:23:24 <sipa> luke-jr is right
1275 2011-10-02 20:23:32 <ByteCoin> sipa: Thinking...
1276 2011-10-02 20:23:38 <ByteCoin> what?
1277 2011-10-02 20:23:47 <forrestv> not if the clients don't actually activate the feature until that threshold is reached..
1278 2011-10-02 20:23:52 copumpkin has quit (Ping timeout: 252 seconds)
1279 2011-10-02 20:23:52 <ByteCoin> no PRACTICAL way?
1280 2011-10-02 20:23:54 <luke-jr> forrestv: yes, even then
1281 2011-10-02 20:23:57 <forrestv> why?
1282 2011-10-02 20:23:59 <sipa> but that also means that if miners do this collusion, the new ones having 50% will look like 100% to the rest of the network
1283 2011-10-02 20:24:16 <luke-jr> forrestv: someone with 50% of hashpower can make the other 50% invalid period
1284 2011-10-02 20:24:18 copumpkin has joined
1285 2011-10-02 20:24:20 <ByteCoin> sipa: Orphan block will tell the story
1286 2011-10-02 20:24:35 <ByteCoin> luke-jr: Easy to detect
1287 2011-10-02 20:24:47 <ByteCoin> And shun if necessary
1288 2011-10-02 20:24:55 <sipa> yes, you'll see somewhat more orphan blocks, but note that those won't be relayed by new nodes either, once the upgrade is enabled
1289 2011-10-02 20:25:03 <ByteCoin> Seem my old posts on cartel formation
1290 2011-10-02 20:25:18 <ByteCoin> sipa: Why not relayed?
1291 2011-10-02 20:25:27 <ByteCoin> They contain good transactions
1292 2011-10-02 20:25:33 <sipa> good point
1293 2011-10-02 20:25:37 <luke-jr> ByteCoin: the assumption is that new nodes are all colluding
1294 2011-10-02 20:25:49 <AnnihilaT> im coming into this conversation a bit late
1295 2011-10-02 20:25:54 <luke-jr> which is somewhat likely unless there's no reason to
1296 2011-10-02 20:25:58 <AnnihilaT> can someone point me to some info where i can read up
1297 2011-10-02 20:26:06 <AnnihilaT> on the problem you guys are attempting to solve
1298 2011-10-02 20:26:27 <sipa> ByteCoin: regarding HMAC, i suppose it is not really an issue, as ECDSA is typically done on "just a hash" of the message, right?
1299 2011-10-02 20:26:41 datagutt has quit (Quit: Computer has gone to sleep.)
1300 2011-10-02 20:26:45 <ByteCoin> Anniha...: better use http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/10/02/3
1301 2011-10-02 20:26:52 <CIA-101> libbitcoin: genjix * rbcf239d17150 / (bitcoin.sql include/bitcoin/script.hpp src/script.cpp): Added OP_NOP which is in block 127630, 4th tx 0adfc9 1st output.
1302 2011-10-02 20:26:54 <CIA-101> libbitcoin: genjix * rb440b4ac2433 /src/storage/ (3 files): Non-blocking recovery organise/validate blocks upon program startup.
1303 2011-10-02 20:27:33 <ByteCoin> sipa: As I said. I know nothing worthwhile about length extension attacks at the moment. Would be irresponsibkle to comment
1304 2011-10-02 20:27:50 <sipa> ok, let's suppose we're safe :)
1305 2011-10-02 20:28:22 <ByteCoin> When does the feature go into the new client? When do we loose opportunity to fix it if it's not ideal?
1306 2011-10-02 20:28:22 <gavinandresen> AnnihilaT: the big-picture feature is new types of transactions, for escrow, secure wallets, corporate "N officers must sign" , etc
1307 2011-10-02 20:29:03 <sipa> ByteCoin: it's merged, so it will go in 0.5.0 most likel
1308 2011-10-02 20:29:04 <sipa> y
1309 2011-10-02 20:29:27 <ByteCoin> Ok... When does 0.5.0 go final?
1310 2011-10-02 20:29:35 <sipa> in a few weeks, probably
1311 2011-10-02 20:29:41 <jgarzik> yep
1312 2011-10-02 20:29:54 <ByteCoin> we still use openssl for crypto yes?
1313 2011-10-02 20:30:09 <jgarzik> yes
1314 2011-10-02 20:30:12 <sipa> yes, except key recovery is implemented manually
1315 2011-10-02 20:30:34 <jgarzik> OpenSSL's ECDSA and AES-256-CBC
1316 2011-10-02 20:30:58 <ByteCoin> sipa: Of course ;)
1317 2011-10-02 20:31:11 <ByteCoin> openssl has HMAC?
1318 2011-10-02 20:31:18 <sipa> yes
1319 2011-10-02 20:31:37 <ByteCoin> So the change would be relatively painless and likely to be bug free?
1320 2011-10-02 20:31:47 <sipa> i'm checking the SEC document, whether they give a suggestion for the hash function
1321 2011-10-02 20:31:48 <ByteCoin> One function for anotyher
1322 2011-10-02 20:33:45 <sipa> from what i read, a length extension is a problem when the hash and the message length, but not the message itself are known
1323 2011-10-02 20:34:02 <sipa> in our case, the message is never secret for those who have access to the hash or the signature
1324 2011-10-02 20:34:39 <luke-jr> sipa: what's merged? "length extension attacks"⁇
1325 2011-10-02 20:34:48 sacarlson has quit (Ping timeout: 258 seconds)
1326 2011-10-02 20:34:55 <sipa> luke-jr: message signing, and i worried about something
1327 2011-10-02 20:35:09 <sipa> but it seems unrelated
1328 2011-10-02 20:35:12 <gmaxwell> sipa: you sign message. I form message+Extension which the same signature is valid for.
1329 2011-10-02 20:35:13 amtal has joined
1330 2011-10-02 20:35:33 <sipa> yes, that was my worry
1331 2011-10-02 20:35:35 <gmaxwell> sipa: E.g. "I agree to pay greg $1"  and I extend it to "I agree to pay greg $185329874278234"
1332 2011-10-02 20:36:54 <gmaxwell> I still don't like the idea that someone who asks you to sign something has complete control and foreknoweldge of the data you'll be signing.  But I'm unable to articluate a pratical attack from it and bytecoin really disliked my solution (including a sender selected nonce)
1333 2011-10-02 20:37:27 mmoya has joined
1334 2011-10-02 20:37:28 <ByteCoin> gmaxwell: I think defense against one attack opens up another
1335 2011-10-02 20:37:47 <gmaxwell> I know, I understood your opposition.
1336 2011-10-02 20:37:52 <ByteCoin> I wasn't objecting to your idea if I did'nt think it had a cost
1337 2011-10-02 20:39:11 <gmaxwell> (The reason I prefer it vs the potential cost is that while neither has an obviously feasable attack, I just heuristically prefer the one that makes an attacker face more uncertanty— and I'm fixating on the subset of usecases where my suggestion did that :) )
1338 2011-10-02 20:39:40 AStove has quit ()
1339 2011-10-02 20:40:24 <gmaxwell> In any case, can't all risk of length extension be closed by simply coding the message length in the data to be signed? It would only add a couple of bytes typically.
1340 2011-10-02 20:41:12 <sipa> http://www.derkeiler.com/Newsgroups/sci.crypt/2008-02/msg00665.html
1341 2011-10-02 20:41:21 <sipa> No. Signature schemes typically rely on collision resistance. Length-
1342 2011-10-02 20:41:22 <sipa> extension attacks are irrelevant here.
1343 2011-10-02 20:41:28 <sipa> can someone explain why?
1344 2011-10-02 20:42:38 <sipa> my assumption: being able to find a suffix that causes the hash to remain the same is considered hard
1345 2011-10-02 20:42:38 zhoutong has quit (Read error: Connection reset by peer)
1346 2011-10-02 20:42:56 <sipa> however, adding data to the message, while being able to find the changed hash is easy
1347 2011-10-02 20:43:02 <gmaxwell> well, what he's talking about indeed doesn't sound relevant. If it's something that lets you find a collision, it's not going to cause us problem.
1348 2011-10-02 20:43:25 <gmaxwell> sipa: yes, it's hard or the hash is weak (see md5 where this is trivial now)
1349 2011-10-02 20:43:38 zhoutong has joined
1350 2011-10-02 20:43:50 <sipa> and in the case of a message authentication, were there the message contains secret data (the key), this is a problem
1351 2011-10-02 20:44:07 <sipa> but for signatures it doesn't matter - all the message is known anyway
1352 2011-10-02 20:44:34 <sipa> gmaxwell: seen PM?
1353 2011-10-02 20:44:38 soap is now known as soap_
1354 2011-10-02 20:46:03 zhoutong has quit (Read error: Connection reset by peer)
1355 2011-10-02 20:46:39 EskimoBob is now known as EskimoBob_afk
1356 2011-10-02 20:47:10 zhoutong has joined
1357 2011-10-02 20:48:16 <gmaxwell> The other thing we should consider before really shipping the signature stuff.... Is it possible for me to reliably pay you for a signature?
1358 2011-10-02 20:48:47 MC1984 has quit (Read error: Connection reset by peer)
1359 2011-10-02 20:49:04 MC1984 has joined
1360 2011-10-02 20:49:05 <gmaxwell> E.g. I should be able to say "Sipa, if you sign this message 'gmaxwell is awesome' with key 12345, I will give you 1 BTC"
1361 2011-10-02 20:49:44 <ByteCoin> gmaxwell: Do you want us to facilitate it or prevent it?
1362 2011-10-02 20:49:45 disq has quit (Ping timeout: 258 seconds)
1363 2011-10-02 20:50:15 <gmaxwell> And we should be able to do some negoiation, and then I should be able to form a transaction which is only valid providing a copy of the signature... and we should be able to do this without putting a lot of crap in the blockchain.
1364 2011-10-02 20:50:17 disq has joined
1365 2011-10-02 20:50:17 disq has quit (Changing host)
1366 2011-10-02 20:50:17 disq has joined
1367 2011-10-02 20:50:18 <ByteCoin> presumably facilitate..
1368 2011-10-02 20:50:52 <ByteCoin> gmaxwell: I'm detecting shades of hashcoin's zero knowledge stuff
1369 2011-10-02 20:51:00 <gmaxwell> facilitate it— because right now the alternative is that I form a txn with data stuffed in it that says "by spending this, sipa agrees that gmaxwell is awesome".  And thats kinda lame.
1370 2011-10-02 20:51:05 sacarlson has joined
1371 2011-10-02 20:51:25 <luke-jr> could sign the SHA256 hash of the message
1372 2011-10-02 20:51:28 <ByteCoin> gmaxwell: I'll give it some thought....
1373 2011-10-02 20:51:34 <luke-jr> then it's good as long as SHA256 has no vuln
1374 2011-10-02 20:51:35 <ByteCoin> afk
1375 2011-10-02 20:51:49 <gmaxwell> yea, I'll think on it some too.
1376 2011-10-02 20:52:05 <sipa> i don't think it's possible
1377 2011-10-02 20:52:13 <luke-jr> ?
1378 2011-10-02 20:52:13 iocor has joined
1379 2011-10-02 20:52:21 <sipa> as it requires the script to be able to do a verification of the signature
1380 2011-10-02 20:52:41 <luke-jr> ⁇
1381 2011-10-02 20:52:42 <sipa> and the only ecdsa code scripts allow is verification of transaction signature
1382 2011-10-02 20:53:07 <luke-jr> no, I mean you can avoid letting the attacker specify your signing input
1383 2011-10-02 20:53:11 <luke-jr> by signing the hash instead
1384 2011-10-02 20:53:22 <sipa> the message is already signed
1385 2011-10-02 20:53:25 <sipa> eh hashed
1386 2011-10-02 20:53:26 <luke-jr> then the attacker can only control sig input by cracking SHA256
1387 2011-10-02 20:53:30 <gmaxwell> luke-jr: that doesn't do that.  I mean, the attacker can run the hash algorithim too.
1388 2011-10-02 20:53:31 <luke-jr> oh, then what's the problem?
1389 2011-10-02 20:53:48 <gmaxwell> luke-jr: e.g. if the attacker only needs a few bits of control for his attack he can search.
1390 2011-10-02 20:53:51 <luke-jr> gmaxwell: but he can't control the result of it
1391 2011-10-02 20:54:14 <luke-jr> gmaxwell: well, he could do ti with a txn then easier
1392 2011-10-02 20:54:27 clr_ has joined
1393 2011-10-02 20:54:33 <luke-jr> "oops, I accentially sent you 100 BTC; please send it back"
1394 2011-10-02 20:54:48 <gmaxwell> E.g. Say there turns up some ECDSA vulnerablity that comes into play if you have 256 signatures each for data that begins with an initial 0 byte. I can make 256 such messages and ask you to sign them.
1395 2011-10-02 20:55:12 <gmaxwell> luke-jr: yes, but an attacker has a lot more message control with signatures.
1396 2011-10-02 20:55:33 <luke-jr> fine. hash the message with a salt.
1397 2011-10-02 20:55:44 <gmaxwell> Vs a txn they only control the amount— and not even because they won't know all the inputs available to you or which coin's you'll select.
1398 2011-10-02 20:55:48 <luke-jr> the sigs are different every time anyway
1399 2011-10-02 20:55:53 <ByteCoin> gmaxwel: Ok so you want to pay someone for signing a message M. So one way to do it would be to create a transaction which has a scriptPubKey that requires a scriptSig which is a signature of M
1400 2011-10-02 20:55:56 <luke-jr> a couple extra octets to salt won't hurt
1401 2011-10-02 20:56:06 <gmaxwell> luke-jr: yes, I suggested that, bytecoin pointed out that it opens other ~equally theoretical attacks.
1402 2011-10-02 20:56:13 <luke-jr> …
1403 2011-10-02 20:57:41 <ByteCoin> gmaxwell: Oh not only a signature of M (which someone could copy) but also a signature of the transaction by a key held by the signer
1404 2011-10-02 20:58:11 <gmaxwell> e.g. You sign  "I, luke, owe gmaxwell $10" and I modify the message to "I, luke, owe gmaxwell $90"  then do some search over the salts to make it correct again. If the hash is strong, it's not a real problem... but of course we try to minimize these assumptions.
1405 2011-10-02 20:58:25 <ByteCoin> This allows the signer to safely spend the transaction while releasing the signature of the message hash
1406 2011-10-02 20:58:39 <luke-jr> gmaxwell: sign the salt too?
1407 2011-10-02 20:59:38 <ByteCoin> luke-jr: Getting complicated perhaps?
1408 2011-10-02 21:00:09 <nanotube> what are we doing here? including arbitrary signed messages into transactions?
1409 2011-10-02 21:00:15 <gmaxwell> luke-jr: well you're doing that by including it in the hash implicitly. :) Doesn't help— it's an extra degree of control someone could make use of while trying to produce a rebinding attack.
1410 2011-10-02 21:00:30 <gmaxwell> nanotube: trying not to include the message itself in the transaction.
1411 2011-10-02 21:00:46 <luke-jr> gmaxwell: well, finding a collision is assumed to be impossible for all of bitcoin
1412 2011-10-02 21:00:50 <luke-jr> so it's a safe assumption IMO
1413 2011-10-02 21:01:24 <gmaxwell> luke-jr: It's not a question of safty... it's just a matter of maximal conservatism.
1414 2011-10-02 21:01:43 <nanotube> gmaxwell: hrm, so using some kind of hash of the message? what's the use case for stuffing anything like that into the block chain?
1415 2011-10-02 21:01:47 <gmaxwell> Given two systems which are otherwise equal, we want the one that holds up to more attacks— since there will be attacks.
1416 2011-10-02 21:02:22 <gmaxwell> nanotube: the case for it is to make a transaction conditional on it. E.g. You give me signature I give you coin, with no cheating possible.
1417 2011-10-02 21:03:25 <gmaxwell> I guess its not a big deal, you could just embed the hash in a transaction without any script validation— and there is your signature.
1418 2011-10-02 21:03:26 zhoutong has quit (Read error: Connection reset by peer)
1419 2011-10-02 21:04:03 gavinandresen has quit (Quit: gavinandresen)
1420 2011-10-02 21:04:33 zhoutong has joined
1421 2011-10-02 21:04:49 <nanotube> hm interesting thought heh
1422 2011-10-02 21:05:51 ymirhotfoot has quit (Quit: ERC Version 5.2 (IRC client for Emacs))
1423 2011-10-02 21:07:16 osmosis has joined
1424 2011-10-02 21:08:54 zhoutong has quit (Read error: Connection reset by peer)
1425 2011-10-02 21:09:27 zhoutong has joined
1426 2011-10-02 21:10:24 <gmaxwell> wow. Gavin's point that EVAL can be done without a split blew my mind.
1427 2011-10-02 21:10:28 <gmaxwell> Thats really awesome.
1428 2011-10-02 21:10:34 clr_ has quit (Ping timeout: 255 seconds)
1429 2011-10-02 21:10:50 <gmaxwell> Bring out the champaign.
1430 2011-10-02 21:12:10 <terrytibbs> Campaign?
1431 2011-10-02 21:12:34 <gmaxwell> champaign :)
1432 2011-10-02 21:13:01 <gmaxwell> gah got it wrong twice, champagne.
1433 2011-10-02 21:13:24 <terrytibbs> There you go! I was getting worried you'd be running for president.
1434 2011-10-02 21:13:28 <gmaxwell> Though my excitement is dampened by the fact that it will make blockchain bloating nonstandard txn very easy, and not only does it not increase our ability to cope with them or their harm, it decreases it. :(
1435 2011-10-02 21:14:11 <gmaxwell> E.g. I'd hope that we wouldn't start having txn that require 8 signatures until we had key recovery. :(
1436 2011-10-02 21:14:37 marf_away2 has joined
1437 2011-10-02 21:15:32 <gmaxwell> hm. I guess we could make key-recovery style signature possible but only inside evaled scripts.
1438 2011-10-02 21:15:56 marf_away has quit (Ping timeout: 256 seconds)
1439 2011-10-02 21:17:36 <ByteCoin> gmaxwell: Bloat not possible without concomitant IsStandard relaxation
1440 2011-10-02 21:18:18 clr_ has joined
1441 2011-10-02 21:18:28 <ByteCoin> OP_EVAL is orthogonal to bloat-increasing changes
1442 2011-10-02 21:18:47 Eliel has quit (Read error: Operation timed out)
1443 2011-10-02 21:19:30 <gmaxwell> ByteCoin: It changes the pressure—  right now you can't open a bloat creating txn if denied by IsStandard, with OP_EVAL you can't _close_ one.
1444 2011-10-02 21:20:02 Eliel has joined
1445 2011-10-02 21:20:09 <luke-jr> gmaxwell: sure you can
1446 2011-10-02 21:20:11 <gmaxwell> E.g. you send your self 100 BTC to a must provide 8 signatures transaction. Once you've done that, come hell or high water you're going to get that bloated txn into the blockchain.
1447 2011-10-02 21:20:16 erska_ has quit (Read error: Operation timed out)
1448 2011-10-02 21:20:56 <gmaxwell> E.g. failure to get a bloated txn through right now leaves the coin where it is, failure to get a bloated txn through with OP_EVAL leaves the coin stuck in limbo.
1449 2011-10-02 21:21:26 <luke-jr> nonsense
1450 2011-10-02 21:21:32 <luke-jr> unless you're comparing different failures
1451 2011-10-02 21:21:34 <ByteCoin> luke-jr: Gmaxwell is right. How do you do "sure you can"?
1452 2011-10-02 21:21:46 <luke-jr> ByteCoin: not everyone checks IsStandard bs
1453 2011-10-02 21:21:47 <gmaxwell> luke-jr: The failures _are_ different, thats my point.
1454 2011-10-02 21:22:05 <luke-jr> gmaxwell: OP_EVAL does not imply accepting every transaction using it
1455 2011-10-02 21:22:17 <gmaxwell> OP_EVAL moves the point of pressure to after coin is locked up and can't be spent any other way.
1456 2011-10-02 21:22:38 <ByteCoin> luke-jr: Ah yes... You are a source of some danger potentially....
1457 2011-10-02 21:23:14 <gmaxwell> Hey, luke, can you change your code real quick to not mine any txn with that NOP we're talking about reusing?
1458 2011-10-02 21:23:28 <luke-jr> which one?
1459 2011-10-02 21:23:39 <gmaxwell> Because if you manage to mine a txn with a broken OP_EVAL input then implementation becomes much harder. :)
1460 2011-10-02 21:23:48 <luke-jr> got a patch? :P
1461 2011-10-02 21:23:49 <ByteCoin> gmaxwell: You are right. I believe I mentioned it "could cause some distress"
1462 2011-10-02 21:24:34 <gmaxwell> Not impossible at least, but we'd have to have a check e.g. if block != {x} apply_eval_checking();
1463 2011-10-02 21:24:41 phatsphere has quit (Read error: Connection reset by peer)
1464 2011-10-02 21:24:54 <gmaxwell> luke-jr: Patcha. Ha. Normal nodes already won't mine the darn things. :)
1465 2011-10-02 21:25:09 <ByteCoin> luke-jr: Just out of interest, what would you do if all the other miners refused to build off your blocks?
1466 2011-10-02 21:25:18 <gmaxwell> luke-jr: In general I suggest you block all NOP's that aren't already in the chain?
1467 2011-10-02 21:25:30 <luke-jr> gmaxwell: http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/commitdiff/77b21e59ce81dbd8b5079f4880d066dd29dfc797
1468 2011-10-02 21:25:41 <sipa> http://blockexplorer.com/rawblock/0000000000001d39eac1016f91da0ebf79714e2e425e7b8f9c188635df2fca58
1469 2011-10-02 21:25:47 <sipa> OP_NOP is already used
1470 2011-10-02 21:25:54 <gmaxwell> luke-jr: Because as this OP_EVAL discussion shows, the NOPs are very useful for compatible additions to bitcoin, but only if they aren't actually used before we give them meaning.
1471 2011-10-02 21:26:00 <luke-jr> ByteCoin: sound the abuse alarm?
1472 2011-10-02 21:27:18 <ByteCoin> luke-jr: I don't have an agenda so don't take this as anything other than seeking info. If you sound the abuse alarm, do you expect many people will rally to your cause?
1473 2011-10-02 21:27:32 heinz` has joined
1474 2011-10-02 21:27:46 <luke-jr> ByteCoin: hopefully
1475 2011-10-02 21:28:18 <ByteCoin> gmaxwell: Couldn't we specify that the OP_NOP had no effect before a certain block number
1476 2011-10-02 21:28:41 erska has joined
1477 2011-10-02 21:28:55 <gmaxwell> ByteCoin: We could. It's just an extra test we'd have to carry forever, and we'd still need to keep people from shoving it in after that number but before we gave it meaning.
1478 2011-10-02 21:29:06 <gmaxwell> e.g. we should probably deploy discouragement code that does that ASAP.
1479 2011-10-02 21:29:13 <ByteCoin> The vulnerability in the use of the OP_NOP is during the slow rollout of the new client which changes the interpretation
1480 2011-10-02 21:29:49 pickett has quit (Ping timeout: 248 seconds)
1481 2011-10-02 21:29:52 <luke-jr> gmaxwell: I will side against any bs discouragement system
1482 2011-10-02 21:30:02 <gmaxwell> (I think a lot of people missed the significance of the NOPs as an extension mechenism — we should have been more agressive about keeping them out of the chain.)
1483 2011-10-02 21:30:15 pickett has joined
1484 2011-10-02 21:30:16 <gmaxwell> luke-jr: Please don't fuck up bitcoin.
1485 2011-10-02 21:30:18 <ByteCoin> gmaxwell: It's just one more thing we prevent people shoving in all the time. There's no overhead to that
1486 2011-10-02 21:30:30 <luke-jr> gmaxwell: you're the one screwing it up if you do that.
1487 2011-10-02 21:30:38 Joric has joined
1488 2011-10-02 21:30:44 <gmaxwell> luke-jr: It's really bad if people are mining the NOPs.
1489 2011-10-02 21:30:59 <gmaxwell> Because it means we can't use them as compatible extensions for things like this OP_EVAL.
1490 2011-10-02 21:31:00 <ByteCoin> gmaxwell: I think luke-jr is valuable in being somewhat adversarial at this early stage.
1491 2011-10-02 21:31:05 <luke-jr> gmaxwell: make a patch to reject OP_NOP2+ and I'll apply it
1492 2011-10-02 21:31:21 <luke-jr> gmaxwell: but block discouragement for bs reasons is bs
1493 2011-10-02 21:31:41 <gmaxwell> luke-jr: But we still need some way of discouraging people from being silly going forward. Not _you_, but just anyone who wants to make the same one line change as you.
1494 2011-10-02 21:31:52 <luke-jr> "block discouragement" amounts to collusion to abuse 50% hashpower
1495 2011-10-02 21:32:07 <ByteCoin> gmaxwell: If we're being professional about this, we should be able to cope with the situation where miners say they've blocked it but actually force inclusion themselves..... ie. they lie.
1496 2011-10-02 21:32:25 <gmaxwell> luke-jr: the software automatically abuses 50%+ already. :)
1497 2011-10-02 21:32:30 <ByteCoin> If miners lie then it's OK to force them to loose money
1498 2011-10-02 21:32:42 <luke-jr> gmaxwell: oh? not quite the same way, at least.
1499 2011-10-02 21:32:55 <gmaxwell> luke-jr: no… not the same way. Indeed.
1500 2011-10-02 21:33:20 <luke-jr> "block discouragement" basically forces every miner into one camp or the other
1501 2011-10-02 21:33:39 <luke-jr> either you "discourage" (ie, collude against) some block, or you accept it
1502 2011-10-02 21:33:43 <ByteCoin> luke-jr: Agreed. It leads to cartel formation potentially.
1503 2011-10-02 21:33:46 <gmaxwell> But right now you'll never switch off extending your own prev until someone else is at least 1 further ahead. So if you have >>50% on one node it will automatically do the takeover attack. :)
1504 2011-10-02 21:34:01 <luke-jr> gmaxwell: but right now, you never intentionally fork
1505 2011-10-02 21:34:16 <gmaxwell> luke-jr: if you aceept it it does you no harm, however.
1506 2011-10-02 21:34:32 <gmaxwell> er accept.
1507 2011-10-02 21:34:36 <luke-jr> gmaxwell: if you accept it, you do the colluders harm ;)
1508 2011-10-02 21:34:40 <gmaxwell> Yes.
1509 2011-10-02 21:34:54 <diki> what in the world does colluders mean????
1510 2011-10-02 21:34:58 <luke-jr> basically, you have two groups fighting over the blocks instead of cooperating
1511 2011-10-02 21:35:03 <luke-jr> effectively halving the hashpower
1512 2011-10-02 21:35:23 <gmaxwell> Right, which is why it would be moronic to put anything people should really want to use in as a discouragement trigger.
1513 2011-10-02 21:35:24 <ByteCoin> luke-jr: Let me get this straight. You only extend off your own prev until someone else is more ahead?!?!?!
1514 2011-10-02 21:35:27 <ByteCoin> This is now?
1515 2011-10-02 21:35:49 <luke-jr> ByteCoin: uh, of course?
1516 2011-10-02 21:35:52 <gmaxwell> ByteCoin: If you solved the last block, then you'll only extend your own until some other fragement is longer by 1.
1517 2011-10-02 21:36:31 <ByteCoin> Oh. Ok I see. I thought you meant something else
1518 2011-10-02 21:36:38 <luke-jr> ByteCoin: anything else is suicide unless you (or your collusion) has 50% hashpower
1519 2011-10-02 21:37:01 <gmaxwell> It has the weird-ish result that if you get >>50% you'll get all the blocks.
1520 2011-10-02 21:37:04 <ByteCoin> luke-jr: Yes of course :-/
1521 2011-10-02 21:37:17 <ByteCoin> gmaxwell: Shh
1522 2011-10-02 21:37:29 <luke-jr> gmaxwell: that's only with the "discouragement" bs set to 1 ;)
1523 2011-10-02 21:37:40 <luke-jr> or true, rather
1524 2011-10-02 21:37:51 <gmaxwell> well all pool operatorators except luke run multiple bitcoind's and I bet none have adjusted them to pool that decision. :)
1525 2011-10-02 21:38:08 <luke-jr> what decision?
1526 2011-10-02 21:38:16 <ByteCoin> gmaxwell: Cartells - here we come!
1527 2011-10-02 21:38:41 <gmaxwell> luke-jr: extending your own prev, even if it almost certantly lost in the network.
1528 2011-10-02 21:38:46 <luke-jr> gmaxwell: running multiple bitcoinds doesn't get past the time range issue btw
1529 2011-10-02 21:38:51 <ByteCoin> gmaxwel: Shh
1530 2011-10-02 21:39:02 <gmaxwell> Yea okay. I'll be quiet.
1531 2011-10-02 21:39:16 <ByteCoin> Just about that.... otherwise you're good
1532 2011-10-02 21:39:19 Joric has quit ()
1533 2011-10-02 21:40:14 <gmaxwell> luke-jr: so do you have any solution to keep people from mining things we can't expressly forbid without creating forks, but which are clearly and objectively harmful to bitcoin?
1534 2011-10-02 21:40:50 <luke-jr> gmaxwell: like what?
1535 2011-10-02 21:40:51 <gmaxwell> E.g. what if some anonymous party with a lot of hashpower started issuing large amounts of 1MB blocks full of 0 value outputs and nothing else? What should we do?
1536 2011-10-02 21:41:52 <gmaxwell> say they had 40% hashpower.. so they'd be adding about 1.75GBytes/month to the blockchain.
1537 2011-10-02 21:41:55 <luke-jr> no, I can't think of any good solution for that other than collusion
1538 2011-10-02 21:42:47 <gmaxwell> Right, I can't either.
1539 2011-10-02 21:42:55 yeah has joined
1540 2011-10-02 21:43:31 huk has quit ()
1541 2011-10-02 21:43:39 <gmaxwell> Bad collusion is possible no matter what we put in the software. But good collusion is only possible if we make it easy.
1542 2011-10-02 21:44:47 <gmaxwell> E.g. two or three miners that combine to >50% could easily share a patch that identifies and excludes the eligius blocks.  It would probably only be about 10 lines of code, in fact.
1543 2011-10-02 21:45:23 <gmaxwell> E.g. reject blocks as invalid over height X if they have multiple outputs in the coinbase.
1544 2011-10-02 21:45:52 <nanotube> gmaxwell: not all of those are eligius
1545 2011-10-02 21:46:18 <gmaxwell> fine, add four more lines of code to check against a list of 100 obviously eligius payout addresses.
1546 2011-10-02 21:46:23 <luke-jr> gmaxwell: even good collusion is still vulnerable to <50%
1547 2011-10-02 21:47:29 theorbtwo has joined
1548 2011-10-02 21:49:06 <luke-jr> that is, if you're discouraging 40% of blocks and have <50% hashpower, 40% of YOUR blocks are invalid
1549 2011-10-02 21:49:35 <gmaxwell> No, because proper discouragement causes you to switch as soon as you fall behind.
1550 2011-10-02 21:50:51 <diki> so i havent been very active
1551 2011-10-02 21:50:52 zhoutong has quit (Read error: Connection reset by peer)
1552 2011-10-02 21:50:58 <diki> but what happened to all the bruce wagner stuff?
1553 2011-10-02 21:51:04 <diki> havent read anything about him for a while
1554 2011-10-02 21:51:43 zhoutong has joined
1555 2011-10-02 21:53:16 yeah has quit (Quit: Page closed)
1556 2011-10-02 21:53:52 Rabbit67890 has quit (Quit: Rabbit67890)
1557 2011-10-02 21:56:01 zhoutong has quit (Read error: Connection reset by peer)
1558 2011-10-02 21:56:28 magn3ts has quit (Ping timeout: 258 seconds)
1559 2011-10-02 21:56:42 zhoutong has joined
1560 2011-10-02 21:57:48 <terrytibbs> diki: #bitcoin-drama
1561 2011-10-02 22:00:50 <luke-jr> gmaxwell: then that "proper discouragement" has very little effect
1562 2011-10-02 22:00:59 <luke-jr> diki: he confessed
1563 2011-10-02 22:02:33 zhoutong has quit (Read error: Connection reset by peer)
1564 2011-10-02 22:03:52 zhoutong has joined
1565 2011-10-02 22:04:41 <diki> luke-jr:i know he confessed about bold funding or whatever it was
1566 2011-10-02 22:04:47 <diki> but what happened after that?
1567 2011-10-02 22:08:21 <terrytibbs> diki: gotcha!
1568 2011-10-02 22:08:30 danbri has quit (Remote host closed the connection)
1569 2011-10-02 22:11:23 magn3ts has joined
1570 2011-10-02 22:11:38 Schematografter has joined
1571 2011-10-02 22:13:15 zhoutong has quit (Read error: Connection reset by peer)
1572 2011-10-02 22:13:57 zhoutong has joined
1573 2011-10-02 22:14:43 Joric has joined
1574 2011-10-02 22:16:16 abragin has quit (Ping timeout: 244 seconds)
1575 2011-10-02 22:16:22 abragin has joined
1576 2011-10-02 22:16:22 abragin has quit (Changing host)
1577 2011-10-02 22:16:23 abragin has joined
1578 2011-10-02 22:16:25 t3a has quit (Ping timeout: 260 seconds)
1579 2011-10-02 22:16:51 <Joric> is moving to qt is still questionnable or it's done already? is there any possibility you'll move back to wxwidgets?
1580 2011-10-02 22:18:07 fahadsadah has quit (Excess Flood)
1581 2011-10-02 22:19:52 <sipa> if you want to bring the wxui up-to-date and maintain it, maybe
1582 2011-10-02 22:21:40 faraday has quit (Quit: Connection closed for inactivity)
1583 2011-10-02 22:22:27 <sipa> and the move is already done in git head
1584 2011-10-02 22:24:09 clr_ has quit (Ping timeout: 252 seconds)
1585 2011-10-02 22:24:09 zhoutong has quit (Read error: Connection reset by peer)
1586 2011-10-02 22:24:51 Cusipzzz has quit (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/)
1587 2011-10-02 22:25:07 zhoutong has joined
1588 2011-10-02 22:31:10 zhoutong has quit (Write error: Connection reset by peer)
1589 2011-10-02 22:31:49 zhoutong has joined
1590 2011-10-02 22:32:05 fahadsadah has joined
1591 2011-10-02 22:32:17 <diki> sipa
1592 2011-10-02 22:32:30 <diki> does 0.4.0 feature an rpc command for fetching generated blocks?
1593 2011-10-02 22:32:45 <diki> what i mean is to avoid using listtransactions
1594 2011-10-02 22:34:04 sshirokov has joined
1595 2011-10-02 22:34:58 <sipa> not afaik
1596 2011-10-02 22:35:07 someone42 has quit (Write error: Connection reset by peer)
1597 2011-10-02 22:35:18 yeah has joined
1598 2011-10-02 22:37:09 zhoutong has quit (Read error: Connection reset by peer)
1599 2011-10-02 22:38:07 AnnihilaT has quit (Quit: changing servers)
1600 2011-10-02 22:38:11 zhoutong has joined
1601 2011-10-02 22:38:24 AnnihilaT has joined
1602 2011-10-02 22:45:13 DontMindMe has joined
1603 2011-10-02 22:47:23 Diablo-D3 has joined
1604 2011-10-02 22:48:41 marf_away2 has quit (Ping timeout: 255 seconds)
1605 2011-10-02 22:48:46 abragin has quit ()
1606 2011-10-02 22:53:01 zhoutong has quit (Read error: Connection reset by peer)
1607 2011-10-02 22:54:11 zhoutong has joined
1608 2011-10-02 22:55:17 zhoutong has quit (Read error: Connection reset by peer)
1609 2011-10-02 22:56:05 HarryS has joined
1610 2011-10-02 22:56:22 zhoutong has joined
1611 2011-10-02 22:58:22 noagendamarket has joined
1612 2011-10-02 22:59:58 Zarutian has quit (Quit: Zarutian)
1613 2011-10-02 23:01:11 heinz` has left ()
1614 2011-10-02 23:02:13 clr_ has joined
1615 2011-10-02 23:04:31 genjix has joined
1616 2011-10-02 23:04:39 <genjix> hey
1617 2011-10-02 23:04:43 <genjix> http://privatepaste.com/fb86b7c91c
1618 2011-10-02 23:05:00 <genjix> 1) nAskedForBlocks should be initialised to 0 if someone wants to make that patch
1619 2011-10-02 23:05:27 <genjix> 2) What's the purpose of vNodes.size() <= 1?
1620 2011-10-02 23:05:32 Turingi has quit (Read error: Connection reset by peer)
1621 2011-10-02 23:10:54 zhoutong has quit (Read error: Connection reset by peer)
1622 2011-10-02 23:11:23 erus` has quit (Quit: ChatZilla 0.9.87 [Firefox 6.0.2/20110902133214])
1623 2011-10-02 23:11:36 zhoutong has joined
1624 2011-10-02 23:11:39 yeah has quit (Quit: Page closed)
1625 2011-10-02 23:12:17 <tcatm> genjix: is that code in bitcoin? if so, where?
1626 2011-10-02 23:12:38 <genjix> tcatm: main.cpp when you get version message
1627 2011-10-02 23:12:53 <genjix> it's not a huge deal having that non-initialised (it's a minor bug)
1628 2011-10-02 23:16:28 <tcatm> it is initialized :)
1629 2011-10-02 23:16:51 <genjix> cool. but why does it have that vNodes.size() <= 1 check?
1630 2011-10-02 23:17:18 <genjix> the nAskedForBlocks < 1 is much better.
1631 2011-10-02 23:17:21 t3a has joined
1632 2011-10-02 23:17:36 <genjix> i don't think that should be there tbh
1633 2011-10-02 23:17:46 <tcatm> that's probably very old code so it might not be needed anymore
1634 2011-10-02 23:21:53 zhoutong has quit (Read error: Connection reset by peer)
1635 2011-10-02 23:21:57 mosimo has quit (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com ))
1636 2011-10-02 23:22:19 zhoutong has joined
1637 2011-10-02 23:26:09 <genjix> tcatm: also CNode::Subscribe is never called anywhere.
1638 2011-10-02 23:26:22 <genjix> so you can scrub that
1639 2011-10-02 23:27:02 <genjix> it's something satoshi started and never finished
1640 2011-10-02 23:27:22 <tcatm> maybe someone else will finish it someday?
1641 2011-10-02 23:27:31 <genjix> dont think so :p
1642 2011-10-02 23:27:35 underscor has joined
1643 2011-10-02 23:29:52 zhoutong has quit (Read error: Connection reset by peer)
1644 2011-10-02 23:30:29 <devrandom> later tell gavinandresen OP_EVAL will fork the chain.  All that is needed is for someone to mine a tx with an embedded script that fails to verify.  Then old clients will think it's valid and new ones will think it's invalid.
1645 2011-10-02 23:30:54 zhoutong has joined
1646 2011-10-02 23:31:04 <devrandom> gah
1647 2011-10-02 23:31:07 <genjix> yeah i think it's a very bad idea
1648 2011-10-02 23:31:10 <devrandom> ;;later tell gavinandresen OP_EVAL will fork the chain.  All that is needed is for someone to mine a tx with an embedded script that fails to verify.  Then old clients will think it's valid and new ones will think it's invalid.
1649 2011-10-02 23:31:11 <gribble> The operation succeeded.
1650 2011-10-02 23:31:37 <genjix> what do you all think about a new message like:
1651 2011-10-02 23:31:52 <genjix> "error" "123" "Reason is blaa blaa"
1652 2011-10-02 23:32:17 <genjix> command="error". payload is var_uint and var_str
1653 2011-10-02 23:32:27 <MagicalTux> anyone with good knowledge of bitcoin tx could tell me why my tx is not accepted by the bitcoin client if I show it?
1654 2011-10-02 23:32:30 <genjix> so before cutting off nodes, you can give them a reason.
1655 2011-10-02 23:32:30 underscor has quit (Ping timeout: 248 seconds)
1656 2011-10-02 23:33:38 <gmaxwell> devrandom: this isn't news to him
1657 2011-10-02 23:33:41 <tcatm> genjix: I'd prefer a few very useful hardcoded error messages instead of custom strings. after all, no one is going to read it ever.
1658 2011-10-02 23:34:04 <gmaxwell> devrandom: you simply have to get a majority of miners on the new code prior to someone doing that. The chain will unfork then if it does.
1659 2011-10-02 23:34:22 <genjix> tcatm: hence the error_code. but you need body text for adding context.
1660 2011-10-02 23:34:35 <gmaxwell> You can also make the new code keep the old behavior for blocks before a certian height.
1661 2011-10-02 23:34:58 <gmaxwell> So you can set the actual switch point at some point in the future.
1662 2011-10-02 23:35:50 <gmaxwell> (so that you have time to actually achieve >>50% hashpower behind the change)
1663 2011-10-02 23:35:52 brunner has joined
1664 2011-10-02 23:38:09 zhoutong has quit (Read error: Connection reset by peer)
1665 2011-10-02 23:38:13 Namegduf has quit (Remote host closed the connection)
1666 2011-10-02 23:38:14 <gmaxwell> e.g. make and backport a patch which will agressively not forwardward txn with the reserved NOP until block X, and after X start applying the new validation rules but only to future blocks.  Then so long has >>50% hashpower is running this patch by block X there is no lasting fork created.
1667 2011-10-02 23:38:18 <tcatm> genjix: I don't think context is needed. If a client drops your connection you can connect to a new node. As long as it has around 6 to 8 connections it should be fine.
1668 2011-10-02 23:39:32 zhoutong has joined
1669 2011-10-02 23:39:56 <devrandom> gmaxwell: good point
1670 2011-10-02 23:40:36 <gmaxwell> Life can be made even happier if someone wants to backport the patch to old versions.
1671 2011-10-02 23:42:57 <devrandom> gmaxwell: generalizing from that - any validation change that increases restrictions (makes some valids become invalid) has the same property.
1672 2011-10-02 23:44:21 <gmaxwell> devrandom: right, but if you make something invalid valid you're screwed.
1673 2011-10-02 23:44:22 <genjix> k well tcatm i made a ML post
1674 2011-10-02 23:44:32 ThomasV has joined
1675 2011-10-02 23:44:36 <genjix> :p
1676 2011-10-02 23:44:38 genjix has left ()
1677 2011-10-02 23:45:34 <devrandom> ;;later tell gavinandresen gmaxwell just explained to me that if >>50% of hashpower has the new behavior then such a fork would not be lasting.  This seems to be a property of any validation change where some valid txs become invalid.
1678 2011-10-02 23:45:34 <gribble> The operation succeeded.
1679 2011-10-02 23:47:31 Cablesaurus has quit (Quit: IceChat - Keeping PC's cool since 2000)
1680 2011-10-02 23:49:07 Joric has quit ()
1681 2011-10-02 23:50:11 zhoutong has quit (Read error: Connection reset by peer)
1682 2011-10-02 23:51:20 zhoutong has joined
1683 2011-10-02 23:54:22 vorlov has joined
1684 2011-10-02 23:55:26 andrew__ has joined
1685 2011-10-02 23:55:30 andrew__ has quit (Client Quit)
1686 2011-10-02 23:55:40 noagendamarket has quit (Ping timeout: 276 seconds)
1687 2011-10-02 23:57:18 fnord0 has joined
1688 2011-10-02 23:59:30 vorlov has quit (Quit: vorlov)