1 2013-02-21 00:01:12 <Luke-Jr> is there any reason I shouldn't withdraw BIP 19 at this point?
   2 2013-02-21 00:02:54 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
   3 2013-02-21 00:02:55 maaku_ has quit (Read error: Connection reset by peer)
   4 2013-02-21 00:03:04 maaku has joined
   5 2013-02-21 00:04:49 D34TH has quit (Quit: Leaving)
   6 2013-02-21 00:05:46 pirateat41 is now known as Pirateat42
   7 2013-02-21 00:05:50 Pirateat42 is now known as Pirateat43
   8 2013-02-21 00:06:41 owowo is now known as Pirateat43-5
   9 2013-02-21 00:06:41 Arathill has joined
  10 2013-02-21 00:06:55 Pirateat43-5 is now known as owowo
  11 2013-02-21 00:08:47 ralphtheninja has joined
  12 2013-02-21 00:12:45 word_ has joined
  13 2013-02-21 00:14:41 word has quit (Ping timeout: 252 seconds)
  14 2013-02-21 00:16:05 <jgarzik> hrm
  15 2013-02-21 00:17:11 <sipa> Luke-Jr: i can think of several (wishful thinking, vanity, desperation, ...) but none of them seem very good
  16 2013-02-21 00:18:06 ovidiusoft has quit (Ping timeout: 276 seconds)
  17 2013-02-21 00:20:14 [\\\]_z has joined
  18 2013-02-21 00:20:16 [\\\]_z has quit (Remote host closed the connection)
  19 2013-02-21 00:21:04 ralphtheninja has left ()
  20 2013-02-21 00:21:52 <Luke-Jr> sipa: well, I could always un-withdraw it if there turned out to be a need later too..
  21 2013-02-21 00:21:53 [\\\] has quit (Ping timeout: 255 seconds)
  22 2013-02-21 00:22:06 [\\\]_l has joined
  23 2013-02-21 00:22:20 agricocb has joined
  24 2013-02-21 00:23:35 RBecker is now known as rbecker
  25 2013-02-21 00:23:51 <owowo> now i got it to compile, but it won't start...
  26 2013-02-21 00:24:47 <maaku> anyone know the simplest way to prevent safe-mode (when a longer, invalid chain is detected)?
  27 2013-02-21 00:25:02 <sipa> maaku: -disablesafemode
  28 2013-02-21 00:25:12 <maaku> hah! awesome thanks
  29 2013-02-21 00:25:27 <gmaxwell> maaku: ... in what condition are you encountering a longer invalid chain?
  30 2013-02-21 00:25:38 <maaku> hostile attack of freicoin
  31 2013-02-21 00:26:14 <gmaxwell> What is the character of the attack?
  32 2013-02-21 00:27:01 <maaku> Someone with 400% the current freicoin network hash is running their own fork with Freicoin-invalid coin bases
  33 2013-02-21 00:27:12 <jouke> hehe
  34 2013-02-21 00:27:14 <swhitt> niiice
  35 2013-02-21 00:27:26 <swhitt> does freicoin use scrypt?
  36 2013-02-21 00:27:32 <maaku> so every official client, including the ones running the official mining pools, seed servers, etc. have entered safe-mode
  37 2013-02-21 00:27:40 <maaku> no, double-sha256
  38 2013-02-21 00:28:11 <gmaxwell> Do you think their intent was to trigger safemode, or?  Does freecoin change the validation model?  Did the attacker not know that nodes would simply reject their invalid blocks?
  39 2013-02-21 00:28:53 <sipa> it's remarkable that the blocks get accepted into the tree, if their coinbase is invalid
  40 2013-02-21 00:29:07 <sipa> that should be checked in the context-independent checks
  41 2013-02-21 00:30:50 <Luke-Jr> gmaxwell: my guess is filling disks
  42 2013-02-21 00:31:39 <maaku> sipa: IIRC the specific added check depends on the block height, and so was placed in ConnectBlock instead of CheckBlock
  43 2013-02-21 00:31:58 <gmaxwell> Luke-Jr: you could do that with valid blocks.
  44 2013-02-21 00:32:04 <Luke-Jr> gmaxwell: tre
  45 2013-02-21 00:32:06 <Luke-Jr> true*
  46 2013-02-21 00:32:12 word_ has quit (Changing host)
  47 2013-02-21 00:32:12 word_ has joined
  48 2013-02-21 00:32:14 word_ is now known as word
  49 2013-02-21 00:32:18 <Luke-Jr> gmaxwell: perhaps they did intend safe mode. more effective shutdown in some ways
  50 2013-02-21 00:33:06 <sipa> maaku: shouldn't be necessary, the height is known in AcceptBlock
  51 2013-02-21 00:33:13 <gmaxwell> Yes... I've seen a lot of people who really understand bitcoin poorly and think a majority miner can do _anything_, so I was just wondering if these people were now attacking things.
  52 2013-02-21 00:33:14 <maaku> gmaxwell: I'm still investigating what their possible motive could be, but DoS via safe-mode is certainly a good theory. They had to know that the change they made would make their blocks rejected by the network
  53 2013-02-21 00:33:55 <gmaxwell> maaku: how exactly are they invalid? e.g. is it some difference that someone might want?  Higher subsidy for the miner or something?
  54 2013-02-21 00:34:36 <gmaxwell> maaku: Depending on the nature of the change — their own nodes would accept it.
  55 2013-02-21 00:34:36 [ken] has quit (Quit: leaving)
  56 2013-02-21 00:35:03 <maaku> gmaxwell: yes. freicoin moves 80% of its initial distribution through a foundation, via hardcoded addresses. the fork simply replaced the foundation addresses with its own.
  57 2013-02-21 00:35:22 <gmaxwell> I'd bet they thought they could just do that.
  58 2013-02-21 00:35:36 <gmaxwell> And their own nodes would accept it, since they've been modified.
  59 2013-02-21 00:36:02 <gmaxwell> maybe they'll even post a modified version and encourage people to accept their foundation instead.
  60 2013-02-21 00:36:44 alexwaters has quit (Quit: Leaving.)
  61 2013-02-21 00:39:04 <maaku> Very likely, although this happened in the past so people are very aware that changing the foundation addresses results in a hard fork. However they did it in such a way as to mask what they're doing (same 80/20 split, but to their own address) and the only FRC coin explorer is on the fork...
  62 2013-02-21 00:40:07 <gmaxwell> ha. Is the explorer on the fork because its incahoots with the fork, or is it on the fork because its not a full freicoin node?
  63 2013-02-21 00:40:11 <Luke-Jr> gmaxwell: did slush ever request a BIP for stratum?
  64 2013-02-21 00:40:40 <gmaxwell> Not as far as I know, but there were bips assigned without being noted anywhere.
  65 2013-02-21 00:40:50 <maaku> gmaxwell: still investigating...
  66 2013-02-21 00:41:52 <Luke-Jr> slush1: is there a BIP assigned for stratum?
  67 2013-02-21 00:42:51 <Luke-Jr> I guess technically speaking, there should be a few.. one for the basic protocol, one for the thinclient protocol, and one for mining
  68 2013-02-21 00:43:08 blishchrot has quit (Ping timeout: 248 seconds)
  69 2013-02-21 00:55:31 <maaku> sipa: so bitcoind never stores orphan blocks?
  70 2013-02-21 00:55:45 D34TH has joined
  71 2013-02-21 00:55:45 D34TH has quit (Changing host)
  72 2013-02-21 00:55:45 D34TH has joined
  73 2013-02-21 00:55:50 <sipa> maaku: depends on your definition of orphan, but if you mean "no parent known", yes
  74 2013-02-21 00:56:10 <maaku> that's what I meant yes
  75 2013-02-21 00:56:25 <Luke-Jr> maaku: in this case, the parent is known
  76 2013-02-21 00:56:34 <maaku> ok cool the freicoin check should be in AcceptBlock() then
  77 2013-02-21 00:58:31 <maaku> I think I may have been lazy because I needed access to nFees and didn't think about this consequence, but that's easily calculated.
  78 2013-02-21 01:08:25 blishchrot has joined
  79 2013-02-21 01:13:47 blishchr1t has joined
  80 2013-02-21 01:14:27 word_ has joined
  81 2013-02-21 01:16:44 blishchrot has quit (Ping timeout: 248 seconds)
  82 2013-02-21 01:17:20 pooler has quit (Ping timeout: 255 seconds)
  83 2013-02-21 01:17:23 word has quit (Ping timeout: 252 seconds)
  84 2013-02-21 01:21:53 rbecker is now known as RBecker
  85 2013-02-21 01:25:17 Arathill has quit (Remote host closed the connection)
  86 2013-02-21 01:25:44 blishchr1t is now known as blishchrot
  87 2013-02-21 01:27:00 andytoshi has quit (Ping timeout: 276 seconds)
  88 2013-02-21 01:29:20 andytoshi has joined
  89 2013-02-21 01:30:08 <gmaxwell> holy crap, sorry guys, but that hardlinking idea was the worst idea ever. It totally breaks windows users little brains.
  90 2013-02-21 01:30:16 unknown45682 has quit (Read error: Connection reset by peer)
  91 2013-02-21 01:30:40 <gmaxwell> And turns them into belligerent zombies who are furious that bitcoin takes 2x the space.
  92 2013-02-21 01:30:56 kytv has left ()
  93 2013-02-21 01:31:45 unknown45682 has joined
  94 2013-02-21 01:32:59 <SomeoneWeird> why isn't it a softlink?
  95 2013-02-21 01:33:06 <jgarzik> gmaxwell: Comm problem.  Just don't mention hardlinking at all.
  96 2013-02-21 01:33:18 <jgarzik> gmaxwell: "delete the extra copy, and all is well"
  97 2013-02-21 01:35:05 word__ has joined
  98 2013-02-21 01:36:41 coblee_ has joined
  99 2013-02-21 01:37:10 <gmaxwell> oh here is a clever attack if you've got a LOT of hashpower.
 100 2013-02-21 01:37:25 <gmaxwell> You outpace the network with invalid blocks, knocking everyone into safemode
 101 2013-02-21 01:37:44 <gmaxwell> Then you mine normally— you're the only miner until you catch up with yourself.
 102 2013-02-21 01:38:17 word_ has quit (Ping timeout: 252 seconds)
 103 2013-02-21 01:38:18 <gmaxwell> I'm not sure what that accomplishes that a normal supermajority attack doesn't...
 104 2013-02-21 01:39:45 coblee has quit (Ping timeout: 264 seconds)
 105 2013-02-21 01:39:45 coblee_ is now known as coblee
 106 2013-02-21 01:39:53 pooler has joined
 107 2013-02-21 01:40:02 <gmaxwell> jgarzik: thanks. Sometimes the simple way is best.
 108 2013-02-21 01:41:29 andytoshi has quit (Quit: WeeChat 0.4.0)
 109 2013-02-21 01:42:58 <jrmithdobbs> gmaxwell: i still don't get how that's confusing
 110 2013-02-21 01:43:19 <jrmithdobbs> gmaxwell: and yet every time the topic comes up there's someone confused by it
 111 2013-02-21 01:47:41 <gmaxwell> jrmithdobbs: all the normal windows tools double count the size of hardlinks
 112 2013-02-21 01:48:01 <gmaxwell> e.g. the explorer report on the directory reports 13GB instead of 7.
 113 2013-02-21 01:49:02 <jrmithdobbs> gmaxwell: it boggles my mind that windows is still dealing with the fat32->ntfs transition
 114 2013-02-21 01:49:11 ielo has quit (Ping timeout: 272 seconds)
 115 2013-02-21 01:49:20 <jrmithdobbs> (because really when it comes down to it, that's what that's a holdover from)
 116 2013-02-21 01:50:18 <jrmithdobbs> gmaxwell: and how is such a horrible fs handling/display error not a blocking bug for release? that's crazy
 117 2013-02-21 01:52:21 qhorin123 has joined
 118 2013-02-21 01:53:36 PhantomSpark has quit (Read error: Connection reset by peer)
 119 2013-02-21 01:54:26 <MC1984> winfs was planned for vista and then scrapped
 120 2013-02-21 01:54:29 <MC1984> no sign of it since
 121 2013-02-21 01:54:38 eckey has joined
 122 2013-02-21 01:54:40 <MC1984> assume stuck with ntfs for more decades
 123 2013-02-21 01:55:25 word__ has quit (Read error: Connection reset by peer)
 124 2013-02-21 01:55:51 word__ has joined
 125 2013-02-21 02:00:50 toffoo has joined
 126 2013-02-21 02:01:08 qhorin123 has quit ()
 127 2013-02-21 02:03:55 JZavala has joined
 128 2013-02-21 02:06:44 axhlf has joined
 129 2013-02-21 02:12:48 <jrmithdobbs> MC1984: they've not even finished the fat32->ntfs migration, how can they even think about winfs realistically? (I kind of think this is what was realized internally, tbqh)
 130 2013-02-21 02:13:15 <jrmithdobbs> (in addition to the crazy MS internal politics, of course)
 131 2013-02-21 02:13:40 <MC1984> sd cards and stuff still come in fat32 by default
 132 2013-02-21 02:13:42 <MC1984> lol
 133 2013-02-21 02:14:11 <MC1984> i even heard they were gonna update fatx again for some reason
 134 2013-02-21 02:14:12 <jrmithdobbs> cause fat makes more sense on nand than ntfs
 135 2013-02-21 02:14:22 <jrmithdobbs> a lot more
 136 2013-02-21 02:14:51 <jrmithdobbs> (fatx is dumb though, what a stupid reason to allow them to re-file that patent, ugh)
 137 2013-02-21 02:15:33 <MC1984> maybe it was exfat
 138 2013-02-21 02:15:35 <MC1984> dunno
 139 2013-02-21 02:15:43 RazielZ has quit (Ping timeout: 256 seconds)
 140 2013-02-21 02:15:45 <MC1984> why is fat better on flash
 141 2013-02-21 02:17:33 coblee has quit (Ping timeout: 264 seconds)
 142 2013-02-21 02:20:57 paraipan has quit (Ping timeout: 276 seconds)
 143 2013-02-21 02:22:20 maaku has quit (Quit: maaku)
 144 2013-02-21 02:28:24 LargoG has quit (Remote host closed the connection)
 145 2013-02-21 02:28:30 <jrmithdobbs> MC1984: lack of journal and semantics on how updates/writes occur
 146 2013-02-21 02:28:56 <jrmithdobbs> MC1984: can be evened out by simpler wear leveling algorithms than busy journals in the same loctian and similar
 147 2013-02-21 02:29:02 HM has quit (Ping timeout: 252 seconds)
 148 2013-02-21 02:29:30 b4tt3r135 has joined
 149 2013-02-21 02:29:31 <MC1984> thought journals were always good
 150 2013-02-21 02:30:06 <MC1984> oh well, the 4gb limit is adeal breaker for me
 151 2013-02-21 02:31:26 eckey has quit (Remote host closed the connection)
 152 2013-02-21 02:34:49 HM has joined
 153 2013-02-21 02:35:59 rdponticelli has joined
 154 2013-02-21 02:37:33 word has joined
 155 2013-02-21 02:37:33 darkskiez has quit (Ping timeout: 276 seconds)
 156 2013-02-21 02:39:25 darkskiez has joined
 157 2013-02-21 02:39:47 paraipan has joined
 158 2013-02-21 02:39:53 word__ has quit (Ping timeout: 252 seconds)
 159 2013-02-21 02:42:28 devrandom has quit (Remote host closed the connection)
 160 2013-02-21 02:42:34 rdponticelli has quit (Remote host closed the connection)
 161 2013-02-21 02:42:34 MobiusL has quit (Remote host closed the connection)
 162 2013-02-21 02:44:18 MobiusL has joined
 163 2013-02-21 02:47:56 [\\\]_l is now known as [\\\]
 164 2013-02-21 02:48:21 coblee has joined
 165 2013-02-21 02:49:56 devrandom has joined
 166 2013-02-21 02:53:32 skeledrew has joined
 167 2013-02-21 02:54:22 skeledrew1 has quit (Ping timeout: 248 seconds)
 168 2013-02-21 02:54:25 b4tt3r135 has quit (Ping timeout: 272 seconds)
 169 2013-02-21 03:07:02 rdponticelli has joined
 170 2013-02-21 03:08:11 D34TH has quit (Read error: Connection reset by peer)
 171 2013-02-21 03:09:53 RBecker is now known as rbecker
 172 2013-02-21 03:16:51 rdponticelli has quit (Ping timeout: 276 seconds)
 173 2013-02-21 03:17:13 <Luke-Jr> gmaxwell: around?
 174 2013-02-21 03:18:42 paybitcoin has quit (Read error: Connection reset by peer)
 175 2013-02-21 03:18:55 word_ has joined
 176 2013-02-21 03:19:23 <gmaxwell> Luke-Jr: kinda
 177 2013-02-21 03:19:47 <Luke-Jr> gmaxwell: any chance you want to pop into #stratum to give slush some BIP numbers? :p
 178 2013-02-21 03:21:08 rdponticelli has joined
 179 2013-02-21 03:21:09 word has quit (Ping timeout: 252 seconds)
 180 2013-02-21 03:27:15 rdponticelli has quit (Ping timeout: 276 seconds)
 181 2013-02-21 03:27:34 alexwaters has joined
 182 2013-02-21 03:41:05 Maged has joined
 183 2013-02-21 03:43:24 Goonie has quit (Ping timeout: 248 seconds)
 184 2013-02-21 03:46:23 Mrcheesenips has quit (Ping timeout: 260 seconds)
 185 2013-02-21 03:49:51 Kireji has joined
 186 2013-02-21 03:50:18 <Kireji> ok, WTF here.  I just tried to put my old wallet.dat into 0.7.2, and I got "Bitcoin: Error initializing database environment /home/dugan/.bitcoin! To recover, BACKUP THAT DIRECTORY, then remove everything from it except for wallet.dat."
 187 2013-02-21 03:51:19 <Kireji> I'm pretty freaked out, as all my bitcoins are in my old wallet file, and it took more than a week to download the 7.2GB of data now in .bitcoin
 188 2013-02-21 03:52:03 <gmaxwell> Your bitcoins are probably fine.
 189 2013-02-21 03:52:13 fiesh has quit (Ping timeout: 260 seconds)
 190 2013-02-21 03:52:13 fiesh_ has joined
 191 2013-02-21 03:52:40 <Luke-Jr> Kireji: how about upgrading to 0.8 while you're at it?
 192 2013-02-21 03:52:47 <Luke-Jr> Kireji: it will probably just work
 193 2013-02-21 03:53:07 <gmaxwell> go install 0.8.0, it will reindex the blockchain, this takes a bit— but a bit is an hour or two. That should clearup whatever issue you're having.
 194 2013-02-21 03:53:47 <Kireji> ok
 195 2013-02-21 04:00:52 paraipan has quit (Quit: Saliendo)
 196 2013-02-21 04:01:21 EagleTM has quit (Ping timeout: 264 seconds)
 197 2013-02-21 04:01:45 valparaiso_ has joined
 198 2013-02-21 04:03:06 rdponticelli has joined
 199 2013-02-21 04:03:34 Tritonio1 has left ()
 200 2013-02-21 04:03:44 nouitfvf has quit (Ping timeout: 255 seconds)
 201 2013-02-21 04:05:19 valparaiso has quit (Ping timeout: 276 seconds)
 202 2013-02-21 04:05:19 valparaiso_ is now known as valparaiso
 203 2013-02-21 04:09:26 owowo has quit (Quit: sayonara)
 204 2013-02-21 04:11:31 d4de has joined
 205 2013-02-21 04:11:50 Kireji has left ()
 206 2013-02-21 04:16:55 MC1984 has quit (Read error: Connection reset by peer)
 207 2013-02-21 04:16:59 MasterChief has joined
 208 2013-02-21 04:17:23 MasterChief is now known as Guest61604
 209 2013-02-21 04:23:23 gruvfunk has quit (Excess Flood)
 210 2013-02-21 04:24:18 b4tt3r135 has joined
 211 2013-02-21 04:24:36 Pasha has joined
 212 2013-02-21 04:25:07 Cory has quit (Ping timeout: 240 seconds)
 213 2013-02-21 04:28:21 rdponticelli has quit (Ping timeout: 276 seconds)
 214 2013-02-21 04:28:21 Zarutian has quit (Quit: Zarutian)
 215 2013-02-21 04:28:51 Cory has joined
 216 2013-02-21 04:29:44 TradeFortress has joined
 217 2013-02-21 04:29:50 Pasha has quit (Ping timeout: 255 seconds)
 218 2013-02-21 04:31:27 Kireji has joined
 219 2013-02-21 04:32:55 <Kireji> in the linux commandline client, why does walletpassphrase require the passphrase on the comandline?  this adds it to bash history, puts the passphrase into the process table, ... not really a secure method.  same for encryptwallet
 220 2013-02-21 04:41:37 <Luke-Jr> Kireji: because it's not really a client, it's just for testing crap
 221 2013-02-21 04:41:50 <Luke-Jr> Kireji: it's not supposed to be used in production
 222 2013-02-21 04:47:01 comboy has quit (Remote host closed the connection)
 223 2013-02-21 04:47:12 comboy has joined
 224 2013-02-21 04:47:20 <slush1> Luke-Jr: really?
 225 2013-02-21 04:47:32 <Luke-Jr> slush1: ?
 226 2013-02-21 04:47:45 <slush1> Luke-Jr: what's the client for production then? :)
 227 2013-02-21 04:47:57 <Luke-Jr> python-bitcoinrpc
 228 2013-02-21 04:48:03 <Luke-Jr> or your favourite JSON-RPC client :p
 229 2013-02-21 04:48:30 <slush1> oh you mean that shell interface isn't for production. agree.
 230 2013-02-21 04:48:46 <slush1> I understood that you're talking about bitcoind ;)
 231 2013-02-21 04:48:55 <Luke-Jr> oops
 232 2013-02-21 04:49:28 <Luke-Jr> gotta remember to be more clear on that
 233 2013-02-21 04:49:46 <Luke-Jr> I think you're the second one to misunderstand it that way when I said that<.<
 234 2013-02-21 04:50:21 JWU42 has quit (Read error: Connection reset by peer)
 235 2013-02-21 04:50:57 JWU42 has joined
 236 2013-02-21 05:00:22 <Kireji> Luke-Jr: I am using bitcoind
 237 2013-02-21 05:01:16 <Kireji> is there a different commandline client instead of calling bitcoind on the command line?
 238 2013-02-21 05:01:37 coolsa has quit (Quit: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
 239 2013-02-21 05:01:40 <Luke-Jr> Kireji: bitcoind is not a commandline client, it is a JSON-RPC server client; I am not aware of any commandline clients in existence yet
 240 2013-02-21 05:02:22 <Kireji> well, that explains it
 241 2013-02-21 05:02:24 <Kireji> thanks
 242 2013-02-21 05:02:43 TheSeven has quit (Disconnected by services)
 243 2013-02-21 05:02:50 [7] has joined
 244 2013-02-21 05:05:42 b4tt3r135 has quit (Quit: Nettalk6 - www.ntalk.de)
 245 2013-02-21 05:12:36 ProfMac has joined
 246 2013-02-21 05:13:51 coolsa has joined
 247 2013-02-21 05:14:20 <gmaxwell> Kireji: you can happily keep the passphrase out of your history: https://bitcointalk.org/index.php?topic=54671.0
 248 2013-02-21 05:15:24 <gmaxwell> Luke-Jr: Basically everyone that talks in this room using the rpc client from the commandline, so perhaps its a little disingenuous to say it isn't one. :)
 249 2013-02-21 05:15:50 <gmaxwell> (heck, I even like it— as evidence by my psycho shell script automation of it!)
 250 2013-02-21 05:20:28 <Luke-Jr> gmaxwell: well, it doesn't meet the minimum reasonable requirements for one as noted by Kireji :P
 251 2013-02-21 05:25:59 <gmaxwell> an interactive method for getting the keys would be like .. dunno, four lines of code. :P
 252 2013-02-21 05:30:56 <Luke-Jr> gmaxwell: even hiding the input typed? :P
 253 2013-02-21 05:33:43 alexwaters has quit (Quit: Leaving.)
 254 2013-02-21 05:33:51 xorgate has quit (Ping timeout: 256 seconds)
 255 2013-02-21 05:36:52 ProfMac has quit (Quit: Page closed)
 256 2013-02-21 05:38:48 hattorihanzo has joined
 257 2013-02-21 05:40:27 FredEE has quit (Quit: FredEE)
 258 2013-02-21 05:40:36 root2 has quit (Quit: Leaving)
 259 2013-02-21 05:41:33 word_ has quit (Read error: Connection reset by peer)
 260 2013-02-21 05:41:56 word_ has joined
 261 2013-02-21 05:43:11 Mrcheesenips has joined
 262 2013-02-21 05:43:11 Mrcheesenips has quit (Changing host)
 263 2013-02-21 05:43:11 Mrcheesenips has joined
 264 2013-02-21 05:45:09 <hattorihanzo> is there a command line brainwallet?
 265 2013-02-21 05:46:30 <hattorihanzo> On a side note, I'm working on some mod to bitcoin-testnet-box
 266 2013-02-21 05:46:37 <hattorihanzo> checkout my repo here https://github.com/willwharton/bitcoin-testnet-box/blob/master/testnet-box
 267 2013-02-21 05:47:32 <gmaxwell> hattorihanzo: 'brainwallets' are a generally a poor idea, at least as is often done. Because there is no salt an attacker gets an enormous precomputation advantage, and people greatly overestimate their memory and how random they are able to be.
 268 2013-02-21 05:49:41 <hattorihanzo> gmaxwell: ;)
 269 2013-02-21 05:50:00 <gmaxwell> (and, no— I'm not aware of any commandline software for it)
 270 2013-02-21 05:50:21 <hattorihanzo> welp looks like im rewriting some js to c tonight
 271 2013-02-21 05:50:59 <hattorihanzo> but ok.. whats ur thoughts on makeing a better interface for testnet-box
 272 2013-02-21 05:51:53 <hattorihanzo> i plan on writing an ebook for setting up bitcoind + testnet-box + abe for devs
 273 2013-02-21 05:52:28 JDuke128 has joined
 274 2013-02-21 05:53:30 <gmaxwell> dunno, I'm perfectly happy with no 'interface' at all— I create shell aliases for different bitcoin daemons, e.g. tn is testnet b19 is bitcoin 0.3.19 b7 is bitcoin 0.7.2, bd is bitcoin git, so I'm not the right person to ask.
 275 2013-02-21 05:53:52 <gmaxwell> Does abe work w/ testnet? I've never seen a public abe install with testnet.
 276 2013-02-21 05:54:17 <SomeoneWeird> wouldn't see why not
 277 2013-02-21 05:54:20 <gmaxwell> I'm not sure what useful thing abe would provide for testnet over what you can get now from the rpc.
 278 2013-02-21 05:56:20 <weex> is there an encryption scheme were 1 of n secrets can be used to decrypt the data but isn't just n copies of the data?
 279 2013-02-21 05:56:55 <gmaxwell> weex: why do you care if it isn't just N copies of the data?
 280 2013-02-21 05:57:05 <weex> i guess it could be n copies of a key
 281 2013-02-21 05:57:13 <gmaxwell> well there you go then.
 282 2013-02-21 05:57:17 <weex> didn't want to increase storage too much
 283 2013-02-21 06:05:44 HM has quit (Ping timeout: 252 seconds)
 284 2013-02-21 06:05:56 andytoshi has joined
 285 2013-02-21 06:07:27 <Kireji> gmaxwell: Luke-Jr: thanks
 286 2013-02-21 06:08:30 <Kireji> I'm 4h post 0.8.0 upgrade.  "bitcoind getbalance" shows correct balance, but "bitcoind listreceivedbyaddress" shows some addresses off by the generation amount on the address
 287 2013-02-21 06:08:33 JZavala has quit (Ping timeout: 252 seconds)
 288 2013-02-21 06:08:54 <Kireji> will this resolve once the client has had more time, or is there an error somewhere?
 289 2013-02-21 06:11:16 <Luke-Jr> Kireji: generation isn't considered confirmed for 120 blocks
 290 2013-02-21 06:13:40 root2 has joined
 291 2013-02-21 06:13:56 <Kireji> his was on block  133,000
 292 2013-02-21 06:13:59 <Kireji> ish
 293 2013-02-21 06:15:15 <Kireji> so a long time ago for that address
 294 2013-02-21 06:16:40 m00p has quit (Remote host closed the connection)
 295 2013-02-21 06:17:00 andytoshi has quit (Quit: WeeChat 0.4.0)
 296 2013-02-21 06:17:16 Motest003 has joined
 297 2013-02-21 06:17:22 Motest003 has quit (Client Quit)
 298 2013-02-21 06:23:08 word_ has quit (Read error: Connection reset by peer)
 299 2013-02-21 06:23:35 word_ has joined
 300 2013-02-21 06:28:25 <Luke-Jr> Kireji: sounds like a bug, please report
 301 2013-02-21 06:30:39 <Kireji> ok, sure.  where?
 302 2013-02-21 06:30:53 <Luke-Jr> github issues
 303 2013-02-21 06:31:36 <Kireji> k
 304 2013-02-21 06:35:21 Mango-chan has joined
 305 2013-02-21 06:35:21 Mango-chan has quit (Changing host)
 306 2013-02-21 06:35:21 Mango-chan has joined
 307 2013-02-21 06:35:28 Mango-chan has left ()
 308 2013-02-21 06:35:45 Jackneill has joined
 309 2013-02-21 06:37:16 raad287 has joined
 310 2013-02-21 06:41:22 Jackneill has quit (Quit: Leaving)
 311 2013-02-21 06:43:10 awfwadaw has joined
 312 2013-02-21 06:45:09 <Kireji> Luke-Jr: 2326 submitted
 313 2013-02-21 06:46:06 Maged has quit (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344])
 314 2013-02-21 06:49:50 xorgate has joined
 315 2013-02-21 06:53:11 root2 has quit (Ping timeout: 272 seconds)
 316 2013-02-21 06:56:08 root2 has joined
 317 2013-02-21 07:01:13 ciphermonk has joined
 318 2013-02-21 07:05:47 nouitfvf has joined
 319 2013-02-21 07:06:51 raad287 has quit (Quit: Leaving)
 320 2013-02-21 07:13:19 Kireji has left ()
 321 2013-02-21 07:15:38 reizuki__ has quit (Quit: Konversation terminated!)
 322 2013-02-21 07:15:59 root2 has quit (Ping timeout: 272 seconds)
 323 2013-02-21 07:18:35 reizuki__ has joined
 324 2013-02-21 07:18:35 reizuki__ has quit (Changing host)
 325 2013-02-21 07:18:35 reizuki__ has joined
 326 2013-02-21 07:24:34 RazielZ has joined
 327 2013-02-21 07:26:39 <gmaxwell> And this is how namecoin died, ... not with a bang but with a .. burp?  https://github.com/runn1ng/namecoin-files
 328 2013-02-21 07:26:53 reizuki__ has quit (Ping timeout: 260 seconds)
 329 2013-02-21 07:30:06 <hattorihanzo> found this pastebin to make brainwallets: http://pastebin.com/hzehdrzk
 330 2013-02-21 07:30:52 <hattorihanzo> edited ~5 lines and it did what I wanted it to: https://github.com/willwharton/pybrainwallet
 331 2013-02-21 07:36:42 reizuki__ has joined
 332 2013-02-21 07:36:42 reizuki__ has quit (Changing host)
 333 2013-02-21 07:36:42 reizuki__ has joined
 334 2013-02-21 07:38:20 <gmaxwell> again. I strongly recommend against using something like that. People doing that have gotten ripped off when their believed to be secure passphrase got guessed.
 335 2013-02-21 07:39:53 AtashiCon has quit (Quit: AtashiCon)
 336 2013-02-21 07:46:29 <hattorihanzo> gmaxwell: it doesnt have to be a string mnemonic, it could be the hash of something else
 337 2013-02-21 07:47:32 <hattorihanzo> i just wanted a way to generate a deterministic address from a string
 338 2013-02-21 07:48:02 <hattorihanzo> other than on brainwallet
 339 2013-02-21 07:49:38 <gmaxwell> if it doesn't have to have a string mnemonic then do bitcoind dumpprivkey `bitcoind getnewaddress`
 340 2013-02-21 07:49:59 <gmaxwell> the result is a determinstic (see, its a string and the string doesn't change) private key.
 341 2013-02-21 07:50:04 AtashiCon has joined
 342 2013-02-21 07:50:17 <hattorihanzo> not exactly what i meant, but sure
 343 2013-02-21 07:50:42 <gmaxwell> As a bonus, it's a private key for a compressed pubkey, so the transactions aren't bloated. And it has full entropy, so its not going to get gussed.
 344 2013-02-21 07:51:29 <hattorihanzo> not really the point
 345 2013-02-21 07:52:14 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
 346 2013-02-21 07:58:38 <hattorihanzo> but its really my question at fault, after figure it out
 347 2013-02-21 07:59:09 <hattorihanzo> i should of asked how to create an address from a common seed
 348 2013-02-21 07:59:45 <hattorihanzo> im thinking something like the hash of a image or something random that someone else would know, but be comepletly discreet telling them
 349 2013-02-21 07:59:56 <Luke-Jr> gmaxwell: WTF
 350 2013-02-21 08:00:17 <hattorihanzo> its not abount mnemonic string
 351 2013-02-21 08:00:23 <hattorihanzo> its about any string
 352 2013-02-21 08:01:18 <hattorihanzo> u know; its in the place where I put that thing that time
 353 2013-02-21 08:01:33 <gmaxwell> Luke-Jr: wrt namecoin, right?
 354 2013-02-21 08:01:37 <Luke-Jr> gmaxwell: yes
 355 2013-02-21 08:01:45 <Luke-Jr> gmaxwell: I think it's time Eligius shuts off namecoin
 356 2013-02-21 08:02:26 <gmaxwell> yea... as I said in #bitcoin — as soon as a few gb of junk is added pools will shut it off
 357 2013-02-21 08:03:42 Goonie has joined
 358 2013-02-21 08:05:59 paybitcoin has joined
 359 2013-02-21 08:07:58 ielo has joined
 360 2013-02-21 08:15:32 ovidiusoft has joined
 361 2013-02-21 08:16:34 ovidiusoft has quit (Client Quit)
 362 2013-02-21 08:16:52 nus has quit (Ping timeout: 276 seconds)
 363 2013-02-21 08:18:47 jdnavarro has joined
 364 2013-02-21 08:29:42 gfinn has quit (Remote host closed the connection)
 365 2013-02-21 08:31:18 [\\\] has quit (Remote host closed the connection)
 366 2013-02-21 08:33:03 [\\\] has joined
 367 2013-02-21 08:47:27 coolsa has quit (Quit: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,)
 368 2013-02-21 08:50:21 ielo has quit (Ping timeout: 272 seconds)
 369 2013-02-21 09:10:46 denisx has joined
 370 2013-02-21 09:10:50 coolsa has joined
 371 2013-02-21 09:13:28 valparaiso has quit (Read error: Connection reset by peer)
 372 2013-02-21 09:13:44 valparaiso has joined
 373 2013-02-21 09:19:45 <denisx> I say the osx gui version of bitcoin still has problems with 100% load
 374 2013-02-21 09:20:00 ielo has joined
 375 2013-02-21 09:20:04 <denisx> I don't have this problem with my selfbuild commandline osx version
 376 2013-02-21 09:20:33 <denisx> and the 100% load is per CPU!
 377 2013-02-21 09:20:55 <denisx> per core even
 378 2013-02-21 09:21:11 valparaiso_ has joined
 379 2013-02-21 09:22:09 <denisx> maybe it is a GUI problem
 380 2013-02-21 09:22:34 dooglus has quit (Remote host closed the connection)
 381 2013-02-21 09:22:49 valparaiso has quit (Ping timeout: 244 seconds)
 382 2013-02-21 09:22:49 valparaiso_ is now known as valparaiso
 383 2013-02-21 09:23:16 <jouke> Luke-Jr: how is the data gathered for the chart that shows different branches? Are those nodes currently connected to your node?
 384 2013-02-21 09:23:40 <Luke-Jr> jouke: sipa's bitcoinseeder thing
 385 2013-02-21 09:24:17 <sipa> denisx: sure that's not just sigchecking?
 386 2013-02-21 09:24:40 ielo has quit (Read error: Operation timed out)
 387 2013-02-21 09:24:44 dooglus has joined
 388 2013-02-21 09:24:44 <denisx> sipa: on my harddisk based machine I needed 5min for 1100 blocks to update
 389 2013-02-21 09:24:58 dparrish has quit (Remote host closed the connection)
 390 2013-02-21 09:25:06 <denisx> on the ssd one I needed 2 hours for 5000 blocks
 391 2013-02-21 09:25:38 <gmaxwell> those numbers are all crazy... but there isn't enough detail to say whats wrong for you.
 392 2013-02-21 09:25:47 <gmaxwell> I can reindex the whole chain in something like an hour.
 393 2013-02-21 09:26:12 <Luke-Jr> gmaxwell: on Mac?
 394 2013-02-21 09:27:11 <denisx> ok, to exclude some diskblocksize ssd problem I start the gui version on the harddisk machine too
 395 2013-02-21 09:28:40 <gmaxwell> denisx: oh hey, is this machine ZFS?
 396 2013-02-21 09:28:49 <denisx> gmaxwell: no
 397 2013-02-21 09:29:06 <sipa> gmaxwell: i thought namecoin already was ab arbitrary key/value store... but he seems to need to encode everything as domain entries?
 398 2013-02-21 09:29:09 <gmaxwell> at least bdb performance was known to be pessimal on zfs, but that wasn't expected for 0.8 anyways but I thought I'd ask.
 399 2013-02-21 09:29:30 <gmaxwell> sipa: yea, because using it properly wouldn't be spammy enough? I dunno why.
 400 2013-02-21 09:31:41 <doublec> sipa: the domain is the key in namecoin
 401 2013-02-21 09:32:25 <doublec> so it's a key/value store. When used for domains the key is the domain and the value is the ip address (or whatever)
 402 2013-02-21 09:33:38 <gmaxwell> doublec: I thought there were other namespaces though?
 403 2013-02-21 09:35:36 <doublec> gmaxwell: there are but namespaces are really just a prefix on the name
 404 2013-02-21 09:35:46 <denisx> ok, starting now fresh on osx with harddisk
 405 2013-02-21 09:35:49 <doublec> gmaxwell: so domains are prefixed by d/ which is the 'namespace'
 406 2013-02-21 09:36:02 <doublec> the filesharing thing prefixes with something else iirc
 407 2013-02-21 09:36:09 <gmaxwell> ah, okay!
 408 2013-02-21 09:36:12 toffoo has quit ()
 409 2013-02-21 09:36:27 <doublec> seems to use fp/
 410 2013-02-21 09:36:42 dparrish has joined
 411 2013-02-21 09:37:03 <gmaxwell> seems likely to me that once that tool runs some big pools out of diskspace... it'll be over for namecoin.
 412 2013-02-21 09:37:28 <doublec> looks like some experimentation going on: http://explorer.dot-bit.org/
 413 2013-02-21 09:37:38 <doublec> there's some fb/ prefixes that just use a hash
 414 2013-02-21 09:38:03 <doublec> gmaxwell: it's already over I think. No stratum pools are supporting it.
 415 2013-02-21 09:38:19 <doublec> so as their getwork userbase dies so will the namecoin hashrate
 416 2013-02-21 09:38:53 <CodeShark> namecoin is dead?
 417 2013-02-21 09:38:55 <gmaxwell> doublec: really? why?  P2pool stratum supports it.
 418 2013-02-21 09:39:04 <doublec> maybe this will motivate the namecoind devs to do something...
 419 2013-02-21 09:39:18 <gmaxwell> are there any namecoin devs anymore? (are they even on IRC?)
 420 2013-02-21 09:39:35 <doublec> gmaxwell: I think their motivation to support it is low. Graet mentioned in #namecoin that slush, btcguild and ozcoin were dropping it.
 421 2013-02-21 09:39:55 <doublec> gmaxwell: khalahan is the current namecoin dev
 422 2013-02-21 09:39:59 <doublec> he's on irc
 423 2013-02-21 09:40:06 <doublec> intermittently
 424 2013-02-21 09:41:16 <kinlo> i'm planning to support it
 425 2013-02-21 09:41:18 <kinlo> doublec: are you going to drop it?
 426 2013-02-21 09:41:22 <doublec> kinlo: no
 427 2013-02-21 09:41:38 <doublec> assuming it doesn't end up with a multigig blockchain of files of course
 428 2013-02-21 09:42:24 <doublec> khalahan should consider upping the registration fees until more work is done in developing it
 429 2013-02-21 09:42:39 <gmaxwell> doublec: that should have happened a year ago.
 430 2013-02-21 09:42:53 <doublec> yeah, it should never have been reduced
 431 2013-02-21 09:43:10 <gmaxwell> the economics of registration fees were never solved there in any useful way.
 432 2013-02-21 09:43:16 <doublec> they had a plan in place for it to reduce over time then decided to drop them drastically
 433 2013-02-21 09:43:21 <doublec> right
 434 2013-02-21 09:48:17 brwyatt is now known as brwyatt|Away
 435 2013-02-21 09:50:09 bitcoinbulletin has quit (Ping timeout: 245 seconds)
 436 2013-02-21 09:50:10 upb has quit (Ping timeout: 245 seconds)
 437 2013-02-21 09:51:12 upb has joined
 438 2013-02-21 09:51:12 upb has quit (Changing host)
 439 2013-02-21 09:51:12 upb has joined
 440 2013-02-21 09:51:58 word__ has joined
 441 2013-02-21 09:53:23 <Luke-Jr> doublec: speak for your own pool :P
 442 2013-02-21 09:54:02 <doublec> Luke-Jr: what am I speaking for?
 443 2013-02-21 09:54:13 <Luke-Jr> [09:19:58] <doublec> gmaxwell: it's already over I think. -----> No stratum pools are supporting it. <------
 444 2013-02-21 09:54:24 <doublec> Luke-Jr: you support stratum?
 445 2013-02-21 09:54:28 <Luke-Jr> yes
 446 2013-02-21 09:54:38 <doublec> I stand corrected
 447 2013-02-21 09:55:05 <Luke-Jr> not for long if Eligius removes it XD
 448 2013-02-21 09:55:07 <gmaxwell> well, if its only eligius mining namecoin, perhaps you can change the fees by fiat. :-/
 449 2013-02-21 09:55:09 <doublec> haha
 450 2013-02-21 09:55:18 word_ has quit (Ping timeout: 276 seconds)
 451 2013-02-21 09:56:40 <Luke-Jr> gmaxwell: I never really liked Namecoin anyway. Names need court oversight IMO.
 452 2013-02-21 09:56:58 <Diablo-D3> so namecoin is dead now?
 453 2013-02-21 09:57:04 <Luke-Jr> it's not like money that has no effect on unrelated third-parties
 454 2013-02-21 09:57:11 <gmaxwell> Luke-Jr: you can have court oversight with namecoin in any case.
 455 2013-02-21 09:57:18 <Diablo-D3> gmaxwell: no you cant
 456 2013-02-21 09:57:34 <sipa> denisx: you say 5000 blocks are slower on one system than 1100 on another, but are you talking about the same blocks?
 457 2013-02-21 09:57:45 <Luke-Jr> gmaxwell: ?
 458 2013-02-21 09:57:52 <gmaxwell> Luke-Jr: just have the court publish their blacklists and conformat resolvers that check the applicable ones. Even solves the screwed up jurisdictional issues.
 459 2013-02-21 09:57:56 <Diablo-D3> gmaxwell: DNS means I can sue someone, win, and have the registrar give me the domain
 460 2013-02-21 09:58:04 <sipa> denisx: sigchecking is only enabled after the last checkpoint
 461 2013-02-21 09:58:19 <Diablo-D3> gmaxwell: namecoin means the guy can choose to go to jail for contempt and I still dont get the name
 462 2013-02-21 09:58:20 bitcoinbulletin has joined
 463 2013-02-21 09:58:21 <denisx> sipa: I meant the last blocks in each case
 464 2013-02-21 09:58:21 <Luke-Jr> gmaxwell: Namecoin is a failure if the resolvers aren't client-side.
 465 2013-02-21 09:58:38 <denisx> sipa: both after the checkpoint
 466 2013-02-21 09:58:41 <gmaxwell> Diablo-D3: you can do that for namecoin too— if you know who the party is ... the court orders them to give over the name and they end up in jail for contempt of court if they don't.
 467 2013-02-21 09:58:49 <sipa> denisx: ok, strange
 468 2013-02-21 09:59:00 <Diablo-D3> gmaxwell: thats what I just said
 469 2013-02-21 09:59:06 <denisx> sipa: I report back when my machine here is done
 470 2013-02-21 09:59:13 <Luke-Jr> gmaxwell: his point is that he wants the choice to go to jail
 471 2013-02-21 09:59:20 <gmaxwell> Diablo-D3: we manage to survive that way on basically all other kinds of property.
 472 2013-02-21 09:59:34 <gmaxwell> I think thats actually a pretty fair balance.
 473 2013-02-21 09:59:49 <Luke-Jr> gmaxwell: you're making his point <.<
 474 2013-02-21 09:59:52 <Diablo-D3> gmaxwell: no, lets say I get a judgement against someone and they refuse to pay
 475 2013-02-21 09:59:53 <gmaxwell> The ability to choose to go to jail for your cause is a useful backstop.
 476 2013-02-21 10:00:01 <Diablo-D3> gmaxwell: in texas, I can have a local sherrif go in and ransack their house
 477 2013-02-21 10:00:27 <Luke-Jr> Diablo-D3: I wouldn't bet on that.
 478 2013-02-21 10:00:41 <Luke-Jr> pretty sure in Texas, nobody can bother you at your own place.
 479 2013-02-21 10:00:45 <gmaxwell> Diablo-D3: sheriff recovery is actually not so smooth, and generally stuff is taken by consent for a sheriff action. In businesses thats always the case.
 480 2013-02-21 10:01:24 <Diablo-D3> Luke-Jr: texas isnt the dreamland that "americans" think it is
 481 2013-02-21 10:01:38 <Diablo-D3> Luke-Jr: I mean, they have both the bushes and ron paul living there
 482 2013-02-21 10:02:40 <Luke-Jr> Diablo-D3: pretty sure if they were regularly ransacking people, they'd either not be living or not be there
 483 2013-02-21 10:03:16 * Diablo-D3 shrugs
 484 2013-02-21 10:03:21 <Diablo-D3> most people actually comply with court orders
 485 2013-02-21 10:03:26 <Luke-Jr> exactly
 486 2013-02-21 10:03:36 b00tkitz has joined
 487 2013-02-21 10:03:38 <doublec> Luke-Jr: it's true that the inability to negotiate with a name holder in namecoin has put people off
 488 2013-02-21 10:03:59 <doublec> if someone owns the name you want, you can't get in touch with them unless they've provided contact details in the value field
 489 2013-02-21 10:04:40 <sipa> how about the inability to negotiate with the nameservers that will serve the data?
 490 2013-02-21 10:04:55 <Luke-Jr> mtgox.bit = "Haha, I'm holding this name hostage unless you pay me 25 million BTC!"
 491 2013-02-21 10:04:58 <Luke-Jr> :P
 492 2013-02-21 10:05:02 <Diablo-D3> how about the inability to actually find other namecoin users that use it?
 493 2013-02-21 10:06:14 <Luke-Jr> why the heck am I still awake? -.-
 494 2013-02-21 10:07:02 <Luke-Jr> night..
 495 2013-02-21 10:07:13 <gmaxwell> I like my new timezone, I get to see sipa in his morning without saying up all night. :)
 496 2013-02-21 10:08:03 <Diablo-D3> you moved?
 497 2013-02-21 10:08:04 <sipa> haha
 498 2013-02-21 10:08:12 <sipa> hmmm: http://www.reddit.com/r/Bitcoin/comments/18w8hc/please_upgrade_to_bitcoin_08_and_help/c8iwjl1
 499 2013-02-21 10:08:31 <gmaxwell> Diablo-D3: Yes, no longer living at the CIA. :P I'm in california now.
 500 2013-02-21 10:08:36 <sipa> seems leveldb fails on windows network drives
 501 2013-02-21 10:08:46 <Diablo-D3> sipa: thats normal
 502 2013-02-21 10:08:52 <sipa> gmaxwell: will you be at the conference?
 503 2013-02-21 10:08:55 <Diablo-D3> windows smb supporrt is horrid
 504 2013-02-21 10:09:06 <Diablo-D3> I dont even know why microsoft still ships it
 505 2013-02-21 10:09:07 <sipa> Diablo-D3: it's a regression nonetheless
 506 2013-02-21 10:09:08 <Diablo-D3> its always broken and breaks shit constantly
 507 2013-02-21 10:09:23 <gmaxwell> sipa: I suppose its obligatory, I guess I should register.
 508 2013-02-21 10:09:27 <Diablo-D3> do they even support sparse files yet?
 509 2013-02-21 10:09:36 <gmaxwell> sipa: perhaps the issue is the hardlinking code?
 510 2013-02-21 10:09:40 <Diablo-D3> last time I cared to give a shit, samba still choked on those
 511 2013-02-21 10:09:56 <gmaxwell> he's not saying if the directory was empty I think?
 512 2013-02-21 10:10:05 <Diablo-D3> gmaxwell: hardlinking as in ln without -s?
 513 2013-02-21 10:10:15 <sipa> gmaxwell: no, that's optional, and would give an other error
 514 2013-02-21 10:10:16 <Diablo-D3> windows doesnt support hardlinks. or softlinks, really.
 515 2013-02-21 10:10:25 <sipa> it does
 516 2013-02-21 10:10:28 <gmaxwell> Diablo-D3: windows actually has hardlinks— surprised me too!
 517 2013-02-21 10:10:33 <sipa> only harflinks
 518 2013-02-21 10:10:36 <Diablo-D3> wait, what?
 519 2013-02-21 10:10:40 <Diablo-D3> where?
 520 2013-02-21 10:10:42 <gmaxwell> Diablo-D3: they totally break windows users brains though.
 521 2013-02-21 10:10:43 <sipa> and only on ntfs
 522 2013-02-21 10:10:58 <Diablo-D3> thats just wrong. so very wrong.
 523 2013-02-21 10:11:30 s4m20 has joined
 524 2013-02-21 10:12:27 <gmaxwell> in any case, whatever the windows version of strace is— thats what we want from that user
 525 2013-02-21 10:12:57 <gmaxwell> my next guess is that its some stat call or something that gives a wonky result
 526 2013-02-21 10:13:42 <sipa> or leveldb windows that relies on mmapping perhaps
 527 2013-02-21 10:14:42 <sipa> and fails on network drives
 528 2013-02-21 10:15:04 <Diablo-D3> sipa: yeah, you cant mmap network drives
 529 2013-02-21 10:15:10 <Diablo-D3> well, _depends_
 530 2013-02-21 10:15:19 <Diablo-D3> I think you CAN mmap mounted drives
 531 2013-02-21 10:15:26 <Diablo-D3> because those show up even in legacy win9x apps
 532 2013-02-21 10:15:39 <Diablo-D3> its //machinename/foo style addresses that wont work
 533 2013-02-21 10:15:56 <Diablo-D3> I dont want to boot windows and install mingw to find out
 534 2013-02-21 10:16:25 <Diablo-D3> infact, I like pretending windows doesnt exist
 535 2013-02-21 10:16:27 <Diablo-D3> it makes me happy
 536 2013-02-21 10:16:48 <sipa> me too, but painful when confronted with reality
 537 2013-02-21 10:17:13 <Diablo-D3> its painful to close bugs WONTFIX?
 538 2013-02-21 10:17:24 B0g4r7 has quit (Ping timeout: 276 seconds)
 539 2013-02-21 10:18:35 sturles has quit (Remote host closed the connection)
 540 2013-02-21 10:18:41 <gmaxwell> wow, I'd missed the blocksize threads in the general forum until an hour ago... dear lord, its a forrest fire.
 541 2013-02-21 10:19:15 <Diablo-D3> oh, right, the forum
 542 2013-02-21 10:19:19 <Diablo-D3> that thing still exists?
 543 2013-02-21 10:19:47 <petertodd> gmaxwell: emphasis on threads...
 544 2013-02-21 10:20:29 one_zero has quit ()
 545 2013-02-21 10:20:55 <gmaxwell> yea, its not a forrest fire if only one tree burns.
 546 2013-02-21 10:21:13 <petertodd> however brightly...
 547 2013-02-21 10:21:20 <Diablo-D3> gmaxwell: you know Im no longer a mod of the hardware forum because theymos is a shill for bfl?
 548 2013-02-21 10:21:23 <petertodd> although the number of participants is actually kinda low
 549 2013-02-21 10:21:28 <gmaxwell> I like the people arguing that blocksize changes are persusive because evorhees wants them.
 550 2013-02-21 10:22:03 <petertodd> evorhees gettingo into the game was a big "moment"
 551 2013-02-21 10:22:12 B0g4r7 has joined
 552 2013-02-21 10:22:27 <petertodd> I though it was interesting how passionate hazak is about it though
 553 2013-02-21 10:24:36 <petertodd> two things: 1) People mostly do not understand my argument that the incentives lead to spiraling blocksize. 2) People really misunderstand what the costs for a node are. The UTXO set issue almost never comes up, people don't get that you need way more bandwidth to keep orphan rate down if you are a miner, etc.
 554 2013-02-21 10:25:31 <petertodd> 2a) People don't understand the nuances of inflation fraud at all, and the inflation fraud proof stuff.
 555 2013-02-21 10:25:37 [ken] has joined
 556 2013-02-21 10:26:40 <gmaxwell> might be good to go and enumerate all the misunderstandings (in all directions, I've seen some pretty odd stuff argued)
 557 2013-02-21 10:27:33 <sipa> i've been thinking about trying to explain all arguments in a dialogue form
 558 2013-02-21 10:27:55 <petertodd> For instance when merge-mined alt chains by the dozens came up...
 559 2013-02-21 10:28:20 <petertodd> sipa: What do you mean by dialogue?
 560 2013-02-21 10:28:51 <sipa> "hey let's raise the limit" - "ok but have you thought about..." - "right, but let's do X to avoid that" - "ok, but then ..."
 561 2013-02-21 10:29:13 ovidiusoft has joined
 562 2013-02-21 10:29:41 <gmaxwell> certantly the argument form happening now is not enlightening people. People are reading only the parts that confirm their understandings mostly... there is a lot of repetition.
 563 2013-02-21 10:30:38 <petertodd> Yes, there just can't be, what, 25 pages worth of inciteful material on the subject that there are on the forums right now.
 564 2013-02-21 10:34:45 grau has joined
 565 2013-02-21 10:44:26 <sipa> i just realized that if the blockchain limit size is increased "too much" in a hard fork, it only requires a softfork to constrain it again
 566 2013-02-21 10:44:42 reizuki__ has quit (Ping timeout: 255 seconds)
 567 2013-02-21 10:44:48 <sipa> however, as a softfork is literally voted upon by miners, that may not be viable
 568 2013-02-21 10:45:00 <petertodd> sipa: Good point, on both arguments.
 569 2013-02-21 10:45:11 <sipa> as those (in particular those with a lot of hashpower) may be the ones benefitting from a large size the most
 570 2013-02-21 10:45:34 <gmaxwell> sipa: yea the problem there is that some of the arguments about excessive size are miner motivation related.
 571 2013-02-21 10:49:26 <gmaxwell> there appears to be no acceptable nash equilibrium on either fees (only obviously stable with difficulty=very-low) or using large blocks offensively to drive smaller miners out (only stable with 1 miner), to be wanky-economical about it. If there were a way for miners to impose their behavior on future blocks, not just past ones then maybe you get a new stability where miners vote within the system to prevent future blocks from being ...
 572 2013-02-21 10:49:32 <gmaxwell> ... outsized.
 573 2013-02-21 10:49:59 <gmaxwell> But that still disenfranchises non-miners, who likely will have very different motivational structure (and already do to some extent)
 574 2013-02-21 10:50:45 <gmaxwell> another lark-though I had was someone could actually regulate this kind of decision with a PoS. PoS within a chain doesn't have the 'there is nothing at stake' issue: you'd only have one coin one vote.
 575 2013-02-21 10:50:50 <sipa> petertodd: yeah, it seems the majority of posters in your thread don't understand your arguments
 576 2013-02-21 10:51:23 <petertodd> It's instructive to work out what is the expected present cost for a given KiB of UTXO taking up indefinetely; I applied standard financial assumptions and came up with something where for even just 1,000 validating nodes, the current fee was only adequate.
 577 2013-02-21 10:51:38 <gmaxwell> but I don't think you have the right incentive alignment there either. Fundimentally you're still going to force some portion of users into something they _do not agree with_. ... unless anything is done at such a time when there is an real consensus.
 578 2013-02-21 10:51:50 <petertodd> sipa: Do they ever? They did understand my sentiment though, or alternatively, Gavin and Mike's.
 579 2013-02-21 10:51:51 devrandom has quit (Ping timeout: 276 seconds)
 580 2013-02-21 10:52:12 <sipa> petertodd: i mostly agree by the way - i'm not sure about the "inevitably" in your title, but the risk is certainly worth taking into account
 581 2013-02-21 10:52:56 <sipa> petertodd: regarding UTXO size: verifying relayers will never be paid for it anyway, so i'm not sure their cost should be taken into the equation; you can only hope to make it feel worthwhile to them to expend it
 582 2013-02-21 10:52:59 <petertodd> sipa: Yeah, when I said inevitably, I was thinking about how I had made this nifty mathy proof... should have realized how it'd be taken.
 583 2013-02-21 10:53:41 <petertodd> sipa: Remember, economists usually don't care if the costs of externialities actually go to the people harmed; having the costs be thrown into the sea is good enough.
 584 2013-02-21 10:53:44 devrandom has joined
 585 2013-02-21 10:53:49 <petertodd> *to encourage the right behavior.
 586 2013-02-21 10:54:02 <sipa> makes sense - i'm not economist though :)
 587 2013-02-21 10:54:24 <gmaxwell> economists don't do well with non-linear utilities in any case.
 588 2013-02-21 10:54:56 <sipa> i once did some calculation for a new fee structure, trying to account for the "cost of forever storing a byte at a given time" when creating a TX, and subtracting the cost for storing a byte at redeem time
 589 2013-02-21 10:55:21 <sipa> assuming an expontially dropping cost/byte*time, that results in finite numbers
 590 2013-02-21 10:56:17 <sipa> though i'm not sure that's enough for the UTXO set, as it's not just about storage but also about being able to quickly search and modify in it
 591 2013-02-21 10:56:34 <gmaxwell> sipa: you could get a similar result without assuming dropping cost/byte*time by discounting future expenses (which is very commonly done, see hyperbolic discounting)
 592 2013-02-21 10:56:42 <petertodd> sipa: My dad is. :)
 593 2013-02-21 10:57:23 <gmaxwell> then again, hyperbolic discounting is part of what causes a lot of clearly 'wrong' behavior. :(
 594 2013-02-21 10:57:25 <petertodd> Basically you assume the money goes into an annuity, and interest pays for on-going fees.
 595 2013-02-21 10:57:46 twobitcoins has joined
 596 2013-02-21 11:00:24 twobitcoins__ has quit (Ping timeout: 252 seconds)
 597 2013-02-21 11:06:43 <sipa> gmaxwell: sure, but just accounting for interest will give you a few % drop per year, taking into technological evolution you get a lot more
 598 2013-02-21 11:07:07 <sipa> so the resulting price per byte would be several times larger, i assume
 599 2013-02-21 11:08:56 jdnavarro has quit (Remote host closed the connection)
 600 2013-02-21 11:09:28 <sipa> i actually like hazek's post here: https://bitcointalk.org/index.php?topic=145475.msg1545331#msg1545331
 601 2013-02-21 11:09:41 drizztbsd has joined
 602 2013-02-21 11:10:29 grau has quit (Remote host closed the connection)
 603 2013-02-21 11:11:04 grau has joined
 604 2013-02-21 11:14:00 TD_ has joined
 605 2013-02-21 11:14:52 robocoin has joined
 606 2013-02-21 11:15:32 word__ has quit (Read error: Connection reset by peer)
 607 2013-02-21 11:15:58 word__ has joined
 608 2013-02-21 11:21:39 <amiller> hell yeah i just figured out all the functors
 609 2013-02-21 11:22:00 * gmaxwell merkelizes amiller
 610 2013-02-21 11:22:01 <amiller> https://gist.github.com/amiller/5003770 this is a lambda calculus evaluator using merkle trees
 611 2013-02-21 11:22:31 <amiller> i have an even better definition now - you can merkleize any data structure with a church-encoding
 612 2013-02-21 11:22:58 <gmaxwell> so this gets you merklized general computation?
 613 2013-02-21 11:23:01 <amiller> yes.
 614 2013-02-21 11:23:17 <amiller> what's neat is that the untyped lambda calculus doesn't terminate
 615 2013-02-21 11:23:30 <amiller> but non termination isn't a problem because this is always productive after constant effort
 616 2013-02-21 11:23:49 <sipa> amiller: very nice result I guess, but requiring a church encoding isn't particularly useful in practice
 617 2013-02-21 11:24:15 <gmaxwell> We'll have to make sure a plot element in the sequel of rapture of the nerds involves this.
 618 2013-02-21 11:24:26 <amiller> it's not a requirement, just it's the simplest way i could think of showing off that it's general
 619 2013-02-21 11:24:31 <sipa> right
 620 2013-02-21 11:24:39 <amiller> sipa i used debruijn indices
 621 2013-02-21 11:24:56 <amiller> that's really interesting because it means you only put things on a stack and you only have to look back in the stack as far as the depth of the program
 622 2013-02-21 11:25:02 <amiller> so there's nothing like a heap that would grow
 623 2013-02-21 11:25:05 <gmaxwell> certantly its more interesting to do what you've done then to simply write out a proof. :)
 624 2013-02-21 11:25:29 <sipa> amiller: yes, i'm familiar with writing lambda calculus interpreters :)
 625 2013-02-21 11:26:04 <amiller> heh, well i wasn't sure how it would work... but now i don't see any problem with running a bit of computation and then pushing a continuation back on the blockchain, or something like that
 626 2013-02-21 11:28:07 <gmaxwell> amiller: unfortunately this kind of thing ends up precluding transformations that make the execution efficient.
 627 2013-02-21 11:29:47 <amiller> we'll see
 628 2013-02-21 11:31:30 <gmaxwell> amiller: can you write transformations on your merklizer so that it becomes a merklizer of a more efficient computational structure? :P
 629 2013-02-21 11:32:07 <Goonie> Is there a reason bitcoin 0.8.0 is not announce on bitcointalk in that top news line yet?
 630 2013-02-21 11:32:16 <sipa> Goonie: it is?
 631 2013-02-21 11:32:30 <petertodd> anyone care to translate amiller
 632 2013-02-21 11:32:35 <petertodd> 's work into non-moon-speak?
 633 2013-02-21 11:32:38 <Goonie> hmmm I see "Looking for someone to deliver new forum software"
 634 2013-02-21 11:32:51 <Goonie> ah ok its cycling
 635 2013-02-21 11:32:53 <amiller> yeah the lambda calculus thing is just a cute example and demonstrates pretty wide generality - but the real reason it works is because of stuff other people figured out for generic programming in haskell
 636 2013-02-21 11:33:04 twobitcoins has quit (Read error: Connection reset by peer)
 637 2013-02-21 11:33:25 <gmaxwell> petertodd: you know how you can attach hashes to a link list and get an authenticated blockchain?  .. or hashes to a tree data structure and get an authenticated tree with authenticated queries?
 638 2013-02-21 11:33:29 twobitcoins has joined
 639 2013-02-21 11:33:44 <petertodd> gmaxwell: yup
 640 2013-02-21 11:34:34 <gmaxwell> petertodd: amiller wrote code that transforms code that implements datastructures to make any kind of datastructure and its corresponding computation merklized. At least if you express it all in the right way.
 641 2013-02-21 11:35:20 <gmaxwell> so e.g. you write an implementation of some fancy database operation.. feed it to this, and you get a new version of its operators that vomits tree fragment proofs
 642 2013-02-21 11:35:28 <petertodd> gmaxwell: right, so the lambda calculus and church numerals comes into it because they're just really general ways of describing computations
 643 2013-02-21 11:35:33 <gmaxwell> right.
 644 2013-02-21 11:35:59 <petertodd> gmaxwell: kinda like making a turing machine merklize a log of tape movements
 645 2013-02-21 11:36:35 <gmaxwell> The earlier version worked with fixed-point functors (so basically any datastructure that you could describe with induction, but not all computation)
 646 2013-02-21 11:36:41 <sipa> well, you could write a turing machine in lambda calculus, and have it work on a church-encoded program, with a church-encoded input tape
 647 2013-02-21 11:37:08 <gmaxwell> petertodd: yea, this program could actually create such a turing machine.
 648 2013-02-21 11:37:28 <gmaxwell> but, perhaps not a very efficiently computed one. :P
 649 2013-02-21 11:37:49 <petertodd> gmaxwell: turing machines are rarely known for efficiency as it is :P
 650 2013-02-21 11:37:52 <amiller> i don't think that turing machines can express data structures but i'm not sure
 651 2013-02-21 11:37:56 <amiller> i was thinking about doing it that way first
 652 2013-02-21 11:38:16 <petertodd> gmaxwell: so when you say "functor", do you mean the abstract moon-man-speak at http://en.wikipedia.org/wiki/Functor ?
 653 2013-02-21 11:38:16 <amiller> even though church numerals are silly you can still encode a binary tree and it only does log n work
 654 2013-02-21 11:38:50 <amiller> petertodd, this is the blog about functors that helped me out the most the past couple days http://www.timphilipwilliams.com/posts/2013-01-16-fixing-gadts.html
 655 2013-02-21 11:39:03 <amiller> try it and you'll be vomiting tree fragment proofs in no time
 656 2013-02-21 11:39:18 <petertodd> amiller: if I understand it correctly, church numerals basically represent numbers as recursive functions?
 657 2013-02-21 11:39:51 <petertodd> amiller: I was doing that last saturday morning, while hungover, never again...
 658 2013-02-21 11:39:54 <sipa> petertodd: everything in (pure) lambda calculus is a function, and church encoding in general is representing data as such functions
 659 2013-02-21 11:40:42 <sipa> church numerals a specific case for integers
 660 2013-02-21 11:40:43 ciphermonk has quit (Remote host closed the connection)
 661 2013-02-21 11:40:52 <amiller> the lambda calculus part isn't so important here - what's important is i figured out the haskell/functors way to describe composite inductive datatypes (not just regular datatypes like i had before)
 662 2013-02-21 11:41:08 <amiller> so i can have.. like blockchains with trees hanging off and etc
 663 2013-02-21 11:42:02 <petertodd> so an inductive datatype basically defines the data as any datatype would, but while also allowing for additional levels of recursion? (hand-waving here)
 664 2013-02-21 11:42:51 <sipa> petertodd: for example a list can be thought of as: a list with elements of type X is either the empty list, or an element of type X + a list over X
 665 2013-02-21 11:43:11 <sipa> in haskell: data List a = Empty | Cons a (List a)
 666 2013-02-21 11:43:32 <sipa> so it refers to itself
 667 2013-02-21 11:43:37 copumpkin has quit (Ping timeout: 240 seconds)
 668 2013-02-21 11:43:47 <gmaxwell> At least my big take away from this was the insight that if I want to figure out how to merklize something I should see if I can come up with an inductive representation (basically what you just described).
 669 2013-02-21 11:44:13 copumpkin has joined
 670 2013-02-21 11:44:16 <petertodd> right, and because there is an option, there is a bottom (that's a haskell term right? i read up on haskell years ago and vagely understood it)
 671 2013-02-21 11:44:29 <petertodd> *option as in non-recursive option
 672 2013-02-21 11:44:38 <sipa> petertodd: it means you can have an infinite datastructure, so it speak
 673 2013-02-21 11:44:39 <gmaxwell> I hadn't realized that before amiller's work— I'd, of course, realized some things efficiently merklized and some didn't but I didn't have a general rule that predicted it without me thinking about it.
 674 2013-02-21 11:44:50 <petertodd> sipa: right, which is ok in haskell because of lazy computation
 675 2013-02-21 11:44:55 <sipa> indeed
 676 2013-02-21 11:45:05 <sipa> but that indeed implies a bottom
 677 2013-02-21 11:45:23 <sipa> as the unevaluating part can be non-terminating
 678 2013-02-21 11:45:23 <amiller> s/infinite/unbounded
 679 2013-02-21 11:45:29 <sipa> *unevaluated
 680 2013-02-21 11:45:57 ralphthe1inja has joined
 681 2013-02-21 11:46:13 <petertodd> gmaxwell: ok, so what's a good example then of something that doesn't efficiently merklize, and obviously so because it can't be inductivly defined?
 682 2013-02-21 11:46:20 <amiller> a hash table
 683 2013-02-21 11:46:36 <gmaxwell> amiller types faster than I do.
 684 2013-02-21 11:46:40 ralphthe1inja is now known as ralphtheninja
 685 2013-02-21 11:47:14 <petertodd> right, and hash tables can't be inductivly defined, basically because they're stateful and thus imperative?
 686 2013-02-21 11:47:26 <petertodd> (I guess bloom filters fall into that category too)
 687 2013-02-21 11:47:43 <petertodd> (oh, and arrays of course...)
 688 2013-02-21 11:47:47 <sipa> well you could have a functional version of a hash table
 689 2013-02-21 11:47:47 <amiller> it's not so much that it's stateful but that it relies on arrays
 690 2013-02-21 11:47:49 <amiller> basically arrays
 691 2013-02-21 11:48:01 <sipa> but it would mean rewriting the entire table for every modification
 692 2013-02-21 11:48:10 <amiller> you could make the hash table out of a tree but you'd end up with a log N penalty
 693 2013-02-21 11:48:20 <sipa> yup
 694 2013-02-21 11:48:20 <petertodd> sipa: which might actually be ok for some workloads...
 695 2013-02-21 11:48:37 <sipa> if writes are exceedingly uncommon compared to reads, perhaps
 696 2013-02-21 11:49:03 forrestv has quit (Quit: ZNC - http://znc.sourceforge.net)
 697 2013-02-21 11:49:31 <gmaxwell> well, keep in mind— the inefficiency there would make proofs bit for this usage.
 698 2013-02-21 11:49:35 <gmaxwell> s/bit/big/
 699 2013-02-21 11:49:43 <petertodd> ok, so an array isn't inductive, basically because there is exactly one level to it, the pointer for the first element, and the offset
 700 2013-02-21 11:50:04 forrestv has joined
 701 2013-02-21 11:50:04 <petertodd> equally a hash on an array, must be over the whole array
 702 2013-02-21 11:50:08 <amiller> normally you think of the array as random access
 703 2013-02-21 11:50:25 <gmaxwell> You can just replace your array with a fully populated binary tree. Thats basically what the txn set is in a block.
 704 2013-02-21 11:50:52 <sipa> well, it's not the fact that it's inductive or not; it's that the elementary datastructure it consists of is very complex
 705 2013-02-21 11:51:17 <petertodd> gmaxwell: ah, true, the standard compressed binary tree memory representation
 706 2013-02-21 11:51:18 <gmaxwell> the real data structure is an array, — it's a list of transactions. We coerce it into a tree for the purpose of making an efficient proof against it.
 707 2013-02-21 11:51:19 <sipa> the elementary datastructure for a list is just (nothing or element + new list)
 708 2013-02-21 11:51:36 <sipa> the elementary datastructure for an array or hashtable is the array or hashtable itself
 709 2013-02-21 11:52:15 rbecker is now known as RBecker
 710 2013-02-21 11:52:16 <petertodd> right, hence different versions don't share any structure, changes always modify the whole thing in functional terms
 711 2013-02-21 11:52:40 <gmaxwell> you can replace your array with a linked list, and then some kinds of operations are cheap. and update at the tip is cheap, for example.
 712 2013-02-21 11:53:07 <gmaxwell> or a fully populated tree (of whatever branching you like), and then a different set of things is cheap.
 713 2013-02-21 11:53:26 <gmaxwell> but none of them get you back the O(1) operations you had on the array. :(
 714 2013-02-21 11:54:05 <petertodd> gmaxwell: well, if it makes you feel any better arrays don't actually scale by O(1) when implemented on computers occupying space and time :P
 715 2013-02-21 11:54:36 <sipa> right, since the index itself scales by O(log n) anyway
 716 2013-02-21 11:55:06 <petertodd> sipa: well, actually I mean because a physical memory must have some bits farther away than others from your cpu
 717 2013-02-21 11:55:13 <gmaxwell> well, they can over big swaths. The thing I find interesting is that atomic updates break your O(1) badly.
 718 2013-02-21 11:55:17 <sipa> but talking about real asymptotic behaviour of data structures doesn't make sense in reality anyway
 719 2013-02-21 11:55:37 <sipa> as no one can store an arbitrarily large amount of data
 720 2013-02-21 11:56:09 <petertodd> yeah, I love how the internal guts of cpu's these days handle atomic updates with all the complex schemes invented for clusters years ago
 721 2013-02-21 11:56:14 <sipa> so it is always just about behaviour in a finite subset
 722 2013-02-21 11:56:23 <gmaxwell> yea, and log n generally turns anything you can store into a reasonable number.
 723 2013-02-21 11:56:27 <petertodd> there's a great quote by linus about it in response to someone complaining about how complex it all is
 724 2013-02-21 11:57:35 <petertodd> taking heat dissipation into account log2 is pretty much always possible, two dimensional layout, power goes in one side and heat goes out the other
 725 2013-02-21 11:58:24 <petertodd> these days CPU's very agressively use that concept at the physical level, a socket handles hundreds of amps at less than a volt now
 726 2013-02-21 12:00:07 rdymac has joined
 727 2013-02-21 12:00:11 RBecker is now known as rbecker
 728 2013-02-21 12:01:42 etotheipi_ has quit (Remote host closed the connection)
 729 2013-02-21 12:03:30 jurov has quit (Ping timeout: 245 seconds)
 730 2013-02-21 12:11:05 dub has quit (Ping timeout: 264 seconds)
 731 2013-02-21 12:11:05 smiddi has quit (Ping timeout: 264 seconds)
 732 2013-02-21 12:11:05 hsy has quit (Ping timeout: 264 seconds)
 733 2013-02-21 12:11:30 smiddi has joined
 734 2013-02-21 12:11:47 hsy has joined
 735 2013-02-21 12:12:05 dub has joined
 736 2013-02-21 12:15:16 jurov has joined
 737 2013-02-21 12:16:17 reizuki__ has joined
 738 2013-02-21 12:18:08 TradeFortress has quit (Ping timeout: 272 seconds)
 739 2013-02-21 12:18:33 nus has joined
 740 2013-02-21 12:26:06 JZavala has joined
 741 2013-02-21 12:28:18 kicek has joined
 742 2013-02-21 12:32:07 kicek has quit (Client Quit)
 743 2013-02-21 12:32:08 rdymac has quit (Read error: Connection reset by peer)
 744 2013-02-21 12:32:32 nus- has joined
 745 2013-02-21 12:34:13 <Goonie> I have a question about HD wallets:
 746 2013-02-21 12:34:15 <Goonie> I know you can derive a sequence of private keys from a master private key and each private key corresponds to a public key -- but can I also derive the same sequence of _public_ keys by knowing a "master public key" (which can probably be derived from the master private key)?
 747 2013-02-21 12:34:30 <sipa> Goonie: yes, that's the point
 748 2013-02-21 12:35:39 twobitcoins_ has joined
 749 2013-02-21 12:35:46 <Goonie> cool -- so in order to give out public addresses (for example for donations) I don't need the master private key, a master public key (which I still would like to hold private) is enough
 750 2013-02-21 12:36:07 <sipa> yes, several of the use cases depend on that property
 751 2013-02-21 12:36:16 <Goonie> ok cool, thanks
 752 2013-02-21 12:36:27 <Goonie> I'm very happy
 753 2013-02-21 12:36:35 <sipa> it's what gmaxwell originally called "type-2 deterministic wallets"
 754 2013-02-21 12:36:52 nus has quit (Ping timeout: 276 seconds)
 755 2013-02-21 12:37:47 <sipa> from BIP 32: Note that the extended public key corresponding to the evaluation of CKD(x,n) is identical to the evaluation of CKD'(X,n), with X the extended public key corresponding to x. Symbolically, CKD(x,n)*G = CKD'(x*G,n). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.
 756 2013-02-21 12:38:17 <Goonie> (-:
 757 2013-02-21 12:38:33 twobitcoins has quit (Ping timeout: 264 seconds)
 758 2013-02-21 12:38:49 <sipa> Goonie: however, if someone knows the parent extended public key, and a private child key, they can retrieve the parent extended private key (and thus everything)
 759 2013-02-21 12:39:11 <Goonie> is there already an implementation for apache to generate public keys?
 760 2013-02-21 12:39:20 <sipa> for apache?
 761 2013-02-21 12:39:46 <Goonie> yes if you want to put a donation address on your web page
 762 2013-02-21 12:39:55 <Goonie> it would be cool if its a different each time
 763 2013-02-21 12:39:59 <CodeShark> why would that be part of apache?
 764 2013-02-21 12:40:07 <sipa> yes, certainly, but why would you want this in apache?
 765 2013-02-21 12:40:26 <Goonie> hmm, because apache is already running
 766 2013-02-21 12:40:31 <CodeShark> >
 767 2013-02-21 12:40:33 <CodeShark> ?
 768 2013-02-21 12:40:34 <Goonie> and no, bitcoind is not running
 769 2013-02-21 12:41:14 <CodeShark> it's fairly simple to write a library to perform this operation that your web app can call
 770 2013-02-21 12:41:25 <CodeShark> no need to incorporate it into apache nor run bitcoind
 771 2013-02-21 12:41:32 <sipa> you may want that in PHP, or Java, or Ruby, or Perl, or ...
 772 2013-02-21 12:41:36 <Goonie> ok sure
 773 2013-02-21 12:41:38 <sipa> but why in your webserver?
 774 2013-02-21 12:41:45 <Goonie> except that my web page is static atm
 775 2013-02-21 12:42:09 reizuki__ has quit (Ping timeout: 252 seconds)
 776 2013-02-21 12:42:36 <Goonie> but ok, you're right, using a library from my "web app" is probably the way to go
 777 2013-02-21 12:42:50 Hashdog has joined
 778 2013-02-21 12:44:48 <Goonie> actually I'd like to access that from an android app that has donations (or maybe in-app payments), and I don't want to include the master public key with the app
 779 2013-02-21 12:45:00 asuk has quit (afk!~asuk@ec2-54-234-43-224.compute-1.amazonaws.com|Quit: ZNC - http://znc.in)
 780 2013-02-21 12:45:44 <CodeShark> so then have the app connect to your server and request a new public key
 781 2013-02-21 12:46:01 asuk has joined
 782 2013-02-21 12:46:11 <Goonie> yes, exactly
 783 2013-02-21 12:47:24 Hashdog has quit (Ping timeout: 248 seconds)
 784 2013-02-21 12:47:47 <CodeShark> so that's not exactly a web app - although you could still use HTTP and REST
 785 2013-02-21 12:48:42 <Goonie> this is why I used parenthesis
 786 2013-02-21 12:48:55 <CodeShark> you mean quotes ? :p
 787 2013-02-21 12:49:00 <Goonie> oh yes
 788 2013-02-21 12:49:50 <Goonie> I mean in the simplest form it could just be one of these substitution variables you can use in apache, even in static web pages
 789 2013-02-21 12:50:13 <CodeShark> argh...lol
 790 2013-02-21 12:50:44 <CodeShark> all you really need is a listening socket that can parse an HTTP header :p
 791 2013-02-21 12:50:51 <CodeShark> and call a library
 792 2013-02-21 12:51:11 <Goonie> so you suggest writing your own server?
 793 2013-02-21 12:51:14 <CodeShark> no
 794 2013-02-21 12:51:23 <CodeShark> my point is that the web server only does what I just said
 795 2013-02-21 12:51:38 mappum has quit (Ping timeout: 260 seconds)
 796 2013-02-21 12:52:06 <Goonie> ok and that library is called "plugin" on apache
 797 2013-02-21 12:52:15 ciphermonk has joined
 798 2013-02-21 12:52:47 <Goonie> and that is what I originally meant with "implementation for apache"
 799 2013-02-21 12:53:13 <CodeShark> why not just use one of the languages (and existing bindings that exist for them) that sipa mentioned? :)
 800 2013-02-21 12:53:47 <CodeShark> <?php getNewPubkey()?> or whatever
 801 2013-02-21 12:53:48 <CodeShark> lol
 802 2013-02-21 12:54:17 <Goonie> yes, sure, I'm just looking for existing solutions
 803 2013-02-21 12:54:32 <sipa> i don't think you want to generate a new key for each new page request
 804 2013-02-21 12:54:45 <sipa> at least keep it in a cookie or session variable
 805 2013-02-21 12:54:52 kjj has quit (Ping timeout: 264 seconds)
 806 2013-02-21 12:55:02 <sipa> but probably some mechanism to reuse them if not used for X time
 807 2013-02-21 12:55:20 <Goonie> Yes, that's what I'm thinking also
 808 2013-02-21 12:56:29 <Goonie> I'd like to avoid unused addresses, but in this case the library would need to communicate with a client
 809 2013-02-21 12:57:28 kjj has joined
 810 2013-02-21 12:57:53 <Goonie> with a bitcoin client I mean
 811 2013-02-21 12:57:58 <CodeShark> ?
 812 2013-02-21 12:58:13 <CodeShark> why?
 813 2013-02-21 12:58:25 <Goonie> to know which addresses have been used
 814 2013-02-21 12:59:05 <CodeShark> oh, hmm...better would be to have a listener connected to a bitcoin node that sends alerts
 815 2013-02-21 12:59:14 JZavala has quit (Ping timeout: 252 seconds)
 816 2013-02-21 12:59:20 <CodeShark> updates a database, or whatever
 817 2013-02-21 12:59:55 <Goonie> yes, that's what I meant with "communicate"
 818 2013-02-21 13:00:37 <Goonie> ok thanks for your help
 819 2013-02-21 13:00:52 <CodeShark> the library doesn't need to know anything about the bitcoin protocol at all - nor about bitcoind
 820 2013-02-21 13:01:42 <Goonie> But that "listener", which protocol should it be?
 821 2013-02-21 13:01:48 <CodeShark> the listener would have to know how to communicate with a bitcoin node and update a database
 822 2013-02-21 13:01:56 <CodeShark> the library would just look at the database
 823 2013-02-21 13:02:34 HM has joined
 824 2013-02-21 13:02:50 <CodeShark> I've been trying really hard to get this kind of listener hook added generally to bitcoind...but it doesn't seem to be a great priority :p
 825 2013-02-21 13:03:00 Hashdog has joined
 826 2013-02-21 13:03:14 <Goonie> I don't  know how HD wallets will be implemented in bitcoind, but maybe I will be able to query bitcoind directly for unused addresses (JSON interface)? In this case the DB would be superfluous.
 827 2013-02-21 13:03:19 t7 has joined
 828 2013-02-21 13:03:56 HM has quit (Client Quit)
 829 2013-02-21 13:04:08 <CodeShark> I wouldn't recommend that architecture
 830 2013-02-21 13:04:26 <sipa> Goonie: 'unused' isn't enough - you'll need to mark them temporarily used, until they show up in a transaction somewhere
 831 2013-02-21 13:05:18 <CodeShark> I'm a strong advocate of separation between key generation/management and anything protocol-related
 832 2013-02-21 13:05:21 da2ce7_d has joined
 833 2013-02-21 13:05:29 <Goonie> sipa: well it depends on your privacy requirements, but yes, you're right
 834 2013-02-21 13:05:45 twobitcoins__ has joined
 835 2013-02-21 13:06:24 <Goonie> CodeShark: good point. On the other hand, bitcoin-qt will need at least some of that functionality anyway
 836 2013-02-21 13:06:56 <CodeShark> bitcoin-qt can still perform both tasks in a single process - but they are really functionally distinct
 837 2013-02-21 13:07:06 <Goonie> true
 838 2013-02-21 13:07:21 da2ce7 has quit (Ping timeout: 255 seconds)
 839 2013-02-21 13:07:28 <Goonie> At least I'm happy that the BIP has been to well thought out
 840 2013-02-21 13:07:37 <Goonie> s/to/so
 841 2013-02-21 13:07:50 <CodeShark> and what you want, at any rate, is a way to be updated when the status of a key changes
 842 2013-02-21 13:08:54 alexwaters2 has joined
 843 2013-02-21 13:09:39 twobitcoins_ has quit (Ping timeout: 276 seconds)
 844 2013-02-21 13:10:26 HM has joined
 845 2013-02-21 13:13:32 denisx has quit (Quit: denisx)
 846 2013-02-21 13:20:40 MagicalTux has quit (Ping timeout: 264 seconds)
 847 2013-02-21 13:20:45 MT`AwAy has joined
 848 2013-02-21 13:21:10 MT`AwAy is now known as Guest10421
 849 2013-02-21 13:23:44 dvide has quit ()
 850 2013-02-21 13:24:51 jdnavarro has joined
 851 2013-02-21 13:26:32 jdnavarro has quit (Remote host closed the connection)
 852 2013-02-21 13:29:18 JWU42 has quit (Read error: Connection reset by peer)
 853 2013-02-21 13:29:51 JWU42 has joined
 854 2013-02-21 13:30:36 JWU42 has quit (Read error: Connection reset by peer)
 855 2013-02-21 13:31:04 JWU42 has joined
 856 2013-02-21 13:36:57 word__ has quit (Changing host)
 857 2013-02-21 13:36:57 word__ has joined
 858 2013-02-21 13:37:00 word__ is now known as word
 859 2013-02-21 13:39:56 alexwaters2 has quit (Quit: Leaving.)
 860 2013-02-21 13:44:42 cosurgi has quit (Ping timeout: 252 seconds)
 861 2013-02-21 13:45:38 vampireb has joined
 862 2013-02-21 13:46:28 alexwaters has joined
 863 2013-02-21 13:49:18 ciphermonk has quit (Ping timeout: 276 seconds)
 864 2013-02-21 13:54:21 awfwadaw has quit (Ping timeout: 245 seconds)
 865 2013-02-21 13:54:55 t7 has quit (Read error: Connection reset by peer)
 866 2013-02-21 13:55:23 t7 has joined
 867 2013-02-21 14:03:05 Zarutian has joined
 868 2013-02-21 14:05:34 paraipan has joined
 869 2013-02-21 14:05:57 CodeShark has quit (Remote host closed the connection)
 870 2013-02-21 14:09:07 serp has quit (Ping timeout: 240 seconds)
 871 2013-02-21 14:10:36 [ken] has quit (Quit: leaving)
 872 2013-02-21 14:11:46 twobitcoins__ has quit (Read error: Connection reset by peer)
 873 2013-02-21 14:11:51 serp has joined
 874 2013-02-21 14:11:51 serp has quit (Changing host)
 875 2013-02-21 14:11:51 serp has joined
 876 2013-02-21 14:12:12 twobitcoins__ has joined
 877 2013-02-21 14:14:46 <s4m20> bitcoind using 70% of 1G RAM, is this normal?
 878 2013-02-21 14:14:58 <gmaxwell> s4m20: how are you measuring it?
 879 2013-02-21 14:15:08 <s4m20> top
 880 2013-02-21 14:15:12 <gmaxwell> which field?
 881 2013-02-21 14:15:19 <gmaxwell> and if you're accepting inbound connections that doesn't sound too insane.
 882 2013-02-21 14:15:28 <gmaxwell> you should be looking at res/rss
 883 2013-02-21 14:15:50 <Guest61604> 5. Check if transaction hashes contained in the "header" command are already in the Tx pool.
 884 2013-02-21 14:15:50 <Guest61604> 6a. If all hashes are in the pool, reconstruct the block referred by the "header" and announce to peers.
 885 2013-02-21 14:15:58 <Guest61604> i came up with this idea months ago
 886 2013-02-21 14:15:59 <s4m20>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 887 2013-02-21 14:15:59 <s4m20> 13013 sam       20   0 1147m 701m 2372 S    1 69.6 369:02.92 bitcoind
 888 2013-02-21 14:16:09 <Guest61604> i just cant write a proposal down in a cognizant manner
 889 2013-02-21 14:16:10 <Guest61604> ffffffffffffff
 890 2013-02-21 14:16:24 Guest61604 is now known as MC1984
 891 2013-02-21 14:16:31 <s4m20> it's cool, i was just wondering really
 892 2013-02-21 14:16:47 <gmaxwell> MC1984: see the responses.
 893 2013-02-21 14:21:55 <s4m20> so roughly how many devs are involved in the bitcoin client?
 894 2013-02-21 14:22:40 rdponticelli has joined
 895 2013-02-21 14:23:55 <gmaxwell> https://www.ohloh.net/p/bitcoin/contributors?sort=latest_commit&time_span=12+months
 896 2013-02-21 14:25:46 <s4m20> wow, thanks
 897 2013-02-21 14:27:20 Guest10421 is now known as MagicalTux
 898 2013-02-21 14:27:23 MagicalTux has quit (Changing host)
 899 2013-02-21 14:27:23 MagicalTux has joined
 900 2013-02-21 14:32:32 da2ce7_d is now known as da2ce7
 901 2013-02-21 14:33:52 <MC1984> is that like facebook for nerds
 902 2013-02-21 14:34:12 <MC1984> why do you have 9......rank.....
 903 2013-02-21 14:36:27 <TD_> s4m20: try restarting the app and it may use less memor
 904 2013-02-21 14:36:55 tk993 has joined
 905 2013-02-21 14:37:47 grau has quit (Remote host closed the connection)
 906 2013-02-21 14:38:08 gavinandresen has joined
 907 2013-02-21 14:38:10 Jackneill has joined
 908 2013-02-21 14:38:10 Jackneill has quit (Changing host)
 909 2013-02-21 14:38:10 Jackneill has joined
 910 2013-02-21 14:38:52 vampireb has quit (Quit: Lost terminal)
 911 2013-02-21 14:42:06 <MC1984> it reads like the core idea is sound, he just underspecified/didint think through the details in the "BIP"
 912 2013-02-21 14:42:16 <MC1984> and got his ass handed to him for not writing code first
 913 2013-02-21 14:44:06 Jackneill has quit (Remote host closed the connection)
 914 2013-02-21 14:46:05 Jackneill has joined
 915 2013-02-21 14:46:35 <TD_> it's a fairly obvious optimization
 916 2013-02-21 14:46:44 <TD_> to speccing it without code doesn't help much.
 917 2013-02-21 14:46:45 TD_ is now known as TD
 918 2013-02-21 14:47:48 Hasimir has quit (Ping timeout: 255 seconds)
 919 2013-02-21 14:48:37 Hasimir has joined
 920 2013-02-21 14:48:53 Hasimir is now known as Guest58662
 921 2013-02-21 14:50:26 Nesetalis has quit (Ping timeout: 252 seconds)
 922 2013-02-21 14:50:31 Guest58662 has quit (Changing host)
 923 2013-02-21 14:50:31 Guest58662 has joined
 924 2013-02-21 14:50:52 Guest58662 is now known as Hasimir
 925 2013-02-21 14:53:30 <MC1984> yeah i suppose it would be obvious to people familiar
 926 2013-02-21 14:53:42 <MC1984> i probably shouldnt feel so vindicated and shit
 927 2013-02-21 14:53:51 Nesetalis has joined
 928 2013-02-21 14:54:34 agricocb has quit (Quit: Leaving.)
 929 2013-02-21 14:55:53 topace has quit (Ping timeout: 246 seconds)
 930 2013-02-21 14:59:10 <TD> well when you see the protocol and observe that it sends the same data multiple times, "don't do that" is a fairly reasonable next step :)
 931 2013-02-21 15:00:39 <MC1984> indeed
 932 2013-02-21 15:00:50 Pirateat43 is now known as Mad7Scientist
 933 2013-02-21 15:08:42 <Tykling> what can cause bitcoind to hang when calling rpc commands ? I noticed a script I have doesn't work anymore, and when I try from the command line it just never returns, it just sits there
 934 2013-02-21 15:09:15 QuantumQrack has joined
 935 2013-02-21 15:09:47 <Tykling> nothing in debug.log that looks out of the ordinary
 936 2013-02-21 15:10:01 <QuantumQrack> Is there anybody here that can explain any solution to the blockchain getting abnormally large, or is this even a problem at all?
 937 2013-02-21 15:12:19 <helo> QuantumQrack: the solution is essentially time. the blockchain (currently) will grow at most linearly, so hardware should outpace it
 938 2013-02-21 15:12:52 grau has joined
 939 2013-02-21 15:13:02 <kjj> well, linear once it hits the block size cap, assuming the cap stays in place (huge threadnought on the forums yesterday)
 940 2013-02-21 15:13:05 <QuantumQrack> You mean memory density per $?
 941 2013-02-21 15:13:34 <helo> hard disk capacity, memory for caching, cpu for validating
 942 2013-02-21 15:13:38 <QuantumQrack> To me I see it as an approaching cliff and the only solution is online wallets.
 943 2013-02-21 15:13:50 <QuantumQrack> tell me I'm wrong.. :-)
 944 2013-02-21 15:13:53 <gavinandresen> Tykling: what version of bitcoind?  There was a nasty race codition in the 'move' command in the 0.7.1 release
 945 2013-02-21 15:14:34 <jaakkos> QuantumQrack: that would lead to centralization
 946 2013-02-21 15:14:38 <Tykling> gavinandresen: hah, I literally JUST narrowed it down to when a move happens
 947 2013-02-21 15:14:43 <QuantumQrack> jaakkos, indeed.
 948 2013-02-21 15:14:54 <Tykling> gavinandresen: thank you for confirming, I will upgrade to 0.8 :)
 949 2013-02-21 15:15:49 <QuantumQrack> I guess to further illustrate this point, do people have to invest in hard drive space to utilize bitcoin in the future assuming it is widely adopted...
 950 2013-02-21 15:16:13 <helo> it will grow 144MB per day with a 1MB block size
 951 2013-02-21 15:16:22 <helo> so 52GB per year
 952 2013-02-21 15:16:55 topace has joined
 953 2013-02-21 15:17:03 <QuantumQrack> What if transaction volume outpaces a 52gb limit...  I guess I dont understand that.
 954 2013-02-21 15:17:07 topace has quit (Changing host)
 955 2013-02-21 15:17:07 topace has joined
 956 2013-02-21 15:17:09 <kjj> I just got a hard drive capable of storing the next 57 years worth of bitcoin for $150
 957 2013-02-21 15:17:12 <helo> i have that much free space right now, and when i upgrade my drives next i'll probably have enough extra space comfortably for 10 years of blockspace
 958 2013-02-21 15:17:51 <kjj> again, assuming the block size cap
 959 2013-02-21 15:17:54 <helo> QuantumQrack: valid block cannot exceed 1MB, so 1MB per 10 minutes is the block chain growth rate
 960 2013-02-21 15:17:58 agricocb has joined
 961 2013-02-21 15:18:12 <QuantumQrack> helo, ahh, I think I see now.
 962 2013-02-21 15:19:00 <QuantumQrack> so, if 52 gigs is hit...then the price of bitcoin will go up..and people will have to subdivide bitcoins given there is demand for them?
 963 2013-02-21 15:19:07 <jaakkos> QuantumQrack: anyway the chain size is already a problem in some applications like the android wallet
 964 2013-02-21 15:19:10 <kjj> different issue
 965 2013-02-21 15:19:42 <kjj> transactions can be any size.  hitting the cap will have an effect on fees, but not (necessarily) exchange rate
 966 2013-02-21 15:19:52 <QuantumQrack> jaakkos, yes that is what I am asking.  People in the future will not be able to store the whole block chain on mobile devices, thus online wallets, etc will be needed...
 967 2013-02-21 15:19:53 <jaakkos> QuantumQrack: but there is https://en.bitcoin.it/wiki/BIP_0037 for that
 968 2013-02-21 15:20:03 <helo> QuantumQrack: it will work on a block-by-block basis. so every 10 minutes, the 1MB of transactions with the highest fees can be included
 969 2013-02-21 15:20:08 <QuantumQrack> thus, centralization
 970 2013-02-21 15:20:41 <helo> people will be able to store the whole block chain on mobile devices if the block size stays at 1MB
 971 2013-02-21 15:21:20 <QuantumQrack> Yeah, but I heard the blocksize is increasing possibly.
 972 2013-02-21 15:21:37 <helo> the approach for mobile is to avoid needing to store the entire blockchain
 973 2013-02-21 15:22:03 <helo> i disagree strongly with those people :)
 974 2013-02-21 15:22:22 rdymac has joined
 975 2013-02-21 15:23:10 <helo> (with the people saying the blocksize is increasing)
 976 2013-02-21 15:23:15 <QuantumQrack> yeah
 977 2013-02-21 15:24:19 <MC1984> SPV + the bloom filter stuf seems to have seen of the spectre of thin clients on mobile for now
 978 2013-02-21 15:24:36 <MC1984> web wallets anyway
 979 2013-02-21 15:26:02 <MC1984> and assuming the block cap stays or even get increased once in a while, the cost of storage should easily outpace the chain
 980 2013-02-21 15:26:23 <MC1984> lots of people have enough storage for decades of the chain and dont even know it
 981 2013-02-21 15:26:29 <QuantumQrack> Yeah, but I would rather have the whole blockchain on a mobile device....
 982 2013-02-21 15:26:46 <QuantumQrack> at all times.
 983 2013-02-21 15:27:05 <MC1984> youll probably be ablet to do that with bitcoinj one day
 984 2013-02-21 15:27:14 <QuantumQrack> and I would also like the mobile device to operate as a full node, at all times.
 985 2013-02-21 15:27:30 <TD> hah
 986 2013-02-21 15:27:41 <MC1984> also i have a mobile bitcoin-qt with the chain on a thumb drive, does that count
 987 2013-02-21 15:27:44 <TD> well, if you want to make such an app, it's only a couple of lines change to the Bitcoin Wallet app
 988 2013-02-21 15:27:44 <helo> changing the block cap will really screw with mining profit, and thus hashrate
 989 2013-02-21 15:27:48 <TD> have fun!
 990 2013-02-21 15:28:02 <TD> helo: that's not necessarily a correct assumption. there are alternative ways to fund miners than per-tx fees
 991 2013-02-21 15:28:06 <helo> so it will probably be resisted quite a bit once an equilibrium forms around a particular cap
 992 2013-02-21 15:28:31 <MC1984> if the block cap stays at 1mb youll be able to run full node on a phone within a few years imo
 993 2013-02-21 15:29:03 <MC1984> the benchmark specs for the new HTC One are more than double the nexus 4, which also just came out
 994 2013-02-21 15:29:19 <TD> the One looks sexy. i just wish it ran jellybean
 995 2013-02-21 15:29:25 <TD> if they get an update out ASAP i might be tempted to swap my S3 for one
 996 2013-02-21 15:29:29 <QuantumQrack> Well, I dont think running a full node on mobile devices is an options.  I think it is required to maintain the non-central nature of bitcoin.
 997 2013-02-21 15:29:35 <helo> QuantumQrack: bitcoin wallet on android can be configured to sync the blockchain headers when you charge
 998 2013-02-21 15:29:39 <MC1984> lol it doesnt have jellybea are you serious
 999 2013-02-21 15:29:41 <TD> QuantumQrack: er, why
1000 2013-02-21 15:29:58 <TD> QuantumQrack: you realize that Satoshi fully supported the idea of most users being on SPV clients, right? not only for mobile devices but all end users
1001 2013-02-21 15:30:13 <helo> QuantumQrack: so it stays relatively synched up, despite not being a full node
1002 2013-02-21 15:30:15 <QuantumQrack> sorry, spv?
1003 2013-02-21 15:30:16 <TD> MC1984: sure, why wouldn't I be? i always want to be on the latest release. sammy got the S3 there.
1004 2013-02-21 15:30:32 <TD> QuantumQrack: simplified payment verification. see Satoshis paper: bitcoin.org/bitcoin.pdf
1005 2013-02-21 15:30:47 <TD> QuantumQrack: you verify the chain headers and the tx merkle branches but don't store all transactions or run scripts.
1006 2013-02-21 15:30:48 <MC1984> how long has JB been out now? No excuse for not having it on new dvices anymore
1007 2013-02-21 15:30:48 <QuantumQrack> TD, ahh, gotcha.  I am not familiar with that.
1008 2013-02-21 15:31:02 <sipa> i think wanting a full node on every device, or even the majority of users is overkill
1009 2013-02-21 15:31:06 <TD> MC1984: yeah. if HTC can't keep up they shouldn't step up. and i'm sure they realize it.
1010 2013-02-21 15:31:17 <MC1984> the problem is manufacturers using several versions of android to differentiate their too-large product lineup
1011 2013-02-21 15:31:33 <TD> QuantumQrack: it's how Satoshi envisioned the system scaling. basically it means your client trusts whatever the hardest chain says. so it can't validate everything itself, but to trick it, you need to be able to outrun the network
1012 2013-02-21 15:31:44 <QuantumQrack> no way sipa.  in the spirit of bitcoin, every person should function as a node.  This would ensure bitcoin staying non-central.
1013 2013-02-21 15:32:07 <sipa> QuantumQrack: i agree that the decentralization is measured by how easy it is to run a full node
1014 2013-02-21 15:32:08 <TD> QuantumQrack: SPV clients connect directly to the P2P network and download and process the block chain [headers].
1015 2013-02-21 15:32:10 <helo> i like the idea of the majority of users being able to run a full node. i.e. normal midrange hardware is sufficient
1016 2013-02-21 15:32:12 <MC1984> i dont think there should be a barrier to running full verifying node on most desktops going forward
1017 2013-02-21 15:32:20 <TD> QuantumQrack: see here: http://code.google.com/p/bitcoinj/wiki/SecurityModel
1018 2013-02-21 15:32:35 <sipa> helo: agree, *being able*
1019 2013-02-21 15:32:38 <MC1984> mobile is fine with spv and bloom filter, the main problem there is derisory data caps
1020 2013-02-21 15:32:41 <TD> QuantumQrack: or read satoshis paper of course
1021 2013-02-21 15:32:41 <sipa> helo: not necessarily doing it
1022 2013-02-21 15:32:48 <helo> yep
1023 2013-02-21 15:34:58 Diablo-D3 has quit (Ping timeout: 260 seconds)
1024 2013-02-21 15:35:03 * TD views SPV clients as decentralized, peer to peer nodes
1025 2013-02-21 15:35:08 <helo> setting the block size in a way that guarantees that midrange hardware is sufficient to sync up in a reasonable amount of time 10 years from now is going to be pretty tricky
1026 2013-02-21 15:35:21 <sipa> TD: well, a degree of decentralization, absolutely
1027 2013-02-21 15:35:42 <sipa> TD: but the extreme, with one full node, and only SPV clients around it, is as centralized as paypal
1028 2013-02-21 15:35:45 <TD> helo: midrange hardware 10 years from now will probably mean 24 cores with 512 GB of RAM
1029 2013-02-21 15:35:53 <TD> sipa: yes, obviously.
1030 2013-02-21 15:36:14 <sipa> so just looking at the clients isn't enough of a measure for decentralization
1031 2013-02-21 15:36:18 <MC1984> only 24?
1032 2013-02-21 15:36:32 <sipa> i agree that getting end users on SPV is an inevitable evolution, and a good one
1033 2013-02-21 15:36:50 <sipa> but at some point it - where is becomes actually hard to run a full node - things change
1034 2013-02-21 15:37:20 <helo> TD: validating a 500GB blockchain (which is roughly how big it will be at 1MB blocks) will probably be quite a chore
1035 2013-02-21 15:37:30 <jaakkos> i was thinking, would it be possible/sensible to create a bitcoin address based on biometric measurement?
1036 2013-02-21 15:37:46 <jaakkos> well it isn't obviously because the secret key can't be generated
1037 2013-02-21 15:38:15 <TD> helo: i don't think we're going to keep it at 1mb blocks. but even if we did, no, it wouldn't be a chore. especially not if we fork the chain and switch to more advanced algorithms like ed25519
1038 2013-02-21 15:38:22 <helo> a potentially 100x larger blockchain in 10 years with the current block size seems to indicate that the block size is big enough
1039 2013-02-21 15:38:25 <TD> anyway, full nodes would be run by people who are serious about it, yes
1040 2013-02-21 15:38:30 <MC1984> helo even with continued SSD improvements and MORE CORES, seeing as verifying seems pretty linear with core count?
1041 2013-02-21 15:38:38 vigilyn2 has quit (Read error: Connection reset by peer)
1042 2013-02-21 15:38:43 <TD> "serious" means you aren't gonna blink at a weeks setup time.
1043 2013-02-21 15:38:53 <TD> of course, you can also bootstrap a node by copying the database of a node you trust.
1044 2013-02-21 15:38:58 vigilyn has joined
1045 2013-02-21 15:39:00 <TD> you don't _HAVE_ to build the database from scratch
1046 2013-02-21 15:39:03 <MC1984> thats cheating
1047 2013-02-21 15:39:10 <TD> is it? we already use checkpoints
1048 2013-02-21 15:39:17 <sipa> it is not cheating, if you actually trust the data
1049 2013-02-21 15:39:33 <sipa> but convenience can easily change your sentiment over trust
1050 2013-02-21 15:39:40 <sipa> and there is becomes dangerous :)
1051 2013-02-21 15:39:58 <MC1984> i dont like checkpoints but see them as neccesary for any unforeseen shenanigans
1052 2013-02-21 15:40:01 <QuantumQrack> As long as the majority has a trusted blockchain, it doesnt matter.
1053 2013-02-21 15:40:07 <sipa> TD: i hope to get rid of checkpoints when we have headers-first sync
1054 2013-02-21 15:40:45 <TD> i don't think we should remove checkpoints, they're a nice safety feature that doesn't cost anything
1055 2013-02-21 15:41:06 <TD> i'm planning to use checkpointing quite aggressively in bitcoinj
1056 2013-02-21 15:41:12 <sipa> they cost trust from the community in a piece of centrally controlled data
1057 2013-02-21 15:41:17 <TD> on phones even syncing headers from an old checkpoint is too slow
1058 2013-02-21 15:41:30 <QuantumQrack> phones will get more powerful I think
1059 2013-02-21 15:41:42 <sipa> btw, i'm not advocating changing the no-check-sigs-when-deep-enough policy
1060 2013-02-21 15:41:45 <sipa> just the actual checkpoints
1061 2013-02-21 15:41:50 <TD> sipa: it's easily verified data. and, if you aren't auditing the code, you also need to trust that
1062 2013-02-21 15:41:58 andytoshi has joined
1063 2013-02-21 15:42:55 <sipa> well, i consider it an unnecessary hack :)
1064 2013-02-21 15:43:13 <sipa> (right now, because of implementation issues, it is necessary)
1065 2013-02-21 15:43:58 Diablo-D3 has joined
1066 2013-02-21 15:44:52 <TD> i see it as a nice safety feature and optimization point. but regardless. it can be discussed later.
1067 2013-02-21 15:45:29 <BlueMatt> Luke-Jr: yes, I have...been a bit busy, but Im trying to get around to it
1068 2013-02-21 15:45:30 <gavinandresen> Checkpoints give some people warm fuzzies-- e.g. "If my cold wallet transactions are behind a checkpoint, then they're safe FOREVER."
1069 2013-02-21 15:45:54 <gavinandresen> … people worry about weird things.
1070 2013-02-21 15:46:03 <kjj> heh
1071 2013-02-21 15:46:34 <TD> one of the next high priority items for bcj is partial chains where we throw away the headers > N blocks deep and just accept we can't accept re-orgs beyond that point
1072 2013-02-21 15:46:34 HM has quit (Read error: Connection reset by peer)
1073 2013-02-21 15:46:50 HM has joined
1074 2013-02-21 15:46:56 <TD> so that's kind of a rolling checkpoint, almost
1075 2013-02-21 15:47:01 <sipa> TD: i love the optimization part, i hate the safety feature idea
1076 2013-02-21 15:47:09 <gavinandresen> wumpus : I started a discussion about renaming Bitcoin-Qt on the Foundation forums, not sure if you ever go there.  I figured a discussion on bitcointalk would just turn into a troll-fest
1077 2013-02-21 15:47:09 <TD> you hate safety? :)
1078 2013-02-21 15:47:21 <sipa> TD: no, but it's the wrong way to get it
1079 2013-02-21 15:47:31 <TD> sipa hates safety everyone. perhaps he's a terrorist.
1080 2013-02-21 15:47:34 * gavinandresen has decided to go cold-turkey on bitcointalk for a while.....
1081 2013-02-21 15:47:49 <QuantumQrack> Probably a wise move.
1082 2013-02-21 15:47:50 <gavinandresen> sipa is a terrorist?
1083 2013-02-21 15:47:50 <TD> gavinandresen: the block limit threads are having the same effect on me ...
1084 2013-02-21 15:48:03 <sipa> TD: what i mean is, if you do headers-first sync, you can have a rule "do not do sigchecks for blocks that are more than N deep in a PoW-validated chain"
1085 2013-02-21 15:48:17 <gavinandresen> TD: yes, there's some variation on Godwin's law that says past page 2 of a bitcointalk thread you might as well give up
1086 2013-02-21 15:48:18 <sipa> TD: which has more benefits than checkpoints, and doesn't require hardcoding
1087 2013-02-21 15:48:33 <TD> sipa: sure. but checkpointing still can save us in the case of some really titanic re-org that comes out of nowhere and screws with the entire economy
1088 2013-02-21 15:48:43 <QuantumQrack> gavinandresen, its nice to have input from the worldwide bitcoin community though. I think its a necassary evil.
1089 2013-02-21 15:48:46 <sipa> if someone would do that, we're screwed anyway
1090 2013-02-21 15:49:12 <sipa> yes, the whole block size issue on the forums makes me sad
1091 2013-02-21 15:49:23 <sipa> makes it seem like consensus won't ever be reachab;e
1092 2013-02-21 15:49:23 <gavinandresen> QuantumQrack: that's like saying it's nice to tune your radio to the worldwide radio station community….
1093 2013-02-21 15:50:01 <QuantumQrack> gavinandresen, bitcoin is a community.  A large part of that community is on bitcointalk.  Ignore it at your peril. :-)
1094 2013-02-21 15:50:03 <sipa> gavinandresen: welcome to the internet
1095 2013-02-21 15:50:21 <gavinandresen> re: consensus over block size:  am I the only one who remembers the Dire Warnings about BIP16 ?  How it was going to Ruin Bitcoin ?
1096 2013-02-21 15:50:31 rdymac has quit (Quit: This computer has gone to sleep)
1097 2013-02-21 15:50:39 <QuantumQrack> afk..
1098 2013-02-21 15:50:39 <sipa> gavinandresen: BIP16 but was just a soft fork
1099 2013-02-21 15:50:48 <sipa> it WAS safe with 51% miner deployment
1100 2013-02-21 15:50:51 <gavinandresen> right, a hard fork is…. harder ....
1101 2013-02-21 15:50:52 <sipa> a hard fork isn't
1102 2013-02-21 15:51:09 <TD> the set of people who need to arrive at consensus on this topic is much smaller than {all of bitcointalk}
1103 2013-02-21 15:51:30 <TD> gavinandresen: so "Bitcoin Core" ?
1104 2013-02-21 15:51:43 <sipa> i'm not sure i agree with that
1105 2013-02-21 15:51:45 Zarutian has quit (Quit: Zarutian)
1106 2013-02-21 15:52:00 <sipa> in practice, most will side with an economic majority anyway
1107 2013-02-21 15:52:04 <sipa> but still
1108 2013-02-21 15:52:29 <TD> well, this is one of those rare times when sufficiently advanced technology can make everyone happy, i think
1109 2013-02-21 15:52:29 HM has quit (Read error: Connection reset by peer)
1110 2013-02-21 15:52:34 <TD> just most people don't realize it yet
1111 2013-02-21 15:52:36 <sipa> haha
1112 2013-02-21 15:52:44 <gavinandresen> Soft and hard forks are easier with recent versions of Bitcoin Core, because you'll get a warning if there are a bunch of new-version blocks that your client doesn't understand
1113 2013-02-21 15:53:10 <gavinandresen> (that was one of the lessons learned from BIP 16)
1114 2013-02-21 15:53:10 <helo> the issue is accessible enough that everyone's likely to have their own opinion, so i predict a massive dramafight
1115 2013-02-21 15:53:26 <gavinandresen> TD: agreed
1116 2013-02-21 15:53:44 <sipa> yeah, many people think they understand it, but it seems to me very few understand all potential issues raised
1117 2013-02-21 15:54:01 <gavinandresen> Most of the drama is stirred up by a very small minority of people.  Gotta remember that a small minority of people using Bitcoin bother reading bitcointalk
1118 2013-02-21 15:54:23 <TD> once we actually have time to really address this issue, a well written doc and a few prototypes can probably help a lot
1119 2013-02-21 15:54:35 <TD> especially if we combine the hard fork for block size limits with some obvious upgrades, like ed25519
1120 2013-02-21 15:54:50 <TD> that changes the slope of the scalability graph quite dramatically
1121 2013-02-21 15:54:55 <gavinandresen> does openssl support ed255191935 out of the box?
1122 2013-02-21 15:55:01 <sipa> gavinandresen: not afaik
1123 2013-02-21 15:55:25 <sipa> but it's just a few source files
1124 2013-02-21 15:55:25 <TD> no, though the ed25519 code is higher quality than openssl anyway imho
1125 2013-02-21 15:55:30 <sipa> yes, certainly
1126 2013-02-21 15:55:36 <TD> and was written by some of the worlds leading cryptographers. so i have a lot of confidence in it.
1127 2013-02-21 15:55:39 <gavinandresen> "just a few source files" …. mmmm….
1128 2013-02-21 15:55:58 <TD> gavinandresen: ok more than a few, but most are reimplementations of the algorithm to exploit different hardware features for extra speed
1129 2013-02-21 15:56:04 HM has joined
1130 2013-02-21 15:56:25 <sipa> the native C implementation of Ed25519 is terribly slow though
1131 2013-02-21 15:56:35 <sipa> many times slower than OpenSSL's secp256k1 ECDSA
1132 2013-02-21 15:56:37 <TD> it's written for clarity, not speed
1133 2013-02-21 15:56:40 <sipa> yes, sure
1134 2013-02-21 15:56:42 <TD> openssls ECDSA is not written for clarity
1135 2013-02-21 15:56:48 <TD> so it's not really a fair comparison
1136 2013-02-21 15:57:00 <sipa> just saying that the native C version is not a practically viable implementation
1137 2013-02-21 15:57:02 setkeh has quit (Ping timeout: 244 seconds)
1138 2013-02-21 15:57:18 <sipa> and the only optimized versions are for x86_64 afaik
1139 2013-02-21 15:57:50 <HM>  can you not optimise for a fixed curve?
1140 2013-02-21 15:58:00 <TD> yeah but x86_64 makes up approximately 100% of our userbase :)
1141 2013-02-21 15:58:03 <HM> i presume the openssl code works across many curve specifications
1142 2013-02-21 15:58:23 <sipa> TD: i doubt that - there are no 64-bit binaries for Windows of Bitcoind/Bitcoin-Qt for example :)
1143 2013-02-21 15:58:29 setkeh has joined
1144 2013-02-21 15:58:57 <sipa> so switching to Ed25519 would mostly mean dropping 32-bit support entirely
1145 2013-02-21 15:59:00 * TD shrugs
1146 2013-02-21 15:59:21 <TD> when was the last time an x86 chip shipped without 64 bit support? outside of specialized processors for netbooks or tablets i bet the answer is years ago
1147 2013-02-21 15:59:40 <sipa> yeah
1148 2013-02-21 16:00:05 <HM> Even Mozilla almost gave up on 64bit binaries. The situation is hopeless on Windows
1149 2013-02-21 16:00:47 setkeh has quit (Client Quit)
1150 2013-02-21 16:00:56 setkeh has joined
1151 2013-02-21 16:03:48 <GMP> you do understand thats its not switching, its adding. optimized ECDSA will have to stay forever, and ed25519 too.. its better be justified, and not by single/doble digit performance %
1152 2013-02-21 16:04:03 <sipa> sure
1153 2013-02-21 16:04:48 <sipa> Ed25519 is - purely from a theoretical point of view - computationally much less complex than ECDSA
1154 2013-02-21 16:05:15 <sipa> though i'd like to try writing an ECDSA secp256k1 implementation, designed from scratch as well as Ed25519, just to compare :)
1155 2013-02-21 16:05:45 <HM> you masochist
1156 2013-02-21 16:06:46 <TD> GMP: it's more like orders of magnitude faster
1157 2013-02-21 16:06:55 <TD> GMP: not a few percent. especially with batching
1158 2013-02-21 16:08:31 <s4m20> many people on virtualised vps' stick to 32 bit
1159 2013-02-21 16:09:17 ovidiusoft has quit (Read error: Operation timed out)
1160 2013-02-21 16:09:40 <GMP> 64-bit dedics are 9.99eur..
1161 2013-02-21 16:10:31 <MC1984> "I found a way to save any arbitrary files to namecoin blockchain."
1162 2013-02-21 16:10:33 <sipa> TD: not really, it's around 7 times faster when comparing 64-bit assembly-optimized versions of openssl's secp256k1 and ed25519
1163 2013-02-21 16:10:40 <MC1984> damn
1164 2013-02-21 16:10:55 <GMP> sipa: nice
1165 2013-02-21 16:11:05 <sipa> 13500 vs 1800 verifications per second, on a test i did on an i7 CPU a year ago
1166 2013-02-21 16:11:13 <sipa> no batching
1167 2013-02-21 16:11:14 <TD> sipa: that doesn't include batching
1168 2013-02-21 16:11:15 <TD> right
1169 2013-02-21 16:11:32 <TD> cycles for a batch sig verification is half that, according to their site
1170 2013-02-21 16:11:36 <HM> http://ed25519.cr.yp.to/python/ed25519.py <-- I like the lack of code in this code
1171 2013-02-21 16:11:39 <TD> and bitcoin verifies lots of signatures in batch ….. sooooo
1172 2013-02-21 16:12:01 <sipa> TD: batch verification speeds things up x2.5, according to ed25519 site
1173 2013-02-21 16:12:08 <TD> yeah
1174 2013-02-21 16:12:13 <TD> so 14 times faster, i guess
1175 2013-02-21 16:12:17 <TD> ok. one order of magnitude.
1176 2013-02-21 16:12:22 <sipa> :)
1177 2013-02-21 16:12:30 * TD handwaves
1178 2013-02-21 16:12:38 <TD> what's an order of magnitude or two amongst friends? :)
1179 2013-02-21 16:12:44 <sipa> haha
1180 2013-02-21 16:12:58 <sipa> batch verifications isn't all that trivial for us, actually
1181 2013-02-21 16:13:43 <sipa> as someone could write a masochistic script that tests for a non-success in validating a sig
1182 2013-02-21 16:14:10 <sipa> one easy solution is only using it for standard scripts
1183 2013-02-21 16:14:17 <GMP> haha why  why i never used that  (always used extended gcd()) def inv(x):
1184 2013-02-21 16:14:17 <GMP>   return expmod(x,q-2,q)
1185 2013-02-21 16:14:18 <TD> yes, of course. it's just an optimization.
1186 2013-02-21 16:14:57 <GMP> both algo run in log time
1187 2013-02-21 16:15:06 <gavinandresen> sipa: we could do ONLY  OP_CHECSIGVERIFY_ED25519   :  if it fails, txn is invalid.
1188 2013-02-21 16:15:07 <sipa> GMP: extended gcd is faster, unless you've got a very optimizid field multiplication for a single modulus (extended gcd requires arbitrary-modulus operations)
1189 2013-02-21 16:15:11 <GMP> but gcd require division
1190 2013-02-21 16:15:24 <sipa> GMP: which Ed25519 has
1191 2013-02-21 16:16:31 <sipa> gavinandresen: a pity that it wouldn't be usable for multisig or complex transactions
1192 2013-02-21 16:16:52 <gavinandresen> ok, OP_CHECKMULTISIG_ED25519_VERIFY too…..
1193 2013-02-21 16:17:20 <TD> i think using regular CHECKSIG is fine. if a signature in a batch fails, yes, it has to be retried individually
1194 2013-02-21 16:17:39 <TD> so it'd be more expensive to validate them. but if they're non-standard scripts then it may not be an issue in practice.
1195 2013-02-21 16:17:53 <gavinandresen> "if signature check fails" seems like it is mostly useful to attackers mounting a CPU exhaustion attack.
1196 2013-02-21 16:18:28 <TD> nothing stops you writing scripts that are more expensive than others already
1197 2013-02-21 16:18:44 <TD> i'm not sure we should try and enforce complete consistency of cost in every kind of script imaginable
1198 2013-02-21 16:19:32 <gavinandresen> okey dokey. I'm going to stop procrastinating and get back to implementing the payments protocol.....
1199 2013-02-21 16:19:38 <sipa> consistency in cost isn't that essential, but ability to estimate cost without execution makes sense
1200 2013-02-21 16:19:47 <sipa> (for fee/priority calculations)
1201 2013-02-21 16:20:49 <TD> yay
1202 2013-02-21 16:20:53 * TD is clearing findbugs warnings
1203 2013-02-21 16:20:57 <TD> boring but important
1204 2013-02-21 16:21:13 <gavinandresen> Random fact of the day:  QSslSocket::defaultCaCertificates()  <-- returns system-provided list of root CAs on Linux/OSX/Windows
1205 2013-02-21 16:21:27 <TD> but we want our own list, i think
1206 2013-02-21 16:21:44 <gavinandresen> sure, I'll let the user override.  But most users won't.
1207 2013-02-21 16:21:50 <HM> all those lovely dodgy foreign CAs we love so much
1208 2013-02-21 16:22:04 <TD> no, i meant, we want a canonical list blessed by the project
1209 2013-02-21 16:22:10 <TD> otherwise clients will differ in what CAs they accept
1210 2013-02-21 16:22:12 <TD> and that'd be annoying
1211 2013-02-21 16:22:42 <sipa> eww
1212 2013-02-21 16:22:45 <gavinandresen> meh.  It's the intersection of whatever is accepted on Linux/OSX/Windows.....
1213 2013-02-21 16:22:45 <MC1984> https://github.com/runn1ng/namecoin-files incase anyone doesnt look at the altcoin forum anymore
1214 2013-02-21 16:23:00 <TD> and android and iOS across different versions
1215 2013-02-21 16:23:06 <TD> and maybe chromeos
1216 2013-02-21 16:23:10 <sipa> don't forget BeOS
1217 2013-02-21 16:23:24 <TD> and whatever random distro blockchain.info runs on
1218 2013-02-21 16:23:42 <TD> in practice not specifying it will mean people have to build a canonical list anyway, except it'll be done by trial and error and always be slightly wrong
1219 2013-02-21 16:23:47 <gavinandresen> I do NOT want to decide which CA's are trustworthy enough.  I'll let Apple/Microsoft/Ubuntu/...etc figure that out
1220 2013-02-21 16:23:57 <TD> sure. so just snapshot the list used by windows or chrome or whatever.
1221 2013-02-21 16:24:05 <TD> as long as there's a list, it doesn't really matter much what's on it
1222 2013-02-21 16:24:13 <HM> what is bitcoin doing with SSL?
1223 2013-02-21 16:24:23 <HM> rpc?
1224 2013-02-21 16:24:30 <TD> signing payment requests
1225 2013-02-21 16:24:50 <HM> oh my
1226 2013-02-21 16:24:51 <lianj> "as long as there's a list, it doesn't really matter much what's on it" lol
1227 2013-02-21 16:25:28 <TD> you know what i meant
1228 2013-02-21 16:26:31 <helo> so with two different signature schemes, if one or the other is weakened, everyone could just move to the other?
1229 2013-02-21 16:26:36 <lianj> i havent looked into the ca signing for bitcoin but it sounds like a bad idea
1230 2013-02-21 16:26:44 <TD> lianj: ship has sailed
1231 2013-02-21 16:26:56 <lianj> great oO
1232 2013-02-21 16:27:12 <TD> helo: the goal of a new signature scheme would be that it'd be better than the old one, always, not as a backup in case one weakened.
1233 2013-02-21 16:27:14 <gavinandresen> … I'd say the ship is leaving the harbor....
1234 2013-02-21 16:27:17 <lianj> whats the best place to read up on it?
1235 2013-02-21 16:27:32 <TD> helo: anyway ed25519 is also based on elliptic curves. if the ECDLP problem weakens it'll affect both most likely
1236 2013-02-21 16:27:46 <helo> TD: ahh, right
1237 2013-02-21 16:27:47 <HM> I don't understand payment request singing
1238 2013-02-21 16:27:49 <HM> signing
1239 2013-02-21 16:28:03 <HM> who connects to who and why does it need SSL? any wiki links?
1240 2013-02-21 16:28:04 <TD> https://gist.github.com/gavinandresen/4120476
1241 2013-02-21 16:28:09 <TD> SSL isn't involved. just the certificates.
1242 2013-02-21 16:28:29 <TD> it's just a way to sign a payment request with a domain name or business identity instead of just providing an address (which might have been switched out by a MITM or a virus)
1243 2013-02-21 16:28:37 <gavinandresen> lianj: that gist will turn into a BIP once it is implemented and we're pretty sure we're happy with it
1244 2013-02-21 16:29:28 <TD> PKIX makes sense as a first version. later versions might support DNSSEC or whatever other PKIs people want.
1245 2013-02-21 16:29:37 <gavinandresen> If you want to help:  https://github.com/gavinandresen/paymentrequest   <-- server-side code for generating payment requests
1246 2013-02-21 16:30:04 <gavinandresen> … and : https://github.com/gavinandresen/bitcoin-git/tree/paymentrequest  <-- client-side work-in-progress
1247 2013-02-21 16:30:09 <lianj> gavinandresen: ok thanks. a lot to let sink in at first sight i must say
1248 2013-02-21 16:30:25 <TD> yeah it's been in the works for a while
1249 2013-02-21 16:30:26 zooko` has joined
1250 2013-02-21 16:30:42 <HM> sounds horrific
1251 2013-02-21 16:31:05 zooko` is now known as zooko
1252 2013-02-21 16:31:13 <BlueMatt> HM: writing a secp256k1 impl from scratch isnt as bad as it sounds
1253 2013-02-21 16:31:22 <lianj> but is it just about the request? the actual bitcoin tx that follows is unrelated?
1254 2013-02-21 16:31:45 <HM> BlueMatt: A friend of mine wrote a RSA implementation in Lisp. I was a little bit envious
1255 2013-02-21 16:32:00 <TD> lianj: the request contains the outputs the recipient would like you to create on the network
1256 2013-02-21 16:32:13 <TD> HM: why?
1257 2013-02-21 16:32:23 <TD> HM: just a kneejerk "cert authorities are bad"?
1258 2013-02-21 16:32:32 <BlueMatt> HM: heh, nice...i wrote secp256k1 in java...it was still slow :(
1259 2013-02-21 16:32:35 <gavinandresen> lianj: ummm… it is "unrelated" in the same way a bitcoin address on a web page is "unrelated" to a particular tx ….
1260 2013-02-21 16:32:45 <TD> gavinandresen: i'm thinking maybe the .proto file in the source tree should have comments for each field explaining what they're for.
1261 2013-02-21 16:32:46 <BlueMatt> (though way faster than bounce-castle)
1262 2013-02-21 16:32:52 <lianj> gavinandresen: ok, good to hear that :)
1263 2013-02-21 16:33:04 <gavinandresen> TD: Good Idea.
1264 2013-02-21 16:33:36 zooko has quit (Remote host closed the connection)
1265 2013-02-21 16:33:48 <TD> BlueMatt: the other advantage of your code would be that we could lose the bouncy castle dependency entirely. that in turn makes it simpler to compile bcj to native code using GCJ/CNI
1266 2013-02-21 16:34:13 <TD> BlueMatt: i stopped updating the branch because i upgraded bouncy castle and it started needing BigInteger.nextProbablePrime() in some unrelated code, which didn't exist in the gnu classpath version.
1267 2013-02-21 16:34:40 <lianj> gavinandresen: is it a follow up on https://gist.github.com/sipa/1237788 ?
1268 2013-02-21 16:35:01 <gavinandresen> lianj: yes
1269 2013-02-21 16:35:05 <HM> TD: I'm probably not grokking payment requests. What's the use case?
1270 2013-02-21 16:35:32 <BlueMatt> TD: hmm...well I think Ive got the branch lying around, though it would take quite a bit of work to get it mergeable...though a re-implementation of openssl line-by-line without any optimizations may also be possible
1271 2013-02-21 16:35:43 <HM> TD: If i ask you for money, and you receive the request, it could be from anyone. Sure. But once we've established a relationship you don't need a third party.
1272 2013-02-21 16:35:55 <gavinandresen> HM: click on a "pay using bitcoins" link, and instead of being asked "are you sure you want to pay 1958ds9c92d302359b8wdrt" you're asked "Are you sure you want to pay Amazon.com?"
1273 2013-02-21 16:35:57 <TD> gavinandresen: 50k seems a bit restrictive. why not make it a couple of megs or something. i'm thinking in future requests might contain pictures and logos and things.
1274 2013-02-21 16:36:10 <TD> BlueMatt: well, no matter. it's not a high priority.
1275 2013-02-21 16:36:48 <gavinandresen> TD: pictures and logos should be fetched via URL so they can be cached.....
1276 2013-02-21 16:37:08 <TD> gavinandresen: ok. 50kb still feels tight. 500kb and split the difference? :)
1277 2013-02-21 16:37:12 <helo> HM: i think the point is that signing defeats mitm
1278 2013-02-21 16:37:30 <helo> so while you may trust the counterparty, you won't have to trust the network
1279 2013-02-21 16:37:31 <TD> HM: it has a lot of use cases. you can think of it as an anti-virus protection for now though in future it'll get more features.
1280 2013-02-21 16:37:32 <gavinandresen> TD: my demo payment request is 600 bytes.
1281 2013-02-21 16:37:36 <HM> you can defeat mitm without having preshared keys or PKI
1282 2013-02-21 16:38:08 <sipa> the primary reason for a payment protocol, is to make transactions negotiable/sendable directly between the parties, instead of needing the blockchain/p2p network for all communication
1283 2013-02-21 16:38:22 <sipa> signing on top gives you nice things like proof of payment
1284 2013-02-21 16:38:24 <TD> HM: how? the designers of SSL would surely like to know …
1285 2013-02-21 16:38:50 <HM> when you pair your phone with another for instance, on first use, both phones display a code (presumably after some DH exchange) which you then read out to one another to ensure you're paired with the person you expect
1286 2013-02-21 16:38:58 <lianj> sipa: when using browser ca dont we have to pay for certs then?
1287 2013-02-21 16:38:58 <HM> after that you can communicate securely
1288 2013-02-21 16:39:16 <HM> TextSecure on android does a similar thing with text messages
1289 2013-02-21 16:39:27 <TD> HM: sure, of course. and nothing stops you having some alternative trust mechanism beyond PKIX of course.
1290 2013-02-21 16:39:35 <sipa> HM: how is that not a preshared key?
1291 2013-02-21 16:39:35 <TD> HM: but how do you do this when the other party is a website?
1292 2013-02-21 16:39:39 <TD> as is often the case?
1293 2013-02-21 16:40:00 <HM> the website refreshes and displays the code
1294 2013-02-21 16:40:09 <TD> gavinandresen: i'm thinking ahead. if it's too tight one day we might want to add a feature, and then find old clients barf.
1295 2013-02-21 16:40:21 <TD> gavinandresen: it's not like most device can't handle 500kb or so
1296 2013-02-21 16:40:44 <HM> sipa: it's postshared :P
1297 2013-02-21 16:40:45 <TD> HM: …. the threat model here is that either your internet connection is hacked (coffee shop wifi), or you have a virus that knows how to rewrite web pages.
1298 2013-02-21 16:40:48 <gavinandresen> TD: mmmm….. hardware-based devices might could have trouble….
1299 2013-02-21 16:40:51 zooko has joined
1300 2013-02-21 16:40:53 <helo> nobody should ever need more than arrrgulfmbp
1301 2013-02-21 16:40:58 <TD> HM: this is the threat model internet banking already operates under.
1302 2013-02-21 16:41:04 BTCOxygen has quit (1!~BTCOxygen@unaffiliated/mroxy/bot/btcoxygen|Ping timeout: 260 seconds)
1303 2013-02-21 16:41:16 <TD> gavinandresen: at least you'd only have to leave them behind and not old desktop apps too
1304 2013-02-21 16:41:19 <TD> but alright. as you wish.
1305 2013-02-21 16:41:20 <HM> TD: websites can be over HTTPS, what about someone who wants to register with a merchant over the phone or face to face?
1306 2013-02-21 16:41:30 <sipa> lianj: the payment protocol is designed to support multiple PKIs
1307 2013-02-21 16:41:47 <sipa> lianj: the idea is just that it optionally supports integration with a trust system
1308 2013-02-21 16:42:02 <sipa> and right now, in practice, the only viable is the SSL PKI
1309 2013-02-21 16:42:14 <gavinandresen> TD: I already got some feedback from one of the hardware device people and re-arranged the order of the fields so the whole request doesn't have to be in memory at once.
1310 2013-02-21 16:42:19 <TD> HM: HTTPS is terminated at the browser. we want this to be plumbed through to devices like the Trezor so when you confirm the payment, what you see on the secure display is meaningful to you (a name not a number)
1311 2013-02-21 16:42:40 <TD> HM: but yes if you want to do physical pre-shared keys you can of course do that. just tell your client to treat the counterparties cert as if it were a root cert. now they can self-sign.
1312 2013-02-21 16:42:45 <HM> what's a Trezor?
1313 2013-02-21 16:42:56 <TD> HM: ah ha. that would explain the confusion :) http://trezor.bitcoin.cz/
1314 2013-02-21 16:43:16 <TD> gavinandresen: yeah, i'm thinking like a few years ahead here. today small payment requests are definitely a goal.
1315 2013-02-21 16:43:42 <TD> HM: it's a device being designed that holds a wallet in secure hardware and has a little screen with a couple of buttons
1316 2013-02-21 16:44:10 <HM> so it's a security token
1317 2013-02-21 16:44:12 <HM> basically
1318 2013-02-21 16:44:15 <TD> HM: you plug it in via USB and use it to confirm payments. the device is powerful enough to do the ECDSA itself, and before it does that, the idea is it'll show you a message like "Confirm payment to bitmit.net"
1319 2013-02-21 16:44:15 <TD> yeah
1320 2013-02-21 16:44:18 <TD> except with a display.
1321 2013-02-21 16:44:41 <GMP> and amount!
1322 2013-02-21 16:44:46 <TD> of course
1323 2013-02-21 16:44:59 <HM> I have several tokens on my keyring
1324 2013-02-21 16:44:59 <TD> trezor v1 probably won't support the payment protocol. the goal is more for a v2 device.
1325 2013-02-21 16:45:49 <TD> (or a firmware upgrade to v1)
1326 2013-02-21 16:46:50 LargoG has joined
1327 2013-02-21 16:47:07 <jgarzik> Get a payment protocol out, and call it version 0.  People will use it, figure out the problems and solutions in the field, and then we'll all settle on an improved version 1.
1328 2013-02-21 16:47:10 <HM> If I want to pay a friend, i don't see why i wouldn't just pair with them directly. Same with merchants.
1329 2013-02-21 16:47:21 <jgarzik> At some point, you need to get the protocol out there, to see what works and what doesn't.
1330 2013-02-21 16:47:27 <TD> if you can physically meet them and already know their identity, that's great.
1331 2013-02-21 16:47:36 <TD> obviously not all trades fall into that category.
1332 2013-02-21 16:47:52 <TD> also, how you pair directly with someone when you have a compromised host PC is an open question.
1333 2013-02-21 16:48:04 <TD> trezor only has two buttons. it isn't powerful enough to type keys or certs in directly.
1334 2013-02-21 16:48:10 <HM> if your host is compromised so is your CA list
1335 2013-02-21 16:48:16 ralphtheninja has quit (Quit: leaving)
1336 2013-02-21 16:48:40 <TD> the idea is that the device has the CA list inside it
1337 2013-02-21 16:48:48 <TD> shipped from the factory
1338 2013-02-21 16:49:00 <HM> and when you need to revoke?
1339 2013-02-21 16:49:01 axhlf has quit (Remote host closed the connection)
1340 2013-02-21 16:49:05 <HM> or add
1341 2013-02-21 16:49:16 <GMP> CA's cert's tend to expire...
1342 2013-02-21 16:49:22 <TD> firmware upgrades will handle that.
1343 2013-02-21 16:49:29 axhlf has joined
1344 2013-02-21 16:49:39 <sipa> GMP: thanksfully, hardware tends to break
1345 2013-02-21 16:49:47 <TD> anyway
1346 2013-02-21 16:49:52 <HM> and what if the merchant you're transacting with is lazy
1347 2013-02-21 16:49:56 <TD> obviously you don't need to validate the sigs/certs if you don't care about it
1348 2013-02-21 16:49:56 <HM> and don't update their firmware
1349 2013-02-21 16:49:59 axhlf has quit (Read error: Connection reset by peer)
1350 2013-02-21 16:50:02 <TD> the merchant doesn't use a trezor - the user does.
1351 2013-02-21 16:50:12 <HM> well the user can be lazy as well
1352 2013-02-21 16:50:28 <TD> yeah, then if they get a wallet-stealing virus they might lose their money
1353 2013-02-21 16:51:05 <HM> and what about malicious firmware...the attack surface seems much the same as avoiding PKI altogether.
1354 2013-02-21 16:51:41 <TD> no it doesn't seem much the same. now you're just being difficult. the firmware is signed by the people who made the device itself. it doesn't accept any other firmwares.
1355 2013-02-21 16:51:53 <TD> anyway, you clearly aren't interested in this, so don't use it. problem solved.
1356 2013-02-21 16:52:05 <HM> ah i see, secure devices and signed firmware. a proven model :P
1357 2013-02-21 16:52:10 <TD> it is actually
1358 2013-02-21 16:52:15 <TD> that's what banks do and it works
1359 2013-02-21 16:52:38 <gavinandresen> raw bitcoin addresses aren't going away. In fact, part of the payment protocol work is making bitcoin: URIs actually work on all the plaforms we support.
1360 2013-02-21 16:53:42 Cory has quit (Ping timeout: 255 seconds)
1361 2013-02-21 16:54:09 <HM> Well, I think it'll be a disaster. I'll stop ranting now :P
1362 2013-02-21 16:55:14 <gavinandresen> nah, it'll be better than sex.  I 100% guarantee it.
1363 2013-02-21 16:55:31 <TD> but gavin is married, so take that statement with a pinch of salt
1364 2013-02-21 16:55:37 <gavinandresen> lol
1365 2013-02-21 16:55:50 <sipa> also, it'll use unicorn hair
1366 2013-02-21 16:56:03 <gavinandresen> sssh, the unicorn hair part is a secret
1367 2013-02-21 16:56:14 Cory has joined
1368 2013-02-21 16:56:15 <sipa> even better: it'll use *secret* unicorn hair
1369 2013-02-21 16:56:43 <gavinandresen> mmmm …. "Unicore Hair" as the new name for Bitcoin-Qt .....
1370 2013-02-21 16:57:06 <HM> I can see the potential for people having to trust Verisign if a merchant choses Verisign not going down well with a lot of bitcoin fans
1371 2013-02-21 16:57:08 <TD> 4.2% 0.8 nodes already, nice
1372 2013-02-21 16:57:33 <HM> the problem with PKI is the user doesn't get to chose who to trust if they want to use a merchant
1373 2013-02-21 16:57:35 <TD> HM: thought you were gonna stop ranting? :) but anyway where did you get "have to trust" from. if you don't trust them, ignore the signatures and you're back to regular addresses
1374 2013-02-21 16:57:38 <TD> no different than today
1375 2013-02-21 16:57:46 <HM> true.
1376 2013-02-21 16:58:56 <jgarzik> what % of last 1000 blocks is version-2 blocks?  That's the more interesting upgrade stat to me ;p
1377 2013-02-21 17:00:06 <TD> looks like btcguild upgraded already
1378 2013-02-21 17:00:16 <TD> maybe eclipse also
1379 2013-02-21 17:02:43 Cory has quit (Ping timeout: 276 seconds)
1380 2013-02-21 17:05:34 t7 has quit (Quit: Leaving)
1381 2013-02-21 17:05:55 gruvfunk has joined
1382 2013-02-21 17:07:56 tonikt has joined
1383 2013-02-21 17:07:58 da2ce7_d has joined
1384 2013-02-21 17:10:21 da2ce7 has quit (Ping timeout: 255 seconds)
1385 2013-02-21 17:12:11 freakazoid has joined
1386 2013-02-21 17:12:12 ovidiusoft has joined
1387 2013-02-21 17:12:21 FredEE has joined
1388 2013-02-21 17:14:25 <helo> it will be interesting if relying on CAs gives "them" the ability to interfere with bitcoin merchants
1389 2013-02-21 17:14:42 <TD> there are so many CAs they really have almost no power
1390 2013-02-21 17:14:46 <TD> that's part of the problem with the system actually
1391 2013-02-21 17:14:51 <TD> it's _too_ decentralized and quality suffers
1392 2013-02-21 17:15:05 <helo> so verisign
1393 2013-02-21 17:15:33 <HM> rubbish
1394 2013-02-21 17:15:50 * TD has never bought a cert from verisign
1395 2013-02-21 17:16:37 <helo> going after payment systems is standard faire for extrajudicial punishment these days... could relying on pkix expose bitcoin to the same kind of abuse?
1396 2013-02-21 17:16:45 <HM> the problem with PKI is the idea of having CA which both parties mutually trust doesn't work. One party ends up deciding which CA is used and the other either likes it or lumps it
1397 2013-02-21 17:16:53 <helo> they couldn't block transaction payloads, but they could cause confusion and undermine security
1398 2013-02-21 17:16:54 <HM> or at least that's the current system
1399 2013-02-21 17:17:56 agricocb has quit (Remote host closed the connection)
1400 2013-02-21 17:18:54 <HM> no CA has any real incentive to maintain a level of due diligence because everyone is forced to trust them to get shit done. Even after a massive public disgrace, people keep on using them.
1401 2013-02-21 17:19:21 <HM> as long as it's only advisary and doesn't become a deal breaker it'll be fine
1402 2013-02-21 17:19:55 Cory has joined
1403 2013-02-21 17:20:22 <TD> helo: there are CAs in every jurisdiction. USA doesn't like you? Get a cert from china or turkey instead.
1404 2013-02-21 17:20:35 <HM> except the merchant picks the CA
1405 2013-02-21 17:20:42 <HM> and if they sell stuff you want you'll use them
1406 2013-02-21 17:20:47 <TD> so?
1407 2013-02-21 17:20:54 <TD> this is no different to visiting an SSLd website
1408 2013-02-21 17:20:58 <HM> I know
1409 2013-02-21 17:21:01 <HM> which is also broken
1410 2013-02-21 17:21:08 unknown45682 has quit (Ping timeout: 246 seconds)
1411 2013-02-21 17:21:27 <TD> well, terminally hosed CAs do get revoked and then merchants who had certs from them have to buy new ones
1412 2013-02-21 17:21:29 <TD> see: diginotar
1413 2013-02-21 17:21:40 <TD> so it's not a complete loss
1414 2013-02-21 17:22:09 <TD> i suppose theoretically the protocol could support multiple cert chains up to multiple different roots
1415 2013-02-21 17:22:23 <TD> but that's not a feature that sounds very likely to be used. most users just don't have opinions on particular CAs
1416 2013-02-21 17:22:32 <TD> it's up to browser/wallet vendors to make that decision
1417 2013-02-21 17:23:03 <TD> if some CA was dicking about with the bitcoin world then wallet makers would revoke them and merchants who were signing their payment requests with those certs would just appear as unsigned for a while until they bought new certs
1418 2013-02-21 17:24:01 <HM> I await the first Bitcoin CA and the first Bitcoin CA hack
1419 2013-02-21 17:24:15 <HM> just like exchanges, it'll be laughable.
1420 2013-02-21 17:24:24 <HM> let people take charge of their own trust, that's my opinion
1421 2013-02-21 17:24:42 <TD> if you want to do that, go right ahead
1422 2013-02-21 17:24:48 <TD> you can compile lists of certs you trust
1423 2013-02-21 17:25:05 <HM> nobody will do that. they'll follow the herd like sheep
1424 2013-02-21 17:25:42 <HM> but hey, as long as it doesn't become a requirement before you can make a transaction with a merchant, it's cool
1425 2013-02-21 17:26:04 <TD> i can't imagine it would ever be, given that a "merchant" might be another person and there's no PKI for individuals
1426 2013-02-21 17:26:10 <TD> outside of enlightened countries like Estonia, that is
1427 2013-02-21 17:26:20 <TD> perhaps one day we'll set one up
1428 2013-02-21 17:26:40 <TD> but even if people and companies all had certs, we also want to be able to pay machines that run autonomous agents and stuff
1429 2013-02-21 17:26:43 <HM> of course there's PKI for invidivuals
1430 2013-02-21 17:26:47 <HM> individuals*
1431 2013-02-21 17:26:50 <TD> so a notion of identity is always going to be optional
1432 2013-02-21 17:26:54 <TD> what is it?
1433 2013-02-21 17:27:01 <TD> email providers that support DKIM sorta do it
1434 2013-02-21 17:27:19 BTCTrader has quit (Quit: BTCTrader)
1435 2013-02-21 17:27:37 <sipa> TD: beglium's identity cards form one, actually
1436 2013-02-21 17:27:49 <TD> s/Estonia/Estonia and Belgium/
1437 2013-02-21 17:27:52 <HM> i have certificates from StartSSL for my email address and domains
1438 2013-02-21 17:27:59 <sipa> damn, i fail at typing my country's name
1439 2013-02-21 17:28:14 <HM> they actually use client certificates for authentication
1440 2013-02-21 17:28:17 <coblee> bitcoin 0.8 is giving me corrupt databases on my Mac OSX 10.6.8. i've tried loading the block chain from peers and from bootstrap.dat. I've reverted back to 0.7.2 to make sure that it's 0.8 and not my computer. any ideas? has this been tested on OSX 10.6.8?
1441 2013-02-21 17:29:01 <TD> HM: yeah but that's really unusual. almost nobody has such certs. fortunately email providers sign most mail on their users behalf
1442 2013-02-21 17:29:03 <helo> coblee: did you get 0.7.2 from the same source as 0.8?
1443 2013-02-21 17:29:11 <TD> so that's a reasonable standin. but it needs extra work to be usable in the bitcoin context
1444 2013-02-21 17:29:17 <helo> coblee: that is, did you compile one yourself, and not the other?
1445 2013-02-21 17:29:50 <coblee> helo: yeah, both downloaded from sourceforge
1446 2013-02-21 17:29:53 <HM> TD: they sign to authenticate the server really. it doesn't gaurantee anything about who sent the e-mail unless you trust their server/webmail interface etc.
1447 2013-02-21 17:30:12 <sipa> coblee: 0.8 way of validating the database is very different from 0.7
1448 2013-02-21 17:30:28 <sipa> coblee: it may well be that there's something causing corruption, and one version notices and the other doesn't
1449 2013-02-21 17:31:37 gruvfunk has quit (Ping timeout: 276 seconds)
1450 2013-02-21 17:31:46 <coblee> i've tried 0.8 about 5 times. it stops at a different block height and either craps out with a corrupt db due to checksum mismatch error, or it will stop accepting new blocks claiming that the hash is invalid
1451 2013-02-21 17:32:16 ProfMac has joined
1452 2013-02-21 17:32:39 <TD> HM: yeah exactly. at which point DNSSEC+DKIM is just as good
1453 2013-02-21 17:32:46 word_ has joined
1454 2013-02-21 17:33:16 <HM> I trust DNSSEC more than I trust the CAs. they at least put some decent master key sharing in place
1455 2013-02-21 17:34:03 <HM> the CA hacks to date have all shown incompetance, and there are over 600 organisations trusted by your browser that can sign certificates for *any* domain
1456 2013-02-21 17:34:26 <TD> there are over 100 TLDs though
1457 2013-02-21 17:34:46 <TD> there's an amusing list of DNSSEC screwups somewhere inside google. the number of ways people get it wrong is amazing.
1458 2013-02-21 17:34:58 <TD> i think DNSSEC will be better than the SSL PKI but not massively so
1459 2013-02-21 17:35:10 <TD> primary advantage? you can get arbitrary extra data signed which SSL CAs won't do
1460 2013-02-21 17:35:20 <TD> also it should hopefully be free
1461 2013-02-21 17:35:32 <HM> what? one isn't a replacement for the other
1462 2013-02-21 17:35:51 word has quit (Ping timeout: 252 seconds)
1463 2013-02-21 17:36:13 <TD> it is for any site that only uses a domain cert
1464 2013-02-21 17:36:19 <TD> for EV certs, no, that's true
1465 2013-02-21 17:36:23 <HM> there's always a problem of establishing trust between newly met parties, but i regard that as a social problem not a technical one
1466 2013-02-21 17:37:16 Cory has quit (Ping timeout: 244 seconds)
1467 2013-02-21 17:40:58 jouke has quit (Remote host closed the connection)
1468 2013-02-21 17:42:24 tsche has quit ()
1469 2013-02-21 17:44:15 rdymac has joined
1470 2013-02-21 17:45:51 TD has quit (Quit: TD)
1471 2013-02-21 17:46:05 tsche has joined
1472 2013-02-21 17:46:51 ProfMac has quit (Ping timeout: 245 seconds)
1473 2013-02-21 17:48:57 rdymac has quit (Client Quit)
1474 2013-02-21 17:49:28 mappum has joined
1475 2013-02-21 17:49:28 rdymac has joined
1476 2013-02-21 17:55:19 zooko has left ("#tahoe-lafs")
1477 2013-02-21 17:56:37 JDuke128 has joined
1478 2013-02-21 17:57:24 JDuke128 has quit (Remote host closed the connection)
1479 2013-02-21 17:58:14 jouke has joined
1480 2013-02-21 18:02:23 moarrr has quit (Read error: No route to host)
1481 2013-02-21 18:05:58 jevin has quit (Quit: Textual IRC Client: www.textualapp.com)
1482 2013-02-21 18:09:50 jevin has joined
1483 2013-02-21 18:13:11 sgornick has quit (Read error: Operation timed out)
1484 2013-02-21 18:13:58 Muis_ has joined
1485 2013-02-21 18:14:07 Muis has quit (Ping timeout: 240 seconds)
1486 2013-02-21 18:20:01 andrew_wmf has joined
1487 2013-02-21 18:21:09 andrew_wmf has quit (Client Quit)
1488 2013-02-21 18:22:40 Cory has joined
1489 2013-02-21 18:29:13 drizztbsd has quit (Remote host closed the connection)
1490 2013-02-21 18:32:18 sync has joined
1491 2013-02-21 18:32:42 sync is now known as Guest64904
1492 2013-02-21 18:33:27 <Guest64904> ok
1493 2013-02-21 18:33:55 Guest64904 has left ()
1494 2013-02-21 18:40:30 axhlf has joined
1495 2013-02-21 18:41:05 rdymac has quit (Quit: This computer has gone to sleep)
1496 2013-02-21 18:41:34 root2 has joined
1497 2013-02-21 18:43:58 rdymac has joined
1498 2013-02-21 18:44:28 FredEE has quit (Quit: FredEE)
1499 2013-02-21 18:44:57 juchmis has joined
1500 2013-02-21 18:46:55 coolsa_ has joined
1501 2013-02-21 18:48:39 discretefx has joined
1502 2013-02-21 18:50:32 discrete has quit (Read error: Connection reset by peer)
1503 2013-02-21 18:50:33 Jackneill has quit (Read error: Operation timed out)
1504 2013-02-21 18:50:34 variousnefarious has quit (Remote host closed the connection)
1505 2013-02-21 18:50:34 swappermall has quit (Ping timeout: 256 seconds)
1506 2013-02-21 18:50:34 techlife has quit (Ping timeout: 256 seconds)
1507 2013-02-21 18:50:35 coolsa has quit (Ping timeout: 256 seconds)
1508 2013-02-21 18:50:40 variousnefarious has joined
1509 2013-02-21 18:51:08 none has joined
1510 2013-02-21 18:51:39 techlife has joined
1511 2013-02-21 18:51:39 techlife has quit (Max SendQ exceeded)
1512 2013-02-21 18:52:14 techlife has joined
1513 2013-02-21 18:52:15 techlife has quit (Max SendQ exceeded)
1514 2013-02-21 18:52:50 techlife has joined
1515 2013-02-21 18:52:51 techlife has quit (Max SendQ exceeded)
1516 2013-02-21 18:53:23 techlife has joined
1517 2013-02-21 18:53:23 techlife has quit (Max SendQ exceeded)
1518 2013-02-21 18:53:56 techlife has joined
1519 2013-02-21 18:53:57 techlife has quit (Max SendQ exceeded)
1520 2013-02-21 18:54:06 shwooop has quit (Ping timeout: 252 seconds)
1521 2013-02-21 18:54:27 techlife has joined
1522 2013-02-21 18:54:28 techlife has quit (Max SendQ exceeded)
1523 2013-02-21 18:54:51 rdymac has quit (Quit: This computer has gone to sleep)
1524 2013-02-21 18:54:58 techlife has joined
1525 2013-02-21 18:56:07 LargoG has quit (Ping timeout: 276 seconds)
1526 2013-02-21 18:56:43 LargoG has joined
1527 2013-02-21 18:57:48 jdnavarro has joined
1528 2013-02-21 19:00:40 coolsa_ has quit (Ping timeout: 276 seconds)
1529 2013-02-21 19:02:09 b00tkitz has quit (Quit: leaving)
1530 2013-02-21 19:03:28 grondilu has joined
1531 2013-02-21 19:04:05 <grondilu> guys, where could I find numeric example values for a testbench of an elliptic artithmetic module?
1532 2013-02-21 19:04:28 <grondilu> s/elliptic/& curve/
1533 2013-02-21 19:04:34 LargoG has quit (Ping timeout: 276 seconds)
1534 2013-02-21 19:04:42 Jackneill has joined
1535 2013-02-21 19:09:32 denisx has joined
1536 2013-02-21 19:10:04 whizter has joined
1537 2013-02-21 19:10:42 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
1538 2013-02-21 19:11:43 frosks has joined
1539 2013-02-21 19:13:58 axhlf has quit (Ping timeout: 252 seconds)
1540 2013-02-21 19:20:11 reizuki__ has joined
1541 2013-02-21 19:20:57 shwooop has joined
1542 2013-02-21 19:22:53 coolsa has joined
1543 2013-02-21 19:22:54 gruvfunk has joined
1544 2013-02-21 19:23:30 [ken] has joined
1545 2013-02-21 19:26:12 rdymac has joined
1546 2013-02-21 19:26:58 reizuki__ has quit (Ping timeout: 252 seconds)
1547 2013-02-21 19:27:10 rdymac has quit (Client Quit)
1548 2013-02-21 19:27:46 Cory has quit (Ping timeout: 264 seconds)
1549 2013-02-21 19:28:10 frosks has quit (Remote host closed the connection)
1550 2013-02-21 19:28:10 rdymac has joined
1551 2013-02-21 19:28:44 egecko has joined
1552 2013-02-21 19:29:00 FredEE has joined
1553 2013-02-21 19:30:30 jdnavarro has quit (Remote host closed the connection)
1554 2013-02-21 19:32:07 chrisco has joined
1555 2013-02-21 19:37:32 axhlf has joined
1556 2013-02-21 19:40:39 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1557 2013-02-21 19:41:00 BTCTrader has joined
1558 2013-02-21 19:41:44 BTCTrader has quit (Read error: Connection reset by peer)
1559 2013-02-21 19:42:18 tonikt has quit (Read error: Connection reset by peer)
1560 2013-02-21 19:44:29 daybyter has joined
1561 2013-02-21 19:44:47 BTCTrader has joined
1562 2013-02-21 19:46:33 coolsa_ has joined
1563 2013-02-21 19:49:15 axhlf has quit (Remote host closed the connection)
1564 2013-02-21 19:49:32 runeks has joined
1565 2013-02-21 19:49:56 coolsa has quit (Ping timeout: 256 seconds)
1566 2013-02-21 19:50:04 BTCTrader has quit (Ping timeout: 276 seconds)
1567 2013-02-21 19:51:03 FredEE has quit (Quit: FredEE)
1568 2013-02-21 19:53:22 axhlf has joined
1569 2013-02-21 19:55:06 agath has quit (Remote host closed the connection)
1570 2013-02-21 19:55:25 agath has joined
1571 2013-02-21 19:56:40 <MC1984> "How a floating blocksize limit inevitably leads towards centralization"
1572 2013-02-21 19:57:02 <MC1984> anyone read this thread? whats the general consensus?
1573 2013-02-21 19:57:29 <MC1984> ive had the tab open for 4 days and im putting off reading it all :(
1574 2013-02-21 20:00:03 s4m20 has quit (Quit: Lost terminal)
1575 2013-02-21 20:01:09 agricocb has joined
1576 2013-02-21 20:05:18 wereHamster has quit (Changing host)
1577 2013-02-21 20:05:18 wereHamster has joined
1578 2013-02-21 20:09:56 <helo> ~no consensus
1579 2013-02-21 20:11:22 <phantomcircuit> MC1984, he's wrong
1580 2013-02-21 20:11:40 <phantomcircuit> it leads towards only the most low cost miners being able to mine
1581 2013-02-21 20:11:46 discretefx has quit (Ping timeout: 244 seconds)
1582 2013-02-21 20:11:47 <phantomcircuit> which is the current state of affairs anyways
1583 2013-02-21 20:12:07 discrete has joined
1584 2013-02-21 20:12:27 <MC1984> gavin still seems to think raising the cap is neccesary i see
1585 2013-02-21 20:17:20 <helo> phantomcircuit: it will affect only miners, and not full nodes?
1586 2013-02-21 20:17:33 <jurov> i've read it not much consensus.
1587 2013-02-21 20:18:12 <jurov> even added my opinion, got reply "what about poor miners with 1200 baud internet?"
1588 2013-02-21 20:18:20 <jurov> gave up.
1589 2013-02-21 20:18:54 <phantomcircuit> helo, it would but the effect would be roughly the same for slow nodes vs fast nodes as long as they can keep up with the rate of transactions
1590 2013-02-21 20:19:05 <phantomcircuit> and realistically even very slow nodes will be able to catch up
1591 2013-02-21 20:19:13 <phantomcircuit> (although it might take a week instead of a day)
1592 2013-02-21 20:19:29 <phantomcircuit> helo, however the post is about miners on slow internet connections really
1593 2013-02-21 20:19:41 <phantomcircuit> and frankly that's just a silly concern
1594 2013-02-21 20:19:54 <jurov> yes, i think even 100x current volume shouldn't be a problem
1595 2013-02-21 20:20:20 <phantomcircuit> well... it wouldn't be a problem but it also wouldn't be a smooth transition
1596 2013-02-21 20:20:20 <helo> that's roughly the 1MB limit
1597 2013-02-21 20:20:30 rdymac has quit (Quit: This computer has gone to sleep)
1598 2013-02-21 20:20:40 <helo> err... 10x the 1MB limit
1599 2013-02-21 20:20:58 <phantomcircuit> it would certainly cause problems for some people
1600 2013-02-21 20:21:04 <jurov> i think 5 seconds limit is good idea... did not find rational counterargument, really
1601 2013-02-21 20:21:28 <helo> how big of a block should a full node accept as valid?
1602 2013-02-21 20:21:58 <phantomcircuit> helo, currently it's 1MB iirc
1603 2013-02-21 20:22:00 <phantomcircuit> i might be wrong
1604 2013-02-21 20:22:17 <phantomcircuit> the rules most miners are using sets a smaller soft limit though
1605 2013-02-21 20:22:26 <jurov> someone should make an estimate/measurement how big block these 5 seconds mean on average pc
1606 2013-02-21 20:22:32 <helo> yeah, it's 1MB
1607 2013-02-21 20:22:42 <helo> with a default max size of 250k
1608 2013-02-21 20:22:51 <helo> (for generated blocks)
1609 2013-02-21 20:22:59 <phantomcircuit> jurov, im not sure what you mean by that
1610 2013-02-21 20:23:12 <helo> jurov: the 5s limit is how long a miner would have to validate it in?
1611 2013-02-21 20:23:42 <jurov> gavin proposes if any node wouldn't validate block in 5 seconds, to drop it
1612 2013-02-21 20:24:00 <jurov> longer timeout if it's catching up
1613 2013-02-21 20:24:21 <phantomcircuit> as a soft rule or a hard network rule?
1614 2013-02-21 20:24:35 <phantomcircuit> gavinandresen, ^ can you comment on that
1615 2013-02-21 20:24:59 <jurov> dunno how hard. this would mean big blocks validating several seconds would propagate very slow due many nodes dropping them
1616 2013-02-21 20:25:15 <gavinandresen> soft rule. The hard rule would be "no limit"
1617 2013-02-21 20:25:20 <jurov> i like that
1618 2013-02-21 20:25:21 <petertodd> phantomcircuit: No, it leads to the most low *overhead* miners being able to mine.
1619 2013-02-21 20:26:04 <MC1984> reading through it slowly
1620 2013-02-21 20:26:05 <petertodd> phantomcircuit: Overhead is different than mining cost; overhead is what you spend on stuff distinct from hashing power, your network connection, your validating node hardware, disk space, all the stuff that doesn't contribute to the security of the network.
1621 2013-02-21 20:26:10 <MC1984> seems like a huge bunfight
1622 2013-02-21 20:26:56 <petertodd> phantomcircuit: On the other hand, what does contribute to the security of the network is hashing power, and there you want the cost for legit miners with an incentive to be honest to be as low as possible relative to the cost for attackers, and you want the incentives to not lead to centralization.
1623 2013-02-21 20:27:01 <gavinandresen> do we have any data on how directly miners are connected?  e.g. if I broadcast a new block, does it reach 50% of hashing power without going through a relay?
1624 2013-02-21 20:27:14 Cory has joined
1625 2013-02-21 20:27:18 daybyter has quit (Read error: Connection reset by peer)
1626 2013-02-21 20:27:29 <petertodd> phantomcircuit: That's why you want to keep overhead low, so the startup cost to mine is as little as possible and people can do so in their basement while *still* validating fully. (pools by themselves aren't enough)
1627 2013-02-21 20:27:33 <gavinandresen> … because validating relay nodes wont have a lot of incentive to invest in super-high-speed network connections....
1628 2013-02-21 20:27:48 <phantomcircuit> gavinandresen, without going through a relay? assuming the default 8 connections almost certainly not
1629 2013-02-21 20:27:50 <gavinandresen> … which is a good thing, if miners are afraid that their blocks will be orphaned if they're too big
1630 2013-02-21 20:27:59 <petertodd> gavinandresen: Good question. I suspect the picture now will be totally different than if blocks become bigger.
1631 2013-02-21 20:28:24 <petertodd> gavinandresen: Right now running a node for fun is fairly cheap, so lots of people, myself included, are really just giving bandwidth away.
1632 2013-02-21 20:28:42 <gavinandresen> okey dokey
1633 2013-02-21 20:28:47 <phantomcircuit> petertodd, for even the most tiny operation the cost of a network connection and the validating nodes hardware should be trivial compared to the cost of the actual hashing hardware
1634 2013-02-21 20:29:17 <petertodd> gavinandresen: Yes, but miners can always connect directly to other miners, and the biggest operations can afford to track down those other miners the best to keep their orphan rates low.
1635 2013-02-21 20:29:35 <petertodd> phantomcircuit: Right now that's true, with 1GiB blocks that won't be true.
1636 2013-02-21 20:29:53 <gavinandresen> sure, and they could get together a cartel with 51% and then ignore the other 49%'s blocks, too......
1637 2013-02-21 20:30:00 <phantomcircuit> 1GiB blocks doesn't seem... practical
1638 2013-02-21 20:30:38 <petertodd> gavinandresen: The point is they don't have to get together in a cartel or have any organization at all, orphan rates do the job naturally.
1639 2013-02-21 20:30:40 <helo> if it floats, keeping tx fees low as volume increases, isn't 1GiB possible?
1640 2013-02-21 20:30:40 <gavinandresen> I really feel like we'd be making a mistake if we bet against technology getting better/faster/cheaper.
1641 2013-02-21 20:31:11 <petertodd> gavinandresen: I'm an electronics designer, and I feel like we'd be making a mistake betting technology will keep getting better/faster/cheaper. Moores law doesn't have that many more interations left.
1642 2013-02-21 20:31:30 rbecker is now known as RBecker
1643 2013-02-21 20:31:32 <petertodd> gavinandresen: I work in analog actually, and much of that field has hit physical limits and stuff has just stopped getting better.
1644 2013-02-21 20:31:43 <MC1984> isnt bitcoin the least of our concerns in that case
1645 2013-02-21 20:31:45 <helo> i like the idea of decentralization increasing over time as technology gets better/faster/cheaper
1646 2013-02-21 20:32:05 <petertodd> MC1984: why? so computers become like normal consumer products, so what?
1647 2013-02-21 20:32:23 <petertodd> MC1984: lots of cars still get sold even though the improvements are gradual
1648 2013-02-21 20:32:54 <helo> rather than risking growing faster than technology advances, and largely wrecking decentralization
1649 2013-02-21 20:33:32 <MC1984> this seems like a saddle problem
1650 2013-02-21 20:33:41 <MC1984> like a ball resting on a saddle
1651 2013-02-21 20:34:04 <gavinandresen> petertodd: ok.  So do a back-of-the-envelope calculation on a reasonable max block size is in… oh, two years.  1MB ?  bigger?  smaller  ?
1652 2013-02-21 20:34:05 <MC1984> like, theres one very specific equilibrium case for what bitcoin is supposed to be
1653 2013-02-21 20:34:39 <petertodd> gavinandresen: Well, I think we should work like heck to create solid off-chain transaction methods, and only if that fails, then we consider raising the limit.
1654 2013-02-21 20:35:02 <petertodd> gavinandresen: And when the least efficient chain-space utilizers like satoshidice complain in the interm, tell them to take a hike.
1655 2013-02-21 20:35:02 <gavinandresen> petertodd: I think putting all of our eggs in the off-chain transaction basket is a bad idea.
1656 2013-02-21 20:35:20 <petertodd> gavinandresen: Me too, but raising the limit will take less time than really getting those ideas to work.
1657 2013-02-21 20:36:13 <petertodd> gavinandresen: You're probably right about website-based bitcoin services becoming more and more popular, so in the future we'll need less consensus and hopefully less time, 6 months hopefully?
1658 2013-02-21 20:36:43 <gavinandresen> We're in the middle of a soft fork right now… but I haven't look at adoption rate of block.version==2 blocks
1659 2013-02-21 20:37:07 <petertodd> gavinandresen: Then put a *non-miner-controlled* increase in place if you have to, perferably the simpliest way possible so the multitude of implementations that have to change are less likely to screw it up.
1660 2013-02-21 20:37:52 <petertodd> Yeah, who was graphing that data again? Looked like the 95% target could happen faster than you'd think with ASCIs.
1661 2013-02-21 20:38:34 <petertodd> (oh, and by miner controlled, I mean floating rates, voting on it in coinbases is ok)
1662 2013-02-21 20:40:22 <phantomcircuit> gavinandresen, so with a soft rule to drop blocks that are slow to process how do you avoid that effectively being a hard rule if a large % (but not all) of the network agrees on the definition of slow?
1663 2013-02-21 20:40:33 <helo> is there some other way to lower satoshi dice's % abuse of blocks than increasing fees (presumably because of tight block space)?
1664 2013-02-21 20:41:02 <phantomcircuit> helo, hilarious hilarious ways
1665 2013-02-21 20:41:16 <helo> :D
1666 2013-02-21 20:41:23 <gavinandresen> sure, we could make transactions with small outputs non-standard…..
1667 2013-02-21 20:41:37 <gavinandresen> (something we should seriously consider when the payment protocol is available, I think)
1668 2013-02-21 20:41:38 JWU_42_ has joined
1669 2013-02-21 20:42:32 <gavinandresen> wallet full of dust spam, and dust spam in the UTXO set, are bad.
1670 2013-02-21 20:42:50 <petertodd> Yeah, small outvalue non-standard is good I think.
1671 2013-02-21 20:42:59 <petertodd> Anything < a tx fee really.
1672 2013-02-21 20:43:15 <helo> the foundation needs to set up its own "non-profit" SD competitor
1673 2013-02-21 20:43:26 <gavinandresen> RE: soft versus hard rule:  uhh… if your ginormous blocks are rejected, then they're rejected, the soft/hard line will be determined by who is participating in the network.
1674 2013-02-21 20:43:43 <helo> a lot of the anti-gambling rules change with non-profit orgs
1675 2013-02-21 20:43:46 <petertodd> phantomcircuit: Anything that discourages blocks is dangerous; it becomes an easy way to fork the hashing power.
1676 2013-02-21 20:44:26 <gavinandresen> dangerous in this case is good, it discourages miners from skating too close to the "might be rejected" line
1677 2013-02-21 20:45:12 <petertodd> Sure, the second a miner can use it to perform an attack with greater value than the block reward they have a reason to do it anyway.
1678 2013-02-21 20:45:20 <petertodd> *but the second
1679 2013-02-21 20:45:29 <jurov> even if large miners connect themselves with phat pipes...there's still incentive for smaller miners to mine smaller blocks with cherry-picked best-value transactions
1680 2013-02-21 20:46:07 <petertodd> Even without explicit rules this is a problem, just with larger proportions of hashing power, if one side of the fork can mine new blocks faster than it can validate the large blocks from the other side.
1681 2013-02-21 20:46:40 <petertodd> With explicit rules you just have to find a minority target that will reject a block, get such a block mined, and then feed them extensions of the fork they're on.
1682 2013-02-21 20:46:44 <gavinandresen> uhhh…. blocks that take 10 MINUTES to validate?
1683 2013-02-21 20:47:00 WolfAlex has joined
1684 2013-02-21 20:47:24 <petertodd> If there is a bug, that could very well happen. Or the usual example of a node on a slow connection, potentially just a connection made *temporarily* slow.
1685 2013-02-21 20:47:36 axhlf has quit (Remote host closed the connection)
1686 2013-02-21 20:47:42 <gavinandresen> okey dokey.  That could happen today, right?
1687 2013-02-21 20:47:55 <petertodd> Absolutely, but with 1MiB blocks it's a lot less likely; 1MiB is tiny.
1688 2013-02-21 20:47:55 joshft has joined
1689 2013-02-21 20:48:14 <petertodd> (the example being a fiber cut that separates a whole country on it's own)
1690 2013-02-21 20:48:21 <gavinandresen> so, again….  do you think 1MB is the Perfect Size ?
1691 2013-02-21 20:48:46 <petertodd> If satoshi chose 10MiB I'd say it's the perfect size, because it's what we have now.
1692 2013-02-21 20:48:57 dparrish has quit (Quit: leaving)
1693 2013-02-21 20:49:12 freakazoid has quit (Ping timeout: 272 seconds)
1694 2013-02-21 20:49:13 <petertodd> Changing this stuff says we're open to changing it, and if we don't do it because we really have to, we're saying we'll change it again, and again.
1695 2013-02-21 20:49:17 <muhoo> the general trend in technology is a seesaw between centrlized and decentralized
1696 2013-02-21 20:49:25 <muhoo> been that way for lifetimes now.
1697 2013-02-21 20:50:04 <gavinandresen> Sigh.  I'm COMPLETELY AND UTTERLY AGAINST changing it again and again.  I don't want the Official BlockSize Committee to set the size, I want to let the market decide the size
1698 2013-02-21 20:50:05 <muhoo> so maybe btc is heading towards centralized, web wallets, blockchain.info, mtgox, etc. then something disruptive wll happen and things will decentralize
1699 2013-02-21 20:50:24 WolfAlex_ has quit (Ping timeout: 255 seconds)
1700 2013-02-21 20:50:31 <phantomcircuit> gavinandresen, the issue is some portion of the network decides the block shouldn't be accepted while another decides it should be
1701 2013-02-21 20:50:33 <muhoo> if you can isolate yourself from those cycles, then great.
1702 2013-02-21 20:50:40 <petertodd> gavinandresen: ...and as I've shown, you *can't* let the market decide the size! There are peverse incentives; it becomes an attack route that we don't understand well.
1703 2013-02-21 20:50:51 <phantomcircuit> so the rules for soft reject would have to be deterministic at least :)
1704 2013-02-21 20:51:03 <gavinandresen> petertodd: you think.  I'm still unconvinced.
1705 2013-02-21 20:51:07 <petertodd> gavinandresen: Maybe, *maybe* a proof-of-stake vote could pull it off, but I don't see any way of actually doing that.
1706 2013-02-21 20:51:41 <petertodd> gavinandresen: I wish one of the alt-chains had a floating limit so I could demonstrate the attack, or be shown to be wrong.
1707 2013-02-21 20:51:53 <jurov> proof of stake by tieing blocksize to previous txfees?
1708 2013-02-21 20:52:15 <petertodd> jurov: the vote has to be completely out of miner control; txfees are under miner control.
1709 2013-02-21 20:52:37 JWU_42_ has left ()
1710 2013-02-21 20:53:03 <jurov> the validation timeout is as far from miner control as possible... no idea what could be better
1711 2013-02-21 20:53:06 <gavinandresen> no, if your block gets orphaned any fake fees you inserted get lost
1712 2013-02-21 20:53:10 <petertodd> gavinandresen: You gotta admit, even if the particular method I outlined is wrong, god knows what other attacks are out there lurking.
1713 2013-02-21 20:53:35 <gavinandresen> petertodd: I agree it needs deep thought.  But I still think it will need to be raised.
1714 2013-02-21 20:53:43 <petertodd> gavinandresen: Yes, but with low and unknown probability, and probability that is much lower when you use high-overhead techniques like broadcasting directly to every ndoe.
1715 2013-02-21 20:54:03 <gavinandresen> you keep saying things like "broadcasting to every node" like that was easy.....
1716 2013-02-21 20:54:18 <petertodd> gavinandresen: Don't get me wrong, I see that it may need to be raised too, but we have to let the community realize that it also might not be possible to raise it.
1717 2013-02-21 20:54:45 <petertodd> gavinandresen: blockchain.info does a pretty good job of it... after all, you don't need 100%, orphan probability goes down for every additional node to connect too
1718 2013-02-21 20:54:49 owowo has joined
1719 2013-02-21 20:55:32 <muhoo> triangular numbers. i everyone connects to everyone...
1720 2013-02-21 20:55:33 <petertodd> gavinandresen: Point is, you can't assume orphans make a fake tx fee attack expensive, because the minimum orphan rate is 0%
1721 2013-02-21 20:55:45 <gavinandresen> the minimum orphan rate is not zero
1722 2013-02-21 20:55:53 <denisx> jgarzik: I think I found a small problem with pushpoold
1723 2013-02-21 20:55:53 <gavinandresen> it can't be in a universe with a finite speed of light....
1724 2013-02-21 20:56:14 <petertodd> gavinandresen: ...and if it turns out all the mining capacity is actually sitting in the same server closet?
1725 2013-02-21 20:56:29 <gavinandresen> then we've got bigger problems than max block size
1726 2013-02-21 20:56:33 <petertodd> gavinandresen: point it, we don't know, can't know, and must assume it could be very, very small.
1727 2013-02-21 20:57:38 <gavinandresen> sigh.  this is why I have trouble taking you seriously, you want to start arguing from irrational assumptions like "assume the orphan rate is zero…."
1728 2013-02-21 20:57:40 chrisco has left ()
1729 2013-02-21 20:57:47 <petertodd> 20,000km/c = 66ms, or 0.01% orphan rate
1730 2013-02-21 20:57:59 <petertodd> maybe 10x that for real hardware
1731 2013-02-21 20:58:04 <gavinandresen> … and you seem completely immune to the possiblity that there IS a solution
1732 2013-02-21 20:58:13 <petertodd> or less because hashing power is concentrated
1733 2013-02-21 20:58:41 <petertodd> gavinandresen: My assumptions are *safe*
1734 2013-02-21 20:59:42 <gavinandresen> You're also assuming that any decision is irreversible. That if we see Bad Things happening "we" can't tell people:  Hey, bad things are happening-- you know that change we made?  we need to fix it
1735 2013-02-21 20:59:54 <petertodd> And what I propose, make it clear that raising the block limit may or may *not* happen, is also safe and hedges are bets. Of course, you probably want to temper that statement, because most people don't understand it, but I want to see alternatives actually get worked on, and not just my pet idea.
1736 2013-02-21 21:00:23 <gavinandresen> I think you're biased because you want the off-the-chain stuff to happen so badly.
1737 2013-02-21 21:00:33 <petertodd> Assuming the decision *is* irreversible is another safe assumption. I know damn well that lowering the limit is a soft-fork and doable, but if we have to lower because mining power got concentrated, good luck.
1738 2013-02-21 21:00:51 D34TH has joined
1739 2013-02-21 21:00:51 D34TH has quit (Changing host)
1740 2013-02-21 21:00:51 D34TH has joined
1741 2013-02-21 21:01:02 <petertodd> gavinandresen: Hey, I could say you're biased because you hang around business types who really don't want to have to change a lot of expensive infrastructure; which is a valid argument of course.
1742 2013-02-21 21:01:03 <gavinandresen> sigh.  Miners will very quickly change what they mine if the big merchants and exchanges reject their blocks.
1743 2013-02-21 21:01:30 b4tt3r135 has joined
1744 2013-02-21 21:01:55 <jurov> petertodd, i outlined awhile back possible incentive why mining power needs not necessarily to get concentrated, you did not respond to that
1745 2013-02-21 21:02:17 <petertodd> We're assuming that, we also may find it gives advantages to big merchants, who in turn take advantage of it at the expense of other bitcoin users, we don't know.
1746 2013-02-21 21:02:22 <gavinandresen> I've had absolutely zero input from "business types" on the blocksize issue, by the way.  They're oblivious.
1747 2013-02-21 21:02:36 <petertodd> jurov: was this in irc or on the forum? I probably missed it
1748 2013-02-21 21:02:43 <jurov> not even evoorhees?
1749 2013-02-21 21:03:00 dparrish has joined
1750 2013-02-21 21:03:01 <jurov> jurov	even if large miners connect themselves with phat pipes...there's still incentive for smaller miners to mine smaller blocks with cherry-picked best-value transactions
1751 2013-02-21 21:03:04 <petertodd> gavinandresen: Heh, well that in itself is worrying... evorhees responded on the forum, and there was one self-proclaimed business person, but they didn't identify who they were.
1752 2013-02-21 21:03:32 <gavinandresen> must have posted recently, I gave up on the forums this morning as "too much noise"
1753 2013-02-21 21:03:46 <petertodd> jurov: But smaller miners can't mine unless they have access to the previous blocks; you need to know what tx's were spent by them to mine.
1754 2013-02-21 21:04:07 Jackneill has quit (Ping timeout: 240 seconds)
1755 2013-02-21 21:04:14 <petertodd> jurov: UTXO trees will potentially help, but that feature is a long way off, as is inflation proofing.
1756 2013-02-21 21:04:33 <jurov> if miners cut the network from access to blocks, then they undermine themselves
1757 2013-02-21 21:04:49 <jurov> it's not in their interest
1758 2013-02-21 21:04:51 <petertodd> jurov: Only if they cut off more than 50%
1759 2013-02-21 21:04:55 <helo> a market to determine btc price works. i'm not sure if a market to determine block size is nearly as simple.
1760 2013-02-21 21:05:13 <helo> (or feasible)
1761 2013-02-21 21:05:16 <petertodd> jurov: If >50% of the hashing power is working to extend your block, you come out ahead at the expense of the remainder.
1762 2013-02-21 21:05:53 <petertodd> gavinandresen: yes, the 10-odd threads on the subject is rediculous
1763 2013-02-21 21:06:14 <helo> the hard block limit creates a stable market for block space, so that i get
1764 2013-02-21 21:06:43 <gavinandresen> petertodd: next time, it might be more productive to write a whitepaper and then post a pointer on the bitcoin-development list, or discuss here.
1765 2013-02-21 21:06:49 <jurov> in >50% they will leave rest of the network more and more behind, rendering bitcoins useless
1766 2013-02-21 21:07:14 <petertodd> gavinandresen: Well, that's what I did; my post was a re-post of what I posted to bitcoin-dev
1767 2013-02-21 21:07:28 <jurov> you would want it, were you miner yourself?
1768 2013-02-21 21:07:39 <petertodd> gavinandresen: I really didn't think it'd blow up like it did; I should have known better how political the issue can be taken as.
1769 2013-02-21 21:08:23 <joshft> i think the mention of a possible hard fork intimidates people
1770 2013-02-21 21:09:04 <petertodd> jurov: If you're in the >50%, you *are* the bitcoin network, yet you didn't have to posesse as much hashing power to be there as you should have.
1771 2013-02-21 21:09:08 <gavinandresen> … somebody should post block.version==2 statistics and see how long it takes THAT to blow up into a big controversy….
1772 2013-02-21 21:09:22 rdponticelli has quit (Ping timeout: 276 seconds)
1773 2013-02-21 21:09:31 <petertodd> jurov: Remember that a 51% attacker doesn't need to validate transactions at all.
1774 2013-02-21 21:09:32 <jurov> following the train of thought... miner himself wouldn't be able to transact bitcoins mined in such a way.. you need the merchant to have the block validated too
1775 2013-02-21 21:10:10 <petertodd> gavinandresen: I'll do my best; maybe hire some film-makers to make a propaganda video about it?
1776 2013-02-21 21:10:32 <gavinandresen> petertodd: good idea.  With scary music and a deep-voiced announcer
1777 2013-02-21 21:10:34 <jurov> what would you do? show them your website and convince people you do have the coins?
1778 2013-02-21 21:10:41 <gavinandresen> .. and lots of pictures of cliffs and explosions
1779 2013-02-21 21:11:14 <petertodd> jurov: You do, but there's a good chance if you just wait merchants will either beef up their nodes, or switch to SPV. After all, you're chain is the legit chain.
1780 2013-02-21 21:11:19 andytoshi has quit (Ping timeout: 276 seconds)
1781 2013-02-21 21:11:30 <petertodd> jurov: ...and by definition, you can spend your coins with at least half of the network in that attack.
1782 2013-02-21 21:11:39 <petertodd> gavinandresen: We can take turns being the villian.
1783 2013-02-21 21:11:54 <gavinandresen> I'll work on my evil laugh
1784 2013-02-21 21:11:57 <jurov> but the half of the network is just your haunted server closet in this case!
1785 2013-02-21 21:12:08 agricocb has quit (Remote host closed the connection)
1786 2013-02-21 21:12:25 <jurov> you'll have to wait till your gigabyte blocks propagate from that closet
1787 2013-02-21 21:12:36 <petertodd> jurov: No it's not. It's the part of the network that can validate blocks faster than the other part, for whatever reason. That's lots of people.
1788 2013-02-21 21:12:59 <petertodd> jurov: Read my post again, it's a gradual process in practice.
1789 2013-02-21 21:13:27 <jurov> it will be gradual process if the limit stays anyway
1790 2013-02-21 21:14:01 <jurov> if minimal practical tx will be $50 or so, number of nodes will drop too
1791 2013-02-21 21:14:03 <petertodd> jurov: Not at all, with the limit the time to validate a new block is bounded by the fact that blocks can't be bigger than 1MiB
1792 2013-02-21 21:14:25 <petertodd> jurov: Not if off-chain transactions are developed.
1793 2013-02-21 21:14:32 <jurov> If.
1794 2013-02-21 21:14:34 <petertodd> jurov: Or if people just use Bitcoin as a store of value.
1795 2013-02-21 21:14:56 <jurov> If, again.
1796 2013-02-21 21:15:09 <petertodd> Yes, it's an if, but it's an if we should. I'm not saying I'm guaranteed to be right, and Gavin wrong, I'm saying I might be right, and we have to prepare for that.
1797 2013-02-21 21:15:28 <petertodd> Anyway, off-chain transaction systems can offer a lot of other useful things, like instant confirmations and privacy trough chaum tokens.
1798 2013-02-21 21:15:31 <jurov> prepare how?
1799 2013-02-21 21:16:13 <gavinandresen> We could prepare by telling people that Bitcoin is an experiment that we're still in the middle of….. oh, wait....
1800 2013-02-21 21:16:17 <petertodd> Make it clear that people should work on the technology. Right now we have defacto systems, Mt. Gox withdrawl codes, but as far as I know I'm one of the few people working on alternatives to that.
1801 2013-02-21 21:16:36 <jurov> nobody's got an incentive to off-chain tx system at the moment... not even evoorhees :)
1802 2013-02-21 21:16:44 <petertodd> gavinandresen: I seriously respect you a lot for making that clear. Bitcoin really needs that kind of level-headed, *realistic*, leadership.
1803 2013-02-21 21:17:21 <jurov> and giving mtgox codes as an example, srsly?
1804 2013-02-21 21:17:22 <petertodd> jurov: Yup. The biggest incentive is privacy, so what I'm proposing will get used for that first probably.
1805 2013-02-21 21:17:37 <petertodd> jurov: Yes! They suck, but they are an off-chain value transfer system.
1806 2013-02-21 21:18:10 <jurov> we'll end up with expensive core and broken off-blockchain transfer systems
1807 2013-02-21 21:18:24 <jurov> inevitably
1808 2013-02-21 21:18:24 <petertodd> gavinandresen: The worst thing you could do is give interviews about how bitcoin will change the world, buy coins NOW!
1809 2013-02-21 21:18:27 <gavinandresen> there seems to be a HUGE market demand for a trustless stock exchange system, that seems like an obvious early-adopers use
1810 2013-02-21 21:18:37 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
1811 2013-02-21 21:18:46 <gavinandresen> (scares the pants off me, though....)
1812 2013-02-21 21:19:03 <petertodd> jurov: they'll only be broken if we make crappy ones, and that's most likely to happen if people think they'll never be used
1813 2013-02-21 21:19:24 <jurov> worse is better, you know
1814 2013-02-21 21:19:41 <petertodd> gavinandresen: Yeah, fidelity bonds is really jgarzik's pybonds + throwing cash away.
1815 2013-02-21 21:19:49 <petertodd> jurov: I know, that's what worries me...
1816 2013-02-21 21:20:28 <petertodd> jurov: Believe me, I know damn well off-chain tx's will have to be really good to have any hope of the idea catching on. Look at IPv6...
1817 2013-02-21 21:20:34 <jurov> so i'm just on side of risking to allow bigger block size cause the system is more stable and reliable
1818 2013-02-21 21:20:52 <jurov> instead of relying on "off-blockchain something will happen"
1819 2013-02-21 21:21:20 <jurov> i think that's whole argument
1820 2013-02-21 21:21:29 <petertodd> Hey, it *is* an option, but we also need to recognize that it's an option with a serious risk of centralization, and the risk might not be something we can mitigate.
1821 2013-02-21 21:22:02 <jurov> as opposed to off-blockchain things that are centralized already
1822 2013-02-21 21:22:31 <petertodd> jurov: That's the thing, off-chain tx's are not nescessarily centralized, there are ways to build them without centralization.
1823 2013-02-21 21:22:47 * gavinandresen goes back to wrestling with OpenSSL
1824 2013-02-21 21:23:06 <petertodd> jurov: If I had realized this issue would become huge from one forum post, I would have written up a description of my idea for such a system first, but alas, I had no idea...
1825 2013-02-21 21:24:19 <jurov> people can exchange pgp-encrypted private keys, there is plenty of options already... but they don't do that for some reason
1826 2013-02-21 21:24:22 <helo> ideally users of an off-chain system would be able to verify that the funds are backed with real bitcoin
1827 2013-02-21 21:24:29 <jurov> if your idea is better, go ahead
1828 2013-02-21 21:25:48 <joshft> wouldn't a worst case scenario end up with a fork. possibly two bitcoins that coexist with one focusing on decentralized storage and the other on decentralized tx? that doesn't sound like a bad idea in the long term
1829 2013-02-21 21:26:27 <petertodd> jurov: Yes, because that method sucks.
1830 2013-02-21 21:27:06 <petertodd> helo: Exactly. Verifying that is also much easier with 1MiB blocks because you're sure the chain is valid.
1831 2013-02-21 21:27:14 clr_ has joined
1832 2013-02-21 21:28:27 runeks has quit (Quit: Leaving)
1833 2013-02-21 21:29:03 <helo> so for off-chain to be viable, running a full node to verify backing funds should be as painless as possible
1834 2013-02-21 21:29:24 <helo> i.e. loww block size
1835 2013-02-21 21:29:25 <petertodd> So, specifically, my idea is that you have these banks. You communicate with your bank using a protocol, where every step of the way if the bank defrauds you, you can prove it to the world. Information is easy to spread and hard to censor, so that proof will get out there and the banks customers will vanish. Now you also require the bank to purchase what I call a fidelity bond to operate, which is expensive, so even if the bank is anony
1836 2013-02-21 21:29:40 <petertodd> helo: Exactly.
1837 2013-02-21 21:30:08 <phantomcircuit> gavinandresen, trustless stock exchange is inherently not viable
1838 2013-02-21 21:30:16 <petertodd> Basically, it'd be like if Fort Knox was made of bullet proof glass, and everyone could wanter around counting the gold bars.
1839 2013-02-21 21:30:18 <phantomcircuit> i still dont understand why people think it's even possible
1840 2013-02-21 21:30:19 <jurov> banks *do* get bankrupt. quite often.
1841 2013-02-21 21:30:39 <jurov> and there are wolfram bars, too
1842 2013-02-21 21:31:11 <petertodd> jurov: Absolutely, but if you don't want your bank to go bankrupt, well, don't transact with banks that loan money! The protocols will let you know for sure that the bank isn't loaning out funds by inspecting the blockchain and audit logs.
1843 2013-02-21 21:32:00 <jurov> yes, if someone comes with bulletproof system how to assign one bitcoin output to thousands end users... i'm all for it
1844 2013-02-21 21:32:51 <helo> those thousands of end users would track where the funds from that one output go. at any point, they could challenge the bank via signmessage to prove it owns all subsequent outputs
1845 2013-02-21 21:33:05 <petertodd> Well, that's what I'm working on, but it's really early. I thought of the idea about a year ago, but only just after new years did I realize how important it would be given the blocksize limits; I used to just assume they would be lifted too.
1846 2013-02-21 21:33:46 <petertodd> helo: Exactly! Or more likely, the contract the bank offers is that all funds will be held at a given address, and any movement in or out of that address has to be recorded in the audit log for all to see.
1847 2013-02-21 21:33:55 joshft has quit (Quit: Page closed)
1848 2013-02-21 21:34:06 <petertodd> The bank would then give out chaum tokens, and clients would trade the tokens.
1849 2013-02-21 21:34:23 <jurov> in any case, 1MB is still low. we can then end up in place that many of the 7 billion people won't ever touch original bitcoin transaction in lifetime
1850 2013-02-21 21:34:49 <jurov> it would be best if you can still transact btc when buying house or car
1851 2013-02-21 21:35:10 <jurov> can we at least agree on that?
1852 2013-02-21 21:35:29 <petertodd> What's cool about chaum tokens, is they are anonymous. Basically it's like you write a number on a ticket, then put the ticket in an unmarked envelope with some carbon paper. The bank signs the envelope, transfering their signature to the ticket inside, but they don't actually know what ticket they signed. Later you give that ticket to someone else, and they present it to the bank, who either gives them another ticket in return, or the
1853 2013-02-21 21:35:44 <helo> when [some populus country] starts a bitcoin competitor, and its supporters start dossing bitcoin nodes, 1MB may be found to be too big :)
1854 2013-02-21 21:35:54 <petertodd> jurov: Bingo. I figure $20/transaction is a number that we're likely to see if the bitcoin market cap is in the trillions.
1855 2013-02-21 21:36:48 <petertodd> jurov: Not a big deal for big transactions.
1856 2013-02-21 21:37:17 <petertodd> jurov: And that $20 would give you access to the *same* fund transfer system used by big banks, yet, they couldn't stop you from using it.
1857 2013-02-21 21:38:53 <amiller> by the time bitcoin tx are $20 in fees, i think there's going to be really weird interactions between bitcoin and the other altcoins that will take up its place on the bottom
1858 2013-02-21 21:39:39 <helo> s/weird/violent/ ?
1859 2013-02-21 21:39:53 <petertodd> amiller: Quite possibly. Yet at the same time, with $20's in fees and 1MiB blocks a 51% attacker has to spend *billions* of dollars to have any chance; I think that's a really good thing.
1860 2013-02-21 21:40:48 <jurov> $20 fees/tx mean $12m daily
1861 2013-02-21 21:41:12 <jurov> the competition for mining power will be insane
1862 2013-02-21 21:41:32 <helo> it will be bizarre... a new altcoin would be lean and mean, which alone could give it enough support to start gaining in value vs bitcoin
1863 2013-02-21 21:41:40 <jurov> we will end up like hft did... everyone in one closet
1864 2013-02-21 21:42:04 <petertodd> For sure, yet, with 1MiB blocks anyone can trivially buy a small mining rig and get into the same, and I suspect the costs for small miners are actually less proportionally, because they can often get free power and don't need to worry about cooling.
1865 2013-02-21 21:42:14 <helo> "~Zero transaction fees! Has tripled value in the last 6 months!"
1866 2013-02-21 21:42:16 <petertodd> It's only the overhead of running a node that's the issue, and with 1MiB blocks that overhead is tiny.
1867 2013-02-21 21:42:38 <jurov> why would anyone run a node when he'll do 5 txs in lifetime?
1868 2013-02-21 21:42:58 <petertodd> jurov: So they can audit the people doing transactions on their behalf.
1869 2013-02-21 21:43:31 <petertodd> I've been thinking a lot about these banking protocols, and they really need full-chain access to be really trustworthy.
1870 2013-02-21 21:43:49 <petertodd> That also means the ability to keep up with the tx's coming in over the mempool too.
1871 2013-02-21 21:44:12 <jurov> assuming such auditing can be done without including verification of all these "on behalf" transactions
1872 2013-02-21 21:44:52 <jurov> i think you're building imaginary castles here. code or ...
1873 2013-02-21 21:45:05 <petertodd> Yeah, validating the non-chain-transactions is the hardest part of it actually. gmaxwell and I think we have solutions that work, but it may turn out that you need trusted hardware.
1874 2013-02-21 21:45:19 <petertodd> *scalable solutions that work
1875 2013-02-21 21:45:21 Motest003 has joined
1876 2013-02-21 21:45:28 Motest003 has quit (Client Quit)
1877 2013-02-21 21:46:27 <petertodd> Having said that, because all this stuff can be checked by machine, it'll be quite possible for a merchant to accept payment regardless of which of these banks/payment processors you happen to be using. They'll evaluate if the payment is coming from a trustworthy one automatically, no human intervention needed.
1878 2013-02-21 21:47:11 <jurov> this assumes web of trust or authority infrastructure
1879 2013-02-21 21:47:23 <helo> if i was a banking exec, i would be astroturfing the hell out of the idea that the blocksize should float
1880 2013-02-21 21:48:03 <petertodd> No actually. You evaluate that by determining if the fidelity bond the bank has to purchase to operate is worth more than the deposits they have access too, and possibly if the trusted hardware they're running their software on is secure.
1881 2013-02-21 21:48:05 <jurov> do i sound like a banker? i think i'm asking technical questions
1882 2013-02-21 21:48:41 <petertodd> jurov: and thank you, because I need more practice answering them.
1883 2013-02-21 21:49:21 <petertodd> BTW: I think I didn't mention it: a fidelity bond is basically where you provably sacrifice Bitcoins, to make the banks cryptographical identity expensive to aquire.
1884 2013-02-21 21:49:23 <jurov> only argument i heard is "we must avoid centralization" but this will end up in centralization nevertheless
1885 2013-02-21 21:49:41 <jurov> and one built on trust, moreover
1886 2013-02-21 21:49:55 <petertodd> Yes, but it's a decentralized centralization, and one built not on trust, but auditing.
1887 2013-02-21 21:50:28 <petertodd> After all, anyone can run one of these banks, and the protocols allow you to evaluate if the bank will defraud you automatically.
1888 2013-02-21 21:50:37 <jurov> then banks can issue zillions of fake transaction to make audtiing difficult
1889 2013-02-21 21:50:46 <jurov> you just move pthe problem to another level
1890 2013-02-21 21:51:06 <jurov> it will not be miners, but banks
1891 2013-02-21 21:51:38 <petertodd> Design your protocols right, and the transactions can't be fake. In fact, I think a really important mechanism will be forcing the banks to pay tx fees to *miners* for each transaction, very small fees sure, but ones high enough that bloating thei tx volume will be too expensive to fake.
1892 2013-02-21 21:52:14 <petertodd> (basically, the tx fees would be collected together, and provably given to miners in one transaction)
1893 2013-02-21 21:52:19 <jurov> if we had such protocol, it would already be part of bitcoin!
1894 2013-02-21 21:52:47 rdponticelli has joined
1895 2013-02-21 21:52:50 <petertodd> Why? It's a new idea, and making it happen takes time.
1896 2013-02-21 21:53:05 DamascusVG has joined
1897 2013-02-21 21:53:30 <jurov> if it is feasible, then it will happen anyway, let's not force it
1898 2013-02-21 21:53:32 <petertodd> Satoshi had the amazing insight that made the block chain, and based on his work, I've made the much more minor insight that this type of banking is possible. You can't come up with one without the other.
1899 2013-02-21 21:53:46 <petertodd> Stuff doesn't "just happen", people have to make it happen.
1900 2013-02-21 21:54:12 <petertodd> What worries me, is if people assume the block size limit will be lifted, no matter what, then these ideas aren't worth working on.
1901 2013-02-21 21:54:22 <petertodd> So they won't hapeen and we'll have no options.
1902 2013-02-21 21:55:03 <jurov> you see what happened already when btc was made "difficult" . "banks" without any verification/audit possibility sprouted
1903 2013-02-21 21:55:05 <petertodd> Also, I'm sure there are other ideas even better than mine out there, but again, people won't think of them unless they have a reason to be thinking of them.
1904 2013-02-21 21:55:39 <jurov> and it will get worse if putting tx to blockchain will be difficult
1905 2013-02-21 21:55:42 <petertodd> sure, but stuff like Mt. Gox codes are a really bad solution, we can do better
1906 2013-02-21 21:56:16 <petertodd> Again, stuff done late, out of absolute nesessity, tends to be worse than solutions where people have put a lot of thought to for a longer time.
1907 2013-02-21 21:56:48 <petertodd> Satoshi said the scripting system was adding as a last minute thing, and sure enough the only major problems Bitcoin has ever had have been scripting system bugs.
1908 2013-02-21 21:57:11 <jurov> well, lot of thought was put into IPv6. and yet whole world uses NAT
1909 2013-02-21 21:57:23 robocoin has quit (Quit: >'_')>~(\\\)
1910 2013-02-21 21:57:28 rdponticelli has quit (Ping timeout: 276 seconds)
1911 2013-02-21 21:57:36 <jurov> cause 4B addresses are enough
1912 2013-02-21 21:57:40 <petertodd> jurov: Actually, that's changing... which I'll admit I'm surprised by.
1913 2013-02-21 21:58:02 [ken] has quit (Quit: leaving)
1914 2013-02-21 21:58:05 <petertodd> jurov: IPv6 should be a cautionary tale though: this stuff has to happen early.
1915 2013-02-21 21:58:14 <midnightmagic> altcoins/merged-mining coins are not necessary for micro-btc txns.
1916 2013-02-21 21:58:17 <petertodd> At least we *have* IPv6 at all.
1917 2013-02-21 21:58:31 <midnightmagic> jurov: IPv6 has some significant problems which are going to causea lot of pain for a lot of people.
1918 2013-02-21 21:58:31 <jurov> it DID happen early
1919 2013-02-21 21:59:02 <petertodd> jurov: Exactly, and as early as it was, IPv6 has arrived just barely in time.
1920 2013-02-21 21:59:22 <jurov> if IPv4 had 64bits instead of 32, we'll be using it happily and whole problem wouldn't happen
1921 2013-02-21 21:59:24 <petertodd> You gotta realize, it's actually getting used for production stuff right now and has solved some really big problems.
1922 2013-02-21 21:59:46 <petertodd> No, 64bits had nothing to do with it. Being different than IPv4 was the problem.
1923 2013-02-21 22:00:05 <petertodd> 128bit addressing was frankly a brilliant move that showed a lot of foresight.
1924 2013-02-21 22:00:20 <jurov> so i think if btc allows enought txs now to keep /41 tx fees, we'll avoid NAT-like mess
1925 2013-02-21 22:00:35 <jurov> * $1 tx fees
1926 2013-02-21 22:01:02 <petertodd> With $1 tx fees, we're still going to need off-chain payments, so we might as well make them good.
1927 2013-02-21 22:01:38 <petertodd> Frankly I think it's $0.1 or $0.05 is where the "can get away with it" limit is, and that implies really, really big blocks if Bitcoin becomes popular.
1928 2013-02-21 22:01:43 <jurov> you won't need to have such elaborate infrastructure with banks, etc. in this case
1929 2013-02-21 22:01:55 <petertodd> Why not?
1930 2013-02-21 22:02:13 <petertodd> How are you going to do your $1 tx>
1931 2013-02-21 22:02:16 <petertodd> ?
1932 2013-02-21 22:02:25 <jurov> banknotes with pubkeys or so
1933 2013-02-21 22:03:03 <jurov> you'll have to trust their issuer only for $50 instead of $1000
1934 2013-02-21 22:03:47 <petertodd> So, basically you're proposing PayPal.
1935 2013-02-21 22:04:14 <petertodd> ...which means people will be using it for $100 tx's, and thus you'll wind up trusting the service with $1000's
1936 2013-02-21 22:04:41 <jurov> Of course. What I'm trying to tell you, if you force medium txs out, paypal will take $1000 transactions over.
1937 2013-02-21 22:05:16 <petertodd> Yes, but the point is, the difference between $20 and $1 isn't really all that big, it's $20 vs $0.05 tha's the real gamechanger.
1938 2013-02-21 22:05:21 <jurov> You seem to think some bulletproof infrastructue just arises cause it "has to"
1939 2013-02-21 22:05:39 <jurov> $ 0.05 is out already
1940 2013-02-21 22:05:52 <jurov> i'm speaking about $20 vs. $1000
1941 2013-02-21 22:06:02 <petertodd> You talking fees or tx value?
1942 2013-02-21 22:06:24 <jurov> tx value. i said, i can imagine txfees to be $1
1943 2013-02-21 22:06:44 <petertodd> and no, I think bulletproof infrastructure takes time, but as I keep on saying, it's more likely to happen if people start working on it earlier because they see a need
1944 2013-02-21 22:07:04 <petertodd> Right, so $20 is wasting you %5
1945 2013-02-21 22:07:10 <petertodd> (a $20 value tx)
1946 2013-02-21 22:07:25 <petertodd> Bitcoin already has enough friction due to fiat exchange.
1947 2013-02-21 22:07:37 <jurov> if you want to send it to the other end of the world quickly, it may be worthwhile
1948 2013-02-21 22:07:47 JZavala has joined
1949 2013-02-21 22:08:22 <petertodd> Well sure, but given that bulletproof infrastructure is possible, lets hope it gets worked on. I'm working on one method, and I hope others work on other methods.
1950 2013-02-21 22:09:09 <petertodd> FWIW I submitted a grant proposal to the bitcoin foundation asking them to set aside funds for *anyone* interested in working on stuff using trusted hardware; not just myself. It's a powerful technology and people should explore what it can do.
1951 2013-02-21 22:09:28 <petertodd> It's a good way to enable fairly bulletproof services that anyone can audit.
1952 2013-02-21 22:09:46 <petertodd> Not perfect of course, but it's stuff that should be explored.
1953 2013-02-21 22:11:05 <jurov> gotta go.. hope i helped anything
1954 2013-02-21 22:11:22 <petertodd> yes, you did
1955 2013-02-21 22:11:28 <petertodd> I should get some work done myself...
1956 2013-02-21 22:11:37 <petertodd> its' really helpful to explain this to other people for me
1957 2013-02-21 22:11:40 <petertodd> so thank you
1958 2013-02-21 22:15:34 whizter has quit ()
1959 2013-02-21 22:16:54 jurov has left ()
1960 2013-02-21 22:16:54 b4tt3r135 has quit (Read error: Connection reset by peer)
1961 2013-02-21 22:22:10 jouke has quit (Ping timeout: 276 seconds)
1962 2013-02-21 22:23:15 jouke has joined
1963 2013-02-21 22:25:55 grau has quit (Remote host closed the connection)
1964 2013-02-21 22:26:35 grau has joined
1965 2013-02-21 22:27:04 ralphtheninja has joined
1966 2013-02-21 22:29:07 freakazoid has joined
1967 2013-02-21 22:30:54 grau has quit (Ping timeout: 246 seconds)
1968 2013-02-21 22:43:15 ThomasV_ has joined
1969 2013-02-21 22:45:22 jurov has joined
1970 2013-02-21 22:45:28 reizuki__ has joined
1971 2013-02-21 22:45:32 reizuki__ has quit (Changing host)
1972 2013-02-21 22:45:32 reizuki__ has joined
1973 2013-02-21 22:46:13 word__ has joined
1974 2013-02-21 22:47:04 agricocb has joined
1975 2013-02-21 22:48:06 Insti has joined
1976 2013-02-21 22:49:22 word_ has quit (Ping timeout: 252 seconds)
1977 2013-02-21 22:49:59 word__ has quit (Client Quit)
1978 2013-02-21 22:51:48 Hashdog has quit (Remote host closed the connection)
1979 2013-02-21 22:56:27 ThomasV_ has quit (Ping timeout: 246 seconds)
1980 2013-02-21 22:58:01 nus- is now known as nus
1981 2013-02-21 23:04:10 one_zero has joined
1982 2013-02-21 23:04:47 ProfMac has joined
1983 2013-02-21 23:05:12 gavinandresen has left ()
1984 2013-02-21 23:07:21 <jgarzik> sheesh
1985 2013-02-21 23:07:28 <jgarzik> how many block size limit threads does one forum need?
1986 2013-02-21 23:07:35 <denisx> jgarzik: I think I found a small problem with pushpoold
1987 2013-02-21 23:08:56 <ProfMac> everybody loves the design, except for 1 small thing.  Too bad it is a different small thing for each person.
1988 2013-02-21 23:11:11 <ProfMac> I'm about brain dead on OpenWRT in a VirtualBox.  I have IPv4 connectivity great.  I have IPv6 connectivity from the console to both the LAN & the WAN (HE).  The LAN & WAN don't share IPv6.  Sounds like a route problem.  I'm gonna put it away for a while.
1989 2013-02-21 23:13:05 <gmaxwell> jgarzik: it wouldn't be a forrest fire if only one tree was burning.
1990 2013-02-21 23:13:21 <petertodd> jgarzik: obviously thread fees are too low
1991 2013-02-21 23:14:25 <Luke-Jr> denisx: lol, are you trying to use pushpoold?
1992 2013-02-21 23:14:26 <jgarzik> oh if only it cost BTC to post...  if only...
1993 2013-02-21 23:14:29 <gmaxwell> sipa: It occurs to me that if a maximum size upper bound were pegged to difficulty (after everthing is switched to asic and things are stablized), that doing so kills my security race to the bottom concern.
1994 2013-02-21 23:14:34 <jgarzik> denisx: ok?
1995 2013-02-21 23:15:00 <denisx> jgarzik: the history only holds 10000 in default
1996 2013-02-21 23:15:12 <gmaxwell> Though it doesn't address the centerailzation concerns (like petertodd's argument). :(
1997 2013-02-21 23:15:24 <HM> what centralisation concern is this?
1998 2013-02-21 23:15:26 <denisx> I think some smart guys try to exploit that, because it should overflow with more than 333GH/sec in two minutes
1999 2013-02-21 23:15:42 <jgarzik> denisx: easy enough to recompile and change
2000 2013-02-21 23:15:52 <denisx> jgarzik: yeah, I know
2001 2013-02-21 23:15:59 <petertodd> I wouldn't trust difficulty to actually stay stable... Bitcoin has the problem that if a sha256 break happens that makes pow easier, difficulty could go whacky
2002 2013-02-21 23:16:06 <jgarzik> denisx: people are moving away from pushpool, though, because it's getwork rather than GBT, and doesn't support stratum
2003 2013-02-21 23:16:15 <petertodd> (though I dunno, can the crypto break that way?)
2004 2013-02-21 23:16:23 <denisx> jgarzik: yes, I know, but I like it
2005 2013-02-21 23:16:28 <jgarzik> :)
2006 2013-02-21 23:16:35 <phantomcircuit> <petertodd> jgarzik: obviously thread fees are too low
2007 2013-02-21 23:16:39 <jgarzik> denisx: I have given some thought to pushpool 2.0 with those improvements :)
2008 2013-02-21 23:16:42 <phantomcircuit> that is 1000x more inciteful than you will ever know
2009 2013-02-21 23:16:47 <phantomcircuit> insightful
2010 2013-02-21 23:16:54 <jgarzik> phantomcircuit: either or ;p
2011 2013-02-21 23:16:55 <gmaxwell> HM: for example, petertodd's argument... or more generally, security doesn't really make a market.  It's in everyone's economic interest to freeload and let someone else validate.  If validation is cheap indifference, altruism, paranoia are enough.. if validation is expensive not so much.
2012 2013-02-21 23:17:00 <phantomcircuit> jgarzik, lol
2013 2013-02-21 23:17:04 QuantumQrack has quit (Quit: Leaving)
2014 2013-02-21 23:17:05 <denisx> jgarzik: if you ever start it let me know
2015 2013-02-21 23:17:09 <Luke-Jr> jgarzik: problem with Eloipool?
2016 2013-02-21 23:17:16 clr_ has quit (Ping timeout: 245 seconds)
2017 2013-02-21 23:17:55 Zarutian has joined
2018 2013-02-21 23:18:08 <gmaxwell> petertodd: It can break that way but its very unlikely. Also, pratical large QC would vastly speed up the pow.
2019 2013-02-21 23:18:33 <HM> meh
2020 2013-02-21 23:18:37 <gmaxwell> petertodd: but if we really could reduce the issue to a cryptobreak ... thats not bad. We'll have to hardfork fix a crypto break in any case.
2021 2013-02-21 23:18:49 <gmaxwell> But sadly, it doesn't do that.
2022 2013-02-21 23:19:50 <petertodd> gmaxwell: Yeah, PoW break would be horrible given the ASIC investment
2023 2013-02-21 23:19:58 <HM> how does this relate to max block size? transaction rate?
2024 2013-02-21 23:20:51 runeksvendsen has joined
2025 2013-02-21 23:20:58 <petertodd> HM: Basically linking block size to difficulty is a potentially bad idea.
2026 2013-02-21 23:21:05 <gmaxwell> HM: there are three main classes of concern with block size changes: User sovereignty— who has the right to change the involitile rules of the system against the consent of some (I'll ignore this one now). The next is the assumption that fees will be what pay to keep bitcoin secure once the subsidy is gone— if you simply remove the blocksize cap then it it is _far_ from obvious that the economic equlibrium is secure.
2027 2013-02-21 23:21:56 runeksvendsen has quit (Remote host closed the connection)
2028 2013-02-21 23:22:04 <gmaxwell> The third issue is that if the size is not limited that will foster centeralization because it will be costly to validate and so people won't, allowing the few that do to inflate the currency and other crap.  Peter Todd pointed out that miners could intentionally mine larger blocks to push out compeition, boiling the frog slowly.
2029 2013-02-21 23:22:31 <gmaxwell> The first can be solved by doing something only when ~everyone agrees with it... ugh. Well. Topic for another day.
2030 2013-02-21 23:23:03 <gmaxwell> The second may be solvable by fixing the third against difficulty, though I agree that its ... a little unsound sounding. It is certantly not as bad as _not_ fixing it against difficulty.
2031 2013-02-21 23:23:25 runeksvendsen has joined
2032 2013-02-21 23:23:30 <gmaxwell> The third I still have no real suggestions for except to say that people should oppose any change they feel endagers it.
2033 2013-02-21 23:23:44 runeksvendsen has quit (Remote host closed the connection)
2034 2013-02-21 23:23:51 <gmaxwell> (but if it's 'opposition' based then it can't be automatic, and gavin wants an automatic process)
2035 2013-02-21 23:24:19 <HM> difficulty, block rate and block size are already linked
2036 2013-02-21 23:24:35 <HM> higher block sizes means a lower block rate is required to maintain some transaction rate, right?
2037 2013-02-21 23:24:46 <HM> and block rate determines difficulty
2038 2013-02-21 23:25:03 <petertodd> HM: not really, difficulty is artifical
2039 2013-02-21 23:25:11 runeksvendsen has joined
2040 2013-02-21 23:25:19 <petertodd> HM: it's just a knob we tweak to converge on 10min block averages
2041 2013-02-21 23:25:21 <gmaxwell> Difficulty is a measure of computation. The blockrate is 'constant'.
2042 2013-02-21 23:25:36 <HM> yes i know it's constant
2043 2013-02-21 23:25:51 <gmaxwell> Basically difficulty tells you the relationship between computing-electricty-costs and (speculative) income from mining.
2044 2013-02-21 23:26:21 <HM> i see difficulty as more of a buffer
2045 2013-02-21 23:26:48 <gmaxwell> The (2) concern there is that it you uncap the size then it is rational to include very low fee transactions, getting paid something is better than nothing. ... and the operating cost slack would come out of difficulty, because difficulty is artificial.
2046 2013-02-21 23:27:27 <GMP> there was an interesting idea to link blocksize with amount of fees (reward) from block . miners who 'cheat' will risk that artificial fees will be stolen
2047 2013-02-21 23:27:47 <gmaxwell> so we should expect difficulty to fall when subsidy is gone unless there is vigorous competition from scarace block space. Something has to produce the scarcity. MAYBE some cartel beyhavior by a majority of miners could produce it, but I think thats ugly as heck. ..
2048 2013-02-21 23:27:54 <gmaxwell> GMP: no can do.
2049 2013-02-21 23:28:04 <gmaxwell> GMP: you can't tell if a txn was ever announced or not.
2050 2013-02-21 23:28:06 <HM> i mean CPU consumption is a function of tx volume. it doesn't matter whether you have 10 tx in a block or 20, if you have 20 you need half as many blocks.  but the difficulty will double to maintain 1/10mins. so number crunching remains the same, right?
2051 2013-02-21 23:28:21 <gmaxwell> GMP: unless you propose another blockchain to decide if transactions were actually announced. :P
2052 2013-02-21 23:28:21 <HM> will half*
2053 2013-02-21 23:28:23 <HM> double
2054 2013-02-21 23:28:25 <HM> something
2055 2013-02-21 23:28:44 <HM> yes double :P
2056 2013-02-21 23:28:44 <gmaxwell> HM: oh difficulty does not and cannot have anything to do with transaction validation cpu consumption.
2057 2013-02-21 23:29:01 <HM> Yes, but i'm making the case that block size doesn't either
2058 2013-02-21 23:29:18 <gmaxwell> HM: It _must_ be artifical. If the cost of mining comes from validation instead of POW, miners who don't validate will have an enormous competitive advantage.
2059 2013-02-21 23:29:35 <gmaxwell> so cpu consumption for miners is not a function of tx volume.
2060 2013-02-21 23:29:39 Dyaheon has quit ()
2061 2013-02-21 23:29:55 <GMP> gmaxwell: it doesnt matter if it was announced, other miners will follow the same incentive to re-mine 'suspicious' transactions
2062 2013-02-21 23:30:01 <HM> ah i see
2063 2013-02-21 23:30:19 toffoo has joined
2064 2013-02-21 23:30:21 <GMP> gmaxwell: if fee is large enough
2065 2013-02-21 23:30:29 <HM> gmaxwell: well why can't you force miners to validate all transactions in a block?
2066 2013-02-21 23:30:34 <gmaxwell> GMP: then you break convergence.
2067 2013-02-21 23:30:40 <gmaxwell> HM: because validation is invisible.
2068 2013-02-21 23:30:47 <HM> invisible?
2069 2013-02-21 23:31:01 <petertodd> HM: the pow doesn't tell you validation has been done
2070 2013-02-21 23:31:08 <petertodd> (by itself)
2071 2013-02-21 23:31:14 <HM> pow?
2072 2013-02-21 23:31:22 <petertodd> pow = proof of work
2073 2013-02-21 23:31:26 <HM> of course
2074 2013-02-21 23:32:28 <petertodd> only further pow's do that, and only by making assumptions about miner behavior (fortunately assumptions backed up by incentives)
2075 2013-02-21 23:32:38 <HM> but why not? why should miners be able to claim fees on tx's that aren't economically feasible?
2076 2013-02-21 23:33:08 <petertodd> HM: huh?
2077 2013-02-21 23:33:29 <gmaxwell> HM: assuming I understand what you're saying, Because you can't prevent them without being able to algorithimically define economically fesable
2078 2013-02-21 23:33:45 <HM> hmm
2079 2013-02-21 23:34:01 <petertodd> yeah, economically feasible is not something you can determine by an algorithm
2080 2013-02-21 23:34:15 <HM> well if you have a more simplistic tx specification you can
2081 2013-02-21 23:34:27 <gmaxwell> That isn't obvious to me.
2082 2013-02-21 23:34:51 cheako has joined
2083 2013-02-21 23:35:19 <HM> I guess I'm confused as to how miners collect fees
2084 2013-02-21 23:35:30 Dyaheon has joined
2085 2013-02-21 23:36:23 <gmaxwell> When someone makes a transaction and the sum of outputs is less then the sum of inputs, the rest is fee that the miner that mines that txn will recieve.  Miners can opt to not accept transactions they don't like, nothing can force a miner to include a transaction.
2086 2013-02-21 23:36:31 Muis_ has quit (Read error: Connection reset by peer)
2087 2013-02-21 23:36:53 <HM> it doesn't make sense to me that if block rewards go away that miners wouldn't validate transactions. the fees aren't valid if the transactions aren't valid, right?
2088 2013-02-21 23:36:59 Muis_ has joined
2089 2013-02-21 23:37:40 <GMP> HM: its easier, the block isnt valid if it contains invalid tx
2090 2013-02-21 23:38:03 <HM> right, and the miner has then wasted time and money mining that block
2091 2013-02-21 23:38:09 <HM> because they won't get any reward or fees
2092 2013-02-21 23:38:12 <HM> correct?
2093 2013-02-21 23:38:12 <gmaxwell> HM: as the block rewards go away it will only be fees that pay miners to apply lots of computing power to keep bitcoin secure.
2094 2013-02-21 23:38:14 <ne0futur> HM: miners will mine for transaction fees
2095 2013-02-21 23:38:34 <fiesh_> is there any specific design decision as to why the geometric series for reducing the block-reward was chosen in such a crude way, and not, say "continuous" along the blocks, with each block having slightly less value than its predecessor?
2096 2013-02-21 23:39:01 <HM> if i create a tx that promises a 100 BTC fee, miners should jump on it
2097 2013-02-21 23:39:04 <fiesh_> or is it just an early design decision that could not be improved any more later on?
2098 2013-02-21 23:39:19 <HM> are you saying they should blindly shove that tx in a block and try pow'ing away without checking to see if my promise is good?
2099 2013-02-21 23:39:20 <gmaxwell> fiesh_: it was intentional. You can back justify it if you like.
2100 2013-02-21 23:39:41 <gmaxwell> HM: sure, if the pow costs are nearly zero, why not?
2101 2013-02-21 23:39:46 agricocb has quit (Quit: Leaving.)
2102 2013-02-21 23:39:52 <HM> but the pow isn't near zero is it.
2103 2013-02-21 23:39:55 <fiesh_> gmaxwell: what's the rationale behind it?  to me it seems like a quite bad choice, having these jumps
2104 2013-02-21 23:40:07 <HM> people are blowing $1000s on ASICs that prove that it isn't near zero
2105 2013-02-21 23:40:13 runeksvendsen has quit (Remote host closed the connection)
2106 2013-02-21 23:40:39 <gmaxwell> fiesh_: It makes it easier for people to invest in persistant resources for mining because it makes the income from doing so more clear and predictable.
2107 2013-02-21 23:40:53 <gmaxwell> fiesh_: objectively— it caused no problem for the first halving.
2108 2013-02-21 23:41:04 <HM> couldn't i ddos the network right now by sending miners bogus tx's promising huge fees?
2109 2013-02-21 23:41:20 <HM> seems weird to me
2110 2013-02-21 23:41:27 <petertodd> fiesh_: a continuous algorithm is more complex than the dead simple 'shift one bit right every n blocks' algorithm we have now
2111 2013-02-21 23:41:37 <petertodd> fiesh_: + gmaxwells more eloquent arguments :P
2112 2013-02-21 23:41:37 <gmaxwell> HM: No.  Unfortunately this whole discussion has wooshed you entirely, because I assumed you understood things you didn't.
2113 2013-02-21 23:42:00 <fiesh_> well a geometric series that changes with each block wouldn't be complex or unpredictable at all -- but gmaxwell's argument that the first halving went fine is valid I guess
2114 2013-02-21 23:42:12 <HM> gmaxwell: well i'd appreciate some enlightenment
2115 2013-02-21 23:42:18 <gmaxwell> fiesh_: there is other fun stuff like a falling difficulty creates an incentive to instead remine the last block... though if it's slow enough its probably fine.
2116 2013-02-21 23:42:26 <fiesh_> in fact it would be more predictable since your estimated income doesn't vary so much when the halving approaches
2117 2013-02-21 23:42:55 <gmaxwell> HM: the POW is whatever it takes to achieve 10 minutes. It may be effectively free, or quite costly. It's a free parameter.
2118 2013-02-21 23:42:57 <fiesh_> gmaxwell: well that's a bigger issue with a sudden halving, isn't it?
2119 2013-02-21 23:43:08 <petertodd> fiesh_: in general, keep in mind that we've had four years to think all this stuff over very carefully, with many, many people thinking about it. Satoshi was apparently just one guy working by himself.
2120 2013-02-21 23:43:10 <gmaxwell> fiesh_: yes but thats a one time event.
2121 2013-02-21 23:43:51 <fiesh_> petertodd: yeah but that's not a sufficient answer ;)  I do think a less crude geometric series is more natural and more predictable
2122 2013-02-21 23:43:53 <HM> gmaxwell: yes, and a block has limited space. let's say it's 100 tx can fit in a block. Now what happens if i send a miner 100 tx promising large fees. if they don't validate my tx's and prioritise high fee txs, then all the other users get bumped
2123 2013-02-21 23:44:08 <gmaxwell> HM: this whole discussion is about blocks _not_ having limited space.
2124 2013-02-21 23:44:16 <fiesh_> gmaxwell: yeah but for a smooth geometric series, there's hardly any incentive, one could just compute the incentive, it's definitely negative
2125 2013-02-21 23:44:19 <gmaxwell> I agree, it all holds up and works perfectly with blocks having limited space.
2126 2013-02-21 23:44:57 <gmaxwell> fiesh_: well, it's not instantly negative.
2127 2013-02-21 23:45:15 <gmaxwell> But thats here nor there, — it doesn't really matter.
2128 2013-02-21 23:45:50 <fiesh_> true
2129 2013-02-21 23:46:06 <HM> blocks have to have a reasonable size limit. if a user can't download a single block in 10 minutes they'll never sync the whole chain. :P
2130 2013-02-21 23:46:23 <gmaxwell> HM: Go tell all the people arguing otherwise! :)
2131 2013-02-21 23:47:04 <HM> miners have to decide on a size anyway to begin pow
2132 2013-02-21 23:47:09 <gmaxwell> HM: some would argue that even if the size is enormous some big banks can download the whole thing still, and that is enough.
2133 2013-02-21 23:47:12 <HM> you may as well make it explicit
2134 2013-02-21 23:47:37 <petertodd> fiesh_: Sure, I mean, just remember that Bitcoin itself might not have a good reason to do whatever it did. IE, you're quite possibly right.
2135 2013-02-21 23:47:44 <gmaxwell> HM: miners incrementally add txn to a block as they come in, the POW is memorless... you don't really 'begin'.
2136 2013-02-21 23:48:23 <GMP> gmaxwell: so, whats the best ideas so far? i reckon 1) discard block too slow to validate 2) link blocksize cap to last blocks "history" somehow 3) allow to exceed 'limit' if reward is high
2137 2013-02-21 23:48:42 <fiesh_> petertodd: one might equally ask if any decline is wanted at all, doesn't seem obvious to me either
2138 2013-02-21 23:48:47 <gmaxwell> fiesh_: basically satoshi seemed to follow a principle where he did not introduce complexity without a benefit. So there are a number of arbritary things, but they tend to be ones that make it simpler.  The only counterexample I'm aware of is the use of SHA256^2 over SHA256.
2139 2013-02-21 23:49:10 <HM> true yes, but SHA-256 operates in blocks doesn't it. hashing a 2MB block is slower than hashing a 1 MB block. + memory constraints, you're going to pick a reasonable size as a miner to get blocks out as quickly as possible
2140 2013-02-21 23:49:12 <fiesh_> gmaxwell: heh yes, I have been wondering over SHA256^2 like this too
2141 2013-02-21 23:49:27 <gmaxwell> GMP: (1) ruins convergence, (2) is equal to miners just being able to control it directly, as does (3).. Because miners can just mine their own txn.
2142 2013-02-21 23:49:58 <petertodd> fiesh_: Personally I think security should have been paid through inflation. Although with lost coins it's tricky to figure out a way that gets the rate correct.
2143 2013-02-21 23:50:00 <gmaxwell> fiesh_: well I know why he did that— it's an intended security hedge aganst attachs on SHA256 that don't work with twice the number of rounds.
2144 2013-02-21 23:50:15 <gmaxwell> Though it's unlikely to be actually helpful.
2145 2013-02-21 23:50:17 <GMP> gmaxwell: so, what other ideas are there?
2146 2013-02-21 23:50:30 <HM> gmaxwell: is that length extension attack?
2147 2013-02-21 23:50:42 <fiesh_> gmaxwell: plus there might be attacks against SHA256^2 that are not feasible against SHA256, I'm not fully convinced by that argument
2148 2013-02-21 23:50:49 <gmaxwell> HM: our usage isn't vulnerable to length extension attacks.
2149 2013-02-21 23:51:14 <HM> so what was double sha about?
2150 2013-02-21 23:51:21 <fiesh_> petertodd: it's not clear how coins are lost, linearly or exponentially, hmm
2151 2013-02-21 23:51:33 <petertodd> fiesh_: In general hashing algorithms only get better as you add more rounds. Their designed pretty much by "well, this this and this prevent these attacks, and we added n more rounds to be sure."
2152 2013-02-21 23:51:38 <gmaxwell> fiesh_: sure, though I think it's reasonably obvious that that is less likely.  Satoshi felt least comfortable with the cryptography in the system and was trying to be conservative.
2153 2013-02-21 23:51:47 CodeShark has joined
2154 2013-02-21 23:52:01 <fiesh_> petertodd: I'm not sure about that
2155 2013-02-21 23:52:02 <HM> ah i see
2156 2013-02-21 23:52:12 sacredchao has joined
2157 2013-02-21 23:52:19 <fiesh_> gmaxwell: is it?  Can't tell, do not know enough about hashing I guess
2158 2013-02-21 23:52:19 <petertodd> fiesh_: Exactly. Yet if you're funding security through inflation, you want the fees taken to match the economic market cap, not the numerical one.
2159 2013-02-21 23:52:21 <gmaxwell> petertodd: we do lose some security against preimage attacks to computation unbounded attackers for inputs smaller than the hash output size.
2160 2013-02-21 23:53:08 <petertodd> gmaxwell: explain?
2161 2013-02-21 23:53:19 <fiesh_> the anti-inflation decision was most likely a practical one: bitcoin wasn't clear to be successful at all, and a fixed inflation might have seemed scary to people initially
2162 2013-02-21 23:53:47 <petertodd> fiesh_: absolutely, social factors are huge in technological adoption.
2163 2013-02-21 23:54:10 <petertodd> "gotta know your audience"
2164 2013-02-21 23:54:13 <HM> So maybe inflation would start at huge block rewards and converge to 3% annually or some arbitrary small amount
2165 2013-02-21 23:54:22 <petertodd> 3% of what?
2166 2013-02-21 23:54:25 <gmaxwell> petertodd: the hashing algorithim is destructive. So if you send [0,2^256) in you get less than 2^256 outputs. SHA256^2 is moreso (by another bit or so).  So say you had a 256 bit input and needed another 256 bit input with the same hash. For some inputs this might be impossible for sha256 and possible for sha256^2.
2167 2013-02-21 23:54:27 <HM> total coins
2168 2013-02-21 23:54:41 <HM> but then lost coins are problematic
2169 2013-02-21 23:54:43 <gmaxwell> petertodd: but once the input gets much larger than 256 bits, that argument goes away and both are possible.
2170 2013-02-21 23:55:30 <gmaxwell> fiesh_: it's still fixed inflation regardless of the pace that it happens with. You're seriously underestimating how hard it already is for miners to reason about income and decide to but expensive hardware or not.
2171 2013-02-21 23:55:37 <petertodd> gmaxwell: Ah I see. The smallest input in Bitcoin would be exactly 256 bits though, from the merkle tree.
2172 2013-02-21 23:56:13 <gmaxwell> fiesh_: having to insert a geometric series in their calculations would absolutely scare off more miners— I don't know how much real effect it would have, but I'm confident that there is some benefit— and though I was concerned before, it doesn't appear to have had a cost.
2173 2013-02-21 23:56:41 <gmaxwell> petertodd: the tree is actually taking 2x that, binary tree and all.
2174 2013-02-21 23:57:07 <petertodd> gmaxwell: I'm thinking of the edge case with an odd-sized input
2175 2013-02-21 23:57:09 <fiesh_> gmaxwell: you think?  I think it's trivial to set up a small javascript applet that even the most math-unsavvy could use to compute the income over the next so-and-so many blocks ;)
2176 2013-02-21 23:57:10 <HM> incidentally, what's the current block size?
2177 2013-02-21 23:57:16 <CodeShark> sha256 processes 512 bits at a time, no?
2178 2013-02-21 23:57:24 <CodeShark> so 256 bits would still need to be padded
2179 2013-02-21 23:57:40 <gmaxwell> CodeShark: yes, but thats irrelevant, the question is how many bits you control.
2180 2013-02-21 23:57:45 <midnightmagic> fiesh_: It would seem trivial, and yet nobody does it except with constant difficulty.
2181 2013-02-21 23:58:43 <fiesh_> yes but also as a miner, you don't want to advertise mining I guess...
2182 2013-02-21 23:58:48 <gmaxwell> petertodd: yes, indeed. in that case there are 256 bits... though even there, we duplicate the hash. Because ... what cryptocurrency would be free without creating its own second preimage attack.
2183 2013-02-21 23:58:54 <HM> 250kb