1 2012-01-03 00:00:21 <sipa> seems it's indeed the other way around
   2 2012-01-03 00:01:05 <sipa> but that still doesn't make sense
   3 2012-01-03 00:02:16 <sipa> as the original code was correct, in that case
   4 2012-01-03 00:02:44 dan__ has quit (Quit: dan__)
   5 2012-01-03 00:03:19 <gmaxwell> Might if have been one of the _other_ callers that was wrong?  I mean, I don't know that I saw proof that dnsseed was the cause of the deadlock, only that it was stuck at the same time.
   6 2012-01-03 00:03:59 <sipa> it's always this way
   7 2012-01-03 00:04:09 erus` has quit (Remote host closed the connection)
   8 2012-01-03 00:04:35 <gmaxwell> e.g. AddressCurrentlyConnected calls addrdb.WriteAddress while holding cs_mapAddresses.
   9 2012-01-03 00:05:23 copumpki_ has joined
  10 2012-01-03 00:05:42 <sipa> damn, i was only checking calls to AddAddress
  11 2012-01-03 00:05:48 <sipa> i'm too tired for this now
  12 2012-01-03 00:06:54 <gmaxwell> sorry, I'd try to fix it but I have basically no mental model about any of the locking in bitcoin. I ignored it while reading the code. I am absolutely I'd be a completely liability touching any of this code.
  13 2012-01-03 00:10:08 osmosis has quit (Ping timeout: 252 seconds)
  14 2012-01-03 00:17:57 Rabbit67890 has quit (Quit: Rabbit67890)
  15 2012-01-03 00:20:06 Wizzleby has joined
  16 2012-01-03 00:24:09 wasabi2 has joined
  17 2012-01-03 00:25:49 wasabi1 has quit (Ping timeout: 244 seconds)
  18 2012-01-03 00:27:04 osmosis has joined
  19 2012-01-03 00:31:03 rdponticelli has quit (Read error: Connection reset by peer)
  20 2012-01-03 00:33:37 <sipa> gmaxwell: care to try once more? 6ceeb3e
  21 2012-01-03 00:34:06 calebopeko has quit (Ping timeout: 252 seconds)
  22 2012-01-03 00:34:07 <sipa> i found two places where database locking occurred inside the mapaddresses cs
  23 2012-01-03 00:34:20 rdponticelli has joined
  24 2012-01-03 00:35:29 Rabbit67890 has joined
  25 2012-01-03 00:39:47 Sedra- has joined
  26 2012-01-03 00:40:17 <gmaxwell> okay!
  27 2012-01-03 00:42:11 Sedra- has quit (Remote host closed the connection)
  28 2012-01-03 00:42:31 <gmaxwell> oh hey, I see it concurrently adding addresses while getting blocks now, don't think it did that before.
  29 2012-01-03 00:42:39 Sedra- has joined
  30 2012-01-03 00:43:19 <sipa> may well be, i shrank the critical sections
  31 2012-01-03 00:43:32 Sedra has quit (Ping timeout: 276 seconds)
  32 2012-01-03 00:44:24 <gmaxwell> survived 6 restarts so far.
  33 2012-01-03 00:50:12 Kolky has quit (Quit: Bye bye!)
  34 2012-01-03 00:50:36 <gmaxwell> sipa: okay, so I added a sleep(30) right above the loopkup in dnsseed.. and now I don't see any AddAddress while it's waiting on it.. but it's still happily connected to its peer and working.
  35 2012-01-03 00:50:58 <gmaxwell> sipa: this is less bad then getting stuck, but I think its still not the right behavior unless lookup can't block.
  36 2012-01-03 00:50:59 <sipa> that's to be expected
  37 2012-01-03 00:51:02 <gmaxwell> (for long)
  38 2012-01-03 00:51:23 <sipa> wait
  39 2012-01-03 00:51:29 <gmaxwell> sipa: we don't want nodes with screwed up dns behaving any worse due to dnsseed...
  40 2012-01-03 00:51:36 hippich_ has joined
  41 2012-01-03 00:52:09 <sipa> there is no locking going on at all, the line above Lookup()
  42 2012-01-03 00:52:29 <gmaxwell> sipa: oh. wtf.
  43 2012-01-03 00:52:36 <gmaxwell> why am I not seeing AddAddress then?!
  44 2012-01-03 00:52:41 <sipa> if you don't see any AddAddress happening, sure that you're not expecting AddAddress'es from thr dns seeds?
  45 2012-01-03 00:53:25 <sipa> Sleep(30) means 30ms by the way
  46 2012-01-03 00:53:37 <CIA-100> bitcoin: p2k * r794e23d73337 ecoinpool/ (3 files in 2 dirs): Web Frontend Bugfix http://tinyurl.com/74pomgm
  47 2012-01-03 00:54:04 <gmaxwell> sipa: sleep not Sleep?
  48 2012-01-03 00:54:28 <sipa> sleep(30) is 30s :)
  49 2012-01-03 00:54:40 <gmaxwell> Yes. I'm sleep(30). Intentionally. :)
  50 2012-01-03 00:54:46 <sipa> let me try myself
  51 2012-01-03 00:54:59 <gmaxwell> I have a peer, I'm getting blocks from it. So I expect to get addresses from it.
  52 2012-01-03 00:55:41 <gmaxwell> I've synced up 130 blocks by the first time AddAddress runs (I assume thats when the 30 second timer runs out).
  53 2012-01-03 00:55:55 <sipa> i see AddAddress'es all righgt
  54 2012-01-03 00:56:07 <sipa> while the dns thread is blocked on a sleep above Lookup
  55 2012-01-03 00:56:41 <gmaxwell> hm. Am I misremebering the protocol? I thought it exchanged addresses before doing anything else?
  56 2012-01-03 00:56:54 <sipa> it sends a getaddr very early, yes
  57 2012-01-03 00:57:06 <sipa> but the reply may come not that early
  58 2012-01-03 00:57:18 <sipa> iirc
  59 2012-01-03 00:57:36 <sipa> i added a sleep(1000), and i am seeing new addresses and connections being made
  60 2012-01-03 00:57:54 <gmaxwell> I'm trying something like that now.
  61 2012-01-03 00:58:56 <gmaxwell> I'm not... odd.
  62 2012-01-03 00:59:04 <sipa> wait a bit?
  63 2012-01-03 00:59:18 <sipa> maybe the addresses your peer knows, are already in your addr.dat ?
  64 2012-01-03 00:59:36 <gmaxwell> no, blowing away addr.day at every startup.
  65 2012-01-03 00:59:52 <gmaxwell> killall -9 bitcoind ; sleep 1 ; killall -9 bitcoind ; rm -Rf ~/.bitcoin/ ; mkdir ~/.bitcoin ; cp bitcoin.conf ~/.bitcoin/bitcoin.conf ; ./bitcoind ; tail -f ~/.bitcoin/debug.log
  66 2012-01-03 01:00:24 <gmaxwell> hm. maybe some --connect behavior I'm unaware of.
  67 2012-01-03 01:00:47 <gmaxwell> ah
  68 2012-01-03 01:00:49 <gmaxwell> there it goes..
  69 2012-01-03 01:01:09 <gmaxwell> happened at block height 500.. I guess it processed it after the getblocks
  70 2012-01-03 01:01:14 BlueMatt-mobile has joined
  71 2012-01-03 01:01:15 <gmaxwell> yippie
  72 2012-01-03 01:01:23 <gmaxwell> sipa: Your code is perfect. Ship it.
  73 2012-01-03 01:02:11 <BlueMatt-mobile> Still havent fixes that deadlock?
  74 2012-01-03 01:02:22 <gmaxwell> BlueMatt-mobile: sipa fixed it.
  75 2012-01-03 01:02:35 <BlueMatt-mobile> Without Sleep?
  76 2012-01-03 01:02:37 <gmaxwell> BlueMatt-mobile: or at least, changed it into something I can't reproduce. :P
  77 2012-01-03 01:03:06 <gmaxwell> yea, restarted it 20 times without the sleep in there... no deadlocks.
  78 2012-01-03 01:03:16 <gmaxwell> And with the sleep in there it behaves okaydokie.
  79 2012-01-03 01:03:28 <sipa> i made three critical blocks for cs_mapAddresses smaller, so concurrency should have improved as well
  80 2012-01-03 01:03:45 <BlueMatt-mobile> Fair enough
  81 2012-01-03 01:03:46 <gmaxwell> sipa: it appears to be _clearly_ faster, yes.
  82 2012-01-03 01:03:54 <sipa> noticably? nice
  83 2012-01-03 01:04:22 <BlueMatt-mobile> (as long as you arent hacking around with Sleep to fix deadlocks...)
  84 2012-01-03 01:04:39 * BlueMatt-mobile was reading oo
  85 2012-01-03 01:04:44 <gmaxwell> BlueMatt-mobile: nah, the purpose of the sleep stuff was to simulate slow/unresponsive dns to make sure it wasn't getting stuck there.
  86 2012-01-03 01:04:51 <BlueMatt-mobile> logs, saw sleep and was concerned
  87 2012-01-03 01:05:09 <BlueMatt-mobile> Oh ok, yea didnt think so
  88 2012-01-03 01:05:17 RazielZ has quit (Quit: Leaving)
  89 2012-01-03 01:05:18 <gmaxwell> One of sipas patches did.
  90 2012-01-03 01:06:45 zeiris has quit (Ping timeout: 240 seconds)
  91 2012-01-03 01:07:38 <CIA-100> bitcoin: Pieter Wuille master * ra75d706 / src/net.cpp : Fix some address-handling deadlocks ... https://github.com/bitcoin/bitcoin/commit/a75d7066b824eb1e70fb5b0e0e7c3c122e00c4b6
  92 2012-01-03 01:07:38 <CIA-100> bitcoin: Pieter Wuille master * r4231eb2 / src/net.cpp : Merge pull request #738 from sipa/dnsseed-fix ... https://github.com/bitcoin/bitcoin/commit/4231eb217ca06e93cfb0875924b4383f92baf134
  93 2012-01-03 01:09:50 <gmaxwell> luke-jr: ^ thats a bug fix that should probably be pulled into whatever stable versions you have (at least after it seasons in head for a bit)
  94 2012-01-03 01:10:47 <luke-jr> gmaxwell: I'm looking at it now
  95 2012-01-03 01:10:56 <luke-jr> it looks like there's a non-fix tacked on the end of it tho
  96 2012-01-03 01:11:06 <luke-jr> specifically, it looks like it disables DNS seeds if IRC connects
  97 2012-01-03 01:11:42 <sipa> luke-jr: no
  98 2012-01-03 01:11:47 <BlueMatt-mobile> Dnsseed should still run if irc connects
  99 2012-01-03 01:11:54 <sipa> that code was already there, inside the critical block
 100 2012-01-03 01:12:00 <BlueMatt-mobile> Irc sucks and should be phased out...
 101 2012-01-03 01:12:00 <sipa> and it is about the hard-coded seeds, not dns seeds
 102 2012-01-03 01:12:06 <gmaxwell> Are you just mistaking an indenting change?
 103 2012-01-03 01:12:18 <sipa> it's a code-move-and-indent
 104 2012-01-03 01:12:20 <luke-jr> ah
 105 2012-01-03 01:12:26 <luke-jr> ok nm
 106 2012-01-03 01:13:07 <sipa> except for increasing concurrency a bit, there should be no functional changes
 107 2012-01-03 01:13:18 <luke-jr> k
 108 2012-01-03 01:13:40 <luke-jr> I'll push to 0.4.x for now, and merge up to 0.5.0.x and 0.5.x later
 109 2012-01-03 01:13:46 <CIA-100> bitcoin: Pieter Wuille 0.4.x * rb52b6f2e3801 bitcoind-stable/src/net.cpp: Fix some address-handling deadlocks http://tinyurl.com/6w9eqyx
 110 2012-01-03 01:16:27 <gmaxwell> Can CIA be made to report issue creation in here?
 111 2012-01-03 01:16:46 <BlueMatt-mobile> No afaik
 112 2012-01-03 01:16:58 <BlueMatt-mobile> Though an rss bot could pretty easily
 113 2012-01-03 01:17:36 <BlueMatt-mobile> (Github private feed following bitcoin/bitcoin)
 114 2012-01-03 01:18:23 <luke-jr> gmaxwell: great idea, but no thanks to GitHub
 115 2012-01-03 01:20:51 copumpki_ is now known as pumpkin
 116 2012-01-03 01:20:51 pumpkin has quit (Changing host)
 117 2012-01-03 01:20:51 pumpkin has joined
 118 2012-01-03 01:21:34 zeiris has joined
 119 2012-01-03 01:32:07 b4epoche_ has joined
 120 2012-01-03 01:32:53 jacobwg has quit (Quit: Computer has gone to sleep.)
 121 2012-01-03 01:33:01 b4epoche has quit (Ping timeout: 240 seconds)
 122 2012-01-03 01:33:01 b4epoche_ is now known as b4epoche
 123 2012-01-03 01:34:25 Cablesaurus has joined
 124 2012-01-03 01:34:25 Cablesaurus has quit (Changing host)
 125 2012-01-03 01:34:25 Cablesaurus has joined
 126 2012-01-03 01:36:15 dissipate has quit (Ping timeout: 252 seconds)
 127 2012-01-03 01:40:28 Backburn has quit (Ping timeout: 252 seconds)
 128 2012-01-03 01:41:13 Backburn has joined
 129 2012-01-03 01:51:07 osmosis has quit (Quit: Leaving)
 130 2012-01-03 01:56:47 <luke-jr> sigh, bzr really does have a much saner design
 131 2012-01-03 02:02:55 JZavala has joined
 132 2012-01-03 02:04:39 JZavala has quit (Client Quit)
 133 2012-01-03 02:04:51 JZavala has joined
 134 2012-01-03 02:12:34 JZavala has quit (Ping timeout: 240 seconds)
 135 2012-01-03 02:16:21 dvide has quit ()
 136 2012-01-03 02:23:24 iocor has quit (Quit: Computer has gone to sleep.)
 137 2012-01-03 02:33:09 <gmaxwell> sipa: so on tmpfs on the same system, the keypool fill takes 15 seconds.. so thats still insanely slow, but a big improvement from almost 40.
 138 2012-01-03 02:34:31 taipres has joined
 139 2012-01-03 02:39:13 <jrmithdobbs> gmaxwell: w/e, i just had to wait for 1.44M to write at 17K/s I don't want to hear you're whining about slow
 140 2012-01-03 02:39:16 <jrmithdobbs> ;p
 141 2012-01-03 02:39:19 Sedra- has quit (Remote host closed the connection)
 142 2012-01-03 02:40:02 <taipres> heh
 143 2012-01-03 02:41:38 Sedra has joined
 144 2012-01-03 02:45:46 dan__ has joined
 145 2012-01-03 02:49:54 taipres has quit ()
 146 2012-01-03 03:02:37 marf_away has quit (Ping timeout: 252 seconds)
 147 2012-01-03 03:06:48 Acciaio has joined
 148 2012-01-03 03:08:11 Cablesaurus has quit (Quit: A fine is a tax for doing wrong. A tax is a fine for doing well)
 149 2012-01-03 03:09:51 <Acciaio> hi all,how can I autenticate to mtgox api? example found here -> https://mtgox.com/api#Authentication dont work  :-(
 150 2012-01-03 03:11:21 gavinandresen has left ()
 151 2012-01-03 03:11:36 <pumpkin> #mtgox
 152 2012-01-03 03:15:32 <Acciaio> #mtgox :Cannot join channel (+r) - you need to be identified with services
 153 2012-01-03 03:15:46 <Acciaio> :-(
 154 2012-01-03 03:16:19 <pumpkin> then register and then identify :) it takes a couple of minutes
 155 2012-01-03 03:18:59 slush has quit (Ping timeout: 252 seconds)
 156 2012-01-03 03:21:17 <Acciaio> where I have to register? on mtgox? I have an account on mtgox and how can i identify?
 157 2012-01-03 03:24:18 Joric has joined
 158 2012-01-03 03:26:49 Cablesaurus has joined
 159 2012-01-03 03:26:50 Cablesaurus has quit (Changing host)
 160 2012-01-03 03:26:50 Cablesaurus has joined
 161 2012-01-03 03:37:32 <nanotube> Acciaio: with nickserv. ,,(sl freenode nickserv registration)
 162 2012-01-03 03:37:33 <gribble> http://freenode.net/faq.shtml | ? Just plug your nickserv ... the one you've got registered use ...
 163 2012-01-03 03:42:48 h4ckm3 has joined
 164 2012-01-03 03:45:39 XX01XX has quit (Ping timeout: 248 seconds)
 165 2012-01-03 03:45:44 <Joric> guys do you mind
 166 2012-01-03 03:46:00 <Joric> check out this private key 5KFKMNB2P989YqLZKoWGLNdFvMPA2K7x3GY6cWiF1jGCGKDuvq
 167 2012-01-03 03:46:22 <Joric> the address should be 1DrGossc3QidjzgDXzveCAQGiPWsoiDZ8C
 168 2012-01-03 03:46:42 <Joric> neither pywallet nor bitaddress.org won't understand this key
 169 2012-01-03 03:47:01 <Joric> it might be something with base58 padding? i can't tell
 170 2012-01-03 03:47:56 <Joric> nevermind it was just a typing error
 171 2012-01-03 03:48:05 <rjk2> lol
 172 2012-01-03 03:48:10 <rjk2> sorry you can't use it now
 173 2012-01-03 03:48:14 <rjk2> :p
 174 2012-01-03 03:49:34 <Joric> meh 400 btc you can have it
 175 2012-01-03 03:50:05 <Joric> price falls anyway
 176 2012-01-03 03:53:54 TheSeven has quit (Disconnected by services)
 177 2012-01-03 03:54:05 osmosis has joined
 178 2012-01-03 03:54:07 [7] has joined
 179 2012-01-03 03:54:21 Rabbit67890 has quit (Quit: Rabbit67890)
 180 2012-01-03 03:54:59 finway has joined
 181 2012-01-03 03:55:33 <finway> So, No OP_EVAL, and no 15th Jan deadline ?
 182 2012-01-03 03:59:22 LightRider has quit ()
 183 2012-01-03 04:01:40 finway has quit (Quit: Page closed)
 184 2012-01-03 04:05:37 BurtyB has joined
 185 2012-01-03 04:06:21 BurtyBB has quit (Ping timeout: 260 seconds)
 186 2012-01-03 04:08:02 toffoo has joined
 187 2012-01-03 04:14:11 gjs278 has joined
 188 2012-01-03 04:22:17 MC1984 has quit (Ping timeout: 268 seconds)
 189 2012-01-03 04:22:57 MC1984 has joined
 190 2012-01-03 04:29:34 gjs278 has quit (Ping timeout: 240 seconds)
 191 2012-01-03 04:35:46 AlonzoTG has joined
 192 2012-01-03 04:35:55 <AlonzoTG> om
 193 2012-01-03 04:36:18 <AlonzoTG> I just tried to build bitcoin yet again, same error I've been getting for many many months now: headers.h:39:20: fatal error: db_cxx.h: No such file or directory
 194 2012-01-03 04:36:22 <AlonzoTG> =|
 195 2012-01-03 04:36:53 <AlonzoTG> << gentoo linux; Yes, I have the correct library, Yes it's in a perfectly reasonable location, NO, bitcoin still doesn't have a build system that can find it.
 196 2012-01-03 04:37:04 gfinn has joined
 197 2012-01-03 04:38:50 gjs278 has joined
 198 2012-01-03 04:39:44 dissipate has joined
 199 2012-01-03 04:41:45 <gmaxwell> AlonzoTG: Bitcoin has a makefile, not an automatic buildsystem. If you can't handle modifying it for your system, then perhaps you shouldn't be using gentoo.
 200 2012-01-03 04:42:26 <gmaxwell> And I seem to recall that you didn't, in fact, have the correct versions of the db-cxx headers when we last spoke.
 201 2012-01-03 04:46:34 Turingi has quit (Read error: Connection reset by peer)
 202 2012-01-03 05:00:44 minimoose has quit (Quit: minimoose)
 203 2012-01-03 05:02:38 RobinPKR_ has joined
 204 2012-01-03 05:04:39 <luke-jr> AlonzoTG: emerge bitcoind
 205 2012-01-03 05:04:42 RobinPKR has quit (Ping timeout: 240 seconds)
 206 2012-01-03 05:04:42 RobinPKR_ is now known as RobinPKR
 207 2012-01-03 05:04:55 <luke-jr> gmaxwell: there should be no need to modify the makefile anymore
 208 2012-01-03 05:05:13 <luke-jr> gmaxwell: also, his problem is not Gentoo-specific, but occurs in most distros
 209 2012-01-03 05:05:33 <luke-jr> (because bdb++ headers are not in the default include path)
 210 2012-01-03 05:10:10 BlueMatt has joined
 211 2012-01-03 05:10:15 BlueMatt-mobile has quit (Quit: BlueMatt)
 212 2012-01-03 05:14:29 Diablo-D3 has joined
 213 2012-01-03 05:24:49 Rabbit67890 has joined
 214 2012-01-03 05:36:03 gfinn has quit (Ping timeout: 276 seconds)
 215 2012-01-03 05:37:54 WakiMiko has quit (Ping timeout: 244 seconds)
 216 2012-01-03 05:38:42 WakiMiko has joined
 217 2012-01-03 05:42:02 roconnor has quit (Ping timeout: 260 seconds)
 218 2012-01-03 05:43:31 b4epoche has quit (Read error: Operation timed out)
 219 2012-01-03 05:43:53 b4epoche has joined
 220 2012-01-03 05:47:46 abbe is now known as abbe|luncheon
 221 2012-01-03 05:47:51 abbe is now known as luncheon!gluside@freebsd/developer/ashish|abbe
 222 2012-01-03 05:56:15 Rabbit67890 has quit (Quit: Rabbit67890)
 223 2012-01-03 06:01:06 cj has joined
 224 2012-01-03 06:08:19 Zarutian has quit (Quit: Zarutian)
 225 2012-01-03 06:09:53 <gribble> New news from bitcoinrss: TheBlueMatt pushed to master at bitcoin/gitian.sigs
 226 2012-01-03 06:11:49 watson787 has joined
 227 2012-01-03 06:12:03 Rabbit67890 has joined
 228 2012-01-03 06:14:40 <SomeoneWeird> heh
 229 2012-01-03 06:15:01 <BlueMatt> ;;bitcoinrss
 230 2012-01-03 06:15:01 <gribble> TheBlueMatt pushed to master at bitcoin/gitian.sigs <https://github.com/bitcoin/gitian.sigs/compare/33e5c35329...70b232f00d>
 231 2012-01-03 06:17:56 <nanotube> BlueMatt: i've changed config, so now the announcements will include url
 232 2012-01-03 06:18:09 <BlueMatt> nice
 233 2012-01-03 06:18:18 <BlueMatt> thanks nanotube
 234 2012-01-03 06:18:25 Turingi has joined
 235 2012-01-03 06:18:49 <nanotube> np. let's see how it works out :)
 236 2012-01-03 06:23:42 Rabbit67890 has quit (Quit: Rabbit67890)
 237 2012-01-03 06:25:03 * BlueMatt -> bed
 238 2012-01-03 06:25:24 BlueMatt has quit (Quit: Ex-Chat)
 239 2012-01-03 06:25:37 gjs278 has quit (Ping timeout: 252 seconds)
 240 2012-01-03 06:25:50 BurtyBB has joined
 241 2012-01-03 06:26:55 BitMark has quit (Quit: BitMark)
 242 2012-01-03 06:28:03 BurtyB has quit (Ping timeout: 276 seconds)
 243 2012-01-03 06:39:16 booo has joined
 244 2012-01-03 06:44:19 <gmaxwell> so... ltrace is interesting.
 245 2012-01-03 06:44:37 <gmaxwell> I set bitcoin to generate 1000 new keys then quit, ran it in ltrace:
 246 2012-01-03 06:44:37 <gmaxwell>  92.01 1969.537721      280121      7031 mlock
 247 2012-01-03 06:44:38 <gmaxwell>   1.23   26.424516         533     49547 pthread_mutex_lock
 248 2012-01-03 06:44:44 diki has joined
 249 2012-01-03 06:44:53 <gmaxwell> ------ ----------- ----------- --------- --------------------
 250 2012-01-03 06:45:01 <gmaxwell> % time     seconds  usecs/call     calls      function
 251 2012-01-03 06:46:12 Rabbit67890 has joined
 252 2012-01-03 06:46:49 dan__ has quit (Quit: dan__)
 253 2012-01-03 06:49:03 <gmaxwell> commenting out all mlock in the source makes it ~instantly fast.
 254 2012-01-03 06:49:15 <gmaxwell> jesus christ that was a pain in the ass to figure out.
 255 2012-01-03 06:49:20 <gmaxwell> oprofile sees nothing there.
 256 2012-01-03 06:49:32 <gmaxwell> valgrind/callgrind sees nothing (unsurprising)
 257 2012-01-03 06:49:47 <gmaxwell> strace saw nothing (I'm not sure why).
 258 2012-01-03 06:50:16 <gmaxwell> but ltrace sees it. mlock is #@$@# expensive, I assume because it has to twiddle the page tables then flush the tlbs.
 259 2012-01-03 06:50:37 <Diablo-D3> what are we doing?
 260 2012-01-03 06:50:53 <luke-jr> gmaxwell: in case you missed it, someone informed me that bitcoind mlocks *everything*
 261 2012-01-03 06:51:09 <Diablo-D3> who the fuck uses locks goddamnit
 262 2012-01-03 06:51:24 <Diablo-D3> no, luke just steals the namecoins
 263 2012-01-03 06:51:28 <gmaxwell> luke-jr: it does?
 264 2012-01-03 06:51:37 <luke-jr> gmaxwell: apparently
 265 2012-01-03 06:51:51 <Diablo-D3> I dont really doubt it
 266 2012-01-03 06:52:01 <Diablo-D3> DURR HURR, WE HAVE THREADS, LETS USE LOCKS
 267 2012-01-03 06:52:01 <luke-jr> gmaxwell: some Linux security framework complains about it mlocking too much, is how he noticed
 268 2012-01-03 06:52:26 <Diablo-D3> LOCKS LOCKS LOCKITY LOCKS
 269 2012-01-03 06:52:35 <gmaxwell> well doing so is enormously stupendously slow. if you really want all mlocked you do a mlockall(MCL_FUTURE) .. but the program will crash it it can't mlock more.
 270 2012-01-03 06:52:44 <gmaxwell> Diablo-D3: mlock isn't a lock.
 271 2012-01-03 06:52:52 <gmaxwell> Diablo-D3: man mlock
 272 2012-01-03 06:52:56 <Diablo-D3> gmaxwell: its a memory lock
 273 2012-01-03 06:52:58 <Diablo-D3> erg, m lock
 274 2012-01-03 06:53:16 <Diablo-D3> its part of the suite of functions that people think are legitimate to EVER USE
 275 2012-01-03 06:53:36 <gmaxwell> omg
 276 2012-01-03 06:53:41 <gmaxwell> block chain syncup is 1000x faster.
 277 2012-01-03 06:53:47 <SomeoneWeird> hah
 278 2012-01-03 06:54:00 <gmaxwell> seriously, ... what took >3 hours before just finished in 30 seconds.
 279 2012-01-03 06:54:11 <gmaxwell> omg
 280 2012-01-03 06:55:38 * gmaxwell cries because its so beautiful
 281 2012-01-03 06:58:29 <Diablo-D3> 3 HOURS?!
 282 2012-01-03 06:58:33 <Diablo-D3> what the fuck takes 3 hours!
 283 2012-01-03 06:59:07 <gmaxwell> Diablo-D3: syncing part of the blockchain.
 284 2012-01-03 07:01:19 osmosis has quit (Quit: Leaving)
 285 2012-01-03 07:01:39 <gmaxwell> synced from zero to 140000 in seven minutes!
 286 2012-01-03 07:02:20 <gmaxwell> (it got somewhat slower after that— I assume because it's doing signature validations again, though its still processing many blocks per second)
 287 2012-01-03 07:02:24 <Rabbit67890> PONG :VERNE.FREENODE.NET
 288 2012-01-03 07:02:31 <Diablo-D3> gmaxwell: wait wait wait
 289 2012-01-03 07:02:33 <Diablo-D3> as in
 290 2012-01-03 07:02:38 <Diablo-D3> downloading the blocks?
 291 2012-01-03 07:02:42 <Diablo-D3> in 7 minutes?
 292 2012-01-03 07:03:02 <gmaxwell> Diablo-D3: yes.
 293 2012-01-03 07:03:09 <Diablo-D3> godfuckingdamnit
 294 2012-01-03 07:03:17 <Backburn> i just host the block chain on my CDN heh
 295 2012-01-03 07:03:19 <gmaxwell> well, the last bit is going to take somewhat longer... it's still going.
 296 2012-01-03 07:03:32 dissipate has quit (Ping timeout: 248 seconds)
 297 2012-01-03 07:03:45 <gmaxwell> Backburn: network speed was never the issue, I've been saying this for months.
 298 2012-01-03 07:04:27 <gmaxwell> (well, fsync is _still_ an issue even with the mlock problem removed, but right now I'm syncing to media that its not a problem on)
 299 2012-01-03 07:05:01 chrisb__ has joined
 300 2012-01-03 07:05:04 <Diablo-D3> gmaxwell: its better than 9000 fucking hours
 301 2012-01-03 07:05:22 <gmaxwell> only up to 144000 now.
 302 2012-01-03 07:05:36 larsivi has quit (Ping timeout: 252 seconds)
 303 2012-01-03 07:06:06 <Diablo-D3> stil, a total of what, 10 minutes? 15?
 304 2012-01-03 07:06:18 <Diablo-D3> it took me 3 hours to just do about 5000 blocks
 305 2012-01-03 07:07:15 <gmaxwell> Yea, I'll say when its done. Maybe 20 minutes.
 306 2012-01-03 07:08:36 <gmaxwell> anyways.. removing mlock completely isn't an actual solution... (well, it's a workaround esp for nodes that don't deal with private data)
 307 2012-01-03 07:09:32 mcorlett has quit (Remote host closed the connection)
 308 2012-01-03 07:11:58 booo has quit (Ping timeout: 240 seconds)
 309 2012-01-03 07:13:29 dikidera has joined
 310 2012-01-03 07:13:54 <gmaxwell> :-/
 311 2012-01-03 07:13:55 <gmaxwell> class CDataStream
 312 2012-01-03 07:13:55 <gmaxwell> {
 313 2012-01-03 07:13:55 <gmaxwell> protected: typedef std::vector<char, secure_allocator<char> > vector_type;
 314 2012-01-03 07:14:18 <gmaxwell> I'm C++ incompetent, is _that_ how everything under the @#$@#$@ sun is ending up mlocking?
 315 2012-01-03 07:14:53 diki has quit (Ping timeout: 276 seconds)
 316 2012-01-03 07:16:04 BlueMatt has joined
 317 2012-01-03 07:18:35 <gmaxwell> BlueMatt: !
 318 2012-01-03 07:20:56 <TuxBlackEdo> not sure if this is the right channel to ask, but anyone here know of/use ga-bitbot?
 319 2012-01-03 07:21:42 <BlueMatt> gmaxwell: was just reading logs, wtf?
 320 2012-01-03 07:21:47 dikidera is now known as diki
 321 2012-01-03 07:21:56 <BlueMatt> gmaxwell: so removing the one mlock call in bitcoin makes chain download 10000x faster?
 322 2012-01-03 07:23:35 <BlueMatt> (sorry, 4 mlock calls)
 323 2012-01-03 07:23:41 <midnightmagic> mlock is being applied to incoming block data, or mlock is being applied to keygen?
 324 2012-01-03 07:23:41 <gmaxwell> COMPLETE SYNC IN 28 minutes!!!
 325 2012-01-03 07:23:50 <BlueMatt> no way in hell
 326 2012-01-03 07:23:54 <gmaxwell> Yep!
 327 2012-01-03 07:24:07 <gmaxwell> midnightmagic: to *
 328 2012-01-03 07:24:30 <BlueMatt> how did it not used to be that fast (before we added encryption?)
 329 2012-01-03 07:24:39 <BlueMatt> also, why is everyone finding bugs in my code today
 330 2012-01-03 07:24:45 <midnightmagic> it makes sense to apply it to private data, else key recovery can retrieve it with swap tricks
 331 2012-01-03 07:24:48 <BlueMatt> also, why are there so many bugs in my code that no one found until today
 332 2012-01-03 07:24:50 <BlueMatt> also, wtf???
 333 2012-01-03 07:25:03 <BlueMatt> midnightmagic: its written to only apply to private data...
 334 2012-01-03 07:25:06 <gmaxwell> Because I started testing again.
 335 2012-01-03 07:25:12 <gmaxwell> I have this effect on code bases.
 336 2012-01-03 07:27:24 wasabi1 has joined
 337 2012-01-03 07:28:10 <BlueMatt> can anyone duplicate gmaxwell's results?
 338 2012-01-03 07:28:37 <midnightmagic> as luck has it, I am *exactly right now* just raising up a fresh vm and about to compile stock btc on it.
 339 2012-01-03 07:28:49 <midnightmagic> what's the patch
 340 2012-01-03 07:29:21 <BlueMatt> in serialize.h and crypter.cpp, comment out mlock calls
 341 2012-01-03 07:29:25 wasabi2 has quit (Ping timeout: 252 seconds)
 342 2012-01-03 07:29:28 <BlueMatt> should be a total of 5
 343 2012-01-03 07:29:49 <midnightmagic> k i'll head towards that..
 344 2012-01-03 07:29:52 <BlueMatt> gmaxwell: well heres your damn bug, who the fuck put secure_allocator in CDataStream???
 345 2012-01-03 07:30:06 <BlueMatt> oh, probably for key export...
 346 2012-01-03 07:30:07 <BlueMatt> wtf?
 347 2012-01-03 07:31:04 <gmaxwell> https://people.xiph.org/~greg/omg_go_fast.patch
 348 2012-01-03 07:31:16 <gmaxwell> BlueMatt: thats what I said above!
 349 2012-01-03 07:31:42 <gmaxwell> Keep in mind, that patch just removes all the mlock.. bad for encrypted wallet security.
 350 2012-01-03 07:32:19 <BlueMatt> gmaxwell: what the stuff about CDataStream?
 351 2012-01-03 07:32:21 <midnightmagic> bad for any private data security, including txn
 352 2012-01-03 07:32:26 <gmaxwell> And you're not going to get the _28 minute_ sync unless you're on a fast network and have a fs/media where fsync doesn't hurt.  but it still should be enormously faster. (or at least it is for me even with a slow disk)
 353 2012-01-03 07:32:33 <BlueMatt> midnightmagic: txn are not private...
 354 2012-01-03 07:32:41 pickett has quit (Ping timeout: 252 seconds)
 355 2012-01-03 07:33:04 <gmaxwell> BlueMatt: see up 23:10 < gmaxwell> class CDataStream
 356 2012-01-03 07:33:07 <midnightmagic> retrieving txn origins would be uncomfortable for someone who expected his swap not to be contaminated with evidence of txn sends..
 357 2012-01-03 07:33:11 <midnightmagic> unenecrypted..
 358 2012-01-03 07:33:14 <BlueMatt> gmaxwell: oh...sorry cant read apparently
 359 2012-01-03 07:33:23 <gmaxwell> midnightmagic: well, that would be exposed already.
 360 2012-01-03 07:33:40 <midnightmagic> where?
 361 2012-01-03 07:33:43 <gmaxwell> midnightmagic: tons of stuff is _not_ mlocked.
 362 2012-01-03 07:34:04 <gmaxwell> There is just enough stuff mlocked to create horiffic performance, but not enough to e.g. hide your addresses.
 363 2012-01-03 07:34:28 <midnightmagic> assumption on my part then.
 364 2012-01-03 07:34:31 <gmaxwell> midnightmagic: e.g. non of the bdb memory is mlocked for sure, plus lots of other stuff.
 365 2012-01-03 07:34:52 pickett has joined
 366 2012-01-03 07:35:19 <midnightmagic> mm
 367 2012-01-03 07:35:30 <gmaxwell> midnightmagic: if that were a goal, I'm afraid the first step would be to throw out the software and rewrite it all.
 368 2012-01-03 07:36:12 <gmaxwell> (there are allocations all over the @#$@ place, so the only way to do it would be to mlockall(mcl_future) — and that would crash on all systems because we use _far_ too much memory for that)
 369 2012-01-03 07:36:28 <midnightmagic> i guess i'd assumed that similar practices to openssh/et al would be in satoshi's radar. guess he just wanted to get the software written.
 370 2012-01-03 07:36:33 <BlueMatt> midnightmagic: txn are not encrypted in wallet
 371 2012-01-03 07:36:54 <gmaxwell> hm. Res side of bitcoind of 70m now too.
 372 2012-01-03 07:36:57 dissipate has joined
 373 2012-01-03 07:37:02 BlueMatt has quit (Quit: Ex-Chat)
 374 2012-01-03 07:37:15 <gmaxwell> midnightmagic: ssh doesn't hide your identity in memory.. or the hosts you connect to.. only keying data.
 375 2012-01-03 07:37:29 BlueMatt has joined
 376 2012-01-03 07:38:25 <midnightmagic> no, because there's not a lot of point in hiding a one-hop connection txn, and state must be preserved to help detect host key changes.
 377 2012-01-03 07:39:00 <BlueMatt> gmaxwell: https://github.com/bitcoin/bitcoin/commit/223b6f1b#diff-18
 378 2012-01-03 07:39:05 <BlueMatt> commit that killed it
 379 2012-01-03 07:39:34 groffer has quit (Ping timeout: 276 seconds)
 380 2012-01-03 07:39:34 devrandom has quit (Ping timeout: 276 seconds)
 381 2012-01-03 07:40:06 <gmaxwell> Thanks, I was just starting to look.. the bitcoin-qt stuff made a @#$@ mess of the history.
 382 2012-01-03 07:40:27 <gmaxwell> oh no, that didn't do it.
 383 2012-01-03 07:40:29 <BlueMatt> why the fuck were any functional changes made in that commit???
 384 2012-01-03 07:40:39 <BlueMatt> it changed to secure_allocator in CDataStream
 385 2012-01-03 07:40:53 <gmaxwell> No it didn't.
 386 2012-01-03 07:40:54 <BlueMatt> oh, nope Im a dumbass
 387 2012-01-03 07:40:55 <Joric> how to get back to old db version? i hate qt
 388 2012-01-03 07:41:04 <gmaxwell> -    typedef vector<char, secure_allocator<char> > vector_type;
 389 2012-01-03 07:41:04 <gmaxwell> +    typedef std::vector<char, secure_allocator<char> > vector_type;
 390 2012-01-03 07:41:07 <BlueMatt> god why can I not focus at all today...
 391 2012-01-03 07:41:37 <gmaxwell> yea, I'm trying to find it, but that commit is off on some crazy branch where Wladimir wrote every line of code.
 392 2012-01-03 07:42:21 <BlueMatt> wait, nope I have that secure_allocator was in a commit by s_nakamoto
 393 2012-01-03 07:42:31 <BlueMatt> (before secure_allocator mlocked)
 394 2012-01-03 07:42:43 <BlueMatt> so its when secure_allocator was changed to mlock
 395 2012-01-03 07:43:52 <gmaxwell> Yea, which is what you did, I guess.
 396 2012-01-03 07:44:00 <BlueMatt> no, that wasnt me
 397 2012-01-03 07:44:05 <BlueMatt> that is when SecureString was added
 398 2012-01-03 07:44:35 <BlueMatt> c1aacf0b
 399 2012-01-03 07:45:03 <gmaxwell> c1aacf0b
 400 2012-01-03 07:45:05 <gmaxwell> yea.
 401 2012-01-03 07:45:05 <BlueMatt> oh, but it was part of the encryption pull
 402 2012-01-03 07:45:08 <BlueMatt> that I wrote...
 403 2012-01-03 07:45:10 <BlueMatt> goddamit
 404 2012-01-03 07:45:15 d4de has quit (Ping timeout: 248 seconds)
 405 2012-01-03 07:45:25 <BlueMatt> alway my goddamn fault of late it seems...
 406 2012-01-03 07:45:39 <gmaxwell> This is what you get for being productive.
 407 2012-01-03 07:45:48 <gmaxwell> If you were more like me you'd insert no faults!
 408 2012-01-03 07:46:29 <BlueMatt> while you are being productive and benchmarking code, do you feel like benchmarking and faul-testing something Ive been working on?
 409 2012-01-03 07:47:03 <midnightmagic> new machine raised, patch committed, building bitcoind
 410 2012-01-03 07:47:04 <gmaxwell> In any case, options seem to be: write our own malloc() that uses a pre-mlocked arena... and/or seperate off the 'secure_allocator' with a 'really_secure_allocator' which is only used on the the keying material.
 411 2012-01-03 07:47:17 * BlueMatt votes for #2
 412 2012-01-03 07:47:39 * BlueMatt goes to implement
 413 2012-01-03 07:48:31 <gmaxwell> Yea. Thats my preference too.. though, ... seeing how CDataStream works.. meh, it's already a performance problem even without the mlock making it horiffic. (it's creating a LOT of allocator calls)
 414 2012-01-03 07:48:46 <BlueMatt> though can I ask why CDataStream gets secure_allocated to begin with?
 415 2012-01-03 07:49:05 <gmaxwell> I don't know.
 416 2012-01-03 07:49:10 <BlueMatt> dealloc used to clear it, but thats also a waste if we dont need it...
 417 2012-01-03 07:49:48 <gmaxwell> yea, ... well. the code should be carefully audited to make sure private keys never get stored in one (e.g. in the process of signing) I guess.
 418 2012-01-03 07:49:55 <gmaxwell> if not, then I don't think they need to clear.
 419 2012-01-03 07:50:00 <gmaxwell> and yes, that should be a lot faster.
 420 2012-01-03 07:50:13 <BlueMatt> does key export use CDataStream?
 421 2012-01-03 07:50:19 <gmaxwell> But just going back to the old behavior would last least make us no less secure than we were.
 422 2012-01-03 07:50:41 <BlueMatt> not a big deal, Ive got a plane ride to audit tomorrow
 423 2012-01-03 07:51:08 <gmaxwell> probably, but if you're exporting.. you're probably getting that data all over unlocked memory in any case. ::shrugs:: .. though clearing is kinda prudent.. though oy, bad for performance:
 424 2012-01-03 07:51:35 Rabbit67890 has quit (Quit: Rabbit67890)
 425 2012-01-03 07:51:42 <gmaxwell> ends up freshinging it in cache just to throw it away.
 426 2012-01-03 07:51:54 <midnightmagic> downloading blockchain.
 427 2012-01-03 07:52:03 <midnightmagic> curheight 22k
 428 2012-01-03 07:52:07 Rabbit67890_ has joined
 429 2012-01-03 07:52:39 <BlueMatt> fix: https://github.com/TheBlueMatt/bitcoin/commit/03f238d86e497315e595f74cc4721a57a4b63dd0
 430 2012-01-03 07:52:47 <BlueMatt> (to be pull-requested after audit)
 431 2012-01-03 07:52:59 <gmaxwell> midnightmagic: 14:20 < gmaxwell> hmph. weird. seeing really slow syncup off the network. Three hours and twenty five minutes and it only made it up to block 36448,  with very low cpu/disk IO the whole time.
 432 2012-01-03 07:53:19 <BlueMatt> CDataStream does not exist in wallet.*, thats a great sign
 433 2012-01-03 07:53:53 <midnightmagic> curheight 43k
 434 2012-01-03 07:55:03 <gmaxwell> midnightmagic: it'll slow down some and become cpu bound at 140k or so. (wherever the highest checkpoint is)
 435 2012-01-03 07:55:54 <gmaxwell> (the code doesn't do ECDSA validation below the highest checkpoint)
 436 2012-01-03 07:56:20 Rabbit67890_ is now known as Rabbit67890
 437 2012-01-03 07:57:49 <gmaxwell> BlueMatt: the secure allocator probably need to be changed some too, but its less urgent.
 438 2012-01-03 07:59:23 <gmaxwell> mlock is damn slow (0.28 seconds per call for me, according to ltrace).. that slow enough that its making keypool refill take too darn long.
 439 2012-01-03 07:59:55 <BlueMatt> ok, only place CDataStream needs to be secure: reading wallet.dat in db.*
 440 2012-01-03 08:00:14 <gmaxwell> BlueMatt: why does it need to be secure there?
 441 2012-01-03 08:00:25 <BlueMatt> oh wait, it doesnt
 442 2012-01-03 08:00:29 <gmaxwell> :)
 443 2012-01-03 08:01:11 <gmaxwell> but if only a very few things are mlocking ... we can fix that pretty easily.
 444 2012-01-03 08:01:59 <BlueMatt> https://github.com/bitcoin/bitcoin/pull/740
 445 2012-01-03 08:02:31 <gmaxwell> BlueMatt: we really need to get the jenkins setup performing automated tests.. e.g. having it run a build that times bringing up a new node.
 446 2012-01-03 08:02:51 <BlueMatt> gmaxwell: it does, but the vm is too unreliable to rely on chain download times
 447 2012-01-03 08:03:09 <gmaxwell> It would have caught this.
 448 2012-01-03 08:03:18 <BlueMatt> gmaxwell: it does that exact test...
 449 2012-01-03 08:03:19 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 740 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/740>
 450 2012-01-03 08:03:32 <BlueMatt> thanks gribble ,,(botsnack)
 451 2012-01-03 08:03:33 RazielZ has joined
 452 2012-01-03 08:03:33 <gribble> Forget the snack, just send me some bitcoins at 1MgD6rah5zUgEGYZnNmdpnXMaDR3itKYzU :)
 453 2012-01-03 08:03:45 <midnightmagic> curheight 97k, 30% cpu
 454 2012-01-03 08:03:57 <luke-jr> BlueMatt: that patch would be much nicer if you just typedef std::vector<char> vector_type; :P
 455 2012-01-03 08:04:10 <BlueMatt> luke-jr: yea, but the resulting code wouldnt be
 456 2012-01-03 08:04:18 <luke-jr> yes it would :p
 457 2012-01-03 08:04:21 <BlueMatt> (or would be more standard with other bitcoin code)
 458 2012-01-03 08:04:58 <luke-jr> the typedef means you don't need to change 20 lines if it every changes type
 459 2012-01-03 08:05:15 <luke-jr> actually, that one should probably be a template with a typedef on it
 460 2012-01-03 08:05:18 <BlueMatt> but you are defining std::vector<char>
 461 2012-01-03 08:05:19 gjs278 has joined
 462 2012-01-03 08:05:25 <luke-jr> …
 463 2012-01-03 08:05:37 <BlueMatt> meh
 464 2012-01-03 08:06:47 <BlueMatt> luke-jr: changed, happy?
 465 2012-01-03 08:08:20 chmod755 has joined
 466 2012-01-03 08:08:21 <gribble> New news from bitcoinrss: TheBlueMatt commented on pull request 740 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/740#issuecomment-3337231>
 467 2012-01-03 08:08:21 <gribble> New news from bitcoinrss: luke-jr commented on pull request 740 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/740#issuecomment-3337214>
 468 2012-01-03 08:08:26 * BlueMatt -> actually to bed instead of reading irc logs right before going to bed and waking up thanks to gmaxwell's crazyness...
 469 2012-01-03 08:08:33 <luke-jr> :p
 470 2012-01-03 08:08:44 <midnightmagic> crazIness
 471 2012-01-03 08:08:49 * midnightmagic ducks
 472 2012-01-03 08:09:12 * BlueMatt cant spell, especially after a crazy day where his mental facilities have been so far off its not even funny, plus hes tired
 473 2012-01-03 08:09:37 <BlueMatt> (on that subject can someone check my CDataStream grepping?)
 474 2012-01-03 08:09:38 <midnightmagic> BlueMatt should go to sleep and stop worrying about things that can wait until tomorrow. :)
 475 2012-01-03 08:10:26 BlueMatt has quit (Quit: Ex-Chat)
 476 2012-01-03 08:13:54 <midnightmagic> slowing now. 111k
 477 2012-01-03 08:13:55 <gribble> New news from bitcoinrss: gmaxwell commented on pull request 740 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/740#issuecomment-3337245>
 478 2012-01-03 08:14:00 <midnightmagic> very very low cpu usage.
 479 2012-01-03 08:14:06 booo has joined
 480 2012-01-03 08:14:34 <gmaxwell> midnightmagic: cpu use won't go up until 140xxx
 481 2012-01-03 08:15:26 <gmaxwell> You might just be getting network throughtput bound now with the bigger blocks.
 482 2012-01-03 08:16:37 imsaguy2 has quit (Remote host closed the connection)
 483 2012-01-03 08:21:24 <gmaxwell> BlueMattBot: alas, your pull doesn't actually build for me.
 484 2012-01-03 08:21:24 <BlueMattBot> gmaxwell you may not issue bot commands in this chat!
 485 2012-01-03 08:24:37 * gmaxwell reminds BlueMattBot of The Second Law.
 486 2012-01-03 08:24:51 <midnightmagic> +1
 487 2012-01-03 08:25:41 molecular has quit (Read error: Operation timed out)
 488 2012-01-03 08:26:32 molecular has joined
 489 2012-01-03 08:27:12 <gmaxwell> I'm betting that this mlock fix will also improve the performance I've had with mining..
 490 2012-01-03 08:27:32 <gmaxwell> had some annoyance with bitcoin being unresponsive for a second or so when a new block comes in...
 491 2012-01-03 08:28:03 booo has quit (Read error: Operation timed out)
 492 2012-01-03 08:28:10 <midnightmagic> 123k and I am definitely not running into bandwidth issues..  total incoming b/w is like 120k
 493 2012-01-03 08:28:21 sneak has quit (Ping timeout: 268 seconds)
 494 2012-01-03 08:28:41 <midnightmagic> how big's your mining wallet?
 495 2012-01-03 08:28:58 sneak has joined
 496 2012-01-03 08:28:58 sneak has quit (Changing host)
 497 2012-01-03 08:28:58 sneak has joined
 498 2012-01-03 08:29:50 <gmaxwell> midnightmagic: many inputs.
 499 2012-01-03 08:30:36 wasabi1 has quit (Ping timeout: 252 seconds)
 500 2012-01-03 08:30:39 <midnightmagic> disk i/o is... 4MB/s and so on..
 501 2012-01-03 08:30:56 <gmaxwell> midnightmagic: well, time to fix the _next_ issue.
 502 2012-01-03 08:30:58 <gmaxwell> :)
 503 2012-01-03 08:30:59 <midnightmagic> 125k, total bog.
 504 2012-01-03 08:31:35 <midnightmagic> when i mine into an empty wallet, i don't have to worry about wallet flushes gumming me up
 505 2012-01-03 08:31:55 <midnightmagic> accidental getinfo by some script i wrote that i never disabled.. etc.
 506 2012-01-03 08:32:22 <gmaxwell> setting up an empty wallet node to mine aagainst was actually what inspired me to setup another node eariler today and I've been finding bugs since then. :)
 507 2012-01-03 08:33:11 <midnightmagic> i only ever noticed the problem because my minin return during the merged-mining initial rush was..  pathetic. like.. 1% of what it should have been.
 508 2012-01-03 08:33:33 imsaguy2 has joined
 509 2012-01-03 08:33:34 imsaguy2 has quit (Changing host)
 510 2012-01-03 08:33:34 imsaguy2 has joined
 511 2012-01-03 08:33:39 <midnightmagic> totally screwed me because i'd calculated in advance what i was going to make a pre-sold them, expecting a crash in the price.
 512 2012-01-03 08:34:05 <gmaxwell> midnightmagic: yea, I expected a crash too.. came much later than expected!
 513 2012-01-03 08:34:18 <midnightmagic> wayyyy later. i didn't understand that at all
 514 2012-01-03 08:34:39 <gmaxwell> I sold a bunnnnch and then it went way up later.
 515 2012-01-03 08:34:46 <midnightmagic> lol
 516 2012-01-03 08:34:56 <midnightmagic> stupid weird namecoin dynamics anyway
 517 2012-01-03 08:37:01 <midnightmagic> kvm is way faster than i expected it to be
 518 2012-01-03 08:37:15 <gmaxwell> midnightmagic: if you get bored of watching that node... undo the patch and nuke it... I'd not expect it to be synced before 12 hours was up. :)
 519 2012-01-03 08:37:25 <gmaxwell> midnightmagic: yea, KVM is fast.
 520 2012-01-03 08:37:33 <midnightmagic> ok, nuking.
 521 2012-01-03 08:37:59 <midnightmagic> need a pristine base for qcow2 branchpoint anyway
 522 2012-01-03 08:39:10 <cjdelisle> on any modernish processor, kvm is essentially native speed
 523 2012-01-03 08:39:10 <gmaxwell> midnightmagic: Did I tell you I'm running p2pool now? I'm quite impressed with it. It's come a long way.
 524 2012-01-03 08:40:04 <midnightmagic> very nice. :) i forget now, the individual payouts are by the individual right?
 525 2012-01-03 08:40:25 <midnightmagic> forrestv isn't doing centralized payouts like i think he used to be?
 526 2012-01-03 08:40:36 <gmaxwell> midnightmagic: Correct. It's eligius style payouts.
 527 2012-01-03 08:40:52 <gmaxwell> The pool uses a merged mining chain to agree on shares for a PPLNS decision.
 528 2012-01-03 08:41:13 <gmaxwell> The coinbase txn pays according to the consensus (and if not, your shares aren't valid for the pool)
 529 2012-01-03 08:41:29 <midnightmagic> i must've asked this before..  how does it stop me from sending along non-solve shares but keeping the winnings for myself?
 530 2012-01-03 08:41:37 <gmaxwell> the merged chain has a mean time of 10 seconds.. so lots of stales on it, but all that matters is your relative stale rate.
 531 2012-01-03 08:41:40 devrandom has joined
 532 2012-01-03 08:42:09 <gmaxwell> midnightmagic: same way any pool does: you send your peers the failed candidates that prove that you were trying to pay according to the consensus.
 533 2012-01-03 08:43:06 <gmaxwell> where 'failed' means not difficulty enough to be a solution but at least the p2pshare difficulty (adapts to keep the mean time to 10 seconds)
 534 2012-01-03 08:44:01 <gmaxwell> Works ducky with namecoin merged mining too, though the merged mining part is just solo.  Even easier to setup than any other merged mining solution.
 535 2012-01-03 08:44:04 <midnightmagic> and the solve has a pool midstate or whatever, so if you do find a solve, it already belongs to the pool
 536 2012-01-03 08:44:13 <gmaxwell> midnightmagic: right.
 537 2012-01-03 08:44:46 Fnar has quit (Quit: Client exiting)
 538 2012-01-03 08:44:59 <midnightmagic> nice.  so I guess there's no more reason not to switch to p2pool..  all my original objections are gone. no more central payouts..
 539 2012-01-03 08:45:18 <midnightmagic> and the more of us there are, the stronger our shared anonymity
 540 2012-01-03 08:45:31 <gmaxwell> Indeed. I'm .. kind of identifyable on it right now.
 541 2012-01-03 08:45:34 groffer has joined
 542 2012-01-03 08:45:40 <midnightmagic> you are
 543 2012-01-03 08:45:42 <midnightmagic> ?
 544 2012-01-03 08:45:46 <midnightmagic> for your hashrate?
 545 2012-01-03 08:46:07 <forrestv> currently 38% of the p2pool hashrate is going to .. 14ezpf2E6pK3A4EWibdPYWZSs442NtX1Ft
 546 2012-01-03 08:46:10 <forrestv> i wonder who that is :P
 547 2012-01-03 08:46:33 <gmaxwell> yea....
 548 2012-01-03 08:46:35 <midnightmagic> is it possible to chew through addresses for shares?
 549 2012-01-03 08:47:08 <gmaxwell> right now it pulls an address at startup, though I don't see any technical reason you couldn't split it up or rotate.
 550 2012-01-03 08:47:39 <midnightmagic> lol so what is your p2pool hashrate then? :)
 551 2012-01-03 08:47:40 <gmaxwell> would be kinda lame if enough was done to bloat the coinbase, but ::shrugs::
 552 2012-01-03 08:48:14 <forrestv> midnightmagic, currently 25GH/s
 553 2012-01-03 08:48:41 <midnightmagic> for the whole pool?
 554 2012-01-03 08:48:58 <gmaxwell> midnightmagic: well, only have about 9GH/s on it. I guess I'll move the rest soon.
 555 2012-01-03 08:49:36 <gmaxwell> Yea, it's currently small. But hey, improvement on solo.. but you still retain the same amount of txn selection autonomy. And you get fees, and the confidence that a pool operator isn't robbing you blind.
 556 2012-01-03 08:50:00 <midnightmagic> mmm.. fees!  yeah for sure.
 557 2012-01-03 08:50:12 <forrestv> midnightmagic, yeah, see http://u.forre.st/p2pool/600.png for history
 558 2012-01-03 08:50:31 <midnightmagic> cool!
 559 2012-01-03 08:50:37 <gmaxwell> you can see where I recently came in. :)
 560 2012-01-03 08:50:57 larsivi has joined
 561 2012-01-03 08:51:04 <midnightmagic> i'll have to put some on it, but i guess i keep saying that and doing nothing..
 562 2012-01-03 08:51:51 <midnightmagic> lol  yeah IMO that's the future of mining. at a certain point, really this or something like it should be integrated into -main
 563 2012-01-03 08:53:01 <midnightmagic> apparently i have some miners somewhere still working on deepbit, but you think i can find them? trickling along..
 564 2012-01-03 08:53:13 abragin has joined
 565 2012-01-03 08:53:13 abragin has quit (Changing host)
 566 2012-01-03 08:53:13 abragin has joined
 567 2012-01-03 08:53:36 <forrestv> it's not yet a complete solution - the share difficulty is proportional to the pool size, which will make it difficult for small miners
 568 2012-01-03 08:53:44 <forrestv> i'm working on techniques to make it more scalable, though
 569 2012-01-03 08:54:02 booo has joined
 570 2012-01-03 08:54:09 <gmaxwell> forrestv: yea... and unfortunately the use-p2pool as a pool doesn't work great due to the fast chain's stales.
 571 2012-01-03 08:54:33 <gmaxwell> otherwise I'd say that p2pool would be a boon for small centeralized pools too..
 572 2012-01-03 08:56:09 <gmaxwell> forrestv: in any case, as is it's pretty much an ideal solution for someone who is big enough to be on the fence about solo mining.
 573 2012-01-03 08:57:19 <forrestv> a separate p2pool with a share period of something like a minute would make using it as a pool work...
 574 2012-01-03 08:57:47 <midnightmagic> can i set my own difficulty in it?
 575 2012-01-03 08:58:24 <forrestv> midnightmagic, you mean in current-p2pool? no, it's automatically set to regulate the time between shares
 576 2012-01-03 08:58:32 <midnightmagic> ok
 577 2012-01-03 08:58:38 <midnightmagic> ah, so attractive.
 578 2012-01-03 08:59:15 mcorlett has joined
 579 2012-01-03 08:59:16 <gmaxwell> it's at 51 right now.
 580 2012-01-03 09:00:45 the_batman has quit (Read error: Connection reset by peer)
 581 2012-01-03 09:01:05 the_batman has joined
 582 2012-01-03 09:02:31 Rabbit67890 has quit (Quit: Rabbit67890)
 583 2012-01-03 09:04:05 <gmaxwell> Okay, way late to bed... hopefully I'll wake tomorrow to find all kinds of wonderful fixes and more things to measure.
 584 2012-01-03 09:04:12 <midnightmagic> :)
 585 2012-01-03 09:04:14 <gmaxwell> midnightmagic: how's that resync going?
 586 2012-01-03 09:04:14 <midnightmagic> night man
 587 2012-01-03 09:04:27 <midnightmagic> oh, I nuked it, it bogged down around 120k
 588 2012-01-03 09:04:59 danbri has joined
 589 2012-01-03 09:05:03 <midnightmagic> it would be nice if I could tell it to leech off my local trusted node so i didn't have to shut it down and copy the blockchain
 590 2012-01-03 09:05:21 <gmaxwell> --connect but it still validates. :)
 591 2012-01-03 09:05:33 chmod755 has quit (Ping timeout: 258 seconds)
 592 2012-01-03 09:07:43 mcorlett has quit (Remote host closed the connection)
 593 2012-01-03 09:07:58 darkee has quit (Ping timeout: 276 seconds)
 594 2012-01-03 09:09:15 darkee has joined
 595 2012-01-03 09:11:16 watson787 has quit (Ping timeout: 240 seconds)
 596 2012-01-03 09:12:45 sneak has quit (Ping timeout: 268 seconds)
 597 2012-01-03 09:13:03 sneak has joined
 598 2012-01-03 09:15:45 <midnightmagic> LOL "Now FPGA mining at a whole 25 MHash/sec. Wow!" (makomk sig) awesome!
 599 2012-01-03 09:16:31 <Diablo-D3> http://naurunappula.com/748185/tehosekoitin.jpg
 600 2012-01-03 09:21:31 <midnightmagic> uh..  forrestv did you merge the getauxblock patches successfully with luke's coinbase uniqueless bugfix patch?
 601 2012-01-03 09:22:13 <forrestv> midnightmagic, getauxblock is only present in namecoin. are you talking about getmemorypool?
 602 2012-01-03 09:22:37 <midnightmagic> woops.
 603 2012-01-03 09:22:55 <forrestv> pretty sure his patch wouldn't affect getmemorypool, because getmemorypool doesn't create a coinbase transaction, it just returns what you need to construct one
 604 2012-01-03 09:23:37 <midnightmagic> no, i'm tired of being blocked by my procrastination in merging vince's bitcoind patch with the ongoing march of main bitcoind progress
 605 2012-01-03 09:24:58 <midnightmagic> okay then.. hrm..
 606 2012-01-03 09:28:03 wasabi1 has joined
 607 2012-01-03 09:33:24 erus` has joined
 608 2012-01-03 09:36:45 slush has joined
 609 2012-01-03 09:55:04 b4epoche_ has joined
 610 2012-01-03 09:56:33 b4epoche has quit (Ping timeout: 268 seconds)
 611 2012-01-03 09:56:33 b4epoche_ is now known as b4epoche
 612 2012-01-03 09:58:54 larsivi has quit (Ping timeout: 252 seconds)
 613 2012-01-03 10:06:04 h4ckm3 has quit (Remote host closed the connection)
 614 2012-01-03 10:06:07 larsivi has joined
 615 2012-01-03 10:06:31 davout has joined
 616 2012-01-03 10:07:07 mcorlett has joined
 617 2012-01-03 10:18:12 [Tycho] has joined
 618 2012-01-03 10:18:55 da2ce7 has joined
 619 2012-01-03 10:23:34 ThomasV has joined
 620 2012-01-03 10:28:14 <sipa> q wait what
 621 2012-01-03 10:28:43 wasabi2 has joined
 622 2012-01-03 10:28:46 <sipa> CDataStream used the secure allocator?
 623 2012-01-03 10:29:00 <sipa> since always?
 624 2012-01-03 10:29:48 <sipa> why didn't we notice a performance regression when mlock was introduced?
 625 2012-01-03 10:30:47 wasabi1 has quit (Ping timeout: 240 seconds)
 626 2012-01-03 10:31:33 <sipa> and 28 minutes for block sync
 627 2012-01-03 10:32:18 <sipa> it was way more than that before mlock was introduced, no?
 628 2012-01-03 10:37:50 Clipse has joined
 629 2012-01-03 10:49:32 dissipate has quit (Remote host closed the connection)
 630 2012-01-03 11:02:36 slush has quit (Ping timeout: 240 seconds)
 631 2012-01-03 11:05:08 <gribble> New news from bitcoinrss: laanwj commented on issue 734 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/734#issuecomment-3338486>
 632 2012-01-03 11:05:08 <gribble> New news from bitcoinrss: laanwj closed issue 734 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/734>
 633 2012-01-03 11:05:08 <gribble> New news from bitcoinrss: laanwj opened pull request 741 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/741>
 634 2012-01-03 11:07:08 Joric has quit (Ping timeout: 255 seconds)
 635 2012-01-03 11:10:54 Joric has joined
 636 2012-01-03 11:10:54 Joric has quit (Changing host)
 637 2012-01-03 11:10:54 Joric has joined
 638 2012-01-03 11:11:34 Joric has quit (Client Quit)
 639 2012-01-03 11:15:27 booo has quit (Ping timeout: 252 seconds)
 640 2012-01-03 11:16:50 slush has joined
 641 2012-01-03 11:19:11 slush1 has joined
 642 2012-01-03 11:21:33 marf_away has joined
 643 2012-01-03 11:21:34 slush has quit (Ping timeout: 260 seconds)
 644 2012-01-03 11:27:08 slush has joined
 645 2012-01-03 11:27:35 slush1 has quit (Ping timeout: 240 seconds)
 646 2012-01-03 11:35:27 <CIA-100> DiabloMiner: Patrick McFarland master * r0b8a06b / src/main/java/com/diablominer/DiabloMiner/DiabloMiner.java : Fix silly bug in multipool pool advancing - http://git.io/ImNT3Q https://github.com/Diablo-D3/DiabloMiner/commit/0b8a06b9f648a6b033acc722ea271833c603c948
 647 2012-01-03 11:37:08 torsthaldo has joined
 648 2012-01-03 11:37:37 Joric has joined
 649 2012-01-03 11:41:41 datagutt has joined
 650 2012-01-03 11:42:45 devrandom has quit (Remote host closed the connection)
 651 2012-01-03 11:42:45 groffer has quit (Remote host closed the connection)
 652 2012-01-03 11:43:07 devrandom has joined
 653 2012-01-03 11:43:08 groffer has joined
 654 2012-01-03 12:09:20 da2ce7 has quit (Ping timeout: 276 seconds)
 655 2012-01-03 12:18:08 coingenuity has left ()
 656 2012-01-03 12:20:21 larsivi has quit (Ping timeout: 252 seconds)
 657 2012-01-03 12:20:26 Acciaio has quit (Quit: Ex-Chat)
 658 2012-01-03 12:37:30 larsivi has joined
 659 2012-01-03 12:41:01 theorbtwo has joined
 660 2012-01-03 12:43:05 davout has quit (Remote host closed the connection)
 661 2012-01-03 12:49:55 <luke-jr> sipa: since always
 662 2012-01-03 12:50:49 <luke-jr> forrestv: actually, getmemorypool *strips* the coinbase from a normal work…
 663 2012-01-03 12:51:18 <luke-jr> midnightmagic: I'm not sure why anyone would merge vince's patch :P
 664 2012-01-03 12:54:46 rdponticelli has quit (Read error: Connection reset by peer)
 665 2012-01-03 12:59:34 iocor has joined
 666 2012-01-03 13:04:48 rdponticelli has joined
 667 2012-01-03 13:06:11 p0s has joined
 668 2012-01-03 13:08:40 pumpkin is now known as copumpkin
 669 2012-01-03 13:19:31 roconnor has joined
 670 2012-01-03 13:19:31 abragin has quit (Read error: Connection reset by peer)
 671 2012-01-03 13:21:02 abragin has joined
 672 2012-01-03 13:21:02 abragin has quit (Changing host)
 673 2012-01-03 13:21:02 abragin has joined
 674 2012-01-03 13:26:00 BurtyBB has quit (Quit: Leaving)
 675 2012-01-03 13:26:13 [Tycho] has quit (Remote host closed the connection)
 676 2012-01-03 13:26:33 dvide has joined
 677 2012-01-03 13:30:46 booo has joined
 678 2012-01-03 13:30:50 Stove has joined
 679 2012-01-03 13:32:14 roconnor has quit (Remote host closed the connection)
 680 2012-01-03 13:32:17 copumpkin has quit (Quit: Computer has gone to sleep.)
 681 2012-01-03 13:33:31 merde has quit (Ping timeout: 248 seconds)
 682 2012-01-03 13:34:18 BurtyB has joined
 683 2012-01-03 13:34:54 davout has joined
 684 2012-01-03 13:39:36 merde has joined
 685 2012-01-03 13:40:12 Stove has quit ()
 686 2012-01-03 13:41:32 booo has quit (Ping timeout: 244 seconds)
 687 2012-01-03 13:43:59 minimoose has joined
 688 2012-01-03 13:46:24 ovidiusoft has quit (Ping timeout: 240 seconds)
 689 2012-01-03 13:47:42 rdponticelli_ has joined
 690 2012-01-03 13:48:04 rdponticelli has quit (Ping timeout: 240 seconds)
 691 2012-01-03 13:49:17 Cablesaurus has quit (Ping timeout: 240 seconds)
 692 2012-01-03 13:50:22 Cablesaurus has joined
 693 2012-01-03 13:50:28 Cablesaurus has quit (Changing host)
 694 2012-01-03 13:50:28 Cablesaurus has joined
 695 2012-01-03 13:58:07 booo has joined
 696 2012-01-03 13:58:44 larsivi has quit (Ping timeout: 240 seconds)
 697 2012-01-03 13:59:57 copumpkin has joined
 698 2012-01-03 14:07:27 b4epoche_ has joined
 699 2012-01-03 14:08:17 b4epoche has quit (Ping timeout: 240 seconds)
 700 2012-01-03 14:08:17 b4epoche_ is now known as b4epoche
 701 2012-01-03 14:10:19 larsivi has joined
 702 2012-01-03 14:14:43 watson787 has joined
 703 2012-01-03 14:15:33 asa has joined
 704 2012-01-03 14:16:14 asa is now known as watson7872
 705 2012-01-03 14:18:57 watson787 has quit (Ping timeout: 240 seconds)
 706 2012-01-03 14:19:21 watson7872 is now known as watson787
 707 2012-01-03 14:20:56 da2ce7 has joined
 708 2012-01-03 14:20:58 Joric has quit (Read error: No route to host)
 709 2012-01-03 14:22:46 Joric has joined
 710 2012-01-03 14:23:00 booo has quit (Ping timeout: 260 seconds)
 711 2012-01-03 14:23:14 TuxBlackEdo has quit (Ping timeout: 276 seconds)
 712 2012-01-03 14:24:06 hippich_ has quit (Ping timeout: 252 seconds)
 713 2012-01-03 14:25:02 chrisb__ has quit (Quit: Ex-Chat)
 714 2012-01-03 14:26:45 mega_p2k has joined
 715 2012-01-03 14:28:53 <mega_p2k> hi, got a specific protocol question: can someone tell me under what conditions a valid transaction will be removed from the transaction pool while building a block?
 716 2012-01-03 14:29:17 luke-jr has quit (Excess Flood)
 717 2012-01-03 14:29:39 luke-jr has joined
 718 2012-01-03 14:33:18 TuxBlackEdo has joined
 719 2012-01-03 14:33:19 TuxBlackEdo has quit (Changing host)
 720 2012-01-03 14:33:19 TuxBlackEdo has joined
 721 2012-01-03 14:33:41 ovidiusoft has joined
 722 2012-01-03 14:36:05 _Fireball has joined
 723 2012-01-03 14:37:09 <lianj> mega_p2k: not sure, but a valid tx should not be removed
 724 2012-01-03 14:38:16 Carmivore has quit (Remote host closed the connection)
 725 2012-01-03 14:38:45 <mega_p2k> lianj: I'm asking because I'd like to skip the getmemorypool call in my software and get the transactions off the p2p protocol instead
 726 2012-01-03 14:39:35 <mega_p2k> is it also true that a bitcoind will only relay valid blocks and valid transactions to a connected peer?
 727 2012-01-03 14:40:37 <mega_p2k> that way I could skip validation in my software knowing that I'm connected to a local - and therefore trusted - client
 728 2012-01-03 14:40:58 <lianj> yes, to extend that it will only forward to types of valid tx script types atm. but protocol spec wise the other tx scripts are also valid
 729 2012-01-03 14:41:30 <lianj> depends on how you define valid in your case but yes
 730 2012-01-03 14:41:54 hippich_ has joined
 731 2012-01-03 14:42:32 <mega_p2k> I would define valid as being allowed in a block
 732 2012-01-03 14:43:32 gavinandresen has joined
 733 2012-01-03 14:43:34 <mega_p2k> but a valid tx should be a tx for which the inputs are valid
 734 2012-01-03 14:43:38 <lianj> then the current client might not forward all valid ones to you, as it check for is_standard txs and only forward these
 735 2012-01-03 14:43:59 <mega_p2k> well, how would I get other transactions then?
 736 2012-01-03 14:44:22 <mega_p2k> just by examining a block?
 737 2012-01-03 14:44:38 Carmivore has joined
 738 2012-01-03 14:45:14 <lianj> yes, just wait for them to show up in latest blocks. for the official client i dont know how to get them. using the wire protocol on your own you would just get them (and have to validate them on your own)
 739 2012-01-03 14:45:32 <mega_p2k> in all cases, I don't see any problem for me.
 740 2012-01-03 14:45:33 copumpkin has quit (Read error: Connection reset by peer)
 741 2012-01-03 14:45:39 <lianj> but non is_standard txs are rare cases
 742 2012-01-03 14:45:50 <lianj> yep, you should be fine
 743 2012-01-03 14:46:03 pumpkin has joined
 744 2012-01-03 14:46:09 <mega_p2k> in case you don't know, I'm the author of a new pool mining software called ecoinpool
 745 2012-01-03 14:46:55 <lianj> ah ok, hehe then you might what those other valid, but non is_standard txs too. but its not a must
 746 2012-01-03 14:46:55 pumpkin is now known as copumpkin
 747 2012-01-03 14:46:59 <mega_p2k> so for creating a block, I should be fine just taking any transactions the official client relays to me and putting them in a new block
 748 2012-01-03 14:47:01 <lianj> *want
 749 2012-01-03 14:47:42 <mega_p2k> yes, my point is that I don't require to get or validate non standard txs at all
 750 2012-01-03 14:48:12 <lianj> aw :( but yes, then youre fine with the official client
 751 2012-01-03 14:48:33 <mega_p2k> I just want to build a block, that's the single purpose of a pool software
 752 2012-01-03 14:49:45 <lianj> i was under the impression that most mining pools still accept valid txs even though they are not is_standard ones
 753 2012-01-03 14:50:29 <gavinandresen> There are three places where transactions are accepted:  when relaying, when deciding what to put into blocks, and when validating blocks...
 754 2012-01-03 14:50:46 <gavinandresen> Most mining pools do not relay or mine non-standard transactions, but will accept them if somebody else has mined them
 755 2012-01-03 14:50:50 <mega_p2k> lianj: yes, but how should non-standard txns find their way into a block that a mining pool software?
 756 2012-01-03 14:52:01 <lianj> gavinandresen: ah, thanks. so makes the chance very low/hard for these non-standard txs to get mined at all
 757 2012-01-03 14:52:10 <mega_p2k> gavinandresen: well yes, sure, they are accepted. but they won't be integrated into a new block per se.
 758 2012-01-03 14:53:14 <gavinandresen> lianj: yes, it is hard to get non-standard transactions accepted into the block chain (unless you own a big mining pool or can convince a big mining pool to accept them)
 759 2012-01-03 14:53:38 <mega_p2k> to my rationale, a non-standard txn can only find its way into a block if the mining software itself creates it and places it into a new block
 760 2012-01-03 14:54:02 booo has joined
 761 2012-01-03 14:54:29 <gavinandresen> mega_p2k: that's not true, I believe the Eligius pool will mine non-standard transactions as long as they include a fee.
 762 2012-01-03 14:54:29 <mega_p2k> the "mining software" could also just be bitcoind via getwork
 763 2012-01-03 14:55:18 <mega_p2k> gavinandresen: does this imply that eligius' bitcoind will also forward non-standard transactions?
 764 2012-01-03 14:55:20 <lianj> gavinandresen: aw :(  oh, now i like eligius even more
 765 2012-01-03 14:55:42 <gavinandresen> mega_p2k: I think so.  You'd have to ask luke-jr for a definitive answer.
 766 2012-01-03 14:55:48 <mega_p2k> ok
 767 2012-01-03 14:56:32 <gavinandresen> mega_p2k: you might want to use getmemorypool instead of getwork, depending on how much control your pool software wants to have.
 768 2012-01-03 14:57:42 hippich_ has quit (Ping timeout: 248 seconds)
 769 2012-01-03 14:57:47 <mega_p2k> gavinandresen: you joined a bit late. I was talking to lianj that I want to leave out calling an RPC call at all and instead take the forwarded transactions directly via the p2p protocol.
 770 2012-01-03 14:58:26 <gavinandresen> mega_p2k: that'd work, too, if you trust the node forwarding you transactions to validate them before relaying them (the standard client always does).
 771 2012-01-03 14:58:31 merde has quit (Ping timeout: 244 seconds)
 772 2012-01-03 14:59:09 <mega_p2k> yes, the node which you can configure in my software must be a trusted one, preferably running on localhost
 773 2012-01-03 14:59:20 <mega_p2k> this is a precondition, ofc
 774 2012-01-03 15:00:10 <mega_p2k> this is until I implement the complete validation in my software
 775 2012-01-03 15:02:11 <mega_p2k> but given that a local or trusted bitcoind will only forward valid blocks and valid transactions, I can skip validation for now
 776 2012-01-03 15:02:12 Lolcust- has joined
 777 2012-01-03 15:02:23 Lolcust has quit (Quit: Nap time)
 778 2012-01-03 15:03:22 <mega_p2k> I just need to calculate the fees based on the referenced transactions, which should be easy
 779 2012-01-03 15:03:52 merde has joined
 780 2012-01-03 15:05:08 <mega_p2k> gavinandresen: just to be sure: is there really no way that a forwarded transaction from a trusted node will become invalid at some point?
 781 2012-01-03 15:06:09 <gavinandresen> If it was part of a double-spend, and the "other" spend gets into the block-chain, then it will be invalid.
 782 2012-01-03 15:07:36 <mega_p2k> I see. is it easy to detect that?
 783 2012-01-03 15:07:58 <mega_p2k> I just have to compare inputs, right?
 784 2012-01-03 15:08:02 [Tycho] has joined
 785 2012-01-03 15:08:19 <gavinandresen> Yes, txin[i].prevout.hash/prevout.n
 786 2012-01-03 15:08:25 <[Tycho]> Hello.
 787 2012-01-03 15:08:50 <gavinandresen> When a new block is created, remove any transactions that you were thinking of including that have matching prevout.hash/n ....
 788 2012-01-03 15:09:14 <gavinandresen> (when you see a new block message from the network....)
 789 2012-01-03 15:09:20 <gavinandresen> Hi [Tycho]
 790 2012-01-03 15:09:27 <mega_p2k> gavinandresen: yep, sonds easy enough to me
 791 2012-01-03 15:10:19 <mega_p2k> gavinandresen, lianj: thanks a lot
 792 2012-01-03 15:10:19 roconnor has joined
 793 2012-01-03 15:11:02 <mega_p2k> gavinandresen: btw. we know each other, I'm p2k on github. looks like my mac deploy script did its job well.
 794 2012-01-03 15:11:48 <gavinandresen> mega_p2k: yes-- I need to pull your updated doesn't-depend-on-macdeployqt version....
 795 2012-01-03 15:12:40 <mega_p2k> I'm still to lazy to ask github's support for moving around my forks :)
 796 2012-01-03 15:15:15 da2ce7 has quit (Ping timeout: 276 seconds)
 797 2012-01-03 15:15:48 booo has quit (Ping timeout: 252 seconds)
 798 2012-01-03 15:19:45 user_ has joined
 799 2012-01-03 15:22:00 <sipa> ;;later tell BlueMatt your perf fix do't compile here
 800 2012-01-03 15:22:00 <gribble> The operation succeeded.
 801 2012-01-03 15:22:05 larsivi has quit (Ping timeout: 252 seconds)
 802 2012-01-03 15:22:27 gfinn has joined
 803 2012-01-03 15:23:11 da2ce7 has joined
 804 2012-01-03 15:24:38 <CIA-100> bitcoin: Gavin Andresen master * r0fcf91e / (src/init.cpp src/irc.cpp src/net.cpp src/util.cpp src/util.h): Fix issue #659, and cleanup wallet/command-line argument handling a bit - http://git.io/Rwa9fQ https://github.com/bitcoin/bitcoin/commit/0fcf91ea1e23697736032caadc8e487e0ba6cfef
 805 2012-01-03 15:25:19 <gribble> New news from bitcoinrss: gavinandresen pushed to master at bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/compare/4231eb217c...0fcf91ea1e>
 806 2012-01-03 15:25:20 <gribble> New news from bitcoinrss: gavinandresen merged pull request 726 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/726>
 807 2012-01-03 15:25:55 mega_p2k has left ()
 808 2012-01-03 15:26:15 <CIA-100> bitcoin: Gavin Andresen master * rdaad9a9 / (5 files in 4 dirs): Merge branch 'gitianfix' of https://github.com/TheBlueMatt/bitcoin - http://git.io/rlZnAw https://github.com/bitcoin/bitcoin/commit/daad9a9a71e9efc42e43245e374b4466dca6ebe6
 809 2012-01-03 15:26:27 erus` has quit (Read error: Connection reset by peer)
 810 2012-01-03 15:26:58 justmoon has joined
 811 2012-01-03 15:27:55 yorick has quit (Ping timeout: 252 seconds)
 812 2012-01-03 15:28:10 <CIA-100> bitcoin: Gavin Andresen master * r73e86ee / (src/script.cpp src/test/multisig_tests.cpp): Merge branch 'bugfix_multisig' of https://github.com/coderrr/bitcoin - http://git.io/czTgFA https://github.com/bitcoin/bitcoin/commit/73e86eedd5703e43bb8770a62acbb7c589a1905a
 813 2012-01-03 15:30:22 <gribble> New news from bitcoinrss: gavinandresen pushed to master at bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/compare/daad9a9a71...73e86eedd5>
 814 2012-01-03 15:30:23 <gribble> New news from bitcoinrss: gavinandresen merged pull request 733 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/733>
 815 2012-01-03 15:30:23 <gribble> New news from bitcoinrss: gavinandresen pushed to master at bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/compare/0fcf91ea1e...daad9a9a71>
 816 2012-01-03 15:30:24 <gribble> New news from bitcoinrss: gavinandresen merged pull request 728 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/728>
 817 2012-01-03 15:30:53 torsthaldo has quit (Read error: Connection reset by peer)
 818 2012-01-03 15:30:56 yorick has joined
 819 2012-01-03 15:31:23 <sipa> do we need both gribble and cia reporting pulls here?
 820 2012-01-03 15:33:07 molecular has quit (Quit: Leaving)
 821 2012-01-03 15:34:03 darkskiez has quit (Read error: No route to host)
 822 2012-01-03 15:35:23 <gmaxwell> 02:28 < sipa> it was way more than that before mlock was introduced, no?
 823 2012-01-03 15:35:39 <gmaxwell> ^ it was, but gavin removed the ecdsa sig validation before the highest checkpoint.
 824 2012-01-03 15:35:48 <gmaxwell> thats why I note it gets slower after ~144k.
 825 2012-01-03 15:36:53 erus` has joined
 826 2012-01-03 15:37:44 <gmaxwell> And why didn't we notice?  I expect that we need to further improve the development process... we're not often resyncing nodes, and people expect it to be slow and getting slower.
 827 2012-01-03 15:38:11 <gavinandresen> gmaxwell: I'm not going to regret pulling "no secure allocator for CDataStream" am I?  My rationale is: it is at BEST a teeny-tiny-marginal improvement in security, if it even has any effect at all...
 828 2012-01-03 15:39:31 jacobwg has joined
 829 2012-01-03 15:40:35 <gmaxwell> gavinandresen: I haven't personally audited the usage of CDataStream.  So long as it's not being used to handle private keys, I think the difference is pretty inconsequential.  Though Matt's patch goes further than the behavior before mlock made everything suck since it removes the post-zeroization.
 830 2012-01-03 15:41:26 <gmaxwell> (this is also probably good for performance but I hadn't measured it— when I checked out matt's patch didn't build for me and I didn't spare even a moment to try fixing it)
 831 2012-01-03 15:41:38 <gavinandresen> Doesn't build for me either....
 832 2012-01-03 15:42:57 <gmaxwell> If we wanted to be more security conservative we could replace all that with a properly performaing mlocked allocator (e.g. mlock in big infrequently allocated blocks and provide our own allocator on top of it), but I think that carries non-trivial software bug risk.
 833 2012-01-03 15:43:57 <sipa> whatever we try to mlock, there will always be data leaking
 834 2012-01-03 15:44:08 <sipa> so it is never more than a best-effort attempt, imho
 835 2012-01-03 15:44:15 <gavinandresen> Not zeroing freed memory makes me nervous, that's a good building block for a remote code injection exploit
 836 2012-01-03 15:44:49 <sipa> we could have a secure_alocator which zeroes, and a very_secure_allocator which mlocks
 837 2012-01-03 15:44:54 <gmaxwell> yea, use after free...
 838 2012-01-03 15:45:00 <user_> if i die. is it possible bitcooin automaticaly send my coins to a predefinied address
 839 2012-01-03 15:45:14 <sipa> user_: how will bitcoin know you died?
 840 2012-01-03 15:45:35 <justmoon> sipa: it will know ...if it killed him!!
 841 2012-01-03 15:45:39 <gmaxwell> user_: It's possible to constrct arrangements like that but you need a trusted agent to confirm that you died.
 842 2012-01-03 15:46:14 <gmaxwell> justmoon: I think if bitcoin was going to kill you it would start by sending all your coins to another address long before it got to the stabbing killing stage.
 843 2012-01-03 15:46:21 <justmoon> sipa: unrelated question, are there any bitcoin meetups in belgium?
 844 2012-01-03 15:46:29 <sipa> justmoon: not that i know of
 845 2012-01-03 15:46:38 <justmoon> gmaxwell: lol, help, somebody make a patch!
 846 2012-01-03 15:46:52 booo has joined
 847 2012-01-03 15:46:55 <sipa> gavinandresen: i prefer keeping the zeroing-freed-memory property as well
 848 2012-01-03 15:47:08 abragin has left ()
 849 2012-01-03 15:47:19 <justmoon> sipa: do you want to maybe come to a swiss one sometime? I've got a belgian guy living in geneva who's a fan of yours :D
 850 2012-01-03 15:47:47 <sipa> maybe, i even have family in switzerland :)
 851 2012-01-03 15:48:06 <sipa> not sure exactly where, never visited them there
 852 2012-01-03 15:48:23 <justmoon> sipa: switzerland is very small, they are probably my neighbours
 853 2012-01-03 15:48:38 <justmoon> sipa: I'll put you on swiss meetup mailing list
 854 2012-01-03 15:48:43 <sipa> good
 855 2012-01-03 15:50:38 <gribble> New news from bitcoinrss: gavinandresen commented on pull request 740 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/740#issuecomment-3341417>
 856 2012-01-03 15:51:42 <gmaxwell> Boost apparently does have an allocator, which you can override how it gets memory: http://www.boost.org/doc/libs/1_47_0/libs/pool/doc/interfaces/user_allocator.html
 857 2012-01-03 15:52:29 <sipa> gmaxwell: looks exactly like what we need
 858 2012-01-03 15:53:38 wasabi1 has joined
 859 2012-01-03 15:55:09 <gmaxwell> if we want to be properly security paranoid, and we're using a library allocator, we could potentially add canary functionality just like the stack protection in addition to the zeroize. I'd have to dump the allocator usage data to see how much overhead that might have.
 860 2012-01-03 15:55:41 <gmaxwell> (e.g. add a word after (and perhaps before) every allocation which is checked on free)
 861 2012-01-03 15:56:38 <gavinandresen> sounds like a very good idea, maybe turned on by compile-time or run-time debug switch....
 862 2012-01-03 15:57:23 <gavinandresen> (if performance matters)
 863 2012-01-03 15:58:10 <CIA-100> bitcoin: Gavin Andresen master * r112b0e9 / (15 files in 2 dirs): Merge pull request #741 from laanwj/typo734fix ... https://github.com/bitcoin/bitcoin/commit/112b0e97d47709f9f7fd0d9aad62a9063ba541f3
 864 2012-01-03 15:59:18 <sipa> can anyone on OSX try to build my netbase patch?
 865 2012-01-03 16:00:43 <gribble> New news from bitcoinrss: gavinandresen pushed to master at bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/compare/73e86eedd5...112b0e97d4>
 866 2012-01-03 16:00:43 <gribble> New news from bitcoinrss: gavinandresen merged pull request 741 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/741>
 867 2012-01-03 16:00:44 <gribble> New news from bitcoinrss: sipa commented on pull request 740 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/740#issuecomment-3341582>
 868 2012-01-03 16:00:56 <gavinandresen> sipa: ok, I'll try...
 869 2012-01-03 16:01:05 <sipa> gavinandresen: thanks
 870 2012-01-03 16:05:04 <gavinandresen> sipa:  I'm doing the rebasing work as I go... (I pulled an fTOR cleanup this morning)
 871 2012-01-03 16:05:05 btc_novice has joined
 872 2012-01-03 16:05:30 davout has quit (Remote host closed the connection)
 873 2012-01-03 16:05:44 <gribble> New news from bitcoinrss: gmaxwell commented on pull request 740 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/740#issuecomment-3341703>
 874 2012-01-03 16:05:56 DontMindMe2 has joined
 875 2012-01-03 16:08:49 datagutt is now known as ImTheMayne
 876 2012-01-03 16:08:59 <sipa> gavinandresen: ok, let me know if you have troubles
 877 2012-01-03 16:09:00 ImTheMayne is now known as datagutt
 878 2012-01-03 16:09:09 <gavinandresen> sipa: compiling....
 879 2012-01-03 16:11:31 <jgarzik> sipa: bdb ugh...  a75d7066b824eb1e70fb5b0e0e7c3c122e00c4b6
 880 2012-01-03 16:11:47 <jgarzik> sipa: better to build a list, then shove it all into bdb with a single transaction
 881 2012-01-03 16:12:02 <jgarzik> sipa: that _dramatically_ increases the db load, for the normal case (quick DNS lookups)
 882 2012-01-03 16:12:53 <jgarzik> sipa: there is a reason why bdb txn commit was designed as it was, prior to a75d7066b824eb1e70fb5b0e0e7c3c122e00c4b6
 883 2012-01-03 16:13:16 <sipa> jgarzik: that's possible, but it increases the time before you have any seeds
 884 2012-01-03 16:13:23 <sipa> especially when there is a problem with one
 885 2012-01-03 16:13:30 SomeoneWeird is now known as chmod775
 886 2012-01-03 16:14:04 chmod775 is now known as SomeoneWeird
 887 2012-01-03 16:14:51 <sipa> anyway, i'm thinking about redoing the CAddress-database entirely
 888 2012-01-03 16:15:16 <jgarzik> sipa: the normal case blasts a bunch of ~100-byte flushes to your disk
 889 2012-01-03 16:15:20 <jgarzik> sipa: that's a regression
 890 2012-01-03 16:16:26 da2ce7 is now known as chmod775
 891 2012-01-03 16:16:32 <sipa> yes, but seeds come faster and with less contention on the db db lock
 892 2012-01-03 16:16:41 <CIA-100> bitcoinjs/bitcoinjs-lib: booo master * r7675cf1 / src/wallet.js : src/wallet.js: retab file - http://git.io/M42BgQ https://github.com/bitcoinjs/bitcoinjs-lib/commit/7675cf14e4bd7643af61a95aa5231863434c5e0e
 893 2012-01-03 16:16:41 <CIA-100> bitcoinjs/bitcoinjs-lib: booo master * r57d2695 / src/wallet.js : src/wallet.js: remove console.log statements - http://git.io/75AsGA https://github.com/bitcoinjs/bitcoinjs-lib/commit/57d26950b9e4835090f153e81f4d90e4f534380f
 894 2012-01-03 16:16:41 <CIA-100> bitcoinjs/bitcoinjs-lib: booo master * r3445ae2 / src/wallet.js : src/wallet.js: use jshint - http://git.io/X5Znlw https://github.com/bitcoinjs/bitcoinjs-lib/commit/3445ae2a3649e40a4ec639654defed1113e3980a
 895 2012-01-03 16:16:42 <CIA-100> bitcoinjs/bitcoinjs-lib: booo master * ref903ba / src/wallet.js : src/wallet: getNextAddresss: add new address if necessary - http://git.io/JsuzvQ https://github.com/bitcoinjs/bitcoinjs-lib/commit/ef903bae07c600bb0eb1e17e406646a494205f43
 896 2012-01-03 16:16:42 <CIA-100> bitcoinjs/bitcoinjs-lib: Stefan Thomas master * ra5f9afd / src/wallet.js : Merge pull request #3 from booo/master ... https://github.com/bitcoinjs/bitcoinjs-lib/commit/a5f9afde5a587d0a1721595a6ec86f6dc259ae8a
 897 2012-01-03 16:18:08 user_ has quit (Quit: Leaving)
 898 2012-01-03 16:18:10 <jgarzik> sipa: not quite true -- it is noticeably slow here, because disk flush takes a longer than average time
 899 2012-01-03 16:18:49 <sipa> hmm, would it help moving the CAddrDb declaration out of the loop?
 900 2012-01-03 16:19:17 <sipa> i really prefer not needing to wait for all dns seeds
 901 2012-01-03 16:19:52 <jgarzik> sipa: one commit per seed is better than one commit per address
 902 2012-01-03 16:20:08 <sipa> so, it's one commit per seed noz
 903 2012-01-03 16:20:16 <jgarzik> noz?
 904 2012-01-03 16:20:18 <gmaxwell> jgarzik: Even on a super slow writing cheap ssd there didn't appear to be any performance problem from that change... though yea, one commit per seed would not insert any horrible delays.
 905 2012-01-03 16:20:18 <sipa> now
 906 2012-01-03 16:20:26 <gmaxwell> oh.
 907 2012-01-03 16:20:56 <gribble> New news from bitcoinrss: gmaxwell commented on issue 739 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/739#issuecomment-3341895>
 908 2012-01-03 16:21:03 <CIA-100> bitcoin: Gavin Andresen master * r8677f9c / src/init.cpp : I broke -testnet with my TOR option-parsing fixes. - http://git.io/soaXkQ https://github.com/bitcoin/bitcoin/commit/8677f9c751b397476593f60c747709c61d5b8f19
 909 2012-01-03 16:22:22 <jgarzik> sipa: hrm, so it is.  will have to benchmark this performance regression further.  new bitcoin is definitely hitting db hard and flushing a lot more, making it noticably slower.  zero activity from other processes on the machine.
 910 2012-01-03 16:22:49 * jgarzik had assumed that that was the only notable bdb txn commit change, but perhaps that was an invalid assumption
 911 2012-01-03 16:22:53 <sipa> we're talking about *three* more db commits; in total
 912 2012-01-03 16:23:00 <jgarzik> nod
 913 2012-01-03 16:23:16 <jgarzik> sipa: any non-seed-related db changes come to mind, perchance?
 914 2012-01-03 16:23:22 <jgarzik> otherwise it's bisect time :/
 915 2012-01-03 16:23:55 <sipa> jgarzik: in the same git commit i moved some things out of db-locked code
 916 2012-01-03 16:24:05 <gmaxwell> I expect with the mlock fix syncup will be fsync limited again. So sounds like a good time to think about reducing the db load independant of whatever regression jgarzik is seeing.
 917 2012-01-03 16:24:37 <sipa> jgarzik: though it's hard to see how that could reduce performance
 918 2012-01-03 16:24:47 <jgarzik> yeah
 919 2012-01-03 16:24:52 <gavinandresen> I've thought several times of using a different DbEnv for wallet.dat versus the other .dats-- sync is really only important for wallet.
 920 2012-01-03 16:24:59 <gmaxwell> jgarzik: sipa's patch creates much greater concurrency.. e.g. it doesn't sit blocked waiting on dns seed before it beging pulling blocks from a peer. Make it noticably faster to start syncing for me.
 921 2012-01-03 16:25:01 <jgarzik> gavinandresen: that would be nice
 922 2012-01-03 16:25:32 <sipa> gavinandresen: ACK, it's even required if we want to have multiple-wallets and wallets loaded from user-defined locations one day
 923 2012-01-03 16:25:37 watson787 has quit (Ping timeout: 240 seconds)
 924 2012-01-03 16:25:57 <jgarzik> gmaxwell: agree that sipa's commit no longer -appears- to be the source of a flush-based performance regression
 925 2012-01-03 16:25:59 <gribble> New news from bitcoinrss: gavinandresen pushed to master at bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/compare/112b0e97d4...8677f9c751>
 926 2012-01-03 16:27:22 <sipa> gavinandresen: any result from compiling netbase?
 927 2012-01-03 16:28:14 <gavinandresen> sipa: compiles fine after fixing merge conflicts
 928 2012-01-03 16:28:48 <gmaxwell> gavinandresen: so the other advantage of that seperation would be that they could have seperate transaction logs.. right now you can think you're being clever and putting your wallet on a more reliable medium and get hosed by not taking the txn logs with it.
 929 2012-01-03 16:29:11 <gavinandresen> sipa:  but I managed to get myself into merge/rebase hell by fixing an unrelated bug in the middle....
 930 2012-01-03 16:29:30 <gmaxwell> gavinandresen: e.g. you've put datadir on tmpfs but symlinked the wallet onto a raid array. Works great until you have a power outage while it was writing the wallet.
 931 2012-01-03 16:29:33 <sipa> ah
 932 2012-01-03 16:29:53 <gavinandresen> gmaxwell: good point.
 933 2012-01-03 16:30:38 <gmaxwell> Of course, without all the fsync crap on everything else— there would be a lot less reason to run from tmpfs. :)
 934 2012-01-03 16:32:36 user_ has joined
 935 2012-01-03 16:33:43 <CIA-100> bitcoinjs/bitcoinjs-gui: booo master * re0eef3c / scripts/exitnode.js : scripts/exitnode: log socketio errors - http://git.io/6oXWSA https://github.com/bitcoinjs/bitcoinjs-gui/commit/e0eef3c4f07dd1268d5a4fa02044554be713da08
 936 2012-01-03 16:33:43 <CIA-100> bitcoinjs/bitcoinjs-gui: booo master * ra5c6be5 / scripts/desktop/index.js : scripts/desktop/index: use wm instead of walletMan; changed call to createWallet - http://git.io/B-bZ5w https://github.com/bitcoinjs/bitcoinjs-gui/commit/a5c6be522e09b23d5136515f26d413f325797bd3
 937 2012-01-03 16:33:44 <CIA-100> bitcoinjs/bitcoinjs-gui: booo master * racddc7b / scripts/vendor/bitcoinjs-lib : update bitcoinjs-lib submodule - http://git.io/eoFeFg https://github.com/bitcoinjs/bitcoinjs-gui/commit/acddc7bb43f5865e426b32d3ed34aac76b518ca1
 938 2012-01-03 16:33:44 <CIA-100> bitcoinjs/bitcoinjs-gui: booo master * r6fc98c6 / scripts/desktop/index.js : scripts/desktop/index: fix wallet initialisation/update - http://git.io/zqkZEA https://github.com/bitcoinjs/bitcoinjs-gui/commit/6fc98c607f0809234b520355d3409e8d62eecec6
 939 2012-01-03 16:33:44 <CIA-100> bitcoinjs/bitcoinjs-gui: Stefan Thomas master * r710a56d / (3 files in 3 dirs): Merge pull request #4 from booo/master ... https://github.com/bitcoinjs/bitcoinjs-gui/commit/710a56dc8f2c9b6949866a219a2b7e8f8f70249d
 940 2012-01-03 16:34:13 <justmoon> aw man, why do I always hit exactly five commits, where it spams like crazy... sorry :(
 941 2012-01-03 16:35:01 <luke-jr> gavinandresen: Why does 0fcf91e change net.cpp?
 942 2012-01-03 16:35:24 <luke-jr> actually, I think I understand the reasoning now…
 943 2012-01-03 16:37:13 Lolcust- has quit (Quit: Nap time)
 944 2012-01-03 16:37:14 <sipa> gavinandresen: in 0fcf91e, in net.cpp: you declare fTOR locally, but don't use it anymore?
 945 2012-01-03 16:37:16 SomeoneWeird is now known as SomeoneWeirdzzzz
 946 2012-01-03 16:37:32 <gavinandresen> sipa: oops
 947 2012-01-03 16:38:02 <gavinandresen> You guys shouldn't let me write code any more, I'm going senile.....
 948 2012-01-03 16:38:13 Lolcust has joined
 949 2012-01-03 16:39:07 chmod775 is now known as da2ce6
 950 2012-01-03 16:39:43 SomeoneWeirdzzzz is now known as da4ce2
 951 2012-01-03 16:40:13 da4ce2 is now known as SomeoneWeirdzzzz
 952 2012-01-03 16:40:49 da2ce6 is now known as SomeoneWeird
 953 2012-01-03 16:41:08 <sipa> gavinandresen: i've rebased my netbase now
 954 2012-01-03 16:41:19 SomeoneWeird is now known as Guest86813
 955 2012-01-03 16:41:40 <sipa> ah damn, don't have the ssh key there to push
 956 2012-01-03 16:41:53 <gavinandresen> sipa:  that's funny, I just finished rebasing....
 957 2012-01-03 16:42:07 <sipa> don't worry; it wasn't much work :)
 958 2012-01-03 16:42:08 Guest86813 is now known as Some1W
 959 2012-01-03 16:42:44 Some1W is now known as da2ce7
 960 2012-01-03 16:44:02 tower has quit (Disconnected by services)
 961 2012-01-03 16:44:16 tower has joined
 962 2012-01-03 16:44:34 <gavinandresen> sipa: rebased netbase compiles and runs fine on my mac
 963 2012-01-03 16:46:28 <sipa> good!
 964 2012-01-03 16:46:52 <sipa> ming/win may be a bit more trouble, as it uses getaddrinfo now, which requires some extra/other headers
 965 2012-01-03 16:50:38 <justmoon> gavinandresen: has anyone thought of a good name for your proposal? (the OP_EVAL alternative with a magic scriptPubKey)
 966 2012-01-03 16:50:47 <sipa> gavinandresen, jgarzik, gmaxwell: what do you think about this new handling of CAddress'es: classify each address in one of 64 buckets, based on Hash(nonce + addr >> 16); for each bucket, keep at most 64 already-succesfully-connected-to addresses (ordered by last succesfull try), and at most 64 not-yet-tried addresses
 967 2012-01-03 16:51:18 <sipa> that means at most 8192 addresses, which are just kept in memory all the time, and occasionally (not synchronously) written to disk
 968 2012-01-03 16:51:19 <gribble> New news from bitcoinrss: gavinandresen commented on pull request 735 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/735#issuecomment-3342374>
 969 2012-01-03 16:51:42 <gavinandresen> justmoon: It needs a good name-- PayToScriptHash is the best I've been able to come up with
 970 2012-01-03 16:52:04 <justmoon> k, I'll use that until further notice
 971 2012-01-03 16:52:40 luke-jr has quit (Ping timeout: 252 seconds)
 972 2012-01-03 16:55:11 erus` has quit (Remote host closed the connection)
 973 2012-01-03 16:55:31 Joric has quit ()
 974 2012-01-03 16:55:40 <gavinandresen> sipa:  do we have any data on how many connection attempts it takes to find a working peer if you haven't connected in a day/week/month ?
 975 2012-01-03 16:56:13 <gavinandresen> sipa:  ... or, in other words, I'm not sure how we'd know if 8192 is too many or too few.
 976 2012-01-03 16:56:25 <sipa> gavinandresen: stats from bitcoin-crawler:
 977 2012-01-03 16:56:26 luke-jr has joined
 978 2012-01-03 16:56:27 <sipa> 1641/16549 available (16268 tried in 1620s, 257 new, 24 active), 301029 banned;
 979 2012-01-03 16:56:51 <sipa> that means it knows about 16500 sometimes-reachable nodes, of which 1641 are very reliable
 980 2012-01-03 16:57:20 <sipa> and it also knows about 300000 nodes that have awful reliability (probably not reachable at all)
 981 2012-01-03 16:57:35 <gmaxwell> sipa: I feel a little uneasy about the >>16 just because I don't like the fact that your neighbor can spin up 64 hosts and knock you out of nodes tables.
 982 2012-01-03 16:58:01 <sipa> gmaxwell: he could only poison one of the 64 buckets
 983 2012-01-03 16:58:11 <sipa> that's exactly the reason for the shift
 984 2012-01-03 16:58:44 <sipa> oh, addr is in network byte order, so it should be <<
 985 2012-01-03 16:59:02 <sipa> anyway, i just meant: the higher-order 16 bits of the IPv4 address
 986 2012-01-03 16:59:22 <phantomcircuit> i still think the connection strategy needs to be updated
 987 2012-01-03 16:59:30 <sipa> phantomcircuit: explain
 988 2012-01-03 16:59:32 <phantomcircuit> 4 stable connections 4 roaming connections
 989 2012-01-03 16:59:46 <sipa> hmm
 990 2012-01-03 16:59:54 <gmaxwell> Yes, I agree but thats seperate.
 991 2012-01-03 17:00:55 <gmaxwell> (I actually think it should be something like 'keep the 'best' two peers where best means they give you the most good blocks and txn' and roam the single oldest connection... but whatever, seperate subject)
 992 2012-01-03 17:02:22 <phantomcircuit> well actually
 993 2012-01-03 17:02:23 <gmaxwell> sipa: thats a great assumption if you assume that a single /16 is an administrative domain, but thats a poor assumption.  I wasn't disagreeing with the shift, I know why you have it there. I just feel uneasy about the amount.
 994 2012-01-03 17:02:30 da2ce7 has quit (Ping timeout: 276 seconds)
 995 2012-01-03 17:02:40 <phantomcircuit> i would say have about 100 roaming connections
 996 2012-01-03 17:02:51 <phantomcircuit> but that will break on windows and destroy many NAT setups
 997 2012-01-03 17:03:06 <gmaxwell> ugh. no. 8 connections is already a _lot_ from a graph connectivity perspective.
 998 2012-01-03 17:03:19 <sipa> gmaxwell: no, i assume most administrative domains are smaller than a /16
 999 2012-01-03 17:03:25 <phantomcircuit> gmaxwell, yeah i understand
1000 2012-01-03 17:03:51 <phantomcircuit> if you had lots of roaming connections you would need to change the notification algorithm
1001 2012-01-03 17:04:02 <phantomcircuit> doing so would obviously be dangerous though
1002 2012-01-03 17:04:16 <gmaxwell> sipa: right, which means that I can zot out neighboring admin domains. How about something morally like this:
1003 2012-01-03 17:04:59 <sipa> gmaxwell: not following
1004 2012-01-03 17:05:26 <sipa> gavinandresen: i'll try to gather some real statistics, butbased on what i've seen with my crawler, i'd guess that 100 addresses is enough to find a good one after a week
1005 2012-01-03 17:05:47 <sipa> but that's really just a guess based on how many different addresses i've seen in +- a week
1006 2012-01-03 17:05:49 <phantomcircuit> sipa, if the average admin domain is smaller than a /16 then you can get neighboring domains blocked
1007 2012-01-03 17:06:25 <gribble> New news from bitcoinrss: gavinandresen commented on issue 739 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/739#issuecomment-3342682>
1008 2012-01-03 17:06:33 <gmaxwell> e.g. I can get hosted 'next door' to mtgox and get them blocked.
1009 2012-01-03 17:06:41 <sipa> phantomcircuit: but all addresses under your control will for everyone always end up in only one bucket
1010 2012-01-03 17:06:58 <phantomcircuit> uh
1011 2012-01-03 17:07:00 <phantomcircuit> no
1012 2012-01-03 17:07:24 <phantomcircuit> spammers are getting better
1013 2012-01-03 17:07:26 <gmaxwell> Well I controll addresses on multiple 16s just fine. :)
1014 2012-01-03 17:07:33 <phantomcircuit> i've got stuff here where the sa score is 1.7
1015 2012-01-03 17:07:34 <phantomcircuit> :(
1016 2012-01-03 17:07:49 <gmaxwell> sipa: (ignoring byteswap) hash(nonce + addr>>16 + hash(nonce+address&((1<<16)-1)&3)  e.g. /16 goes into 4 bins.
1017 2012-01-03 17:07:58 <gmaxwell> ^ what do you think of something like that.
1018 2012-01-03 17:08:04 <sipa> hmm, maybe the buckets for not-yet-tried-addresses should be based on where you got them from
1019 2012-01-03 17:08:11 <sipa> instead of the addresses themselves
1020 2012-01-03 17:08:16 <gmaxwell> yea, I think that someone suggested that before.
1021 2012-01-03 17:08:24 <sipa> yes, i think i did
1022 2012-01-03 17:09:00 <sipa> gmaxwell: looks good, a bit of spreading in it as well
1023 2012-01-03 17:09:22 <gavinandresen> I'd be a much happier camper if somebody was simulating all this under plausible attack scenarios....
1024 2012-01-03 17:09:50 <gavinandresen> (but I agree the addr message handling / addr.dat is broken enough to warrant fixing)
1025 2012-01-03 17:10:02 <gmaxwell> gavinandresen: the problem with that is 'attacker gets a bunch of /16s and denies incoming to some nodes is plausable but we can't stop it.
1026 2012-01-03 17:11:21 <gmaxwell> sipa: perhaps always take a few bits from where you learned it.
1027 2012-01-03 17:12:58 Clipse has quit (Ping timeout: 240 seconds)
1028 2012-01-03 17:14:48 <sipa> as soon as you go to using where you got an address from, a single address can of course end up in several bins
1029 2012-01-03 17:16:50 mcorlett has quit (Remote host closed the connection)
1030 2012-01-03 17:17:23 <gmaxwell> meh. yea.
1031 2012-01-03 17:17:49 <sipa> not really a problem, but that may warrant somewhat larger bins for the not-yet-tried ones
1032 2012-01-03 17:17:54 <sipa> as they will have overlap
1033 2012-01-03 17:18:20 <gmaxwell> Hm. Well, you need to lookup to see if you have it already... so you can just use the first you heard it from, no?
1034 2012-01-03 17:18:45 <sipa> that's also possible
1035 2012-01-03 17:18:55 <gmaxwell> though overlap might not be so bad.
1036 2012-01-03 17:18:59 <sipa> and probably the easiest way
1037 2012-01-03 17:19:13 <sipa> on the other hand: you can use overlap in your advantage: as a scoring function
1038 2012-01-03 17:19:21 <sipa> that was suggested before as well, iirc
1039 2012-01-03 17:19:27 <gmaxwell> (makes it harder to slay an address if there is some chance it'll stick around in an overlap)
1040 2012-01-03 17:20:38 <sipa> what about: for tried addresses: use mostly upper bits of address itself, with a small influence from the lower-order bits (like your example above)
1041 2012-01-03 17:21:14 <sipa> for non-tried addresses: use mostly upper bits of source, with a small influence from the address itself
1042 2012-01-03 17:21:18 p0s has quit (Remote host closed the connection)
1043 2012-01-03 17:23:08 <sipa> meh, becomes hard if you want to do it right
1044 2012-01-03 17:23:15 <gmaxwell> I wonder how much attack resistance we'd gain by using random eviction that can actually evict the new entry.
1045 2012-01-03 17:23:46 <sipa> eviction when the bins get full, you mean?
1046 2012-01-03 17:23:52 <CIA-100> bitcoin: Gavin Andresen master * raf8c56f / (src/bitcoinrpc.cpp src/main.h): Merge branch 'getblock' - http://git.io/reg12g https://github.com/bitcoin/bitcoin/commit/af8c56f8be7f01136c88e665c7580daf6f9c9d7d
1047 2012-01-03 17:24:01 <gavinandresen> gribble, be quiet.
1048 2012-01-03 17:24:04 <gmaxwell> e.g. when you're full and you go to add a new one pick one of the 65 possible addresses at random to evict. This way someone trying to flood out your bin can only increase their chances with more attacks.
1049 2012-01-03 17:24:56 <sipa> sounds good
1050 2012-01-03 17:25:02 <gmaxwell> (they might just evict themselves over and over agai.. and as they get closer to all of the bin they'll spend most of their time doing that)
1051 2012-01-03 17:25:15 <sipa> i like having random factors in the algorithm, makes it hard to control by others
1052 2012-01-03 17:25:35 <luke-jr> gavinandresen: wasn't the older dumpblock more powerful/useful? O.o
1053 2012-01-03 17:26:51 <gribble> New news from bitcoinrss: gavinandresen pushed to master at bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/compare/8677f9c751...af8c56f8be>
1054 2012-01-03 17:26:51 <gribble> New news from bitcoinrss: gavinandresen merged pull request 727 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/727>
1055 2012-01-03 17:27:28 <rjk2> when did gribble get spam capabilities?
1056 2012-01-03 17:28:16 <gmaxwell> sipa: I dunno, seems easy enough, especially if you allow duplication in the ones that include the source... just don't bother to check if you've already got an address before adding it to the waiting pool.
1057 2012-01-03 17:28:26 <CIA-100> bitcoin: Gavin Andresen master * r96d3bcb / (4 files): Merge pull request #731 from laanwj/txshowfix ... https://github.com/bitcoin/bitcoin/commit/96d3bcb99690726d4c0e28355cc87c25e14f4c8d
1058 2012-01-03 17:28:41 <gmaxwell> Check the addresses against connected.. fails that stuff it in the waiting pool
1059 2012-01-03 17:28:51 <CIA-100> bitcoin: Wladimir J. van der Laan 0.5.x * r20e3f2aefc60 bitcoind-stable/src/qt/ (15 files in 2 dirs): Fix typo (#734) http://tinyurl.com/8yhtqu9
1060 2012-01-03 17:28:54 <CIA-100> bitcoin: Luke Dashjr 0.5.x * ra2e9767225d3 bitcoind-stable/src/ (7 files in 2 dirs): Merge branch '0.5.0.x' into 0.5.x http://tinyurl.com/6rf58sv
1061 2012-01-03 17:29:10 <luke-jr> rjk2: BlueMatt
1062 2012-01-03 17:29:57 Sedra- has joined
1063 2012-01-03 17:30:10 * luke-jr wonders what "EV_EVAL" is  :p
1064 2012-01-03 17:30:48 <gmaxwell> rjk2: if it bugs you, filter it out.
1065 2012-01-03 17:31:05 <rjk2> nah i like to hear from him occasionally
1066 2012-01-03 17:31:30 <justmoon> you could filter on "news from bitcoinrss"
1067 2012-01-03 17:31:52 <gribble> New news from bitcoinrss: gavinandresen pushed to master at bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/compare/af8c56f8be...96d3bcb996>
1068 2012-01-03 17:31:53 <gribble> New news from bitcoinrss: gavinandresen merged pull request 731 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/731>
1069 2012-01-03 17:31:53 <gribble> New news from bitcoinrss: Stemby opened issue 742 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/742>
1070 2012-01-03 17:32:16 <rjk2> it just seems a little more verbose than expected =)
1071 2012-01-03 17:32:16 <sipa> wow, it's mergin' day!
1072 2012-01-03 17:32:22 Sedra has quit (Ping timeout: 248 seconds)
1073 2012-01-03 17:32:27 <rjk2> ill look into a special ignore rule
1074 2012-01-03 17:33:02 Kolky has joined
1075 2012-01-03 17:33:25 <luke-jr> gavinandresen: am I correct in assuming that coinbaser and signmessage are waiting on jgarzik and wumpus at this point?
1076 2012-01-03 17:33:38 <gavinandresen> luke-jr: yup
1077 2012-01-03 17:36:33 <luke-jr> wumpus: Does 56c6e36 hold true (not all tx'es with "from"/"to" field are necessarily IP tx'es) before OP_EVAL?
1078 2012-01-03 17:37:13 <gribble> New news from bitcoinrss: gmaxwell commented on issue 739 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/739#issuecomment-3343118>
1079 2012-01-03 17:39:05 <gavinandresen> luke-jr: I hate to feature-creep.... but I wonder if -blocknotify aught to pass the block hash to the command being run.  That'd make it play nicely with getblock.
1080 2012-01-03 17:39:22 <luke-jr> gavinandresen: it does, if you put %s in the command
1081 2012-01-03 17:40:13 <gavinandresen> So it does.... cool
1082 2012-01-03 17:42:25 <justmoon> gmaxwell: do you have a branch where I can pull your secure allocator test version?
1083 2012-01-03 17:42:39 <luke-jr> gavinandresen: don't suppose you know the answer to "from"/"to" since wumpus seems to not be here?
1084 2012-01-03 17:42:46 <justmoon> (secure allocator disablement to be precise)
1085 2012-01-03 17:42:51 <gmaxwell> justmoon: Er, I have a stupid patch that removes all the mlocks.
1086 2012-01-03 17:43:01 <sipa> justmoon: just re-#define mlock/munlock in serialize.h
1087 2012-01-03 17:43:04 <gmaxwell> BlueMatt: has the disablement but it doesn't build.
1088 2012-01-03 17:43:19 <gmaxwell> https://people.xiph.org/~greg/omg_go_fast.patch
1089 2012-01-03 17:43:21 <sipa> the real patch won't do that though; but is broken currently
1090 2012-01-03 17:43:48 <gmaxwell> (that leaves the zeroization in.. which is what I expect we'll do long term)
1091 2012-01-03 17:44:00 <gmaxwell> justmoon: if you'd like to benchmark it w and w/o that be fun.
1092 2012-01-03 17:44:13 <sipa> 12000
1093 2012-01-03 17:44:21 <justmoon> gmaxwell: i just want to run it on my standard benchmark system so I can get a sense where it is in comparison w/ bitcoinjs
1094 2012-01-03 17:44:22 <gmaxwell> It might be that it was more of a speedup for me (due to cpu/kernel/libc version) than others.
1095 2012-01-03 17:44:49 <gmaxwell> justmoon: oh well, there are still a lot of low hanging fruit in bitcoind.
1096 2012-01-03 17:45:08 <sipa> 15000
1097 2012-01-03 17:45:18 <shadders> luke-jr: miss me?  hope you've finally released yr toy pool sw while I was awol...
1098 2012-01-03 17:45:24 <justmoon> gmaxwell: such as?
1099 2012-01-03 17:45:31 <sipa> gmaxwell: still, you did a full sync in half an hour?
1100 2012-01-03 17:45:34 <luke-jr> shadders: not really, but the other pool ops were getting desperate.
1101 2012-01-03 17:45:36 <gmaxwell> justmoon: all the crazy pointless fsync behavior.
1102 2012-01-03 17:45:37 <sipa> over lan?
1103 2012-01-03 17:45:42 <luke-jr> shadders: they're all defecting to an Erlang pool :P
1104 2012-01-03 17:45:42 <gmaxwell> sipa: yes sir.
1105 2012-01-03 17:45:54 <sipa> gmaxwell: that's by far faster than any number i've ever seen
1106 2012-01-03 17:46:17 <shadders> luke-jr: so I hear... Now I know how Moses felt after a few weeks on a mountain
1107 2012-01-03 17:46:19 <gmaxwell> sipa: as I mentioned earlier, gavin made it faster recently with the ecdsa disabling.
1108 2012-01-03 17:46:38 <sipa> yes, but still.. a few hours for a sync, no?
1109 2012-01-03 17:46:52 <justmoon> gmaxwell: that doesn't do too much, 4.5 million ecdsa verifications take about 8 minutes of cpu time
1110 2012-01-03 17:46:57 <sipa> not sure i tested it after that check was disabled
1111 2012-01-03 17:47:16 <sipa> 21000
1112 2012-01-03 17:47:31 <gmaxwell> Yes, thats what it's been.. but back in march? before the mlock stuff it was taking a half hourish on a system with a slower cpu. (If I go through logs I can probably find where I benchmarked it)
1113 2012-01-03 17:48:00 * sipa dinner
1114 2012-01-03 17:48:01 <sipa> cya
1115 2012-01-03 17:48:24 <justmoon> gmaxwell: wait, so the 30 min figure - is it for the current chain or back then?
1116 2012-01-03 17:48:42 <gmaxwell> current chain.
1117 2012-01-03 17:49:14 <gmaxwell> (This isn't surprising, as mentioned: faster system)
1118 2012-01-03 17:49:26 <gmaxwell> (plus improvements)
1119 2012-01-03 17:49:43 <justmoon> alright, I gotta run this for myself
1120 2012-01-03 17:49:45 <justmoon> thanks for the help
1121 2012-01-03 17:49:52 <gmaxwell> gavinandresen: Then perhaps we have another bug because I see it become obviously slower at about 140k
1122 2012-01-03 17:50:19 <nanotube> well, i can filter out the 'pushed' rss items, since they're duplicated by cia. leaving the issue comments and pull requests that are not covered by cia ?
1123 2012-01-03 17:50:21 Internet13 has quit (Quit: Leaving)
1124 2012-01-03 17:50:25 <nanotube> what do you guys think?
1125 2012-01-03 17:51:02 <gavinandresen> new pull requests are valuable.  I think issue comments are too much
1126 2012-01-03 17:51:09 <gmaxwell> lemme run a syncup with timestamps.
1127 2012-01-03 17:51:22 Internet13 has joined
1128 2012-01-03 17:51:26 <gmaxwell> Can we make it just do new issues?
1129 2012-01-03 17:51:54 <nanotube> yes we can
1130 2012-01-03 17:51:59 <nanotube> just ... decide what you guys want :)
1131 2012-01-03 17:52:06 <nanotube> gribble is here to serve
1132 2012-01-03 17:52:38 <justmoon> gmaxwell: here is a partial download with bitcoinjs (with timestamps) if you're curious: https://gist.github.com/1556051
1133 2012-01-03 17:53:24 <justmoon> i broke something that makes it run out of file descriptors, once that's fixed I'll run a full one
1134 2012-01-03 17:53:44 <justmoon> (and no I'm not leaking file descriptors just opening too many...)
1135 2012-01-03 17:56:41 <gmaxwell> Why aren't timestamps on in the debug log by default? They're very handy.
1136 2012-01-03 17:56:58 <gmaxwell> (would be more handy if they had subsecond precision, but hey)
1137 2012-01-03 17:57:28 <nanotube> ok, gribble will now only mention new pull requests and issues, and ignore comments and commits
1138 2012-01-03 17:58:40 <gavinandresen> gmaxwell: they're not on by default for probably-paranoid-and-ill-considered privacy reasons:  what if an attacker gathered debug.logs from a bunch of machines and used the timestamps to figure out.... stuff....
1139 2012-01-03 17:58:55 <gmaxwell> meh, they still preserve total otder.
1140 2012-01-03 17:58:56 <gmaxwell> er order.
1141 2012-01-03 17:59:31 <gavinandresen> ... so you're saying we should randomize OutputDebugStringF a little bit... I'll get right on that.
1142 2012-01-03 17:59:33 <gavinandresen> :)
1143 2012-01-03 17:59:46 luke-jr_ has joined
1144 2012-01-03 17:59:50 <gmaxwell> god no. hah. I should watch what I say.
1145 2012-01-03 18:00:08 luke-jr has quit (Ping timeout: 252 seconds)
1146 2012-01-03 18:00:16 <gmaxwell> too often in #bitcoin/forums I'll make a joke and someone will say "thats a fantastic idea!"
1147 2012-01-03 18:01:28 luke-jr_ is now known as luke-jr
1148 2012-01-03 18:01:36 <gmaxwell> Looks like I might beat my prior record...
1149 2012-01-03 18:01:58 gribble has quit (Ping timeout: 240 seconds)
1150 2012-01-03 18:02:18 <luke-jr> gmaxwell: you were going to implement deterministic wallets, right?
1151 2012-01-03 18:02:21 <luke-jr> :P
1152 2012-01-03 18:04:29 Asthrou- has joined
1153 2012-01-03 18:05:27 Asthrou has quit (Ping timeout: 248 seconds)
1154 2012-01-03 18:05:32 StevenCH has joined
1155 2012-01-03 18:09:09 <gmaxwell> I'll have cool syncup graphs in a bit.
1156 2012-01-03 18:12:05 <justmoon> gmaxwell: I got 80000 blocks in ten minutes so far - that would still be significantly slower than bitcoinjs (about 50%)
1157 2012-01-03 18:12:12 <justmoon> obviously the real test will be the larger blocks
1158 2012-01-03 18:12:34 <justmoon> gmaxwell: have you run the unmodified client on the same system? how long does that take?
1159 2012-01-03 18:17:15 Asthrou- has quit ()
1160 2012-01-03 18:23:20 d4de has joined
1161 2012-01-03 18:23:35 <gmaxwell> justmoon: you're slow, I took 100 seconds to get 80k blocks.
1162 2012-01-03 18:23:54 <justmoon> gmaxwell: how long does the unmodified client take for you?
1163 2012-01-03 18:24:36 <justmoon> I think you are testing on >3 times faster hardware than I am :)
1164 2012-01-03 18:24:57 <justmoon> I got to 110000 blocks after 20 minutes (bitcoinjs does it in 6)
1165 2012-01-03 18:25:05 copumpkin is now known as gribble
1166 2012-01-03 18:25:21 mcorlett has joined
1167 2012-01-03 18:25:31 mcorlett has quit (Changing host)
1168 2012-01-03 18:25:31 mcorlett has joined
1169 2012-01-03 18:25:34 gribble is now known as Guest23331
1170 2012-01-03 18:25:44 <gmaxwell> 01/03/12 17:51:33 SetBestChain: new best=00000000839a8e6886ab  height=1 work=8590065666
1171 2012-01-03 18:25:47 <gmaxwell> 01/03/12 18:21:04 SetBestChain: new best=00000000000004c0de2c  height=160458 work=201667296186438652831
1172 2012-01-03 18:25:51 Guest23331 is now known as copumpkin
1173 2012-01-03 18:25:56 <gmaxwell> Just finished measuring patched with timestamps.
1174 2012-01-03 18:26:11 <forrestv> luke-jr, oh yeah, forgot about that, but that's just an implementation detail :P
1175 2012-01-03 18:27:14 <justmoon> gmaxwell: unmodified client, how long does it take on that same system you're testing the patch on - seems like a percentage improvement would be a useful figure, even a rough one
1176 2012-01-03 18:27:39 erle- has joined
1177 2012-01-03 18:28:06 <gmaxwell> justmoon: stop!
1178 2012-01-03 18:28:12 copumpkin is now known as grobble
1179 2012-01-03 18:28:13 <gmaxwell> justmoon: :) you're asking the same question over and over again.
1180 2012-01-03 18:28:26 <justmoon> gmaxwell: I'm known to be persistent :)
1181 2012-01-03 18:28:27 <gmaxwell> justmoon: I'm measuring that now. But it takes a while to sync up in order to answer!
1182 2012-01-03 18:28:35 <justmoon> gmaxwell: kk, sorry
1183 2012-01-03 18:28:53 <gmaxwell> ask again _tomorrow_ thats how slow it is without the patch for me.
1184 2012-01-03 18:28:54 <gmaxwell> :)
1185 2012-01-03 18:29:02 <justmoon> hmm, weird
1186 2012-01-03 18:29:04 <gmaxwell> (I'll give some halarious partial results in a bit)
1187 2012-01-03 18:31:18 <luke-jr> gmaxwell: instead of comparing time from block 1 to 160458, compare number of blocks in 30 minutes ;)
1188 2012-01-03 18:31:25 rdponticelli_ has quit (Ping timeout: 240 seconds)
1189 2012-01-03 18:31:47 <luke-jr> maybe not perfect, but still a general idea
1190 2012-01-03 18:32:08 wasabi3 has joined
1191 2012-01-03 18:32:23 vragnaroda has joined
1192 2012-01-03 18:32:27 <justmoon> I got 120000 blocks in 30 minutes with gmaxwell's patch and 145000 for bitcoinjs
1193 2012-01-03 18:32:40 <imsaguy> gmaxwell: you're lucky vragnaroda only just now joined :p
1194 2012-01-03 18:33:26 <vragnaroda> imsaguy: I still smacked him in #bitcoin.
1195 2012-01-03 18:34:23 wasabi2 has quit (Ping timeout: 252 seconds)
1196 2012-01-03 18:34:37 jim618 has joined
1197 2012-01-03 18:35:34 PK has joined
1198 2012-01-03 18:36:27 <justmoon> gmaxwell: OS and system specs would be good to know
1199 2012-01-03 18:36:40 <justmoon> gmaxwell: maybe your OS has a bug in mlock/munlock?
1200 2012-01-03 18:37:12 jim618 has left ()
1201 2012-01-03 18:37:51 gribble has joined
1202 2012-01-03 18:41:44 larsivi has joined
1203 2012-01-03 18:41:55 user_ has quit (Quit: Leaving)
1204 2012-01-03 18:42:03 BlueMatt has joined
1205 2012-01-03 18:44:09 vragnaroda has left ()
1206 2012-01-03 18:46:16 <luke-jr> IMO, mlock is basically useless so long as we're not secure-deleting unencrypted wallet files ;)
1207 2012-01-03 18:47:01 ovidiusoft has quit (Ping timeout: 252 seconds)
1208 2012-01-03 18:48:50 <justmoon> kind of interesting, with node-bitcoin-p2p I don't care about zeroing memory, because it doesn't handle any secrets
1209 2012-01-03 18:49:19 <luke-jr> wumpus: wumpus where are you? :P
1210 2012-01-03 18:49:19 <BlueMatt> the reason for the memory zeroing is to prevent use-after-free attacks
1211 2012-01-03 18:49:26 <BlueMatt> not to clear secrets
1212 2012-01-03 18:49:31 <midnightmagic> luke-jr: unless someone cares about whether their swap is vulnerable to analysis, though right?
1213 2012-01-03 18:49:32 <BlueMatt> (CDataStream never handles secrets
1214 2012-01-03 18:49:33 <BlueMatt> )
1215 2012-01-03 18:49:36 <BlueMatt> have to board bbl
1216 2012-01-03 18:49:38 BlueMatt has quit (Quit: Ex-Chat)
1217 2012-01-03 18:51:02 <justmoon> so what if an attacker uses-before-free...
1218 2012-01-03 18:51:51 BlueMatt-mobile has joined
1219 2012-01-03 18:52:45 LightRider has joined
1220 2012-01-03 18:53:10 <BlueMatt-mobile> justmoon then zeroing wont help
1221 2012-01-03 18:54:02 <LightRider> Is it possible to construct a bitcoin transaction such that anyone can spend the result?
1222 2012-01-03 18:54:19 <BlueMatt-mobile> Yes very easily
1223 2012-01-03 18:54:31 <BlueMatt-mobile> (With nonstd txn)
1224 2012-01-03 18:54:33 <gmaxwell> justmoon: http://people.xiph.org/~greg/bitcoin-sync.png
1225 2012-01-03 18:54:44 <gmaxwell> http://people.xiph.org/~greg/bitcoin-sync-speed.png
1226 2012-01-03 18:55:05 <justmoon> lol
1227 2012-01-03 18:55:09 MimeNarrator has joined
1228 2012-01-03 18:55:14 <BlueMatt-mobile> Heh oh god
1229 2012-01-03 18:55:21 <justmoon> gmaxwell: there is more to the story than just zeroing memory
1230 2012-01-03 18:55:39 <luke-jr> midnightmagic: swap isn't special
1231 2012-01-03 18:55:41 <BlueMatt-mobile> Kinda depressing that no one noticed that...
1232 2012-01-03 18:55:42 <gmaxwell> justmoon: it's not zeroing memory thats the issue, it's calling mlock.
1233 2012-01-03 18:55:45 <justmoon> for me your patch does maybe a 40% improvement
1234 2012-01-03 18:55:54 <justmoon> at most
1235 2012-01-03 18:55:55 <gmaxwell> justmoon: and mlock blows up the TLB.
1236 2012-01-03 18:56:07 <justmoon> so something is going on on your system that isn't on mine
1237 2012-01-03 18:56:12 <BlueMatt-mobile> gmaxwell can you benchmark how much time zeroing takes?
1238 2012-01-03 18:56:15 <gmaxwell> justmoon: may be worse on AMD vs intel. ... though, I'm also pulling from an mlocked fixed node.
1239 2012-01-03 18:56:21 <gmaxwell> (I'm still zeroing in mine)
1240 2012-01-03 18:56:42 <BlueMatt-mobile> Can you test nonzerod
1241 2012-01-03 18:56:54 <gmaxwell> BlueMatt-mobile: I would, but your patch didn't compile as was.
1242 2012-01-03 18:56:58 <justmoon> gmaxwell: right... pulling from a fixed node would probably be a good idea, wouldn't it.... *facepalm*
1243 2012-01-03 18:57:00 <gmaxwell> and I didn't feel like fixing it.
1244 2012-01-03 18:57:09 <BlueMatt-mobile> gmaxwell fixed now
1245 2012-01-03 18:57:23 <gmaxwell> okay. I'll let the embarassing mode run for a bit longer..
1246 2012-01-03 18:57:29 <BlueMatt-mobile> (I REALLY need to stop coding at night
1247 2012-01-03 18:57:31 <gmaxwell> justmoon: I'm also just a lot faster than you for some reason.
1248 2012-01-03 18:57:31 <BlueMatt-mobile> )
1249 2012-01-03 18:58:09 <justmoon> gmaxwell: hardware maybe? mine is a four year old core duo with a 5400rpm hard drive on its last leg :)
1250 2012-01-03 18:58:42 <gmaxwell> oh. yea, you're getting fsync bound.
1251 2012-01-03 18:59:17 <gmaxwell> This is on a X6 1055T with a super fast ssd and fs logging disabled.
1252 2012-01-03 18:59:40 <justmoon> lol
1253 2012-01-03 19:00:09 MimeNarrator has quit (Ping timeout: 276 seconds)
1254 2012-01-03 19:00:46 <gmaxwell> https://people.xiph.org/~greg/with.fix.debug.log.xz  < here is the debug log from that run.
1255 2012-01-03 19:01:11 <gmaxwell> justmoon: but hey, 40% is still nice on a system that is otherwise 'slow'
1256 2012-01-03 19:01:43 <justmoon> gmaxwell: yeah, I was just freaking out because if it was faster than bitcoinjs, then I just wasted two months of my life :)
1257 2012-01-03 19:01:50 <luke-jr> lol
1258 2012-01-03 19:02:09 <gmaxwell> justmoon: oh well, you may be in trouble if someone takes out the fsync crap. ;)
1259 2012-01-03 19:02:44 <luke-jr> :D
1260 2012-01-03 19:02:46 <justmoon> gmaxwell: maybe you could run bitcoinjs on your beastmachine sometime - I need to fix some bugs of my own first though
1261 2012-01-03 19:02:58 <justmoon> also: challenge accepted :P
1262 2012-01-03 19:03:35 <BlueMatt-mobile> justmoon tmpfs?
1263 2012-01-03 19:04:35 grobble is now known as copumpkin
1264 2012-01-03 19:05:05 <justmoon> BlueMatt-mobile: that machine has 2GB of memory - might work, but tight
1265 2012-01-03 19:05:23 <justmoon> also tmpfs is kinda cheating :P
1266 2012-01-03 19:05:25 <BlueMatt-mobile> Oh...
1267 2012-01-03 19:05:36 <BlueMatt-mobile> Buy a new machine?
1268 2012-01-03 19:05:52 <gmaxwell> BlueMatt-mobile: pull 740 gives me b92bbfce3fab46a79b5f06c746761a59891a3b9e which still doesn't build for me
1269 2012-01-03 19:06:03 <justmoon> my desktop is faster - but... it's complicated
1270 2012-01-03 19:07:05 <justmoon> although...
1271 2012-01-03 19:07:20 <justmoon> if I run on tmpfs anyway I could use a livecd
1272 2012-01-03 19:07:26 <justmoon> brb
1273 2012-01-03 19:07:28 justmoon has quit (Quit: Leaving)
1274 2012-01-03 19:07:40 <BlueMatt-mobile> gmaxwell i never tested it just fixed the function that looked culprity
1275 2012-01-03 19:08:22 nhodges has quit (Remote host closed the connection)
1276 2012-01-03 19:08:25 kobier has quit (Remote host closed the connection)
1277 2012-01-03 19:08:25 terrytibbs has quit (Remote host closed the connection)
1278 2012-01-03 19:08:25 <gmaxwell> the explody part is
1279 2012-01-03 19:08:25 <gmaxwell> serialize.h:934:10: error: ‘void CDataStream::insert(CDataStream::iterator, std::vector<char>::const_iterator, std::vector<char>::const_iterator)’ cannot be overloaded
1280 2012-01-03 19:08:36 <gmaxwell> (and since it's a C++ ism I'm not touching it)
1281 2012-01-03 19:08:42 <BlueMatt-mobile> Arg.. .
1282 2012-01-03 19:09:09 <BlueMatt-mobile> Oh come on that is the simplest error ever...just remove the func in question
1283 2012-01-03 19:10:46 Backburn2 has joined
1284 2012-01-03 19:11:47 BlueMatt-mobile has quit (Read error: Connection reset by peer)
1285 2012-01-03 19:11:59 BlueMatt-mobile has joined
1286 2012-01-03 19:12:35 <gmaxwell> BlueMatt-mobile: oh that was easy. I guess I should have looked.
1287 2012-01-03 19:12:51 <BlueMatt-mobile> Yep
1288 2012-01-03 19:12:59 davout has joined
1289 2012-01-03 19:14:15 davout_ has joined
1290 2012-01-03 19:16:07 terrytibbs has joined
1291 2012-01-03 19:17:30 davout has quit (Ping timeout: 248 seconds)
1292 2012-01-03 19:18:32 StevenCH has quit ()
1293 2012-01-03 19:19:01 <gmaxwell> BlueMatt-mobile: measurably faster, but it might end up taking longer because the keypool gen is still slow. :)
1294 2012-01-03 19:19:10 <gmaxwell> Graphs when it finishes.
1295 2012-01-03 19:20:28 <sipa> gmaxwell: new idea: for tried addresses, 256 buckets of 64 addresses, each based on high bits + 4 possibilities per low bits
1296 2012-01-03 19:21:16 <sipa> gmaxwell: for non-tried addresses, 256 buckets of 64 addresses, where in a first step 64 buckets are selected based on high bits of source, and in a second step one of those is selected based on the address itself
1297 2012-01-03 19:21:44 <sipa> this means that an attacker will have to send from many many source before he can cover all 256 buckets, as each source only covers 64 of them
1298 2012-01-03 19:23:33 justmoon has joined
1299 2012-01-03 19:23:54 rdponticelli has joined
1300 2012-01-03 19:24:06 BlueMatt-mobile has quit (Ping timeout: 244 seconds)
1301 2012-01-03 19:26:10 <luke-jr> oh ugly!
1302 2012-01-03 19:26:16 <luke-jr> Devcoin uses version 0 for their addresses too
1303 2012-01-03 19:26:18 <gmaxwell> I think thats quite attractive.
1304 2012-01-03 19:26:27 <luke-jr> gmaxwell: then you fail
1305 2012-01-03 19:26:28 <gmaxwell> oh
1306 2012-01-03 19:26:39 <gmaxwell> I thought you were responding to sipa
1307 2012-01-03 19:26:40 <luke-jr> :p
1308 2012-01-03 19:26:41 user_ has joined
1309 2012-01-03 19:26:41 <gmaxwell> yea that sucks.
1310 2012-01-03 19:27:01 <sipa> luke-jr: their problem
1311 2012-01-03 19:27:08 <luke-jr> yeah
1312 2012-01-03 19:27:28 <luke-jr> I was considering spending the 12 BTC to mine up to their merged mining block
1313 2012-01-03 19:27:38 <luke-jr> but I've decided to treat it like any other scamcoin :P
1314 2012-01-03 19:29:16 <sipa> gmaxwell: that would add up to about 1.3 MiB memory for all addresses... acceptable i think
1315 2012-01-03 19:29:23 <sipa> max
1316 2012-01-03 19:29:24 <gmaxwell> sipa: I assume still using a randomized hash function for all this? that sounds pretty good.
1317 2012-01-03 19:29:30 <sipa> yes
1318 2012-01-03 19:29:41 <sipa> with a nonce that should be unknown to attackers
1319 2012-01-03 19:30:40 <sipa> maybe use only 64 buckets total for the known addresses - you prefer not to use those, but need them to find a stable connection
1320 2012-01-03 19:30:48 <gmaxwell> Plus with random eviction... oh la la. I like this.
1321 2012-01-03 19:32:22 <gmaxwell> sipa: make known smaller, but make eviction from known insert into unknown again?
1322 2012-01-03 19:32:41 <gmaxwell> (or perhaps only do so probablistically)
1323 2012-01-03 19:33:14 <gmaxwell> (I guess the latter since we do want nodes to forget about addresses eventually)
1324 2012-01-03 19:33:48 <CIA-100> bitcoin: p2k * r76696d3caae2 ecoinpool/ (README.md apps/ecoinpool/rebar.config): Fixed Issues on Erlang R15B http://tinyurl.com/7n8ttk4
1325 2012-01-03 19:33:50 <gmaxwell> oh I guess insert into unknown if there is room in unknown and then only insert into unknown with low probability.
1326 2012-01-03 19:33:51 <CIA-100> bitcoin: p2k * r64dfcb915142 ecoinpool/ (41 files in 10 dirs): Web Frontend for ebitcoin http://tinyurl.com/6v6a46p
1327 2012-01-03 19:34:04 <sipa> i'd rather remove them if evicted from known
1328 2012-01-03 19:34:05 PK has quit ()
1329 2012-01-03 19:34:35 <sipa> if you hear from it again, it gets re-added to unknown anyway
1330 2012-01-03 19:35:49 <sipa> of course, you don't want to make eviction forget you about too many good nodes
1331 2012-01-03 19:36:38 <sipa> you could say: if unknown is X% full, eviction from known has (100-X)% chance to cause a move to unknown, otherwise remove
1332 2012-01-03 19:36:39 <gmaxwell> oh, when a unknown node connects... swap it with the node it would evict if it would evict one.
1333 2012-01-03 19:37:00 <sipa> how do you ever forget about a node then?
1334 2012-01-03 19:37:14 <gmaxwell> it'll get replaced by new unknown nodes you learn about.
1335 2012-01-03 19:37:15 <sipa> ah, by eviction caused by new unknowns
1336 2012-01-03 19:37:22 <sipa> sounds good
1337 2012-01-03 19:37:38 <sipa> what if a known node fails to connect?
1338 2012-01-03 19:38:14 <gmaxwell> well, we don't want to evict your whole good pool just because your network burped.. so two issues.. how to measure failure and what to do about it.
1339 2012-01-03 19:38:33 <gmaxwell> if you've measured failure in (some) reliable way, then I think you could just toss the node.
1340 2012-01-03 19:38:41 <sipa> just try another? or do we want to keep stats, and after N subsequent failures just remove it
1341 2012-01-03 19:39:40 osmosis has joined
1342 2012-01-03 19:39:48 <gmaxwell> thats the obvious thing to do.. count the failures.. fails n times toss it so long as the good pool is at least half full or whatever.
1343 2012-01-03 19:39:48 toffoo has quit ()
1344 2012-01-03 19:39:54 sneak has quit (Ping timeout: 248 seconds)
1345 2012-01-03 19:39:58 <gmaxwell> if it's not half full, then leave it there.
1346 2012-01-03 19:40:38 phantomfake has quit (Ping timeout: 240 seconds)
1347 2012-01-03 19:40:52 <sipa> with a random pre-selection based on source IP, you need about 20 (high bits of) sources to get a reasonable chance at poisoning the entire cache
1348 2012-01-03 19:41:24 <sipa> if the pre-selection is only 32 nodes, you need about 40 sources
1349 2012-01-03 19:41:46 <sipa> would be nice if you'd need >256 sources, as that would mean a /8 doesn't suffice
1350 2012-01-03 19:41:51 <sipa> but that's unreasonable
1351 2012-01-03 19:43:16 sneak has joined
1352 2012-01-03 19:43:16 sneak has quit (Changing host)
1353 2012-01-03 19:43:16 sneak has joined
1354 2012-01-03 19:43:55 <gmaxwell> sipa: might want to reserve a bin to only be reachable by dnsseed.
1355 2012-01-03 19:44:36 <gmaxwell> e.g. so you'd have to have your 40 sources plus a dnsseed.
1356 2012-01-03 19:46:29 <sipa> and other fixed sources, like -addnode, or builtin seed ips
1357 2012-01-03 19:47:32 <gmaxwell> (though I think when the good nodes list is ~empty it should just be directly populated with dnsseed, but thats mostly a seperate matter)
1358 2012-01-03 19:48:23 freeplay has quit (Ping timeout: 244 seconds)
1359 2012-01-03 19:51:23 <gmaxwell> BlueMattBot: you're 12 seconds faster.. which is good if you consider that you take 16 seconds longer for the keypool additions.
1360 2012-01-03 19:51:23 <BlueMattBot> gmaxwell you may not issue bot commands in this chat!
1361 2012-01-03 19:51:34 <gmaxwell> damnit
1362 2012-01-03 19:53:01 <Backburn2> i heard gavin is giving away free hats here in about an hour
1363 2012-01-03 19:53:51 <sipa> hmm the OP_EVAL discussion is in 10 minutes?
1364 2012-01-03 19:54:21 <Backburn2> 21:00 UTC is in hour and 10 right?
1365 2012-01-03 19:54:36 eldentyrell has joined
1366 2012-01-03 19:55:02 <nanotube> whatever happens with op-eval, i'll just say, let's give it plenty of time to cure, before pushing it out into a client release.
1367 2012-01-03 19:55:19 <Backburn2> discussion started early XD
1368 2012-01-03 19:59:57 freeplay has joined
1369 2012-01-03 20:00:55 <gmaxwell> new graphs: http://people.xiph.org/~greg/bitcoin-sync.png
1370 2012-01-03 20:01:01 <gmaxwell> http://people.xiph.org/~greg/bitcoin-sync-speed.png
1371 2012-01-03 20:01:10 <gmaxwell> http://people.xiph.org/~greg/bitcoin-sync-speed-smooth.png
1372 2012-01-03 20:02:26 <Backburn2> yummy
1373 2012-01-03 20:03:12 <gmaxwell> (so it _is_ 1000x faster.. but only for the first few blocks. :) )
1374 2012-01-03 20:03:17 <marf_away> wow
1375 2012-01-03 20:03:22 <marf_away> is that in 0.6?
1376 2012-01-03 20:03:36 <sipa> it will be
1377 2012-01-03 20:03:38 <gmaxwell> marf_away: not merged yet, but I'm sure some form of it will be.
1378 2012-01-03 20:04:01 <gmaxwell> marf_away: YMMV, some systems may not suffer from mlock as much as this one does.
1379 2012-01-03 20:04:16 <marf_away> was it a bug or is it now less secrue?
1380 2012-01-03 20:04:51 <gmaxwell> It was a bug. Some reasonable security improvement also changed a whole bunch of non-security-relevant stuff.
1381 2012-01-03 20:05:48 <gmaxwell> bluematt's patch arguably hurts security a little.. but its also not that much faster.. e.g. 30 seconds out of 30 minutes of work.
1382 2012-01-03 20:06:02 molecular has joined
1383 2012-01-03 20:07:02 <luke-jr> marf_away: that being said, stuff has been "will be in 0.5" that wasn't either
1384 2012-01-03 20:08:04 Cablesaurus has quit (Quit: Clap on! , Clap off! Clap@#&$NO CARRIER)
1385 2012-01-03 20:08:57 <gmaxwell> luke-jr: you really think _that_ is going to miss the next release, whatever the heck it is? :)
1386 2012-01-03 20:09:13 <luke-jr> gmaxwell: who knows
1387 2012-01-03 20:09:22 BlueMatt has joined
1388 2012-01-03 20:09:38 genjix has joined
1389 2012-01-03 20:09:51 <luke-jr> does anyone know if the bug fixed in 56c6e3696d0f8e222395be00f9e532412781b339 affects 0.4 or 0.5?
1390 2012-01-03 20:09:57 <luke-jr> or if it just applies to OP_EVAL?
1391 2012-01-03 20:10:31 kobier has joined
1392 2012-01-03 20:10:32 <luke-jr> (I don't mean "does the code merge" - it does - but whether the problem it's "fixing" is actually a problem before OP_EVAL)
1393 2012-01-03 20:10:57 <BlueMatt> luke-jr: anything post encryption, if you are talking about the gmaxwell-found slowness
1394 2012-01-03 20:11:30 <genjix> why do people prefer tor over i2p?
1395 2012-01-03 20:11:39 <genjix> is it because tor has exit nodes?
1396 2012-01-03 20:11:48 <gavinandresen> i2p has exit nodes....
1397 2012-01-03 20:12:34 <gavinandresen> luke-jr: I'm pretty sure 56c does apply to old releases, but you'd have to ask wumpus to be absolutely sure (I think if you used RPC send commands you could confuse the GUI wallet)
1398 2012-01-03 20:12:40 <genjix> ah they are called out proxy... still why is tor more preferred?
1399 2012-01-03 20:12:51 <gavinandresen> genjix: better marketing?
1400 2012-01-03 20:13:25 <gavinandresen> tor definitely has better packaging than i2p
1401 2012-01-03 20:13:43 <gmaxwell> genjix: http://www.i2p2.de/how_networkcomparisons
1402 2012-01-03 20:14:14 <genjix> gmaxwell: yeah i'm reading that and the benefits of i2p seem far better than tor
1403 2012-01-03 20:14:17 <genjix> "Designed and optimized for hidden services, which are much faster than in Tor"
1404 2012-01-03 20:14:33 <genjix> "Fully distributed and self organizing"
1405 2012-01-03 20:14:45 <genjix> tor's argument is just "we are more popular because."
1406 2012-01-03 20:14:53 <luke-jr> "Java, not C (ewww)" <-- why I2P sucks
1407 2012-01-03 20:15:33 <welterde> (and vice-versa ;)
1408 2012-01-03 20:15:40 <luke-jr> no, C is great
1409 2012-01-03 20:15:49 <genjix> 1 good java coder is better than 100 bad c coders
1410 2012-01-03 20:16:06 <genjix> a good artist doesnt blame his tools
1411 2012-01-03 20:16:12 <BlueMatt> yay religious wars
1412 2012-01-03 20:16:20 <gavinandresen> If I had infinite time, I might learn a whole lot more about network programming and i2p-ize bitcoin....
1413 2012-01-03 20:16:27 <genjix> note: i dislike java
1414 2012-01-03 20:16:27 <luke-jr> genjix: maybe, but nobody wants to *use* Java ;)
1415 2012-01-03 20:16:35 <helo> 1 good c coder is better than 1024 bad java coders
1416 2012-01-03 20:16:39 <luke-jr> Java-the-language isn't too bad
1417 2012-01-03 20:16:46 <luke-jr> but Java-the-VM sucks
1418 2012-01-03 20:17:06 <welterde> luke-jr: still better than all other VMs
1419 2012-01-03 20:17:08 <genjix> i dunno. infinite namespace recursion is pretty bad :p
1420 2012-01-03 20:17:19 * BlueMatt gets popcorn
1421 2012-01-03 20:17:29 <genjix> and fuzzy lifetime for objects is horrid
1422 2012-01-03 20:17:29 <luke-jr> welterde: not true
1423 2012-01-03 20:17:35 <genjix> means RAII is not possible
1424 2012-01-03 20:17:40 <luke-jr> only Java manages to eat tons of memory for nothing
1425 2012-01-03 20:17:49 <sipa> please
1426 2012-01-03 20:17:51 <luke-jr> the only other language close to that is PHP and IIRC it's interpreted
1427 2012-01-03 20:18:02 <welterde> luke-jr: uh.. perl is worse than that
1428 2012-01-03 20:18:09 <luke-jr> welterde: no way, perl is ultra-light
1429 2012-01-03 20:18:22 <rjk2> gavinandresen: don't say that too loud, otherwise you might get druggies breathing down your neck for it to happen RIGHT NOW OMG
1430 2012-01-03 20:18:22 <welterde> luke-jr: not true ;)
1431 2012-01-03 20:18:29 tower has quit (Quit: | ReactOS - The FOSS alternative to MS Windows! | http://www.reactos.org/ | join #ReactOS |)
1432 2012-01-03 20:18:33 <luke-jr> welterde: very true
1433 2012-01-03 20:18:53 <luke-jr> Perl programs use a tiny fraction of the memory used by PHP and PHP uses a fraction of the memory used by Java
1434 2012-01-03 20:18:57 <luke-jr> for the same tasks
1435 2012-01-03 20:18:57 <welterde> luke-jr: maybe just on my systems.. dunno
1436 2012-01-03 20:19:19 <phantomcircuit> we should be using PHP for network stuff
1437 2012-01-03 20:19:24 <phantomcircuit> seems to work well for webs
1438 2012-01-03 20:19:29 * phantomcircuit runs
1439 2012-01-03 20:19:29 <rjk2> lol
1440 2012-01-03 20:19:46 <Backburn2> <3
1441 2012-01-03 20:20:00 <luke-jr> I agree with phantomcircuit: let's rewrite Bitcoin in all Perl.
1442 2012-01-03 20:20:01 <welterde> phantomcircuit: seen people try that.. worked.. really.. well.. ;)
1443 2012-01-03 20:20:33 <luke-jr> including redefining Scripts to be Perl scripts
1444 2012-01-03 20:20:57 <luke-jr> >:p
1445 2012-01-03 20:21:06 <genjix> d:<
1446 2012-01-03 20:21:08 <luke-jr> who runs Vircurex btw?
1447 2012-01-03 20:21:10 <luke-jr> it's down
1448 2012-01-03 20:21:14 <welterde> luke-jr: and at least I can compile and run my java applications(ok.. just i2p more or less) on machines with < 1GB of ram..
1449 2012-01-03 20:21:30 <luke-jr> welterde: can you? I can't.
1450 2012-01-03 20:21:31 <welterde> (not true for many c++ applications :>)
1451 2012-01-03 20:21:35 <luke-jr> I can't compile Java period really.
1452 2012-01-03 20:21:42 <luke-jr> why can't Java compile in some simple way?
1453 2012-01-03 20:22:00 <luke-jr> GCJ works ok for single-class projects, but who knows for anything complex
1454 2012-01-03 20:22:08 <justmoon> gmaxwell: still there?
1455 2012-01-03 20:22:56 kdomanski has joined
1456 2012-01-03 20:23:21 <welterde> luke-jr: I guess we are back to I don't have 16GB of ram in my machine ;)
1457 2012-01-03 20:23:30 ahbritto_ has quit (Read error: Operation timed out)
1458 2012-01-03 20:24:16 <welterde> luke-jr: and btw.. it says so in the perl manpage somewhere too
1459 2012-01-03 20:24:55 <welterde> (high memory usage that is)
1460 2012-01-03 20:25:12 user_ has quit (Quit: Leaving)
1461 2012-01-03 20:25:37 minimoose has quit (Quit: minimoose)
1462 2012-01-03 20:25:38 ahbritto has quit (Ping timeout: 255 seconds)
1463 2012-01-03 20:26:11 <luke-jr> welterde: that'
1464 2012-01-03 20:26:14 <luke-jr> welterde: that's MY point
1465 2012-01-03 20:26:32 <welterde> that perl consumes loads of loads of memory?
1466 2012-01-03 20:27:21 <luke-jr> no, Perl does not
1467 2012-01-03 20:28:35 <welterde> luke-jr: what stuff programmed in perl do you use?
1468 2012-01-03 20:28:49 booo has quit (Ping timeout: 240 seconds)
1469 2012-01-03 20:29:20 <luke-jr> I maintain a VoiceXML browser, various interpretors, a MIPS emulator, and a bunch of other toys
1470 2012-01-03 20:29:24 <gmaxwell> justmoon: kinda
1471 2012-01-03 20:30:23 molecular has quit (Quit: Leaving)
1472 2012-01-03 20:30:49 BlueMatt has quit (Quit: Ex-Chat)
1473 2012-01-03 20:31:07 <welterde> luke-jr: hmm.. so more or less nagios-frontend-scale
1474 2012-01-03 20:31:16 <gavinandresen> luke-jr: I reworked -blocknotify; can you help test?  https://github.com/gavinandresen/bitcoin-git/commit/28decb4c07f8f292f91eff02f94e38ec33a6e34a
1475 2012-01-03 20:31:51 <luke-jr> gavinandresen: I intentionally didn't use system()
1476 2012-01-03 20:31:52 molecular has joined
1477 2012-01-03 20:31:57 <gavinandresen> luke-jr: why not?
1478 2012-01-03 20:32:07 <welterde> luke-jr: maybe all perl-software I use just sucks.. but they all consume loads of ram ;)
1479 2012-01-03 20:32:19 <luke-jr> gavinandresen: it blocks
1480 2012-01-03 20:32:31 <gavinandresen> .... thats why I use boost::thread....
1481 2012-01-03 20:32:42 RazielZ has quit (Ping timeout: 248 seconds)
1482 2012-01-03 20:33:00 <luke-jr> oh right
1483 2012-01-03 20:33:15 <welterde> (scripts.. sure.. I couldn't care less.. but long running processes.. annoying)
1484 2012-01-03 20:33:48 <luke-jr> gavinandresen: is system() portable to Windows?
1485 2012-01-03 20:33:58 <gavinandresen> yes, according to Mr. Google and MSDN
1486 2012-01-03 20:35:37 tower has joined
1487 2012-01-03 20:35:41 <luke-jr> probably for performance, blocknotify has traditionally not occurred during the initial download
1488 2012-01-03 20:35:49 <gavinandresen> luke-jr: yes, I was just about to bring that up....
1489 2012-01-03 20:36:09 <gavinandresen> luke-jr:  it seems to me better to notify if you are catching up with the chain, rather than not....
1490 2012-01-03 20:36:35 <gavinandresen> luke-jr: because whatever command you call can look at timestamps and ignore old blocks if it doesn't care
1491 2012-01-03 20:36:44 <luke-jr> that could become a DoS, though
1492 2012-01-03 20:37:09 <gavinandresen> luke-jr: how?  new blocks have to have good proof-of-work or they get dumped
1493 2012-01-03 20:37:17 ahbritto_ has joined
1494 2012-01-03 20:37:26 RazielZ has joined
1495 2012-01-03 20:37:39 <luke-jr> gavinandresen: if they can delay enough blocks, suddenly you have a ton of PIDs used up…
1496 2012-01-03 20:37:55 ahbritto has joined
1497 2012-01-03 20:38:11 <luke-jr> considering a new thread uses up a PID internally, then system() forks and execs sh, then sh forks and execs your command(s)
1498 2012-01-03 20:38:20 <welterde> luke-jr: anyway... at least we don't have as many bufferoverlows / heapoverflows / etc. to fix as tor.. that's at least *something*, right? ;)
1499 2012-01-03 20:38:42 <luke-jr> welterde: I write perfect code, so I wouldn't know.
1500 2012-01-03 20:38:44 <luke-jr> :P
1501 2012-01-03 20:38:59 <luke-jr> also disclaimer: I don't use Tor either
1502 2012-01-03 20:39:35 <genjix> "< welterde> luke-jr: anyway... at least we don't have as many bufferoverlows / heapoverflows / etc. to fix as tor."
1503 2012-01-03 20:39:38 <genjix> sick brag
1504 2012-01-03 20:40:08 <luke-jr> (in reality, using a high-level language to avoid bugs really just means that *when* you encounter said bug, you *can't* really fix it)
1505 2012-01-03 20:40:15 <welterde> luke-jr: heh.. so I have heard :P
1506 2012-01-03 20:41:12 <welterde> luke-jr: sure.. but I have yet to see such a bug that can be exploited from outside
1507 2012-01-03 20:41:13 <luke-jr> gavinandresen: anything that really needs to look at old blocks, can always scan for them with a "startup" program too
1508 2012-01-03 20:41:28 <gavinandresen> luke-jr:  I think the real danger is DoS'ing yourself by running -blocknotify=...  on a brand-new install... Ok, I'll make if !InitialDownload
1509 2012-01-03 20:41:54 <welterde> genjix: but it's true ;)
1510 2012-01-03 20:42:08 <luke-jr> gavinandresen: if you have no PID limits in place, that's probably the only real risk; but a sanely configured system will have strict PID limits to stop a user from forkbombing the whole system
1511 2012-01-03 20:42:52 <luke-jr> gavinandresen: if you're intending to replace my branch, also need to add the documentation in init.cpp
1512 2012-01-03 20:43:08 BlueMatt has joined
1513 2012-01-03 20:43:10 <luke-jr> (not sure if that's the intent, or if you expect me to merge/replace my branch with these changes)
1514 2012-01-03 20:43:49 <luke-jr> btw, this rework is a good example of the difference between a C programmer and a C++ programmer :p
1515 2012-01-03 20:44:03 <luke-jr> you managed to replace 119 lines with like 30 ;)
1516 2012-01-03 20:44:15 <gavinandresen> I just hate #ifdefs
1517 2012-01-03 20:44:20 <luke-jr> heh
1518 2012-01-03 20:44:22 <welterde> genjix: but yeah.. we have about as many "high level" bugs as tor
1519 2012-01-03 20:45:18 <BlueMatt> gavinandresen: #ifdef bool x = 1; #else bool x = 0; #endif if(x) doSomething;
1520 2012-01-03 20:45:35 <gavinandresen> ... don't get me started on #ifdef UPNP.....
1521 2012-01-03 20:45:59 <luke-jr> well, *that* is *very good* use of #ifdef :p
1522 2012-01-03 20:46:19 * justmoon wonders what is smaller: the SHA256 hashes of all blocks or a bzip2 of the block headers
1523 2012-01-03 20:46:19 <sipa> and hardly anyone gets it the first time
1524 2012-01-03 20:46:26 <luke-jr> sipa: well, that's the build system's problem
1525 2012-01-03 20:46:50 * justmoon just answered his own question
1526 2012-01-03 20:48:04 <LightRider> ok guys, I just had bitcoinqt crash on me. How can I best help you determine the problem?
1527 2012-01-03 20:48:24 <LightRider> I created a minidump from processexplorer, and I have the main thread stack copied
1528 2012-01-03 20:48:44 <sipa> LightRider: can you pastebin it somewhere?
1529 2012-01-03 20:48:48 <sipa> *paste
1530 2012-01-03 20:49:08 <luke-jr> LightRider: most likely the main thread is useless
1531 2012-01-03 20:49:13 <luke-jr> LightRider: can you get the other threads?
1532 2012-01-03 20:49:27 <LightRider> Yeah, i have all the threads available
1533 2012-01-03 20:49:28 <sipa> justmoon: the bzip2 being smaller seems impossible to me
1534 2012-01-03 20:49:41 BlueMatt has quit (Ping timeout: 252 seconds)
1535 2012-01-03 20:49:44 <justmoon> sipa: of course it is, it contains two sha hashes per block ^^
1536 2012-01-03 20:49:53 <sipa> exactly
1537 2012-01-03 20:49:53 <justmoon> I just needed to write it down to realize it for some reason
1538 2012-01-03 20:50:30 <LightRider> Is it possible to pastebin a .dmp file?
1539 2012-01-03 20:51:24 <luke-jr> I think he  meant the stacktrace
1540 2012-01-03 20:51:27 <LightRider> ah
1541 2012-01-03 20:52:15 jim618 has joined
1542 2012-01-03 20:54:44 BlueMatt has joined
1543 2012-01-03 20:55:09 <LightRider> http://yfrog.com/gyw9uip
1544 2012-01-03 20:55:09 nibor has joined
1545 2012-01-03 20:55:17 <LightRider> which one of those are you interested in?
1546 2012-01-03 20:55:29 <genjix> https://en.bitcoin.it/wiki/Meetings
1547 2012-01-03 20:55:50 <genjix> i'll put logs on there after
1548 2012-01-03 20:56:14 <luke-jr> genjix: it's backward!
1549 2012-01-03 20:56:17 <luke-jr> 2011-01-03
1550 2012-01-03 20:56:47 <jim618> 2012-01-03  !
1551 2012-01-03 20:56:48 <genjix> in europe it's DD/MM/YYYY :)
1552 2012-01-03 20:57:13 <luke-jr> genjix: I don't care how backward Europe is.
1553 2012-01-03 20:57:20 <luke-jr> jim618: oh right
1554 2012-01-03 20:57:21 <sipa> YYYY/MM/DD or DD/MM/YYYY, i don't care
1555 2012-01-03 20:57:29 <sipa> as long as it is not YYYY/DD/MM
1556 2012-01-03 20:57:31 <jim618> It is 2012 - Happy New Year
1557 2012-01-03 20:57:37 <sipa> hello jim618!
1558 2012-01-03 20:57:41 <genjix> bike shed paint
1559 2012-01-03 20:57:42 <luke-jr> sipa: you mean MM/DD/YYYY
1560 2012-01-03 20:57:47 <sipa> luke-jr: yeah, that
1561 2012-01-03 20:58:02 <BlueMatt> how about Jan 3, 2012
1562 2012-01-03 20:58:02 <BlueMatt> keeps everyone happy?
1563 2012-01-03 20:58:25 <luke-jr> no
1564 2012-01-03 20:58:28 <luke-jr> 2012 Jan 3
1565 2012-01-03 20:58:48 <genjix> we still has 10 mins
1566 2012-01-03 20:58:54 <luke-jr> or better still, 7 Anuary 
1567 2012-01-03 20:58:56 <genjix> BlueMatt: good idea
1568 2012-01-03 20:58:56 <gribble> New news from bitcoinrss: gavinandresen opened pull request 743 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/743>
1569 2012-01-03 20:59:30 <sipa> what's wrong with you people? just use 0x4D2238D0
1570 2012-01-03 20:59:32 <gavinandresen> There's an RFC for dates... I think 3 Jan 2012  adheres to the standard
1571 2012-01-03 20:59:48 <luke-jr> 2012-01-03 does too
1572 2012-01-03 20:59:51 <genjix> hoooo lol i put 2011
1573 2012-01-03 21:00:13 <sipa> the first days of the next year actually belong to the previous one
1574 2012-01-03 21:00:17 <sipa> everybody knows that
1575 2012-01-03 21:00:58 <gavinandresen> I like eleven, but I don' t think I'll get away with dating my checks  34 Dec 2011
1576 2012-01-03 21:01:25 <luke-jr> :P
1577 2012-01-03 21:02:28 <genjix> so i guess there is no new OP_EVAL now
1578 2012-01-03 21:03:07 <genjix> instead there's a new script template which will be evaluated implicitly
1579 2012-01-03 21:03:22 <sipa> the magic hash script
1580 2012-01-03 21:03:28 <jrmithdobbs> gavinandresen: that rfc basically makes every known human date format "valid" and is a bitch
1581 2012-01-03 21:03:41 diki has quit (Ping timeout: 276 seconds)
1582 2012-01-03 21:03:58 <sipa> fine; meating time?
1583 2012-01-03 21:04:04 * BlueMatt still thinks we should add a flagging OP_NOP1 to the front
1584 2012-01-03 21:04:05 <sipa> meeting!
1585 2012-01-03 21:04:16 <phantomcircuit> gavinandresen, there are several RFCs for dates
1586 2012-01-03 21:04:17 <gavinandresen> mmmm, meat
1587 2012-01-03 21:04:19 <genjix> yep
1588 2012-01-03 21:04:25 <sipa> i definitely wouldn't mind an OP_NOP1 in front
1589 2012-01-03 21:04:43 <gavinandresen> I'm firmly against putting an extra byte in front.
1590 2012-01-03 21:04:45 <genjix> i would like an OP_NOP1 too if simply for the future when things become muddled.
1591 2012-01-03 21:05:01 <justmoon> I'm against adding an extra byte and using up OP_NOP1 for no good reason
1592 2012-01-03 21:05:10 <gavinandresen> ... but is that the first item on the agenda?  Is there an agenda?
1593 2012-01-03 21:05:10 <justmoon> if you mean that script add OP_NOP to the front
1594 2012-01-03 21:05:12 <genjix> the python mantra: in the face of ambiguity, avoid the temptation to guess
1595 2012-01-03 21:05:29 <justmoon> i.e. if you *don't* want code replacement to happen
1596 2012-01-03 21:05:35 <justmoon> add OP_NOP
1597 2012-01-03 21:05:36 <sipa> justmoon: it's not using up; OP_NOP1 can still be used to signify other "special" scripts later
1598 2012-01-03 21:06:01 <genjix> OP_NOP1 = this script, OP_NOP1 OP_NOP1 = another script, ...
1599 2012-01-03 21:06:12 <justmoon> sipa: well, I'm trying to use the logic of the people who are in favor of the OP_NOP1
1600 2012-01-03 21:06:38 <justmoon> sipa: i.e. that people are going to want to actually use some awkward script you should never use in practice
1601 2012-01-03 21:06:40 <sipa> justmoon: i don't like giving a special meaning to an otherwise ordinary and perfectly valid script
1602 2012-01-03 21:07:05 <justmoon> sipa: I don't like adding a byte purely to make you happy
1603 2012-01-03 21:07:12 <sipa> fair point
1604 2012-01-03 21:07:28 <genjix> yeah there's also the issue of blockchain bloat
1605 2012-01-03 21:07:44 <luke-jr> I don't think scripts should be special-cased.
1606 2012-01-03 21:07:48 <gavinandresen> I don't like adding extra rules to the BIP that say what happens if the first byte is OP_NOP1 and the next ones are NOT HASH <> EQUAL
1607 2012-01-03 21:07:52 <genjix> and then what gavin said about extra rules
1608 2012-01-03 21:07:59 Carmivore has quit (Remote host closed the connection)
1609 2012-01-03 21:08:41 <genjix> ok, well i dont feel too strongly about having the byte. it would be nice. whatever.
1610 2012-01-03 21:08:56 <luke-jr> I prefer the original OP_EVAL.
1611 2012-01-03 21:09:00 <luke-jr> with recursion fixed.
1612 2012-01-03 21:09:01 <gavinandresen> I hate to bring it up.... but the byte could be in the scriptSig
1613 2012-01-03 21:09:44 <luke-jr> gavinandresen: so an attacker can just say "don't execute this" and bypass the whole thing?
1614 2012-01-03 21:09:45 <genjix> so you're saying that OP_DUP OP_HASH160 <> OP_EQUAL would be valid?
1615 2012-01-03 21:09:51 <genjix> what's to stop me spending that
1616 2012-01-03 21:10:20 <justmoon> o_O - I think gavin just means putting the OP_NOP1 marker byte somewhere else
1617 2012-01-03 21:10:22 <gavinandresen> luke-jr: you're right, that wouldn't work.  never mind
1618 2012-01-03 21:11:04 <genjix> what's the timescale for this last idea?
1619 2012-01-03 21:11:14 <genjix> because it is pretty good imo and is good enough
1620 2012-01-03 21:11:33 <justmoon> genjix: two weeks delay compared to OP_EVAL
1621 2012-01-03 21:11:33 <BlueMatt> who wants to volunteer to implement it?
1622 2012-01-03 21:11:34 <genjix> and it's simple enough that there doesn't seem to be any problems
1623 2012-01-03 21:11:57 <sipa> i don't like "doesn't seem to be"
1624 2012-01-03 21:12:35 <justmoon> *crickets*
1625 2012-01-03 21:12:40 <genjix> well the other ideas all had nagging feelings for me
1626 2012-01-03 21:12:41 <gavinandresen> I implemented it yesterday, it is only about 20 lines of code to do the validation
1627 2012-01-03 21:12:43 <Eliel> how does the current version react to transactions with one of the reserved opcodes in them?
1628 2012-01-03 21:12:47 <genjix> but this one is nice it seems
1629 2012-01-03 21:13:03 <genjix> Eliel: well in bitcoin there are a bunch of OP_NOP... which are ignored
1630 2012-01-03 21:13:15 <Eliel> ah, ok, so those are the reserved ones.
1631 2012-01-03 21:13:22 <genjix> the idea was before to replace them, but now there won't be any new OPs introduced
1632 2012-01-03 21:13:34 <justmoon> gavinandresen: does EvalScript() need any modification at all for PayToScriptHash?
1633 2012-01-03 21:13:53 <gavinandresen> justmoon: no
1634 2012-01-03 21:14:07 <justmoon> yeah, so that's something I really like
1635 2012-01-03 21:14:09 <gavinandresen> justmoon: It is all done a level higher, in VerifyScript
1636 2012-01-03 21:14:15 <justmoon> exactly
1637 2012-01-03 21:14:16 <gmaxwell> meh, byte bloat.
1638 2012-01-03 21:14:21 <genjix> so the old transaction was DUP HASH160 <pubkey hash> EQUALVERIFY CHECKSIG : <sig> <pubkey>.
1639 2012-01-03 21:14:23 Carmivore has joined
1640 2012-01-03 21:14:28 <genjix> the new one is like:
1641 2012-01-03 21:14:42 <Eliel> I'd personally favor redefining one of the NOPS but that wouldn't be backwards compatible I guess. perhaps have this hackiness be temporary measure so you can cut out even more bytes in the future once all clients have support?
1642 2012-01-03 21:14:52 <BlueMatt> gavinandresen: oh, is there a pull?
1643 2012-01-03 21:14:58 <genjix> DUP HASH160 <hash of code> EQUAL : <sig> <<pubkey hash> CHECKSIG>
1644 2012-01-03 21:15:13 <gavinandresen> BlueMatt: no pull yet, still testing/polishing.  And waiting for the results of this meeting
1645 2012-01-03 21:15:36 <gavinandresen> genjix:  No, new would be:    HASH160 <> EQUAL
1646 2012-01-03 21:15:38 <BlueMatt> so, what, do we vote on if we are all good with this solution?
1647 2012-01-03 21:15:38 <genjix> and the client sees the output script and understands implicitly to execute the top stack item at the end or start
1648 2012-01-03 21:15:42 <gavinandresen> (no need to DUP)
1649 2012-01-03 21:15:44 <genjix> ok
1650 2012-01-03 21:15:56 <luke-jr> what is the current spec we're discussing?
1651 2012-01-03 21:16:07 <sipa> magic hash script
1652 2012-01-03 21:16:15 <sipa> or how is it called?
1653 2012-01-03 21:16:17 <luke-jr> so exactly the worst possible option
1654 2012-01-03 21:16:19 <luke-jr> ?
1655 2012-01-03 21:16:24 <justmoon> sipa: PayToScriptHash
1656 2012-01-03 21:16:25 <genjix> magic hash script will do :p
1657 2012-01-03 21:16:44 <BlueMatt> (for the record /me is lagging by anywhere from 10 to 60 sec, so dont expect responses...)
1658 2012-01-03 21:17:08 coblee has quit (Ping timeout: 240 seconds)
1659 2012-01-03 21:17:41 <genjix> i think the only checks done during block validation which regard the scripts are the sig ops count
1660 2012-01-03 21:18:21 spaola has quit (Quit: ne0futur)
1661 2012-01-03 21:18:23 dvide has quit (Ping timeout: 260 seconds)
1662 2012-01-03 21:18:31 rjk2 has quit (Quit: Over and out)
1663 2012-01-03 21:18:42 <luke-jr> and what if i really want my data to be DATA and NOT a script?
1664 2012-01-03 21:19:18 <BlueMatt> in the interest of time (since Id assume most people understand the current magic hash script idea pretty well) can we vote on using an OP_NOP1, and then vote on the final solution?
1665 2012-01-03 21:19:27 <justmoon> luke-jr: OP_NOP OP_HASH160 <> OP_EQUAL
1666 2012-01-03 21:19:28 <sipa> then don't place it in a place that is declared by the protocol to contain a script?
1667 2012-01-03 21:19:39 <genjix> eh i prefer not voting on dangerous issues.
1668 2012-01-03 21:19:41 <gavinandresen> luke-jr: or OP_RIPEMD160 <> OP_EQUAL
1669 2012-01-03 21:19:55 spaola has joined
1670 2012-01-03 21:19:58 <justmoon> luke-jr: or OP_HASH160 <> OP_EQUALVERIFY OP_1
1671 2012-01-03 21:20:15 <gmaxwell> genjix: likewise.
1672 2012-01-03 21:20:16 <luke-jr> and how about if I want to use a single SHA256 for the hash?
1673 2012-01-03 21:20:20 <justmoon> but I guess gavinandresen's way saves one byte ;)
1674 2012-01-03 21:20:41 <genjix> luke-jr: just put a NOP in there?
1675 2012-01-03 21:20:54 <luke-jr> no, I mean for a script
1676 2012-01-03 21:20:59 <BlueMatt> luke-jr: so that you get regular-looking addresses
1677 2012-01-03 21:21:07 <sipa> i'm not too sure about hardcoding HASH160 as hash-function
1678 2012-01-03 21:21:19 <sipa> but i guess it's equally easy to extend it in the future if necessary
1679 2012-01-03 21:21:28 <justmoon> hmm
1680 2012-01-03 21:21:30 <genjix> wait
1681 2012-01-03 21:21:32 <luke-jr> OP_EVAL was far better than this ugly thing
1682 2012-01-03 21:21:35 <sipa> (note that secp256k1 only has 128 bits of security anyway)
1683 2012-01-03 21:21:40 <gavinandresen> Yeah, we're already in the HASH160 boat.
1684 2012-01-03 21:21:45 dvide has joined
1685 2012-01-03 21:21:52 <genjix> why not define OP_X to be OP_HASH160 + ... + OP_EQUAL?
1686 2012-01-03 21:21:59 <genjix> OP_X ...
1687 2012-01-03 21:22:03 <BlueMatt> if you dont hardcode hash function, you have to put hash function in addresses...
1688 2012-01-03 21:22:07 <genjix> OP_X <code hash>
1689 2012-01-03 21:22:08 <gmaxwell> I'm not super keen on the hardcoded hash either. But, meh.
1690 2012-01-03 21:22:09 user__ has joined
1691 2012-01-03 21:22:21 <gmaxwell> BlueMatt: nah, the address can imply OP_HASH160 without putting it in the script.
1692 2012-01-03 21:22:21 <sipa> BlueMatt: no, the address type defines the function
1693 2012-01-03 21:22:27 <justmoon> sipa: that doesn't necessarily means it's weaker than RIPE160
1694 2012-01-03 21:22:31 <genjix> that would solve the extra rules, the ambiguity and wanting a marker byte
1695 2012-01-03 21:22:32 ByteCoin has joined
1696 2012-01-03 21:22:37 <gavinandresen> genjix: because having old clients half-validate the transaction is valuable.
1697 2012-01-03 21:22:37 <genjix> it is a composition of operations
1698 2012-01-03 21:22:46 <genjix> ah damn that's right
1699 2012-01-03 21:22:48 <gmaxwell> genjix: ++++
1700 2012-01-03 21:22:53 <gmaxwell> oh
1701 2012-01-03 21:22:54 <luke-jr> how about prepending the script data with <script version> and <hash type> ?
1702 2012-01-03 21:22:58 <BlueMatt> sipa: yea, and youd have to change the address type...
1703 2012-01-03 21:23:00 <genjix> yeah i lost it there :p
1704 2012-01-03 21:23:30 <sipa> justmoon: no, indeed, but assuming RIPEMD160 + SHA256 is secure, you don't lose any of secp256k1's security by only using 160 bits
1705 2012-01-03 21:23:32 <justmoon> gavinandresen: I recently argued that half-validation really is no validation, so...
1706 2012-01-03 21:23:44 <gavinandresen> luke-jr: ... and while we're at it, lets change the standard DUP HASH160 <> EQUALVERIFY transaction too... NOT.
1707 2012-01-03 21:23:51 b4epoche_ has joined
1708 2012-01-03 21:24:13 <luke-jr> gavinandresen: I mean only for the eval'd scripts
1709 2012-01-03 21:24:38 <justmoon> sipa: right, it's the "assuming RIPEMD160 + SHA256 is secure" part that I wanted to point out
1710 2012-01-03 21:24:46 b4epoche has quit (Ping timeout: 240 seconds)
1711 2012-01-03 21:24:46 b4epoche_ is now known as b4epoche
1712 2012-01-03 21:25:43 <sipa> i have no problem with the current proposal as such, assuming we can still do some nice, more extensive script-tweaking by introducing a more complete OP_EVAL (with possibly changed script language inside) later
1713 2012-01-03 21:25:50 <sipa> however, i fear that will not happen at all then
1714 2012-01-03 21:25:59 <justmoon> sipa: why not?
1715 2012-01-03 21:26:07 <genjix> i think the script system is going to die
1716 2012-01-03 21:26:07 <sipa> there won't be any need
1717 2012-01-03 21:26:19 <genjix> why hasten the inevitable
1718 2012-01-03 21:26:27 <sipa> i hope it doesn't
1719 2012-01-03 21:26:30 <justmoon> sipa: I have no problem with having an OP_EVAL, just with having it be needed for the very basic use case of moving scripts to the scriptSig
1720 2012-01-03 21:26:33 <gavinandresen> sipa: I know of at least two mining pool operators who are excited about a better scripting system...
1721 2012-01-03 21:26:37 diki has joined
1722 2012-01-03 21:26:57 <sipa> good then
1723 2012-01-03 21:27:02 <gmaxwell> I also hope it doesn't. Script is one of the most mindblowing and exciting parts of the system.
1724 2012-01-03 21:27:07 <sipa> exactly
1725 2012-01-03 21:27:23 <sipa> (and underexplored)
1726 2012-01-03 21:27:32 <luke-jr> special-casing a specific template = fail
1727 2012-01-03 21:27:48 <justmoon> more than not die I'm hoping that one day you'll be able to use it on the p2p network
1728 2012-01-03 21:27:49 <genjix> yeah lol
1729 2012-01-03 21:27:51 <gmaxwell> In order to grow bitcoin we need a big tent, too. And scripts make our tent bigger.
1730 2012-01-03 21:27:54 <gavinandresen> Agreed, but I also agree with roconnor-- nobody fully understands it  (CODESEPARATOR has to have a use... right?  right?)
1731 2012-01-03 21:28:02 <genjix> @luke-jr
1732 2012-01-03 21:28:11 BlueMatt has quit (Ping timeout: 252 seconds)
1733 2012-01-03 21:28:22 <gmaxwell> gavinandresen: thats why I'm not currently opposed to IsStandard... dampens down the scarriest stuff.
1734 2012-01-03 21:28:54 <groffer> is the question of eliminating IsStandard off topic for this meeting?
1735 2012-01-03 21:29:08 <genjix> no way lol
1736 2012-01-03 21:29:24 <justmoon> gmaxwell: there are ways to slowly expand IsStandard, that was my main argument for static analyzability
1737 2012-01-03 21:29:26 <gavinandresen> I had a couple of other things on my agenda:  first, what to do with BIP 12.  Outdate/rewrite, or update?
1738 2012-01-03 21:29:54 <luke-jr> gavinandresen: BIP 12 is fine IMO
1739 2012-01-03 21:29:54 <genjix> might be good for hisotorical purposes to keep it around
1740 2012-01-03 21:30:00 <sipa> if we eliminate it, the only reasonable way is in steps... first incresasing number of scripts, maybe later have a list of safe instructions that are always permitted, then ...
1741 2012-01-03 21:30:01 <genjix> but reject it
1742 2012-01-03 21:30:18 <sipa> i'd just add a new BIP
1743 2012-01-03 21:30:23 <genjix> sipa: how about a new script system that is phased in somehow
1744 2012-01-03 21:30:28 <gavinandresen> Rejecting and adding a new BIP sounds good to me, I can write it up.
1745 2012-01-03 21:30:37 <sipa> it's a different proposal altogether
1746 2012-01-03 21:30:40 <genjix> yep thats the way
1747 2012-01-03 21:30:47 <luke-jr> I gtg
1748 2012-01-03 21:30:49 <genjix> keep the old one for history
1749 2012-01-03 21:31:04 <luke-jr> hopefully there won't be a final decision made today - or at least not one that sucks
1750 2012-01-03 21:31:06 <luke-jr> bbl
1751 2012-01-03 21:31:53 <groffer> sipa: IsStandard is not applied to the blockchain itself
1752 2012-01-03 21:31:59 <groffer> it creates a false sense of security
1753 2012-01-03 21:32:02 <gavinandresen> Second, I think we should think about rules for counting CHECKMULTISIG sigOps when the CHECKMULTISIG is 'hidden' inside the scriptSig
1754 2012-01-03 21:32:22 <gmaxwell> groffer: It makes any 'attack' involving funky txn costly.
1755 2012-01-03 21:32:45 BlueMatt has joined
1756 2012-01-03 21:32:49 <gmaxwell> groffer: in practice it's effective. I don't think anyone here thinks isstandard protects us from outright vulnerabilties.
1757 2012-01-03 21:32:59 chrisb__ has joined
1758 2012-01-03 21:33:05 <groffer> gmaxwell: just pass the !IsStandard txns to eligius - they will mine it
1759 2012-01-03 21:33:06 <gmaxwell> groffer: rather it lets us discover "opps, add really subtracts, lets fix that because it's unused"
1760 2012-01-03 21:33:16 <MC1984> so this is where the real action is
1761 2012-01-03 21:33:29 <gmaxwell> groffer: no, not really. They'll mine some of them, sometimes, maybe.
1762 2012-01-03 21:33:35 <justmoon> gavinandresen: I liked your proposal from the other day, count OP_1 - OP_16 followed by OP_CHECKMULTISIG as such and a lone OP_CHECKMULTISIG as 20
1763 2012-01-03 21:34:17 <gavinandresen> justmoon: great, I'll make that part of the BIP  (and will have to write that code...)
1764 2012-01-03 21:34:23 <sipa> justmoon: is that backward compatible?
1765 2012-01-03 21:34:36 <sipa> it makes things that were illegal legal
1766 2012-01-03 21:34:39 <justmoon> sipa: yes, as long as it applies only to the script literal
1767 2012-01-03 21:34:48 <sipa> in that case, agree
1768 2012-01-03 21:35:10 <gavinandresen> Yes, and it will have to be enforced only after the "full validation switchover" date.
1769 2012-01-03 21:35:24 <gavinandresen> Which was my other agenda item:  how much to slip the rollout?
1770 2012-01-03 21:35:26 nhodges has joined
1771 2012-01-03 21:35:40 <CIA-100> bips: genjix master * r7c1296b / bip-0012.md : BIP0012: Accepted -> Withdrawn. To be replaced by new proposal. - http://git.io/Zym2Pw https://github.com/genjix/bips/commit/7c1296b7b62b5a9c09668e1fd66817596d91e6d3
1772 2012-01-03 21:35:47 <justmoon> gavinandresen: don't slip it at all, live dangerously!
1773 2012-01-03 21:35:49 <justmoon> I kid I kid
1774 2012-01-03 21:35:54 <gavinandresen> I'm proposing two weeks, so we look at the blockchain on Feb 1 for miner support, and, assuming 50+% support, rollout Feb 15
1775 2012-01-03 21:36:01 <genjix> sounds good
1776 2012-01-03 21:36:06 <sipa> what % do we require?
1777 2012-01-03 21:36:10 <sipa> 60%, 70% ?
1778 2012-01-03 21:36:30 <genjix> 50.01% :)
1779 2012-01-03 21:36:33 <gavinandresen> Good question.  Eleven is my favorite number.... so 61% ?
1780 2012-01-03 21:36:40 <justmoon> the bitcoin paper says 51% will do the job pretty quickly, doesn't it?
1781 2012-01-03 21:36:45 <genjix> haha
1782 2012-01-03 21:36:47 <gavinandresen> Oooh, yeah, 50.11%
1783 2012-01-03 21:36:55 <genjix> XD
1784 2012-01-03 21:37:02 <sipa> not too close to 50%...
1785 2012-01-03 21:37:06 <justmoon> gavinandresen: I really thought your favorite number would be 12 now
1786 2012-01-03 21:37:16 baz has joined
1787 2012-01-03 21:37:16 <gavinandresen> blasphemy
1788 2012-01-03 21:37:38 <justmoon> but that question was serious - do we care about 51% vs 70%?
1789 2012-01-03 21:37:43 <roconnor> I propose two months; also how specifically are you going to measure support and what will your sampling error be?
1790 2012-01-03 21:37:53 <justmoon> I guess the measurement isn't perfectly accurate
1791 2012-01-03 21:38:20 <genjix> roconnor: ask miners to put a string in their coinbase as a vote
1792 2012-01-03 21:38:27 <gavinandresen> roconnor: I'll be asking the miners to put a string in their coinbase transactions
1793 2012-01-03 21:38:45 <justmoon> I agree with roconnor as a developer but would like to distance myself from his position for political reasons (i.e. not being lynched)
1794 2012-01-03 21:38:53 <gavinandresen> roconnor: ... and I've got a tool that tells me how many of the previous N blocks had a given string.
1795 2012-01-03 21:38:58 <justmoon> two weeks sounds ok to me
1796 2012-01-03 21:39:08 <roconnor> gavinandresen: and the N you plan to use is?
1797 2012-01-03 21:39:36 <gavinandresen> roconnor: about 24 hours.  But I'll take a look at 24, 48, and maybe more, just to see variance
1798 2012-01-03 21:39:37 <genjix> lets say 80% confidence
1799 2012-01-03 21:39:52 <genjix> so i guess 1.5 sigma?
1800 2012-01-03 21:40:15 <gmaxwell> genjix: it should be something like x% confidence on y% with y picked so that we don't reduce 6 confirms to less than 5 confirms security.
1801 2012-01-03 21:40:19 <sipa> ;;bc,help
1802 2012-01-03 21:40:19 <gribble> Alias bc,24hprc, Alias bc,altprofit, Alias bc,avgprc, Alias bc,bcm, Alias bc,bitpenny, Alias bc,blockdiff, Alias bc,blocks, Alias bc,bounty, Alias bc,btceur, Alias bc,btcgbp, Alias bc,btcguild, Alias bc,btcrub, Alias bc,btcto, Alias bc,calc, Alias bc,calcd, Alias bc,channels, Alias bc,convert, Alias bc,deepbit, Alias bc,diff, Alias bc,diffchange, Alias bc,eligius, Alias bc,estimate, Alias (2 more messages)
1803 2012-01-03 21:40:23 <MC1984> this al sounds so hacky teehee
1804 2012-01-03 21:40:32 <sipa> ;;bc,diffchange
1805 2012-01-03 21:40:34 <gribble> Estimated percent change in difficulty this period | 4.69534022467 % based on data since last change | 8.01215569553 % based on data for last three days
1806 2012-01-03 21:40:34 <genjix> yeah maybe hypothesis testing is better here
1807 2012-01-03 21:40:39 <gmaxwell> MC1984: thats because almost any criteria is acceptable.
1808 2012-01-03 21:40:41 <sipa> ;;bc,stats
1809 2012-01-03 21:40:43 <gribble> Current Blocks: 160487 | Current Difficulty: 1159929.4972244 | Next Difficulty At Block: 161279 | Next Difficulty In: 792 blocks | Next Difficulty In About: 5 days, 7 hours, 9 minutes, and 36 seconds | Next Difficulty Estimate: 1214392.13348545 | Estimated Percent Change: 4.69534022467
1810 2012-01-03 21:40:54 jon_corzine has joined
1811 2012-01-03 21:40:56 <gavinandresen> Can we assign one of you to figure out what x and y aught to be?
1812 2012-01-03 21:41:05 larg78 has joined
1813 2012-01-03 21:41:17 <genjix> sure we can do that
1814 2012-01-03 21:41:26 <sipa> gavinandresen: what about using an entire 2016-wide list of blocks
1815 2012-01-03 21:41:33 <genjix> however it comes down to what amount of blocks come from which sources
1816 2012-01-03 21:41:41 <genjix> i'm guessing mining pools are the majority of blocks
1817 2012-01-03 21:41:46 <genjix> so it doesnt matter too much.
1818 2012-01-03 21:41:48 <sipa> let's say from the 3rd to the 4th difficulty change from now
1819 2012-01-03 21:42:14 <genjix> so the variance isnt going to be huge in sampling rates
1820 2012-01-03 21:42:30 <genjix> because we have a large sample for a small population
1821 2012-01-03 21:42:48 <LightRider> I'm getting a large number of log files in bitcoin/database is that normal?
1822 2012-01-03 21:43:19 <gavinandresen> LightRider: yes, they'll get cleaned up if you restart
1823 2012-01-03 21:43:22 <BlueMatt> LightRider: yes, patches welcome
1824 2012-01-03 21:43:34 <LightRider> ok thanks
1825 2012-01-03 21:43:47 <gmaxwell> sipa: one option is to use a criteria similar to one we might use if we were making this automatic.
1826 2012-01-03 21:43:54 <genjix> BlueMatt: you want the log files kept. they are from WAL
1827 2012-01-03 21:44:26 <BlueMatt> genjix: yea, but you want to limit the log files after stuff has been committed (takes too much disk during initial download)
1828 2012-01-03 21:45:54 <genjix> if the new standard is documented then thats good
1829 2012-01-03 21:46:00 <genjix> and the documentation is the code
1830 2012-01-03 21:47:01 <genjix> reading the code helped me understand bitcoin, not forum or wiki posts because they can be ambiguous or unclear
1831 2012-01-03 21:47:10 <ByteCoin> I'd like to point out an apparent inconsistency in the decisionmaking over the functionality enabled by OP_EVAL. Casascius' original proposal changed the way in which OP_CHECKSIG worked in a roughly analogous fashion to what Gavin is suggesting now. The proposal was rejected in favour of OP_EVAL at the time which was seen to be "cleaner".
1832 2012-01-03 21:47:55 <sipa> yes, the current proposal is ugly, no doubt about it
1833 2012-01-03 21:48:02 <sipa> the magic hash, i mean
1834 2012-01-03 21:48:15 <genjix> yeah well whoever writes the BIP or code, gets to set the standard
1835 2012-01-03 21:48:31 <ByteCoin> So why is the current "magic hash" proposal in danger of being adopted while Casascius' was rejected?
1836 2012-01-03 21:48:35 <gmaxwell> This is still a general mechensism for pay to script if less general than OP_EVAL.
1837 2012-01-03 21:48:40 <justmoon> it's ugly because of being backwards compatible - arguably the txout should have contained a hash of the script to begin with
1838 2012-01-03 21:49:10 <justmoon> and then instead of scriptPubKey we would have right now a nHashType and scriptPubKeyHash
1839 2012-01-03 21:49:15 <gmaxwell> where IIRC Casascius' was not pay to script.. it was pay to a hashes of address sets which is _far_ less general.
1840 2012-01-03 21:49:17 * BlueMatt takes this opportunity to point out that with an OP_NOP1, it becomes 100% less ugly
1841 2012-01-03 21:49:18 <justmoon> which is what the new proposal is
1842 2012-01-03 21:49:23 <genjix> imagine in the future if the input eval-script was a new custom script system in bitcoin
1843 2012-01-03 21:49:58 <gmaxwell> justmoon: right, I think we should have always been pure pay to script(-hash).
1844 2012-01-03 21:50:11 <ByteCoin> I agree too.
1845 2012-01-03 21:50:41 <justmoon> so that's how i see this proposal - maybe future documentations won't even think of the scriptPubKey as a script anymore
1846 2012-01-03 21:50:51 <genjix> yeah i mean all that junk with hash type would not be needed
1847 2012-01-03 21:50:54 <justmoon> as such I don't think it's "ugly" just cause it's "magic"
1848 2012-01-03 21:51:08 <justmoon> anyway
1849 2012-01-03 21:51:21 <gmaxwell> (and I think a year or so for now I may find myself calling for miners to stop mining any new pay-to-address outputs, depending how addoption goes)
1850 2012-01-03 21:51:24 <genjix> the bitcoin standard is on its path to becoming complicated and obtuse
1851 2012-01-03 21:51:37 <genjix> gogogo
1852 2012-01-03 21:51:42 <gmaxwell> genjix: as are all production systems. There are worse fates. :)
1853 2012-01-03 21:52:01 <genjix> it's inevitable
1854 2012-01-03 21:52:32 <sipa> there is a certain truth there
1855 2012-01-03 21:52:46 <sipa> we do not lose anything by adooting the current proposal for basically everything
1856 2012-01-03 21:52:56 <sipa> except 23 bytes
1857 2012-01-03 21:53:13 <genjix> well it's good *right now*
1858 2012-01-03 21:53:27 <justmoon> sipa: how do we lose 23 bytes?
1859 2012-01-03 21:53:29 <genjix> but 100 small paper-cuts
1860 2012-01-03 21:53:44 <gmaxwell> justmoon: it's like losing 10 pounds.
1861 2012-01-03 21:53:51 <sipa> justmoon: that is assuming you just put the script in scriptSig, and use the magic hash script in the scriptPubKey
1862 2012-01-03 21:54:09 <sipa> you can do optimizations of course, as you don't need the address anymore, but can do a pay-to-pubkey directly
1863 2012-01-03 21:54:42 <roconnor> how many bytes fit in a typical QR-code or whatever 2-D bar code is popular?
1864 2012-01-03 21:54:43 <gavinandresen> Speaking of old, crufty stuff we'd like to get rid of... anybody want to start an informational BIP to keep track of changes we want to make if/when a 'hard' blockchain split is scheduled?
1865 2012-01-03 21:54:51 <justmoon> roconnor: depends on the size
1866 2012-01-03 21:54:59 <genjix> gavinandresen: maybe an informal list is better
1867 2012-01-03 21:55:05 <genjix> then when it comes we make a proper BIP
1868 2012-01-03 21:55:09 <roconnor> justmoon: naturally
1869 2012-01-03 21:55:11 <justmoon> roconnor: the absolute max is like 4k or so, but those guys are HUGE
1870 2012-01-03 21:55:12 <genjix> what do you think?
1871 2012-01-03 21:55:29 <justmoon> or even more if you lower the error correction level
1872 2012-01-03 21:55:36 <justmoon> (don't quote me, speaking from memory)
1873 2012-01-03 21:55:56 <justmoon> http://www.denso-wave.com/qrcode/vertable4-e.html
1874 2012-01-03 21:56:03 <justmoon> there you can see the tables for the largest ones
1875 2012-01-03 21:56:04 <gavinandresen> genjix: ok.  I just fear that if it is a wiki page we'll be constantly removing "I want my bitcoin client to clean my room for me" -type features
1876 2012-01-03 21:56:11 <justmoon> 23k is absolute max
1877 2012-01-03 21:56:36 <genjix> ok lets see what happens. if it gets bad, ill lock the page
1878 2012-01-03 21:56:50 <sipa> justmoon: 23k in a QR code? no way
1879 2012-01-03 21:56:56 <roconnor> what I don't quite get is why, if people want send-to-script, don't people just send to script?
1880 2012-01-03 21:57:04 <justmoon> sipa: that's bits, but yes
1881 2012-01-03 21:57:21 <Eliel> could the proposal also include support for only having the hash in txout, no opcodes at all? To be enabled once significant majority of users have migrated.
1882 2012-01-03 21:57:23 <genjix> https://en.bitcoin.it/wiki/Hardfork_Wishlist
1883 2012-01-03 21:57:51 <genjix> Eliel: not backwards compatible
1884 2012-01-03 21:57:54 <gmaxwell> ByteCoin: where is your post on flipping the chanin direction to instead approve trees of open txn?
1885 2012-01-03 21:58:12 <Eliel> genjix: hence, won't be enabled until significant majority of users are compatible.
1886 2012-01-03 21:58:23 <genjix> ok thats a hard change
1887 2012-01-03 21:58:27 <jim618> justmoon: Andreas Schildbach did some work on having tx as QR codes - said he started having scanning problems above about 1KB
1888 2012-01-03 21:58:31 <nanotube> <roconnor> I propose two months... <- i would agree that more time rather than less time is better. we don't lose anything by leaving more time for eyes to look at things and point out the stupid stuff.
1889 2012-01-03 21:58:36 <ByteCoin> gmaxwell: On the forum probably titled "Most of the block chain can be forgotten"
1890 2012-01-03 21:58:46 <justmoon> jim618: yeah, doesn't surprise me
1891 2012-01-03 21:58:46 <BlueMatt> gavinandresen: about 1 in 10 times when compiled with DEBUG_LOCKORDER you get a boost::interprocess::lock_exception on exit (last log line is DBFlush(true), so I dont think it matters, just thought Id tell you)
1892 2012-01-03 21:59:02 <sipa> nanotube: the question is whether we will look at it for longer, if it is two months instead of two weeks
1893 2012-01-03 21:59:12 <justmoon> jim618: you need like a Canan 7D or something to scan one of those big ones :D
1894 2012-01-03 21:59:21 <genjix> ok so lets call the meeting "officially" finished in case people wanna leave :p
1895 2012-01-03 21:59:22 <justmoon> Canon*
1896 2012-01-03 21:59:40 <BlueMatt> genjix: did we get anything done?
1897 2012-01-03 21:59:41 <roconnor> sipa: 2 months worked for debugging OP_EVAL ;)
1898 2012-01-03 21:59:50 <justmoon> yeah, let's recap decisions made
1899 2012-01-03 21:59:52 <ByteCoin> gmaxwell: Alternatively it might be titled "Balance sheets"
1900 2012-01-03 21:59:54 <nanotube> sipa: yes, and i was basically voting for 2 months, rather than 2 weeks. :)
1901 2012-01-03 21:59:57 <justmoon> (if any)
1902 2012-01-03 22:00:02 jon_corzine has quit (Quit: Page closed)
1903 2012-01-03 22:00:09 <genjix> justmoon: ill put something on bitcoinmedia.com
1904 2012-01-03 22:00:17 <justmoon> put it here
1905 2012-01-03 22:00:23 <sipa> i argue we had only a week of seriously inspecting op_eval
1906 2012-01-03 22:00:25 <genjix> well ill do a proper writeup
1907 2012-01-03 22:00:28 <justmoon> so that we can see if people actually agree on what we "decided"
1908 2012-01-03 22:00:29 <sipa> s/had/used/
1909 2012-01-03 22:00:53 booo has joined
1910 2012-01-03 22:01:40 <genjix> https://en.bitcoin.it/wiki//3_Jan_2011
1911 2012-01-03 22:01:42 <genjix> logs
1912 2012-01-03 22:02:15 <genjix> not sure how to make it line break
1913 2012-01-03 22:02:27 <nanotube> p(something would be found in 2 months that would have caused damage to bitcoin net) * (cost of said damage) > p($bad thing if we delay for 2 extra months)*(cost of $badthing to the bitcoin ecosystem)
1914 2012-01-03 22:02:41 <justmoon> genjix: it fits on the screen, get a 30"
1915 2012-01-03 22:02:42 <nanotube> iow, i don't think we /lose/ anything by waiting a little more
1916 2012-01-03 22:02:43 <BlueMatt> why does /me have the feeling genjix is using this meeting partially as an excuse to pimp bitcoinmedia.com?
1917 2012-01-03 22:02:44 <justmoon> :P
1918 2012-01-03 22:02:45 <nanotube> and shaking out the bugs
1919 2012-01-03 22:02:49 <genjix> nanotube: laptop
1920 2012-01-03 22:02:56 <genjix> justmoon: laptop
1921 2012-01-03 22:03:02 <justmoon> ^^
1922 2012-01-03 22:03:38 <genjix> BlueMatt: because you're young and immature
1923 2012-01-03 22:03:58 <genjix> no offense but it shows
1924 2012-01-03 22:04:04 datagutt has quit (Quit: Computer has gone to sleep.)
1925 2012-01-03 22:04:15 <BlueMatt> ouch
1926 2012-01-03 22:04:23 <gavinandresen> Waiting makes fixing bugs harder... it is much better to write code on Monday, have somebody bang on it on Tuesday and fix the bugs on Wednesday rather than have a week or month inb between
1927 2012-01-03 22:04:42 <genjix> yeah release early/often
1928 2012-01-03 22:04:44 <ByteCoin> genjix: You missed out the ;) from your last
1929 2012-01-03 22:04:49 <BlueMatt> way to not answer a question, though since I dont really care, Ill leave it at that
1930 2012-01-03 22:05:15 <gavinandresen> And have a process to fix the small mistakes, but avoid the really big mistakes....
1931 2012-01-03 22:05:35 <sipa> BlueMatt: can you let jenkin retry building netbase?
1932 2012-01-03 22:05:44 <genjix> well if its done carefully then it should be easy to see the problems and respond quickly
1933 2012-01-03 22:05:45 <roconnor> gavinandresen: thank you for withdrawing BIP 0012.
1934 2012-01-03 22:05:46 <nanotube> gavinandresen: not saying don't write code - but rather, don't push it out to a client release
1935 2012-01-03 22:06:02 <BlueMatt> sipa: internet is kinda a pain...didnt I give you an account on there at one point?
1936 2012-01-03 22:06:09 <sipa> hmm, may be
1937 2012-01-03 22:06:10 <BlueMatt> sipa: or ask gavin to log in and run bitcoin-testing-build
1938 2012-01-03 22:06:13 <sipa> let me check myself, first
1939 2012-01-03 22:06:26 <nanotube> BlueMatt: btw, due to popular demand, i filtered gribble's rss to only show new pullreqs and new issues.
1940 2012-01-03 22:06:52 <BlueMatt> nanotube: sounds good
1941 2012-01-03 22:07:00 <gavinandresen> nanotube: user-visible changes won't happen for a couple of months, the plan is still: rollout to miners, release a client that relays the new transactions, then when enough clients are relaying start on the higher-level stuff
1942 2012-01-03 22:07:01 <justmoon> nanotube: thanks!
1943 2012-01-03 22:07:11 merde has quit (Remote host closed the connection)
1944 2012-01-03 22:07:26 merde has joined
1945 2012-01-03 22:07:41 <gavinandresen> nanotube: I don't want user's first experience with multisignature transactions to be "it took 24 hours to get the first confirmation!"
1946 2012-01-03 22:07:55 <gmaxwell> gavinandresen: HELLO. I added requests for room cleaning and dessert topping to the page for you! https://en.bitcoin.it/wiki/Hardfork_Wishlist
1947 2012-01-03 22:08:12 <gavinandresen> gmaxwell: mmmm, dessert.....
1948 2012-01-03 22:08:20 <genjix> my pony remains
1949 2012-01-03 22:08:28 <gmaxwell> gavinandresen: multisig txn should probably be CLI only at first, selecting for the kind of users who need to support first.
1950 2012-01-03 22:08:34 <gmaxwell> genjix: who doesn't want a pony?
1951 2012-01-03 22:08:43 <gavinandresen> gmaxwell: yup
1952 2012-01-03 22:09:21 <gavinandresen> Anybody have a bette name than PayToScriptHash, by the way?
1953 2012-01-03 22:09:25 <Backburn2> i had something come up and missed op_eval discussion :(
1954 2012-01-03 22:09:34 <Backburn2> whats the consensus?
1955 2012-01-03 22:09:46 <nanotube> gavinandresen: i suppose i really meant, wait on the relay code for 2m. because once everyone is relaying, avenue for possible attacks is open.
1956 2012-01-03 22:09:51 <gmaxwell> gavinandresen: VelocityPay™
1957 2012-01-03 22:09:59 <nanotube> not writing the code, but putting it into a client release
1958 2012-01-03 22:10:08 <genjix> gmaxwell: how do you like the idea of a crossover block?
1959 2012-01-03 22:10:23 <genjix> which contains the state of the network from point X
1960 2012-01-03 22:10:47 <gmaxwell> gavinandresen: how about we merge keepnode (or something with the same functionality) and we just tell people nodes they can keepnode if they want to use this stuff during the introduction?
1961 2012-01-03 22:10:51 <genjix> a snapshot block
1962 2012-01-03 22:11:14 <gmaxwell> genjix: you can carry that to its logical conclusion and _always_ carry a committment to the state.
1963 2012-01-03 22:11:29 <sipa> genjix: would a snapshot block be different than a pruned block chain at that point?
1964 2012-01-03 22:11:38 <genjix> nope
1965 2012-01-03 22:11:41 <justmoon> Backburn2: https://en.bitcoin.it/wiki//3_Jan_2011
1966 2012-01-03 22:11:49 <genjix> but it would be for the hardfork wishlist
1967 2012-01-03 22:11:51 <justmoon> Backburn2: genjix will write a nice summary
1968 2012-01-03 22:12:09 <genjix> essentially a reset of the blockchain with continuity
1969 2012-01-03 22:12:16 <gavinandresen> gmaxwell: I'd rather they used the testnet, it already relays/mines all of this stuff
1970 2012-01-03 22:12:36 <gavinandresen> (speaking of which, I need to pull my new-testnet-rules patch soon)
1971 2012-01-03 22:12:44 <gmaxwell> nanotube: Perhaps your concern is address by how slowly people deploy new nodes?
1972 2012-01-03 22:12:49 <gmaxwell> er addressed.
1973 2012-01-03 22:13:18 <nanotube> gmaxwell: perhaps :)
1974 2012-01-03 22:13:24 <sipa> genjix: well, how would it be different?
1975 2012-01-03 22:13:35 <gavinandresen> The diversity of bitcoin versions on the network fits into the "will not fail spectacularly" category
1976 2012-01-03 22:13:38 <nanotube> gmaxwell: can we split the difference and say, 5 weeks? :)
1977 2012-01-03 22:13:42 <genjix> hmm this gives me an idea actually
1978 2012-01-03 22:13:56 <genjix> there could be a new protocol command called "snapshot"
1979 2012-01-03 22:13:57 <nanotube> yea that's a comforting point
1980 2012-01-03 22:14:09 <gmaxwell> genjix: there are thing that belong on the hardfork wishlist (if anywhere) but I don't think are desirable personally. What should we do with those?
1981 2012-01-03 22:14:15 <genjix> and it's a snapshot of pre-defined blockchain states
1982 2012-01-03 22:14:18 <gmaxwell> genjix: for example the MSFT red balloons payment stuff.
1983 2012-01-03 22:14:24 <genjix> so the last checkpoint block for example
1984 2012-01-03 22:14:37 <genjix> so a new bitcoin node can hardcore the last checkpoint block
1985 2012-01-03 22:14:44 <genjix> (snapshot block)
1986 2012-01-03 22:14:49 <genjix> and then continue on from there.
1987 2012-01-03 22:14:51 <gavinandresen> gmaxwell:  that didn't require a block-chain split, did it?  I thought that could all be done on a separate network....
1988 2012-01-03 22:14:54 <sipa> oh yeah hardcore
1989 2012-01-03 22:15:25 <Backburn2> justmoon: ty for link
1990 2012-01-03 22:15:37 <gmaxwell> gavinandresen: It does, otherwise the miners can strip off all the relay node payements.  (it can be done without a split so long as you trust the miners to cooperate with it)
1991 2012-01-03 22:16:02 <sipa> anyone with a working windows build environnement here?
1992 2012-01-03 22:16:12 <gavinandresen> gmaxwell: ok, that makes sense.
1993 2012-01-03 22:16:21 <sipa> wumpus said he could build bitcoin-qt easily on windows, but i wouldn't know how to start
1994 2012-01-03 22:16:31 <sipa> environment
1995 2012-01-03 22:17:08 <gmaxwell> But I think it's a bad idea because even using ultra tiny ecc signatures it adds a lot of data... and I fear the bloat creates the problem its trying to solve (relaying is costly, so you don't relay)
1996 2012-01-03 22:17:08 CaptainDDL has quit (Ping timeout: 252 seconds)
1997 2012-01-03 22:17:35 jm9000 has quit (Ping timeout: 252 seconds)
1998 2012-01-03 22:17:38 CaptainDDL has joined
1999 2012-01-03 22:17:45 larsivi_ has joined
2000 2012-01-03 22:17:58 wizkid057 has quit (Read error: Connection reset by peer)
2001 2012-01-03 22:18:12 wizkid057 has joined
2002 2012-01-03 22:18:36 larsivi has quit (Ping timeout: 252 seconds)
2003 2012-01-03 22:20:13 <gavinandresen> gmaxwell: added Bug Fixes to Hardfork page
2004 2012-01-03 22:20:48 theorbtwo has quit (Ping timeout: 252 seconds)
2005 2012-01-03 22:21:32 roconnor has quit (Ping timeout: 268 seconds)
2006 2012-01-03 22:22:02 <sipa> gavinandresen: how about fixing the time-lapse bug together with OP_EVAL?
2007 2012-01-03 22:22:13 <sipa> well, it replacement
2008 2012-01-03 22:22:37 slush has quit (Ping timeout: 252 seconds)
2009 2012-01-03 22:22:43 ByteCoin has left ()
2010 2012-01-03 22:22:48 watson787 has joined
2011 2012-01-03 22:23:57 Turingi has quit (Read error: Connection reset by peer)
2012 2012-01-03 22:26:59 watson787 has quit (Ping timeout: 240 seconds)
2013 2012-01-03 22:27:48 slush has joined
2014 2012-01-03 22:28:05 user__ has quit (Quit: Leaving)
2015 2012-01-03 22:28:46 theorbtwo has joined
2016 2012-01-03 22:28:57 toffoo has joined
2017 2012-01-03 22:33:49 <BlueMatt> gmaxwell: wow, with your fix I can actually watch the progress bar move along on tmpfs...
2018 2012-01-03 22:34:00 jm9000 has joined
2019 2012-01-03 22:36:35 _Fireball has quit (Quit:  Want to be different? Try HydraIRC -> http://www.hydrairc.com <-)
2020 2012-01-03 22:37:12 oww has quit (Remote host closed the connection)
2021 2012-01-03 22:40:39 <justmoon> BlueMatt: do we need to update the scalability wiki page at all? ;D
2022 2012-01-03 22:41:45 <BlueMatt> justmoon: no, it used to work this way, but with encryption it slowed down
2023 2012-01-03 22:41:57 <BlueMatt> actually, no its a bit faster
2024 2012-01-03 22:42:00 <BlueMatt> but wait a month, there is another change Im benchmarking now that is looking very promising
2025 2012-01-03 22:42:20 <justmoon> good luck!
2026 2012-01-03 22:42:45 kdomanski has quit (Quit: Leaving)
2027 2012-01-03 22:46:25 <gmaxwell> The world is a weird place.
2028 2012-01-03 22:46:36 <gmaxwell> I see someone has created a client designd around holding the blockchain in ram.
2029 2012-01-03 22:47:28 <Eliel> gmaxwell: that client probably works pretty fast :D
2030 2012-01-03 22:47:29 <sipa> roconnor's?
2031 2012-01-03 22:47:52 <gmaxwell> https://bitcointalk.org/index.php?topic=56424.0
2032 2012-01-03 22:49:53 * BlueMatt 's client runs in tmpfs ie ram...
2033 2012-01-03 22:53:26 <BlueMatt> what nHeight does a node push in its version message if it has no blocks?
2034 2012-01-03 22:53:44 <BlueMatt> 0, -1 or 1?
2035 2012-01-03 22:53:44 <BlueMatt> nope, it has genesis, 1
2036 2012-01-03 22:53:46 <gmaxwell> it always has block zero, it's hard coded?
2037 2012-01-03 22:54:01 <BlueMatt> nBestHeight is inited at -1
2038 2012-01-03 22:54:05 <BlueMatt> genesis is hardcoded
2039 2012-01-03 22:54:09 <BlueMatt> is genesis 1 or 0?
2040 2012-01-03 22:54:33 jim618 has quit (Quit: jim618)
2041 2012-01-03 22:54:53 <justmoon> gmaxwell: technically it only caches it in ram - "it [...] connects to the Satoshi client via localhost"
2042 2012-01-03 22:55:14 <justmoon> the satoshi client stores it on disk, so its own version is just a cache so to speak :)
2043 2012-01-03 22:55:30 <sipa> genesis is at height 0, no?
2044 2012-01-03 22:55:34 <justmoon> sipa: yes
2045 2012-01-03 22:56:12 <gmaxwell> yea yea, but here I am worrying that it will soon be too big for many people to want to keep it on disk— and people are building clients that keep it in ram. :)
2046 2012-01-03 22:58:37 freewil has joined
2047 2012-01-03 22:58:37 freewil has quit (Changing host)
2048 2012-01-03 22:58:37 freewil has joined
2049 2012-01-03 22:59:32 rdponticelli has quit (Ping timeout: 255 seconds)
2050 2012-01-03 23:07:43 oww has joined
2051 2012-01-03 23:10:31 <gmaxwell> sipa: you should probably make your new address stuff all v6 happy. (using /32 in place of /16s, I guess, when working with v6 addresses)
2052 2012-01-03 23:11:11 <BlueMatt> gmaxwell: there has been a long discussion of how to do the equivalent of /16s in ipv6 several times...
2053 2012-01-03 23:11:19 <BlueMatt> gmaxwell: I thought you were a part of one of them?
2054 2012-01-03 23:11:22 <phantomcircuit> are we still talking about this
2055 2012-01-03 23:11:24 <gmaxwell> BlueMatt: probably!
2056 2012-01-03 23:11:35 marf_away has quit (Ping timeout: 252 seconds)
2057 2012-01-03 23:11:38 Diablo-D3 has quit (Ping timeout: 248 seconds)
2058 2012-01-03 23:12:01 <BlueMatt> gmaxwell: boils down to: addr.dat is too easy to fill by an attacker if you just do /32s
2059 2012-01-03 23:12:02 <gmaxwell> BlueMatt: I may have even said the same thing. Or not. The /16 is a really crappy approximation that I'm not super happy with.
2060 2012-01-03 23:12:09 <BlueMatt> gmaxwell: best solution: use a snapshot of bgp
2061 2012-01-03 23:12:17 <BlueMatt> afaik
2062 2012-01-03 23:12:19 <BlueMatt> afair
2063 2012-01-03 23:12:26 <gmaxwell> Yep (and _that_ would have been a suggestion I'd make)
2064 2012-01-03 23:12:34 <gmaxwell> But, it's yucky.
2065 2012-01-03 23:12:43 <BlueMatt> you likely did ;)
2066 2012-01-03 23:12:46 <phantomcircuit> anybody know how i can nuke my github branch
2067 2012-01-03 23:12:56 <BlueMatt> phantomcircuit: git push origin :branch
2068 2012-01-03 23:13:03 <phantomcircuit> yay
2069 2012-01-03 23:13:08 <phantomcircuit> <-- knows nothing about git
2070 2012-01-03 23:13:12 <gmaxwell> BlueMatt: in any case, you might have missed it earlier— sipa is working on a new attack resistant in-memory structure for addresses.
2071 2012-01-03 23:13:21 <BlueMatt> ooo
2072 2012-01-03 23:13:38 <BlueMatt> oh, well /me is a dumbass then (again)
2073 2012-01-03 23:14:05 <sipa> gmaxwell: see CNetAddr::GetGroup() in my netbase branch
2074 2012-01-03 23:14:36 <sipa> gmaxwell: should have mentioned it, it was obviously going to be extended to v6
2075 2012-01-03 23:14:54 <sipa> as the address handling is what is standing in the way of ipv6 now
2076 2012-01-03 23:15:10 rdponticelli has joined
2077 2012-01-03 23:16:41 <gmaxwell> sipa: in addition to plain v6 we should probably support OnionCat addresses. (basically you can pack a whole hidden service address in a v6 address and there is a block informatlly set aside for that).
2078 2012-01-03 23:16:59 <sipa> onioncat == tor stuff?
2079 2012-01-03 23:17:45 <phantomcircuit> yes
2080 2012-01-03 23:17:45 <BlueMatt> gmaxwell: do we have to do anything to support that?
2081 2012-01-03 23:17:56 <gmaxwell> Yes. It would allow bitcoin to run over tor without the internet working. — A useful property to address fears about 'what if fooville censors bitcoin'
2082 2012-01-03 23:18:01 <phantomcircuit> BlueMatt, no
2083 2012-01-03 23:18:27 <BlueMatt> phantomcircuit: good to hear, so in other words tor implemented it right...
2084 2012-01-03 23:18:29 <sipa> gmaxwell: how do you programmatically interact with tor?
2085 2012-01-03 23:18:40 <phantomcircuit> BlueMatt, well
2086 2012-01-03 23:18:45 <gmaxwell> Onioncat itself? no but it's horrible itself. I think we should use onioncat addresses to work with hidden services.
2087 2012-01-03 23:19:09 <sipa> wait what are you suggesting, exactly?
2088 2012-01-03 23:19:28 <luke-jr> gmaxwell: if fooville censors Bitcoin, then people in fooville should not use Bitcoin
2089 2012-01-03 23:19:31 <gmaxwell> sipa: pretty poorly, but we don't have to. The only thing we need from tor is 'create me a hidden service' and 'what is that hidden service address'  The control port can do this, but I'd probably just leave those manual for now.
2090 2012-01-03 23:20:10 <gmaxwell> sipa: Right now you can't use bitcoin over tor except to connect to bitcoin nodes on the public internet, which is lame because it depends on tor's exit capacity.
2091 2012-01-03 23:20:52 <gmaxwell> luke-jr: the fact that blocking would be ineffective will discourage fooville from even trying.
2092 2012-01-03 23:21:05 <phantomcircuit> gmaxwell, probably not
2093 2012-01-03 23:21:10 <phantomcircuit> but still worth having
2094 2012-01-03 23:21:13 <luke-jr> gmaxwell: only if fooville is full of criminals
2095 2012-01-03 23:21:22 <BlueMatt> gmaxwell: if bitcoin is setup to use a tor proxy and you -connect=onioncat, would it not work by itself?
2096 2012-01-03 23:21:35 <sipa> gmaxwell: so it would come down to a test "is this an encapsulated onion address? if so, use tor proxy" ?
2097 2012-01-03 23:21:38 <luke-jr> if fooville State says "stop using Bitcoin", it should fully expect its citizens to comply without any kind of filtering
2098 2012-01-03 23:21:38 davout_ has quit (Remote host closed the connection)
2099 2012-01-03 23:21:44 <gmaxwell> I want to be able to ./bitcoind -mytoraddress foobarbaz.onion  -proxy 127.0.0.1:9050  and then bitcoin will be able to announce foobarbaz.onion in address messages.
2100 2012-01-03 23:21:48 <gmaxwell> sipa: bingo.
2101 2012-01-03 23:21:50 <sipa> luke-jr: welcome to real life
2102 2012-01-03 23:22:10 <luke-jr> sipa: making that harder is IMO not a legitimate goal.
2103 2012-01-03 23:23:48 <gmaxwell> sipa: and if you don't have a tor proxy, don't bother with those addresses.
2104 2012-01-03 23:24:57 <BlueMatt> gmaxwell: aside from the announcement, wouldnt bitcoin function properly in if a tor proxy is specified already?
2105 2012-01-03 23:25:00 <BlueMatt> (assuming IPv6)
2106 2012-01-03 23:26:07 <gmaxwell> BlueMatt: no. All it can do now is connect to public bitcoin nodes via tor exists.   Iff you install onioncat which is this horrible seperate IP-in-TCP layer then yes it would, assuming our v6 support was complete.
2107 2012-01-03 23:26:18 <gmaxwell> But onioncat and IP-in-TCP is dumb.
2108 2012-01-03 23:26:37 <gmaxwell> If we had a DNS based address system then tor without onioncat would work fine.
2109 2012-01-03 23:26:52 <gmaxwell> But we don't we have an IP(v6) based address system.
2110 2012-01-03 23:27:06 <gmaxwell> (e.g. you could just add and rumor .onion hostnames)
2111 2012-01-03 23:27:08 <BlueMatt> gmaxwell: oh, I thought onioncat was in tor already
2112 2012-01-03 23:27:20 <gmaxwell> No, and never will be (as far as I can tell)
2113 2012-01-03 23:27:26 <BlueMatt> thats sad...
2114 2012-01-03 23:27:32 <luke-jr> indeed
2115 2012-01-03 23:27:36 <gmaxwell> it has significant anonymity problems.
2116 2012-01-03 23:27:41 <luke-jr> so?
2117 2012-01-03 23:27:44 <BlueMatt> oh
2118 2012-01-03 23:27:52 Eueie has joined
2119 2012-01-03 23:27:53 <luke-jr> I'd use Tor if I could send to some normal IPv6 address and let the nearest Tor router forward it
2120 2012-01-03 23:27:56 <gmaxwell> because it exposes your easily fingerprintable IP stack to remote parties.
2121 2012-01-03 23:28:00 Eueie is now known as Uiuiuiui
2122 2012-01-03 23:28:03 <luke-jr> I don't care about anonymity nonsense
2123 2012-01-03 23:28:05 <gmaxwell> oh tor is getting IPv6 support.
2124 2012-01-03 23:28:14 chrisb__ has quit (Quit: Ex-Chat)
2125 2012-01-03 23:28:20 <luke-jr> gmaxwell: I mean that I, as a user, don't want to run Tor.
2126 2012-01-03 23:28:48 <luke-jr> gmaxwell: and if "anonymous webhost" wants to stay anonymous, it'd be nice if there was an anycast solution to bridge me to him
2127 2012-01-03 23:28:53 <phantomcircuit> gmaxwell, the major issue there being the way in which tcp responded over the ipv6 tunnel
2128 2012-01-03 23:29:02 <phantomcircuit> which is hard to disguise
2129 2012-01-03 23:29:36 <gmaxwell> phantomcircuit: right, in any case.. I don't think much of onioncat but their address packing system is super clever. So I think we should use it to allow hidden service peers to fit in our address oriented protocol.
2130 2012-01-03 23:30:01 <luke-jr> gmaxwell: does IANA recognize these onioncat addresses?
2131 2012-01-03 23:30:21 <phantomcircuit> probably not
2132 2012-01-03 23:30:39 erle- has quit (Ping timeout: 240 seconds)
2133 2012-01-03 23:31:43 <sipa> does anyone here have a windows build environment?
2134 2012-01-03 23:31:50 <BlueMatt> jenkins does
2135 2012-01-03 23:31:53 <luke-jr> do we still support building on Windows?
2136 2012-01-03 23:31:54 <BlueMatt> (and gives you binaries)
2137 2012-01-03 23:31:55 <phantomcircuit> lold
2138 2012-01-03 23:32:05 <BlueMatt> oh, actual windows, heh fuck that
2139 2012-01-03 23:32:18 <phantomcircuit> that sounds not fun
2140 2012-01-03 23:32:19 <makomk> phantomcircuit: IIRC, they're done in a way that's unlikely to conflict; one of the site-local ranges IIRC.
2141 2012-01-03 23:32:29 <luke-jr> makomk: even worse
2142 2012-01-03 23:32:30 <sipa> yes, i know mingw already works because of jenkins
2143 2012-01-03 23:33:28 <phantomcircuit> fd87:
2144 2012-01-03 23:34:26 * BlueMatt is gonna land soon, see yall later
2145 2012-01-03 23:34:55 <sipa> FD87:D87E:EB43::/48
2146 2012-01-03 23:34:59 <sipa> is the onioncat prefix
2147 2012-01-03 23:35:01 BlueMatt has quit (Read error: Connection reset by peer)
2148 2012-01-03 23:35:22 <makomk> Yep, http://en.wikipedia.org/wiki/Unique_local_address
2149 2012-01-03 23:35:30 <gmaxwell> luke-jr: IIRC they use the unique link local.
2150 2012-01-03 23:35:36 <phantomcircuit> They are not expected to be routable on the global Internet.
2151 2012-01-03 23:35:38 <luke-jr> gmaxwell: even worse
2152 2012-01-03 23:35:40 <gmaxwell> Which is perfectly safe to use for protocol specific purposes.
2153 2012-01-03 23:35:54 <sipa> my ipv6 network code already considers that address non-routable
2154 2012-01-03 23:35:58 <phantomcircuit> i think you're not supposed to
2155 2012-01-03 23:36:01 <sipa> *range
2156 2012-01-03 23:36:02 <phantomcircuit> but that it's likely to not break
2157 2012-01-03 23:36:17 <makomk> Randomly-generated prefix that should be unique to each network using them, hopefully.
2158 2012-01-03 23:36:20 <sipa> but i like the idea of directly interacting with tor
2159 2012-01-03 23:36:58 <makomk> gmaxwell: might be an idea to generate your own prefix actually.
2160 2012-01-03 23:37:03 <phantomcircuit> https://gitweb.torproject.org/torspec.git/blob_plain/HEAD:/control-spec.txt
2161 2012-01-03 23:37:38 <luke-jr> hmm
2162 2012-01-03 23:37:54 <phantomcircuit> just a thought
2163 2012-01-03 23:37:56 <luke-jr> how about having a mandatory parameter -torprefix=somesubnet ?
2164 2012-01-03 23:37:58 <phantomcircuit> tor is a fucking mess
2165 2012-01-03 23:38:06 <luke-jr> or wait, nm
2166 2012-01-03 23:38:13 <gmaxwell> luke-jr: I think you're misunderstanding the purpose here.
2167 2012-01-03 23:38:15 <gmaxwell> oh. okay.
2168 2012-01-03 23:38:17 <luke-jr> gmaxwell: just realized
2169 2012-01-03 23:38:54 <luke-jr> would it work just as well to define a format for hostnames?
2170 2012-01-03 23:39:08 <gmaxwell> The purposes here is to just have some way of signaling onion addresses inside bitcoin addresses messages.. that actual addresses used wouldn't appear outside of bitcoin, though care should be taken to not conflict with IPv6 space people will actually want to use.
2171 2012-01-03 23:39:45 * luke-jr wonders if it's possible to prepend network addresses with an octet for type
2172 2012-01-03 23:40:08 <gmaxwell> luke-jr: it would, but it would require a protocol change whereas this doesn't... and I don't really like the idea of dns names in rumored addresses in any case.
2173 2012-01-03 23:40:09 <phantomcircuit> luke-jr, actually...
2174 2012-01-03 23:40:25 <phantomcircuit> one sec
2175 2012-01-03 23:40:51 <makomk> (I was actually considering something similar a while ago.)
2176 2012-01-03 23:41:17 <phantomcircuit> addr is a list of addresses
2177 2012-01-03 23:41:31 <phantomcircuit> if the first address in the list was say 0.0.0.0
2178 2012-01-03 23:41:43 <phantomcircuit> then you could interpret the rest as onion in ipv6
2179 2012-01-03 23:41:51 <phantomcircuit> and remain compatible with current clients
2180 2012-01-03 23:41:55 <sipa> old clients would interpret the rest as garbage
2181 2012-01-03 23:42:08 <phantomcircuit> they would see ipv6 addresses
2182 2012-01-03 23:42:12 <sipa> yes
2183 2012-01-03 23:42:19 <phantomcircuit> they just drop them currently right?
2184 2012-01-03 23:42:40 <phantomcircuit> maybe not...
2185 2012-01-03 23:43:03 <sipa> but 1) bitcoin ignores unroutable addresses 2) an informal standard for encapsulating onion addresses in ipv6 already exists 3) that encapsulation causes them to end up in an otherwise unroutable address range
2186 2012-01-03 23:43:15 <sipa> so using that prefix sounds perfectly safe to me
2187 2012-01-03 23:46:39 <phantomcircuit> fair enough
2188 2012-01-03 23:46:43 eldentyrell has quit (Quit: eldentyrell)
2189 2012-01-03 23:47:01 <phantomcircuit> / Copyright (c) 2011 The Bitcoin developers
2190 2012-01-03 23:47:02 <phantomcircuit> lol
2191 2012-01-03 23:47:11 <phantomcircuit> i doubt that helps
2192 2012-01-03 23:47:45 <luke-jr> ?
2193 2012-01-03 23:48:09 <phantomcircuit> it's in the source code
2194 2012-01-03 23:48:13 <phantomcircuit> i cant imagine why
2195 2012-01-03 23:48:32 <gmaxwell> meh, under the berne convention signing states can't require any formalities in order to enjoy copyright protection... so it doesn't matter.
2196 2012-01-03 23:48:46 <phantomcircuit> lol yeah that's my point
2197 2012-01-03 23:49:11 <sipa> well we just don't want people to think that it was still all written by satoshi, i guess...
2198 2012-01-03 23:50:04 <luke-jr> phantomcircuit: it clarifies copyright
2199 2012-01-03 23:50:29 <luke-jr> if it said "Copyright Satoshi" and we contributed code without adding "Copyright Luke", it can be interpreted as copyright assignment
2200 2012-01-03 23:50:44 onelineproof has quit (Ping timeout: 244 seconds)
2201 2012-01-03 23:50:44 <luke-jr> "Copyright the Bitcoin developers" seems to be clear that each person retains copyright
2202 2012-01-03 23:51:04 freewil has quit (Quit: Leaving)
2203 2012-01-03 23:51:10 roconnor has joined
2204 2012-01-03 23:52:35 baz has quit (Ping timeout: 240 seconds)
2205 2012-01-03 23:53:19 jacobwg has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
2206 2012-01-03 23:53:38 jacobwg has joined
2207 2012-01-03 23:53:48 bobke has quit (Read error: Connection reset by peer)
2208 2012-01-03 23:54:41 bobke has joined