1 2012-11-27 00:00:45 darkskiez_ has quit (Quit: darkskiez_)
   2 2012-11-27 00:01:35 <jgarzik> still using Paxos under the hood, a la the original Google Chubby   http://research.google.com/archive/chubby.html
   3 2012-11-27 00:01:50 <i18n> whatever happened to that bitcoin gambling game where you could bet that the block will end in some hex characters, and once there is a block that does, you were sent the pot?
   4 2012-11-27 00:02:16 <WeLoveCP> So the client right now verifies all the blocks, why don't you push a cached state of the blocks up to a certain date and have it hashed and distribute it p2p to speed that process up?
   5 2012-11-27 00:02:51 <sipa> WeLoveCP: if you're going to trust us to do the database indexing for you, why are you running a full node in the first place?
   6 2012-11-27 00:03:14 <sipa> WeLoveCP: the reason is because you exactly don't want to trust anyone - if you do, you're better off running a lightweight node
   7 2012-11-27 00:03:16 <WeLoveCP> 'trust'?  if it is hashed and verified by many people it's more like web of trust?
   8 2012-11-27 00:03:30 <WeLoveCP> then you just calculate blocks from that date to the future?
   9 2012-11-27 00:03:34 <sipa> lightweight nodes get their trust from the entire bitcoin network
  10 2012-11-27 00:03:48 <sipa> that's much safer and much more automatic
  11 2012-11-27 00:04:23 <WeLoveCP> ok cool
  12 2012-11-27 00:04:29 <sipa> http://bitcoin.stackexchange.com/questions/5471/would-it-be-possible-to-provide-a-downloadable-blockchain-that-is-updated-and-ve
  13 2012-11-27 00:04:36 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
  14 2012-11-27 00:10:05 <i18n> do any of you guys remember the bitcoin game someone made a long time ago in which you could bet that a block would end in some hex value, and are sent the pot if that happens?
  15 2012-11-27 00:10:22 <i18n> i think it was one of the very first games...
  16 2012-11-27 00:10:51 <i18n> and it's interesting because it's not just a random number, because it used the block chain
  17 2012-11-27 00:10:55 JZavala has joined
  18 2012-11-27 00:13:50 <Luke-Jr> jgarzik: it would be nice if bitcoind had some way to resume-index from its last known block, if files were appended or it crashed during IBreindex
  19 2012-11-27 00:14:02 Gladamas_ has joined
  20 2012-11-27 00:14:18 <jgarzik> Luke-Jr: reindex is a rare one-time event, so not worth the effort
  21 2012-11-27 00:14:27 <Luke-Jr> aw
  22 2012-11-27 00:14:29 <sipa> Luke-Jr: it *does* that
  23 2012-11-27 00:14:30 <jgarzik> new users >= 0.8 will never use that code at all
  24 2012-11-27 00:14:34 <Luke-Jr> sipa: it does? :o
  25 2012-11-27 00:14:37 <sipa> it resumes from a reindex
  26 2012-11-27 00:15:03 <sipa> it stores a flag in the blk database that it is reindexing, and removes it when finished
  27 2012-11-27 00:15:23 <sipa> if the flag is present at startup, it starts over again, skipping over parts of the files that are already indexes
  28 2012-11-27 00:17:27 Gladamas has quit (Ping timeout: 245 seconds)
  29 2012-11-27 00:17:45 <Luke-Jr> nice
  30 2012-11-27 00:17:54 PhantomSpark has quit (Ping timeout: 276 seconds)
  31 2012-11-27 00:18:14 maaku has quit (Quit: maaku)
  32 2012-11-27 00:18:20 Gladamas_ has quit (Read error: Connection reset by peer)
  33 2012-11-27 00:18:59 <i18n> nobody remembers it? wow. that makes me wish i didn't get bored of bitcoin two years ago.
  34 2012-11-27 00:20:17 <Luke-Jr> i18n: there's still at least one ongoing
  35 2012-11-27 00:20:19 <i18n> by get bored of i mean lose interest
  36 2012-11-27 00:20:23 <Luke-Jr> except the "pot" is ASIC hardware
  37 2012-11-27 00:20:26 <i18n> Luke-Jr: really? do you know what it's called?
  38 2012-11-27 00:20:29 <Luke-Jr> no
  39 2012-11-27 00:20:30 <i18n> oh
  40 2012-11-27 00:20:33 <Luke-Jr> luceo (otc) runs it
  41 2012-11-27 00:20:48 * i18n considers creating one
  42 2012-11-27 00:23:53 <Luke-Jr> bitcoind: main.cpp:1543: bool CBlock::DisconnectBlock(CBlockIndex*, CCoinsViewCache&): Assertion `blockUndo.vtxundo.size() + 1 == vtx.size()' failed.
  43 2012-11-27 00:23:55 <Luke-Jr> sipa: O.o⁇
  44 2012-11-27 00:24:16 flatfly has quit (Quit: Yo!)
  45 2012-11-27 00:25:10 <sipa> Luke-Jr: that shouldn't be an assert, but it does mean the undo data and the block data are out of sync
  46 2012-11-27 00:25:11 x18882 has joined
  47 2012-11-27 00:25:45 <sipa> what did you do to get that?
  48 2012-11-27 00:27:01 Gladamas has joined
  49 2012-11-27 00:28:33 MrTiggr- has joined
  50 2012-11-27 00:29:20 MrTiggr- is now known as MrTiggr
  51 2012-11-27 00:31:41 <Luke-Jr> sipa: reindexed from a read-only blk file
  52 2012-11-27 00:31:59 <Luke-Jr> tired of fighting it, so giving up and copying the block files now
  53 2012-11-27 00:32:03 <Luke-Jr> will let you know if it still happens
  54 2012-11-27 00:32:14 <Luke-Jr> (giving up = after I finish this pullreq)
  55 2012-11-27 00:32:24 PhantomSpark has joined
  56 2012-11-27 00:32:51 <sipa> right, having read-only linked files is certainly that sounds nice to support, but i don't expect it to work out of the box now
  57 2012-11-27 00:34:41 x18882 has quit (Quit: Yo!)
  58 2012-11-27 00:39:23 <Luke-Jr> there, pullreq fixed (though I'm ignoring the truncate race for now)
  59 2012-11-27 00:40:40 TD has quit (Quit: TD)
  60 2012-11-27 00:41:05 <sipa> i wonder how the old code prevented writing the genesis block to the block files?
  61 2012-11-27 00:41:10 <Luke-Jr> sipa: with copied files, it assert fails still. trying again with -reindex
  62 2012-11-27 00:41:34 <sipa> in test i mean
  63 2012-11-27 00:42:38 darkskiez2 has quit (Ping timeout: 245 seconds)
  64 2012-11-27 00:42:59 darsk1ez has quit (Ping timeout: 250 seconds)
  65 2012-11-27 00:43:04 da2ce7 has quit (Ping timeout: 255 seconds)
  66 2012-11-27 00:43:15 rdponticelli has quit (Ping timeout: 276 seconds)
  67 2012-11-27 00:43:30 rdponticelli_ has joined
  68 2012-11-27 00:45:25 darkskiez2 has joined
  69 2012-11-27 00:45:39 darsk1ez has joined
  70 2012-11-27 00:57:32 <Luke-Jr> sipa: assert still fails with -reindex, trying on master now :/
  71 2012-11-27 00:57:41 trreffferter has quit (Quit: Page closed)
  72 2012-11-27 01:02:45 PhantomSpark has quit (Ping timeout: 276 seconds)
  73 2012-11-27 01:04:45 denisx has joined
  74 2012-11-27 01:07:23 denisx has quit (Read error: Connection reset by peer)
  75 2012-11-27 01:07:27 denisx_ has joined
  76 2012-11-27 01:12:55 PhantomSpark has joined
  77 2012-11-27 01:15:57 <sipa> Luke-Jr: test_bitcoin indeed writes some blocks to blk00000.dat
  78 2012-11-27 01:16:19 <sipa> i wonder whether 0.7.x did that as well
  79 2012-11-27 01:26:38 <sipa> Luke-Jr: 0.7.1 does also write blocks to blk0001.dat :)
  80 2012-11-27 01:27:16 maaku has joined
  81 2012-11-27 01:27:18 <sipa> however, pre-ultraprune it was always just appending; now it writes at the end of the used section of the file, which in case of a fresh memenv-backed db is nothing
  82 2012-11-27 01:27:32 <sipa> so running test_bitcoin really corrupts your block database
  83 2012-11-27 01:39:20 maaku has quit (Quit: maaku)
  84 2012-11-27 01:39:35 unknown45682 has joined
  85 2012-11-27 01:49:04 djoot has quit (Ping timeout: 252 seconds)
  86 2012-11-27 01:49:18 emryss has quit (Ping timeout: 245 seconds)
  87 2012-11-27 01:50:01 <Luke-Jr> sipa: eh, but master just worked :/
  88 2012-11-27 01:52:41 npouillard has quit (Quit: WeeChat 0.3.9.2)
  89 2012-11-27 01:52:54 <sipa> normal sync; test_bitcoin; bitcoind -reindex  <-- should fail
  90 2012-11-27 01:53:28 <sipa> (well, it should work, but the reindex will fail after the genesis block, and normal sync should recover)
  91 2012-11-27 01:55:08 npouillard has joined
  92 2012-11-27 01:58:54 <Luke-Jr> pretty sure I've done that a number of times <.<
  93 2012-11-27 02:01:56 <sipa> hmm, strange!
  94 2012-11-27 02:01:59 <sipa> afk
  95 2012-11-27 02:10:28 <weex> is there a way to convert a compressed private key into an uncompressed one?
  96 2012-11-27 02:14:14 <sipa> private keys are not compressed or uncompressed
  97 2012-11-27 02:14:38 <sipa> each private key has a public key, and that public key can be serialized in compressed or uncompressed form
  98 2012-11-27 02:15:54 <weex> so the first letter of the privkey is just to tell how the public key should be handled?
  99 2012-11-27 02:15:59 <sipa> yes
 100 2012-11-27 02:16:07 <sipa> actually, no
 101 2012-11-27 02:16:10 <sipa> the last base
 102 2012-11-27 02:16:27 <sipa> but adding a byte changes every character (including the first one) in base58 encoding
 103 2012-11-27 02:17:17 <weex> if i'm trying to import a compressed key and getting invalid key, i'm just wondering if there is a transformation i can do to make it importable
 104 2012-11-27 02:17:31 <sipa> into what software?
 105 2012-11-27 02:17:34 <weex> litcoind
 106 2012-11-27 02:17:45 <sipa> there's no point
 107 2012-11-27 02:17:58 <weex> litecoind (i have modified addrgen to create litecoin addresses)
 108 2012-11-27 02:18:09 <sipa> if the software doesn't support compressed keys, there's no point trying to import it
 109 2012-11-27 02:18:17 <sipa> as the address will not match anyway
 110 2012-11-27 02:18:18 <weex> that's the answer i was looking for
 111 2012-11-27 02:19:09 <weex> ok so basically unspendable until more code is working
 112 2012-11-27 02:26:12 <weex> does bitcoind support importing compressed keys?
 113 2012-11-27 02:27:17 <sipa> yes
 114 2012-11-27 02:27:23 <sipa> since 0.5, iirc
 115 2012-11-27 02:28:12 <sipa> since 0.6
 116 2012-11-27 02:29:51 PhantomSpark has quit (Ping timeout: 276 seconds)
 117 2012-11-27 02:32:36 Keefe_ is now known as Keefe
 118 2012-11-27 02:38:19 BlackPrapor has quit (Read error: Connection reset by peer)
 119 2012-11-27 02:41:01 phungus has quit (Ping timeout: 255 seconds)
 120 2012-11-27 02:44:07 phungus has joined
 121 2012-11-27 03:00:08 D34TH has quit (Read error: Connection reset by peer)
 122 2012-11-27 03:19:24 dust-otc has joined
 123 2012-11-27 03:25:31 denisx_ has quit (Quit: denisx_)
 124 2012-11-27 03:27:23 emryss has joined
 125 2012-11-27 03:45:54 da2ce7 has joined
 126 2012-11-27 03:46:17 fiesh has quit (Ping timeout: 255 seconds)
 127 2012-11-27 03:47:06 PhantomSpark has joined
 128 2012-11-27 03:50:36 twobitcoins has joined
 129 2012-11-27 03:51:28 fiesh has joined
 130 2012-11-27 03:55:55 denisx has joined
 131 2012-11-27 04:12:35 phungus has quit (Ping timeout: 260 seconds)
 132 2012-11-27 04:13:04 jarpiain has quit (Ping timeout: 260 seconds)
 133 2012-11-27 04:13:30 phungus has joined
 134 2012-11-27 04:13:30 jarpiain has joined
 135 2012-11-27 04:13:55 jarpiain is now known as Guest35103
 136 2012-11-27 04:30:03 <phantomcircuit> am i reading this invoicing proposal correctly that it's wanting to use the X.509 (ie https) infrastructure for bitcoin invoices?
 137 2012-11-27 04:30:19 emryss has quit (Ping timeout: 260 seconds)
 138 2012-11-27 04:31:23 <gmaxwell> X.509 is _not_ https.
 139 2012-11-27 04:31:47 emryss has joined
 140 2012-11-27 04:31:50 <phantomcircuit> gmaxwell, find me a cert issuer that isn't entirely based around https :|
 141 2012-11-27 04:31:54 <gmaxwell> But yes, it's talking about using the x.509 certificate infrastructure at least as an initial option for persistant identities.
 142 2012-11-27 04:41:39 OneFixt has quit (Remote host closed the connection)
 143 2012-11-27 04:41:48 mykhal has quit (Ping timeout: 276 seconds)
 144 2012-11-27 04:43:26 OneFixt has joined
 145 2012-11-27 04:49:25 [7] has quit (Disconnected by services)
 146 2012-11-27 04:49:34 TheSeven has joined
 147 2012-11-27 04:49:34 denisx has quit (Quit: denisx)
 148 2012-11-27 05:00:10 arij_ has joined
 149 2012-11-27 05:01:10 djoot has joined
 150 2012-11-27 05:01:25 arij_ has quit (Read error: Connection reset by peer)
 151 2012-11-27 05:01:26 arij has quit (Ping timeout: 244 seconds)
 152 2012-11-27 05:01:34 djoot is now known as Guest36215
 153 2012-11-27 05:02:45 arij has joined
 154 2012-11-27 05:03:09 arij is now known as Guest83524
 155 2012-11-27 05:07:11 PhantomSpark has joined
 156 2012-11-27 05:11:42 PhantomSpark has quit (2!~kvirc@pool-71-190-231-20.nycmny.fios.verizon.net|Ping timeout: 276 seconds)
 157 2012-11-27 05:13:53 ThomasV has joined
 158 2012-11-27 05:35:18 JZavala has quit (Ping timeout: 256 seconds)
 159 2012-11-27 05:39:49 swulf-- has joined
 160 2012-11-27 05:49:56 Bootstrapper has quit (Remote host closed the connection)
 161 2012-11-27 06:11:37 WeLoveCP is now known as VronSKY
 162 2012-11-27 06:12:26 Silverion has joined
 163 2012-11-27 06:14:23 emryss has quit (Ping timeout: 260 seconds)
 164 2012-11-27 06:14:42 root2 has quit (Read error: Connection reset by peer)
 165 2012-11-27 06:23:56 root2 has joined
 166 2012-11-27 06:24:37 Detritus has quit (Ping timeout: 244 seconds)
 167 2012-11-27 06:24:49 Guest83524 is now known as arij
 168 2012-11-27 06:25:00 arij has quit (Changing host)
 169 2012-11-27 06:25:00 arij has joined
 170 2012-11-27 06:32:56 unknown45682 has joined
 171 2012-11-27 06:33:25 maaku has joined
 172 2012-11-27 06:34:05 brwyatt is now known as brwyatt|Away
 173 2012-11-27 06:35:23 unknown45682 has quit (Ping timeout: 246 seconds)
 174 2012-11-27 06:41:59 RazielZ has joined
 175 2012-11-27 06:46:50 maaku has quit (Quit: maaku)
 176 2012-11-27 06:51:19 devrandom has quit (Remote host closed the connection)
 177 2012-11-27 06:52:37 devrandom has joined
 178 2012-11-27 06:55:58 Bootstrapper has joined
 179 2012-11-27 07:01:20 ovidiusoft has joined
 180 2012-11-27 07:03:29 ThomasV has quit (Quit: Quitte)
 181 2012-11-27 07:05:00 Detritus has joined
 182 2012-11-27 07:07:54 tonikt has quit (Quit: Leaving)
 183 2012-11-27 07:11:29 AlexWaters1 has quit (Remote host closed the connection)
 184 2012-11-27 07:12:27 AlexWaters1 has joined
 185 2012-11-27 07:12:33 eroot has joined
 186 2012-11-27 07:14:51 maaku has joined
 187 2012-11-27 07:16:32 Guest36215 has quit (Quit: leaving)
 188 2012-11-27 07:16:56 djoot has joined
 189 2012-11-27 07:16:56 djoot has quit (Changing host)
 190 2012-11-27 07:16:56 djoot has joined
 191 2012-11-27 07:24:04 veeminer has joined
 192 2012-11-27 07:46:29 MobiusL has quit (Quit: Ex-Chat)
 193 2012-11-27 07:50:06 MobiusL has joined
 194 2012-11-27 07:50:24 Bootstrapper has quit (Remote host closed the connection)
 195 2012-11-27 07:58:51 CodesInChaos has joined
 196 2012-11-27 08:03:59 Gladamas has quit (Read error: Connection reset by peer)
 197 2012-11-27 08:04:10 Gladamas has joined
 198 2012-11-27 08:19:29 w0mbat has joined
 199 2012-11-27 08:24:52 zebedee_ has joined
 200 2012-11-27 08:29:09 maaku has quit (Quit: maaku)
 201 2012-11-27 08:35:57 <Jouke> helo: yesterday you tested that backup wallet didn't overwrite an existing file, could you give more detail: https://github.com/bitcoin/bitcoin/issues/2035
 202 2012-11-27 08:39:01 slush1 has joined
 203 2012-11-27 08:40:50 nibor_ has joined
 204 2012-11-27 08:43:51 nibor has quit (Ping timeout: 255 seconds)
 205 2012-11-27 08:51:17 TD has joined
 206 2012-11-27 09:00:59 Bootstrapper has joined
 207 2012-11-27 09:02:20 BNCatDIGISHELL has quit (Read error: Connection reset by peer)
 208 2012-11-27 09:04:46 jine has quit (Read error: Operation timed out)
 209 2012-11-27 09:06:05 Bootstrapper has quit (Ping timeout: 250 seconds)
 210 2012-11-27 09:20:47 eroot has quit (Remote host closed the connection)
 211 2012-11-27 09:23:41 BNCatDIGISHELL has joined
 212 2012-11-27 09:25:15 TD has quit (Quit: TD)
 213 2012-11-27 09:28:28 toffoo has quit ()
 214 2012-11-27 09:37:02 jine has joined
 215 2012-11-27 09:52:52 comboy_ is now known as comboy
 216 2012-11-27 10:06:00 BlackPrapor has joined
 217 2012-11-27 10:28:49 osmosis has quit (Quit: Leaving)
 218 2012-11-27 10:48:40 toffoo has joined
 219 2012-11-27 10:51:09 gritball_ has quit (Remote host closed the connection)
 220 2012-11-27 10:57:38 gritball has joined
 221 2012-11-27 11:05:36 gritball_ has joined
 222 2012-11-27 11:06:20 [\\\] has quit (Ping timeout: 252 seconds)
 223 2012-11-27 11:08:03 [\\\] has joined
 224 2012-11-27 11:09:07 gritball has quit (Ping timeout: 264 seconds)
 225 2012-11-27 11:10:49 <sipa> ;;bc,blocks
 226 2012-11-27 11:10:49 <gribble> 209812
 227 2012-11-27 11:12:52 gritball_ has quit (Remote host closed the connection)
 228 2012-11-27 11:13:21 gritball has joined
 229 2012-11-27 11:18:02 gritball has quit (Ping timeout: 260 seconds)
 230 2012-11-27 11:21:22 gritball has joined
 231 2012-11-27 11:27:29 DutchBrat has quit (Read error: Connection reset by peer)
 232 2012-11-27 11:28:29 DutchBrat has joined
 233 2012-11-27 11:30:23 DutchBrat has quit (Read error: Connection reset by peer)
 234 2012-11-27 11:32:06 DutchBrat has joined
 235 2012-11-27 11:36:47 unknown45682 has quit (2!~unknown45@pool-98-109-226-74.nwrknj.east.verizon.net|Read error: Connection reset by peer)
 236 2012-11-27 11:37:15 unknown45682 has joined
 237 2012-11-27 11:42:35 one_zero has quit ()
 238 2012-11-27 11:44:09 lumberjak has quit (Read error: Connection reset by peer)
 239 2012-11-27 11:44:17 lumberjak has joined
 240 2012-11-27 11:52:56 xorgate has quit (Read error: Connection reset by peer)
 241 2012-11-27 11:53:59 xorgate has joined
 242 2012-11-27 12:07:06 daybyter has joined
 243 2012-11-27 12:12:42 copumpkin has quit (Ping timeout: 244 seconds)
 244 2012-11-27 12:13:18 copumpkin has joined
 245 2012-11-27 12:13:54 dukedyl_ has quit (Ping timeout: 245 seconds)
 246 2012-11-27 12:24:34 Belkaar has quit (Ping timeout: 244 seconds)
 247 2012-11-27 12:25:33 Belkaar has joined
 248 2012-11-27 12:25:41 Eliel has quit (Quit: leaving)
 249 2012-11-27 12:27:30 Eliel has joined
 250 2012-11-27 12:33:01 t7 has joined
 251 2012-11-27 12:39:17 Hasimir has quit (Ping timeout: 255 seconds)
 252 2012-11-27 12:41:31 dvide has quit ()
 253 2012-11-27 12:43:46 ThomasV has joined
 254 2012-11-27 12:44:59 Hasimir has joined
 255 2012-11-27 12:48:57 ThomasV has quit (Quit: Leaving)
 256 2012-11-27 12:50:02 MC1984 has joined
 257 2012-11-27 12:51:20 Hasimir- has joined
 258 2012-11-27 12:52:14 Hasimir has quit (Disconnected by services)
 259 2012-11-27 12:52:20 Hasimir- has quit (Changing host)
 260 2012-11-27 12:52:20 Hasimir- has joined
 261 2012-11-27 12:53:05 Hasimir- is now known as Hasimir
 262 2012-11-27 13:06:58 toffoo has quit ()
 263 2012-11-27 13:07:06 rdponticelli_ has quit (Remote host closed the connection)
 264 2012-11-27 13:11:50 <slush1> Where the proposal of Payment Protocol which is currently discussed on mailing list can be found?
 265 2012-11-27 13:13:28 <Luke-Jr> slush1: https://gist.github.com/4120476
 266 2012-11-27 13:14:04 <slush1> thanks
 267 2012-11-27 13:17:35 rdponticelli has joined
 268 2012-11-27 13:22:28 rdponticelli has quit (Ping timeout: 276 seconds)
 269 2012-11-27 13:25:41 <Luke-Jr> slush1: btw, to help clarify the stratum discussion: the problem isn't across new blocks as much as it is updating work within a block
 270 2012-11-27 13:26:53 <slush1> luke-jr is there any reason why miners should not accept new job (almost) immediately?
 271 2012-11-27 13:27:14 <Luke-Jr> slush1: no, that's the problem; cgminer insists on using the oldest work it has until clean_jobs=true
 272 2012-11-27 13:27:33 <Luke-Jr> because it's still "valid" according to stratum
 273 2012-11-27 13:27:43 <slush1> For example, stratum proxy don't send long polling broadcast on clean_jobs=False flags, so getwork miners may be a bit late on new jobs. But as far as they should (by getwork definition) ask for jobs every minute, this is almost no problem. And stratum subminers know about new jobs immediately
 274 2012-11-27 13:27:45 ThomasV has joined
 275 2012-11-27 13:28:17 <slush1> luke-jr then it is just implementation bug in the cgminer and should be fixed. The fact there's some flag "you should use this job" won't fix what is broken in the code.
 276 2012-11-27 13:28:29 <Luke-Jr> slush1: it's intentional
 277 2012-11-27 13:28:34 <slush1> ckolivas told me that cgminer is trying the newest job, so it looks it wasn't his purpose
 278 2012-11-27 13:28:36 <slush1> why?
 279 2012-11-27 13:28:43 <Luke-Jr> oh?
 280 2012-11-27 13:29:01 <Luke-Jr> no idea then, as it's clearly re-using the old job after it's had the new one for a while
 281 2012-11-27 13:29:01 daybyter has quit (Quit: Konversation terminated!)
 282 2012-11-27 13:29:16 <slush1> as I said, I think it is more the bug than the feature
 283 2012-11-27 13:29:41 <Luke-Jr> but if you're assuming 60 seconds of grace time, maybe I need to adjust how often I send new jobs
 284 2012-11-27 13:29:43 <slush1> we discussed this with ckolivas months before and he confirmed that cgminer should always use the latest job
 285 2012-11-27 13:29:52 JZavala has joined
 286 2012-11-27 13:29:56 <Luke-Jr> it certainly doesn't in practice.
 287 2012-11-27 13:30:07 <slush1> is ckolivas aware of it?
 288 2012-11-27 13:30:14 <slush1> I must say that I'm a bit lost in cgminer's discussion..
 289 2012-11-27 13:30:22 <Luke-Jr> who knows, he ignores me
 290 2012-11-27 13:30:27 <slush1> lol
 291 2012-11-27 13:30:48 <slush1> is there any evidence/source code which makes the problem? I can report it to him
 292 2012-11-27 13:30:54 <Luke-Jr> 120 - 5 seconds latency - 60 seconds grace time = 55 seconds
 293 2012-11-27 13:31:11 <slush1> what's that ? ^
 294 2012-11-27 13:31:24 <Luke-Jr> 120 seconds is how long jobs are valid from eloipool
 295 2012-11-27 13:31:33 <Luke-Jr> so 55 seconds between job refreshes I guess
 296 2012-11-27 13:31:36 <Luke-Jr> currently using 96 seconds
 297 2012-11-27 13:31:40 <slush1> My pool is updating jobs every 30 seconds, just because it is cheap enough and there's no reason why make windows bigger
 298 2012-11-27 13:32:08 <slush1> are you dropping jobs older than 120 seconds?
 299 2012-11-27 13:32:12 <Luke-Jr> yes
 300 2012-11-27 13:32:23 <Luke-Jr> and even before dropping, I reject shares on jobs older than 120 seconds
 301 2012-11-27 13:32:42 <slush1> does eloipool already implements stratum?
 302 2012-11-27 13:32:47 <slush1> I'm not following the latest development
 303 2012-11-27 13:33:26 <Luke-Jr> yes
 304 2012-11-27 13:33:34 <slush1> well, with correct implementation of miners, 120 seconds is far enough.
 305 2012-11-27 13:33:47 <Luke-Jr> but I always send clean_work=false and 96 seconds between updates right now
 306 2012-11-27 13:33:51 datagutt has joined
 307 2012-11-27 13:34:00 <slush1> However it's not too safe to drop jobs before you send clean_jobs flag
 308 2012-11-27 13:34:37 <slush1> ok, so can we agree that the main problem is that bug in cgminer?
 309 2012-11-27 13:34:40 <Luke-Jr> slush1: BFGMiner is using the new job immediately for all except BFL devices (and BFL devices also if clean_jobs=true)
 310 2012-11-27 13:34:47 <Luke-Jr> slush1: in this case, yes
 311 2012-11-27 13:34:53 <slush1> and it should use latest known job
 312 2012-11-27 13:35:01 <Luke-Jr> slush1: but if your proxy needs 60 second grace window, I need to reduce my update duration
 313 2012-11-27 13:35:19 <slush1> there's no 60 second timeout in the proxy
 314 2012-11-27 13:35:28 <slush1> it just send LP broadcasts on clean_jobs
 315 2012-11-27 13:35:30 <Luke-Jr> but 60 seconds before miners get new work from proxy
 316 2012-11-27 13:35:52 <Luke-Jr> up to*
 317 2012-11-27 13:36:00 <slush1> so it is up to miner implementation how often it calls getwork, instead of reusing the same with rollntime
 318 2012-11-27 13:36:38 <slush1> shortly said - if getwork miners worked with eloipool without problem before, there's probably no need to change eloipool codebase because of stratum proxy
 319 2012-11-27 13:37:34 <Luke-Jr> it's not up to miner implementation with getwork; pool tells the miner how long a job is valid
 320 2012-11-27 13:37:54 <slush1> oh, I forgot that your pool implements these getwork extensions
 321 2012-11-27 13:37:58 <slush1> I never used them :-)
 322 2012-11-27 13:38:08 <Luke-Jr> explains why they're all missing in stratum :/
 323 2012-11-27 13:38:57 <slush1> Although I understand this is the difference between getwork miner->pool and getwork miner->proxy->pool, I definitely don't see the reason why this should be available for stratum miner
 324 2012-11-27 13:39:06 <Luke-Jr> ugh, I really don't have any way for StratumServer to see if the previous job is still valid or not :/
 325 2012-11-27 13:39:15 <slush1> I mean - defining some refresh windows may be required by getwork miners, because getwork protocol is fucked up
 326 2012-11-27 13:39:36 <slush1> hm, can you elaborate a bit more?
 327 2012-11-27 13:39:47 <slush1> What previous job?
 328 2012-11-27 13:40:00 <slush1> you mean - for statistical reasons?
 329 2012-11-27 13:40:01 agricocb has quit (Quit: Leaving.)
 330 2012-11-27 13:40:24 <Luke-Jr> slush1: I mean to decide if clean_work should be true
 331 2012-11-27 13:40:42 <slush1> how so? You - as pool - has everything necessary to decide
 332 2012-11-27 13:40:49 <Luke-Jr> at a different layer
 333 2012-11-27 13:40:55 <Luke-Jr> not exposed to the network layer atm
 334 2012-11-27 13:41:03 <slush1> well, that's implementation detial
 335 2012-11-27 13:41:05 <slush1> detail
 336 2012-11-27 13:41:19 <Luke-Jr> ☺
 337 2012-11-27 13:41:43 <slush1> and it's even not true. You can detect if prevhash has changed, and set clean job flag at any level :-)
 338 2012-11-27 13:42:01 <slush1> although this is more like a workaround for some architectural issues in the pool
 339 2012-11-27 13:42:41 * Luke-Jr is adding a IsJobValid :P
 340 2012-11-27 13:42:45 rdponticelli has joined
 341 2012-11-27 13:42:47 <slush1> :-)
 342 2012-11-27 13:44:57 drizztbsd has joined
 343 2012-11-27 13:46:25 JZavala has quit (Ping timeout: 264 seconds)
 344 2012-11-27 13:50:34 <Luke-Jr> seems to be working
 345 2012-11-27 13:52:11 korozion has left ()
 346 2012-11-27 13:52:25 Guest35103 is now known as jarpiain
 347 2012-11-27 13:55:42 <Luke-Jr> slush1: my (just-posted) post look correct?
 348 2012-11-27 13:56:31 <slush1> luke-jr I would be surprised :-P
 349 2012-11-27 13:56:36 <Luke-Jr> ?
 350 2012-11-27 13:56:43 <slush1> I'm kidding :)
 351 2012-11-27 13:58:21 <slush1> luke-jr I don't understand that "idle job updates" part, I'm probably missing something
 352 2012-11-27 13:59:04 <slush1> there's also nothing like "Stratum (protocol) expects a 60 second window". Is that something related to your implementation?
 353 2012-11-27 13:59:30 <Luke-Jr> slush1: if the proxy sends work based on JobA immediately before I send JobB with clean_jobs=false, and the miner can process that work for 60 seconds, I need to guarantee JobA remains valid for 60 seconds
 354 2012-11-27 13:59:46 <Luke-Jr> slush1: that's a protocol rule you implied with how you described the proxy behaviour to me :p
 355 2012-11-27 14:00:39 <slush1> well, but this is not a part of stratum, it is part of getwork and proxy don't enforce that; it simply depends on >getwork< miners how they implement it.
 356 2012-11-27 14:00:56 <Luke-Jr> getwork has a specification
 357 2012-11-27 14:01:10 <slush1> simply said, you can safely drop old jobs when you send out clean_jobs=True
 358 2012-11-27 14:01:15 <slush1> as I'm doing it
 359 2012-11-27 14:01:26 <Luke-Jr> that doesn't explain when to drop them with clean_jobs=false
 360 2012-11-27 14:01:43 <slush1> there's not any limitation in this case
 361 2012-11-27 14:01:51 <slush1> as miner can still submit old jobs
 362 2012-11-27 14:01:52 <Luke-Jr> there must be, or stratum is useless
 363 2012-11-27 14:01:55 <slush1> why?
 364 2012-11-27 14:02:12 <Luke-Jr> because jobs cannot remain valid forever, and sending clean_jobs=true for every job is wasteful
 365 2012-11-27 14:02:24 <slush1> it is not valid forever
 366 2012-11-27 14:02:29 <slush1> it is valid until next clean_jobs
 367 2012-11-27 14:02:33 <Luke-Jr> that's potentially forever
 368 2012-11-27 14:02:37 <slush1> I'm not saying anywhere you must say clean_jobs with every job
 369 2012-11-27 14:02:40 <slush1> potentially not
 370 2012-11-27 14:02:49 <Luke-Jr> I cannot allow jobs to remain valid longer than 2 minutes period.
 371 2012-11-27 14:02:54 <slush1> why?
 372 2012-11-27 14:02:59 <Luke-Jr> the generation would be stale
 373 2012-11-27 14:03:14 TD has joined
 374 2012-11-27 14:03:19 <slush1> Can you elaborate?
 375 2012-11-27 14:03:24 <slush1> Is that part of bitcoin specs?
 376 2012-11-27 14:03:29 <Luke-Jr> the payouts in the coinbase would no longer be the correct ones
 377 2012-11-27 14:03:35 <Luke-Jr> miners would get overpaid
 378 2012-11-27 14:03:39 <slush1> oh
 379 2012-11-27 14:03:45 <slush1> then you must send clean_jobs every few minutes
 380 2012-11-27 14:03:54 <Luke-Jr> that is stupid
 381 2012-11-27 14:04:05 <slush1> well, your requiest is pretty special :-)
 382 2012-11-27 14:04:13 <Luke-Jr> no, it's really not
 383 2012-11-27 14:04:16 <slush1> so you can expect that two minutes are fine
 384 2012-11-27 14:04:35 <slush1> although I don't see _any_ reason why dropping jobs after two minutes should give you any issue
 385 2012-11-27 14:04:36 <Luke-Jr> clean_jobs is going to invalidate the previous work in addition to the one 2 minutes ago
 386 2012-11-27 14:04:56 <Luke-Jr> losing shares
 387 2012-11-27 14:05:37 <slush1> yes. So just drop old jobs. There's no technical reason why miners should submit such old jobs
 388 2012-11-27 14:05:44 <Luke-Jr> your attempt to oversimplify things seems to make it only usable for a few use cases
 389 2012-11-27 14:05:56 <slush1> you mean - for mining? ;)
 390 2012-11-27 14:05:58 <Luke-Jr> how can I drop the job from 2 minutes ago without dropping the one from 1 minute ago?
 391 2012-11-27 14:06:24 <Luke-Jr> I mean, it only works for your pool and those sufficiently similar to it
 392 2012-11-27 14:06:26 <slush1> luke-jr as you're doing now; just drop the job on pool, so older submits won't be accepted
 393 2012-11-27 14:06:34 <slush1> that's what you basically need
 394 2012-11-27 14:06:43 <Luke-Jr> but stratum says I have to accept it
 395 2012-11-27 14:06:45 <Luke-Jr> ?
 396 2012-11-27 14:06:50 Amit_btc has quit (Ping timeout: 245 seconds)
 397 2012-11-27 14:07:08 <slush1> well, stratum also says "miners should use latest jobs"
 398 2012-11-27 14:07:20 <slush1> so this is no brainer for me. Drop old jobs. problem solved
 399 2012-11-27 14:07:23 <Luke-Jr> ok
 400 2012-11-27 14:07:53 <Luke-Jr> if you add an explicit "old jobs are invalid after 60 seconds in any case" that would make it clearest :P
 401 2012-11-27 14:09:23 <slush1> what if pool wants to broadcast jobs in longer timeframes then? ;-)
 402 2012-11-27 14:09:43 <slush1> There's really no need for hardcoded timeouts. Stating "miners should use latest jobs" is good enough
 403 2012-11-27 14:09:49 <Luke-Jr> then it just needs to delay the expiration 60 seconds longer than that timeframe?
 404 2012-11-27 14:09:55 <slush1> and if miner code is broken, no additional specification will fix it
 405 2012-11-27 14:10:11 bitcoinbulletin has quit (Ping timeout: 246 seconds)
 406 2012-11-27 14:10:15 <Luke-Jr> well, unless the proxy LPs for every job, the miner won't be usign the latest job in that case technically
 407 2012-11-27 14:10:29 <Luke-Jr> … unless you're not enabling rollntime
 408 2012-11-27 14:10:52 <slush1> well, we both know that getwork miners are going to die
 409 2012-11-27 14:11:04 <Luke-Jr> hopefully stratum miners too
 410 2012-11-27 14:11:06 * Luke-Jr ducks, jk
 411 2012-11-27 14:11:07 <slush1> lol
 412 2012-11-27 14:11:28 <slush1> in some future versions of proxy, I can add additional LP broadcasts, which will enforce miners to use latest job
 413 2012-11-27 14:11:31 <slush1> if it will be an issue
 414 2012-11-27 14:11:49 <Luke-Jr> no, I'm good with current behaviour now that it's clear
 415 2012-11-27 14:11:55 <Luke-Jr> also, LPs will break cgminer
 416 2012-11-27 14:12:07 <Luke-Jr> *sigh*
 417 2012-11-27 14:12:55 bitcoinbulletin has joined
 418 2012-11-27 14:13:10 <Luke-Jr> actually, if I were you, I'd personally LP on every new job just to force miners to fix their LP handling :D
 419 2012-11-27 14:13:11 <slush1> that's hidden cost of overoptimized C code
 420 2012-11-27 14:14:58 <slush1> I have one guy on pool, he has around 10% of stales at ~30 GHash/s. I sent him an email, he responded he's aware of it, but he doesn't care. So I think that enforcing LP and breaking miners will only result in lower pool hashrate :-)
 421 2012-11-27 14:15:50 vampireb has joined
 422 2012-11-27 14:16:06 <Luke-Jr> I saw at least one miner that submits every share twice to guarantee it got through -.-
 423 2012-11-27 14:16:08 <Luke-Jr> even when it gets a valid reply
 424 2012-11-27 14:17:23 <kinlo> wasn't that diablo's miner?
 425 2012-11-27 14:17:54 <Luke-Jr> IIRC bitfury
 426 2012-11-27 14:31:25 agricocb has joined
 427 2012-11-27 14:35:05 random_cat has quit (Remote host closed the connection)
 428 2012-11-27 14:35:31 vampireb has quit (Quit: Lost terminal)
 429 2012-11-27 14:38:01 random_cat has joined
 430 2012-11-27 14:38:32 TD has quit (Quit: TD)
 431 2012-11-27 14:41:22 abrkn has joined
 432 2012-11-27 14:47:46 <BlueMatt> Luke-Jr: it doesnt (yet) make blocks, but if you want to use it to check blocks, yes, I would recommend it
 433 2012-11-27 14:48:05 <BlueMatt> (ofc if every other node accepts a given block but only it rejects it, ignore it, but...)
 434 2012-11-27 14:48:11 <Luke-Jr> BlueMatt: does it support BIP 23 Proposals yet?
 435 2012-11-27 14:48:32 <BlueMatt> no
 436 2012-11-27 14:48:44 <BlueMatt> it doesnt support mining (do any non bitcoind clients?)
 437 2012-11-27 14:49:57 <BlueMatt> Luke-Jr: a good miner should check blocks that are being created by multiple clients, not necessarily make them with multiple clients (only one client can atm, no?)
 438 2012-11-27 14:50:21 denisx has joined
 439 2012-11-27 14:50:32 <sipa> BlueMatt: BIP23 proposal == send a block for verification to a node, skipping PoW check
 440 2012-11-27 14:51:04 <BlueMatt> mmm, well maybe I should read more than the title+abstract next time then...
 441 2012-11-27 14:51:26 <BlueMatt> Luke-Jr: anyway, it may be a while before bitcoinj handles anything like that (its a library, not a json-rpc server)
 442 2012-11-27 14:58:18 <gavinandresen> gotta love kitchen-sink international standards:  http://www.edifactory.de/msglist.D05A?m=INVOIC
 443 2012-11-27 15:01:36 torsthaldo has joined
 444 2012-11-27 15:04:07 <sipa> ha, "Dangerous goods"
 445 2012-11-27 15:06:23 <helo> Jouke: commented
 446 2012-11-27 15:08:07 Detritus has quit (Ping timeout: 246 seconds)
 447 2012-11-27 15:12:49 <BlueMatt> gavinandresen: heh, lets implement the whole thing in bitcoin!
 448 2012-11-27 15:14:35 edcba_ is now known as edcba
 449 2012-11-27 15:23:56 Detritus has joined
 450 2012-11-27 15:31:20 slush1 has quit (Ping timeout: 256 seconds)
 451 2012-11-27 15:36:29 unknown45682 has quit (2!~unknown45@pool-98-109-226-74.nwrknj.east.verizon.net|Read error: Connection reset by peer)
 452 2012-11-27 15:37:08 unknown45682 has joined
 453 2012-11-27 15:37:18 <sipa> BlueMatt: surely transactions require a "Dangerous goods" flag!
 454 2012-11-27 15:37:39 unknown45682 has quit (2!~unknown45@pool-98-109-226-74.nwrknj.east.verizon.net|Client Quit)
 455 2012-11-27 15:38:13 <BlueMatt> sipa: ofc, that and the option for any one of a million other flags.  I mean why add arbitrary text when you can just have a huge set of bits for any possible use?
 456 2012-11-27 15:40:58 <phantomcircuit> BlueMatt, perfectly logical
 457 2012-11-27 15:42:35 <phantomcircuit> also the node at metaexch.com:8333 is running git master hardened against sybil attack
 458 2012-11-27 15:42:54 <BlueMatt> wat?
 459 2012-11-27 15:43:17 <BlueMatt> so...they properly use addnode?
 460 2012-11-27 15:43:19 <phantomcircuit> BlueMatt, it's hard to fill all of it's connection slots
 461 2012-11-27 15:43:27 <BlueMatt> so...they properly use addnode?
 462 2012-11-27 15:43:50 <phantomcircuit> addnode isn't going to help against what im trying to prevent :|
 463 2012-11-27 15:44:24 BitDev has joined
 464 2012-11-27 15:44:28 <BitDev> hi all
 465 2012-11-27 15:44:36 <BitDev> its me again :)
 466 2012-11-27 15:44:38 <BlueMatt> addnode makes a connection even when you fill the node's connection slots, so its not an attack against an individual
 467 2012-11-27 15:44:53 <BlueMatt> though Im assuming you are still on about filling the connection slots of every node on the network
 468 2012-11-27 15:45:03 <phantomcircuit> yup
 469 2012-11-27 15:45:29 <phantomcircuit> it would be a lot easier to do than i previously calculated
 470 2012-11-27 15:45:44 <BitDev> and i have new question, if my software receive inv message - is all block hashes come like in branch?
 471 2012-11-27 15:46:06 <BlueMatt> yea...have fun, even given unlimited bw, there is enough turn over all you would accomplish (for the most part) is make connections take a while and maybe sybil some unimportant nodes (which is why merchants, etc should be using addnode properly...)
 472 2012-11-27 15:46:17 <BitDev> or its random position and i must myself put in right position of branch?
 473 2012-11-27 15:46:35 <phantomcircuit> BlueMatt, that's the thing
 474 2012-11-27 15:46:47 <phantomcircuit> those unimportant people would be anybody new pretty much
 475 2012-11-27 15:46:55 <BitDev> sipa help me please again
 476 2012-11-27 15:47:06 <BlueMatt> phantomcircuit: uhh...no
 477 2012-11-27 15:47:07 <BitDev> i can find answer of this
 478 2012-11-27 15:47:16 <BlueMatt> phantomcircuit: unless you can magically be the only node on the dnsseeds
 479 2012-11-27 15:47:42 <phantomcircuit> BlueMatt, uh i could be the only connectable node right now
 480 2012-11-27 15:47:44 <gmaxwell> BlueMatt: uh, he can and thats irrelevant.
 481 2012-11-27 15:47:55 <BitDev> can anyone help me?
 482 2012-11-27 15:48:07 <gmaxwell> BitDev: you need to ask a better question.
 483 2012-11-27 15:48:30 <BlueMatt> phantomcircuit: again, there is enough turnover that I doubt you could be successfully the only one, though obv you could be one of a few
 484 2012-11-27 15:48:32 <BitDev> i receive inv packet - there are hashes
 485 2012-11-27 15:48:55 <BlueMatt> gmaxwell: Im assuming you are just agreeing with his only connectable node thing, or is there some other magic he can do?
 486 2012-11-27 15:49:04 <BitDev> i just wander if hashes are in order or its position is random
 487 2012-11-27 15:49:07 <phantomcircuit> BlueMatt, i'm (very) sure that i could be the only one that is available for the majority of the time
 488 2012-11-27 15:49:43 <BlueMatt> (I also assume you mean the only 8/9 available, because you would need that, not just one)
 489 2012-11-27 15:49:47 <BlueMatt> (well, 8/9 ips)
 490 2012-11-27 15:50:00 <BitDev> if i just connected and have no hashes - i send genesis hash by getheaders packet and i receive inv packet
 491 2012-11-27 15:50:05 <phantomcircuit> yeah i was about to say it would be trivial to have 8 ip's in different groups
 492 2012-11-27 15:50:24 <BitDev> this mean that all hashes in packet goes 1,2,3,4,5,6,... or can be 1,4.2,3,5,6... ?
 493 2012-11-27 15:50:26 <BlueMatt> phantomcircuit: you could probably get close, but Im not so sure there wouldnt be enough turnover to keep quite a few nodes connected
 494 2012-11-27 15:50:37 <phantomcircuit> although practically it would require more just because those 8 nodes would get absolutely hammered
 495 2012-11-27 15:50:39 <BlueMatt> but, yea, "important" nodes should be using addnode
 496 2012-11-27 15:50:42 <BitDev> now you understand my question?
 497 2012-11-27 15:51:01 <BlueMatt> phantomcircuit: ofc
 498 2012-11-27 15:51:56 <BlueMatt> also, bitcoin backbond
 499 2012-11-27 15:51:57 <BlueMatt> e
 500 2012-11-27 15:52:25 <phantomcircuit> BlueMatt, i doubt a practical doublespend could be pulled off simply because correlating node with service isn't really that easy
 501 2012-11-27 15:52:44 <phantomcircuit> however if you were just intent on breaking things...
 502 2012-11-27 15:52:50 <gmaxwell> BlueMatt: he can fill up slots on all the public nodes he can find... but that doesn't harm nodes that have private addnode peering.
 503 2012-11-27 15:53:02 <BlueMatt> gmaxwell: ok, so yes you are just agreeing
 504 2012-11-27 15:53:05 <BitDev> some one knows the answer?
 505 2012-11-27 15:53:20 <gmaxwell> BlueMatt: well disagreeing that he couldn't be the only connectable dns seed.
 506 2012-11-27 15:53:25 <phantomcircuit> i think the disagreement here is about the impact
 507 2012-11-27 15:53:47 <phantomcircuit> gmaxwell, private addnode peering doesn't count as a connectable dns seed :)
 508 2012-11-27 15:53:58 w0mbat has quit (Quit: Leaving.)
 509 2012-11-27 15:54:01 <BlueMatt> phantomcircuit: oh, I have no doubt you could cause issues for many people, but, if "important" nodes are doing things right, impact should be (largely) low
 510 2012-11-27 15:54:11 <gmaxwell> BitDev: the inv is just telling you what is available. I don't think you can depend on it being in any particular order.
 511 2012-11-27 15:54:43 <BitDev> hm, then i must send getdata and check all thing all by myself?
 512 2012-11-27 15:54:52 <gmaxwell> phantomcircuit: It doesn't but bluematt said "maybe sybil some unimportant nodes (which is why merchants, etc should be using addnode properly...)" and I agree with that.
 513 2012-11-27 15:55:23 <BlueMatt> gmaxwell: my point is less that he couldnt be for a while, and more that there is quite a bit of turnover and I would think many nodes would be able to connect regardless
 514 2012-11-27 15:55:25 <phantomcircuit> gmaxwell, even with addnode eventually it's likely the slots would be taken by others
 515 2012-11-27 15:55:29 <gmaxwell> BitDev: if you dont a malicious node could just lie to you. You can't trust your peers not to lie.
 516 2012-11-27 15:55:36 <gmaxwell> phantomcircuit: only if they are public nodes.
 517 2012-11-27 15:56:01 <BlueMatt> phantomcircuit: if you addnode, it will accept a connection from an addnode peer even if your connection slots are full
 518 2012-11-27 15:56:05 <gmaxwell> BlueMatt: well there I don't agree. he can keep a node so stuffed full that he'll likely end up with all slots which he won't turnover.
 519 2012-11-27 15:56:05 <BlueMatt> (and will make them)
 520 2012-11-27 15:56:11 <BitDev> hm thats true
 521 2012-11-27 15:56:28 <BitDev> ok, thnx i will query data )
 522 2012-11-27 15:56:29 <BlueMatt> gmaxwell: no, my point is that new nodes come online quick enough he would lose some
 523 2012-11-27 15:57:01 <gmaxwell> BlueMatt: prior to dnsseed we had slow initial connectivity even absent an attack. I'm not convinced.
 524 2012-11-27 15:57:40 Bootstrapper has joined
 525 2012-11-27 15:58:25 <phantomcircuit> BlueMatt, that's actually very unlikely given that the attacker would be trying to connect far more rapidly than any "real" node
 526 2012-11-27 15:58:27 <phantomcircuit> bbl
 527 2012-11-27 15:59:16 <BlueMatt> phantomcircuit: an attacker is trying to connect more rapidly, yes, and you would shut out many nodes, but the total volume of connection attempts of non-attacker nodes vs the total volume of connection attempts from good nodes (I would think) is such that some good nodes would connect
 528 2012-11-27 15:59:25 <BlueMatt> not to say partitions wouldnt form quite rapidly
 529 2012-11-27 16:02:13 Bootstrapper has quit (Ping timeout: 240 seconds)
 530 2012-11-27 16:09:27 PiZZaMaN2K has joined
 531 2012-11-27 16:09:30 PiZZaMaN2K has quit (Client Quit)
 532 2012-11-27 16:14:54 <kjj> hmm.  I wish the keypool had configurable high and low water marks...
 533 2012-11-27 16:22:09 <gmaxwell> kjj: ... why?
 534 2012-11-27 16:22:37 <kjj> intelligent backup management.
 535 2012-11-27 16:23:53 <kjj> also, it would help a lot on the forums
 536 2012-11-27 16:24:03 <sipa> deterministic wallets would help more :)
 537 2012-11-27 16:25:45 <kjj> heh.  EC wallets have new and different backup problems
 538 2012-11-27 16:26:37 <sipa> you could do a "renew seed" action right before every backup
 539 2012-11-27 16:26:44 <sipa> if you don't like long-lived seeds
 540 2012-11-27 16:27:18 maaku has joined
 541 2012-11-27 16:28:04 <kjj> that just combines the problem sets of both systems
 542 2012-11-27 16:28:07 <gmaxwell> sipa: On that subject— I'm concerned that we need to have a boring determinstic wallet option in addition to the type-2 stuff simply because we haven't managed to wrangle serious cryptoanalytic review of the type-2 stuff yet.
 543 2012-11-27 16:29:10 <sipa> mhem
 544 2012-11-27 16:30:08 <sipa> gmaxwell: well, if you consider the public extended key secret, that's exactly what you get, no?
 545 2012-11-27 16:30:38 <sipa> the resulting secrets are HMAC -> split -> EC multiply
 546 2012-11-27 16:31:07 <sipa> that's an EC multiplication of two random (from the point of an attacker) unknown and random numbers
 547 2012-11-27 16:33:15 <sipa> oh, not EC multiply... just modP multiply
 548 2012-11-27 16:34:20 <gmaxwell> sipa: Right, I prefer that design because it is more conservative e.g. than what etotheipi had. And yes, _I_ have no idea how to attack it and don't even see a place to start because the multiply with a secret should effectively make the private keys 'unrelated'.  And if this were for _any_ other part of the system I'd be completely comfortable with our bit of seminovel cryptography.
 549 2012-11-27 16:36:03 <sipa> well, what would serious cryptoanalytic review mean? pay a cryptoanalist to try to break it?
 550 2012-11-27 16:36:11 <kjj> in BIP32, is there a reason to use fixed sizes for depth and child number instead of VI?
 551 2012-11-27 16:37:49 <sipa> the reason was that it needed to be limited anyway
 552 2012-11-27 16:37:56 <sipa> but i can't remember why
 553 2012-11-27 16:38:51 <gmaxwell> sipa: Well. Degrees of seriousness. Getting someone like DJB to at least _comment_ on it would be nice. As of right now I don't believe that anyone outside of this room who understands this stuff has seen it, except maybe bytecoin.
 554 2012-11-27 16:39:10 <sipa> bytecoin has seen it, yes
 555 2012-11-27 16:39:28 <sipa> he just made some comments on the formulation of the document
 556 2012-11-27 16:39:36 <sipa> ha, DJB would be nice indeed :)
 557 2012-11-27 16:40:44 <gmaxwell> I feel vaguely confident that nothing anyone would raise would be a reason not to use it in cases where its a big win (e.g. the webserver case), but I expect most usage won't be doing that and could use an alternative formulation where the private keys were just straight hmac output.
 558 2012-11-27 16:40:48 <kjj> sipa: ok, I'll take your word for it, but I don't see any place where either of them need an obvious limit, nor any place where the representation matters
 559 2012-11-27 16:41:55 <sipa> gmaxwell: well, we could decide not to expose an interface for importing extended public key chains initially
 560 2012-11-27 16:42:11 <sipa> gmaxwell: if there is no way to export them either, it's clearly experimental
 561 2012-11-27 16:43:10 <BlueMatt> the jenkins vm is getting kinda lonely...anyone core devs wanna sign up to manage an https download server/testnet node/etc?
 562 2012-11-27 16:43:58 <sipa> gmaxwell: i somehow prefer not to have two standards, especially if at least a restricted form of one is safe
 563 2012-11-27 16:44:07 <gmaxwell> Yea.... :(
 564 2012-11-27 16:44:35 <gmaxwell> Well an alternative would be to deploy hd-wallet determinstic support but continue using non-determinstic by default.
 565 2012-11-27 16:45:25 <sipa> gmaxwell: how about trying to get dan kaminsky to look at it?
 566 2012-11-27 16:45:44 <sipa> he's commented on bitcoin before
 567 2012-11-27 16:46:00 <BlueMatt> is he a cryptographer or just a security researcher?
 568 2012-11-27 16:46:12 <sipa> good point, i'm not sure
 569 2012-11-27 16:46:18 <gmaxwell> I think his commentary would be more useful on the Bip32 structure than on the underlying cryptographic construct.
 570 2012-11-27 16:47:16 tonikt has joined
 571 2012-11-27 16:48:24 <sipa> gmaxwell: given the fact that parent-extended-pubkey + child-privkey is enough to derive parent-extended-privkey, i think extended pubkeys should in any case be considered secret to a certain degree
 572 2012-11-27 16:48:29 denisx_ has joined
 573 2012-11-27 16:48:49 denisx has quit (Ping timeout: 264 seconds)
 574 2012-11-27 16:48:50 denisx_ is now known as denisx
 575 2012-11-27 16:49:02 Bootstrapper has joined
 576 2012-11-27 16:50:32 slush1 has joined
 577 2012-11-27 16:52:44 <phantomcircuit> kjj, personally i specify a very large keypool once and wait for all the new keypairs to be generated
 578 2012-11-27 16:53:01 <phantomcircuit> from there on i run usign the normal keypool size
 579 2012-11-27 16:53:18 <sipa> don't share them at all, and you get a traditional derivation scheme (i'm very sure that multiplying two numbers about which nothing is known mod p, will give a number about which nothing is known)
 580 2012-11-27 16:53:39 <sipa> unless one is 0, of course
 581 2012-11-27 16:53:42 <phantomcircuit> the once huge value will however cause the keypool to remain ballooned and since the keypool parameter is smaller it will slowly deplete
 582 2012-11-27 16:53:56 <phantomcircuit> as long as you backup before the pool starts to refill
 583 2012-11-27 16:54:07 <phantomcircuit> you always have a good backup
 584 2012-11-27 16:54:42 <kjj> phantomcircuit: yeah, that's what I'm suggesting should be the default behavior, rather than a silly trick that you have to understand and perform yourself
 585 2012-11-27 16:54:51 <gmaxwell> sipa: they aren't _strictly_ nothing is known, as you do sign with them.
 586 2012-11-27 16:55:01 <phantomcircuit> kjj, true
 587 2012-11-27 16:55:12 <phantomcircuit> kjj, how would you implement that though?
 588 2012-11-27 16:55:23 <sipa> gmaxwell: that's a good p9oint
 589 2012-11-27 16:55:27 <sipa> gmaxwell: i didn't consider that
 590 2012-11-27 16:55:42 <phantomcircuit> the problem is that something like this requires a way for there to be a signal to backup the wallet.dat again
 591 2012-11-27 16:55:44 <sipa> i doubt it changes anything, but i wouldn't bet my life on it
 592 2012-11-27 16:55:58 <phantomcircuit> i do it using polling of the getinfo api call but that's not something most users can do
 593 2012-11-27 16:56:21 <kjj> phantomcircuit: start spewing warnings at the low water mark, and have backupwallet refill the pool just before the backup
 594 2012-11-27 16:56:57 da2ce7_d has joined
 595 2012-11-27 16:57:09 <gmaxwell> sipa: right— obviously I think this construct is secure. But I do not have a proof of it nor do I have the number theory chops to attempt one.  In the case that no one ever sees the signatures there is a someone intutive explination that it is secure but that one doesn't hold under signatures.
 596 2012-11-27 16:57:30 daybyter has joined
 597 2012-11-27 16:57:45 <phantomcircuit> kjj, ah so instead of refilling the pool automatically only do it when a backup is generated
 598 2012-11-27 16:57:58 <gmaxwell> And I can give you an example where it fails too... a child key signs using an insecure nonce, and you can then shimmy up the chain and get other private keys.
 599 2012-11-27 16:58:01 <phantomcircuit> that's actually a very good way to do it (optionally of course)
 600 2012-11-27 16:58:04 <kjj> right.
 601 2012-11-27 16:58:37 <phantomcircuit> i have no idea how you'd make that work in the ui but in the bitcoind i believe it would be (relatively) easy to change
 602 2012-11-27 16:58:38 <kjj> I would even have the wallet start with NO keys, and require the first backupwallet command to fill it.  but that would be more work
 603 2012-11-27 16:59:09 da2ce7 has quit (Ping timeout: 255 seconds)
 604 2012-11-27 16:59:11 <kjj> yeah, I don't mess with the UI at all.  no idea how to handle it there
 605 2012-11-27 16:59:23 t7 has quit (Quit: ChatZilla 0.9.89-rdmsoft [XULRunner 1.9.0.17/2009122204])
 606 2012-11-27 17:01:12 graingert has joined
 607 2012-11-27 17:04:45 <abrkn> hmm when i try this one https://launchpad.net/~bitcoin/+archive/bitcoin it installs 0.6 when using apt-get. is there any issue with the priority of my sources?
 608 2012-11-27 17:05:23 BitDev has quit (Quit: Page closed)
 609 2012-11-27 17:05:58 <sipa> BlueMatt: wasn't there a plan to put a crawler/dnsseed of some kind on the server?
 610 2012-11-27 17:06:32 <BlueMatt> sipa: yea, that was another idea
 611 2012-11-27 17:06:38 <BlueMatt> sipa: wanna run it?
 612 2012-11-27 17:08:53 maaku_ has joined
 613 2012-11-27 17:09:10 maaku has quit (Read error: Connection reset by peer)
 614 2012-11-27 17:09:10 maaku_ is now known as maaku
 615 2012-11-27 17:10:03 <sipa> BlueMatt: i suppose
 616 2012-11-27 17:10:34 slush1 has quit (Ping timeout: 250 seconds)
 617 2012-11-27 17:10:51 <BlueMatt> sipa: os of choice?
 618 2012-11-27 17:11:57 <sipa> something debian or ubuntu based?
 619 2012-11-27 17:12:06 <BlueMatt> debian it is
 620 2012-11-27 17:12:26 <phantomcircuit> http://imgur.com/gallery/t8D7l
 621 2012-11-27 17:12:27 <phantomcircuit> hahah
 622 2012-11-27 17:12:47 pusle has joined
 623 2012-11-27 17:12:51 <abrkn> oh jesus fuck now i have to download the chain again :(
 624 2012-11-27 17:12:58 <abrkn> 48h+ last time
 625 2012-11-27 17:13:03 <sipa> abrkn: why?
 626 2012-11-27 17:13:21 <abrkn> sipa: didnt like my index going from 0.6 to 0.7.1
 627 2012-11-27 17:13:48 <abrkn> sipa: well, it's going pretty fast, maybe it's using the blkindex files i copied in
 628 2012-11-27 17:14:03 <sipa> no, it will not
 629 2012-11-27 17:14:04 <abrkn> err, the blk000.dat files
 630 2012-11-27 17:14:10 <sipa> it will just append to them
 631 2012-11-27 17:14:15 <sipa> and you'll use twice as much storage
 632 2012-11-27 17:14:31 <abrkn> ok, because im getting like 1k/sec now
 633 2012-11-27 17:14:47 <sipa> the first 130k blocks are very fast
 634 2012-11-27 17:14:54 <Eliel> abrkn: if you have lots of RAM, you could setup a ramdisk and keep blkindex.dat on the ramdisk until done and then copy it to the hdd.
 635 2012-11-27 17:15:09 <abrkn> ok, so i should stop bitcoind, remove the blk files, start over?
 636 2012-11-27 17:15:31 <Eliel> abrkn: that'd be a good idea IMO.
 637 2012-11-27 17:15:49 <sipa> abrkn: you should put those blk files somewhere else, clear the actual datadir, and run with -loadblock=/path/to/blk0001.dat -loadblock=/path/to/blk0002.dat
 638 2012-11-27 17:16:00 <sipa> that will import them from disk instead of from network
 639 2012-11-27 17:17:41 <gmaxwell> note that you _must_ heed the "somewhere else" above if you go that way.
 640 2012-11-27 17:18:09 <abrkn> ok, doing as you said now
 641 2012-11-27 17:19:02 <weex> for some reason, this minimal python address generator of mine/Joric's creates invalid compressed privkeys
 642 2012-11-27 17:19:20 <Eliel> by the way, why does the client ignore the earlier contents of blk0*.dat if blkindex.dat is missing and they're not empty or nonexistent?
 643 2012-11-27 17:19:27 <weex> i've been trying to compare what it does vs. bitcoin and that's quite a task
 644 2012-11-27 17:19:42 <kjj> Eliel: it's complicated
 645 2012-11-27 17:20:16 <kjj> weex: invalid in what way?  is it just calculating the parity wrong?
 646 2012-11-27 17:20:18 <sipa> Eliel: its write policy is "new blocks are appended", and without blkindex.dat, it doesn't know about any block, so every block is new
 647 2012-11-27 17:20:33 <weex> bitaddress.org says it's invalid and so does bitcoind
 648 2012-11-27 17:20:40 <weex> https://github.com/weex/addrgen/blob/master/addrgen.py is where the code is
 649 2012-11-27 17:20:44 <sipa> Eliel: 0.8 will work differently (it stores which part of the file is still available in the index)
 650 2012-11-27 17:20:55 <weex> i had it using compressed by default too (yikes but uncompressed seems valid)
 651 2012-11-27 17:22:56 <sipa> Eliel: also 0.8 will have -reindex, which is like -loadblock, but uses the existing block files and reindexes and validates them in-place
 652 2012-11-27 17:23:02 <kjj> ugh.  python, and a just a wrapper for ssl libs
 653 2012-11-27 17:23:27 <Eliel> sipa: will it trigger -reindex if the indexes go missing in 0.8?
 654 2012-11-27 17:24:42 <sipa> Eliel: i think it's safe logic to have: if (block_files_present && !block_index_present) { reindex=1 }
 655 2012-11-27 17:25:34 skeledrew has quit (Ping timeout: 245 seconds)
 656 2012-11-27 17:26:34 <Eliel> sipa: will it start in a lightweight client mode?
 657 2012-11-27 17:26:57 <kjj> weex: I found the bug.  line 151, should be:  payload = secret + chr(1)
 658 2012-11-27 17:27:08 <sipa> Eliel: no
 659 2012-11-27 17:27:24 <weex> k lemme try
 660 2012-11-27 17:27:38 <sipa> what was the line?
 661 2012-11-27 17:28:00 <kjj> they are adding 0x00 as the flag for a compressed key, should be 0x01
 662 2012-11-27 17:28:48 <sipa> ha
 663 2012-11-27 17:28:50 <weex> kjj, nice! now out of curiosity should it be possible to take a private key generated the old way and turn it into a correct one?
 664 2012-11-27 17:29:05 <kjj> weex: sure
 665 2012-11-27 17:29:33 <kjj> decode back to the secret, attach the correct flag, re-encode
 666 2012-11-27 17:31:13 <weex> ok i'll see if i can do that
 667 2012-11-27 17:33:51 sgstair has quit (Read error: Connection reset by peer)
 668 2012-11-27 17:34:06 <kjj> I didn't look closely at your decode function, so I don't know if it is right or not.  but at the very least, it appears to just return all of the data, including the incorrect compression flag
 669 2012-11-27 17:34:12 sgstair has joined
 670 2012-11-27 17:36:34 joepie92 is now known as joepie91
 671 2012-11-27 17:36:49 joepie91 has quit (Changing host)
 672 2012-11-27 17:36:50 joepie91 has joined
 673 2012-11-27 17:37:56 JZavala has joined
 674 2012-11-27 17:39:46 paraipan has joined
 675 2012-11-27 17:40:33 skeledrew has joined
 676 2012-11-27 17:40:35 x18882 has joined
 677 2012-11-27 17:44:04 pusle has quit (Remote host closed the connection)
 678 2012-11-27 17:44:50 skeledrew has quit (Ping timeout: 245 seconds)
 679 2012-11-27 17:45:08 skeledrew has joined
 680 2012-11-27 17:48:21 TD has joined
 681 2012-11-27 17:54:19 <helo> when blocks start filling up consistently, what will happen to all of the transactions that can't make it into blocks for extended periods of time?
 682 2012-11-27 17:54:25 <helo> will they just keep accumulating?
 683 2012-11-27 17:54:54 iddo has quit (Ping timeout: 244 seconds)
 684 2012-11-27 17:58:12 <kjj> we'll probably have the client recognize those and pop up a warning, asking the user if he wants the node to keep re-transmitting it, or if he wants to let it fall out of the network's collective memory pool
 685 2012-11-27 17:58:29 iddo has joined
 686 2012-11-27 17:58:52 molecular has quit (Read error: Operation timed out)
 687 2012-11-27 17:59:43 molecular has joined
 688 2012-11-27 18:03:02 <weex> thanks kjj, looks like the re-encoding is working
 689 2012-11-27 18:03:17 <phantomcircuit> at somepoint you want to doublespend yourself basically with a larger txfee to overrule the previous one
 690 2012-11-27 18:03:35 <phantomcircuit> but iirc the current memory pool wont evict a confirmed tx in favor of one with a larger txfee will it?
 691 2012-11-27 18:06:47 RBecker has quit (Quit: You care. You're there for me.  You love me so much, and I never want to let it go.  You are the one truly amazing person. MDR 3/6/11 <3)
 692 2012-11-27 18:06:56 <sipa> phantomcircuit: no
 693 2012-11-27 18:07:18 <phantomcircuit> sipa, sorry is that yes it will evict or no it wont evict
 694 2012-11-27 18:07:25 <sipa> phantomcircuit: it will not evict
 695 2012-11-27 18:07:43 <phantomcircuit> yeah so you have to find a miner who is willing to replace your previous transaction with a new one
 696 2012-11-27 18:07:54 <phantomcircuit> or to mine if
 697 2012-11-27 18:07:56 <phantomcircuit> it*
 698 2012-11-27 18:07:58 <phantomcircuit> the old one
 699 2012-11-27 18:07:58 <sipa> phantomcircuit: even if tx replacement would be re-enabled, the txins need to remain the same
 700 2012-11-27 18:08:11 <sipa> so the only way to do it would be to reduce the change to yourself
 701 2012-11-27 18:08:22 RBecker has joined
 702 2012-11-27 18:08:41 <helo> to keep it from being useful for double-spending?
 703 2012-11-27 18:09:08 <sipa> i believe that's the idea yes - once in the collective network's memory pool, double spending is prevented
 704 2012-11-27 18:09:49 daybyter has quit (Quit: Konversation terminated!)
 705 2012-11-27 18:14:07 RBecker has quit (Ping timeout: 260 seconds)
 706 2012-11-27 18:14:41 BlueMattBot has quit (Remote host closed the connection)
 707 2012-11-27 18:15:08 x18882 has quit (Quit: Yo!)
 708 2012-11-27 18:15:38 BlueMattBot has joined
 709 2012-11-27 18:15:38 BlueMattBot has quit (Changing host)
 710 2012-11-27 18:15:38 BlueMattBot has joined
 711 2012-11-27 18:16:14 BlueMattBot has quit (Remote host closed the connection)
 712 2012-11-27 18:17:23 BlueMattBot has joined
 713 2012-11-27 18:17:23 BlueMattBot has quit (Changing host)
 714 2012-11-27 18:17:23 BlueMattBot has joined
 715 2012-11-27 18:20:15 RBecker has joined
 716 2012-11-27 18:24:09 maaku has quit (Quit: maaku)
 717 2012-11-27 18:24:48 maaku has joined
 718 2012-11-27 18:27:51 unknown45682 has joined
 719 2012-11-27 18:28:52 JZavala has quit (Ping timeout: 240 seconds)
 720 2012-11-27 18:29:40 unknown45682 has quit (Client Quit)
 721 2012-11-27 18:30:03 unknown45682 has joined
 722 2012-11-27 18:33:35 <BlueMatt> well...I was gonna comment a bit on the payment protocol stuff...now it turned into a thread 41 emails deep...now there is no way Im gonna read through that many emails and respond...
 723 2012-11-27 18:34:33 TD has quit (Quit: TD)
 724 2012-11-27 18:35:48 <jgarzik> BlueMatt: most of the recent stuff is rather off-track
 725 2012-11-27 18:37:44 <kjj> sipa: but old unconfirmed transactions are eventually forgotten if the originating node stops sending them.
 726 2012-11-27 18:38:05 <sipa> kjj: yes, but in an unpredictable fashion
 727 2012-11-27 18:38:43 <kjj> agreed.  and there probably isn't much desire to make it more predictable
 728 2012-11-27 18:38:55 _sgstair has joined
 729 2012-11-27 18:38:56 sgstair has quit (Disconnected by services)
 730 2012-11-27 18:38:56 _sgstair is now known as sgstair
 731 2012-11-27 18:40:10 <kjj> but after 2 weeks, or whatever, we *could* have the local node forget the old transaction, and make a new one sending all back to the change address, allowing them to (eventually) be reclaimed
 732 2012-11-27 18:40:54 <kjj> might not be a bad idea to do that now, actually.  but it won't be a big deal until the block max is hit most of the time
 733 2012-11-27 18:42:29 <kjj> Right now, the solution to "Help, I have a transaction that hasn't confirmed for a month" is to attack your wallet.dat with a hex editor, which is, erm, other than ideal.
 734 2012-11-27 18:42:45 maaku has quit (Ping timeout: 245 seconds)
 735 2012-11-27 18:52:18 <abrkn> is this a reasonable way to keep track of btc sent to own addresses by using bitcoind? https://gist.github.com/4156125
 736 2012-11-27 18:52:33 <gavinandresen> BlueMatt: feel free to comment on payment protocol stuff here. Most of the thread is "We don't like SSL/X.509 certificates, so {let's not bother / let's wait for something better / let's use something 0.0001% of the Internet world uses}"
 737 2012-11-27 18:58:29 <phantomcircuit> gavinandresen, the basic concept is to piggy back on the existing certificates infrastructure right?
 738 2012-11-27 18:58:49 <gavinandresen> phantomcircuit: yes.
 739 2012-11-27 18:59:19 <BlueMatt> I actually find the use x509 pki solution to be quite an elegant solution to the problems we face (not that I like pki, as with all other sane people, I think it has serious problems)
 740 2012-11-27 19:00:11 <kjj> I find protocol buffers to be more objectionable than SSL
 741 2012-11-27 19:00:32 <gavinandresen> good, something in it for EVERYBODY to hate.
 742 2012-11-27 19:00:35 <kjj> heh
 743 2012-11-27 19:00:36 <phantomcircuit> protobuf is a very efficiently packed encoding
 744 2012-11-27 19:00:49 <kjj> I found the segment on "why PB" to be less than convincing.
 745 2012-11-27 19:00:57 <BlueMatt> kjj: and you suggest...?
 746 2012-11-27 19:00:57 <phantomcircuit> that being said im not really sure the libraries have been extensively tested for security issues
 747 2012-11-27 19:00:59 <kjj> phantomcircuit: yes.  ANOTHER efficient packed encoding
 748 2012-11-27 19:01:33 <gavinandresen> kjj: you read the JOSE specs? Or do you have some other favorite binary encoding?  (don't say XML or we'll lynch you)
 749 2012-11-27 19:01:33 <kjj> BlueMatt:  I would do JSON.  I didn't find the reasons stated for not using JSON to be unconvincing
 750 2012-11-27 19:02:01 <phantomcircuit> json is hopelessly inefficient for something like this :|
 751 2012-11-27 19:02:03 <drizztbsd> no, json is overrated
 752 2012-11-27 19:02:07 <gavinandresen> phantomcircuit: I asked TD about protocol buffers and security, and he assures me they're solid.
 753 2012-11-27 19:02:17 <drizztbsd> also yaml is better
 754 2012-11-27 19:02:19 <gavinandresen> (if they weren't, Google would have major problems)
 755 2012-11-27 19:02:23 <phantomcircuit> gavinandresen, k
 756 2012-11-27 19:02:43 <phantomcircuit> i wasn't aware google had any exposed api's using protobuf
 757 2012-11-27 19:02:51 maaku has joined
 758 2012-11-27 19:02:53 <BlueMatt> kjj: if nothing else, the section on why not json is pretty convincing that a binary format is better
 759 2012-11-27 19:03:04 pusle has joined
 760 2012-11-27 19:03:11 <phantomcircuit> i got the opposite impression when i was looking at them, but it was just an impression
 761 2012-11-27 19:03:15 <kjj> BlueMatt:  I read it, but was unconvinced
 762 2012-11-27 19:04:03 <BlueMatt> kjj: in any case, stating that we should use JSON without making an argument (aside from we already use it) when there is an argument against json doesnt do much in the way of convincing anyway
 763 2012-11-27 19:04:04 <kjj> first of all, we trust the certificate, so it doesn't matter if someone can create multiple different encodings of the same data.  we care about the data we got that was signed, not all of the possible other ways it *could* have been encoded
 764 2012-11-27 19:04:48 <kjj> and it that really was important for some reason, we could demand that the JSON be ordered in a particular way prior to signing.
 765 2012-11-27 19:05:00 <kjj> a canonical form, if you will
 766 2012-11-27 19:05:14 <gavinandresen> kjj: complexity like that is the enemy of security.
 767 2012-11-27 19:05:30 <BlueMatt> ^ this
 768 2012-11-27 19:06:02 <kjj> if we assume that the attacker can sign different forms of the same data, why can't we also assume that they can just sign their own stuff instead?
 769 2012-11-27 19:06:33 <kjj> either we trust the signature scheme, or we shouldn't be using it in the first place.
 770 2012-11-27 19:06:39 <BlueMatt> do you have an argument for json (aside from its already used in some places in bitcoin?)
 771 2012-11-27 19:06:52 <gavinandresen> The risk would be that the attacker inserts some extra data that the check-canonical-signature code throws away but (maybe due to a bug) the display-transaction code displays.  For example.
 772 2012-11-27 19:06:53 <BlueMatt> which, btw, its only used in bitcoind, not in any place that is standard bitcoin stuff
 773 2012-11-27 19:08:36 <kjj> gavinandresen: reject the whole thing then instead of silently discarding part of it.  there is plenty of precedent.  and it still doesn't matter unless you think that the attacker can control the data to be signed, which is already game over
 774 2012-11-27 19:09:21 <kjj> BlueMatt: my argument for JSON is that it is already all over the code, and the people working on it know it very well, and the people that don't work on it can figure it out in like 30 seconds.
 775 2012-11-27 19:09:36 <BlueMatt> all over what code?
 776 2012-11-27 19:09:39 <BlueMatt> bitcoind's, yes
 777 2012-11-27 19:10:24 <BlueMatt> the protocol buffer libs are also easy to understand, even if the data isnt as much
 778 2012-11-27 19:10:35 iddo has quit (Read error: Operation timed out)
 779 2012-11-27 19:10:40 <kjj> what is the argument in favor of PB?
 780 2012-11-27 19:10:48 iddo has joined
 781 2012-11-27 19:10:58 <BlueMatt> its better than the alternatives
 782 2012-11-27 19:11:00 <kjj> saving a few bytes per payment?
 783 2012-11-27 19:11:09 <kjj> heh.  better how?
 784 2012-11-27 19:11:38 <BlueMatt> though maybe not significant, there are potential issues (if nothing else, complications in implementation) due to the multiple encodings issue
 785 2012-11-27 19:11:43 <gavinandresen> kjj: Mike Hearn whipped up code for implementing signed invoices in about an hour.  Feel free to do the same for JSON and send me the code, maybe you'll convince me it is easy.
 786 2012-11-27 19:12:15 <gavinandresen> (just be sure to handle the gotchas pointed out in the JOSE specs properly)
 787 2012-11-27 19:15:09 <kjj> heh, that's the best argument in favor of PB that I've seen yet:  "Someone else has already implemented it"
 788 2012-11-27 19:16:19 maaku has quit (Quit: maaku)
 789 2012-11-27 19:16:28 <gavinandresen> Again, complexity is the enemy of security, and that's why the spec went from being JSON-based to PB-based.  PB give zero "wiggle-room" to potential attackers.
 790 2012-11-27 19:16:52 <sipa> gavinandresen: actually, it does; the fields in a PB encoding can be reordered :)
 791 2012-11-27 19:17:19 <phantomcircuit> and integers have something like the var_int weirdness
 792 2012-11-27 19:17:28 <phantomcircuit> but in general there is less wiggleroom
 793 2012-11-27 19:17:36 <gavinandresen> ok, fine, much less wiggle room....
 794 2012-11-27 19:17:58 <kjj> gavinandresen: I don't disagree with that principle, but the wiggle room in question was pretty damn small, while the cost of inflicting yet another incompatible binary packing standard on the bitcoin world is pretty high.
 795 2012-11-27 19:18:22 <sipa> bitcoinj is already entirely PB based
 796 2012-11-27 19:18:37 <sipa> and JSON is only used in bitcoind RPC
 797 2012-11-27 19:19:21 <sipa> if anything, i wished that satoshi had used PB from the start, but at least for all core protocol stuff (blocks and transactions) we're stuck with it
 798 2012-11-27 19:19:25 <kjj> and now EVERYONE that wants to deal with these invoices will be using PB too.  see the difference?
 799 2012-11-27 19:20:12 <sipa> yes, and otherwise EVERYONE that wants to deal with these invoices will be using JSON too.  see the difference?
 800 2012-11-27 19:20:29 D34TH has joined
 801 2012-11-27 19:20:29 D34TH has quit (Changing host)
 802 2012-11-27 19:20:29 D34TH has joined
 803 2012-11-27 19:20:37 <sipa> both are used in some places already, and we got to pick something
 804 2012-11-27 19:20:46 <kjj> oh, totally.  but JSON is a less icky than PB
 805 2012-11-27 19:21:23 <sipa> i love PB's simplicity far more than JSON's ambiguity (it doesn't even specify what kind of precision a "number" has)
 806 2012-11-27 19:21:28 <gavinandresen> http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns has a nice list of the languages supported....  and they're not icky.
 807 2012-11-27 19:23:10 <jgarzik> sipa: +1
 808 2012-11-27 19:23:41 <jgarzik> JSON is runtime flexible, but that's not the best when you are hashing and need tight specificity
 809 2012-11-27 19:24:18 <jgarzik> thus JSON inevitably requires some layer on top, making things more strict
 810 2012-11-27 19:24:44 <jgarzik> RE <sipa> if anything, i wished that satoshi had used PB from the start
 811 2012-11-27 19:24:46 <kjj> except that for this use, we don't need to be tight at all.
 812 2012-11-27 19:24:48 <jgarzik> Satoshi actually said same
 813 2012-11-27 19:24:58 <jgarzik> Satoshi said he would have used PB, if he had known about it at the time
 814 2012-11-27 19:25:07 <jgarzik> rather than a custom serialization
 815 2012-11-27 19:25:34 <jgarzik> but even when he said that, it was obviously far too late to change
 816 2012-11-27 19:26:04 <jgarzik> what was that other serialization....  minpack?
 817 2012-11-27 19:26:06 * jgarzik googles
 818 2012-11-27 19:26:27 <jgarzik> msgpack
 819 2012-11-27 19:26:29 <jgarzik> http://wiki.msgpack.org/display/MSGPACK/Overview
 820 2012-11-27 19:26:46 <jgarzik> more compact than PB.  less well known, fewer languages support, ordering might be more strict.
 821 2012-11-27 19:26:56 <sipa> initially i thought PB was just something like ASN.1, trying to encode the structure of the data along with it
 822 2012-11-27 19:27:03 <jgarzik> another, more exotic option, is to create a PB compiler and lib for bitcoin's custom serialization!
 823 2012-11-27 19:27:11 <jgarzik> you get strict, defined order, re-use existing code.
 824 2012-11-27 19:27:18 <sipa> but it's not; it really just adds exactly as much overhead to keep it infinitely extensible
 825 2012-11-27 19:27:22 <jgarzik> no langs supported
 826 2012-11-27 19:27:55 <jgarzik> if anybody wants that option, I could whip up a BB (bitcoinbufs) compiler
 827 2012-11-27 19:28:21 <kjj> sipa: that's what I call the XML problem.  when XML started making the rounds, people were making all sorts of crazy claims about not needing to know the format of data before interchange
 828 2012-11-27 19:28:36 <sipa> kjj: but that's it - PB doesn't do that
 829 2012-11-27 19:28:48 <sipa> it does require you to know the data type being encoded
 830 2012-11-27 19:28:51 <jgarzik> protobufs notably does not do as good a job of supporting vectors (repeated) as XDR-RPC, either.  PB does not support defined sizes/limit for vectors.
 831 2012-11-27 19:29:01 <sipa> which you in practice always know anyway
 832 2012-11-27 19:29:03 <kjj> sipa: and the structure
 833 2012-11-27 19:30:06 <sipa> jgarzik: yes, i agree there are some missed chances with PB (like tagged unions), but it is very simple
 834 2012-11-27 19:30:21 <jgarzik> yes.  nanopb is cute.  didn't know about that until recently.
 835 2012-11-27 19:30:36 <gavinandresen> speaking of limits... I'm tempted to specify size limits for Invoice/Payment/Receipt messages, to try to head-off DoS attacks like "I'll send you a 10,000-long X.509 chain and hope you spend CPU minutes verifying it...."
 836 2012-11-27 19:30:51 <jgarzik> gavinandresen: is there a version field in there?
 837 2012-11-27 19:30:59 <jgarzik> gavinandresen: might make a mistake on limits
 838 2012-11-27 19:31:25 <gavinandresen> jgarzik: no version field.  Probably a good idea to add one...
 839 2012-11-27 19:31:50 <jgarzik> gavinandresen: I agree that "cert type / cert bytes" is nicer than "x.509 cert bytes"
 840 2012-11-27 19:32:05 <jgarzik> TD is right that the format is upgradeable... but why create a new proto field for each type?
 841 2012-11-27 19:32:13 <gavinandresen> jgarzik: meh.  version=2 could do that....
 842 2012-11-27 19:32:38 <sipa> the cert data is likely to be black box bytes anyway
 843 2012-11-27 19:32:51 <jgarzik> x509_cert bytes.  next week, add jg_cert_format to foo.proto.  next month, add jg_cert_2_format.
 844 2012-11-27 19:32:53 <sipa> i prefer cert type/data as well
 845 2012-11-27 19:33:10 <jgarzik> "x509_cert bytes" is just too hardcoded and inflexible
 846 2012-11-27 19:33:37 <gavinandresen> will we have multiple types in one Invoice?
 847 2012-11-27 19:33:49 <jgarzik> gavinandresen: doubtful
 848 2012-11-27 19:33:50 <gavinandresen> (e.g. for extra security or backwards compatibility) ?
 849 2012-11-27 19:33:53 Icoin has joined
 850 2012-11-27 19:34:08 <jgarzik> gavinandresen: but it's droll to forever have unused x509_cert field in there, even if technically optional by PB standards
 851 2012-11-27 19:34:15 <kjj> oh, ha!
 852 2012-11-27 19:34:49 <gavinandresen> It'll also be droll to forever have to specify type="x509" if we never have anything else
 853 2012-11-27 19:34:51 <kjj> we could just make an optional cert_type and assume that it is X509 if not present
 854 2012-11-27 19:35:05 <jgarzik> kjj: sure, that's doable within PB easily
 855 2012-11-27 19:35:07 <sipa> gavinandresen: i really don't care about that
 856 2012-11-27 19:35:08 <jgarzik> gavinandresen: ^
 857 2012-11-27 19:35:21 <sipa> also fine
 858 2012-11-27 19:35:29 <jgarzik> PB also permits "default = x509"
 859 2012-11-27 19:35:34 <jgarzik> if not specified
 860 2012-11-27 19:35:39 <kjj> but then whenever someone wants to use a different type of cert, they have to pick id numbers for whatever extra data that scheme might use, and hope that those choices don't overlap anyone else's ids
 861 2012-11-27 19:35:39 <gavinandresen> ok.  I'll bend to consensus, cert_bytes and cert_type default=x509
 862 2012-11-27 19:35:45 <jgarzik> ACK
 863 2012-11-27 19:36:19 <sipa> use a string for cert_type
 864 2012-11-27 19:36:39 <kjj> and that looks like a general problem with PB
 865 2012-11-27 19:36:47 <phantomcircuit> gavinandresen, iirc protobuf you shouldn't need a version field
 866 2012-11-27 19:37:03 <phantomcircuit> which fields are present is all the info you should need
 867 2012-11-27 19:37:04 <gavinandresen> string?  what?  No, we need to form a Working Group and register with IANA!   (kidding, string it is)
 868 2012-11-27 19:37:11 <phantomcircuit> maybe TD[gone] can correct me here
 869 2012-11-27 19:37:11 <jgarzik> hehehe
 870 2012-11-27 19:37:38 <sipa> kjj: that's a general problem with any system trying to map a not-known-in-advance list of features into an integer
 871 2012-11-27 19:37:52 <jgarzik> phantomcircuit: generally true, but again, as your data structure gets more flexible, the internal structure of the data may change.  Something not directly expressed by .proto definition.
 872 2012-11-27 19:38:07 <jgarzik> phantomcircuit: c.f. JSON/XML problems just discussed
 873 2012-11-27 19:38:18 <kjj> sipa: heh.  at risk of resurrecting the JSON vs. PB argument...  there is no such problem mapping a string to a string.  :)
 874 2012-11-27 19:38:47 <jgarzik> phantomcircuit: A business rule might not permit more than 10,000 'repeated' for DoS reasons, like gavinandresen mentioned.  But, you might want to increase those limits later.
 875 2012-11-27 19:38:51 <sipa> kjj: that's exactly why a propose cert_type being a string
 876 2012-11-27 19:38:55 <gavinandresen> kjj: there's a whole section of the JOSE/JWS spec on problems mapping strings to strings....
 877 2012-11-27 19:39:06 <jgarzik> phantomcircuit: thus, 'version' is occasionally needed
 878 2012-11-27 19:39:36 <jgarzik> kjj: two words:  text encoding
 879 2012-11-27 19:39:38 <phantomcircuit> actually is there anyway to limit the repeated count with the protobuf libs?
 880 2012-11-27 19:39:43 <phantomcircuit> i never noticed one
 881 2012-11-27 19:39:48 <jgarzik> phantomcircuit: no (also just discussed)
 882 2012-11-27 19:39:54 <phantomcircuit> lol
 883 2012-11-27 19:39:58 <gavinandresen> jgarzik: I was researching how to properly do MIME-type versioning this morning, by the way....
 884 2012-11-27 19:39:58 <phantomcircuit> im a bit tired :|
 885 2012-11-27 19:39:59 <kjj> sipa: not just for certs.  if I want to add custom fields to my invoices, I can't just start using "kjj_myfield1", I have to pick an integer, and woe to anyone with a client that reads that number as something else
 886 2012-11-27 19:40:16 <jgarzik> phantomcircuit: ancient XDR permits this of course.
 887 2012-11-27 19:40:24 * jgarzik wrote an NFSv4 server, and deals with the XDR compiler
 888 2012-11-27 19:40:55 <phantomcircuit> jgarzik, heh of course it can
 889 2012-11-27 19:40:55 <gavinandresen> jgarzik: not yet clear to me if we need version numbers both in the protobuf format AND the request/response or just in the request/response
 890 2012-11-27 19:40:57 <jgarzik> XDR has a very C-like definition language, where you may specify a variable-length array, varlen array w/ limit, varlen array w/ specific size
 891 2012-11-27 19:41:10 dust-otc has quit (Remote host closed the connection)
 892 2012-11-27 19:41:21 <jgarzik> gavinandresen: oh good point
 893 2012-11-27 19:41:52 <jgarzik> gavinandresen: it might indeed be applicable to that lower, packetizing layer that PB requires
 894 2012-11-27 19:46:30 TwilightSparklee has joined
 895 2012-11-27 19:47:14 <gavinandresen> After reading http://www.informit.com/articles/article.aspx?p=1566460  I think I'm against a version field in the structures-- I think knowing what version you're expecting BEFORE you start parsing is the right way to go, and I can't think of situations where an application can't know that.
 896 2012-11-27 19:51:22 <jgarzik> gavinandresen: +1
 897 2012-11-27 19:51:46 <jgarzik> PB apps _must_ know it, because they must packetize PB (store a message length, and possibly a message checksum)
 898 2012-11-27 19:52:12 <jgarzik> PB does not define the transport format, just the message itself.
 899 2012-11-27 19:52:43 joepie91 has quit (Ping timeout: 246 seconds)
 900 2012-11-27 19:53:52 <kjj> wget cracks me up sometimes.  it can ignore whole directories, but to ignore a file, you have to download it, and then delete it
 901 2012-11-27 19:57:36 <kjj> anyhow, I have to run to a board meeting.  I'll make this one last pitch to avoid PB, and then I won't bring it up again.  because of the field IDs, PB requires a central definition.  The community can't experiment with different things and then come to their own consensus
 902 2012-11-27 19:58:47 <kjj> (unless someone wants to start BANA, but that is just a different central repository of IDs)
 903 2012-11-27 19:59:30 joepie91 has joined
 904 2012-11-27 19:59:33 <kjj> actually, shit, at the rate we are using version bytes for keys, we are going to need BANA in a few years anyway
 905 2012-11-27 19:59:54 datagutt has quit (Quit: kthxbai)
 906 2012-11-27 19:59:54 TwilightSparklee has quit (Quit: Colloquy for iPhone - http://colloquy.mobi)
 907 2012-11-27 20:03:12 <jgarzik> kjj: disagree
 908 2012-11-27 20:03:20 <jgarzik> kjj: That is what extensions are for: https://developers.google.com/protocol-buffers/docs/reference/python-generated#extension
 909 2012-11-27 20:04:15 <jgarzik> Disagree with the "community can't experiment" bit, I mean.  Obviously, it does require some method of centralized definition -- and that's a good thing, IMO.
 910 2012-11-27 20:05:02 <gavinandresen> yeah, if it didn't require a centralized definition I would have just written the code and submitted a patch request.
 911 2012-11-27 20:06:38 freakazoid has joined
 912 2012-11-27 20:06:46 gavinandresen has quit (Quit: gavinandresen)
 913 2012-11-27 20:29:11 wizkid057 has quit (Remote host closed the connection)
 914 2012-11-27 20:33:40 maaku has joined
 915 2012-11-27 20:37:38 B0g4r7 has joined
 916 2012-11-27 20:38:34 <jgarzik> picocoin, libccoin announcement: https://bitcointalk.org/index.php?topic=128055.0
 917 2012-11-27 20:38:41 maaku_ has joined
 918 2012-11-27 20:39:45 maaku has quit (Ping timeout: 246 seconds)
 919 2012-11-27 20:39:45 maaku_ is now known as maaku
 920 2012-11-27 20:40:30 nibor has joined
 921 2012-11-27 20:41:41 <gmaxwell> jgarzik: wrt picocoin security, — you'd be an ideal usecase for seccomp 2.0 security. (the BPF filtering of syscalls stuff)
 922 2012-11-27 20:41:58 ThomasV_ has joined
 923 2012-11-27 20:42:10 <jgarzik> gmaxwell: yep
 924 2012-11-27 20:43:18 <jgarzik> gmaxwell: Trying to make the network client as dumb and secure as possible.  Sort of an internal bitcoin server, to which the wallet process connects.   Going to use bloom filters to keep keys out of the network process.  chroot (or selinux if present), ...
 925 2012-11-27 20:43:28 nibor_ has quit (Ping timeout: 246 seconds)
 926 2012-11-27 20:44:33 D34TH has quit (Read error: Connection reset by peer)
 927 2012-11-27 20:45:49 <gmaxwell> yea, the non-wallet side of this should actually have no access to anything at all except the sockets and the block(headers) database and however you're doing IPC to the wallet.  Ideally an attacker with full control of that process shouldn't be more powerful than someone who controls a server for a thinclient.
 928 2012-11-27 20:52:24 gavinandresen has joined
 929 2012-11-27 20:53:51 cut has joined
 930 2012-11-27 20:54:39 <kjj> jgarzik: extensions don't solve the problem.  the initial definition has to define a range, and people have to make sure they don't overlap in that range (which is admittedly large, larger than tcp/udp port numbers)
 931 2012-11-27 20:55:00 quijibo has quit (Ping timeout: 246 seconds)
 932 2012-11-27 20:55:26 <sipa> if there's really a potential for extensions, add some repeated key/value string pair to the protobuf
 933 2012-11-27 20:56:13 <kjj> that's a hack though, a way to pretend to have a proper namespace, when you really don't
 934 2012-11-27 20:56:56 <sipa> but the point is that you need some common structure for an "invoice" to be meaningful; PB allows you to define that structure and make it trivial to parse that part
 935 2012-11-27 20:57:47 <sipa> and yes, JSON in a way also allows that, if you require some structure, and use some JSON parsing library
 936 2012-11-27 20:57:55 <kjj> and difficult to safely extend, while ASCII string identifiers give all the same benefits, and is easy to extend, at the cost of a few extra bytes
 937 2012-11-27 20:58:51 <kjj> anyhow, just wanted to respond to the posts while I was gone.  I'll drop it now.
 938 2012-11-27 20:58:57 <gmaxwell> JSON also seems a bit awkward for data that gets hashed, it is stuffed full of room for non-canonical encoding and for things which different implementations handle differently.
 939 2012-11-27 20:59:14 <sipa> gmaxwell: feel like testing #2033?
 940 2012-11-27 20:59:33 <gmaxwell> sipa: doing as we speak, in fact.
 941 2012-11-27 20:59:42 <gmaxwell> Just moved one of my mining nodes to it... importing the chain now.
 942 2012-11-27 20:59:59 <sipa> ah nice, thanks!
 943 2012-11-27 21:00:51 <kjj> gmaxwell: that's a good point, and I think that most implementations will lack a function to extract a node of the tree as a raw string, making nesting and signing difficult
 944 2012-11-27 21:01:40 <kjj> er, wait.  it is already a serializer, we just need to nest the encoders/decoders
 945 2012-11-27 21:01:54 <jgarzik> when hashing, JSON devolves into a format that ships ascii-encoded, further serialized data ;p
 946 2012-11-27 21:02:15 <jgarzik> look how we use it now, transiting raw data in JSON-RPC
 947 2012-11-27 21:02:36 <kjj> we could even sign the JSON string, and pack that string and the signature into the PB tree, if PB has better support for handling the signing part of the problem
 948 2012-11-27 21:03:21 <sipa> gmaxwell: also, saw my last comment on #1872?
 949 2012-11-27 21:04:01 <kjj> jgarzik: unless I'm missing something big, the sizes of the messages are not a big factor in anything.
 950 2012-11-27 21:04:36 sacredchao has joined
 951 2012-11-27 21:04:42 <jgarzik> kjj: I never implied size was a problem
 952 2012-11-27 21:04:57 <gmaxwell> sipa: yep. haven't had a chance to go look at it again. probably just cruft I pulled through and didn't remove. Indeed it looked stupid.  I'll put on a brown paper bag an update the pull request soon.
 953 2012-11-27 21:04:59 <jgarzik> kjj: it's just an additional layer of encoding, required by deficiencies of the format
 954 2012-11-27 21:05:45 LightRider has joined
 955 2012-11-27 21:06:24 <LightRider> Is anyone running a testnet node, and can I have your ip address for that node please?
 956 2012-11-27 21:06:39 <LightRider> bonus points for ipv6
 957 2012-11-27 21:06:41 <jgarzik> LightRider: us4.exmulti.net
 958 2012-11-27 21:06:45 <gmaxwell> LightRider: why? is testnet not working for you? or?
 959 2012-11-27 21:06:55 <LightRider> I haven't gotten any connections in hours
 960 2012-11-27 21:06:56 <jgarzik> no ipv6 on us4, sadly
 961 2012-11-27 21:07:11 <jgarzik> LightRider: are you on >= 0.7 ?
 962 2012-11-27 21:07:16 <LightRider> yes
 963 2012-11-27 21:07:24 <LightRider> thanks for address
 964 2012-11-27 21:07:29 <gmaxwell> LightRider: are you explictly disabling IRC?
 965 2012-11-27 21:07:41 <LightRider> I'm explicitly enabling it
 966 2012-11-27 21:07:55 <gmaxwell> there is no dns seed or static seeds for testnet, you'll only get peers if you haven't disabled IRC. (It's on by default)
 967 2012-11-27 21:08:24 <gmaxwell> my public testnet node:     "connections" : 31,
 968 2012-11-27 21:10:02 <LightRider> well, I'm on the net now, thanks jgarzik
 969 2012-11-27 21:10:04 <kjj> meh.  90% of the computers on the planet will have to reorder all of the integers anyway.  base64 is a bit harsher of a codec, but in my mind the difference is quantitative, not qualitative
 970 2012-11-27 21:10:26 <jgarzik> kjj: ?
 971 2012-11-27 21:10:27 <gavinandresen> I'm reworking the invoices spec... what do y'all think of doing:  optional string pki_type = 1 [default = "x509"];
 972 2012-11-27 21:10:33 <gavinandresen> and optional bytes pki_data = 2;
 973 2012-11-27 21:10:50 <jgarzik> kjj: most everybody sane is using little endian integers.  "network byte order" is just Sun marketing.
 974 2012-11-27 21:11:06 <jgarzik> gavinandresen: yep, ack
 975 2012-11-27 21:11:16 <sipa> gavinandresen: sounds good
 976 2012-11-27 21:11:22 <gavinandresen> ... then need to define how multiple certificates are packed into pki_data
 977 2012-11-27 21:11:26 <jgarzik> gavinandresen: though is pki_data optional?  I forget the spec details.
 978 2012-11-27 21:11:47 <gmaxwell> yea, at the IETF absolutely no one cares about pushing BE anymore. Heck, no one even cares about 'byte' vs 'octet' anymore.
 979 2012-11-27 21:11:55 <gavinandresen> jgarzik: TD thinks people will want unsigned Invoices for low-value stuff....
 980 2012-11-27 21:12:09 <jgarzik> gavinandresen: heh, for multiple certs pki_type could just as easily be a comma-delimited string "x509,jgarzik,nuttybars"
 981 2012-11-27 21:12:26 <jgarzik> gavinandresen: ok
 982 2012-11-27 21:12:43 <jgarzik> gavinandresen: I think think people will want self-signed rather than totally unsigned
 983 2012-11-27 21:12:45 <sipa> why pki_* and not cert_*?
 984 2012-11-27 21:12:53 <jgarzik> *I still think
 985 2012-11-27 21:12:58 <gavinandresen> because you might be using a pki system that doesn't do certificates
 986 2012-11-27 21:13:09 <gavinandresen> (e.g. gpg web of trust with plain public keys)
 987 2012-11-27 21:13:34 <gmaxwell> I might guess "signed by the key that I'm paying to" would be a somewhat interesting 'selfsigned' case.
 988 2012-11-27 21:13:36 <jgarzik> self-signed at least permits knowing it is the same entity across multiple transactions
 989 2012-11-27 21:14:00 <kjj> agreed on the pki_ names instead of cert_ .
 990 2012-11-27 21:14:06 <jgarzik> and you can verify that OOB to further mitigate MITM ("<irc> hey, I'm cert 0x1234abcd")
 991 2012-11-27 21:14:28 <LightRider> I can confirm that getting a testnet node up to speed from zero is blazing fast, well done guys.
 992 2012-11-27 21:14:33 <sipa> gavinandresen: oh, i thought PKI specifically referred to the hierarchical CA/cert/revoke system
 993 2012-11-27 21:14:39 <kjj> hard to say if unsigned-over-SSL will be more popular than signed.
 994 2012-11-27 21:14:55 theorbtwo has quit (Remote host closed the connection)
 995 2012-11-27 21:15:02 <kjj> if there is any doubt, make it not-optional.  if optional, I'd still default to x509
 996 2012-11-27 21:15:15 <jgarzik> gmaxwell: rofl (RE byte vs octet)
 997 2012-11-27 21:15:46 <kjj> the I in PKI is generic.  the SSL world uses one possible implementation of that infrastructure
 998 2012-11-27 21:16:12 dparrish has quit (Quit: leaving)
 999 2012-11-27 21:16:48 <sipa> well, just looked at the PKI article on wikipedia (undoubtedly of unquestionable veracity), and it calls PGP an alternative to PKI that uses self-signed certificates
1000 2012-11-27 21:17:00 <gmaxwell> #bitcoin-otc WOT is now also bitcoin signmessage based.
1001 2012-11-27 21:17:33 <gmaxwell> sipa: well that article is confused, considering that PGP as a PKI is not "self-signed certificates" ... it's WOT signed.
1002 2012-11-27 21:17:39 <sipa> yeah
1003 2012-11-27 21:18:15 <gavinandresen> I don't care what the name is, "identity_type" and "identity_data" would work, too
1004 2012-11-27 21:18:23 dparrish has joined
1005 2012-11-27 21:18:25 <gmaxwell> having a simple form for bitcoin signmessage cert chains. E.g. a sequence of signmessages than ultimately commit to the payto address on the invoice would be handy for WOT users.
1006 2012-11-27 21:18:44 <gmaxwell> perhaps I'll prod nanotube or someone from around that space to specify such a thing.
1007 2012-11-27 21:19:47 veeminer has quit ()
1008 2012-11-27 21:19:51 <ThomasV_> gavinandresen: where is that spec?
1009 2012-11-27 21:20:02 <gavinandresen> ThomasV_: https://gist.github.com/gists/4120476/
1010 2012-11-27 21:20:42 <ThomasV_> thanks
1011 2012-11-27 21:23:08 <cut> hi, i had 2 unconfirmed transactions in bitcoind, and removed them with pywallet, but now getbalance shows the wrong amount (it is still down the 2 unconfirmed transactions), but getbalance * with the wildcard shows the correct amount. the amount seems to be hiding somewhere. is that normal after running pywallet or can it be fixed?
1012 2012-11-27 21:23:59 <sipa> cut: you'll also mark the inputs used by the unconfirmed transactions as available again
1013 2012-11-27 21:24:05 <sipa> no idea if pywallet can do that
1014 2012-11-27 21:24:37 <cut> ahh thanks
1015 2012-11-27 21:25:10 <sipa> cut: one way would be to remove those input transactions as well, and rescan the blockchain
1016 2012-11-27 21:25:32 <ThomasV_> gavinandresen: are you also working on a pay-to-alias spec? is there a url for it too?
1017 2012-11-27 21:25:49 <gavinandresen> ThomasV_: no, I'm not working on a pay-to-alias spec.
1018 2012-11-27 21:26:24 <sipa> just use a URL to a (perhaps on-the-fly generated) Invoice file as "alias"
1019 2012-11-27 21:26:41 agricocb has quit (Remote host closed the connection)
1020 2012-11-27 21:27:11 pusle has quit (Remote host closed the connection)
1021 2012-11-27 21:27:32 <ThomasV_> sipa: yes, both things are related
1022 2012-11-27 21:28:31 pecket has quit (Ping timeout: 252 seconds)
1023 2012-11-27 21:35:43 theorbtwo has joined
1024 2012-11-27 21:35:57 <gmaxwell> nanotube: you around? Have you seen the invoice proposal?  do you have thoughts about how it could integrate with WOT?
1025 2012-11-27 21:37:16 <cut> sipa: thx that worked. had to "delete all tx" with pywallet instead of just the 2 unconfirmed, and then let bitcoind find everything again with -rescan
1026 2012-11-27 21:37:33 <gmaxwell> nanotube: I'm thinking a simple serialization where there is a sequence of bitcoin sign messages, the first being a gribble controlled key signs the otc username and ultimately signs the key that signs the invoice.
1027 2012-11-27 21:38:45 <gavinandresen> spec updated : https://gist.github.com/4120476
1028 2012-11-27 21:40:03 graingert has quit (Quit: Ex-Chat-GNOME)
1029 2012-11-27 21:47:03 <jgarzik> gmaxwell: BTW any libccoin valgrinding you can be talked into is helpful ;p
1030 2012-11-27 21:47:13 <jgarzik> gmaxwell: and what was that 'make check' valgrind magic again?
1031 2012-11-27 21:47:49 <gmaxwell> 11:27 < gmaxwell> (you're aware you can do 'make check TESTS_ENVIRONMENT=valgrind'  right?)
1032 2012-11-27 21:48:21 <jgarzik> tnx
1033 2012-11-27 21:48:46 <jgarzik> gavinandresen: culture note...  I think the "memo" field will grow formatting regardless of what we or spec says :)
1034 2012-11-27 21:48:56 <jgarzik> people will put newlines in there, inside of a year
1035 2012-11-27 21:49:14 torsthaldo_ has joined
1036 2012-11-27 21:49:56 <gmaxwell> also if you're using libtool already, you can put the libtool --mode=execute in there someplace. :P
1037 2012-11-27 21:49:59 <gmaxwell> e.g.
1038 2012-11-27 21:50:02 <gmaxwell> make check TESTS_ENVIRONMENT='libtool --mode=execute valgrind --error-exitcode=1'
1039 2012-11-27 21:50:05 <gavinandresen> jgarzik: yeah... we have to be careful not to open up acres of new attack surface there
1040 2012-11-27 21:50:42 <gavinandresen> jgarzik: if there was One Obvious plain-text markup language (like markdown) then I'd be tempted to say "use that"
1041 2012-11-27 21:51:14 torsthaldo has quit (Ping timeout: 240 seconds)
1042 2012-11-27 21:51:18 pecket has joined
1043 2012-11-27 21:51:19 <jgarzik> gavinandresen: indeed.  Not claiming I have a great answer...  just noting history shows plaintext fields eventually grow formatting
1044 2012-11-27 21:51:23 <sipa> let's just standardize one including a .bmp file there
1045 2012-11-27 21:51:36 <gavinandresen> sipa: lol
1046 2012-11-27 21:51:53 <gavinandresen> animated gifs FTW!
1047 2012-11-27 21:51:57 <jgarzik> ah bmp.  I remember those from the days of amber screens
1048 2012-11-27 21:52:23 <sipa> gavinandresen: oh, .bmp is way too limited; how about .swf?
1049 2012-11-27 21:52:35 <jgarzik> memo_mime_type [default=plaintext]
1050 2012-11-27 21:52:37 * jgarzik runs
1051 2012-11-27 21:52:39 <gavinandresen> sipa: I was just thinking the same thing
1052 2012-11-27 21:53:10 <gavinandresen> what could possibly go wrong if we let merchants embed some nice flash graphics in their payment requests.....
1053 2012-11-27 21:53:39 <gavinandresen> It's value-added for Bitcoin!  Get some co-merchandising up-selling right there!
1054 2012-11-27 21:54:11 <gavinandresen> Click HERE for EXTRA SAVINGS!  (and a brand-new rootkit...)
1055 2012-11-27 21:58:01 skeledrew has quit (Read error: Connection reset by peer)
1056 2012-11-27 21:58:51 <gmaxwell> .scr so you don't get burnin if you leave the invoice up on your screen.
1057 2012-11-27 21:59:10 <ThomasV_> let us separate the memo's content and formatting, using css and an extra field...
1058 2012-11-27 21:59:17 skeledrew has joined
1059 2012-11-27 22:00:06 Apollonius_of_Pe has joined
1060 2012-11-27 22:00:25 Apollonius_of_Pe is now known as Apollonius
1061 2012-11-27 22:00:32 agricocb has joined
1062 2012-11-27 22:00:46 <sipa> i think we can extend Bitcoin's script language to gain some DOM-tree modification functionality
1063 2012-11-27 22:00:51 <gmaxwell> Obviously there needs to be fields for DRM too.  Invoice_copy_enable: [0/1]
1064 2012-11-27 22:01:15 <Apollonius> hello, would anybody mind if I ask some nooby questions about Bitcoin programming?
1065 2012-11-27 22:01:31 <helo> ask away
1066 2012-11-27 22:01:33 <sipa> Apollonius: don't ask to ask :)
1067 2012-11-27 22:01:43 <Apollonius> thanks :-D
1068 2012-11-27 22:02:15 <liori> protocol buffers are presented in that spec in contrast to json, with json having the disadvantage of having multiple ways to encode the same data. i'm not sure, but protocol buffers have the same disadvantage: fields can be encoded in any order
1069 2012-11-27 22:02:23 phma__ has joined
1070 2012-11-27 22:02:34 <Apollonius> So I think I understand Satoshi's paper from an abstract perspective, but I don't know how it actually works in implementations
1071 2012-11-27 22:02:53 <jgarzik> Apollonius: that's what source code and IRC questions are for ;p
1072 2012-11-27 22:03:09 <Apollonius> cool
1073 2012-11-27 22:04:21 <gmaxwell> liori: there are a couple ways to get multiple encodings in protocol buffers though far far fewer than json. The bigger distinction is that you can expect that it's possible to create json encodings that some implementations will consider valid and some will not.
1074 2012-11-27 22:04:37 <Apollonius> Question 1: If a bitcoin is a chain of hashes of previous transactions, do you just get one hash at the end representing the coin, or is it a list of hashes?
1075 2012-11-27 22:05:00 <sipa> Apollonius: a bitcoin is just a unit of account
1076 2012-11-27 22:05:20 <jgarzik> Apollonius: each transaction has inputs and outputs.  a "coin" is a transaction output that has not been spent (i.e. not yet connected to another transaction's inputs)
1077 2012-11-27 22:05:24 drizztbsd has quit (Read error: Connection reset by peer)
1078 2012-11-27 22:05:39 <sipa> Apollonius: each output has an amount encoded as a 64-bit integer
1079 2012-11-27 22:05:42 <jgarzik> Apollonius: thus, your personal bitcoin balance is the collection of unspent transaction outputs, sent to keys you control
1080 2012-11-27 22:05:54 <sipa> and 100000000 base units ("satoshi's") are called 1 bitcoin
1081 2012-11-27 22:06:17 <gavinandresen> ... and inputs are (hash_of_prior_transaction, output_number)  which is where the notion of a chain of transaction hashes comes from
1082 2012-11-27 22:07:03 <liori> gmaxwell: so json's disadvantage is not multitude of possible encodings, but that implementations do not agree on what is valid encoding. and protocol buffers are presumable lacking this problem.
1083 2012-11-27 22:07:07 <Apollonius> ok, cool, it's that "hash_of_prior_transaction" i'm a little confused about
1084 2012-11-27 22:08:00 <liori> has anybody even worked on a specification related to signing protobuf messages?
1085 2012-11-27 22:08:20 <gmaxwell> liori: lacking it in practice, and I think also being harder to come up with that. Also the degree of the multiple encodings is different. I think it may actually be rather hard to get consistent encodings out of two distinct json implementations, while it's far more likely for protocol buffers. (though it's annoying that protocol buffers aren't always canonical)
1086 2012-11-27 22:08:25 <Apollonius> does that "hash_of_prior_transaction" contain a list of all transactions leading up to the current unspent coins? or is it just the immediately precedent transactions?
1087 2012-11-27 22:08:58 <jgarzik> Apollonius: each transaction hashes to a unique value.  we maintain an internal database, that permits a lookup on a transaction's unique hash value (often called "txid")
1088 2012-11-27 22:09:10 <gavinandresen> Apollonius: just the immediate prior one.  It, in turn, has inputs (unless it is a coin generation transaction, in which case it has no prior inputs)
1089 2012-11-27 22:09:19 <jgarzik> Apollonius: just the immediately preceding transaction
1090 2012-11-27 22:09:40 <Apollonius> excellent, thanks guys!
1091 2012-11-27 22:09:55 <gavinandresen> liori: a previous version of the spec was JSON-based, but then I went and read the JOSE working group's specs and ran away screaming
1092 2012-11-27 22:10:14 fronti has joined
1093 2012-11-27 22:10:28 <Apollonius> Question 2: how do you connect to said transaction database? i.e. where does the blockchain live, where's it published in forms where actual implementations access it?
1094 2012-11-27 22:10:30 <gavinandresen> (JOSE is javascript object signing and encryption working group, we would use their mechanisms for signing instead of inventing our own)
1095 2012-11-27 22:10:36 <liori> maybe if you read a similar work based on protobufs it would be the same? :-)
1096 2012-11-27 22:10:57 <sipa> Apollonius: it's part of the software
1097 2012-11-27 22:11:15 <sipa> Apollonius: and nodes synchronize with eachother
1098 2012-11-27 22:11:45 <Apollonius> how do you connect to other nodes? they have to communicate to each other...how is this accomplished?
1099 2012-11-27 22:11:49 <jgarzik> Apollonius: each node stores its own copy of the transaction database
1100 2012-11-27 22:11:57 <jgarzik> Apollonius: P2P network on the Internet
1101 2012-11-27 22:12:47 * gavinandresen waits for Apollonius to ask the bootstrapping question....
1102 2012-11-27 22:13:03 <Apollonius> lol, i don't know how to phrase the question correctly...but yeah
1103 2012-11-27 22:13:39 Mqrius has joined
1104 2012-11-27 22:13:52 <gavinandresen> Do we have a wiki page on bootstrapping?
1105 2012-11-27 22:14:19 <gavinandresen> Ah: https://en.bitcoin.it/wiki/Network#Bootstrapping
1106 2012-11-27 22:15:05 <gavinandresen> bleuch...  that section of the page is not well written
1107 2012-11-27 22:15:38 <Apollonius> well, it gives me an idea, cool...so do the first nodes you find give you more nodes?
1108 2012-11-27 22:15:45 <gavinandresen> yes
1109 2012-11-27 22:15:57 quijibo has joined
1110 2012-11-27 22:16:33 <Mqrius> I'm trying to export a privkey from bitcoinqt to electrum. I tried doing dumpprivkey, but the resulting privkey is not in wallet import format. I tried importing it in electrum anyway, but I'm getting an error in one of the error handlers, which makes debugging troublesome. For now I'm assuming it won't take anything besides wallet import format, so, my question is, how do I convert to that?
1111 2012-11-27 22:16:56 <Apollonius> it says irc bootstrapping is off by default...does that mean, running a node, you don't automatically connect to irc as a way of letting other nodes find you?
1112 2012-11-27 22:17:05 <sipa> Mqrius: it IS in WIF format, but it's a compressed key, and electrum doesn't support those AFAIK
1113 2012-11-27 22:17:38 mologie has quit (Read error: Operation timed out)
1114 2012-11-27 22:17:46 <gavinandresen> Apollonius: yes.  Other nodes will find you via 'addr' messages broadcast over the network, though.
1115 2012-11-27 22:17:54 <Mqrius> sipa: Any convenient ways of uncompressing?
1116 2012-11-27 22:18:19 <sipa> Mqrius: yes, but that would be pointless, as the corresponding address won't be the same, so it won't let you access funds sent to the original address
1117 2012-11-27 22:18:45 <Mqrius> Oh, right. Damn.
1118 2012-11-27 22:18:55 <sipa> Mqrius: basically, for every private key there are two public keys, each with an own address
1119 2012-11-27 22:19:05 <Apollonius> Thanks so much gavin, sipa, and jgarzik! I'll be sure to come back later with more questions :-D
1120 2012-11-27 22:19:22 <sipa> so we put a marker on the private key saying "you should use the compressed pubkey of this privkey"
1121 2012-11-27 22:19:46 <Mqrius> Hmm. Any other light clients that /do/ support compressed privkeys?
1122 2012-11-27 22:19:46 <sipa> and software that doesn't support compressed pubkeys, doesn't understand that marker, and complains
1123 2012-11-27 22:19:52 ovidiusoft has quit (Quit: leaving)
1124 2012-11-27 22:19:55 <Mqrius> compressed pubkeys*
1125 2012-11-27 22:20:06 <sipa> i know none
1126 2012-11-27 22:20:10 <Mqrius> :S
1127 2012-11-27 22:20:11 Apollonius has quit (Quit: Page closed)
1128 2012-11-27 22:20:26 <sipa> it's been in bitcoind/-qt for half a year though now
1129 2012-11-27 22:20:53 <sipa> ThomasV: actually, i'm making assumptions here; does electrum support compressed pubkeys?
1130 2012-11-27 22:20:59 <ThomasV_> Mqrius: electrum supposedly supports compressed keys, but it does not generated them in its own deterministic sequence
1131 2012-11-27 22:21:31 <Mqrius> The real issue is that I installed bitcoinqt yesterday on my new netbook, encrypted, backed up, and then sent some funds thinking it would be sync'd in a few hours, like on my desktop. Sadly, the cpu is an atom and the HD is not too fast, so now after 24 hours it's still not there. And I want my funds back :P
1132 2012-11-27 22:21:53 LightRider has quit ()
1133 2012-11-27 22:21:58 <Mqrius> ThomasV: Then it's a different issue. Shall I troubleshoot it here or in #electrum?
1134 2012-11-27 22:22:29 <ThomasV_> probably in #electrum, but that will still be me answering  :)
1135 2012-11-27 22:22:33 <gmaxwell> ThomasV_: is there any way you can upgrade so that you do in the future? Not using them is kinda a bummer. They shirnk txn sizes a fair amount.
1136 2012-11-27 22:22:45 <sipa> someone recently found out here that there is software that adds a 0x00 byte to the end instead of a 0x01
1137 2012-11-27 22:22:47 <Mqrius> Yeah, figured as much :)
1138 2012-11-27 22:23:10 <ThomasV_> gmaxwell: not before bip 32 is final. I don't want to have to change that more than once
1139 2012-11-27 22:25:02 <gmaxwell> ThomasV_: ah! fine enough.
1140 2012-11-27 22:25:15 one_zero has joined
1141 2012-11-27 22:26:42 DaQatz has quit (Ping timeout: 246 seconds)
1142 2012-11-27 22:28:51 DaQatz has joined
1143 2012-11-27 22:30:20 one_zero has quit ()
1144 2012-11-27 22:30:33 <Luke-Jr> BlueMatt: how easy would it be to write a simple node wrapper with it?
1145 2012-11-27 22:31:00 unknown45682 has quit (Read error: Connection reset by peer)
1146 2012-11-27 22:31:18 <Luke-Jr> *: Don't expect me to deal with any pullreqs etc today, as I'm feeling pretty ill and probably won't get a chance until I get better.
1147 2012-11-27 22:33:05 <BlueMatt> Luke-Jr: probably, writer a wrapper around it to just check blocks should be easy, though you would have to add your own parameter to ignore difficulty (shouldnt be too hard)
1148 2012-11-27 22:33:28 <Luke-Jr> BlueMatt: but what about the p2p stuff?
1149 2012-11-27 22:33:57 <BlueMatt> p2p stuff is implements already, just add a handler
1150 2012-11-27 22:34:02 <BlueMatt> ed
1151 2012-11-27 22:34:11 <Luke-Jr> i c
1152 2012-11-27 22:34:46 phantomcircuit has quit (Ping timeout: 246 seconds)
1153 2012-11-27 22:35:13 brwyatt has quit (Away!~brwyatt@brwyatt.net|Ping timeout: 256 seconds)
1154 2012-11-27 22:35:54 one_zero has joined
1155 2012-11-27 22:36:05 brwyatt has joined
1156 2012-11-27 22:36:06 <BlueMatt> (its peer selection isnt great (working on it), so just connect to a local node(s))
1157 2012-11-27 22:37:17 mologie has joined
1158 2012-11-27 22:39:23 phantomcircuit has joined
1159 2012-11-27 22:43:14 pecket has quit (Quit: I'm not stupid. I'm just unlucky when I think.)
1160 2012-11-27 22:50:34 devrandom has quit (Ping timeout: 276 seconds)
1161 2012-11-27 22:51:49 mologie has quit (Ping timeout: 244 seconds)
1162 2012-11-27 22:55:32 pecket has joined
1163 2012-11-27 22:59:23 <gmaxwell> 11/27/12 22:46:23 ERROR: CheckInputs() : 4005d6bea3 VerifySignature failed
1164 2012-11-27 22:59:24 <gmaxwell> 0_o
1165 2012-11-27 22:59:35 <gmaxwell> that txn is still circulating! crazy
1166 2012-11-27 22:59:44 <gmaxwell> also, wtf, why is one of my peers propgating it!
1167 2012-11-27 23:00:05 <Luke-Jr> lol
1168 2012-11-27 23:00:26 <Luke-Jr> gmaxwell: because not the whole network upgraded yet
1169 2012-11-27 23:00:34 <Luke-Jr> gmaxwell: this is why I didn't like the idea of DoS banning for it yet
1170 2012-11-27 23:00:47 <gmaxwell> ah, it's         "subver" : "/Snoopy:0.1/",
1171 2012-11-27 23:00:50 <gmaxwell> that guy.
1172 2012-11-27 23:00:59 <gmaxwell> I need a hack to not pull transactions from that idiot.
1173 2012-11-27 23:01:07 <gmaxwell> (though ... I like his blocks...)
1174 2012-11-27 23:01:46 <gmaxwell> oh actually, it might have been 46.4.121.98:8333
1175 2012-11-27 23:03:00 zebedee_ has quit (Remote host closed the connection)
1176 2012-11-27 23:03:03 mologie has joined
1177 2012-11-27 23:03:17 zebedee_ has joined
1178 2012-11-27 23:03:17 zebedee_ has quit (Client Quit)
1179 2012-11-27 23:06:19 GMP has joined
1180 2012-11-27 23:11:38 joepie91 has quit (Ping timeout: 264 seconds)
1181 2012-11-27 23:12:40 BCB7t2 has quit (Remote host closed the connection)
1182 2012-11-27 23:14:08 joepie91 has joined
1183 2012-11-27 23:16:20 x18882 has joined
1184 2012-11-27 23:17:55 BC3ot2 has joined
1185 2012-11-27 23:19:28 ThomasV_ has quit (Quit: Quitte)
1186 2012-11-27 23:20:15 RazielZ has quit (Ping timeout: 246 seconds)
1187 2012-11-27 23:26:35 etotheipi_ has quit (Quit: Ex-Chat)
1188 2012-11-27 23:27:06 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1189 2012-11-27 23:28:05 denisx has quit (Quit: denisx)
1190 2012-11-27 23:29:35 da2ce7 has joined
1191 2012-11-27 23:32:21 mologie has quit (Ping timeout: 245 seconds)
1192 2012-11-27 23:39:07 toffoo has joined
1193 2012-11-27 23:39:22 CodesInChaos has quit (Ping timeout: 248 seconds)
1194 2012-11-27 23:39:32 <jgarzik> gmaxwell: wtf is "/Snoopy:0.1/" ? a miner?
1195 2012-11-27 23:44:25 mologie has joined
1196 2012-11-27 23:44:50 BitDev has joined
1197 2012-11-27 23:45:12 <BitDev> hi all, i have another question... how to calculate hash of the block?
1198 2012-11-27 23:46:11 <Luke-Jr> gmaxwell: that 24 hour bug might be a real problem if ASICs get delayed too long
1199 2012-11-27 23:46:17 <gmaxwell> jgarzik: no. it's a moronic node that forwards everything it gets, valid or not.
1200 2012-11-27 23:46:20 <sturles> jgarzik: The swiss university node which forward blocks very fast.
1201 2012-11-27 23:46:43 <Luke-Jr> gmaxwell: hmm, maybe peering with it is slush's trick to fastest LP?
1202 2012-11-27 23:46:51 <gmaxwell> it's caused no end of drama on the forums because blockchain.info was (is?) reporting it as the source of most of the blocks.
1203 2012-11-27 23:46:59 <gmaxwell> Luke-Jr: I peer with it for that purpose.
1204 2012-11-27 23:47:04 <BitDev> i have send getheaders packet and get headers... now how i can get hash of thar header?
1205 2012-11-27 23:47:30 <gmaxwell> I hoped to get around with replacing it with a slightly smarter forwarder based on jeff's C node.
1206 2012-11-27 23:47:56 <BitDev> can some one help me?
1207 2012-11-27 23:47:57 <jgarzik> BitDev: sha256(sha256(80 byte header))
1208 2012-11-27 23:47:58 <gmaxwell> e.g. something that does spv level validation of blocks before forwarding them... and only forwards to inbound peers so no one is getting crap they don't want.
1209 2012-11-27 23:48:03 <sipa> Luke-Jr: what 24h bug?
1210 2012-11-27 23:48:16 <Luke-Jr> sipa: if bitcoind doesn't have a block in the last 24 hours, it disables mining
1211 2012-11-27 23:48:36 <sipa> meh, only a theoretical risk i think
1212 2012-11-27 23:49:32 <Luke-Jr> sipa: not if we lost a ton of hashrate
1213 2012-11-27 23:49:46 <BitDev> jgarzik - wont work, cuz i get wrong hash (
1214 2012-11-27 23:50:28 <gmaxwell> it's no biggie. in the unlikely case that even gets close we'll just push out a fix to pools.
1215 2012-11-27 23:50:44 <gmaxwell> everyone that matters will show up here asking wtf when we've gone 6 hours without a block. :)
1216 2012-11-27 23:50:45 <jgarzik> BitDev: then you're Doing It Wrong :)  That is the definition of how to calculate the hash.
1217 2012-11-27 23:51:10 <BitDev> i use openssl for calculating hash
1218 2012-11-27 23:51:15 <gmaxwell> There is a rather large chunk of fpga hashpower in existance now in any case.
1219 2012-11-27 23:51:19 <jgarzik> BitDev: https://en.bitcoin.it/wiki/Block_hashing_algorithm
1220 2012-11-27 23:51:38 <jgarzik> BitDev: OpenSSL works just fine for calculating hash.
1221 2012-11-27 23:53:37 <jgarzik> BitDev: https://github.com/jgarzik/picocoin/tree/master/lib
1222 2012-11-27 23:53:47 <jgarzik> BitDev: core.c and util.c demonstrate how to use OpenSSL to calculate block header hash
1223 2012-11-27 23:54:03 <BitDev> ok, thnx i will look!
1224 2012-11-27 23:55:21 <sipa> Luke-Jr: if the hash rate drops by a factor 10, there is a 1 in a million chance of not getting a block in a day
1225 2012-11-27 23:57:59 x18882 has quit (Quit: Yo!)
1226 2012-11-27 23:58:37 <jgarzik> 11/27/12 23:39:46 Verifying last 2500 blocks at level 1
1227 2012-11-27 23:58:37 <jgarzik> 11/27/12 23:39:46 ERROR: bool CBlock::ReadFromDisk(const CDiskBlockPos&)() : deserialize or I/O error
1228 2012-11-27 23:58:37 <jgarzik> 11/27/12 23:39:46 ERROR: LoadBlockIndex() : block.ReadFromDisk failed
1229 2012-11-27 23:58:37 <jgarzik> 11/27/12 23:39:46 Bitcoin: Error loading blkindex.dat
1230 2012-11-27 23:58:38 <jgarzik> hmmmm
1231 2012-11-27 23:58:48 <jgarzik> vanilla HEAD