1 2012-06-20 00:00:50 EricLombrozo has quit ()
   2 2012-06-20 00:02:24 EricLombrozo has joined
   3 2012-06-20 00:03:30 <EricLombrozo> I have another question - for scripts that use only the x coordinate of the EC point for the public key, do you need to compute first the full 65-byte public key and then hash to get the bitcoin address?
   4 2012-06-20 00:03:51 <EricLombrozo> if so, it appears blockexplorer.com and blockchain.info's implementations are wrong
   5 2012-06-20 00:04:33 <EricLombrozo> and if not, it appears there would be two bitcoin addresses corresponding to a single ECDSA key
   6 2012-06-20 00:04:44 <EricLombrozo> so which is it?
   7 2012-06-20 00:06:06 <gmaxwell> There are more than two addresses in fact, because the encoding isn't constrained to a minmal form.
   8 2012-06-20 00:06:51 <gmaxwell> This isn't at all surprising that there is not a 1:1 correspondence in the context over the overall system.
   9 2012-06-20 00:07:01 <gmaxwell> The blockchain has no concept of adresses at all.
  10 2012-06-20 00:07:02 <EricLombrozo> so the bitcoin scripts don't care about ECDSA keys
  11 2012-06-20 00:07:17 <EricLombrozo> the scripts do have a concept of pubkey has
  12 2012-06-20 00:07:20 <EricLombrozo> the scripts do have a concept of pubkey hash
  13 2012-06-20 00:07:22 JStoker has quit (Excess Flood)
  14 2012-06-20 00:07:27 <gmaxwell> Scripts are programs. Addresses are just data that gets filled in a template of a standard script.
  15 2012-06-20 00:07:35 <EricLombrozo> of course the block chain doesn't have base58check
  16 2012-06-20 00:07:48 <gmaxwell> An address is not an ECDSA key.
  17 2012-06-20 00:07:59 <EricLombrozo> I understand that
  18 2012-06-20 00:08:15 <EricLombrozo> an address is a base58check representation of a hash of the public ECDSA key
  19 2012-06-20 00:08:37 <gmaxwell> hopefully. At least if its to be used in a standard script and redeemed! :)
  20 2012-06-20 00:08:59 allied has quit (Ping timeout: 252 seconds)
  21 2012-06-20 00:09:21 <EricLombrozo> the bitcoin script has hash ops - but it doesn't explicitly deal with digital signature schemes
  22 2012-06-20 00:09:40 <EricLombrozo> so it's just assumed that ECDSA with a particular choice of curve is used?
  23 2012-06-20 00:09:48 allied has joined
  24 2012-06-20 00:10:00 brwyatt is now known as brwyatt|Away
  25 2012-06-20 00:10:04 <gmaxwell> Well— CHECKSIG. But just like the hash ops are hardcoded the behavior of checksig is hardcoded.
  26 2012-06-20 00:10:36 <EricLombrozo> ok, right - so checksig needs to be able to use multiple representations for the public key, then
  27 2012-06-20 00:10:44 <EricLombrozo> and automatically detect which representation is being used, right?
  28 2012-06-20 00:10:49 <gmaxwell> (though there is some more flexiblity in hashes, which may be useful for using zero knowledge proofs to lock payments)
  29 2012-06-20 00:11:07 <gmaxwell> EricLombrozo: correct. It's signaled explicitly in the encoding.
  30 2012-06-20 00:12:07 <EricLombrozo> ok, so this means that the pubkey hash used must match the hash of the public key encoding used to redeem the output (in a standard transaction), yes?
  31 2012-06-20 00:12:27 <gmaxwell> Correct.
  32 2012-06-20 00:12:29 <EricLombrozo> which might only be one of several possible encodings of the pubkey
  33 2012-06-20 00:12:29 <luke-jr> EricLombrozo: also, modern addresses don't necessary contain a key relation at all
  34 2012-06-20 00:12:39 <luke-jr> EricLombrozo: they represent a script
  35 2012-06-20 00:13:16 JStoker has joined
  36 2012-06-20 00:14:49 <EricLombrozo> ok - thanks for the help
  37 2012-06-20 00:15:18 EricLombrozo has left ()
  38 2012-06-20 00:16:30 <gmaxwell> Hm. in 0.7.0 callgrind thinks most of the time is being spent the rbtree in CreateNewBlock, esp in the heap allocations its doing.
  39 2012-06-20 00:21:38 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
  40 2012-06-20 00:22:02 torsthaldo has quit (Read error: Connection reset by peer)
  41 2012-06-20 00:27:09 <jgarzik> gmaxwell: mining definitely alters the profile significantly
  42 2012-06-20 00:28:10 RainbowDashh has joined
  43 2012-06-20 00:28:10 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
  44 2012-06-20 00:28:49 <gmaxwell> jgarzik: 0.7.0 killed the #1 cycle user for the getmemorypool workload: ecdsa validation.
  45 2012-06-20 00:32:25 Sipax has joined
  46 2012-06-20 00:34:16 genjix has joined
  47 2012-06-20 00:34:51 <sipa> wait... getmemorypool doesn't/didn't do ECDSA checks, did it?
  48 2012-06-20 00:35:48 Sipax has quit (Client Quit)
  49 2012-06-20 00:41:31 Tykling has quit (Excess Flood)
  50 2012-06-20 00:42:59 Tykling has joined
  51 2012-06-20 00:43:22 Tykling has quit (Excess Flood)
  52 2012-06-20 00:46:24 RainbowDashh has quit (Read error: Connection reset by peer)
  53 2012-06-20 00:46:36 <gmaxwell> sipa: yes. :(
  54 2012-06-20 00:46:45 <gmaxwell> not itself, but connect input was doing them.
  55 2012-06-20 00:46:49 <gmaxwell> Every time it was called.
  56 2012-06-20 00:47:39 RainbowDashh has joined
  57 2012-06-20 00:48:07 imsaguy is now known as imsaguy3
  58 2012-06-20 00:48:10 imsaguy3 is now known as imsaguy
  59 2012-06-20 00:50:00 Tykling has joined
  60 2012-06-20 00:50:39 <jgarzik> gmaxwell: jfyi it should be straightforward to remove the locks serializing GW/GMP RPC calls, making those RPC-heavy calls more parallel
  61 2012-06-20 00:51:12 * jgarzik has been meaning to add an easy way to mark an RPC call as thread-safe
  62 2012-06-20 00:52:23 <gmaxwell> sipa: call tree for getmemorypool for 0.7.0 http://people.xiph.org/~greg/gmp.png
  63 2012-06-20 00:52:34 <AntKinGTube> anybody noticed the strange swings in the price of btc lately
  64 2012-06-20 00:52:42 <gmaxwell> and for 0.6.2.2: http://people.xiph.org/~greg/gmp_old.png
  65 2012-06-20 00:52:43 <AntKinGTube> lets try to stabilize our buy peeps :)
  66 2012-06-20 00:52:49 <gmaxwell> AntKinGTube: wrong channel.
  67 2012-06-20 00:53:03 <AntKinGTube> ah yes
  68 2012-06-20 00:53:06 <AntKinGTube> thanks gm
  69 2012-06-20 00:53:58 Turingi has quit (Read error: Connection reset by peer)
  70 2012-06-20 00:58:44 <BlueMatt> jgarzik: might make more sense to just move the locks to the function calls themselves, for when someone gets around to doing read-only locks, also, I moved some locks over to function calls and most of the functions dont need both cs_main and cs_wallet, and one or two would make more sense with something else that isnt locked
  71 2012-06-20 00:59:51 <doublec> gmaxwell: In CreateNewBlock, the priotity ordering of the transactions, is what appeared to be causing the increase in cpu load on my pool recently.
  72 2012-06-20 01:01:21 <luke-jr> gmaxwell: how about with txn_prio ?
  73 2012-06-20 01:01:25 <BlueMatt> jgarzik: I spent like 10 minutes on this: https://github.com/TheBlueMatt/bitcoin/compare/669a5d4c9e49fb3027ec7110664faa42615698bc...e2616f533c0b2c12c852c50e70cd852d20c9191f
  74 2012-06-20 01:03:07 <BlueMatt> pretty sure the shared locks dont work, they need upgrade instead
  75 2012-06-20 01:03:10 <BlueMatt> havent tested it though
  76 2012-06-20 01:03:36 <gmaxwell> (updated graphs to have lower thresholds and to show omitted functions)
  77 2012-06-20 01:03:41 dvide has quit ()
  78 2012-06-20 01:05:24 <gmaxwell> doublec: I assume thats the RB tree activity I'm seeing.
  79 2012-06-20 01:08:00 <gmaxwell> not sure why I'm not seeing it in the 0.6.2 trace, but it might just be that it was so cheap compared to the ecdsa stuff that got eliminated its below the 1% threshold. Or the 0.6.2 trace may have had fewer txn in the memorypool.
  80 2012-06-20 01:08:24 <gmaxwell> doublec: what code are you running? is it 0.7.0 based? (does it have the ecdsa cache?)
  81 2012-06-20 01:15:45 DamascusVG has quit (Quit: I Quit - http://www.youtube.com/watch?v=9p97zsQ51Rw)
  82 2012-06-20 01:19:32 one_zero has joined
  83 2012-06-20 01:20:51 one_zero has quit (Client Quit)
  84 2012-06-20 01:22:44 one_zero has joined
  85 2012-06-20 01:27:10 agricocb has joined
  86 2012-06-20 01:31:14 rdponticelli has quit (Ping timeout: 246 seconds)
  87 2012-06-20 01:35:23 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
  88 2012-06-20 01:40:12 <doublec> gmaxwell: 0.6.2.2
  89 2012-06-20 01:42:37 <copumpkin> when's the next official release of bitcoin-qt?
  90 2012-06-20 01:43:37 <gmaxwell> doublec: hm. interesting that you were noticing priority over ecdsa.
  91 2012-06-20 01:43:44 egecko has joined
  92 2012-06-20 01:43:57 twmz has quit (Ping timeout: 265 seconds)
  93 2012-06-20 01:45:46 maaku has joined
  94 2012-06-20 01:49:21 davex__ has quit (Read error: Connection reset by peer)
  95 2012-06-20 01:50:20 davex__ has joined
  96 2012-06-20 01:52:03 <gmaxwell> doublec: anyways my profiles of 0.7.0 show it spending time time screwing around with CTxIndex objects. might be some interesting transactions triggering pessimal behavior which is why I missed that in 0.6.2.2. Hard to tell because it seems to have inlined a bunch of stuff there... getting a new trace without optimizations at all.
  97 2012-06-20 01:54:48 AntKinGTube has quit (Read error: Connection reset by peer)
  98 2012-06-20 01:56:41 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
  99 2012-06-20 02:00:30 jurov is now known as jurov|away
 100 2012-06-20 02:01:27 slush has quit (Ping timeout: 244 seconds)
 101 2012-06-20 02:06:52 <gmaxwell> hehe bun5vdg2agmaxwell.onion   vanity onions are a bit easier than vanity bitcoin addresses.
 102 2012-06-20 02:08:07 Apexseals has quit (Ping timeout: 250 seconds)
 103 2012-06-20 02:09:16 [7] has quit (Disconnected by services)
 104 2012-06-20 02:09:25 TheSeven has joined
 105 2012-06-20 02:16:43 Xunie has quit (Ping timeout: 246 seconds)
 106 2012-06-20 02:17:42 MobiusL has quit (Quit: Ex-Chat)
 107 2012-06-20 02:20:02 slush has joined
 108 2012-06-20 02:20:13 minimoose has quit (Quit: minimoose)
 109 2012-06-20 02:21:24 <luke-jr> O.O
 110 2012-06-20 02:21:33 <luke-jr> gmaxwell: you got half? how long to get 100%?
 111 2012-06-20 02:22:12 dk5 has joined
 112 2012-06-20 02:22:17 MobiusL has joined
 113 2012-06-20 02:22:37 <gmaxwell> Well, it's exponential of course. The onion addresses are 80 bits.
 114 2012-06-20 02:23:38 <dk5> where in the official code are non-standard scripts parsed? also - I like your template matching algorithm, are there opcodes that would be safe to use to expand it?
 115 2012-06-20 02:24:11 genjix has quit (Ping timeout: 244 seconds)
 116 2012-06-20 02:24:33 <dk5> i.e. any hex values you guys don't plan on using later on that would create a conflict
 117 2012-06-20 02:25:20 <gmaxwell> You can't just 'extend' it simply— every node in the network must validate scripts. If you write a script that one node accepts and another doesn't then the world ends.
 118 2012-06-20 02:25:45 <gmaxwell> There are opcodes set aside for additions, the NOPs.
 119 2012-06-20 02:26:14 <gmaxwell> Because then you can construct it so that old nodes manage to ignore the new stuff.
 120 2012-06-20 02:26:49 RainbowDashh has joined
 121 2012-06-20 02:27:00 <gmaxwell> Of course, the scripts have to be written so they always evaluate to true under the NOP interpertation, and this must also be enforced by the new implementation or someone can split the network.
 122 2012-06-20 02:28:53 <dk5> i'm more interested in just parsing the existing scripts, not sending strange ones out into the wild. i'd want to try to parse input scripts using templates as well.
 123 2012-06-20 02:29:17 <jgarzik> BlueMatt: well if you wanna do all the lock auditing immediately... I'm all for it :)
 124 2012-06-20 02:30:10 <jgarzik> BlueMatt: I was thinking even more incrementally
 125 2012-06-20 02:30:48 <dk5> gmaxwell: so, for instance, a template for signatures, or one for scripts with messages followed by an OP_DROP
 126 2012-06-20 02:32:10 brwyatt is now known as brwyatt|Away
 127 2012-06-20 02:33:00 <dk5> gmaxwell: you set aside some for OP_PUBKEY and OP_PUBKEYS and you do something special when those are hit in the script. i'd want to put one that can indicate to skip the next chunk of data (like a message) and go on to the next opcode. is there a safe one to use for that purpose?
 128 2012-06-20 02:34:25 <gmaxwell> dk5: you would just push the data onto the stack and then pop it off again, you don't need to add an opcode for this, though you shouldn't be contemplating using the blockchain as a message transport/store. It's not good for that.
 129 2012-06-20 02:35:34 <dk5> gmaxwell: lol, no that's not my plan. I'm just trying to parse the data. kind of like a toString() function for scripts but able to identify where the key portion is.
 130 2012-06-20 02:35:56 <BlueMatt> jgarzik: I really didnt, I just did the really obvious ones
 131 2012-06-20 02:36:59 <jgarzik> BlueMatt: it's mainly a matter of taste.  while auditing, does one (a) poop some boilerplate in each function, or (b) update vRPCCommands[] with a new 'unlocked' column?
 132 2012-06-20 02:37:12 <gmaxwell> oh, well we have script pretty printing code in 0.7 (git master)
 133 2012-06-20 02:37:19 <gmaxwell> 'pretty' at least.
 134 2012-06-20 02:37:35 <BlueMatt> jgarzik: if it were binary, I would say (b), but its not
 135 2012-06-20 02:38:19 <BlueMatt> and then you end up going back and switching to (a) after doing (b), which is just needless work (imho)
 136 2012-06-20 02:38:20 <gmaxwell> (e.g. it looks like             "scriptPubKey" : "OP_DUP OP_HASH160 06f1b66ffe49df7fce684df16c62f59dc9adbd3f OP_EQUALVERIFY OP_CHECKSIG"
 137 2012-06-20 02:38:23 <gmaxwell> )
 138 2012-06-20 02:38:57 <jgarzik> BlueMatt: no, you update VRPCCommands[] each time you audit and properly lock a function
 139 2012-06-20 02:39:02 <dk5> gmaxwell: it's in the 0.6.2 version too, no? i saw something like that
 140 2012-06-20 02:39:31 <jgarzik> BlueMatt: not all of them need LOCK2(cs_main, pwalletMain->cs_wallet), as I'm sure you're discovering
 141 2012-06-20 02:39:55 <BlueMatt> jgarzik: meh, seems like needless steps...
 142 2012-06-20 02:39:55 <jgarzik> BlueMatt: (a) is not an intermediate step
 143 2012-06-20 02:40:18 <dk5> gmaxwell: it's actually the toString() function for the CScript class
 144 2012-06-20 02:40:31 <jgarzik> both (a) and (b) are easy and provable.  as I said, a matter of taste.
 145 2012-06-20 02:40:40 <gmaxwell> dk5: I don't reacall where we exposed it in 0.6.2 except the debugging stuff.
 146 2012-06-20 02:40:46 <BlueMatt> jgarzik: it took me like 20 minutes to do sanity auditing to get to a pretty decent a, if it took more effort, Id agree, but it doesnt
 147 2012-06-20 02:41:00 <gmaxwell> dk5: in 0.7 you can just run gettransaction <hash>
 148 2012-06-20 02:41:04 <dk5> gmaxwell: is the one in 0.7 different?
 149 2012-06-20 02:41:07 <dk5> i see
 150 2012-06-20 02:41:08 <jgarzik> BlueMatt: first step should be an equivalent transformation
 151 2012-06-20 02:41:18 <jgarzik> BlueMatt: subsequent steps update the locking
 152 2012-06-20 02:42:16 <dk5> gmaxwell: alright, thanks. i'll take a look
 153 2012-06-20 02:42:21 <jgarzik> BlueMatt: first step for (a) would be to create a patch that does nothing but move the lock from CRPCTable::execute() to each function this code, "LOCK2(cs_main, pwalletMain->cs_wallet)"
 154 2012-06-20 02:42:42 <jgarzik> then separate commits would change 'LOCK2(cs_main, pwalletMain->cs_wallet)' to the improved locking
 155 2012-06-20 02:43:43 <BlueMatt> jgarzik: feel free to do it in a cleaner way, I wasnt planning on doing it for real until I had deleted cs_main, added a cs to CBlockStore and moved mapBlockIndex/etc to it.  and since I dont plan on doing that until I get some response, and its not like thats coming soon
 156 2012-06-20 02:46:45 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
 157 2012-06-20 02:47:31 onefourone has quit ()
 158 2012-06-20 02:48:22 <jgarzik> BlueMatt: the main driver (or lack thereof) is user interest.  if gmaxwell or luke-jr or miners think it's worthwhile to unlock GW/GMP, it can be done
 159 2012-06-20 02:49:46 <luke-jr> jgarzik: gmp_bip and gmp_longpoll have been waiting for a while
 160 2012-06-20 02:54:33 <BlueMatt> jgarzik: never said it should or shouldnt be considered important, I was just saying I wasnt planning on doing it for real for a while, if at all
 161 2012-06-20 02:56:43 <BlueMatt> (though shared lock support would mean getmemorypool would be trivially multithreaded...
 162 2012-06-20 02:58:32 <gmaxwell> getmemorypool miners do internal work generation— more important is that other RPCs like getblock / getinfo don't obstruct it.
 163 2012-06-20 02:58:42 <gmaxwell> (also that it be fast in general)
 164 2012-06-20 02:58:43 gribble has quit (Ping timeout: 246 seconds)
 165 2012-06-20 02:58:52 <BlueMatt> (which shared lock support would provide ;) )
 166 2012-06-20 02:59:21 nanotube has quit (Ping timeout: 265 seconds)
 167 2012-06-20 03:01:10 eoss has joined
 168 2012-06-20 03:01:10 eoss has quit (Changing host)
 169 2012-06-20 03:01:10 eoss has joined
 170 2012-06-20 03:01:34 maaku has quit (Quit: maaku)
 171 2012-06-20 03:02:12 maaku has joined
 172 2012-06-20 03:02:38 l1l1ll11l11 has joined
 173 2012-06-20 03:03:35 maaku has quit (Client Quit)
 174 2012-06-20 03:03:45 brwyatt is now known as brwyatt|Away
 175 2012-06-20 03:04:07 maaku has joined
 176 2012-06-20 03:05:20 jimbit has quit (Quit: Leaving)
 177 2012-06-20 03:08:52 fpgaminer has joined
 178 2012-06-20 03:17:45 sanchaz has quit (Ping timeout: 276 seconds)
 179 2012-06-20 03:27:28 nanotube has joined
 180 2012-06-20 03:28:46 Xunie has joined
 181 2012-06-20 03:33:06 devrandom has quit (Quit: leaving)
 182 2012-06-20 03:35:27 D34TH_ has joined
 183 2012-06-20 03:38:38 slush has quit (Ping timeout: 246 seconds)
 184 2012-06-20 03:39:12 D34TH has quit (Ping timeout: 276 seconds)
 185 2012-06-20 03:41:15 D34TH__ has joined
 186 2012-06-20 03:41:20 D34TH__ is now known as D34TH
 187 2012-06-20 03:41:30 D34TH has quit (Changing host)
 188 2012-06-20 03:41:30 D34TH has joined
 189 2012-06-20 03:42:45 maaku has quit (Quit: maaku)
 190 2012-06-20 03:43:18 maaku has joined
 191 2012-06-20 03:45:03 D34TH_ has quit (Ping timeout: 276 seconds)
 192 2012-06-20 03:52:32 gribble has joined
 193 2012-06-20 04:05:07 JZavala has joined
 194 2012-06-20 04:05:35 tyn has quit (Ping timeout: 246 seconds)
 195 2012-06-20 04:10:58 <gmaxwell> hm, http://people.xiph.org/~greg/main.cpp.ann.txt  the profile on the O0 compile seems to say that it's spending all the time in getmemorypool at main.cpp:3388
 196 2012-06-20 04:16:01 eoss has quit (Remote host closed the connection)
 197 2012-06-20 04:21:18 <luke-jr> gmaxwell: Mitre is having a hard time figuring out whether our block propagation mis-incentive should be considered a vuln or not >_<
 198 2012-06-20 04:21:22 danbri has quit (Remote host closed the connection)
 199 2012-06-20 04:23:01 <luke-jr> I'm kindof leaning toward the interpretation that "The Bitcoin node p2p protocol suffers from a bitcoin-loss bug affecting miners", and not a vulnerability
 200 2012-06-20 04:28:47 RainbowDashh has quit (Quit: Computer has gone to sleep. DERPY HOOVES SLAMMING THE LAPTOP LID MISTAKE?)
 201 2012-06-20 04:30:37 fpgaminer has quit (Remote host closed the connection)
 202 2012-06-20 04:30:54 fpgaminer has joined
 203 2012-06-20 04:39:32 RainbowDashh has joined
 204 2012-06-20 04:40:15 leotreasure has joined
 205 2012-06-20 04:43:31 <jgarzik> GetTransaction() is an odd, odd function
 206 2012-06-20 04:43:54 <jgarzik> one of those "sometimes we give you a tx, sometimes we give you a block" type of deals
 207 2012-06-20 04:46:43 JZavala has quit (Ping timeout: 240 seconds)
 208 2012-06-20 05:02:32 Hasbro has quit (Changing host)
 209 2012-06-20 05:02:32 Hasbro has joined
 210 2012-06-20 05:06:25 wasabi1 has joined
 211 2012-06-20 05:07:58 wasabi2 has quit (Ping timeout: 244 seconds)
 212 2012-06-20 05:12:23 maaku has quit (Quit: maaku)
 213 2012-06-20 05:13:13 dlb76 has quit (Ping timeout: 245 seconds)
 214 2012-06-20 05:14:08 bobke has quit (Quit: No Ping reply in 180 seconds.)
 215 2012-06-20 05:14:22 bobke has joined
 216 2012-06-20 05:15:18 ByronJohnson has quit (Ping timeout: 245 seconds)
 217 2012-06-20 05:16:22 ByronJohnson has joined
 218 2012-06-20 05:17:47 D34TH has quit (Read error: Connection reset by peer)
 219 2012-06-20 05:18:50 maaku has joined
 220 2012-06-20 05:20:26 guruvan has quit (Quit: oh noessss)
 221 2012-06-20 05:21:51 guruvan has joined
 222 2012-06-20 05:25:56 maaku has quit (Quit: maaku)
 223 2012-06-20 05:25:59 knotwork_ is now known as knotwork
 224 2012-06-20 05:28:34 maaku has joined
 225 2012-06-20 05:36:42 maaku has quit (Quit: maaku)
 226 2012-06-20 05:37:29 maaku has joined
 227 2012-06-20 05:49:18 RainbowDashh has quit (Quit: SLEEP MODE. <@suborbital> no i filtered out RainbowDashh join quit msgs - appearantly it filtered out everything)
 228 2012-06-20 05:49:44 RazielZ has joined
 229 2012-06-20 05:49:54 RainbowDashh has joined
 230 2012-06-20 06:00:04 mmoya has joined
 231 2012-06-20 06:04:29 l1l1ll11l11 has quit (Quit: Leaving.)
 232 2012-06-20 06:06:10 Internet151 has quit (Read error: Connection reset by peer)
 233 2012-06-20 06:06:24 Internet151 has joined
 234 2012-06-20 06:12:51 JStoker has quit (Excess Flood)
 235 2012-06-20 06:14:05 Graet has quit (Ping timeout: 248 seconds)
 236 2012-06-20 06:20:48 JStoker has joined
 237 2012-06-20 06:28:17 toffoo has quit ()
 238 2012-06-20 06:38:37 ovidiusoft has joined
 239 2012-06-20 06:46:03 Graet has joined
 240 2012-06-20 06:47:06 <amiller> etotheipi_, what if we compromise
 241 2012-06-20 06:47:21 <amiller> suppose we balance a merkle tree the way i'd like to, with a red-black balancing bit
 242 2012-06-20 06:47:41 m00p has joined
 243 2012-06-20 06:47:42 <amiller> but actually store the data in an implementation of tires using libjudy
 244 2012-06-20 06:48:43 <amiller> ah i don't know that this actually has the ideal io efficiency
 245 2012-06-20 06:51:37 <amiller> as a server, what i would really like to do is store every possible 'path' (verification object) for the merkle tree, that the clients could ask me to fetch
 246 2012-06-20 06:51:55 <amiller> the naive solution is N log N - it's trivially parallel! but it's a ridiculous solution because it duplicates so much data.
 247 2012-06-20 06:53:36 <amiller> (the naive solution is literally to store each possible path, there are only N, each one is N log N. but for example you'd have N duplicates of the root node)
 248 2012-06-20 06:53:59 <amiller> ah nvm i don't think this is going where i want it to, since every update would change _all_ the possible paths, it's not useful to think of it that way
 249 2012-06-20 06:54:12 m00p has quit (Ping timeout: 276 seconds)
 250 2012-06-20 06:55:04 m00p has joined
 251 2012-06-20 06:55:31 erle- has joined
 252 2012-06-20 06:56:56 <amiller> the next best thing though, still using tries + red black merkle, is that you just store each logical merkle-tree node as an ordinary element in the trie
 253 2012-06-20 06:57:19 <amiller> ick, but that discards any potential use of the locality
 254 2012-06-20 06:58:24 <amiller> if you access a root node you definitely have to access one of your children, so that's the value of higher fanout
 255 2012-06-20 07:00:04 <amiller> my goal will still be to have a logical binary tree as far as the normative protocol is concerned, so that parameters fanout can be left up to the different implementations
 256 2012-06-20 07:00:29 moop has joined
 257 2012-06-20 07:03:09 m00p has quit (Ping timeout: 248 seconds)
 258 2012-06-20 07:06:57 <amiller> "Binary search trees (BSTs) and skip lists are good for main memory implementations, but for large data sets requiring secondary storage, they have poor I/O performance. A classic way to get good I/O performance is to use a B-tree." is from one of the papers i like http://truthsayer.cs.ucdavis.edu/algorithmica.pdf
 259 2012-06-20 07:14:14 ovidiusoft has quit (Ping timeout: 246 seconds)
 260 2012-06-20 07:26:06 <amiller> THEOREM 5. For a one-dimensional range query with T answer points we get a VO of size (log N + T ) which can be constructed with (logB N + T/B) I/O operations using a multi-way tree of size (N).
 261 2012-06-20 07:26:35 <amiller> range query there, especially means "give me all the spendable coins at this address"
 262 2012-06-20 07:28:03 <amiller> B is the size of the block, the main parameter, accessing it costs a single operation in this expression
 263 2012-06-20 07:29:04 one_zero has quit (Ping timeout: 244 seconds)
 264 2012-06-20 07:33:12 Prattler has joined
 265 2012-06-20 07:33:24 <amiller> so i'll go away for a bit and come back when i've made a shitty b-tree simulation using python tuples i guess, it'll still be a 'look at my code' sort of thing
 266 2012-06-20 07:33:52 <amiller> i suppose i could profile it too
 267 2012-06-20 07:35:40 <amiller> since i have a 'reference' implementation of the logical tree, that is intended to be fairly simple to reason about, i shouldn't have to worry about any of the hashes or introduce any new security claims for this exercise
 268 2012-06-20 07:38:41 RainbowDashh has quit (Quit: SLEEP MODE. <@suborbital> no i filtered out RainbowDashh join quit msgs - appearantly it filtered out everything)
 269 2012-06-20 07:41:15 RainbowDashh has joined
 270 2012-06-20 07:42:37 maaku has quit (Quit: maaku)
 271 2012-06-20 07:43:09 maaku has joined
 272 2012-06-20 07:53:57 sirk390 has joined
 273 2012-06-20 08:01:53 luke-jr_ has joined
 274 2012-06-20 08:01:57 luke-jr has quit (Ping timeout: 248 seconds)
 275 2012-06-20 08:09:07 coblee has quit (Ping timeout: 272 seconds)
 276 2012-06-20 08:12:01 coblee has joined
 277 2012-06-20 08:18:06 molecular has quit (Ping timeout: 244 seconds)
 278 2012-06-20 08:21:22 smtmnyz has quit (Read error: Connection reset by peer)
 279 2012-06-20 08:22:00 smtmnyz has joined
 280 2012-06-20 08:27:19 Maccer has quit (Quit: Insert SITOOP)
 281 2012-06-20 08:27:36 TheSeven has quit (Disconnected by services)
 282 2012-06-20 08:27:44 [7] has joined
 283 2012-06-20 08:30:19 [7] has quit (Read error: Operation timed out)
 284 2012-06-20 08:30:36 molecular has joined
 285 2012-06-20 08:30:58 RainbowDashh has quit (Quit: SLEEP MODE. <@suborbital> no i filtered out RainbowDashh join quit msgs - appearantly it filtered out everything)
 286 2012-06-20 08:31:30 ThomasV has joined
 287 2012-06-20 08:32:29 RainbowDashh has joined
 288 2012-06-20 08:34:45 TheSeven has joined
 289 2012-06-20 08:53:27 _Fireball has joined
 290 2012-06-20 09:02:13 sytse has quit (Ping timeout: 248 seconds)
 291 2012-06-20 09:04:27 sturles has quit (Quit: leaving)
 292 2012-06-20 09:17:36 t7 has joined
 293 2012-06-20 09:19:12 TheSeven has quit (Read error: Operation timed out)
 294 2012-06-20 09:20:13 TheSeven has joined
 295 2012-06-20 09:21:07 sturles has joined
 296 2012-06-20 09:21:27 Maccer has joined
 297 2012-06-20 09:27:03 MobiusL has quit (Remote host closed the connection)
 298 2012-06-20 09:27:58 MobiusL has joined
 299 2012-06-20 09:29:13 slush has joined
 300 2012-06-20 09:32:39 ivan\ has quit (Ping timeout: 245 seconds)
 301 2012-06-20 09:33:59 ivan\ has joined
 302 2012-06-20 09:42:24 tsche has joined
 303 2012-06-20 09:44:31 random_cat__ has quit (Ping timeout: 276 seconds)
 304 2012-06-20 09:46:36 random_cat__ has joined
 305 2012-06-20 09:47:38 erle- has quit (Quit: erle-)
 306 2012-06-20 09:49:50 erle- has joined
 307 2012-06-20 09:54:43 Diablo-D3 has quit (Ping timeout: 244 seconds)
 308 2012-06-20 09:55:20 erle- has quit (Quit: erle-)
 309 2012-06-20 09:55:38 erle- has joined
 310 2012-06-20 10:02:01 thesheff17 has quit (Ping timeout: 252 seconds)
 311 2012-06-20 10:05:21 genjix has joined
 312 2012-06-20 10:05:33 grondilu has joined
 313 2012-06-20 10:07:13 <grondilu> I don't understand how IP are encoded on IRC.  For instance, on bitcoinTEST I see an address as u71xQ2UmhBG22nq, but this gives me at most 11 bytes.  Clearly not enough to encode an IPv6.  Apart from the C++ source code which is tough to grasp, is there a documentation about that somewhere?
 314 2012-06-20 10:08:04 leotreasure has quit (Quit: leotreasure)
 315 2012-06-20 10:08:34 ThomasV has quit (Ping timeout: 276 seconds)
 316 2012-06-20 10:11:55 <wumpus> does irc bootstrapping support ipv6 at all?
 317 2012-06-20 10:12:26 Turingi has joined
 318 2012-06-20 10:14:37 <grondilu> wumpus: it's kind of the default since v0.6, I think.
 319 2012-06-20 10:17:19 <wumpus> looking at irc.cpp it seems not, it uses an "u"+a base58-encoded (ipv4 address + port) structure
 320 2012-06-20 10:17:20 _Fireball has quit (Read error: Connection reset by peer)
 321 2012-06-20 10:17:22 thesheff17 has joined
 322 2012-06-20 10:17:30 sanchaz has joined
 323 2012-06-20 10:17:50 <wumpus> see EncodeAddress and the ircaddr structure right at the top
 324 2012-06-20 10:18:05 _Fireball has joined
 325 2012-06-20 10:19:47 <genjix> grondilu: irc isnt used anymore
 326 2012-06-20 10:19:55 <genjix> it's off by default
 327 2012-06-20 10:20:47 <wumpus> yeah only for testnet
 328 2012-06-20 10:22:08 <grondilu> ok so what's the method for bootstapping now?
 329 2012-06-20 10:22:30 sirk390 has quit (Ping timeout: 245 seconds)
 330 2012-06-20 10:23:22 sirk390 has joined
 331 2012-06-20 10:24:56 <genjix> grondilu: bootstrap nodes + peerlist (which is far more sensible)
 332 2012-06-20 10:26:26 <grondilu> is it about this pnSeed big array I see in net.cpp?
 333 2012-06-20 10:26:41 <grondilu> Some IP are hard-coded?
 334 2012-06-20 10:28:06 <wumpus> and the dns mechanism
 335 2012-06-20 10:28:17 Zarutian has joined
 336 2012-06-20 10:28:49 <grondilu> indeed, I see the strDNSSeed array.  Ok, why not.
 337 2012-06-20 10:30:01 sirk390 has quit (Ping timeout: 276 seconds)
 338 2012-06-20 10:30:15 sirk390 has joined
 339 2012-06-20 10:30:17 agricocb has quit (Remote host closed the connection)
 340 2012-06-20 10:30:35 <grondilu> One thing I don't like with C++ is that it is tough to find out where something is defined.  I use etags and it can not find the source of "in_addr" in irc.cpp, for instance :(
 341 2012-06-20 10:31:15 <[Tycho]> How is this related to C++ ?
 342 2012-06-20 10:31:21 <[Tycho]> It's just a flaw in your IDE
 343 2012-06-20 10:31:32 <grondilu> yeah, probably.
 344 2012-06-20 10:31:45 * grondilu doesn't use any IDE
 345 2012-06-20 10:32:44 <wumpus> no problem in qt creator, and many other ides which have a working go-to-definition
 346 2012-06-20 10:33:13 <grondilu> Maybe I should try one.
 347 2012-06-20 10:34:08 <[Tycho]> The best IDE ever is MSVC 6
 348 2012-06-20 10:34:32 * wumpus puke
 349 2012-06-20 10:34:56 <grondilu> [Tycho]: I can't use any MS software.
 350 2012-06-20 10:35:15 <grondilu> The only one I know is Eclypse.  What do you think about it?
 351 2012-06-20 10:35:25 <wumpus> you need a fast machine 
 352 2012-06-20 10:35:29 <wumpus> for eclipse 
 353 2012-06-20 10:35:44 <[Tycho]> I tried eclipse. Don't know what can be worse.
 354 2012-06-20 10:36:01 <wumpus> I really like qt creator
 355 2012-06-20 10:36:20 <grondilu> wumpus: is it ok with a small, netbook like, machine?
 356 2012-06-20 10:36:22 <wumpus> (and yes, you can use it for non-qt projects)
 357 2012-06-20 10:36:23 <wumpus> yes
 358 2012-06-20 10:36:41 * grondilu is running apt-cache search qt creator
 359 2012-06-20 10:37:33 * grondilu runs apt-get install qtcreator{,-doc}
 360 2012-06-20 10:37:37 slush has quit (Ping timeout: 244 seconds)
 361 2012-06-20 10:38:32 slush has joined
 362 2012-06-20 10:43:17 erle- has quit (Quit: erle-)
 363 2012-06-20 10:43:24 erle- has joined
 364 2012-06-20 10:56:23 drizztbsd has joined
 365 2012-06-20 10:57:36 jurov is now known as away!aktooj@84.245.71.31|jurov
 366 2012-06-20 11:07:25 grondilu has quit (Quit: leaving)
 367 2012-06-20 11:07:42 slush has quit (Ping timeout: 246 seconds)
 368 2012-06-20 11:09:35 Turingi has quit (Read error: Connection reset by peer)
 369 2012-06-20 11:17:12 Ferroh has quit (Ping timeout: 265 seconds)
 370 2012-06-20 11:17:27 agricocb has joined
 371 2012-06-20 11:19:41 sytse has joined
 372 2012-06-20 11:26:25 jjjx has joined
 373 2012-06-20 11:27:41 Nachtwind has joined
 374 2012-06-20 11:34:25 genjix has quit (Read error: Operation timed out)
 375 2012-06-20 11:38:12 O2made has joined
 376 2012-06-20 11:38:23 O2made has quit (Read error: Connection reset by peer)
 377 2012-06-20 11:41:02 dvide has joined
 378 2012-06-20 11:52:34 cdecker has joined
 379 2012-06-20 11:55:11 Backburn has quit (Remote host closed the connection)
 380 2012-06-20 11:55:33 Backburn has joined
 381 2012-06-20 12:00:09 xorgate has quit (Ping timeout: 245 seconds)
 382 2012-06-20 12:12:37 osxorgate has joined
 383 2012-06-20 12:17:53 ThomasV has joined
 384 2012-06-20 12:18:13 osxorgate has quit ()
 385 2012-06-20 12:18:31 xorgate has joined
 386 2012-06-20 12:27:42 MobiusL has quit (Quit: Ex-Chat)
 387 2012-06-20 12:31:48 jurov is now known as jurov|away
 388 2012-06-20 12:33:10 MobiusL has joined
 389 2012-06-20 12:34:02 danbri has joined
 390 2012-06-20 12:40:09 <gmaxwell> < luke-jr> gmaxwell: Mitre is having a hard time figuring out
 391 2012-06-20 12:40:29 <gmaxwell> I think it's not, — if it were than almost every performance bug could be argued to be one.
 392 2012-06-20 12:40:51 <gmaxwell> "this bad performance might cause people to use something other than bitcoin!"
 393 2012-06-20 12:41:15 <sipa> mitre?
 394 2012-06-20 12:43:21 <sipa> wumpus: lfnet nicknames are not long enough to encode 128 bits
 395 2012-06-20 12:44:26 <sipa> maybe you could put them in realnames, and have nodes do a whois on eachother
 396 2012-06-20 12:44:47 <sipa> but i don't think it was important enough to bother
 397 2012-06-20 12:45:47 <kinlo> the best chain is determined by only looking at the sum of the difficulties of the chain of blocks right?
 398 2012-06-20 12:46:12 <kinlo> there are no other reasons why bitcoin would choose a different chain - given that all blocks are valid?
 399 2012-06-20 12:46:29 <gmaxwell> luke-jr_: It sort of goes along with this very famous linus post: http://kerneltrap.org/mailarchive/linux-kernel/2008/7/15/2506154  — sometimes we forget that other bugs can be very important too, and want to start calling every serious issue a security bug.
 400 2012-06-20 12:46:56 <gmaxwell> kinlo: well, they can be tied, so you'll use whatever you had first in that case.
 401 2012-06-20 12:47:09 <kinlo> except for ties
 402 2012-06-20 12:47:25 <kinlo> would bitcoind download blocks from their peers if they are tied?
 403 2012-06-20 12:47:53 <kinlo> ie, if I have a chain, and you're offering a chain with last block different, would I even attempt to download the block from you?
 404 2012-06-20 12:48:01 <sipa> kinlo: yes
 405 2012-06-20 12:48:08 <kinlo> so orphans propagate?
 406 2012-06-20 12:48:13 <sipa> no
 407 2012-06-20 12:48:28 <sipa> blocks are only announced when they extend the main chain
 408 2012-06-20 12:48:34 <sipa> but you can always download them
 409 2012-06-20 12:48:38 <kinlo> ic
 410 2012-06-20 12:48:43 <gmaxwell> Your peer will only offer it if your peer has accepted it as best.
 411 2012-06-20 12:48:49 root2 has joined
 412 2012-06-20 12:48:50 <sipa> i don't think you can download an orphan even
 413 2012-06-20 12:49:09 <gmaxwell> If you don't accept it as best you won't pass it on... so the propagation stops.
 414 2012-06-20 12:49:22 <kinlo> and you will download everything that it presented?
 415 2012-06-20 12:49:45 <kinlo> given that it is valid
 416 2012-06-20 12:49:47 <sipa> unless you already have it
 417 2012-06-20 12:49:55 <sipa> and you don't know it's valid before downloading it
 418 2012-06-20 12:50:13 <kinlo> yeah, but you know that the header matches difficulty
 419 2012-06-20 12:50:23 <gmaxwell> No you don't.
 420 2012-06-20 12:50:26 <sipa> no, only hashes are announced, not headers
 421 2012-06-20 12:50:44 <kinlo> oh, so I can just send fake hashes to my peer, and my peer will download the block from me?
 422 2012-06-20 12:50:55 <sipa> no, only hashes are announced, not headersyes
 423 2012-06-20 12:50:59 <sipa> yes
 424 2012-06-20 12:51:01 <kinlo> ofcourse, it will then subsequently invalidate the block and block me
 425 2012-06-20 12:51:06 <sipa> indeed
 426 2012-06-20 12:51:19 <kinlo> but I could trigger a huge download very easily
 427 2012-06-20 12:51:25 <kinlo> well huge, up to blocklenght
 428 2012-06-20 12:51:32 <kinlo> maxblocklength*
 429 2012-06-20 12:51:53 <gmaxwell> kinlo: of course you could also DOS your peer with unwanted pings. And?
 430 2012-06-20 12:52:13 <kinlo> gmaxwell: I'm just trying to grasp the mechanism, not trying to point out flaws :)
 431 2012-06-20 12:52:26 <sipa> upon announce: 1) check if we already have it, if not, request data 2) when data arrives, check superficial validity (PoW, difficulty) 3) check whether its parent is known 4a) if not, store as orphan in memory and request parents 4b) is parent is known, store on disk 5) try to connect it to make it part of the the new best chain
 432 2012-06-20 12:55:02 <kinlo> mmmz, how does it know the difficulty if it doesn't know where the block comes from?
 433 2012-06-20 12:55:27 <kinlo> in theory, the difficulty could drop back to 1 if everybody stopped mining, so the client should accept diff=1 blocks too, right?
 434 2012-06-20 12:55:41 <sipa> you're right; difficulty is only checked after finding the parent, of course
 435 2012-06-20 12:55:46 <sipa> but PoW is checked before that
 436 2012-06-20 12:55:53 <kinlo> PoW could be of diff=1
 437 2012-06-20 12:56:01 <sipa> yes
 438 2012-06-20 12:56:14 <kinlo> mmz, can I then upload 1000 blocks of 1 meg if I just generate 1000 with valid diff=1?
 439 2012-06-20 12:56:33 <kinlo> as you first need to download parent to do proper checking...
 440 2012-06-20 12:57:14 <gmaxwell> kinlo: there is a check for plausable decline from the prior checkpoint.
 441 2012-06-20 12:57:31 <sipa> oh, righty
 442 2012-06-20 12:58:30 <kinlo> :)
 443 2012-06-20 12:58:32 <kinlo> thanks
 444 2012-06-20 12:58:32 <gmaxwell> e.g. it takes log4(difficulty)*2016 blocks to get to diff 1.
 445 2012-06-20 12:58:35 rdponticelli has joined
 446 2012-06-20 12:59:04 <kinlo> and in that case the timestamp must be changed accordingly too
 447 2012-06-20 12:59:19 <kinlo> and the client refuses blocks more then a few hours in the future right?
 448 2012-06-20 12:59:42 slush has joined
 449 2012-06-20 12:59:43 <gmaxwell> Not more than two hours, right.
 450 2012-06-20 12:59:59 <kinlo> makes sense
 451 2012-06-20 13:00:24 <gmaxwell> There are ways to improve this process to make it better but they haven't been done yet.
 452 2012-06-20 13:00:48 <kinlo> I dunno wether improving that part is important
 453 2012-06-20 13:00:58 <gmaxwell> A little.
 454 2012-06-20 13:01:02 <kinlo> the main problem still looks to be io
 455 2012-06-20 13:01:10 <gmaxwell> Main problem of what?
 456 2012-06-20 13:01:16 <kinlo> block propagation
 457 2012-06-20 13:01:22 <kinlo> chain downloading
 458 2012-06-20 13:02:09 <gmaxwell> I would normally take those to be two very different issues.
 459 2012-06-20 13:02:50 <gmaxwell> It appears that absent undiscovered bugs the latency for a block to reach most of the network is due to just the time it takes to validate blocks right now. Though it doesn't have to be.
 460 2012-06-20 13:03:20 <gmaxwell> Downloading the whole chain is just a question of raw data— but there isn't any particular reason that downloading the whole chain needs to get in the user's way.
 461 2012-06-20 13:03:28 <kinlo> yeah, but chain downloading means block validating right?
 462 2012-06-20 13:04:03 Nachtwind has left ("Verlassend")
 463 2012-06-20 13:04:10 <kinlo> during initial download, one does verify the entire chain, or does it assume certain blocks are already verified and valid?
 464 2012-06-20 13:04:13 <gmaxwell> kinlo: In one case, the propagation of a new block, the latency is important — in the other the throughput is important.
 465 2012-06-20 13:04:29 <kinlo> true
 466 2012-06-20 13:04:46 <sipa> never underestimate the bandwidth of a truck filled with DVD's
 467 2012-06-20 13:04:54 <gmaxwell> kinlo: it verifies the whole chain. But as I mentioned, there isn't any reason that this should matter to the user. It should happen in the background.
 468 2012-06-20 13:05:08 JZavala has joined
 469 2012-06-20 13:05:20 <kinlo> but in both cases validation is a big reason of it being slow
 470 2012-06-20 13:05:34 <gmaxwell> kinlo: A node that started up and pulled headers first in reverse time order could pick the probably best chain and act as a SPV node until the chain sync caught up.
 471 2012-06-20 13:05:56 <kinlo> sipa: ack on that, we often use the bandwith of the e19 to get our stuff uploaded, much faster then the average provider here :)
 472 2012-06-20 13:06:07 <gribble> New news from bitcoinrss: zootreeves opened pull request 1487 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1487>
 473 2012-06-20 13:06:13 <gmaxwell> kinlo: depends on the hardware. We've fixed enough bugs that for fast machines network bandwidth and unfortunate peer selection limit the block download.
 474 2012-06-20 13:11:31 JZavala has quit (Ping timeout: 250 seconds)
 475 2012-06-20 13:18:21 root2 has quit (Ping timeout: 244 seconds)
 476 2012-06-20 13:18:37 genjix has joined
 477 2012-06-20 13:21:12 <gribble> New news from bitcoinrss: sipa opened pull request 1488 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1488>
 478 2012-06-20 13:23:24 <genjix> sipa: might want to remove that subscribe stuff in net.cpp too
 479 2012-06-20 13:23:33 moop__ has joined
 480 2012-06-20 13:23:34 <sipa> wasn't that removed already?
 481 2012-06-20 13:23:44 <sipa> yup
 482 2012-06-20 13:23:52 <genjix> ah ok then
 483 2012-06-20 13:24:26 danbri_ has joined
 484 2012-06-20 13:25:29 danbri has quit (Read error: No route to host)
 485 2012-06-20 13:26:15 moop has quit (Ping timeout: 252 seconds)
 486 2012-06-20 13:28:00 gavinandresen has joined
 487 2012-06-20 13:34:08 sanchaz has quit ()
 488 2012-06-20 13:36:53 <gavinandresen> I just tagged v0.6.3rc1, and am gitian-building it now.  Any other gitian-capable people here and able to build?
 489 2012-06-20 13:38:17 egecko_ has joined
 490 2012-06-20 13:39:10 egecko has quit (Ping timeout: 276 seconds)
 491 2012-06-20 13:39:29 copumpkin has quit (Quit: Computer has gone to sleep.)
 492 2012-06-20 13:42:19 TheSeven has quit (Disconnected by services)
 493 2012-06-20 13:42:28 [7] has joined
 494 2012-06-20 13:44:03 JZavala has joined
 495 2012-06-20 13:44:21 ThomasV has quit (Quit: Quitte)
 496 2012-06-20 13:45:18 genjix has quit (Ping timeout: 248 seconds)
 497 2012-06-20 13:46:41 slush2 has joined
 498 2012-06-20 13:46:55 slush has quit (Quit: Leaving.)
 499 2012-06-20 13:47:55 egecko_ has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 500 2012-06-20 13:50:23 JZavala has quit (Ping timeout: 244 seconds)
 501 2012-06-20 13:52:34 [7] has quit (Disconnected by services)
 502 2012-06-20 13:52:42 TheSeven has joined
 503 2012-06-20 13:52:50 luke-jr_ is now known as luke-jr
 504 2012-06-20 13:55:03 danbri_ has quit (Read error: Connection reset by peer)
 505 2012-06-20 13:56:21 <Graet> any info on the proposed "backbone" available yet?
 506 2012-06-20 13:56:23 <sipa> gavinandresen: building (assuming my gitian still works)
 507 2012-06-20 13:56:30 <sipa> Graet: backbone?
 508 2012-06-20 13:56:51 <gavinandresen> jgarzik says a miner backbone is in the works....
 509 2012-06-20 13:56:55 ovidiusoft has joined
 510 2012-06-20 13:57:00 <sipa> ah, jeff's project
 511 2012-06-20 13:57:16 copumpkin has joined
 512 2012-06-20 13:57:25 erle- has quit (Quit: erle-)
 513 2012-06-20 13:57:27 <jgarzik> suddenly accelerated.  ETA 7 days to a 3-node, network dispersed backbone of bitcoin-optimized machines.
 514 2012-06-20 13:57:42 erle- has joined
 515 2012-06-20 13:57:44 <jgarzik> people will be able to sponsor nodes too, if they wish to contribute with money
 516 2012-06-20 13:57:55 <jgarzik> (or simply donate a dedicated server)
 517 2012-06-20 13:57:56 <Eliel> the wonders of additional publicity :)
 518 2012-06-20 13:58:00 minimoose has joined
 519 2012-06-20 13:58:25 <jgarzik> gavinandresen: not necessarily a miner backbone...  a backbone connecting "major" sites of all sorts
 520 2012-06-20 13:58:41 <jgarzik> TX producers as well as miners
 521 2012-06-20 13:58:43 <gavinandresen> right, sorry, I mean to say "major backbone"
 522 2012-06-20 13:58:46 <Graet> dedicated server ? or a vps on a dedi server?
 523 2012-06-20 13:59:00 <gavinandresen> (ooh, new nickname for Jeff,  "Major Backbone")
 524 2012-06-20 13:59:06 <Graet> hehe
 525 2012-06-20 13:59:31 <jgarzik> rofl
 526 2012-06-20 13:59:38 <Eliel> Graet: I'd think a VPS works about as well as a dedicated.
 527 2012-06-20 13:59:49 <jgarzik> Eliel: VPS is not so great for security
 528 2012-06-20 13:59:53 <Eliel> well, depending on the specs though :)
 529 2012-06-20 13:59:54 <Graet> what resources/bandwidth do you expect a node to need jgarzik ?
 530 2012-06-20 14:00:04 <jgarzik> Eliel: latencies are too variable on a VPS, also
 531 2012-06-20 14:00:30 <sipa> hmm, so i won't be able to connect my VPS that runs the DNS seed :(
 532 2012-06-20 14:00:33 <Graet> wel i have dedi servewr is several countries, a vps on one of my servers is as secure as another dedi :) its not linode :P
 533 2012-06-20 14:00:34 <jgarzik> Graet: standard bitcoin node, plus a little bit of extra bandwidth for statistics gathering
 534 2012-06-20 14:01:02 <Graet> ok, i may be able to provide 1 or 2 nodes
 535 2012-06-20 14:01:04 <jgarzik> sipa: you may connect to backbone, sure.  I'm saying I will not build backbone nodes using a VPS.
 536 2012-06-20 14:01:19 danbri has joined
 537 2012-06-20 14:01:34 <jgarzik> Graet: that would be helpful...
 538 2012-06-20 14:01:46 <Graet> jgarzik, i have several powerful machinhes i split into vms, how is onhe less secure than a dedi p[lease ?
 539 2012-06-20 14:02:14 <sipa> jgarzik: i see
 540 2012-06-20 14:02:58 <jgarzik> Graet: it is more difficult to hack into, or clone, a dedicated server unobserved.
 541 2012-06-20 14:03:19 <SomeoneWeird> err
 542 2012-06-20 14:03:22 <jgarzik> Graet: VMs introduce a new level of security issues, as we've seen with LInode and RackSpace hacks
 543 2012-06-20 14:03:37 <Graet> err dont they have to hack into my dedi b4 they can do those thiongs tho?
 544 2012-06-20 14:03:47 <jgarzik> Graet: yes
 545 2012-06-20 14:04:01 minimoose_ has joined
 546 2012-06-20 14:04:04 dvide_ has joined
 547 2012-06-20 14:04:07 <Graet> so how is a vm on my dedi less secure
 548 2012-06-20 14:04:14 <Graet> sorry, i'm confudsed :)
 549 2012-06-20 14:04:16 <sipa> it is not
 550 2012-06-20 14:04:25 <sipa> Graet: the question is just whether you operate the actual hardware it is running on
 551 2012-06-20 14:04:46 <Graet> well i do , but <jgarzik> sipa: you may connect to backbone, sure.  I'm saying I will not build backbone nodes using a VPS.
 552 2012-06-20 14:04:57 <jgarzik> Graet: from the perspective of the outside party, it requires trusting the machine operator's security, in addition to your own.  one additional level of trust.
 553 2012-06-20 14:04:58 <Graet> so i was trying to get clarification :)
 554 2012-06-20 14:05:26 dvide has quit (Ping timeout: 260 seconds)
 555 2012-06-20 14:05:40 <jgarzik> but for backbone, latency is also a big issue.  VPS's tend to "stutter" (have super-high latencies at unpredictable times)
 556 2012-06-20 14:06:06 <Graet> i'm the machine operator? or do you require dedivated servers only you can access similar to freenodes way?
 557 2012-06-20 14:06:11 <gmaxwell> 06:56 <@jgarzik> Eliel: VPS is not so great for security
 558 2012-06-20 14:06:16 genjix has joined
 559 2012-06-20 14:06:37 <gmaxwell> with our current on the wire protocol it hardly matters, anyone with access to the network from $here to $there can just intercept all the connections.
 560 2012-06-20 14:06:58 minimoose has quit (Ping timeout: 272 seconds)
 561 2012-06-20 14:06:58 minimoose_ is now known as minimoose
 562 2012-06-20 14:07:05 <jgarzik> nod
 563 2012-06-20 14:07:13 <gmaxwell> Though perhaps someday we'll add authenticated addnode or something.
 564 2012-06-20 14:07:16 <jgarzik> if you are the machine op, you may of course trust your own VPS
 565 2012-06-20 14:07:28 <jgarzik> I'll need to heavily audit this machines, if I'm building peering agreements with major sites
 566 2012-06-20 14:07:32 Turingi has joined
 567 2012-06-20 14:07:32 Turingi has quit (Changing host)
 568 2012-06-20 14:07:32 Turingi has joined
 569 2012-06-20 14:07:36 TheSeven has quit (Ping timeout: 272 seconds)
 570 2012-06-20 14:07:40 <jgarzik> VPS adds an additional audit hurdle
 571 2012-06-20 14:08:30 <gmaxwell> jgarzik: yea, I'm not arguing at all with the decision, just pointing out that without authenticated connections its not the biggest hurdle.
 572 2012-06-20 14:08:39 <luke-jr> imo, if it's just another node without a wallet, it doesn't need to be secure
 573 2012-06-20 14:08:51 <jgarzik> luke-jr: hah, that's your first mistake ;-)
 574 2012-06-20 14:09:03 <sipa> peering with major sites = with their inner nodes?
 575 2012-06-20 14:09:16 <luke-jr> in fact, the point of such a hub would be to NOT be secure - ie, not do validity checks on the blocks
 576 2012-06-20 14:09:18 <jgarzik> gmaxwell: well the trusted backbone will only connect to known parties
 577 2012-06-20 14:09:30 <luke-jr> …
 578 2012-06-20 14:09:31 <jgarzik> that will, in turn, connect to a public backbone
 579 2012-06-20 14:09:40 <luke-jr> sounds like needless centralization
 580 2012-06-20 14:09:52 <gmaxwell> luke-jr: it's DOS resistance.
 581 2012-06-20 14:10:09 <luke-jr> the point of a miner hub is to relay blocks faster and be available to any miner without a formal arrangement
 582 2012-06-20 14:10:15 <jgarzik> luke-jr: I have plenty of interest from pools and exchanges.  It's no big deal if you aren't interested.
 583 2012-06-20 14:10:17 Ferroh has joined
 584 2012-06-20 14:10:19 <BlueMatt> and /very/ helpful for eg p2pool miners who want quicker connections to big pools
 585 2012-06-20 14:10:30 <jgarzik> Eligius can lag behind other pools ;p
 586 2012-06-20 14:11:13 <gmaxwell> jgarzik: right, but I'm mr. badguy and I operate or have just hacked any router on the path between the backbone and a known party. (or really any BGP speaking router in the default free zone, considering how promiscious internet backbone routing is). I can intercept these connections, and you won't be able to tell.
 587 2012-06-20 14:11:52 <SomeoneWeird> oh noes
 588 2012-06-20 14:12:07 <luke-jr> jgarzik: Eligius already peers directly with other big pools. as described, your node would just be an extra delay.
 589 2012-06-20 14:12:42 <gmaxwell> luke-jr: where you've been able to track down what you guess is their IP addresses.
 590 2012-06-20 14:13:15 <luke-jr> gmaxwell: as long as jgarzik's node requires special peering agreements, it's not much different
 591 2012-06-20 14:14:14 <luke-jr> the only difference is, the pools participating outsource that job to him personally
 592 2012-06-20 14:14:26 <BlueMatt> letting anyone connect to the main nodes would kinda ruin the whole point of being more dos-resistant.  but I do agree its important for there to be public nodes connected to the backbone
 593 2012-06-20 14:14:29 <gmaxwell> luke-jr: but he'll perhaps have better luck in getting them, because he's not a competitor.
 594 2012-06-20 14:15:21 ovidiusoft has quit (Read error: Operation timed out)
 595 2012-06-20 14:15:23 <gmaxwell> (and because it's one hub to negotiate with instead of N)
 596 2012-06-20 14:15:42 <luke-jr> BlueMatt: the problem isn't DoS, it's propagation time
 597 2012-06-20 14:15:55 TheSeven has joined
 598 2012-06-20 14:16:06 <BlueMatt> adding one layer of fast-nodes with tmpfs backing wont hurt propagation much
 599 2012-06-20 14:16:35 <BlueMatt> and if you let anyone connect, it may
 600 2012-06-20 14:16:49 <BlueMatt> (dos, generally more nodes to deal with, ...)
 601 2012-06-20 14:17:27 * Eliel wonders if it'd optimize transaction processing to keep a separate file that contains only unspent txouts to use.
 602 2012-06-20 14:18:31 <Eliel> definitely helpful for tmpfs use I think :)
 603 2012-06-20 14:18:43 <BlueMatt> would be easier to just prune blkindex and would provide most of the optimization, but sipa's working on in-memory stuff that would be even better
 604 2012-06-20 14:19:16 <Eliel> some will want to keep the whole history too... of course, you can run another node for that though.
 605 2012-06-20 14:19:48 <BlueMatt> ofc
 606 2012-06-20 14:21:03 * jgarzik definitely intends to work on fast-propagation.  Benefits the network, and increases the incentive to join the backbone.
 607 2012-06-20 14:21:08 <Eliel> just, if there was a file that contains only unspent txouts, disk caches would get a bigger hit rate. I have no idea how big effect that would have though.
 608 2012-06-20 14:21:08 TheSeven has quit (Ping timeout: 246 seconds)
 609 2012-06-20 14:21:39 <jgarzik> will of course be running latest code w/ signature caching, plus some ideas akin to luke-jr's delayed block validation
 610 2012-06-20 14:24:43 leotreasure has joined
 611 2012-06-20 14:25:24 TheSeven has joined
 612 2012-06-20 14:28:57 genjix has quit (Ping timeout: 246 seconds)
 613 2012-06-20 14:30:28 <luke-jr> jgarzik: so, how much are you charging for peering with this "backbone" that seems to have no other peers yet?
 614 2012-06-20 14:31:50 <jgarzik> luke-jr: just like in the internet world, big sites peer for free
 615 2012-06-20 14:32:45 <kinlo> in the internet world, one can measure the traffic in megabits
 616 2012-06-20 14:32:45 <luke-jr> jgarzik: that doesn't really answer the question on cost
 617 2012-06-20 14:32:57 <kinlo> how are you going to measure the size of a peer?
 618 2012-06-20 14:33:04 <kinlo> in found blocks per week?
 619 2012-06-20 14:33:46 <jgarzik> with subjective judgements.  "big" includes exchanges that produce no blocks, for example.
 620 2012-06-20 14:34:52 Apexseals has joined
 621 2012-06-20 14:35:12 <kinlo> I don't really see why exchanges benefit that much from fast block propagation, depositing coins takes like 5 confirmations, so the minute the last block propagation takes...
 622 2012-06-20 14:35:46 TheSeven has quit (Ping timeout: 260 seconds)
 623 2012-06-20 14:36:19 <gavinandresen> exchanges benefit from double-spend detection/prevention
 624 2012-06-20 14:36:39 <gavinandresen> ... and if they're peered with a good percentage of hashing power then that's good for them
 625 2012-06-20 14:36:49 datagutt has joined
 626 2012-06-20 14:36:56 TheSeven has joined
 627 2012-06-20 14:38:50 <kinlo> true
 628 2012-06-20 14:39:02 <jgarzik> it's not just fast block propagation, it's fast TX propagation too.  The hardware and software will be optimized for quick database accesses (using well known techniques like SSDs, increasing bdb cache, etc.)
 629 2012-06-20 14:39:44 <BlueMatt> s/SSDs/tmpfs/ ?
 630 2012-06-20 14:39:48 <gavinandresen> somebody should write a version of bitcoind that stores the blockchain and index in memcache.
 631 2012-06-20 14:39:52 <jgarzik> Old news to most, I imagine, but I just found a SatoshiDice clone :/  http://www.bitcoin-dice.com/
 632 2012-06-20 14:40:03 <BlueMatt> gavinandresen: sipa's working on it
 633 2012-06-20 14:40:31 <gavinandresen> cool.  Then you could write "slave" bitcoind's that read-only memcache...
 634 2012-06-20 14:40:46 <sipa> not directly, but a 100 MB database would trivially fit in memory anyway
 635 2012-06-20 14:41:09 <gavinandresen> I want the entire N gigabyte blockchain in memcached memory, so it can be served up quickly
 636 2012-06-20 14:41:12 <jgarzik> it's doable... but IMO RAM is so cheap I can just build a node that does not need to worry about hitting disk (SSD) except in rare cases of spending ancient coins
 637 2012-06-20 14:41:52 <jgarzik> or serving old blocks (an unlikely event on a trusted backbone node)
 638 2012-06-20 14:41:57 <sipa> if ultraprune works out, even ancient coins won't need to hit disk
 639 2012-06-20 14:42:03 <jgarzik> sipa: indeed
 640 2012-06-20 14:42:08 TheSeven has quit (Ping timeout: 265 seconds)
 641 2012-06-20 14:42:24 <jgarzik> though I would still prefer to store the entire block chain
 642 2012-06-20 14:42:31 <jgarzik> at least for this backbone project
 643 2012-06-20 14:42:48 <sipa> sure, i think it should
 644 2012-06-20 14:42:58 <sipa> even if just as an example
 645 2012-06-20 14:43:57 TD has joined
 646 2012-06-20 14:44:13 theorb has joined
 647 2012-06-20 14:44:19 <gmaxwell> jgarzik: the author of dice has been selling his code to anyone who wants to pony up 1100 btc.
 648 2012-06-20 14:44:30 <gmaxwell> jgarzik: I expect we'll see a few more.
 649 2012-06-20 14:44:35 <jgarzik> lovely
 650 2012-06-20 14:44:42 theorbtwo has quit (Ping timeout: 246 seconds)
 651 2012-06-20 14:44:51 <gmaxwell> though I don't think more will increase the traffic.
 652 2012-06-20 14:44:54 theorb is now known as theorbtwo
 653 2012-06-20 14:45:05 <gmaxwell> Pretty sure these things are bounded by the supply of suckers, not by the supply of sites.
 654 2012-06-20 14:45:22 <kinlo> the url you just gave might exist, but it probably won't get much traffic
 655 2012-06-20 14:45:34 <jgarzik> heh
 656 2012-06-20 14:45:45 <Graet> gmaxwell, yes
 657 2012-06-20 14:46:02 <kinlo> I think the power of satoshidice is that one can verify that they are not cheating
 658 2012-06-20 14:46:13 <gmaxwell> I also expect that the dice traffic will mostly fall off once the people running bots against it lose all their money.
 659 2012-06-20 14:46:21 <kinlo> I'd rather gamble there then somewhere else
 660 2012-06-20 14:46:33 <gmaxwell> kinlo: you can validate that on many gambling sites.
 661 2012-06-20 14:46:57 <kinlo> gmaxwell: true, but not on the bitcoin-dice.com site
 662 2012-06-20 14:47:05 <gmaxwell> kinlo: for example there is the blackjack site that uses the cryptographic proof I suggested, or even joric's mtgox code slot machine.
 663 2012-06-20 14:47:21 RainbowDashh has quit (Quit: SLEEP MODE. <@suborbital> no i filtered out RainbowDashh join quit msgs - appearantly it filtered out everything)
 664 2012-06-20 14:47:25 <sipa> gavinandresen: windows build matches; linux one doesn't
 665 2012-06-20 14:47:31 <gmaxwell> kinlo: also, dice has failed the proof test and no one cares.
 666 2012-06-20 14:47:48 <gavinandresen> sipa: that's... different....
 667 2012-06-20 14:48:00 <sipa> gavinandresen: not even bitcoind
 668 2012-06-20 14:48:03 <gmaxwell> kinlo: if someone double spends them then other customers get screwed... and this has happened, and its ~indistinguishable from the site ripping them off.
 669 2012-06-20 14:48:21 <gavinandresen> sipa:  d'oh.   Is one of the inputs different?
 670 2012-06-20 14:48:34 tyn has joined
 671 2012-06-20 14:48:36 <sipa> just pushed my sigs
 672 2012-06-20 14:49:02 <sipa> i'll upload my binaries
 673 2012-06-20 14:52:54 <gavinandresen> Release notes and my gitian-built binaries up at:  https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.3/test/
 674 2012-06-20 14:53:43 <sipa> http://bitcoin.sipa.be/builds/0.6.3rc1
 675 2012-06-20 14:54:33 <gavinandresen> sipa:  your sigs aren't in   /gitian.sigs/0.6.3rc1
 676 2012-06-20 14:54:42 moop__ has quit (Ping timeout: 265 seconds)
 677 2012-06-20 14:54:58 <gavinandresen> (they are in the rc1-win32/ directory)
 678 2012-06-20 14:55:25 TheSeven has joined
 679 2012-06-20 14:55:28 <sipa> gavinandresen: oh right; now they are
 680 2012-06-20 14:57:07 m00p has joined
 681 2012-06-20 14:57:52 TheSeven has quit (Disconnected by services)
 682 2012-06-20 14:58:01 [7] has joined
 683 2012-06-20 14:59:55 <sipa> gavinandresen: the linux binaries seem to have things in a different order
 684 2012-06-20 15:00:34 <luke-jr> my win32 matches
 685 2012-06-20 15:00:54 <luke-jr> sigs pushed
 686 2012-06-20 15:01:07 <luke-jr> we have 3 - who wants to update .org?
 687 2012-06-20 15:01:38 <gavinandresen> hold your horses, "we" need to sanity test to make sure they actually run
 688 2012-06-20 15:01:46 <luke-jr> oh right, this is rc1 :P
 689 2012-06-20 15:02:43 <gavinandresen> sipa:  there wasn't a 'randomize segments in the binary' flag added to makefile.unix between 0.6.2 and 0.6.3, was there ?
 690 2012-06-20 15:03:04 <sipa> not that i know of
 691 2012-06-20 15:03:51 <gavinandresen> Looking at the build-asserts from 0.6.2 versus 0.6.3rc1, I don't see any reason they'd differ.  I'll reboot and rebuild and see if I get the same bits.
 692 2012-06-20 15:04:29 <sipa> only changes to the makefile are BOOST_SPLITIT_THREADSAFE and sh before genbuild
 693 2012-06-20 15:04:44 [7] has quit (Ping timeout: 240 seconds)
 694 2012-06-20 15:05:01 RainbowDashh has joined
 695 2012-06-20 15:05:18 c_k has quit (Ping timeout: 248 seconds)
 696 2012-06-20 15:05:18 phungus has quit (Ping timeout: 248 seconds)
 697 2012-06-20 15:05:49 c_k has joined
 698 2012-06-20 15:06:35 phungus has joined
 699 2012-06-20 15:08:49 ovidiusoft has joined
 700 2012-06-20 15:10:05 genjix has joined
 701 2012-06-20 15:12:46 sacredchao has quit (Ping timeout: 276 seconds)
 702 2012-06-20 15:14:19 WKNiGHT has left ()
 703 2012-06-20 15:17:49 sacredchao has joined
 704 2012-06-20 15:28:18 minimoose has quit (Read error: Connection reset by peer)
 705 2012-06-20 15:28:30 minimoose has joined
 706 2012-06-20 15:34:16 <luke-jr> sipa: gavinandresen
 707 2012-06-20 15:34:22 <luke-jr> my linux build matches gavin's
 708 2012-06-20 15:36:56 <sipa> fhmm
 709 2012-06-20 15:37:42 <sipa> i'll rebuild
 710 2012-06-20 15:39:17 <gavinandresen> out doing errands for a while, back later (I'm rebuilding too, will see if I match myself....)
 711 2012-06-20 15:43:53 <gavinandresen> rebuild finished, identical binaries for me
 712 2012-06-20 15:44:23 gavinandresen has quit (Quit: gavinandresen)
 713 2012-06-20 15:47:32 D34TH has joined
 714 2012-06-20 15:49:07 Ummon has joined
 715 2012-06-20 15:50:06 t7 has quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0/20120612164001])
 716 2012-06-20 15:51:55 maaku has quit (Quit: maaku)
 717 2012-06-20 15:55:28 toffoo has joined
 718 2012-06-20 16:01:34 titeuf_87 has joined
 719 2012-06-20 16:03:46 <gribble> New news from bitcoinrss: jgarzik opened pull request 1489 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1489>
 720 2012-06-20 16:04:51 slush2 has quit (Ping timeout: 246 seconds)
 721 2012-06-20 16:07:11 <gmaxwell> jgarzik: did you see that callgrind annotated trace from createnewblock I posted? It /claims/ to be spending a signficant fraction of the total time twiddling with heap allocations for mapTestPoolTmp.
 722 2012-06-20 16:07:15 <gmaxwell> But I don't quite see why.
 723 2012-06-20 16:07:50 <luke-jr> gmaxwell: did you run it for txn_prio?
 724 2012-06-20 16:08:03 <BlueMatt> sipa: your pgp key expired
 725 2012-06-20 16:08:30 <gmaxwell> luke-jr: No. did it touch mapTestPoolTmp?
 726 2012-06-20 16:10:13 <luke-jr> gmaxwell: it significantly changes CreateNewBlock
 727 2012-06-20 16:10:54 <sipa> BlueMatt: what? again? :(
 728 2012-06-20 16:11:08 <BlueMatt> sipa: it expired in 2011, or you need to update gitian-downloader/sipa.pgp
 729 2012-06-20 16:11:32 <BlueMatt> (and push to key servers, because --update-keys isnt finding an unexpired one)
 730 2012-06-20 16:11:59 <BlueMatt> eg --refresh-keys
 731 2012-06-20 16:12:03 <BlueMatt> s/eg/eh/
 732 2012-06-20 16:14:03 <BlueMatt> hm, no it finally found the key, still needs updated in contrib/gitian-downloader/sipa.pgp
 733 2012-06-20 16:14:16 <sipa> sub  3072R/C87992E0  created: 2011-09-23  expires: 2014-09-22  usage: S
 734 2012-06-20 16:14:17 <sipa> sub  3072R/8E3FE6F9  created: 2012-03-16  expires: 2017-03-15  usage: E
 735 2012-06-20 16:15:30 <luke-jr> oh right, we store the actual keys in git
 736 2012-06-20 16:15:51 <BlueMatt> sipa: please dont push sigs to gitian.sigs if they dont match, it freaks gverify out
 737 2012-06-20 16:16:00 <sipa> BlueMatt: ok
 738 2012-06-20 16:16:22 <BlueMatt> ;;later tell devrandom any chance we could get gverify to figure out the number of matching sigs and not freak out if it finds one sig that doesnt match?
 739 2012-06-20 16:16:23 <gribble> The operation succeeded.
 740 2012-06-20 16:17:35 <sipa> BlueMatt: i think that'd be nice; for example when you are the first two pushers, and you don't know yet which one seems to be the 'faulty' one
 741 2012-06-20 16:18:12 <BlueMatt> agreed, and btw pushed my sigs for 0.6.3rc1, which matched gavin's
 742 2012-06-20 16:18:27 <sipa> updated my GPG key
 743 2012-06-20 16:18:57 <gmaxwell> I think it's good to push non-matching ones out because it lets people watching know that there is a problem. When the downloader is something people use it should absolutely hold off doing anything in that case.
 744 2012-06-20 16:19:31 <sipa> same binaries here after rebuild
 745 2012-06-20 16:19:43 <BlueMatt> gmaxwell: downloader doesnt read gitian.sigs, it expects sigs to be in the zip that you download with binaries
 746 2012-06-20 16:20:20 <TD> good evening
 747 2012-06-20 16:20:32 <BlueMatt> hello TD
 748 2012-06-20 16:20:51 <luke-jr> BlueMatt: how does it work with the Windows installer then?
 749 2012-06-20 16:21:04 <BlueMatt> luke-jr: ???
 750 2012-06-20 16:22:57 <BlueMatt> installer doesnt do anything with gitian, it just installs bitcoin.  updater downloads a zip with pgp keys, sigs, and binaries, then checks the pgp keys against its list of signers, checks the sigs, and installs
 751 2012-06-20 16:23:24 ovidiusoft has quit (Ping timeout: 246 seconds)
 752 2012-06-20 16:24:02 <luke-jr> BlueMatt: but updater should never bypass the system package management
 753 2012-06-20 16:24:03 <gribble> New news from bitcoinrss: luke-jr opened pull request 1490 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1490>
 754 2012-06-20 16:24:24 <BlueMatt> luke-jr: windows doesnt have package management, thats why gitian-updater in bitcoin-qt isnt implemented for non-windows
 755 2012-06-20 16:24:58 leotreasure has quit (Quit: leotreasure)
 756 2012-06-20 16:25:02 <luke-jr> BlueMatt: it does, it just sucks
 757 2012-06-20 16:25:27 <BlueMatt> you mean the uninstall dialog crap? meh, it may have an incorrect version, but oh well
 758 2012-06-20 16:25:33 <luke-jr> …
 759 2012-06-20 16:25:55 <BlueMatt> would be nice to update the version in registry, but it doesnt currently
 760 2012-06-20 16:26:40 <luke-jr> imo, it should download the installer, verify that, and use it :p
 761 2012-06-20 16:26:58 <luke-jr> (when it was installed from installer only… sigh)
 762 2012-06-20 16:27:37 <BlueMatt> does nsis have an unattended install option?
 763 2012-06-20 16:27:55 <sipa> why does it need that?
 764 2012-06-20 16:28:23 <BlueMatt> updating and forcing users through the install dialog again would be kinda...ugly
 765 2012-06-20 16:28:36 <sipa> that's only reasonable way, imho
 766 2012-06-20 16:28:49 <BlueMatt> sipa: I know no other app that does that
 767 2012-06-20 16:28:52 <sipa> ?
 768 2012-06-20 16:29:00 <sipa> when i used windows, they all did :)
 769 2012-06-20 16:29:03 <luke-jr> ^
 770 2012-06-20 16:29:09 <BlueMatt> sipa: afaik the standard on win32 is to show an upgrade dialog, if the user hits yes, show a progress bar and restart the app
 771 2012-06-20 16:29:16 <BlueMatt> no next, next, accept, next crap
 772 2012-06-20 16:29:37 <luke-jr> anyhow, I think NSIS does have an autoinstall mode of some form
 773 2012-06-20 16:29:40 <sipa> well then make an installer that doesn't require a next next accept next
 774 2012-06-20 16:29:52 <BlueMatt> sipa: thats my point (unattended install option)
 775 2012-06-20 16:29:53 <sipa> maybe optionally
 776 2012-06-20 16:30:16 <BlueMatt> sipa: would have to be
 777 2012-06-20 16:30:50 t7 has joined
 778 2012-06-20 16:30:54 itwasntme has joined
 779 2012-06-20 16:31:06 itwasntme has left ()
 780 2012-06-20 16:31:14 <BlueMatt> anyway, Ill look at tweaking gitian-updater to have a post-install command, make the only required file in gitian-win32 the installer and look into it when I get around to redoing auto-update
 781 2012-06-20 16:41:34 smtmnyz has quit (Ping timeout: 245 seconds)
 782 2012-06-20 16:42:41 smtmnyz has joined
 783 2012-06-20 16:42:55 tyn has quit (Ping timeout: 245 seconds)
 784 2012-06-20 16:45:55 gavinandresen has joined
 785 2012-06-20 16:48:56 <luke-jr> wb gavinandresen
 786 2012-06-20 16:54:11 Diablo-D3 has joined
 787 2012-06-20 16:56:43 <jgarzik> gmaxwell: interesting
 788 2012-06-20 16:57:02 <gavinandresen> luke-jr : why is https://github.com/bitcoin/bitcoin/compare/0.6.2...0.6.3    such a mess?
 789 2012-06-20 16:57:11 minimoose_ has joined
 790 2012-06-20 16:57:17 <jgarzik> gmaxwell: I wonder if it's this line: swap(mapTestPool, mapTestPoolTmp)
 791 2012-06-20 16:57:53 <jgarzik> gmaxwell: it does that swap on each iteration (for each tx in priority map)
 792 2012-06-20 16:59:06 <BlueMatt> gavinandresen: because 0.6.3 has all of the stable commits that luke did over the years, whereas 0.6.2 doesnt?
 793 2012-06-20 16:59:38 <gavinandresen> is there a way to make it less messy in the future?  I want to give people an easy way to see the diffs between 0.6.2 and 0.6.3
 794 2012-06-20 17:00:43 minimoose has quit (Ping timeout: 246 seconds)
 795 2012-06-20 17:00:44 minimoose_ is now known as minimoose
 796 2012-06-20 17:01:20 <luke-jr> gavinandresen: I think part of it is the splitoff branches for 0.6.2 and 0.6.3
 797 2012-06-20 17:01:44 <BlueMatt> luke-jr: there are a ton of like "Bump version to 0.4.5" in there
 798 2012-06-20 17:01:53 TD has quit (Quit: TD)
 799 2012-06-20 17:02:02 <luke-jr> BlueMatt: yes, but those can mostly be filtered out easily otherwise
 800 2012-06-20 17:02:09 <gavinandresen> If anybody has better git-fu than me, suggestions welcome for improving the process.
 801 2012-06-20 17:02:16 GTRsdk-work has quit (Quit: Lost terminal)
 802 2012-06-20 17:02:57 <BlueMatt> gavinandresen: there is a command, but I dont think you can get to it from github, and I dont remember the proper invocation...
 803 2012-06-20 17:03:12 <BlueMatt> luke-jr: will they are part of the "diff" in any case
 804 2012-06-20 17:03:13 <luke-jr> git log --no-merges 65077e1..origin/0.6.3 will do changes between 0.6.1 and 0.6.3
 805 2012-06-20 17:03:28 <luke-jr> 0.6.2 had fairly few, so those can be removed easily
 806 2012-06-20 17:03:34 RainbowDashh has quit (Quit: SLEEP MODE. <@suborbital> no i filtered out RainbowDashh join quit msgs - appearantly it filtered out everything)
 807 2012-06-20 17:03:46 <luke-jr> BlueMatt: not really
 808 2012-06-20 17:04:03 <BlueMatt> they arent actually different but they are a part of the list of commits different
 809 2012-06-20 17:04:29 m00p has quit (Quit: Leaving)
 810 2012-06-20 17:05:14 <BlueMatt> gavinandresen: git diff-tree -u v0.6.2 v0.6.3rc1 does the actual diff, though not the commit list
 811 2012-06-20 17:05:48 <gavinandresen> yes, git diff does the right thing, I'd just like to give people a github URL that clearly shows what changed
 812 2012-06-20 17:07:07 <gavinandresen> I posted a "help sanity test" request to https://bitcointalk.org/index.php?topic=88734.0
 813 2012-06-20 17:07:12 RainbowDashh has joined
 814 2012-06-20 17:07:56 m00p has joined
 815 2012-06-20 17:08:40 maaku has joined
 816 2012-06-20 17:09:01 RainbowDashh has quit (Read error: Connection reset by peer)
 817 2012-06-20 17:12:22 <gavinandresen> sipa: I want to pick your brain about the signrawtx API when you have a few minutes
 818 2012-06-20 17:12:38 RainbowDashh has joined
 819 2012-06-20 17:22:06 osmosis has joined
 820 2012-06-20 17:22:07 RainbowDashh has quit (Ping timeout: 265 seconds)
 821 2012-06-20 17:24:07 RainbowDashh has joined
 822 2012-06-20 17:25:03 <luke-jr> sipa: What is this doing? 839c4e7 Fix initialization of inaddr_any
 823 2012-06-20 17:25:18 RainbowDashh has quit (Client Quit)
 824 2012-06-20 17:27:03 tyn has joined
 825 2012-06-20 17:27:52 Hasbro has quit ()
 826 2012-06-20 17:29:58 RainbowDashh has joined
 827 2012-06-20 17:31:35 erle- has quit (Quit: erle-)
 828 2012-06-20 17:31:42 erle- has joined
 829 2012-06-20 17:33:13 erle- has quit (Client Quit)
 830 2012-06-20 17:33:19 erle- has joined
 831 2012-06-20 17:35:00 genjix has quit (Read error: Operation timed out)
 832 2012-06-20 17:41:58 denisx has joined
 833 2012-06-20 17:44:14 <sipa> luke-jr: iirc that's a bugfix, but not at a computer right now
 834 2012-06-20 17:44:37 <sipa> gavinandresen: i'll be back in 2-3 hours
 835 2012-06-20 17:45:08 <gavinandresen> sipa: ack
 836 2012-06-20 17:46:17 PK has joined
 837 2012-06-20 17:49:30 maqr has quit (Ping timeout: 246 seconds)
 838 2012-06-20 17:53:58 TD has joined
 839 2012-06-20 17:55:15 jurov is now known as away!aktooj@84.245.71.31|jurov
 840 2012-06-20 17:55:20 sdsf has joined
 841 2012-06-20 17:57:01 toffoo has quit ()
 842 2012-06-20 18:04:23 root2 has joined
 843 2012-06-20 18:06:58 rdponticelli has quit (Ping timeout: 276 seconds)
 844 2012-06-20 18:09:31 drizztbsd has quit (Quit: Konversation terminated!)
 845 2012-06-20 18:10:11 faraday__ has joined
 846 2012-06-20 18:14:00 Clipse has quit (Ping timeout: 246 seconds)
 847 2012-06-20 18:20:41 <gribble> New news from bitcoinrss: darsie opened issue 1491 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1491>
 848 2012-06-20 18:21:08 l1l1ll11l1 has quit (Read error: Connection reset by peer)
 849 2012-06-20 18:28:41 erle- has quit (Quit: erle-)
 850 2012-06-20 18:29:03 sdsf has quit (Ping timeout: 245 seconds)
 851 2012-06-20 18:29:36 erle- has joined
 852 2012-06-20 18:31:44 nameless has quit (!~root@weowntheinter.net|Ping timeout: 250 seconds)
 853 2012-06-20 18:35:55 nameless has joined
 854 2012-06-20 18:44:31 Clipse has joined
 855 2012-06-20 18:45:20 maqr has joined
 856 2012-06-20 18:52:15 ivan\ has quit (Quit: ERC Version 5.3 (IRC client for Emacs))
 857 2012-06-20 18:52:24 <luke-jr> gavinandresen: 0.6.3rc1 for Mac?
 858 2012-06-20 18:52:37 <gavinandresen> luke-jr: right!  thanks for reminding me
 859 2012-06-20 18:54:21 tower has quit (Disconnected by services)
 860 2012-06-20 18:54:40 tower has joined
 861 2012-06-20 18:55:29 <gavinandresen> d'oh, macdeployqtplus is unhappy
 862 2012-06-20 18:55:41 <luke-jr> >_<
 863 2012-06-20 19:01:01 justmoon has quit (Read error: Connection reset by peer)
 864 2012-06-20 19:01:14 <gribble> New news from bitcoinrss: gavinandresen opened issue 1492 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1492>
 865 2012-06-20 19:06:30 RainbowDashh has quit (Read error: Connection reset by peer)
 866 2012-06-20 19:09:26 ivan\ has joined
 867 2012-06-20 19:11:07 Smoovious has quit (Ping timeout: 260 seconds)
 868 2012-06-20 19:11:46 Smoovious has joined
 869 2012-06-20 19:17:46 egecko has joined
 870 2012-06-20 19:23:26 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
 871 2012-06-20 19:24:36 RazielZ has quit (Ping timeout: 250 seconds)
 872 2012-06-20 19:25:14 dw has left ()
 873 2012-06-20 19:30:23 datagutt has quit (Quit: Computer has gone to sleep.)
 874 2012-06-20 19:30:57 RazielZ has joined
 875 2012-06-20 19:31:47 m00p has quit (Remote host closed the connection)
 876 2012-06-20 19:36:50 p0s has joined
 877 2012-06-20 19:41:18 minimoose_ has joined
 878 2012-06-20 19:42:49 <sipa> gavinandresen: back
 879 2012-06-20 19:43:28 Backburn_p has joined
 880 2012-06-20 19:44:17 <gavinandresen> sipa: cool.  So, signrawtx has a third param in case you want to create chains of transactions that aren't yet in the blockchain/memorypool
 881 2012-06-20 19:44:26 Backburn has quit (Ping timeout: 260 seconds)
 882 2012-06-20 19:44:29 <sipa> gavinandresen: i noticed
 883 2012-06-20 19:44:33 <gavinandresen> As currently implemented, that third param is just an array of serialized parent transactions
 884 2012-06-20 19:44:49 <sipa> oh wait; no, i saw you adding a list of secret keys
 885 2012-06-20 19:44:50 <gavinandresen> I'm wondering if it would be better to make it an array of [txid,nout,scriptPubKey]
 886 2012-06-20 19:45:10 <gavinandresen> (I may be misremembering third param versus second)(
 887 2012-06-20 19:45:10 minimoose has quit (Ping timeout: 245 seconds)
 888 2012-06-20 19:45:10 minimoose_ is now known as minimoose
 889 2012-06-20 19:45:45 <sipa> well, txid/nout/scriptPubKey is all you need, the full transaction is overkill
 890 2012-06-20 19:46:23 ghjghj has joined
 891 2012-06-20 19:46:29 <gavinandresen> yup.  If I make that change, it ripples through a couple of other RPC calls-- e.g. listunspent should return [txid, nout, scriptPubKey, nConfirmations]  (I think)
 892 2012-06-20 19:47:21 ghjghj has left ()
 893 2012-06-20 19:47:23 <Eliel> no amounts?
 894 2012-06-20 19:47:43 <sipa> technically, you don't need those
 895 2012-06-20 19:47:47 <gavinandresen> inputs are always completely spent....
 896 2012-06-20 19:48:04 <sipa> but the transaction may be invalid if you fail to provide enough worth of inputs
 897 2012-06-20 19:49:38 <gavinandresen> I think I've convinced myself, [txid,n,hex_script_pubkey] is the right thing to do.
 898 2012-06-20 19:49:52 [Tycho] has quit (Read error: Connection reset by peer)
 899 2012-06-20 19:50:22 <sipa> Yes, I like that better as well.
 900 2012-06-20 19:50:38 <sipa> more transparent, at least
 901 2012-06-20 19:50:46 <gavinandresen> To me that implies the default for reporting txOuts for gettransaction should be hex_script_pubkey.  Which brings up the whole 'decompositions' feature, which I don't like
 902 2012-06-20 19:52:54 <gavinandresen> luke-jr : how upset will you be if I rip out the "decompositions" code ?   What is the use case for gettransaction with "please decompile the scripts into human-readable output" ?
 903 2012-06-20 19:53:35 <gavinandresen> (the RPC interface is meant to be great for machines, not humans)
 904 2012-06-20 19:53:42 dvide_ has quit ()
 905 2012-06-20 19:56:01 dvide has joined
 906 2012-06-20 19:58:55 <gmaxwell> gavinandresen: because humans use it to— and we do actually want power users learning the system better and becoming more powerful power users.
 907 2012-06-20 19:59:40 <jgarzik> gavinandresen: historically speaking, people liked my getblock patch (dumped all fields and all tx's, including scripts) because it was readable -and- computer parseable back into useable form
 908 2012-06-20 19:59:42 <gavinandresen> gmaxwell: meh.  blockchain.info/blockexplorer.com ....
 909 2012-06-20 19:59:49 <gmaxwell> Its a feature that I now personally use while diagnosing transactions and such.
 910 2012-06-20 19:59:59 <jgarzik> gavinandresen: but it was unconditionally decoded.  none of this "choose your own adventure" 12 types of decomposition
 911 2012-06-20 20:00:02 <gmaxwell> Which are often unreliable/slow/unavailable.
 912 2012-06-20 20:00:40 <gmaxwell> yea, I don't really care about the choose your own adventure crap, I only found it tolerable because both raw and human readable had usecases.
 913 2012-06-20 20:00:46 <sipa> jgarzik: i have no idea what you're trying to say
 914 2012-06-20 20:00:50 <gavinandresen> A decodetransaction / decodescript RPC call that takes hex-encoded crap and spits out human-readable JSON would be fine with me.
 915 2012-06-20 20:01:45 <gavinandresen> Those would work better with the 'raw transaction' rpc calls, because they deal entirely with hex-encoded serialized strings.
 916 2012-06-20 20:02:41 <sipa> and they would be a nice example of an RPC that doesn't need cs_main or cs_wallet :)
 917 2012-06-20 20:02:43 dvide is now known as dvide_
 918 2012-06-20 20:02:51 <gmaxwell> That sounds okay to me. Being able to decode a hex encoded transaction is important before you sign the thing.
 919 2012-06-20 20:03:45 <gmaxwell> It's a little less elegant from the CLI usage perspective than getting it directly through the decomp, but I think thats OKAY— as you say the primary target audience of the rpc is machines.
 920 2012-06-20 20:03:45 tyn has quit (Ping timeout: 245 seconds)
 921 2012-06-20 20:04:18 <sipa> It does extend the usefulness of decomposition to all transactions, not just those that can be seen through getblock or gettransaction
 922 2012-06-20 20:04:28 <jgarzik> true
 923 2012-06-20 20:05:05 <gavinandresen> OK, my TODO is:  replace the 'decompositions' stuff with decode RPC call or calls.  And modify the rawtransaction API to deal with prior inputs as [txid, n, scriptPubKey]  (might mean some refactoring of the transaction creation code, too....)
 924 2012-06-20 20:05:15 <sipa> i'm sure luke's response will be that a getblock that can decompose the transactions can save hundreds of rpc calls
 925 2012-06-20 20:05:17 <jgarzik> gavinandresen: ACK
 926 2012-06-20 20:05:40 <jgarzik> sipa: RPC is helpfully multi-threaded now... :)
 927 2012-06-20 20:06:06 <gavinandresen> ... then we should teach the RPC code to speak JSON-RPC-2.0 and take an array of commands to execute.... (I actually wrote that code a while ago, it's not hard)
 928 2012-06-20 20:06:21 <gmaxwell> sipa: no reason that a decodetransaction couldn't take 100 transactions as arugments, though there would be more (de)serialization overhead.
 929 2012-06-20 20:06:43 <jgarzik> sipa: original getblock dumped -everything- in a single call, which was useful for debugging.  Mind you, I'm NOT arguing for that now...  just noting.
 930 2012-06-20 20:06:49 <jgarzik> I think theymos still uses my getblock patch
 931 2012-06-20 20:06:52 <sipa> i think that
 932 2012-06-20 20:06:53 * helo tries to read that as dodecatransaction
 933 2012-06-20 20:06:58 <gmaxwell> but realistically if you're asking for 100 things, you're able to do the darn decoding yourself.
 934 2012-06-20 20:07:30 <gmaxwell> helo: 12 simultaneous outputs in one transaction confirmation!
 935 2012-06-20 20:08:07 <gavinandresen> While I've got your attention:  "Reworking Bitcoin Transaction Fees"  :  https://gist.github.com/2961409
 936 2012-06-20 20:08:46 dvide_ is now known as dvide
 937 2012-06-20 20:08:54 saieko has quit (Ping timeout: 248 seconds)
 938 2012-06-20 20:09:34 wereHamster has quit (Quit: Lost terminal)
 939 2012-06-20 20:10:26 saieko has joined
 940 2012-06-20 20:13:21 <gmaxwell> gavinandresen: "meh". I full expect anyone to look at that and set the first option as high as they can. Because they'll mentally visualize missing out on a mysterious 100 BTC fee transaction otherwise.
 941 2012-06-20 20:13:23 tyn has joined
 942 2012-06-20 20:14:11 <gavinandresen> gmaxwell: hmm?   100 BTC fee would get sorted to the very top of the to-be-included list
 943 2012-06-20 20:14:40 Zarutian has quit (Quit: Zarutian)
 944 2012-06-20 20:14:45 <gmaxwell> "But there might be 4000 100 BTC transactions!"  The key is that you don't know how big the excluded transaction will be.
 945 2012-06-20 20:15:06 <gmaxwell> This is something that stresses senders out about fee rules. They worry that the fees might be enormous on some transaction and so they'd rather send none at all.
 946 2012-06-20 20:15:47 <gmaxwell> Perhaps instead "BTC amount of lost fees which you're willing to tolerate in order to support free txn" ?
 947 2012-06-20 20:16:17 <helo> 'receiver pays fees model' -- neat
 948 2012-06-20 20:16:24 <gavinandresen> Huh?  Paid would always overrule free.  So if you set the "paid" space to 1MB and the free space to 100K and there WERE 1MB of paid transactions there wouldn't be room for any free ones.
 949 2012-06-20 20:16:25 <gmaxwell> e.g. sum up the list of txn over the minimum fee from the _bottom_.
 950 2012-06-20 20:16:57 <gmaxwell> gavinandresen: thats what I'm saying. I'm saying your proposal strongly encourages people to set that to 1MB because they can't reason about how much they'll be losing except retrospectively.
 951 2012-06-20 20:17:16 <gavinandresen> I don't have a problem with that.
 952 2012-06-20 20:17:54 <gavinandresen> I expect SOME people will decide that a little priority-based space is a good idea, so free transactions will eventually be confirmed
 953 2012-06-20 20:18:06 <gmaxwell> I'm suggesting you can solve this by doing the test another way and have much more use of it.
 954 2012-06-20 20:18:36 <gavinandresen> I still don't understand.  Either miners will want to be greedy and take as many fee-paying transactions as possible, or they won't.
 955 2012-06-20 20:19:08 <gmaxwell> Instead, 'Minimum transaction fee-per-kilobyte to be considered "paid"'  'Maximum amount sum fee you're willing to miss out on to process free txn'
 956 2012-06-20 20:19:24 <gavinandresen> why wouldn't the greedy miners just set that to zero?
 957 2012-06-20 20:20:14 <gmaxwell> They will, the issue isn't greed its that your proposal says you can either be generous and take potentially unbounded losses, or you can be a scrooge.
 958 2012-06-20 20:20:57 <helo> might as well make the default to include all transactions with fees that will fit (sorted increasing), with an option to include free transactions if there is room?
 959 2012-06-20 20:20:59 <gavinandresen> minimum-fee-per-kb times kb-of-free-transactions gives that bound
 960 2012-06-20 20:21:11 <helo> *decreasing
 961 2012-06-20 20:22:00 <gmaxwell> gavinandresen: No it doesn't, Say the mempool has 1MB of 100 BTC fee transactions. .. every free txn you take costs you 100 BTC.
 962 2012-06-20 20:22:19 wereHamster has joined
 963 2012-06-20 20:23:08 <gmaxwell> I've seen this same reasoning play out with people on the sending side of fees. People running webservices being VERY anxious about paying any fees at all because they're worried they'll come back and find out they are in the red.  Even though its quite unlikely that the automatic fees will be large.
 964 2012-06-20 20:23:10 <helo> default behavior of "make money please", so every wiki guide to setting up a miner doesn't start with "turn off free transactions"
 965 2012-06-20 20:23:15 <gavinandresen> Ok, I propose that greedy self-interested miners set the params as:  1MB of paid transactions.  100K-max of free transactions.  "free" if paying less than 0.001 BTC/kb.
 966 2012-06-20 20:23:25 maqr has quit (Read error: No route to host)
 967 2012-06-20 20:23:47 <gavinandresen> They'll never lose more than 100K*0.001 BTC of potentially fee-paying transactions, but will include "free" transactions if there is room.
 968 2012-06-20 20:24:23 <Diablo-D3> gavinandresen: what, enforced globally?
 969 2012-06-20 20:24:24 <gmaxwell> hm. I must be misunderstanding you. Not sure where.
 970 2012-06-20 20:24:30 <Diablo-D3> or can individual nodes still do whatever?
 971 2012-06-20 20:24:44 <gmaxwell> oh yes, in that case they would.
 972 2012-06-20 20:24:48 <gavinandresen> I'm talking default, out-of-the-box rules.  (and pulling numbers outta my ass)
 973 2012-06-20 20:24:59 <Diablo-D3> gavinandresen: I'd do it this way
 974 2012-06-20 20:25:17 <sipa> Diablo-D3: read https://gist.github.com/2961409 first
 975 2012-06-20 20:25:18 <Diablo-D3> 4mb max, paid or unpaid, but DONT do it by fee per kb
 976 2012-06-20 20:25:31 <Diablo-D3> do it fee per kb already used in the blocj
 977 2012-06-20 20:25:33 <gmaxwell> Well the out of box rules should be reasonably altruistic ones.
 978 2012-06-20 20:25:33 <sipa> we can't change the max block size without hardfork
 979 2012-06-20 20:25:41 hahuang65 has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
 980 2012-06-20 20:25:42 <Diablo-D3> oh, max is still 1?
 981 2012-06-20 20:25:45 <sipa> yes
 982 2012-06-20 20:25:52 <Diablo-D3> okay, then pretend I said one
 983 2012-06-20 20:26:01 <gavinandresen> Increasing the block size (or not) is a separate issue
 984 2012-06-20 20:26:10 <gavinandresen> (that I don't want to talk about right now)
 985 2012-06-20 20:26:16 <Diablo-D3> sort all possible tx by fee per kb, and just start with the cheapest ones and ramp up the fee as you fill the block
 986 2012-06-20 20:26:43 <Diablo-D3> so, if you have, like, room for 10 tx in our fictional micro-block example chain
 987 2012-06-20 20:26:44 <gmaxwell> gavinandresen: I don't expect anyone to set that 1MB number to anything smaller.  Which then also means you'll get weird outcomes like processing 0.0001 transaction spam over high priority free txn.
 988 2012-06-20 20:27:15 <gmaxwell> Which I don't think even fairly greedy miners want.
 989 2012-06-20 20:27:15 <Diablo-D3> 0% fee, 10% fee, 20% fee, 30% fee, etc
 990 2012-06-20 20:27:20 <gribble> New news from bitcoinrss: jgarzik opened pull request 1493 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1493>
 991 2012-06-20 20:27:35 <gavinandresen> gmaxwell: set the "free" threshold to something reasonable and The Right THing happens
 992 2012-06-20 20:27:36 <Diablo-D3> so only large blocks require extra high fees
 993 2012-06-20 20:27:41 <gmaxwell> or basically, the minimum-which-is-considered-a-fee doesn't actually encapsulate the priority vs fee tradeoff.
 994 2012-06-20 20:28:13 <Diablo-D3> my idea would end up making priority queues
 995 2012-06-20 20:28:32 <Diablo-D3> low priority transactions would get, say, 10% of a block (assuming we have 10 priority queues)
 996 2012-06-20 20:28:42 <gavinandresen> gmaxwell: I'm not following.  If a miner set:  1MB paid.  100K free.  "free" threshold 0.001 BTC then it seems to me all the right things happen.
 997 2012-06-20 20:28:57 <Diablo-D3> high priority transactions would pay ten times more fees per kb but almost always get into a block
 998 2012-06-20 20:29:19 <Diablo-D3> yes/no?
 999 2012-06-20 20:30:20 <gavinandresen> Diablo-D3: I don't see how a user or their software would figure out what fee to pay to know whether or not they have a good chance of getting into the next block or two.
1000 2012-06-20 20:30:32 <Diablo-D3> gavinandresen: make a gui that lists priority
1001 2012-06-20 20:30:47 <Diablo-D3> gavinandresen: low medium high guaranteed
1002 2012-06-20 20:31:02 <Diablo-D3> you pay the fee no matter what even if you would have gotten into a free slot because of low contention
1003 2012-06-20 20:31:05 <gmaxwell> gavinandresen: at 0.001/block the miner potentially walks on 4BTC in fees. So I think people would set it lower than that. With it set lower than that, its cheap to crowd all the free txn out of a block just for burn-the-world purposes.
1004 2012-06-20 20:31:43 <Diablo-D3> default rules could split the blocks into 4, 250kb free, 250kb low, 250kb medium, 250kb high
1005 2012-06-20 20:32:06 <gavinandresen> Huh?  0.001 BTC/k times 100K free-transaction-space would be losing out on 0.1 BTC
1006 2012-06-20 20:32:22 <Diablo-D3> high can spill over into medium, medium into low, low into free, but not the reverse
1007 2012-06-20 20:33:08 <gavinandresen> Diablo-D3: I think you're overcomplicating it.  All most users care about is "fast" or "free"
1008 2012-06-20 20:33:46 <gmaxwell> gavinandresen: say there are 4000 very very low priority transactions in the queue with 0.001 fees. And enough high priority zero fee transactions above them to completely keep the fees out of the block. You'd lose out on 4BTC. (assuming a maximum 4k txn in a block, which is vaguely right)
1009 2012-06-20 20:34:26 <Diablo-D3> gavinandresen: well
1010 2012-06-20 20:34:35 <Diablo-D3> its currently wrong to have a value in the prefs like it does now
1011 2012-06-20 20:34:57 <Diablo-D3> gmaxwell: thats vs my example? doesnt work
1012 2012-06-20 20:34:58 <gavinandresen> gmaxwell: ah, right, I sit corrected.
1013 2012-06-20 20:35:01 <Diablo-D3> because priority is fees.
1014 2012-06-20 20:35:08 <Diablo-D3> the more fee you pay, the higher priority you are
1015 2012-06-20 20:36:00 <sipa> sure, i'd rather include a 1 MB transaction that pays 0.1 BTC than 1000 1 kB transactions that pay 0.01 each
1016 2012-06-20 20:36:24 <gavinandresen> gmaxwell: that scenario seems pretty far-fetched, though.
1017 2012-06-20 20:36:28 <gmaxwell> gavinandresen: thats why I was suggesting an alternative of "how much are you willing to lose per block to support free txn"  even if you set that to zero you'd still process some because there still would be some fee floor under which you would consider feed transactions free.
1018 2012-06-20 20:36:38 <Diablo-D3> sipa: its per kb though
1019 2012-06-20 20:36:54 <gmaxwell> gavinandresen: it absolutely is, I'm not suggesting that its likely. I'm saying that the possibility will encourage irrational settings because people are anxious about 'losing money'.
1020 2012-06-20 20:37:40 <Diablo-D3> so 1mb that pays 0.1 btc is a hundred times less than 1000kb of 0.01 each
1021 2012-06-20 20:38:16 <Diablo-D3> so I dunno
1022 2012-06-20 20:38:19 <Diablo-D3> maybe Im overcomplicating it
1023 2012-06-20 20:38:26 <Diablo-D3> just sort all tx by fee/kb
1024 2012-06-20 20:38:42 <Diablo-D3> and allow 100% free blocks by default
1025 2012-06-20 20:38:45 <gavinandresen> I really like the simplicity of "this chunk of the block is reserved for fee-paying transactions.  I'll take them in order of fees paid."   And "if there's any space leftover, I'll take this many other transactions, sorted by priority."
1026 2012-06-20 20:38:54 <Diablo-D3> gavinandresen: I dont
1027 2012-06-20 20:39:03 <Diablo-D3> because it doesnt lead to people trying to outbid people for the space
1028 2012-06-20 20:39:04 <gavinandresen> Adding fees-paid to the priority calculation might be a good idea.
1029 2012-06-20 20:39:19 <Diablo-D3> so having a priority that is ONLY fee/kb seems to be the best bet
1030 2012-06-20 20:39:20 <Diablo-D3> its what we want
1031 2012-06-20 20:39:23 <gavinandresen> Diablo-D3: huh?  sure it does, the fee-paying space is up for bid
1032 2012-06-20 20:39:34 <Diablo-D3> gavinandresen: yes, but why isnt ALL the space up for bid?
1033 2012-06-20 20:39:40 <Diablo-D3> why is any of it avail for free only?
1034 2012-06-20 20:39:48 <Diablo-D3> the market itself should set the price
1035 2012-06-20 20:39:58 <Diablo-D3> if everyone doesnt want to pay, then we have zero fee blocks
1036 2012-06-20 20:40:03 <gavinandresen> Diablo-D3: could be, set max kilobytes of fee-paying transactions to 1Meg
1037 2012-06-20 20:40:03 <gmaxwell> gavinandresen: I'm not suggesting anything much more complicated: "The block is filled wiht fee paying transactions in order of fees, but I'll replace the X BTC lowest fee transactions with transactions ordered by priority instead"
1038 2012-06-20 20:40:07 <Diablo-D3> if everyone wants to pay exorbant costs, then we have high fee blocks
1039 2012-06-20 20:40:12 <gmaxwell> s/wiht/with/
1040 2012-06-20 20:40:19 <Diablo-D3> gavinandresen: yeah but we're arguing defaults
1041 2012-06-20 20:40:34 <gavinandresen> gmaxwell: ok, got it.  I like that.
1042 2012-06-20 20:40:37 <Diablo-D3> I personally can do whatever I want
1043 2012-06-20 20:40:46 <Diablo-D3> such as ripping out all the priority code and sort by fee/kb.
1044 2012-06-20 20:40:50 <gmaxwell> (and that with same augmentation that fees under some value are taken to be zero for the calculation)
1045 2012-06-20 20:41:06 <Diablo-D3> we shouldnt sort by things like age of inputs or total amount or anything
1046 2012-06-20 20:41:10 <gavinandresen> Diablo-D3: the "knobs" i'm proposing would allow you to do exactly that
1047 2012-06-20 20:41:18 <Diablo-D3> make everyone pay per kb since thats what our most expensive thing
1048 2012-06-20 20:41:23 <Diablo-D3> nothing costs more than the kb.
1049 2012-06-20 20:41:45 <Diablo-D3> even computation time means nothing now
1050 2012-06-20 20:41:49 <gmaxwell> gavinandresen: WRT dust spam, we need fixes in the coin selection code if you want to remove that. Right now we have a dos vulnerability — litecoin has a crazy kludge to fix it.
1051 2012-06-20 20:41:57 <gavinandresen> Diablo-D3: ... you still need a minimum fee to be considered 'paying' to avoid an asshat filling up blocks with spam
1052 2012-06-20 20:41:58 <Diablo-D3> its growing a thousand times faster than our harddrive space is
1053 2012-06-20 20:42:02 <Diablo-D3> gavinandresen: no
1054 2012-06-20 20:42:17 <Diablo-D3> gavinandresen: because if I sort by fee/kb, most blocks will have NO free tx in them eventually
1055 2012-06-20 20:42:42 <gavinandresen> sigh.  I attach a 1-satoshi fee to my spam and your sort now happily includes them....
1056 2012-06-20 20:42:51 <Diablo-D3> thats not what I meant.
1057 2012-06-20 20:42:58 <Diablo-D3> ifs not free vs not free
1058 2012-06-20 20:43:04 <Diablo-D3> its a linear scale of how much you want to pay
1059 2012-06-20 20:43:09 <Diablo-D3> with no minimum or maximum
1060 2012-06-20 20:43:16 <gmaxwell> gavinandresen: is there a way we can express the "minimum fee to be considered non zero" which won't result in fair numbers of people ignorantly setting it to 0?
1061 2012-06-20 20:43:35 <Diablo-D3> so if everyone pays 0.01btc per kb except the spammer, and we max the blocks out every single time with 0.01btc per kb tx, then the spammer cant spam
1062 2012-06-20 20:44:01 <Diablo-D3> or at least, if he wants to spam, then he pays 0,01 btc per kb like everyone else
1063 2012-06-20 20:44:07 <Diablo-D3> which then the market goes to 0.02btc per kb
1064 2012-06-20 20:44:07 <gavinandresen> gmaxwell: good question-- that's the downside of letting people twiddle the knobs, they might be idiots
1065 2012-06-20 20:44:22 <gmaxwell> gavinandresen: maybe express it as a fraction of the fees in the prior block and not let them set it under 1?
1066 2012-06-20 20:44:34 <Diablo-D3> gmaxwell: fraction of fees over the past 100.
1067 2012-06-20 20:44:38 <gmaxwell> Not just idiots. It's not obvious that "0" is really bad.
1068 2012-06-20 20:44:53 danbri_ has joined
1069 2012-06-20 20:44:59 danbri has quit (Read error: Connection reset by peer)
1070 2012-06-20 20:45:09 <gmaxwell> gavinandresen: E.g. "I'm super generous, so I consider any fee to be a fee!"  or "I'm really poor, every cent counts!"  without really thinking through the implications.
1071 2012-06-20 20:45:20 <Diablo-D3> "send with no fee" "send with low (half of average)" "send with medium (average)" "send with high (twice average)"
1072 2012-06-20 20:45:46 <Diablo-D3> and then the reverse "allow % maximum of each"
1073 2012-06-20 20:45:47 PK has quit ()
1074 2012-06-20 20:46:01 <Diablo-D3> so a guy really could allow 100% free
1075 2012-06-20 20:46:09 <Diablo-D3> or set free, low, and medium to 0
1076 2012-06-20 20:46:26 <Diablo-D3> or hell
1077 2012-06-20 20:46:28 <Diablo-D3> set all four to 0
1078 2012-06-20 20:46:30 <Diablo-D3> and mine with no tx
1079 2012-06-20 20:49:52 <Diablo-D3> gavinandresen: seriously, if someone wants to do that, whats wrong with that
1080 2012-06-20 20:51:48 <gavinandresen> it's anti-social behavior that I think should be discouraged.
1081 2012-06-20 20:52:08 <gavinandresen> ... other miners should be encouraged to discourage those blocks.
1082 2012-06-20 20:52:11 <Diablo-D3> gavinandresen: okay lets try this differently
1083 2012-06-20 20:52:15 <gavinandresen> in my humble opinion.
1084 2012-06-20 20:52:16 <Diablo-D3> 1mb is the max, right?
1085 2012-06-20 20:52:19 <gavinandresen> yup
1086 2012-06-20 20:52:26 <Diablo-D3> take the average usage over the past 100 blocks
1087 2012-06-20 20:52:37 <gavinandresen> usage?
1088 2012-06-20 20:52:41 <Diablo-D3> usage of the 1mb
1089 2012-06-20 20:52:42 <gavinandresen> you mean block size?
1090 2012-06-20 20:53:02 <gavinandresen> ok
1091 2012-06-20 20:53:11 <Diablo-D3> then let 100% average usage be 1btc in fees per 1mb (or 0.001 per kb)
1092 2012-06-20 20:53:26 <Diablo-D3> and then make that the fee that is both sent and required by default nodes
1093 2012-06-20 20:53:30 <gavinandresen> why is 1btc in fees the right number?
1094 2012-06-20 20:53:38 <Diablo-D3> its nice and even.
1095 2012-06-20 20:53:41 <gavinandresen> nack
1096 2012-06-20 20:54:05 <sipa> you just said you wanted block space price to be determined by the market
1097 2012-06-20 20:54:07 <Diablo-D3> lets say the past 100 blocks were 10%, the average fee would be 0.1 BTC per 1mb
1098 2012-06-20 20:54:16 <Diablo-D3> sipa: yes but gavin said it was wrong
1099 2012-06-20 20:54:19 <Diablo-D3> so Im trying a new idea
1100 2012-06-20 20:54:30 <sipa> you don't sound very consistent
1101 2012-06-20 20:54:37 <Diablo-D3> sipa: Im trying out ideas here
1102 2012-06-20 20:54:58 <Diablo-D3> gavinandresen: it gets rid of the knobs and it scales the fees with usage
1103 2012-06-20 20:55:01 <sipa> yes, you're just coming up with things before thinking them through, while other people here are discussion some well-formed plan
1104 2012-06-20 20:55:14 <Diablo-D3> sipa: shush, Ive had this on a backburner for awhile
1105 2012-06-20 20:55:26 <sipa> i'm going to shut up
1106 2012-06-20 20:55:38 <Diablo-D3> gavinandresen: spammers cant spam for very long before it starts dragging the average usage up
1107 2012-06-20 20:56:05 <Diablo-D3> and people dont have to set fee because the network sets it dynamically
1108 2012-06-20 20:56:30 <gavinandresen> Diablo-D3: I'm with sipa.  Write up a counter-proposal so I can see it all at once.
1109 2012-06-20 20:58:15 <gavinandresen> gmaxwell: so if we go with "maximum BTC of transactions to replace with priority-sorted-free-transactions", the knobs would be....
1110 2012-06-20 20:59:49 <gavinandresen> uh....    sort all transactions by fee, chop the list when you get to 1MB...  still need to avoid relaying/considering obvious spam (close-to-no-fee/low-priority)
1111 2012-06-20 21:02:01 <gmaxwell> gavinandresen: I just commented on the gist.
1112 2012-06-20 21:02:15 <gmaxwell> Instead I suggest "Maximum amount of BTC to give up in order to process transactions in order of priority: M". The algorithm would be:
1113 2012-06-20 21:02:18 <gmaxwell> Set (for the purpose of selection) all fees below the amount/kb to be considered a fee to zero.
1114 2012-06-20 21:02:21 <gmaxwell> Order transactions by fee per kb. Stop when you hit maximum size.
1115 2012-06-20 21:02:24 <gmaxwell> Go backwards and remove M BTC in fees worth of transactions.
1116 2012-06-20 21:02:26 <gmaxwell> Add transactions in order of priority, stopping when the block is full or when the maximum amount of 0 fee transaction data is hit.
1117 2012-06-20 21:03:31 Maccer has quit (Excess Flood)
1118 2012-06-20 21:06:15 <gavinandresen> gmaxwell: I like it.
1119 2012-06-20 21:08:48 titeuf_87 has quit (Quit: Leaving)
1120 2012-06-20 21:09:44 <gmaxwell> Note that you might just add back the same txn you just removed.. if they happened to have high priority. So it's only a maximum lost. This means it's also reasonably safe to set the option high.
1121 2012-06-20 21:10:50 <gavinandresen> I wonder if jgarzik has a comment, he was looking at benchmarking/optimizing the block creation code today, yes?
1122 2012-06-20 21:13:36 <Diablo-D3> gavinandresen: well, whatever you guys go with, it has to be simple to use
1123 2012-06-20 21:19:51 egecko has joined
1124 2012-06-20 21:22:12 p0s has quit (Remote host closed the connection)
1125 2012-06-20 21:22:54 eoss has joined
1126 2012-06-20 21:22:54 eoss has quit (Changing host)
1127 2012-06-20 21:22:54 eoss has joined
1128 2012-06-20 21:25:19 <BlueMatt> gmaxwell: I was under the impression that was always kinda the plan...anyway, Ive always thought it would work
1129 2012-06-20 21:25:44 egecko has quit (Quit: ~ Trillian Astra - www.trillian.im ~)
1130 2012-06-20 21:25:58 Maccer has joined
1131 2012-06-20 21:26:26 <gmaxwell> BlueMatt: hm?   I'm just clarifying that the 'remove' in my algorithim didn't mean don't mine them at all.
1132 2012-06-20 21:29:09 agricocb has quit (Quit: Leaving.)
1133 2012-06-20 21:30:33 <BlueMatt> gmaxwell: no, the idea that we will always keep around a free tx area and let miners chose how big (or in this case how much) it is
1134 2012-06-20 21:30:48 <BlueMatt> and other than that just sort by fee
1135 2012-06-20 21:31:18 <BlueMatt> aside from getting really complicated, I kinda always assumed that was the idea
1136 2012-06-20 21:32:25 <gmaxwell> BlueMatt: The problem with 'free txn area' as a 'minimum' is that it makes it hard to reason about how much fees you're missing out on.  E.g. you could potentially lose a billonity bitcoins. That encourages people to set it to zero if you make it easy to set.
1137 2012-06-20 21:33:00 <BlueMatt> gmaxwell: agreed, size in btc is much better
1138 2012-06-20 21:36:20 erle- has quit (Quit: erle-)
1139 2012-06-20 21:37:49 paraipan has quit (Remote host closed the connection)
1140 2012-06-20 21:38:21 <gmaxwell> If I think a bit harder perhaps I can figure out how to make the amount closer to the amount you will lose (instead of just a maximum) without making the algorithim terribly complicated.
1141 2012-06-20 21:39:31 <gmaxwell> ah. I've got it.   "sort by fee/kb, then replace txn one at a time from he bottom using txn from the top of the priority sorted list until your lost fee =M or you've hit the maximum amount of free txn"
1142 2012-06-20 21:42:17 <BlueMatt> as long as its not individual txn, but txn groups, yep
1143 2012-06-20 21:42:18 <gavinandresen> Do we need the 'max amount of free txn' knob?
1144 2012-06-20 21:42:43 <BlueMatt> I dont think so, just "max Im willing to lose" should cover it imho
1145 2012-06-20 21:42:59 <gavinandresen> I think so, too.
1146 2012-06-20 21:43:40 <gmaxwell> I only left it in my description because I thought some people who want to fight chain bloat might want to turn it down.
1147 2012-06-20 21:43:51 <gmaxwell> I don't feel strongly that its needed however.
1148 2012-06-20 21:45:51 <BlueMatt> ok...lets see, how do spv nodes with the new filter* stuff get average fee/kb over last n blocks?
1149 2012-06-20 21:46:07 <sipa> they can't
1150 2012-06-20 21:46:15 <gavinandresen> block fees are easy, they're in the coinbase txout
1151 2012-06-20 21:46:18 <sipa> unless they want to trust some full node to tell them
1152 2012-06-20 21:46:18 * BlueMatt is thinking putting it in coinbase
1153 2012-06-20 21:46:40 <gavinandresen> e.g. if the last block was 100K and got a 50.01 BTC reward, you know there was 0.1 fees for 100KB
1154 2012-06-20 21:46:44 <gavinandresen> 0.01
1155 2012-06-20 21:46:58 denisx has quit (Quit: denisx)
1156 2012-06-20 21:47:01 <BlueMatt> gavinandresen: ignore free tx stuff then?
1157 2012-06-20 21:47:03 <sipa> yes, but you cannot do any measurement of how long it takes for a tx to be include
1158 2012-06-20 21:47:06 <sipa> d
1159 2012-06-20 21:47:31 <BlueMatt> sipa: if you pay avg, its a pretty safe bet you will be in the next block?
1160 2012-06-20 21:47:33 <gavinandresen> sipa: right.  SPV nodes need to rely on somebody else to tell them, I think
1161 2012-06-20 21:47:57 <gmaxwell> Client behavior I feel pretty meh about. We need to get replacement working. Nothing automatic is going to work great.
1162 2012-06-20 21:48:01 <sipa> BlueMatt: i think that may be serious overkill someday
1163 2012-06-20 21:48:20 Detritus has quit (Ping timeout: 245 seconds)
1164 2012-06-20 21:49:02 <BlueMatt> Id think avg would be serious overkill, yea.  But if you do the lowest, or low percentile, it just encourages a downward fee spiral
1165 2012-06-20 21:49:17 <gmaxwell> If people start automatically paying the mean,  MinerEconomicus will start mining 100 BTC fee txn in his own blocks. (and hoping he doesn't get orphaned. ;) )
1166 2012-06-20 21:49:18 <BlueMatt> plus then you'd need to trust a full node
1167 2012-06-20 21:49:26 Detritus has joined
1168 2012-06-20 21:50:07 <yellowhat> does anyone know which protocol electrum currently uses for communication with the server?
1169 2012-06-20 21:50:09 <yellowhat> is it the "stratum" protocol already?
1170 2012-06-20 21:50:14 <gavinandresen> miners trying to influence the system is why I think watching the memory pool is the only reliable way to figure it out
1171 2012-06-20 21:50:25 <BlueMatt> and for spv nodes?
1172 2012-06-20 21:50:41 <gavinandresen> spv nodes will subscribe to a fee-reporting service that they trust, I think
1173 2012-06-20 21:50:46 <gmaxwell> miners can influence the memory pool too..
1174 2012-06-20 21:51:33 <gmaxwell> I suppose looking at txn which _aren't_ getting included which you consider valid is probably pretty good.
1175 2012-06-20 21:51:38 <gavinandresen> but influencing the memory pool seems to me to be a lot costlier-- you'd have to submit large-fee transactions and then hope you mine them
1176 2012-06-20 21:52:56 agricocb has joined
1177 2012-06-20 21:53:00 <gmaxwell> e.g. sort the memory pool by fee. When a block comes, whats the highest fee that didn't make it in?  ... now median that over the last N blocks.
1178 2012-06-20 21:53:37 <gmaxwell> (or fit some logistic model to it— so you get a probability out)
1179 2012-06-20 21:53:44 <gavinandresen> gmaxwell: experimentation/data is needed, and I think it might take a couple of iterations to get it close to right
1180 2012-06-20 21:55:06 <gmaxwell> In general I'm cautious about using transactions which get _in_ to blocks right away because that gets influenced by invisible agreements. But I think stays out is better, because invisible agreements to keep txn out are not above board at all and hopefully won't exist in any quantity.
1181 2012-06-20 21:55:17 <gmaxwell> (and they would be futile because to keep something out everyone must agree)
1182 2012-06-20 21:55:54 <gavinandresen> gmaxwell: excellent insight
1183 2012-06-20 21:56:05 paraipan has joined
1184 2012-06-20 21:56:06 TD has quit (Quit: TD)
1185 2012-06-20 21:56:07 <gavinandresen> ... that's why we pay you the big bucks
1186 2012-06-20 21:56:16 <gmaxwell> I was just about to say that. HAHA
1187 2012-06-20 21:57:21 <gmaxwell> How to convert stays out data into an amount is an open question. But I can crunch some numbers on that once I figure out how to mesaure it.
1188 2012-06-20 22:00:54 CluckCreek has joined
1189 2012-06-20 22:01:50 gavinandresen has quit (Quit: gavinandresen)
1190 2012-06-20 22:05:49 MysteryBanshee has quit ()
1191 2012-06-20 22:07:15 <jgarzik> drat, just missed gavin
1192 2012-06-20 22:08:59 <CluckCreek> I'm hoping to release a software project soon and I want some legal advice, I was wondering if anyone here had consulted an attorney they would recommend for bitcoin-related things?
1193 2012-06-20 22:10:53 eoss has quit (Quit: Leaving)
1194 2012-06-20 22:11:31 RazielZ has quit (Quit: Leaving)
1195 2012-06-20 22:15:11 da2ce759 has joined
1196 2012-06-20 22:16:44 da2ce7 has quit (Ping timeout: 246 seconds)
1197 2012-06-20 22:19:55 <gmaxwell> sipa: were you thinking of hardcoding some onionseeds in the tor support eventually?
1198 2012-06-20 22:20:08 <sipa> gmaxwell: yes
1199 2012-06-20 22:20:20 <sipa> though not before there are few decent ones
1200 2012-06-20 22:24:41 * jgarzik wonders if there is a portable interface for querying TXT records
1201 2012-06-20 22:26:09 * sipa doubts there is any portable interface to DNS at all
1202 2012-06-20 22:26:25 <sipa> except getaddrinfo and predecessors
1203 2012-06-20 22:26:30 <Eliel> CluckCreek: you'll have better luck on bitcointalk.org I think.
1204 2012-06-20 22:27:43 _Fireball has quit (Quit:  HydraIRC -> http://www.hydrairc.com <- Wibbly Wobbly IRC)
1205 2012-06-20 22:31:19 <CluckCreek> Would I still be restricted to the newbie forum when I register?
1206 2012-06-20 22:31:30 <sipa> i believe so
1207 2012-06-20 22:32:33 <galambo> bitcoin lawyer :) heh
1208 2012-06-20 22:33:13 <CluckCreek> I know, I thought I'd at least give it a shot. :)
1209 2012-06-20 22:33:53 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1210 2012-06-20 22:46:29 sacredchao has quit (Ping timeout: 276 seconds)
1211 2012-06-20 22:46:59 graingert has joined
1212 2012-06-20 22:48:32 copumpkin has quit (Quit: Computer has gone to sleep.)
1213 2012-06-20 22:48:43 AntKinGTube has joined
1214 2012-06-20 22:50:22 minimoose_ has joined
1215 2012-06-20 22:50:59 sacredchao has joined
1216 2012-06-20 22:53:27 minimoose has quit (Ping timeout: 250 seconds)
1217 2012-06-20 22:53:27 minimoose_ is now known as minimoose
1218 2012-06-20 22:56:02 <jgarzik> gmaxwell: one wonders if the tx.ConnectInputs() call in the CreateNewBlock() callchain isn't redundant?  we are iterating through the mempool, whose members IIUC must have passed ConnectInputs checks
1219 2012-06-20 23:00:06 <sipa> jgarzik: there are some cases where transactions can end up in the mempool that conflict with the blockchain or with eachother, iirc
1220 2012-06-20 23:00:11 <sipa> TD discovered that some time ago
1221 2012-06-20 23:00:52 <jgarzik> sipa: that sounds... odd
1222 2012-06-20 23:01:09 <sipa> maybe the solution is to more strictly enforce that invariant on the mempool better
1223 2012-06-20 23:01:19 <sipa> jgarzik: it's not very likely, it require some reorganisations
1224 2012-06-20 23:02:06 <jgarzik> sipa: hrm.  reorg does not sort into mapOrphans vs. mempool, but just tosses everything into mempool?
1225 2012-06-20 23:03:01 <sipa> i can't remember the details
1226 2012-06-20 23:03:12 <jgarzik> I suppose it must toss them into mempool, otherwise mapOrphans code could throw away transactions
1227 2012-06-20 23:04:03 <jgarzik> thus, mempool requires ConnectInputs upon entry from outside world, but reorg hack might pollute mempool with orphans
1228 2012-06-20 23:04:18 <jgarzik> I guess ConnectInputs is not redundant in CreateNewBlock, then, alas
1229 2012-06-20 23:04:52 <maaku> well, sounds more like the reorg code needs to be fixed
1230 2012-06-20 23:05:28 <sipa> iirc it required two reorganisations and a double spend in between to cause the issue
1231 2012-06-20 23:06:34 <jgarzik> "fixing" reorg to not toss orphans into mempool would require special orphan-from-reorg handling inside mapOrphans, because mapOrphans code randomly deletes orphans if it exceeds a certain size, for anti-DoS reasons.  The ugly hack is understandable... you don't want a big reorg to kick in anti-DoS code
1232 2012-06-20 23:06:59 <jgarzik> thus, orphans in mempool
1233 2012-06-20 23:07:05 <maaku> i see
1234 2012-06-20 23:09:01 egecko has joined
1235 2012-06-20 23:10:01 copumpkin has joined
1236 2012-06-20 23:10:18 cande has joined
1237 2012-06-20 23:10:37 mmoya has quit (Ping timeout: 265 seconds)
1238 2012-06-20 23:11:24 <cande> which URI scheme does bitcoin use?
1239 2012-06-20 23:11:59 <sipa> ;;google BIP 0022
1240 2012-06-20 23:12:00 <gribble> BIP 0022 - Bitcoin: <https://en.bitcoin.it/wiki/BIP_0022>; Talk:BIP 0022 - Bitcoin: <https://en.bitcoin.it/wiki/Talk:BIP_0022>; Category:BIP - Bitcoin: <https://en.bitcoin.it/wiki/Category:BIP>
1241 2012-06-20 23:12:05 <sipa> cande: ^
1242 2012-06-20 23:12:18 <sipa> ow
1243 2012-06-20 23:12:21 <cande> cool, thnx
1244 2012-06-20 23:12:21 <sipa> ;;google BIP 0021
1245 2012-06-20 23:12:22 <gribble> BIP 0021 - Bitcoin: <https://en.bitcoin.it/wiki/BIP_0021>; Category:BIP - Bitcoin: <https://en.bitcoin.it/wiki/Category:BIP>; Category:Developer - Bitcoin: <https://en.bitcoin.it/wiki/Category:Developer>
1246 2012-06-20 23:12:24 <sipa> that ^
1247 2012-06-20 23:12:31 <cande> oh.,
1248 2012-06-20 23:12:33 <cande> :)
1249 2012-06-20 23:12:52 <cande> since when did bitcoin change to bip 0021 =
1250 2012-06-20 23:12:52 <cande> ?
1251 2012-06-20 23:14:45 maaku has quit (Quit: maaku)
1252 2012-06-20 23:15:19 <sipa> "change" ?
1253 2012-06-20 23:15:51 <sipa> BIP's are just proposed improvements; people agree with them or they don't; some implementations choose to follow some if they like
1254 2012-06-20 23:16:15 <cande> ah
1255 2012-06-20 23:16:44 <cande> does bitcoin-qt apply to Bip 0021?
1256 2012-06-20 23:17:17 <sipa> on linux it does
1257 2012-06-20 23:17:30 <sipa> there were issus with the uri handling on osx and windows
1258 2012-06-20 23:17:52 <sipa> though windows will most likely be supported by 0.7.0 when it is release
1259 2012-06-20 23:18:13 <sipa> d
1260 2012-06-20 23:19:02 <cande> :)
1261 2012-06-20 23:19:15 <cande> mm so nice!
1262 2012-06-20 23:19:27 jurov is now known as jurov|away
1263 2012-06-20 23:19:29 <BlueMatt> q
1264 2012-06-20 23:19:50 <BlueMatt> oops, sorry
1265 2012-06-20 23:21:42 <gmaxwell> sipa: I have my new hidden service bitcoin node up: bun5vdg2agmaxwell.onion:8333 it should be working now.
1266 2012-06-20 23:23:39 <cande> gnight
1267 2012-06-20 23:23:42 cande has quit (Quit: Lämnar)
1268 2012-06-20 23:23:46 <sipa> gmaxwell: there is a small chance my crawler will notice it
1269 2012-06-20 23:24:57 Ferroh has quit (Ping timeout: 272 seconds)
1270 2012-06-20 23:24:59 <doublec> does onlynet=tor cause the node to only distribute the tor node informationvia addr and not pass on non-tor addresses to peers?
1271 2012-06-20 23:25:18 sirk390 has quit (Quit: Leaving.)
1272 2012-06-20 23:25:39 <sipa> doublec: not related; -onlynet is about which networks it connects to
1273 2012-06-20 23:26:20 <doublec> sipa: ok thanks
1274 2012-06-20 23:26:55 <sipa> doublec: if you pass -externalip=, it will not attempt to detect other local addresses
1275 2012-06-20 23:27:04 <sipa> doublec: so it certainly won't pass any on
1276 2012-06-20 23:27:17 <gmaxwell> I thought it passed on foreign ones but not many?
1277 2012-06-20 23:27:39 <sipa> gmaxwell: i mean *local* addresses
1278 2012-06-20 23:27:49 <sipa> it does relay other addresses it hears about
1279 2012-06-20 23:30:51 bobke has quit (Ping timeout: 245 seconds)
1280 2012-06-20 23:32:21 <doublec> how does the a node on tor bridge to the real network? Does some node on it not use onlynet=tor so it can receive connections to the non-tor world and other onlynet=tor nodes rely on these existing?
1281 2012-06-20 23:33:49 Prattler has quit (Remote host closed the connection)
1282 2012-06-20 23:33:53 <gmaxwell> doublec: if you're using -proxy  without onlynettor you'll connect to both hidden services and IPv4 nodes via exits, and thus bridge.
1283 2012-06-20 23:34:21 <sipa> and you can be reachable on both networks too
1284 2012-06-20 23:34:23 <gmaxwell> also, there are nodes connected to both directly. E.g. mine is like that.
1285 2012-06-20 23:34:46 gavinandresen has joined
1286 2012-06-20 23:34:54 <doublec> ok thanks. I've been using onlynet=cjdns modelled after the tor/i2p stuff and wanted to make sure I understood things correctly
1287 2012-06-20 23:39:39 <jrmithdobbs> gmaxwell: i should really setup my public node to bridge tor
1288 2012-06-20 23:40:51 tyn has quit (Ping timeout: 245 seconds)
1289 2012-06-20 23:41:21 MC1984 has joined
1290 2012-06-20 23:45:10 <gmaxwell> jrmithdobbs: it'll be somewhat easier when we pull the hidden services patch.
1291 2012-06-20 23:49:23 <gmaxwell> sipa: er.. my onion address is bun5vdg2agmaxwell.onion it's configured correctly... but
1292 2012-06-20 23:49:26 <gmaxwell> 06/20/12 23:11:50 AddLocal(bun5vdg2agmaxwel.onion:8333,6)
1293 2012-06-20 23:49:30 <gmaxwell> (one l instead of two)
1294 2012-06-20 23:50:12 <sipa> heh
1295 2012-06-20 23:50:35 Turingi has quit (Read error: Connection reset by peer)
1296 2012-06-20 23:51:49 <jrmithdobbs> gmaxwell: ah, i thought you were saying that was pulled, that's what i've been waiting for
1297 2012-06-20 23:52:06 <sipa> gmaxwell: sure? it's supposed to be 16 characters
1298 2012-06-20 23:52:10 <sipa> gmaxwell: you claim yours is 17
1299 2012-06-20 23:52:20 <gmaxwell> !
1300 2012-06-20 23:52:22 <gmaxwell> lemme check
1301 2012-06-20 23:53:14 <gmaxwell> hm. well shallot gave me bun5vdg2agmaxwell.onion
1302 2012-06-20 23:53:23 <gmaxwell> lemme see if I can get tor to write it out.
1303 2012-06-20 23:53:36 <sipa> gmaxwell: .../service_dir/hostname
1304 2012-06-20 23:53:46 <sipa> same place the secret key is in
1305 2012-06-20 23:54:35 genjix has joined
1306 2012-06-20 23:54:44 <gmaxwell> right but I'd written that with the shallot output.
1307 2012-06-20 23:54:53 <gmaxwell> well crap— some crazy shallot bug!
1308 2012-06-20 23:54:59 <gavinandresen> sipa: running as a hidden service worked nicely once I set the obscure Vidalia option not to randomize the SOCKS port
1309 2012-06-20 23:55:08 Backburn_p has quit (Remote host closed the connection)
1310 2012-06-20 23:55:25 Backburn_p has joined
1311 2012-06-20 23:55:26 <sipa> gavinandresen: gotten any incoming connections?
1312 2012-06-20 23:55:43 <gavinandresen> I'll fire it up again and check....
1313 2012-06-20 23:55:56 <gmaxwell> sipa: well nevermind then!
1314 2012-06-20 23:56:05 att has joined
1315 2012-06-20 23:56:14 <gmaxwell> apparently my hidden service address is b4ymclq6qeh4um3q.onion ... /me goes to fix shallot
1316 2012-06-20 23:56:41 <sipa> gavinandresen: my crawler didn't ever see any onion node except my own, so i doubt any onion addresses are circulating on the p2p net
1317 2012-06-20 23:56:56 <jrmithdobbs> i've never seen one
1318 2012-06-20 23:57:22 <jrmithdobbs> i've not been looking for them, though, either
1319 2012-06-20 23:58:21 tyn has joined
1320 2012-06-20 23:58:44 <sipa> i've been hunting a bug for hours now... a txindex entry is written to blkindex.dat, it is never deleted, but it can't be found afterwards :(
1321 2012-06-20 23:59:14 <sipa> hmmm, maybe the db transaction where it gets written is aborted
1322 2012-06-20 23:59:55 <gmaxwell> okay.. shallot consistently writes onion addresses that are too long.