1 2013-01-22 00:05:46 zip__ has joined
   2 2013-01-22 00:09:20 Hashdog has quit (Remote host closed the connection)
   3 2013-01-22 00:10:22 rdymac has quit (Remote host closed the connection)
   4 2013-01-22 00:11:17 Guest47451 has quit (Excess Flood)
   5 2013-01-22 00:11:37 amiller has joined
   6 2013-01-22 00:11:48 amiller is now known as Guest84374
   7 2013-01-22 00:14:40 <midnightmagic> Luke-Jr: You might want to turn off ipv6 for connecting to freenode.
   8 2013-01-22 00:14:51 <Luke-Jr> midnightmagic: why?
   9 2013-01-22 00:15:03 <midnightmagic> Luke-Jr: You're going through tunnelbroker?
  10 2013-01-22 00:15:22 <Luke-Jr> yes
  11 2013-01-22 00:15:42 <midnightmagic> Luke-Jr: My experience here has been I achieve a far superior, more stable link if I cut them out of the connection circuit.
  12 2013-01-22 00:18:16 tcatm has quit (Quit: No Ping reply in 180 seconds.)
  13 2013-01-22 00:18:40 tcatm has joined
  14 2013-01-22 00:18:40 tcatm has quit (Changing host)
  15 2013-01-22 00:18:40 tcatm has joined
  16 2013-01-22 00:20:23 bitafterbit has quit (Read error: Connection reset by peer)
  17 2013-01-22 00:20:38 error4733 has joined
  18 2013-01-22 00:20:42 error4733 has left ()
  19 2013-01-22 00:21:00 porquilho has quit ()
  20 2013-01-22 00:25:47 tcatm has quit (Quit: No Ping reply in 180 seconds.)
  21 2013-01-22 00:26:05 tcatm has joined
  22 2013-01-22 00:26:06 tcatm has quit (Changing host)
  23 2013-01-22 00:26:06 tcatm has joined
  24 2013-01-22 00:30:09 forrestv has quit (Ping timeout: 245 seconds)
  25 2013-01-22 00:31:52 forrestv has joined
  26 2013-01-22 00:32:10 pigeons has quit (Ping timeout: 248 seconds)
  27 2013-01-22 00:33:02 pigeons has joined
  28 2013-01-22 00:33:25 pigeons is now known as Guest54821
  29 2013-01-22 00:33:52 rdponticelli has quit (Ping timeout: 276 seconds)
  30 2013-01-22 00:35:05 rdponticelli has joined
  31 2013-01-22 00:39:25 <jgarzik> gavinandresen, sipa: "when will 0.8 be released?"   https://bitcointalk.org/index.php?topic=137811.0
  32 2013-01-22 00:39:35 <jgarzik> we should identify blockers to 0.8-rc1 at least
  33 2013-01-22 00:40:08 <gavinandresen> agreed
  34 2013-01-22 00:40:42 <gavinandresen> jgarzik: I'm trying to get a handle on how stable 0.8 is on Windows; I've been messing with VMs all day
  35 2013-01-22 00:40:48 CodeShark has joined
  36 2013-01-22 00:42:58 swappermall_ has quit (Read error: Connection reset by peer)
  37 2013-01-22 00:43:49 Guest54821 is now known as pigeons
  38 2013-01-22 00:44:08 <gmaxwell> jgarzik: heh. I responded to that post in private "I don't mean to call you out but I was just checking your post history and didn't see any testing reports" and went on an invited him to test and provide feedback. :P
  39 2013-01-22 00:44:38 <jgarzik> gmaxwell: I think we've hit as much testing we'll get without a -rc
  40 2013-01-22 00:44:49 <jgarzik> and there is no law saying we cannot do six months of -rc, if need be
  41 2013-01-22 00:45:21 <gavinandresen> The only blocking issue for a 0.8rc that I'm aware of is vague "slow/uses lots of memory on windows" reports
  42 2013-01-22 00:45:59 <jgarzik> unless -everybody- is crashing on Windows, that is not really a blocker really, balanced against value of wider testing
  43 2013-01-22 00:46:20 <jgarzik> wider testing would hopefully give us a better feel for where Windows is
  44 2013-01-22 00:46:43 <gmaxwell> For an RC? no... not a blocker.
  45 2013-01-22 00:47:14 <BlueMatt> blockers for rc: #2188
  46 2013-01-22 00:47:22 <gmaxwell> jgarzik: I responded more in the spirit of continuing outreach. Everyone who is excited enough about new versions to ask ought to give a prerel build a spin from time to time.
  47 2013-01-22 00:47:59 <jgarzik> agreed
  48 2013-01-22 00:48:25 <jgarzik> BlueMatt: nah, not an -rc blocker
  49 2013-01-22 00:48:51 <jgarzik> BlueMatt: release blocker, possibly sure
  50 2013-01-22 00:48:53 <BlueMatt> jgarzik: its a change to protocol...essentially its a fixup that should have been merged in with the original bloom
  51 2013-01-22 00:49:09 <BlueMatt> jgarzik: I was hoping to get that merged quickly so I didnt have to bother with PROTOCOL_VERSION or anything....
  52 2013-01-22 00:49:09 <jgarzik> BlueMatt: a change that few will notice
  53 2013-01-22 00:49:25 <gmaxwell> BlueMatt: does that make it impossible to fetch the filtered block without the txn?
  54 2013-01-22 00:49:28 <BlueMatt> well, yes, no one will, but the idea is to make sure no nodes are out there with the same PROTOCOL_VERSION but that change
  55 2013-01-22 00:49:41 <BlueMatt> gmaxwell: it always has been
  56 2013-01-22 00:49:52 <jgarzik> BlueMatt: That won't be a problem in practice, any more than git HEAD changes have been
  57 2013-01-22 00:50:24 <BlueMatt> jgarzik: true, but my point is more that its better if the current version never appears in any "official" builds
  58 2013-01-22 00:50:26 <BlueMatt> anyway, whatever
  59 2013-01-22 00:50:27 <gmaxwell> hm. I don't know that thats wise. :-/ but I guess it can be revisited later.
  60 2013-01-22 00:51:03 <jgarzik> BlueMatt: sipa's been doing pre-0.8 builds and encouraging their use, so that horse has left the barn already
  61 2013-01-22 00:51:05 <BlueMatt> gmaxwell: well, you cant ask for them individually...
  62 2013-01-22 00:51:05 <gavinandresen> I already ACK'ed pull 2188.....
  63 2013-01-22 00:51:05 <gmaxwell> (e.g. if you're using filtered blocks to follow the chain you'll likely have many of the txn in the block already if you've been fetching rumored txn)
  64 2013-01-22 00:51:14 <jgarzik> RFT's posted in reddit for pre-0.8 builds, even
  65 2013-01-22 00:51:20 <BlueMatt> jgarzik: true, but...anyway, its such a small pull, debating whether its a blocker or not......
  66 2013-01-22 00:51:24 <gmaxwell> BlueMatt: hm. point.
  67 2013-01-22 00:51:57 <BlueMatt> gmaxwell: yep, and if it is in setInvKnown then those txn wont be forwarded, so (in theory) you should skip most of those automagically
  68 2013-01-22 00:52:26 <zip__> thanks for all the hard work on the btc client guys.. it looks great (linux version)....THANKS!
  69 2013-01-22 00:52:29 <BlueMatt> but, yes, it remains to be seen if it becomes a problem
  70 2013-01-22 00:52:30 <gmaxwell> Yea, though invknown is only the transactions that you forwarded on yourself.
  71 2013-01-22 00:52:39 <BlueMatt> yep
  72 2013-01-22 00:52:48 rich__ has joined
  73 2013-01-22 00:52:57 root2 has quit (Read error: Connection reset by peer)
  74 2013-01-22 00:53:08 <gmaxwell> BlueMatt: yea, if its an issue we can always just add a merkleblocksparser request.
  75 2013-01-22 00:53:17 root2 has joined
  76 2013-01-22 00:53:24 <gmaxwell> along with getdatas to fill in results.
  77 2013-01-22 00:54:38 <BlueMatt> yea, though the getdata would need work (you cant request in-block txn atm)
  78 2013-01-22 00:56:52 <gmaxwell> yea, thus the 'along with getdatas'...  we'd need a getblockdata that takes a block index or hash along with the txnid.
  79 2013-01-22 00:57:12 <BlueMatt> yes, ok
  80 2013-01-22 00:57:43 <gmaxwell> Eventually we'll want to change to doing sparse blocks for relaying in any case, which will need a getdata like that.
  81 2013-01-22 00:58:02 <BlueMatt> sparse blocks?
  82 2013-01-22 00:59:00 <gmaxwell> header + tree. Then you getdata whatever you're missing. Taking advantage of the fact that for newly created blocks almost all txn have already been relayed.
  83 2013-01-22 00:59:17 <BlueMatt> ahh, yes ok
  84 2013-01-22 00:59:34 <BlueMatt> well, you could do that with a dumb bloom filter hack
  85 2013-01-22 00:59:49 <BlueMatt> it'd be kinda evil for the remote node (which now has to calculate lots of hashes for no reason), but....
  86 2013-01-22 01:00:19 <gmaxwell> Yea, well, match everything. But the implicit txn push currently breaks that.
  87 2013-01-22 01:00:40 FredEE has joined
  88 2013-01-22 01:00:55 <BlueMatt> hmmm...maybe there should be some code to skip the hashing/matching if you have a filter that is one byte and all 1s to allow for that (if not entirely the way you say, but still a similar result)
  89 2013-01-22 01:01:14 <gmaxwell> BlueMatt: once the bloom filter code is mature there should probably be a minor anti-dos rule that disables filtering on the server if the hitrate goes too high.. thats why I was asking things like "is the server forbidden from sending too much"
  90 2013-01-22 01:01:17 copumpkin has quit (Ping timeout: 248 seconds)
  91 2013-01-22 01:01:58 copumpkin has joined
  92 2013-01-22 01:02:48 <BlueMatt> maybe, yes. or dont bother calling it a dos, just short-circuit the actual hashing work and assume everything matches and forward it all
  93 2013-01-22 01:04:00 <gmaxwell> ::nods::
  94 2013-01-22 01:09:35 <CodeShark> so basically turn off the filter once the hit rate reaches a certain level
  95 2013-01-22 01:10:23 <gmaxwell> Yea, not worth it for the server to do all that extra computation when it's just going to send you 95% of the block anyways.
  96 2013-01-22 01:11:15 <CodeShark> but the hit rate cannot be assessed instantly - you still need to process a few transactions to evaluate it
  97 2013-01-22 01:11:57 <gmaxwell> The all 1s filter has a known hitrate. :P
  98 2013-01-22 01:12:12 <CodeShark> lol
  99 2013-01-22 01:12:41 <CodeShark> so as soon as the filter has more than a certain number of 1s, turn it off?
 100 2013-01-22 01:13:11 <gmaxwell> Maybe. Don't need to solve this right now.
 101 2013-01-22 01:13:25 FredEE has quit (Quit: FredEE)
 102 2013-01-22 01:13:46 zooko has joined
 103 2013-01-22 01:14:44 <CodeShark> well, assuming a uniform distribution that would work
 104 2013-01-22 01:24:37 igetgames has quit (Read error: Connection reset by peer)
 105 2013-01-22 01:25:02 igetgames has joined
 106 2013-01-22 01:30:06 legitnick1 has joined
 107 2013-01-22 01:33:03 error4733 has joined
 108 2013-01-22 01:33:17 Prattler has joined
 109 2013-01-22 01:34:36 error4733 has quit (Client Quit)
 110 2013-01-22 01:34:50 error4733 has joined
 111 2013-01-22 01:35:54 error4733 has left ()
 112 2013-01-22 01:37:34 rdponticelli has quit (Ping timeout: 276 seconds)
 113 2013-01-22 01:38:52 PhantomSpark has quit (Ping timeout: 276 seconds)
 114 2013-01-22 01:42:51 Guest84374 has quit (Excess Flood)
 115 2013-01-22 01:44:43 <zip__> Is it possible with new versions of the client to create a password to open up the btc client? Just curious...
 116 2013-01-22 01:45:08 Guest42214 has joined
 117 2013-01-22 01:45:28 <gmaxwell> zip__: to open? no.  To spend? yes.
 118 2013-01-22 01:45:38 rdponticelli has joined
 119 2013-01-22 01:45:59 <zip__> thanks gmaxwell
 120 2013-01-22 01:46:08 <gmaxwell> If you want a to-open password you ought to be using disk encryption... We opted for the narrower protection because thats something that disk encryption couldn't do.
 121 2013-01-22 01:46:28 <gmaxwell> (and it means the key can stay out of memory almost all the time)
 122 2013-01-22 01:46:31 <zip__> i use truecrypt... just like the idea.
 123 2013-01-22 01:47:06 t7 has quit (Quit: Konversation terminated!)
 124 2013-01-22 01:47:22 <zip__> really appreciate all that you do [developers]
 125 2013-01-22 01:51:40 JWU42_ has joined
 126 2013-01-22 01:51:52 JWU42 has quit (Ping timeout: 276 seconds)
 127 2013-01-22 01:52:51 mpv has quit (Remote host closed the connection)
 128 2013-01-22 01:55:18 JZavala has joined
 129 2013-01-22 02:01:00 subpar__ has joined
 130 2013-01-22 02:01:06 subpar__ is now known as JWU42
 131 2013-01-22 02:01:22 JWU42 has quit (Changing host)
 132 2013-01-22 02:01:22 JWU42 has joined
 133 2013-01-22 02:03:34 sacredchao has quit (Ping timeout: 276 seconds)
 134 2013-01-22 02:04:13 JWU42_ has quit (Ping timeout: 276 seconds)
 135 2013-01-22 02:05:02 sacredchao has joined
 136 2013-01-22 02:05:48 <CodeShark> I'm working on a configure script for bitcoind that checks for dependencies and gives the user detailed info on how to install any missing dependencies. I want it to work in OS X and all the most popular linux distros. I'd appreciate any comments, suggestions, and willingness to test it out. https://github.com/CodeShark/bitcoin/blob/configure_script/src/configure
 137 2013-01-22 02:09:48 igetgames has quit (Read error: Connection reset by peer)
 138 2013-01-22 02:10:11 igetgames has joined
 139 2013-01-22 02:12:41 tcatm has quit (Remote host closed the connection)
 140 2013-01-22 02:13:06 MC-Eeepc has joined
 141 2013-01-22 02:15:09 tcatm has joined
 142 2013-01-22 02:15:09 tcatm has quit (Changing host)
 143 2013-01-22 02:15:09 tcatm has joined
 144 2013-01-22 02:21:05 corbs132 has quit (Quit: corbs132)
 145 2013-01-22 02:22:25 rdponticelli has quit (Ping timeout: 276 seconds)
 146 2013-01-22 02:23:09 RBecker is now known as chris___
 147 2013-01-22 02:23:15 chris___ is now known as RBecker
 148 2013-01-22 02:24:54 Prattler has quit (Quit: ZNC - http://znc.in)
 149 2013-01-22 02:26:44 <swappermall> CodeShark: I can test Ubuntu Precise setups
 150 2013-01-22 02:26:57 <CodeShark> please, by all means be my guest :)
 151 2013-01-22 02:27:11 <CodeShark> jsut about to push a new version...
 152 2013-01-22 02:27:35 <swappermall> ok, just let me know when it's been pushed
 153 2013-01-22 02:28:01 <legitnick1> time to fuzz?
 154 2013-01-22 02:28:09 <CodeShark> pushed
 155 2013-01-22 02:29:13 <swappermall> ok
 156 2013-01-22 02:29:33 <CodeShark> still needs a lot of work but that's the basic framework
 157 2013-01-22 02:30:06 <CodeShark> for instance, the help needs to be filled out more and made more specific to the distro
 158 2013-01-22 02:30:40 <CodeShark> and additional headers should probably be tested as well - and perhaps some functions of the libs should be explicitly tested - not just their existence
 159 2013-01-22 02:30:49 k0rx has left ()
 160 2013-01-22 02:31:13 <CodeShark> and it should probably also try static linkage if dynamic linkage is not possible
 161 2013-01-22 02:31:29 JWU42_ has joined
 162 2013-01-22 02:31:31 JWU42 has quit (Ping timeout: 276 seconds)
 163 2013-01-22 02:34:10 <swappermall> yeah, I'm noticing it's not very specific for individual Linux distros, I'm not sure when I'll be able slog through it ... no guarantee, but if I can, I go through it carefully ... it would be a learning process for me, actually
 164 2013-01-22 02:35:26 MC-Eeepc has quit (Ping timeout: 252 seconds)
 165 2013-01-22 02:35:30 <gavinandresen> CodeShark: don't go too far or you will reinvent auto tools.
 166 2013-01-22 02:35:49 bitnumus has quit (Ping timeout: 248 seconds)
 167 2013-01-22 02:35:52 <CodeShark> hehe - I don't like all the autotools :p
 168 2013-01-22 02:35:57 DaQatz_ has quit (Ping timeout: 248 seconds)
 169 2013-01-22 02:36:35 bitnumus has joined
 170 2013-01-22 02:37:06 <CodeShark> I intend to grab bits and pieces of scripts generated by autotools but incorporate them into a hand-written script that's easy to read and edit
 171 2013-01-22 02:37:59 DaQatz has joined
 172 2013-01-22 02:39:10 <gavinandresen> I think a _help for each dependency is overkill; I'd do one help function per $SYSTEM that either points to a readme that says how to install dependencies or gives the short "port install foo bar.." / "apt-get install foo bar…"
 173 2013-01-22 02:39:51 <CodeShark> you mean a help for each distro is overkill?
 174 2013-01-22 02:40:06 <CodeShark> help for each dependency is already there
 175 2013-01-22 02:40:17 <gavinandresen> I mean a separate zlib_install_help and bdb_install_help is overkill.
 176 2013-01-22 02:40:35 <CodeShark> but we can give them explicit instructions on how to install the specific package that's missing
 177 2013-01-22 02:40:40 <gavinandresen> meh
 178 2013-01-22 02:41:42 <gavinandresen> so I start with nothing installed, and it tells me how to install boost.  I install boost.  Now it tells me I need openssl.  So I install openssl.....
 179 2013-01-22 02:41:59 lumberja1 has quit (Read error: Connection reset by peer)
 180 2013-01-22 02:42:11 <gavinandresen> I think it is more helpful to tell them how to round up and install everything first.
 181 2013-01-22 02:42:24 JWU42 has joined
 182 2013-01-22 02:42:38 <CodeShark> ok, then how about this: it checks all dependencies independently and generates a help containing all the missing ones?
 183 2013-01-22 02:42:51 <CodeShark> that's to say, it doesn't stop checking just because boost failed
 184 2013-01-22 02:43:14 <gavinandresen> … so it will tell me to run 11 different apt_get commands instead of just one?
 185 2013-01-22 02:43:21 <CodeShark> no, it combines them all into one
 186 2013-01-22 02:43:33 <gavinandresen> sounds complicated, but you're in charge.
 187 2013-01-22 02:43:46 <CodeShark> it's far easier than checking for valid blocks :p
 188 2013-01-22 02:45:01 <gavinandresen> I just think the _help functions will be a mess of "If I'm Linux but don't have bdb 4.8 then apt-get install bdb5, if I'm Mac then port install db48, if Windows then wget something-or-another...."
 189 2013-01-22 02:45:10 JWU42_ has quit (Ping timeout: 276 seconds)
 190 2013-01-22 02:45:20 <zip__> http://www.blogtalkradio.com/globalfactradio/2013/01/22/how-to-with-dean-clifford-ep10-invisible-contracts
 191 2013-01-22 02:47:15 lumberjak has joined
 192 2013-01-22 02:47:35 <CodeShark> gavin, it won't work on windows - and all that's necessary is to have a package manager name for each distro and append package names to the command
 193 2013-01-22 02:47:55 <CodeShark> the help functions can actually be fairly simple
 194 2013-01-22 02:48:04 <CodeShark> all the distro logic really happens in the check_system function
 195 2013-01-22 02:50:01 <CodeShark> getting it to work on windows is probably not worth it
 196 2013-01-22 02:50:19 <CodeShark> if anything a separate script is probably a better plan for windows
 197 2013-01-22 02:50:53 <jgarzik> gavinandresen: Thanks for trying picocoin on OSX.  Trying to parse https://github.com/jgarzik/picocoin/issues/13 ...  does that mean configure failed, or succeeded (and then build failed)?
 198 2013-01-22 02:50:54 <CodeShark> windows won't run bash scripts without a little tweaking
 199 2013-01-22 02:51:29 <gavinandresen> jgarzik: configure succeeded, build failed
 200 2013-01-22 02:51:32 <jgarzik> gavinandresen: If ./configure succeeded, I would be curious to see your picocoin-config.h
 201 2013-01-22 02:51:51 <jgarzik> gavinandresen: because configure has some tests, e.g.
 202 2013-01-22 02:51:53 <jgarzik> checking for special C compiler options needed for large files... no
 203 2013-01-22 02:51:53 <jgarzik> checking for _FILE_OFFSET_BITS value needed for large files... no
 204 2013-01-22 02:52:35 <gavinandresen> jgarzik: https://gist.github.com/4591598
 205 2013-01-22 02:53:32 <jgarzik> gavinandresen: given this, it sounds like I should just force-enable it: http://stackoverflow.com/questions/4003479/how-to-enable-large-file-support-under-darwin
 206 2013-01-22 02:54:20 <gavinandresen> jgarzik: okey dokey...
 207 2013-01-22 02:54:46 owowo has quit (Quit: sayonara)
 208 2013-01-22 02:55:36 copumpkin has quit (Ping timeout: 252 seconds)
 209 2013-01-22 02:55:41 <gavinandresen> CodeShark: your configure worked nicely for me, except I ended up with a Makefile with duplicate USE_UPNP:=1  definitions.
 210 2013-01-22 02:55:54 <CodeShark> yes, I had to remove the one in the original makefile
 211 2013-01-22 02:56:13 <gavinandresen> does that break make -f makefile.osx?
 212 2013-01-22 02:56:18 copumpkin has joined
 213 2013-01-22 02:56:21 <CodeShark> unfortunately
 214 2013-01-22 02:56:55 <jgarzik> gavinandresen: what's the canonical #ifdef for OSX?
 215 2013-01-22 02:56:57 <CodeShark> but it shouldn't be too hard to modify the makefile so that it won't break it
 216 2013-01-22 02:57:01 <jgarzik> #ifdef MACOSX ?
 217 2013-01-22 02:57:16 <gavinandresen> jgarzik: I dunno.
 218 2013-01-22 02:58:50 <CodeShark> I believe it's __APPLE__
 219 2013-01-22 02:58:58 <CodeShark> or __MACH__
 220 2013-01-22 03:01:38 <gavinandresen> my gcc defines both __APPLE__ and __MACH__
 221 2013-01-22 03:01:42 skeledrew1 has joined
 222 2013-01-22 03:02:15 skeledrew has quit (Ping timeout: 252 seconds)
 223 2013-01-22 03:03:03 <CodeShark> gavin, assuming the user has sed installed, I can just have it replace the USE_UPNP line in the makefile
 224 2013-01-22 03:04:07 <CodeShark> all the most popular linux distros should be able to run bash scripts and have sed installed
 225 2013-01-22 03:04:17 <gavinandresen> CodeShark: ok. Seems unlikely somebody will have bash and gcc and not have sed
 226 2013-01-22 03:04:50 <gavinandresen> …. and I don't really care about people trying to port bitcoin to PDP-8's
 227 2013-01-22 03:05:10 <jgarzik> gavinandresen: does this fix things?  http://yyz.us/bitcoin/picocoin-configure-osx.patch
 228 2013-01-22 03:06:47 <gavinandresen> jgarzik: that gets me a new error:  Missing required libevent
 229 2013-01-22 03:07:23 <Luke-Jr> CodeShark: it doesn't look like you use MACHINE anyway, but uname -m will NOT work to get the right value
 230 2013-01-22 03:07:44 <CodeShark> yeah, right now the check_system function isn't very granular
 231 2013-01-22 03:07:49 <CodeShark> the idea was to expand out the case statement
 232 2013-01-22 03:07:57 <jgarzik> gavinandresen: odd
 233 2013-01-22 03:07:59 <gavinandresen> jgarzik: wait, hang on, I need to set the magical environment vars
 234 2013-01-22 03:08:21 <CodeShark> so what's the way to get the right value, Luke-Jr?
 235 2013-01-22 03:08:39 <Luke-Jr> CodeShark: I'm not really sure, I always use autoconf :x
 236 2013-01-22 03:08:58 <CodeShark> I'll just look through some other configure scripts
 237 2013-01-22 03:09:14 <gavinandresen> jgarzik: no, didn't fix it, still get O_LARGEFILE undeclared in file_seq.c:15
 238 2013-01-22 03:09:14 <CodeShark> btw, I got the uname -m from the openssl configure script
 239 2013-01-22 03:09:16 <Luke-Jr> CodeShark: most are autoconf-based :P
 240 2013-01-22 03:09:28 <Luke-Jr> CodeShark: also, your configure-made makefile fails for me
 241 2013-01-22 03:09:31 <Luke-Jr> db.h:14:20: fatal error: db_cxx.h: No such file or directory
 242 2013-01-22 03:09:53 <CodeShark> hmmm...does make -f makefile.whatever work?
 243 2013-01-22 03:09:57 EPiSKiNG- has joined
 244 2013-01-22 03:10:03 <Luke-Jr> CodeShark: not as-is, no
 245 2013-01-22 03:10:07 <jgarzik> gavinandresen: could you paste your new picocoin-config.h ?  it does look like file_seq.c includes picocoin-config.h.
 246 2013-01-22 03:10:22 <Luke-Jr> CodeShark: BDB_INCLUDE_PATH=/usr/include/db4.8/
 247 2013-01-22 03:10:24 <CodeShark> ok, my configure script assumes that the makefiles that exist in the src directory work
 248 2013-01-22 03:11:02 <CodeShark> but I'll probably have to tweak them a bit and insert new lines into them to make it work for all configurations
 249 2013-01-22 03:11:05 <gavinandresen> jgarzik: updated https://gist.github.com/4591598  with new pico-config.h
 250 2013-01-22 03:11:14 <Luke-Jr> CodeShark: in fact, your configure script gives me a copy of makefile.unix with just the extra USE_UPNP line :P
 251 2013-01-22 03:11:24 <CodeShark> yes, indeed, Luke-Jr :)
 252 2013-01-22 03:11:29 <gavinandresen> afk (kid goodnight time)
 253 2013-01-22 03:11:51 <jgarzik> gavinandresen: what does the first few lines of configure say?
 254 2013-01-22 03:11:53 <jgarzik> checking build system type... x86_64-unknown-linux-gnu
 255 2013-01-22 03:11:53 <jgarzik> checking host system type... x86_64-unknown-linux-gnu
 256 2013-01-22 03:11:54 <gavinandresen> Luke-Jr is on gentoo?   That's not one of the distros I personally care about...
 257 2013-01-22 03:12:01 <jgarzik> the host/build system type
 258 2013-01-22 03:12:05 paraipan has quit (Quit: Saliendo)
 259 2013-01-22 03:12:16 <Luke-Jr> gavinandresen: the whole point of configure scripts it to automate portability…?
 260 2013-01-22 03:12:34 <Luke-Jr> (besides, the bdb paths are pretty standard)
 261 2013-01-22 03:12:44 <CodeShark> it shouldn't be too hard to support gentoo
 262 2013-01-22 03:13:19 <gavinandresen> jgarzik: http://pastebin.com/iUGxrY1i  is configure output
 263 2013-01-22 03:13:29 <gmaxwell> gavinandresen: Hey, don't hate on gentoo abstractly: In other OSS projects I've found that gentoo has the unusual and almost unique advantage that its users actually send useful patches. I believe I've never gotten a useful patch from a fedora maintainer, but I get a useful one from a gentoo _user_ once or twice a year. :P
 264 2013-01-22 03:13:50 <jgarzik> gavinandresen: did you re-run autogen twice after patching?
 265 2013-01-22 03:14:05 <jgarzik> I don't see "checking build system type" at all
 266 2013-01-22 03:15:16 <Luke-Jr> gmaxwell: jgarzik doesn't send you patches? :P
 267 2013-01-22 03:15:47 <gmaxwell> He's not a fedora maintainer for anything of mine.
 268 2013-01-22 03:17:11 <Luke-Jr> well, he's a user…
 269 2013-01-22 03:17:30 <gmaxwell> Luke-Jr: you're shedpainting my point. :P
 270 2013-01-22 03:17:51 b4epoche has quit (Read error: Operation timed out)
 271 2013-01-22 03:18:34 <gmaxwell> Gentoo is obsecure but tends to trigger the edgecases and actually report/fix them and the users are used to self-service. Best users an OSS project could have even if they do waste some time due to -funroll-universe-omg-and-kittens -fbet-you-didn-know-this-exists-haha-breaks-your-code triggering gcc bugs.
 272 2013-01-22 03:22:11 b4epoche has joined
 273 2013-01-22 03:23:57 <CodeShark> gavinandresen: it no longer breaks make -f makefile.osx
 274 2013-01-22 03:26:08 <gavinandresen> jgarzik: …rerun autogen twice… I didn't re-run it even once....
 275 2013-01-22 03:26:48 <gavinandresen> jgarzik: ah, works perfectly now.  You've got to remember, I don't know nuthin about autotools....
 276 2013-01-22 03:27:25 Guest42214 is now known as amiller_
 277 2013-01-22 03:30:17 <zip__> Much love Gavin. Have not been her for a while. Thank you so much for keeping btc alive. Love you brother.
 278 2013-01-22 03:31:33 legitnick1 has quit (Ping timeout: 256 seconds)
 279 2013-01-22 03:31:58 <jgarzik> gavinandresen: "make all check" should build and test
 280 2013-01-22 03:32:04 <jgarzik> gavinandresen: will commit patch
 281 2013-01-22 03:33:29 legitnick1 has joined
 282 2013-01-22 03:36:31 zooko has quit (Ping timeout: 245 seconds)
 283 2013-01-22 03:49:43 fiesh has quit (Ping timeout: 244 seconds)
 284 2013-01-22 03:52:50 nus- has joined
 285 2013-01-22 03:53:11 nus has quit (Read error: Connection reset by peer)
 286 2013-01-22 03:53:23 fiesh has joined
 287 2013-01-22 03:57:07 <petertodd> I think I came up with something clever: https://bitcointalk.org/index.php?topic=106449.msg1469608#msg1469608 <- auditing for inflation fraud by having transactions themselves be hashed with a merkle tree, with the values for each part of the tree summed and included in the hash (end of the message)
 288 2013-01-22 04:14:08 <kjj> why are you summing parts of a merkle tree?
 289 2013-01-22 04:15:02 <petertodd> I'm not summing the hashes, I'm summing the values of the txin's and txouts in the transaction
 290 2013-01-22 04:15:18 <petertodd> and including those values in what is being hashed in intermediary nodes in the tree
 291 2013-01-22 04:15:22 mps has joined
 292 2013-01-22 04:15:37 <legitnick1> this is why I'm never using blockchain.info's my wallet again
 293 2013-01-22 04:15:38 <legitnick1> pastebin.com/kpTcQ1xY
 294 2013-01-22 04:17:38 <Luke-Jr> legitnick1: why?
 295 2013-01-22 04:18:34 <kjj> erm, how does the tree help you then?
 296 2013-01-22 04:19:16 FredEE has joined
 297 2013-01-22 04:19:39 rdponticelli has joined
 298 2013-01-22 04:19:51 <kjj> the transaction hash is a hash of the entire transaction, including the inputs and outputs.  I'm really not seeing how hashing those numbers a second time helps anyone
 299 2013-01-22 04:20:18 <petertodd> because you can be sure of the total value of a transaction without actually knowing the whole transaction itself
 300 2013-01-22 04:20:59 <petertodd> equally you can know the total value of the txin's and txouts in a block, without knowing every txin and every txout, and as I said in my message, audit probabalistically, and prove fraud without the whole block
 301 2013-01-22 04:21:03 <kjj> why on earth would you think that you know that part of a transaction is real?
 302 2013-01-22 04:21:23 <petertodd> bonds are one application, you want to know that your txout was real, but don't care who else got paid
 303 2013-01-22 04:21:34 <petertodd> (colored coin bonds that is)
 304 2013-01-22 04:22:00 <petertodd> given the tx hash, the fact that it is in a block is why you know it is real
 305 2013-01-22 04:22:06 <petertodd> which is true of any transaction
 306 2013-01-22 04:22:16 <kjj> yes
 307 2013-01-22 04:22:43 <petertodd> I'm just extending the way the merkle tree works for blocks to within transactions themselves
 308 2013-01-22 04:22:44 <kjj> however, given part of a transaction, and a hash of the whole transaction, you don't know anything at all whatsoever about that alleged fragment you hold
 309 2013-01-22 04:23:08 RainbowDashh has quit (Quit: Computer has gone to sleep.)
 310 2013-01-22 04:23:14 <petertodd> right now you don't, but if transactions themselves were hashed with merkle trees, you could
 311 2013-01-22 04:23:19 B0g4r7 has quit (Ping timeout: 276 seconds)
 312 2013-01-22 04:23:28 <petertodd> this could be implemented as a merge-mined soft-fork
 313 2013-01-22 04:24:12 <legitnick1> Luke-Jr: Probably due to the 13 coins that have been stuck at 0 confirms since the 4th
 314 2013-01-22 04:26:54 <kjj> that's a godawful mess, with very little or no benefit
 315 2013-01-22 04:27:40 <petertodd> proving inflation fraud without having to transmit whole blocks sounds like a big benefit to me if block sizes are increased over 1MiB for instance
 316 2013-01-22 04:27:52 sacredchao has quit (Ping timeout: 276 seconds)
 317 2013-01-22 04:27:59 <petertodd> similarly it makes storage of colored-coin bonds much smaller when large numbers are issued in one tx
 318 2013-01-22 04:28:42 <kjj> I'm not sure what inflation fraud is, but I really doubt that you can prove anything by looking at just one output
 319 2013-01-22 04:29:15 sacredchao has joined
 320 2013-01-22 04:30:09 <petertodd> inflation fraud is where a miner creates a block with fake transactions in it to collect fees that they aren't entitled too. SPV clients have to trust other miners not to defraud them, because the block headers by themselves don't give proof that every transaction in a block was valid.
 321 2013-01-22 04:30:11 <kjj> don't take my criticism too personally.  I looked in the colored coin thing a while back and concluded that it was a mess waiting to happen
 322 2013-01-22 04:31:01 freakazoid has joined
 323 2013-01-22 04:31:07 rdponticelli has quit (Ping timeout: 276 seconds)
 324 2013-01-22 04:31:13 <petertodd> this method allows for you to give an SPV client proof that a block is fraudulant by just giving them the merkle tree leading to the faked transaction, and they can conclude the block is faked if no-one replies with the valid transaction (quenching the fraud alert)
 325 2013-01-22 04:31:39 <petertodd> kjj: responding to criticism is how I convince myself that I'm actually right :P
 326 2013-01-22 04:31:54 <kjj> if the miner is in a position to feed bogus info to a non-validating client, why can't he fake this other new info too?
 327 2013-01-22 04:32:45 <kjj> fraud alert?  you've got a whole little ecosystem going there it seems.
 328 2013-01-22 04:32:46 <petertodd> the problem for him is any honest miner can broadcast a fraud proof, and the second the proof gets to the SPV client P2P network every SPV client can pass it among themselves alerting each other
 329 2013-01-22 04:32:52 SnapSnap has joined
 330 2013-01-22 04:32:59 <kjj> why not just have your non-validating node use a trusted validating node for input?
 331 2013-01-22 04:33:05 <petertodd> heh, I'm thinking about fraud alerts for another project - comes naturally
 332 2013-01-22 04:33:44 <petertodd> the thing is with this system they don't have to have any trusted validating nodes, the proof of work can be checked without access to the txout set
 333 2013-01-22 04:34:54 <petertodd> any honest node with a complete txout set copy can determine if fraud happened and publish a proof
 334 2013-01-22 04:35:02 <kjj> I don't think that is true at all.  I think you are wrong about either how much information you need to make that determination, making your system a de facto validating node, or about how much control an attacker needs over a node to do this, and what else they could do
 335 2013-01-22 04:35:04 darkee has quit (Remote host closed the connection)
 336 2013-01-22 04:35:06 <SnapSnap> When I improperly close bitcoin-qt (using Ubuntu 12.10) I get an error concerning blkindex.dat when I try to start it. At that point I have to delete everything except wallet.dat from /.bitcoin in order for the client to run. Of course, the client begins downloading the block chain anew. Is there a better way to correct the error than deleting those files, and will this bug be fixed in a future version?
 337 2013-01-22 04:35:27 <kjj> stop improperly closing it?  :)
 338 2013-01-22 04:35:55 darkee has joined
 339 2013-01-22 04:35:57 <SnapSnap> kjj, thanks for the tip :P
 340 2013-01-22 04:36:51 <kjj> set a cron job to close it properly with a detach, and make a copy of the BDB files.  and yes, 0.8 should be much more tolerant of people abusing the database
 341 2013-01-22 04:37:51 <petertodd> ok, so my definition is a validating node needs to have a complete txout set, while a SPV node just has access to the block headers. now since the merkle tree embeds value information, any SPV node can check that that out - in = block reward. meanwhile any validating node can create the full transaction tree from the txout set, and if they see a discrepency they can broadcast a fraud proof that would be just 32bytes * tree height long
 342 2013-01-22 04:37:59 <kjj> petertodd:  if a miner can create a bogus block and make you believe it, he can also prevent you from getting any sort of contrary alerts
 343 2013-01-22 04:39:00 <petertodd> right, but SPV clients in the future might know nothing *but* the block headers themselves, for instance if the block size is increased beyond 1MiB it may be too much bandwidth to even receive full blocks
 344 2013-01-22 04:39:22 <kjj> because in general, the network will not forward garbage.  so you'd only get the bad block if he is directly connected to you, and then only if your client is dumb enough not to ask for second opinions
 345 2013-01-22 04:39:42 <petertodd> but if most of the network is SPV clients the network *will* forward garbage, because those clients have no way of knowing otherwise
 346 2013-01-22 04:40:00 <petertodd> without a txout set you can't know if a tx is valid or not
 347 2013-01-22 04:40:20 <petertodd> or if a block header is inflating or not
 348 2013-01-22 04:40:36 <kjj> it seems to me that you are piling on more and more epicycles to try to make things work out the way you want
 349 2013-01-22 04:41:07 D34TH has quit (Read error: Connection reset by peer)
 350 2013-01-22 04:41:10 <petertodd> heh, I'm solving a problem that will exist, not one that does exist, right now every node on the network is a full node essentially
 351 2013-01-22 04:41:30 <kjj> if you are going down that road, there is a very simple version.  make a hash of the UTXO set and stash the root of that tree in each block
 352 2013-01-22 04:41:35 <petertodd> the problem is finding ways to allow large numbers of SPV nodes - we don't know how to do that yet
 353 2013-01-22 04:41:55 <petertodd> right, but that UTXO set hash is still susceptable to the same problem
 354 2013-01-22 04:42:39 <kjj> who is checking these hashes, and what are they being compared to?
 355 2013-01-22 04:43:28 <petertodd> honest validating nodes, and critically, unlike the UTXO-set proposals, any honest validating node, even if they are in the minority, can create a fraud proof
 356 2013-01-22 04:43:49 <petertodd> this way even a >51% cartel of miners still can't inflate the currency
 357 2013-01-22 04:44:17 <kjj> oh god.  a 99% cartel of miners can't inflate the currency.  a 105% cartel can't do it.  no one can
 358 2013-01-22 04:44:50 <petertodd> to validating nodes no-one can, but to SPV nodes yes they can
 359 2013-01-22 04:45:09 <petertodd> all the SPV client knows is that the proof-of-work was as hard as it should be
 360 2013-01-22 04:46:08 <kjj> the system requires validation.  there is no way around that
 361 2013-01-22 04:46:10 <petertodd> remember that in the future even having a full txout set will probably be prohibitively expensive for many nodes
 362 2013-01-22 04:46:26 <petertodd> no, it requires degrees of validating, SPV nodes can't validate very much, but they are efficient
 363 2013-01-22 04:46:42 <petertodd> and they can validate the proof-of-work, which is pretty valuable
 364 2013-01-22 04:46:59 <kjj> it doesn't require that everyone validate, but it requires that someone validate
 365 2013-01-22 04:47:48 <kjj> and you are nuts if you assume the existence of that someone without providing some reason for that someone to exist
 366 2013-01-22 04:48:20 <petertodd> it requires a majority of mining power to validate in the current system, this proposal allows a minority of honest nodes (which don't have to mine) since any of that minority can proof fraud
 367 2013-01-22 04:48:41 <kjj> what requires the majority of mining power for validation right now?  certainly not inflation
 368 2013-01-22 04:48:47 Silverion has joined
 369 2013-01-22 04:49:10 <kjj> miners are in control of the order of transactions, not their amounts, not the creation rate
 370 2013-01-22 04:49:15 <petertodd> basically an SPV client in the future will receive a message from a peer consisting of just "hey, we found a new block header and the PoW checks out", and with this system any honest node can publish a proof saying "hang on, look at this merkle branch, the transaction at the end of it doesn't exist!"
 371 2013-01-22 04:49:45 <petertodd> but that's because the network is made up of full validating nodes, SPV client can-not validate anything other than proof of work
 372 2013-01-22 04:50:00 <kjj> again, my point is that SOMEONE must do that
 373 2013-01-22 04:50:26 <kjj> and if you don't give that someone an economic reason to exist, you shouldn't be basing your hopes and dreams on them existing
 374 2013-01-22 04:50:55 <petertodd> yes, but as I say, if a majority of hashing power colludes, an SPV client can do *nothing* about it, this proposal allows any honest node to prove that the majority are attempting to defraud, without having to publish a lengthy set of blocks
 375 2013-01-22 04:51:30 FredEE has quit (Ping timeout: 246 seconds)
 376 2013-01-22 04:51:35 <petertodd> right now a proof of fraud is enormous, it's the whole block chain itself
 377 2013-01-22 04:51:52 <petertodd> this system allows a proof of fraud to just be a kilobyte in size
 378 2013-01-22 04:52:00 emryss has quit (Ping timeout: 252 seconds)
 379 2013-01-22 04:52:07 <petertodd> and the rebuttle to the proof of fraud is just the actual transaction
 380 2013-01-22 04:53:46 <kjj> is there a cost for a claim of fraud?
 381 2013-01-22 04:54:05 <kjj> (hint, if there is not, then SA or someone like them will just claim fraud on every transaction)
 382 2013-01-22 04:55:09 <petertodd> yeah, that's a nasty sticking point, attaching a proof-of-work a-la hashcash, and adaptive anti-DDoS mechanisms is probably needed, but proving fraud is in the incentive of miners anyway
 383 2013-01-22 04:55:19 <petertodd> *honest miners
 384 2013-01-22 04:55:28 <kjj> and another epicycle falls into place.  :)
 385 2013-01-22 04:55:37 <petertodd> meh, hashcash works
 386 2013-01-22 04:55:42 TheSeven has quit (Disconnected by services)
 387 2013-01-22 04:55:50 <petertodd> and broadcasting a 1KiB of data has a pretty low cost
 388 2013-01-22 04:55:51 [7] has joined
 389 2013-01-22 04:55:53 <kjj> if hashcash worked, it would have taken SMTP by storm in the 90s
 390 2013-01-22 04:56:03 SnapSnap has quit (Quit: Leaving)
 391 2013-01-22 04:56:34 <petertodd> hashcash for SMTP had serious issues around mailing lists, and the fact that SMTP became centralized around web-clients killed it
 392 2013-01-22 04:56:44 <petertodd> or I should say, killed any hope of it ever being implemented
 393 2013-01-22 04:57:13 <petertodd> not to mention it would have really required dedicated hardware to outwit the spammers, who would have bought their own hashcash creation hardware
 394 2013-01-22 04:57:46 <kjj> heh.  bought their own?  they use zombies on cable modems, so hashing was free for them.
 395 2013-01-22 04:58:13 <petertodd> exactly, the cost of the hashing for the spammers is low either way
 396 2013-01-22 04:58:40 <kjj> in fact, it totally misaligns incentives, just like it would here.  honest nodes would have another burden, while bogus fraud claims would remain free
 397 2013-01-22 04:58:43 <petertodd> while a server sending millions of emails a day needs serious hashing power, which even if they do buy, spammers are just going to buy it again
 398 2013-01-22 04:59:35 <petertodd> no, bogus fraud claims will be as expensive as the hashing power required to get them accepted, remember that a bogus claim can be immediately quenched by broadcasting the missing transaction, and any node having both just won't relay the fraud
 399 2013-01-22 04:59:44 <petertodd> basically, the bogus claims won't get all that far
 400 2013-01-22 05:00:17 <petertodd> for instance you can have nodes delay re-broadcasting of fraud notices slightly, while re-broadcasting rebuttles immediately
 401 2013-01-22 05:00:28 <kjj> heh.  don't forget that you are assuming that there are essentially zero nodes that actually have the transaction.  that's the whole problem you are trying to solve.  the fraud claim will flood the entire network before that one honest node sees it
 402 2013-01-22 05:01:07 <kjj> and again, the people making bogus fraud claims will be using your grandma's CPU, and the claim will be free to them
 403 2013-01-22 05:01:11 <petertodd> as I say, delaying fraud claims slightly allows the honest tx to propegate fast enough to stop the broadcast quickly, you just need a small fraction of nodes to have it
 404 2013-01-22 05:01:29 <kjj> and the next epicycle takes shape.  :)
 405 2013-01-22 05:01:49 <petertodd> and for what? they get to slightly increase bandwidth, while a honest node, especially a miner, has a big incentive to create a bunch of expensive hashcash to make their honest fraud claim stick
 406 2013-01-22 05:02:17 <petertodd> after all, mining is a zero-sum game
 407 2013-01-22 05:02:33 <kjj> not in a world where no one can validate what the miners are doing
 408 2013-01-22 05:03:35 <petertodd> miners can validate miners, and in this system the honest percentage of miners does *not* need to be a majority, that's the whole point, and upon proof of fraud the SPV clients simply ignore their chain, even if it is longer, so the dishonest mining effort is in vain
 409 2013-01-22 05:04:11 <petertodd> mining is only valuable if you can convince someone to accept your coins for something other than bitcoins after all
 410 2013-01-22 05:08:54 <kjj> I still think that you've added about 9 steps too many to what used to be a very simple and elegant system, in hopes of being able to validate something in the absense of the information necessary to do that validation
 411 2013-01-22 05:09:50 <petertodd> hey, simple and elegant doesn't always work, and the core of what is needed is a relatively simple change to the transaction hashing algorithm; it'd be easy if the system was designed to work this way from the beginning
 412 2013-01-22 05:10:00 <petertodd> shoe-horning it in now is what is tricky
 413 2013-01-22 05:10:06 <CodeShark> configure script updated: https://github.com/CodeShark/bitcoin/blob/configure_script/src/configure
 414 2013-01-22 05:10:46 LargoG has quit (Ping timeout: 276 seconds)
 415 2013-01-22 05:12:12 <kjj> I think it makes more sense to understand the limitations of low validation clients, and assume that they aren't going to become the entire network ever
 416 2013-01-22 05:14:08 <petertodd> hey, I understand damn well what their limitations are, but proposals that scale bitcoin up to the level of, say, visa, can-not happen without the vast majority of clients being SPV
 417 2013-01-22 05:19:05 <CodeShark> the most important thing for bitcoin to work is that the majority of validation/relay nodes are not in collusion and cheating
 418 2013-01-22 05:20:04 <CodeShark> the problem with low validation is that the cost of setting up a large number of cheating nodes isn't too high
 419 2013-01-22 05:20:33 <petertodd> yup, and detection is difficult
 420 2013-01-22 05:20:43 <CodeShark> however, perhaps this can be ameliorated to an extent by letting the user pick a list of "trusted" validation nodes
 421 2013-01-22 05:21:12 <petertodd> right, but then, you're getting closer to "why not just use PayPal?"
 422 2013-01-22 05:22:41 JZavala has quit (Ping timeout: 252 seconds)
 423 2013-01-22 05:25:05 <CodeShark> longest chain is still longest chain, though - meaning that even if you only check proof of work, the cost of cheating is still high
 424 2013-01-22 05:27:20 <petertodd> well sure, but with SPV nodes the 51% attack becomes theft, rather than just making transactions unable to confirm
 425 2013-01-22 05:27:50 <petertodd> actually, this method can be used to protect SPV nodes from fake transaction inputs too you know
 426 2013-01-22 05:31:55 nus- has quit (Read error: Connection reset by peer)
 427 2013-01-22 05:32:10 nus- has joined
 428 2013-01-22 05:32:18 <CodeShark> someone could try to fork the network and create a bunch of bogus blocks that claim to pay out large sums to a bunch of people - but it would still require a 51% attack to overwhelm the legitimate network
 429 2013-01-22 05:32:24 safra has joined
 430 2013-01-22 05:33:31 brwyatt is now known as brwyatt|Away
 431 2013-01-22 05:33:34 <petertodd> yup, but after all, 51% might be a lot easier to achieve if the block size limit is raised significantly
 432 2013-01-22 05:33:55 <petertodd> now, I happen to think that's a bad idea myself, but this proposal might make that bad idea a lot more workable
 433 2013-01-22 05:34:09 <petertodd> and the alternatives might not be as good ideas as I think they are :)
 434 2013-01-22 05:35:43 <phantomcircuit> petertodd, block size limit has nothing to do with a 51% attack...
 435 2013-01-22 05:37:05 <petertodd> yes it does, if the block size limit is increased, running a validating node becomes more expensive because the full history and txout sets become larger, at the extremes of "replace visa with Bitcoin" there might not be very many validating nodes at all, with the vast majority of mining power doing no actual validation at all
 436 2013-01-22 05:38:05 <petertodd> again, the whole point of this proposal is to limit the power of a 51% attack to disrupting the network, rather than outright theft, even for SPV nodes
 437 2013-01-22 05:41:09 <CodeShark> a 51% attack is more than merely disruptive - it allows someone to rewrite history, in effect allowing them to doublespend
 438 2013-01-22 05:41:50 <CodeShark> I'd consider that a form of theft
 439 2013-01-22 05:43:49 <CodeShark> bitcoin should be rebase-resistant :p
 440 2013-01-22 05:44:35 <petertodd> right, but the power to double spend is limited in that you need to sustain the attack
 441 2013-01-22 05:44:42 B0g4r7 has joined
 442 2013-01-22 05:45:21 <petertodd> 51% is a term for something that's actually probabalistic, if you have close to 51%, but not actually over, you can just wait until you get lucky with a string of tx's and use it to commit theft because they'll look valid
 443 2013-01-22 05:45:21 <CodeShark> you only need to overwrite some of history and get legitimate nodes to accept that history - and then you can take off
 444 2013-01-22 05:45:30 <petertodd> if fees are low, that may be worthwhile
 445 2013-01-22 05:46:39 <CodeShark> an effective 51% attack would destroy bitcoin as we know it
 446 2013-01-22 05:46:41 <legitnick1> in theory the double spends would be easy to spot though right?
 447 2013-01-22 05:47:01 <petertodd> quite possibly yes, in a way that totally fake txin's wouldn't be
 448 2013-01-22 05:47:33 <petertodd> a double-spend requires very little data to prove the existence of
 449 2013-01-22 05:48:06 <petertodd> CodeShark: temporary proof-of-stake schemes can be implemented as Gavin as pointed out before
 450 2013-01-22 05:48:26 <petertodd> CodeShark: it'd be a huge disruption, but outright destorying bitcoin? perhaps not
 451 2013-01-22 05:48:39 <petertodd> CodeShark: especially if the attack can't be maintained (stolen computer power for instance)
 452 2013-01-22 05:48:44 <CodeShark> bitcoin would not survive an effective 51% attack without some significant modifications
 453 2013-01-22 05:49:04 <legitnick1> what if there was more than one blockchain
 454 2013-01-22 05:49:25 <petertodd> CodeShark: no, but those are modifications that can be implemented
 455 2013-01-22 05:49:45 <CodeShark> but those modifications are of the hard-fork variety
 456 2013-01-22 05:49:49 <CodeShark> for the most part
 457 2013-01-22 05:49:52 <gmaxwell> CodeShark: "51% attack" is far too vague to actually speak concretely about. It could mean many things.
 458 2013-01-22 05:49:57 <petertodd> legitnick1: solving the problem of their being more than one blockchain is what bitcoin does...
 459 2013-01-22 05:50:19 <petertodd> CodeShark: hard-forks can be implemented fast in a "shit everything will be worthless now" emergency
 460 2013-01-22 05:50:19 <CodeShark> gmaxwell: I specifically refer to the ability to outpace the rest of the network in finding blocks
 461 2013-01-22 05:50:32 <petertodd> yes, but outpace isn't absolute
 462 2013-01-22 05:50:40 <gmaxwell> For how long and to what end?
 463 2013-01-22 05:50:47 <petertodd> for instance stolen computer power, or just getting lucky
 464 2013-01-22 05:51:02 <gmaxwell> Deepbit has been able to outpace the rest of the network before— and yet, inspite of your and my expectations bitcoin still exists.
 465 2013-01-22 05:51:13 <CodeShark> I'm not talking about statistical aberrations
 466 2013-01-22 05:51:31 <gmaxwell> CodeShark: Nor am I.
 467 2013-01-22 05:51:35 <CodeShark> I'm talking about the ability to have E(generation time) smaller than the rest of the network
 468 2013-01-22 05:51:59 <CodeShark> and using it to deliberately rewrite history
 469 2013-01-22 05:52:08 <gmaxwell> CodeShark: deepbit had an absolute majority of hashpower for some time— basically until forces with unknown motivations kept them offline with heavy dos attacks for about a week.
 470 2013-01-22 05:52:22 <gmaxwell> well then you didn't say "deliberately rewrite history" before.
 471 2013-01-22 05:52:32 <CodeShark> that someone has a majority of hashpower doesn't mean they launch an attack
 472 2013-01-22 05:52:39 <gmaxwell> Thats not the only thing a party with a majority hashpower can do.
 473 2013-01-22 05:53:21 <CodeShark> even if a single entity owned all the hash power, assuming they were benevolent, bitcoin could still survive
 474 2013-01-22 05:53:31 <gmaxwell> And 51% isn't really any different from say— 40% in terms of the ability to rewrite far enough to trip up common acceptance criteria (e.g. 6 blocks)
 475 2013-01-22 05:53:36 <CodeShark> of course, that assumption is exactly what bitcoin does NOT make
 476 2013-01-22 05:53:41 <gmaxwell> CodeShark: No it couldn't thats nonsense.
 477 2013-01-22 05:53:48 <gmaxwell> It couldn't be totally pointless and survive.
 478 2013-01-22 05:54:11 <CodeShark> well, now we're getting into pedantic argumentation
 479 2013-01-22 05:54:21 <CodeShark> yes, it would be pointless
 480 2013-01-22 05:54:26 <gmaxwell> — bitcoin would make for the most over complicated inflexible insecure and resource intensive _centeralized_ system ever devised by man.
 481 2013-01-22 05:55:12 <CodeShark> the only point I was trying to make is that bitcoin is at serious risk if any single entity has majority hashing power - and couldn't survive as it exists if such an entity decided to use that power to launch an attack
 482 2013-01-22 05:55:31 <gmaxwell> CodeShark: No, I'm encouraging you to be specific. 51% != attack, attack != history rewrite,  51% can't really rewrite history 6 blocks back substantlly better than 40%,  and 51% would take an enormous highly risky amount of time to rewrite long horizons (like months)
 483 2013-01-22 05:56:28 <CodeShark> I think I was pretty specific - but I'll reiterate: a 51% attack is someone who has a majority of hashing power using that power to deliberately rewrite history
 484 2013-01-22 05:56:32 <gmaxwell> CodeShark: you've added a lot of qualifications now— good. They're important. All these things have proabilities connected to them, and they compose. Part of the security comes from the difficulty in actually profiting from one of these insanely costly attacks.
 485 2013-01-22 05:56:48 <gmaxwell> CodeShark: you can rewrite history deliberatly with far less hashpower.
 486 2013-01-22 05:56:52 <CodeShark> any such attack diminishes in power as you go back in time
 487 2013-01-22 05:57:11 <CodeShark> and yes, you could get lucky and pull off a finney attack
 488 2013-01-22 05:57:24 <gmaxwell> No. I'm not talking about finney attacks.
 489 2013-01-22 05:57:25 <CodeShark> I wouldn't call that a 51% attack
 490 2013-01-22 05:57:53 <gmaxwell> You can be a miner with 40% hashpower and pull off a six block reorg once every couple days.
 491 2013-01-22 05:58:07 <CodeShark> that's not a 51% attack
 492 2013-01-22 05:58:14 <CodeShark> as I defined it above
 493 2013-01-22 05:58:51 <CodeShark> you can be a miner with far less hash power than that - and over a long enough period of time, you could get a good streak
 494 2013-01-22 05:59:04 <gmaxwell> And at 51% your ability is not bounded, it takes you longer than the history you wish to rewrite— e.g. assuming constant difficulty rewriting 2 years takes over 20 years working on your fork in secret.. and if at any point in time the rate increases and you fall below 51% all your work is wasted.. if a checkpoint is set before you catch up and release your work... all your work is wasted.
 495 2013-01-22 05:59:35 <CodeShark> yes, the amount of power required increases the further back in time you go
 496 2013-01-22 05:59:47 <gmaxwell> CodeShark: No, it's not a "51%" attack, it's a rewriting attack— the thing above you said is what actually live-or-die mattere.d
 497 2013-01-22 06:00:21 <gmaxwell> I'm suggesting you drop "51%" from your description and instead just say successful attack against the expected and understood security model.
 498 2013-01-22 06:00:29 <CodeShark> that's too vague
 499 2013-01-22 06:00:51 <CodeShark> if you would prefer to speak of rewriting attacks, that's fine
 500 2013-01-22 06:01:19 <gmaxwell> 51% is insanely vague. Also inaccurate considering that 50%+ε is fine for eventually success with p=1.  ... but it's also vague because rewriting history isn't the uniquely interesting power of majority hashpower.
 501 2013-01-22 06:01:27 <CodeShark> lol
 502 2013-01-22 06:01:28 B0g4r7 has quit (Ping timeout: 276 seconds)
 503 2013-01-22 06:01:35 <CodeShark> getting pedantic again :p
 504 2013-01-22 06:01:47 <gmaxwell> Rewrites you can do with submajority hashpower.. what you can't do with submajority hashpower is a complete transaction denial of service.
 505 2013-01-22 06:01:57 <CodeShark> I'm using 51% in the colloquial sense - not in the mathematically rigorous sense
 506 2013-01-22 06:02:17 <CodeShark> we're not doing real analysis here
 507 2013-01-22 06:02:36 <gmaxwell> You're ignoring the substantive point I made in favor of a tangent I tossed in.
 508 2013-01-22 06:03:13 <CodeShark> but yes, 50% + ε; ε > 0 is more rigorously correct
 509 2013-01-22 06:03:19 <gmaxwell> Keep in mind where this conversation started— you were saying < CodeShark> bitcoin would not survive an effective 51% attack without some significant modifications and <@gmaxwell> CodeShark: "51% attack" is far too vague to actually speak concretely about. It could mean many things.
 510 2013-01-22 06:03:53 <petertodd> gmaxwell: actually, the conversation really started here: https://bitcointalk.org/index.php?topic=137933
 511 2013-01-22 06:04:00 <petertodd> gmaxwell: long story...
 512 2013-01-22 06:04:07 <gmaxwell> So for all I knew you meant the complete transaction denial of service— since thats the 'unique 50% attack' .. or perhaps you meant the timewarp inflationary attack, which doesn't exist in plationic bitcoin, but exists in the real thing.
 513 2013-01-22 06:04:54 <CodeShark> gmaxwell, there was a context to the conversation
 514 2013-01-22 06:05:01 <CodeShark> and I think petertodd understood what I was trying to say
 515 2013-01-22 06:05:30 <petertodd> CodeShark: disagreed, but understood :)
 516 2013-01-22 06:06:03 <CodeShark> but you're right, gmaxwell, used in an isolated fashion it is not a rigorous term
 517 2013-01-22 06:06:16 <gmaxwell> petertodd: did you see my old post on the proofs concept?
 518 2013-01-22 06:06:21 B0g4r7 has joined
 519 2013-01-22 06:06:39 <petertodd> gmaxwell: I don't think so
 520 2013-01-22 06:06:51 <petertodd> gmaxwell: did I just re-invent something again?
 521 2013-01-22 06:07:30 <gmaxwell> Maybe that means it's a good idea.
 522 2013-01-22 06:08:20 <gmaxwell> I was mostly focusing on a SPV-OTXO security model and proving the history you didn't verify for yourself, rather than SPV-blockchain-tip. But it's the same idea.
 523 2013-01-22 06:08:52 <petertodd> Ah, interesting, did you also do the "sum of value" stuff?
 524 2013-01-22 06:09:29 <petertodd> I think it's neat how the lesser version of fraud proofs, proof of a non-existent tx-in, can be implemented right now.
 525 2013-01-22 06:11:58 <gmaxwell> I didn't go into implementation details— but basically the point being that because information is hard to suppress (one of our core security assmptions) if people form notices of treachery it reduces the tragidy of commons risk.
 526 2013-01-22 06:12:31 <petertodd> Makes sense, the trick is making it possible to cheaply prove treachery.
 527 2013-01-22 06:12:40 <gmaxwell> Becuase then if there exists at least _one_ node which is honest and validating then everyone gets the security of full validation. So long as you can construct and advertise proofs for every rule.
 528 2013-01-22 06:13:01 <petertodd> Exactly my idea.
 529 2013-01-22 06:13:09 <gmaxwell> For txout duplication it's trivial, two tree fragements and txn spending the same coin.
 530 2013-01-22 06:13:42 <gmaxwell> likewise for utxo proper updates (it's a tree fragment and its internal nodes)
 531 2013-01-22 06:14:04 <petertodd> Yup, although you need the utxo set to validate that.
 532 2013-01-22 06:14:22 <petertodd> At VISA levels even the utxo set will be way to expensive for most nodes.
 533 2013-01-22 06:14:37 <gmaxwell> Well 'visa levels' is nonsense, but thats another issue.
 534 2013-01-22 06:14:56 <gmaxwell> http://sourceforge.net/mailarchive/message.php?msg_id=29450793  (one of the posts, but there is an earlier one I hadn't found yet)
 535 2013-01-22 06:15:18 <petertodd> Yeah, I think TrustBits is a much better idea, even if I just spent an hour getting VISA levels to work. :P
 536 2013-01-22 06:15:22 <gmaxwell> petertodd: you don't actually ever need the utxo to verify the utxo, thats part of the beauty of hash validated data structures.
 537 2013-01-22 06:16:15 <petertodd> gmaxwell: So what, the utxo is ordered or something, and valid utxo transformations can be proven that way? (I admit, I haven't read the utxo proposals carefully enough to really understand them)
 538 2013-01-22 06:17:01 <petertodd> (nor do I know enough comp-sci to fully understand them)
 539 2013-01-22 06:17:15 <gmaxwell> petertodd: say you have a datastructure that allows efficient, e.g. O(ln(n)) queries. Could be a tree or whatever. I don't care.
 540 2013-01-22 06:17:55 <gmaxwell> If you attach hashes along side that datastructure hashing all it's state... and then hash up the hashes and I have the root hash from some trusted place (like myself in the past or the chain)
 541 2013-01-22 06:18:20 grau has joined
 542 2013-01-22 06:18:31 <gmaxwell> then when I want to query it, I ask you to query it.. you query it and as you go along you access ln(n) elements and save all the hashes for those elements. You give me all the data you read. I verify up the hashes.
 543 2013-01-22 06:19:08 <petertodd> Right, so the hashes proves the data, and hence the data can be stored on a dishonest node?
 544 2013-01-22 06:19:13 <petertodd> *possibly dishonest
 545 2013-01-22 06:19:14 <gmaxwell> Now you have proven to me that your computation is valid— I can repect the computation, so I know you took all the right actions, and I know the data you acted on was all correct due to the hashes.
 546 2013-01-22 06:19:18 <gmaxwell> Right.
 547 2013-01-22 06:19:52 <gmaxwell> And this is a general concept which can pretty much be applied to any kind of data structure (though efficiency may vary— it's great on trees— so you store the utxo set using some kind of tree)
 548 2013-01-22 06:20:23 <petertodd> Which basically means any dishonest UTXO update is cheaply proven by showing parts of the before and after states that don't match up.
 549 2013-01-22 06:20:39 <gmaxwell> Bingo, you just show the fragments that weren't computed right.
 550 2013-01-22 06:21:10 <gmaxwell> People see.. here is the relevant fragments, here is the new block.. I'm sure the fragements are right due to their chain committed hashes.. uh oh!.
 551 2013-01-22 06:21:23 <petertodd> And, rather than proving inflation dishonestly by value directly, just show that the difference in the UTXO between block n and block n+1 doesn't make sense.
 552 2013-01-22 06:21:36 <petertodd> Although, by value directly is probably going to still be cheaper.
 553 2013-01-22 06:21:42 <gmaxwell> petertodd: downside is that the proofs for that would be rather large.
 554 2013-01-22 06:21:49 <gmaxwell> right.
 555 2013-01-22 06:22:24 <petertodd> Implementing the UTXO stuff requires a soft-fork anyway + merge-mining, so you might as well thrown the value stuff in now, at least if there isn't a flaw/better way to do it.
 556 2013-01-22 06:22:35 <gmaxwell> (a proof for inflation with just the utxo is the fragments connecting every input in the misvalued block— though the fragements merge it would still likely be some multiple of the blocksize)
 557 2013-01-22 06:23:19 <petertodd> Which is the beauty of computing the sum at every level: just fine the one part of the tree where the two halves don't add up.
 558 2013-01-22 06:23:20 <gmaxwell> well, I'm not a fan of UTXO as merged mined, if its to be something we really do it should just be a straight coinbase rule. But there are some gotchas.
 559 2013-01-22 06:24:00 <petertodd> Well, takes a long time to get the 95%... but what are the other gotchas?
 560 2013-01-22 06:24:00 <gmaxwell> petertodd: yea, you're just merkelizing another kind of data structure— a tree over transactions with sum values on interior nodes.
 561 2013-01-22 06:24:17 <petertodd> gmaxwell: as you were saying yesterday about "just merkelize it!"
 562 2013-01-22 06:24:41 <petertodd> gmaxwell: I'm going to go into work tomorrow and see if I can merkelize a preamp...
 563 2013-01-22 06:25:26 <gmaxwell> That there are O(1) datastructures for UTXO (e.g. a hash table) that don't efficiently merkelize.  (or rather, they do, but your O(1) structure gets an O(log(n)) update cost to update the hashes...
 564 2013-01-22 06:26:16 <gmaxwell> At least part of my excitement about UTXO was an initial belief that it could be done for ~free (just the cost of the hashes and hashing operations) but I see now it means that you'd have to abandon ~O(1) updates to the UTXO set and replace it with something of a categorically inferior computational class.
 565 2013-01-22 06:26:41 <gmaxwell> Since soft-fork-mandated UTXO would make normative the storage of the UTXO set we must think very carefully about that.
 566 2013-01-22 06:26:46 <petertodd> Right, I remember skimming through that huge debate going through every type of self-balancing tree thing under the sun.
 567 2013-01-22 06:27:50 RainbowDashh has joined
 568 2013-01-22 06:27:55 <gmaxwell> Yea, balancing is a big concern but at least a soluable one. I don't think my O(1) vs log() concern is soluable, but I don't know that it matters.
 569 2013-01-22 06:28:26 <petertodd> Now that's O(log(n)) per new txout right?
 570 2013-01-22 06:28:36 <petertodd> O(n*log(n)) gets expensive...
 571 2013-01-22 06:29:22 <gmaxwell> well, m*log(n)— it's not like you're replacing the whole set with every block. :)
 572 2013-01-22 06:29:49 <petertodd> true, better than nothing...
 573 2013-01-22 06:30:01 <gmaxwell> hashtables have annoying corner cases (e.g. resize), and difficulty constructing ones with atomic updates... and for a pretty broad spectrum of utxo sizes O(1) isn't _really_ faster than log(n). Esp if you can do batched updates that take advantage of smart ordering...
 574 2013-01-22 06:30:10 <petertodd> although in that scenario keeping the txout set small becomes even *more* important
 575 2013-01-22 06:30:54 <gmaxwell> well, the merkelizing cost is just a small constant factor. I'm okay with constant factors. Thats just N months under some storage law.
 576 2013-01-22 06:30:59 <petertodd> yeah, but implementing batched updates is ugly when every node has to operate in lock-step to some degree; how do you decide who gets stuck with performing the update?
 577 2013-01-22 06:31:44 <gmaxwell> well, I mean batched updates as in if you're updating N nodes that have a common parent, you replace the parent, so it's not strictly M*log(n).
 578 2013-01-22 06:31:56 <petertodd> ah I see
 579 2013-01-22 06:32:28 <gmaxwell> There are other optimizations. For example— if all nodes have the same data structure, I can make your lookups more efficient by transmitting hints along with transactions: a storage/io+computation vs network/io tradeoff.
 580 2013-01-22 06:32:46 <gmaxwell> (though proving that kind of thing secure ugh)
 581 2013-01-22 06:33:04 <petertodd> Yup... Bitcoin is hard enough to reimplement as it is.
 582 2013-01-22 06:33:17 <gmaxwell> So in any case, I think UTXO is still viable but the idea needs to mature enough so that it's clear that issues like this won't make it a really regretable decision.
 583 2013-01-22 06:34:06 <petertodd> Which is an argument for merge-mining it for awhile, basically just so you can discard implementations that don't work without too bad consequences.
 584 2013-01-22 06:34:15 <gmaxwell> petertodd: yea, well most programers can't write a working bisection search... now you want them to create a _bit_ _exact_ self balancing tree  (or level compress trie)?  and it must work exactly the same with identical tiebreaking and ... uhhhhh.
 585 2013-01-22 06:34:36 <gmaxwell> petertodd: perhaps— or just including it but not enforcing it (and thus not trusting it)
 586 2013-01-22 06:35:46 <petertodd> Do the ugly centralized thing and have Luke mine it, and have some trusted community members run a program to sign the set, although of course that'll actually get used...
 587 2013-01-22 06:36:56 <gmaxwell> I dunno— I think UTXO has fairly low risk of premature use: too hard to implement (or even to understand).. people who don't care about security won't bother they'll SPV.
 588 2013-01-22 06:37:48 <petertodd> of course, in that scenario it won't get tested either
 589 2013-01-22 06:37:50 <CodeShark> I bet many people (if not most) will ultimately just end up selecting (or having selected for them) a list of trusted validation nodes and will do minimal if any serious validation clientside
 590 2013-01-22 06:38:29 <gmaxwell> CodeShark: we fix this by being thoughful and ethical in the software we write and recommend— so that we create systems where good security is free to the user, and they get it by default without asking.
 591 2013-01-22 06:38:42 sturles has quit (Remote host closed the connection)
 592 2013-01-22 06:38:53 <CodeShark> good security is never a default :p
 593 2013-01-22 06:39:09 <gmaxwell> And at least etotheipi_, TD, ThomasV, and the bitcoin reference authors have a clear committment to being thoughtful and making things secure by default.
 594 2013-01-22 06:39:12 <petertodd> Some software has better security by default than others.
 595 2013-01-22 06:39:44 <petertodd> I really like Gavin's statement awhile back about how easy to use, but insecure, software is a disaster.
 596 2013-01-22 06:40:11 <gmaxwell> (Other software authors may or may not— but I can speak from expirence that I've seen all the above take an extra effort to make sure that lazy/ignorant users don't shoot themselves, or to close unlikely certificational weaknesses)
 597 2013-01-22 06:40:38 <jgarzik> I think history has shown that bitcoin is too easy to use, for programmers
 598 2013-01-22 06:40:44 <CodeShark> haha
 599 2013-01-22 06:40:54 <jgarzik> it takes a few hours to set up a poorly secured website that handles money
 600 2013-01-22 06:41:17 <CodeShark> indeed, jgarzik
 601 2013-01-22 06:41:18 <petertodd> jgarzik: the RPC interface should have been written such that you could only interface it with Haskell
 602 2013-01-22 06:41:23 <gmaxwell> Security is generally a lemon market... worse, users reason really poorly about it, it's a lemon market squared.
 603 2013-01-22 06:41:30 <jgarzik> Most programmers just aren't suited for fully securing a website from multi-million dollar motivated theft
 604 2013-01-22 06:42:21 <petertodd> Yeah... look how almost a year later you can still get three-digit first-bit P2SH prefixes...
 605 2013-01-22 06:42:25 <gmaxwell> E.g. You can point a user to a real vulnerablity in a program they're using, get them to really understand it... and a good number will say "so? I haven't heard of anyone getting robbed yet" ... never mind that they could easily be the first and if so all their coin— and coin they hold for other people— will be gone at that point.
 606 2013-01-22 06:43:02 <gmaxwell> jgarzik: To some extent the field of software engineering is not mature enough for what bitcoin and the bitcoin community demand of it.
 607 2013-01-22 06:43:15 <CodeShark> it's worse than that - most people seem to like being able to blame someone else when things go wrong and would prefer not to have the responsibility nor liability
 608 2013-01-22 06:44:05 <petertodd> Heh, there's an argument that I should have told piuk to post a message on the forums about how some hacker stole a bunch of Bitcoins with a new and dangerous exploit from the mixer...
 609 2013-01-22 06:44:22 <petertodd> CodeShark: which leads to expelling harmless white-hats from your school...
 610 2013-01-22 06:45:19 <gmaxwell> fun discussion but I'm out, later.
 611 2013-01-22 06:45:31 <petertodd> later
 612 2013-01-22 06:46:38 <petertodd> You know, there's a parallel between the market for security and trying to convince people to use revision control actually: just like the former, the advantages of the later are too easy to dismiss until you've been bitten, and even then it's too easy to just say you should have been more careful.
 613 2013-01-22 06:47:33 RazielZ has joined
 614 2013-01-22 06:47:50 <CodeShark> forget revision control - just backup :p
 615 2013-01-22 06:48:18 <jgarzik> backup == revision control :)
 616 2013-01-22 06:49:05 <petertodd> heh, what's what my coworkers think; they haven't yet learned that revision control is backups + log messages saying what the fuck the backup actually is...
 617 2013-01-22 06:49:34 <CodeShark> I'd say git is a bit more than that
 618 2013-01-22 06:49:55 <petertodd> CodeShark: hey! I don't want to scare them off just yet!
 619 2013-01-22 06:50:58 <petertodd> see, I do analog electronics design at work, and diff tools for EDA software range from terrible to non-existent, so git degrades to mostly just automated backups
 620 2013-01-22 06:51:11 <petertodd> (merge tools are just non-existent)
 621 2013-01-22 06:53:33 <jgarzik> at least you can bisect
 622 2013-01-22 06:54:42 <petertodd> yes, given enough interns to modify the boards at every step... (or me, my job title has "junior" in it)
 623 2013-01-22 07:00:46 MrTiggr has quit (Ping timeout: 248 seconds)
 624 2013-01-22 07:03:06 freakazoid has quit (Ping timeout: 248 seconds)
 625 2013-01-22 07:07:22 reizuki has quit (Read error: Operation timed out)
 626 2013-01-22 07:15:06 freakazoid has joined
 627 2013-01-22 07:16:34 spaz926 has joined
 628 2013-01-22 07:17:00 spaz926 has quit (Changing host)
 629 2013-01-22 07:17:00 spaz926 has joined
 630 2013-01-22 07:22:31 Guest91877 has quit (Read error: Operation timed out)
 631 2013-01-22 07:33:24 b4epoche has quit (Read error: Operation timed out)
 632 2013-01-22 07:36:08 Guest91877 has joined
 633 2013-01-22 07:36:32 b4epoche has joined
 634 2013-01-22 07:38:39 dvide has quit ()
 635 2013-01-22 07:43:04 <CodeShark> hmm, diff tools for EDA software...
 636 2013-01-22 07:45:15 <CodeShark> diff tools for any other kind of file other than simple text files are rather lacking :)
 637 2013-01-22 07:49:38 jdnavarro has joined
 638 2013-01-22 07:51:23 toffoo has quit ()
 639 2013-01-22 07:52:27 ovidiusoft has joined
 640 2013-01-22 08:00:16 DrHaribo_ has joined
 641 2013-01-22 08:00:25 nus- has quit (Read error: Connection reset by peer)
 642 2013-01-22 08:00:25 nus has joined
 643 2013-01-22 08:00:25 Detritus has quit (Read error: Connection reset by peer)
 644 2013-01-22 08:00:25 DrHaribo has quit (Ping timeout: 276 seconds)
 645 2013-01-22 08:00:26 hopey has quit (Ping timeout: 276 seconds)
 646 2013-01-22 08:00:26 hopey has joined
 647 2013-01-22 08:00:26 nus has quit (Changing host)
 648 2013-01-22 08:00:26 nus has joined
 649 2013-01-22 08:00:36 sturles has joined
 650 2013-01-22 08:12:41 CodesInChaos has joined
 651 2013-01-22 08:24:38 <midnightmagic> CodeShark: image diffing, PDF diffing, pure binary diffs, word/openoffice diffing, it's all been around for a long time. I wouldn't say they're lacking so much as "underutilized"
 652 2013-01-22 08:28:52 yareyare has joined
 653 2013-01-22 08:32:21 DaQatz has quit (Remote host closed the connection)
 654 2013-01-22 08:33:05 grau has quit (Remote host closed the connection)
 655 2013-01-22 08:33:06 freakazoid has quit (Ping timeout: 252 seconds)
 656 2013-01-22 08:33:56 <CodeShark> fair enough
 657 2013-01-22 08:35:28 grau has joined
 658 2013-01-22 08:35:41 grau has quit (Remote host closed the connection)
 659 2013-01-22 08:38:26 valparaiso has quit (Read error: Connection reset by peer)
 660 2013-01-22 08:38:34 jrmithdobbs has quit (Read error: Connection reset by peer)
 661 2013-01-22 08:38:43 jrmithdobbs has joined
 662 2013-01-22 08:39:56 valparaiso has joined
 663 2013-01-22 08:40:56 jgarzik has quit (Read error: Operation timed out)
 664 2013-01-22 08:49:26 Luke-Jr has quit (Excess Flood)
 665 2013-01-22 08:50:48 rdymac has joined
 666 2013-01-22 09:01:48 porquilho has joined
 667 2013-01-22 09:02:40 BTCOxygen has joined
 668 2013-01-22 09:05:21 MC-Eeepc has joined
 669 2013-01-22 09:15:13 rdymac has quit (Ping timeout: 255 seconds)
 670 2013-01-22 09:18:24 TD_ has joined
 671 2013-01-22 09:20:02 rdymac has joined
 672 2013-01-22 09:25:32 nus has quit (Read error: Connection reset by peer)
 673 2013-01-22 09:25:49 nus has joined
 674 2013-01-22 09:31:37 spaz926_ has joined
 675 2013-01-22 09:32:47 spaz926 has quit (Ping timeout: 244 seconds)
 676 2013-01-22 09:38:24 rdymac has quit (Quit: Saliendo)
 677 2013-01-22 09:39:47 t7 has joined
 678 2013-01-22 09:41:35 DrHaribo_ is now known as DrHaribo
 679 2013-01-22 09:42:20 rdymac has joined
 680 2013-01-22 09:45:46 denisx has joined
 681 2013-01-22 09:46:47 zooko has joined
 682 2013-01-22 09:49:00 bitnumus has quit (Read error: Connection reset by peer)
 683 2013-01-22 09:49:46 rdymac has left ("Saliendo")
 684 2013-01-22 09:50:29 rdymac has joined
 685 2013-01-22 09:50:58 rdymac has quit (Remote host closed the connection)
 686 2013-01-22 09:51:13 terryww has quit (Ping timeout: 256 seconds)
 687 2013-01-22 09:53:04 porquilho_ has joined
 688 2013-01-22 09:53:37 porquilho has quit (Ping timeout: 240 seconds)
 689 2013-01-22 09:54:51 bitnumus has joined
 690 2013-01-22 09:55:54 zooko has quit (Remote host closed the connection)
 691 2013-01-22 09:56:29 zooko has joined
 692 2013-01-22 10:07:36 one_zero has quit ()
 693 2013-01-22 10:10:44 rdymac has joined
 694 2013-01-22 10:13:06 daybyter has joined
 695 2013-01-22 10:17:41 sgstair has quit (Read error: Connection reset by peer)
 696 2013-01-22 10:18:03 sgstair has joined
 697 2013-01-22 10:18:04 nus has quit (Read error: Connection reset by peer)
 698 2013-01-22 10:18:26 nus has joined
 699 2013-01-22 10:20:01 da2ce7 has quit (Read error: Connection timed out)
 700 2013-01-22 10:21:26 da2ce7 has joined
 701 2013-01-22 10:21:29 B0g4r7 has quit (Ping timeout: 276 seconds)
 702 2013-01-22 10:26:02 B0g4r7 has joined
 703 2013-01-22 10:35:04 gjs278 has quit (Quit: Konversation terminated!)
 704 2013-01-22 10:35:27 gjs278 has joined
 705 2013-01-22 10:35:46 porquilho_ is now known as porquilho
 706 2013-01-22 10:38:35 <sipa> CodeShark: as long as we depend on BDB for wallets, i think you should try v 4.8 first in your script (as you'll otherwise end up with binaries that make wallets backward incompatible with release binaries)
 707 2013-01-22 10:39:12 <sipa> CodeShark: in fact, you should probably only try 4.8, unless something like a --allow-any-bdb-version is specified
 708 2013-01-22 10:39:45 <CodeShark> hmmm - yes, that's doable. The only thing is that for Ubuntu 12.04, you need a special package
 709 2013-01-22 10:40:08 <CodeShark> apt-get won't quite do
 710 2013-01-22 10:40:15 <sipa> i know
 711 2013-01-22 10:40:30 <sipa> BlueMatt, gavinandresen, gmaxwell: i'm not sure I like that the fact that the filteredblock/tx interaction is so fragile
 712 2013-01-22 10:40:48 <CodeShark> how's this: if they have a newer version than 4.8, it will warn them
 713 2013-01-22 10:41:04 <CodeShark> older version, the check will fail
 714 2013-01-22 10:41:43 <sipa> BlueMatt, gmaxwell, gmaxwell: the cleanest solution would be considering txids inside a filtered block to be equivalent to invs, which includes pushing the relevant txs to the relaycache, making sure they're fetchable 9for a while) using getdata
 715 2013-01-22 10:42:29 <sipa> that doesn't solve the latency issue of course
 716 2013-01-22 10:49:37 int0x27h has quit (Quit: bye)
 717 2013-01-22 10:50:06 terryww has joined
 718 2013-01-22 10:52:34 gjs278 has quit (Remote host closed the connection)
 719 2013-01-22 10:52:55 gjs278 has joined
 720 2013-01-22 10:52:57 int0x27h has joined
 721 2013-01-22 10:54:14 rdymac has quit (Read error: Connection reset by peer)
 722 2013-01-22 10:58:45 rdymac has joined
 723 2013-01-22 11:01:18 ThomasV has quit (Quit: Leaving)
 724 2013-01-22 11:02:08 tonikt has joined
 725 2013-01-22 11:02:41 <CodeShark> sipa: check the configure script now
 726 2013-01-22 11:03:51 <CodeShark> notice that the header directory check and the version check are independent - on linux distros, the header should just be in the /usr/include or /usr/local/include directory or something like that
 727 2013-01-22 11:04:31 <CodeShark> in OS X it's in opt/local/include/db48
 728 2013-01-22 11:04:45 reizuki has joined
 729 2013-01-22 11:04:47 <CodeShark> I'm actually pulling the version number from the header file
 730 2013-01-22 11:04:49 gjs278 has quit (Remote host closed the connection)
 731 2013-01-22 11:05:12 gjs278 has joined
 732 2013-01-22 11:06:43 <sipa> gavinandresen, jgarzik, gmaxwell: blockers for 0.8 imho: better disk space checks, and dealing with I/O errors in leveldb; one idea: adding a fFailed global bool to main, and when set, do not attempt to read/write anything to disk anymore, and do a clean shutdown (which in bitcoind is probably just quitting, but in bitcoin-qt showing some informational error first), and have that flag triggered by diskspace or I/O errors
 733 2013-01-22 11:09:27 spaz926_ is now known as spaz926_|away
 734 2013-01-22 11:09:38 gjs278 has quit (Remote host closed the connection)
 735 2013-01-22 11:10:02 gjs278 has joined
 736 2013-01-22 11:11:43 drizztbsd has joined
 737 2013-01-22 11:12:06 <TD_> sipa: did bdb have those?
 738 2013-01-22 11:12:21 <TD_> sipa: i don't think 0.8 should be blocked by lack of features that 0.7 didn't have
 739 2013-01-22 11:13:07 <sipa> TD_: 0.7 didn't do batch writing
 740 2013-01-22 11:13:15 <TD_> so?
 741 2013-01-22 11:13:15 <sipa> so disk space checks were accurate
 742 2013-01-22 11:13:26 <sipa> the ones we have now are useless
 743 2013-01-22 11:13:38 gjs278 has quit (Remote host closed the connection)
 744 2013-01-22 11:14:01 gjs278 has joined
 745 2013-01-22 11:14:10 <sipa> and there was only one database, and a failure to write to that one caused an uncaught exception
 746 2013-01-22 11:15:14 <sipa> i suppose the fFailed thing is mostly esthetic, and can wait
 747 2013-01-22 11:15:38 <TD_> yeah, so, failure to write terminated the app, just like it does now
 748 2013-01-22 11:15:51 <sipa> no, currently it doesn't cause termination at all
 749 2013-01-22 11:16:02 <TD_> what happens if leveldb runs out of disk space?
 750 2013-01-22 11:16:08 <sipa> it fails to write
 751 2013-01-22 11:16:14 <TD_> the data just vanishes?
 752 2013-01-22 11:16:20 <sipa> and there is no exception thrown
 753 2013-01-22 11:16:22 <CodeShark> the leveldb API doesn't have a way of passing back a write failure error?
 754 2013-01-22 11:16:26 <sipa> sure it does
 755 2013-01-22 11:16:34 <sipa> we just don't check it
 756 2013-01-22 11:16:41 <CodeShark> oh, that's not good :)
 757 2013-01-22 11:16:45 <sipa> or don't propagate it, unsure
 758 2013-01-22 11:17:02 <sipa> in any case, in case of BDB it raised an exception, which caused the program to terminate
 759 2013-01-22 11:17:25 <sipa> now the write just returns failure, which is interpreted higher up as "block failed to connect", resulting in the block being marked invalid
 760 2013-01-22 11:17:31 <sipa> which is obviously wrong behaviour
 761 2013-01-22 11:17:36 <CodeShark> so throw an exception on a write error and in the catch clause call shutdown
 762 2013-01-22 11:17:48 sacredchao has quit (Remote host closed the connection)
 763 2013-01-22 11:17:49 <sipa> that's probably the easiest solution, yes
 764 2013-01-22 11:18:20 sacredchao has joined
 765 2013-01-22 11:20:51 <TD_> sipa: i'd also like to see matts bloom filtering change merged and the notfound message. they're so small and simple, and it'd hold up important fixes on the bitcoinj side to ship without them
 766 2013-01-22 11:22:25 <TD_> anyway
 767 2013-01-22 11:22:26 * TD_ -> office
 768 2013-01-22 11:22:28 TD_ has quit (Quit: TD_)
 769 2013-01-22 11:32:15 rdymac has quit (Quit: This computer has gone to sleep)
 770 2013-01-22 11:41:37 <CodeShark> we should have similar version checks for other libraries
 771 2013-01-22 11:42:04 <CodeShark> what are the minimum SSL and boost library requirements?
 772 2013-01-22 11:44:21 zip__ has quit (Ping timeout: 245 seconds)
 773 2013-01-22 11:47:27 t7` has joined
 774 2013-01-22 11:47:50 jdnavarro has quit (Ping timeout: 272 seconds)
 775 2013-01-22 11:48:31 b4epoche has quit (Ping timeout: 256 seconds)
 776 2013-01-22 11:50:13 t7 has quit (Ping timeout: 256 seconds)
 777 2013-01-22 11:51:24 b4epoche has joined
 778 2013-01-22 11:56:10 da2ce7 has quit (Read error: Connection timed out)
 779 2013-01-22 11:57:39 da2ce7 has joined
 780 2013-01-22 11:58:56 Cylta has joined
 781 2013-01-22 12:10:41 B0g4r7 has quit (Ping timeout: 276 seconds)
 782 2013-01-22 12:14:18 t7` is now known as t7
 783 2013-01-22 12:15:41 B0g4r7 has joined
 784 2013-01-22 12:18:23 tigger0 has quit (Ping timeout: 252 seconds)
 785 2013-01-22 12:18:39 RainbowDashh has quit (Ping timeout: 244 seconds)
 786 2013-01-22 12:22:18 dparrish has quit (Ping timeout: 246 seconds)
 787 2013-01-22 12:25:44 t7 has quit (Quit: Leaving)
 788 2013-01-22 12:25:49 daybyter has quit (Quit: Konversation terminated!)
 789 2013-01-22 12:28:15 dparrish has joined
 790 2013-01-22 12:28:55 mariusursache has joined
 791 2013-01-22 12:30:08 <mariusursache> newbie question: how does the network know that a wallet (address) is from testnet or not? (bitcoind verifyaddress xxx says false if ran with -testnet)
 792 2013-01-22 12:30:17 t7 has joined
 793 2013-01-22 12:30:30 jdnavarro has joined
 794 2013-01-22 12:32:36 sgornick_ has joined
 795 2013-01-22 12:34:23 <CodeShark> the addresses use different version numbers - so they start with a different character
 796 2013-01-22 12:35:08 <mariusursache> so to create an address for testnet (in a program), I need to generate it using a different version that's used only on testnet?
 797 2013-01-22 12:35:19 nus- has joined
 798 2013-01-22 12:35:42 <CodeShark> you want to use a separate wallet anyhow
 799 2013-01-22 12:35:42 nus has quit (Read error: Connection reset by peer)
 800 2013-01-22 12:35:49 <CodeShark> so yes
 801 2013-01-22 12:36:14 dparrish has quit (Read error: Operation timed out)
 802 2013-01-22 12:36:59 <CodeShark> there is currently no way to load wallets for both networks concurrently with the satoshi client
 803 2013-01-22 12:38:11 <CodeShark> I'm trying to build bitcoind under gentoo and am getting the following error:
 804 2013-01-22 12:38:16 <mariusursache> I'm trying to connect testnet (bitcoin-qt) with https://github.com/bitcoinjs/bitcoinjs-gui, and I managed to figure out that the wallet generated in the js client is not valid on bitcoind
 805 2013-01-22 12:38:21 <CodeShark>  /bitcoin/src/util.cpp:1064: undefined reference to `boost::filesystem3::path::operator/=(char const*)'
 806 2013-01-22 12:38:46 <mariusursache> do you have boost (boost-devel) installed?
 807 2013-01-22 12:39:20 <CodeShark> I should - my detection utility tells me I do
 808 2013-01-22 12:40:38 Luke-Jr has joined
 809 2013-01-22 12:41:23 <CodeShark> searching through packages...
 810 2013-01-22 12:42:15 <CodeShark> I did an emerge -s boost and am seeing dev-libs/boost
 811 2013-01-22 12:42:41 <CodeShark> the header files and library files are certainly there and the header files say version 1.49
 812 2013-01-22 12:47:13 <Luke-Jr> CodeShark: …?
 813 2013-01-22 12:47:31 <CodeShark> I'm not a big gentoo user...
 814 2013-01-22 12:47:59 <Luke-Jr> is there a question I missed? :p
 815 2013-01-22 12:48:07 <CodeShark> but when I check my boost version via eselect, I see boost-1.42, 1.46, and 1.48
 816 2013-01-22 12:48:21 <CodeShark> but the header for boost says 1_49
 817 2013-01-22 12:48:33 <CodeShark> and when I try to build bitcoind, I get a linker error
 818 2013-01-22 12:48:36 <CodeShark>  /bitcoin/src/util.cpp:1064: undefined reference to `boost::filesystem3::path::operator/=(char const*)'
 819 2013-01-22 12:48:46 <Luke-Jr> boost hasn't used eselect for a month or so now..
 820 2013-01-22 12:49:07 <CodeShark> hmmm - well, I'm still using an old version of gentoo I had set up months ago
 821 2013-01-22 12:49:21 <CodeShark> and just dusting the cobwebs off it
 822 2013-01-22 12:49:26 <CodeShark> so what's the new way of doing things?
 823 2013-01-22 12:49:32 <Luke-Jr> CodeShark: you might find it handy to update, and look at the current bitcoind ebuild
 824 2013-01-22 12:49:42 MrTiggr has joined
 825 2013-01-22 12:49:49 <Luke-Jr> in /usr/portage/net-p2p/bitcoind/bitcoind-0.7.2.ebuild
 826 2013-01-22 12:50:54 <Luke-Jr> brb
 827 2013-01-22 12:51:12 <CodeShark> is that a source repository? or a binary?
 828 2013-01-22 12:53:26 Dyaheon has quit ()
 829 2013-01-22 12:53:59 bitnumus is now known as bitcoinqueen
 830 2013-01-22 12:54:43 Dyaheon has joined
 831 2013-01-22 12:55:20 bitcoinqueen is now known as bitnumus
 832 2013-01-22 12:58:23 bitafterbit has joined
 833 2013-01-22 13:01:47 <CodeShark> my god it's ridiculous...I do an emerge portage and it goes ahead and checks every single fricking little standard C library function
 834 2013-01-22 13:01:56 zooko has quit (Ping timeout: 272 seconds)
 835 2013-01-22 13:02:02 dipho has joined
 836 2013-01-22 13:02:03 WolfAlex_ has joined
 837 2013-01-22 13:02:28 <CodeShark> and type
 838 2013-01-22 13:04:37 WolfAlex has quit (Ping timeout: 240 seconds)
 839 2013-01-22 13:06:07 GMP has quit (Read error: Connection reset by peer)
 840 2013-01-22 13:07:39 agricocb has quit (Quit: Leaving.)
 841 2013-01-22 13:08:45 <SomeoneWeird> loll
 842 2013-01-22 13:09:44 dparrish has joined
 843 2013-01-22 13:10:31 <CodeShark> but now the build works! :)
 844 2013-01-22 13:12:31 yareyare has quit (Quit: \o)
 845 2013-01-22 13:20:16 tonikt has quit (Read error: Connection reset by peer)
 846 2013-01-22 13:25:21 BTCOxygen has joined
 847 2013-01-22 13:26:00 BTCOxygen has quit (Ping timeout: 272 seconds)
 848 2013-01-22 13:26:44 denisx has quit (Quit: denisx)
 849 2013-01-22 13:39:10 BTCOxygen has quit (1!~kvirc@68.233.247.240|Ping timeout: 248 seconds)
 850 2013-01-22 13:39:56 Cylta has quit (Ping timeout: 272 seconds)
 851 2013-01-22 13:53:57 t7 has quit (Read error: Connection reset by peer)
 852 2013-01-22 13:54:25 t7 has joined
 853 2013-01-22 14:00:50 sgornick_ has quit (Ping timeout: 272 seconds)
 854 2013-01-22 14:00:55 ThomasV has joined
 855 2013-01-22 14:03:49 datagutt has joined
 856 2013-01-22 14:05:23 bitnumus_ has joined
 857 2013-01-22 14:22:26 agricocb has joined
 858 2013-01-22 14:23:05 CodeShark has quit (Ping timeout: 256 seconds)
 859 2013-01-22 14:25:04 zooko has joined
 860 2013-01-22 14:28:04 imsaguy has quit (Ping timeout: 272 seconds)
 861 2013-01-22 14:29:38 CodeShark has joined
 862 2013-01-22 14:30:32 Cusipzzz has quit (Ping timeout: 264 seconds)
 863 2013-01-22 14:34:47 imsaguy has joined
 864 2013-01-22 14:35:02 Dyaheon has quit ()
 865 2013-01-22 14:39:25 rdponticelli has joined
 866 2013-01-22 14:39:32 Cusipzzz has joined
 867 2013-01-22 14:39:56 Cusipzzz is now known as Guest85183
 868 2013-01-22 14:41:39 Dyaheon has joined
 869 2013-01-22 14:50:04 <BlueMatt> sipa: it may be a bit late for that, though I still prefer the latency gains of auto-relaying the relevant ones
 870 2013-01-22 14:50:14 <BlueMatt> sipa: and Im not so sure that the interaction is so "fragile"
 871 2013-01-22 15:07:01 <sipa> BlueMatt: yes, not saying it should be changed; just mentioning my concern :)
 872 2013-01-22 15:07:06 <sipa> BlueMatt: see pullreq page
 873 2013-01-22 15:07:58 zooko has quit (Ping timeout: 272 seconds)
 874 2013-01-22 15:08:40 <BlueMatt> sipa: just mentioning that i dont really share the concern :)
 875 2013-01-22 15:14:10 pusle has joined
 876 2013-01-22 15:19:10 reizuki has quit (Ping timeout: 248 seconds)
 877 2013-01-22 15:22:08 contour has joined
 878 2013-01-22 15:34:21 freakazoid has joined
 879 2013-01-22 15:37:14 rdponticelli has quit (Quit: No Ping reply in 180 seconds.)
 880 2013-01-22 15:37:20 Guest85183 has quit (Quit: leaving)
 881 2013-01-22 15:39:02 nus- has quit (Ping timeout: 276 seconds)
 882 2013-01-22 15:40:09 daybyter has joined
 883 2013-01-22 15:40:20 rdponticelli has joined
 884 2013-01-22 15:40:55 LargoG has joined
 885 2013-01-22 15:42:07 contour has quit (Quit: Page closed)
 886 2013-01-22 15:43:57 Descry has joined
 887 2013-01-22 15:46:53 freakazoid has quit (Ping timeout: 248 seconds)
 888 2013-01-22 15:48:04 tcatm has quit (Quit: No Ping reply in 180 seconds.)
 889 2013-01-22 15:48:21 tcatm has joined
 890 2013-01-22 15:48:21 tcatm has quit (Changing host)
 891 2013-01-22 15:48:21 tcatm has joined
 892 2013-01-22 15:49:23 Cylta has joined
 893 2013-01-22 15:51:11 nus has joined
 894 2013-01-22 15:51:53 ThomasV has quit (Quit: Leaving)
 895 2013-01-22 15:52:38 nus- has joined
 896 2013-01-22 15:52:40 EPiSKiNG- has quit ()
 897 2013-01-22 15:53:22 <sipa> gmaxwell: seems you're right about gentoo users :)
 898 2013-01-22 15:53:49 FredEE has joined
 899 2013-01-22 15:55:08 MrTiggr has quit (Ping timeout: 244 seconds)
 900 2013-01-22 15:55:56 nus has quit (Ping timeout: 276 seconds)
 901 2013-01-22 15:57:26 <Luke-Jr> sipa: ?
 902 2013-01-22 15:59:35 valparaiso has quit (Quit: valparaiso)
 903 2013-01-22 15:59:47 <sipa> Luke-Jr: see latest issue
 904 2013-01-22 15:59:55 <sipa> #2196
 905 2013-01-22 16:02:47 Descry has quit (Quit: Leaving)
 906 2013-01-22 16:03:30 b4epoche has quit (Ping timeout: 246 seconds)
 907 2013-01-22 16:03:52 nus- has quit (Read error: Connection reset by peer)
 908 2013-01-22 16:03:54 nus has joined
 909 2013-01-22 16:04:25 FredEE has quit (Quit: FredEE)
 910 2013-01-22 16:06:18 b4epoche has joined
 911 2013-01-22 16:08:52 impulse- has quit (Quit: leaving)
 912 2013-01-22 16:09:32 impulse has joined
 913 2013-01-22 16:09:39 impulse is now known as impulse-
 914 2013-01-22 16:13:07 sytse_ has joined
 915 2013-01-22 16:13:07 sytse_ has quit (Client Quit)
 916 2013-01-22 16:14:35 khalahan has quit (Ping timeout: 248 seconds)
 917 2013-01-22 16:30:09 nus has quit (Read error: Connection reset by peer)
 918 2013-01-22 16:30:28 nus has joined
 919 2013-01-22 16:37:49 benkay has joined
 920 2013-01-22 16:42:22 swappermall_ has joined
 921 2013-01-22 16:49:08 cosurgi has quit (Ping timeout: 264 seconds)
 922 2013-01-22 17:02:16 t7 has quit (Quit: Leaving)
 923 2013-01-22 17:06:58 da2ce7_d has joined
 924 2013-01-22 17:06:59 torsthaldo has quit (Read error: Connection reset by peer)
 925 2013-01-22 17:07:27 vigilyn has joined
 926 2013-01-22 17:07:32 coinmutt has joined
 927 2013-01-22 17:08:00 torsthaldo has joined
 928 2013-01-22 17:09:16 da2ce7 has quit (Ping timeout: 252 seconds)
 929 2013-01-22 17:11:44 pusle has quit ()
 930 2013-01-22 17:24:47 terryww has quit (Ping timeout: 272 seconds)
 931 2013-01-22 17:31:30 HM has joined
 932 2013-01-22 17:31:44 reizuki has joined
 933 2013-01-22 17:31:44 reizuki has quit (Changing host)
 934 2013-01-22 17:31:44 reizuki has joined
 935 2013-01-22 17:31:49 CodeShark has quit (Remote host closed the connection)
 936 2013-01-22 17:31:59 <HM> Anyone here an expert on scripts?
 937 2013-01-22 17:32:12 <sipa> bitcoin scripts?
 938 2013-01-22 17:32:15 <HM> Indeed
 939 2013-01-22 17:32:40 <SomeoneWeird> if($balance > 0) { send_coins($someoneweird); }
 940 2013-01-22 17:32:54 <HM> I'm wondering what this means on the bitcoin.it wiki: " Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them."
 941 2013-01-22 17:33:05 agricocb has quit (Quit: Leaving.)
 942 2013-01-22 17:33:09 <HM> it seems self explanatory, but to me this means you can't broadcast nonstandard scripts?
 943 2013-01-22 17:33:57 <sipa> you can broadcast them, but they won't be relayed :)
 944 2013-01-22 17:34:14 <gavinandresen> If you want to experiment with non-standard scripts, use the -testnet.  It relays and mines them.
 945 2013-01-22 17:35:00 <HM> right
 946 2013-01-22 17:35:34 <HM> so all the fancy contract stuff is basically a non-starter for the foreseeable future
 947 2013-01-22 17:35:51 <gavinandresen> no, a lot of the fancy contract stuff can be done with existing script forms
 948 2013-01-22 17:36:34 <HM> how so?
 949 2013-01-22 17:36:50 <gavinandresen> … and if you've got a great use case for fancy contract stuff that requires a new type of script, then prototype it on test net and then lobby for a new 'standard' transaction type.
 950 2013-01-22 17:37:30 <HM> what consitutes a standard script?
 951 2013-01-22 17:37:40 <HM> i'm looking at CTransaction::IsStandard right now
 952 2013-01-22 17:38:35 <gavinandresen> HM: see the Templates in script.cpp, Solver() function
 953 2013-01-22 17:39:53 <HM> ah sweet
 954 2013-01-22 17:41:15 rdponticelli has quit (Remote host closed the connection)
 955 2013-01-22 17:41:55 JZavala has joined
 956 2013-01-22 17:42:42 <HM> so basically you're limited to 1 or N sig transactions
 957 2013-01-22 17:42:54 rdponticelli has joined
 958 2013-01-22 17:43:24 <gavinandresen> yes
 959 2013-01-22 17:43:41 <gavinandresen> … where N <= 3
 960 2013-01-22 17:44:28 <Luke-Jr> HM: also, you can connect directly to the Eligius mining pool to get non-standard transactions mined
 961 2013-01-22 17:44:43 <Luke-Jr> (with an appropriate fee)
 962 2013-01-22 17:45:02 <HM> that's the "accepted if they are in a block" bit, right?
 963 2013-01-22 17:45:17 <HM> presumably that means you could be waiting a while
 964 2013-01-22 17:45:29 <sipa> yes, non-standardness rules only apply to relaying
 965 2013-01-22 17:45:35 <Luke-Jr> a few days at worst
 966 2013-01-22 17:45:43 <sipa> if it's a valid script, it is acceptable when in a block
 967 2013-01-22 17:45:47 <gavinandresen> yes.  Again, if you want to experiment, use test net.  If you have a compelling use-case, then adding new 'standard' transactions is something we've done before and is fairly easy.
 968 2013-01-22 17:46:24 t7 has joined
 969 2013-01-22 17:48:57 <HM> i think i can get away with OP_CHECKMULTISIG
 970 2013-01-22 17:49:39 <HM> i need to get my head around the specifics of signature checking
 971 2013-01-22 17:50:48 <HM> is there a transaction emulator out there other than testnet? something that lets you put rawtx's in in pairs and see if you can spend?
 972 2013-01-22 17:51:01 <HM> just offline
 973 2013-01-22 17:51:41 Hashdog has joined
 974 2013-01-22 17:51:46 jdnavarro has quit (Ping timeout: 256 seconds)
 975 2013-01-22 17:53:12 <gavinandresen> the signrawtransaction RPC will tell you if it thinks the transaction is fully signed….  but there is no "check this transaction and tell me if its inputs are unspent etc etc etc" RPC call.
 976 2013-01-22 17:53:12 runeks has joined
 977 2013-01-22 17:55:49 <HM> hmm
 978 2013-01-22 17:56:01 <gavinandresen> sipa: I'm testing the native leveldb port on winxp, and it does seem to use less memory (47MB to sync test net chain versus 58MB).
 979 2013-01-22 17:57:27 benkay has quit (Quit: Lost terminal)
 980 2013-01-22 17:57:35 <gavinandresen> sipa:  … umm, except I'm getting an error on shutdown….
 981 2013-01-22 17:57:54 <sipa> which?
 982 2013-01-22 17:58:48 <gavinandresen> sipa: http://pastebin.com/BVVB3Mt5
 983 2013-01-22 18:03:27 <sipa> gavinandresen: that's weird... seems like some problem with winsock not being initialized, but that would mean all network stuff should fail
 984 2013-01-22 18:04:18 <gavinandresen> sipa: same error on exit with git HEAD
 985 2013-01-22 18:04:56 <HM> Ok one more question. All the SIGHASH_* variants are allowed on the standard network right? and will be relayed?
 986 2013-01-22 18:04:56 <gavinandresen> exception happens AFTER 'Bitcoin exited' in debug.log, so it is a global destructor problem....
 987 2013-01-22 18:05:57 <gavinandresen> HM: yes, all the SIGHASH_* variants work.  Theoretically....
 988 2013-01-22 18:06:06 <HM> lol...why theoretically?
 989 2013-01-22 18:06:12 <sipa> gavinandresen: maybe WS is being uninitialized at shutdown somehow in a global destructor, and the RPC shutdown happens after that?
 990 2013-01-22 18:06:15 <gavinandresen> They haven't been well-tested
 991 2013-01-22 18:07:23 <HM> of course
 992 2013-01-22 18:07:57 <gavinandresen> sipa: http://pastebin.com/gNnaQ6Gr   is end of debug.log running git HEAD
 993 2013-01-22 18:08:28 <gavinandresen> sipa: the ipcThread exited makes me think it isn't RPC-related....
 994 2013-01-22 18:09:12 <sipa> pfff
 995 2013-01-22 18:10:16 <gavinandresen> sipa: if you don't see anything obvious, I'll compile a debug version and run in gdb to find out exactly what is crashing
 996 2013-01-22 18:11:54 toffoo has joined
 997 2013-01-22 18:13:47 <gavinandresen> HM: re: transaction emulator:  testnet-in-a-box is very useful for experimenting/testing. If you've got even a single under-powered GPU you can mine a block or two a minute on a testnet-in-a-box setup.
 998 2013-01-22 18:17:17 <HM> hmm not sure if that's what i want
 999 2013-01-22 18:17:38 <HM> i just want to be able to load 2 raw transactions in to memory and simular whether #2 can spend #1
1000 2013-01-22 18:18:02 <HM> i don't care about the blockchain side of things atm
1001 2013-01-22 18:23:21 juchmis has joined
1002 2013-01-22 18:23:27 <gavinandresen> HM: see https://en.bitcoin.it/wiki/Raw_Transactions#Validate_a_transaction_without_broadcasting_it   for a partial sanity check
1003 2013-01-22 18:24:02 sgstair has quit (Read error: Connection reset by peer)
1004 2013-01-22 18:24:20 sgstair has joined
1005 2013-01-22 18:26:22 <HM> yeah i think i'm just going to have to play
1006 2013-01-22 18:29:11 terryww has joined
1007 2013-01-22 18:30:35 freakazoid has joined
1008 2013-01-22 18:32:58 blishchrot has joined
1009 2013-01-22 18:34:37 JZavala has quit (Ping timeout: 240 seconds)
1010 2013-01-22 18:35:12 coinmutt has quit (Ping timeout: 245 seconds)
1011 2013-01-22 18:37:40 drizztbsd has quit (Remote host closed the connection)
1012 2013-01-22 18:43:21 jdnavarro has joined
1013 2013-01-22 18:43:37 jdnavarro has quit (Remote host closed the connection)
1014 2013-01-22 18:57:58 rdponticelli has quit (Remote host closed the connection)
1015 2013-01-22 19:01:40 jurov has quit (Ping timeout: 246 seconds)
1016 2013-01-22 19:01:50 rdponticelli has joined
1017 2013-01-22 19:02:37 jurov has joined
1018 2013-01-22 19:03:50 <lianj> gavinandresen: is doing http://paste.mhanne.net/p/96073634b9fe8e9d98e1d8799b0edb3664ccbeb9?hl=diff evil for testnet-in-a-box tests when you want to mine with cpu and faster?
1019 2013-01-22 19:04:03 grau has joined
1020 2013-01-22 19:04:13 knotwork_ has quit (Read error: Connection reset by peer)
1021 2013-01-22 19:05:16 knotwork_ has joined
1022 2013-01-22 19:05:21 knotwork_ has quit (Read error: Connection reset by peer)
1023 2013-01-22 19:06:16 knotwork_ has joined
1024 2013-01-22 19:07:03 FredEE has joined
1025 2013-01-22 19:11:03 <dub> so, I has bad disk?
1026 2013-01-22 19:11:07 <dub> ERROR: bool CTransaction::ReadFromDisk(CDiskTxPos, FILE**)() : deserialize or I/O error
1027 2013-01-22 19:11:35 <dub> initial sync is stuck on a block
1028 2013-01-22 19:14:27 Cylta has quit (Ping timeout: 256 seconds)
1029 2013-01-22 19:17:38 <sipa> dub: or a bad blkindex.dat
1030 2013-01-22 19:17:53 <sipa> which refers to a position in a block file that isn't available
1031 2013-01-22 19:18:03 <gavinandresen> lianj: if you're in a testnet-in-a-box, then go nuts and do whatever you like.
1032 2013-01-22 19:18:05 Detritus has joined
1033 2013-01-22 19:18:38 <dub> sipa: gah I'll try another sync
1034 2013-01-22 19:18:48 <sipa> dub: which version?
1035 2013-01-22 19:19:11 <dub> the latest binary on bitcoin.org, cant ask it
1036 2013-01-22 19:19:49 <dub> oh, says v0.7.2-beta in debug.log
1037 2013-01-22 19:19:57 <lianj> gavinandresen: just saying, do that need a gpu to mine a block in 30 on that testnet-in-a-box then
1038 2013-01-22 19:19:58 mariusursache has quit (Quit: mariusursache)
1039 2013-01-22 19:20:37 <gavinandresen> lianj: parse sentence not able to am i
1040 2013-01-22 19:20:55 <sipa> s/do/does/
1041 2013-01-22 19:22:41 <gavinandresen> sipa:  still no luck tracking down the crash-on-exit; after getting a working mingw32 gdb on my XP VM, it doesn't give me a useful stack trace.
1042 2013-01-22 19:23:11 daybyter has quit (Quit: Konversation terminated!)
1043 2013-01-22 19:23:35 <gavinandresen> sipa: while I was doing that, I continued a full-chain block sync to look at memory usage, and it looks OK so far (190MB used, but it hasn't hit block 210,000 yet)
1044 2013-01-22 19:25:12 <gmaxwell> dub: or you ran out of space.
1045 2013-01-22 19:26:54 <gavinandresen> sipa:  by the way… good news on run-out-of-disk-space: I accidentally tested that, too.  VM ran out of disk space and bitcoin exited.  I copied the datadir to a bigger disk, and sync continued where it left off.
1046 2013-01-22 19:28:29 <Diablo-D3> gavinandresen: it didnt corrupt it? good
1047 2013-01-22 19:29:56 <sipa> gavinandresen: gmaxwell has had a different experience, where the out of disk space caused a correct block to be considered invalid, and the chain it was in became marked invalid (and *that* write did make it to disk)
1048 2013-01-22 19:30:16 TD has joined
1049 2013-01-22 19:30:25 <sipa> and imho, there is no reason why the code would prevent such a thing from happening
1050 2013-01-22 19:31:07 <gavinandresen> ok.  I guess I got lucky.
1051 2013-01-22 19:32:08 CodeShark has joined
1052 2013-01-22 19:32:08 CodeShark has quit (Read error: Connection reset by peer)
1053 2013-01-22 19:32:34 reizuki has quit (Ping timeout: 252 seconds)
1054 2013-01-22 19:32:39 <gmaxwell> sipa: FWIW, I tested three out-of-space events with that small patch to not mark it invalid on the write fail, and it has recovered.
1055 2013-01-22 19:35:15 <sipa> gmaxwell: good, so it really is just that
1056 2013-01-22 19:35:55 <sipa> so the fast fix is make leveldb I/O errors cause an exception to be thrown, that will kill the entire application
1057 2013-01-22 19:38:01 reizuki has joined
1058 2013-01-22 19:38:01 reizuki has quit (Changing host)
1059 2013-01-22 19:38:01 reizuki has joined
1060 2013-01-22 19:40:06 swappermall__ has joined
1061 2013-01-22 19:46:42 agricocb has joined
1062 2013-01-22 19:53:54 reizuki has quit (Ping timeout: 252 seconds)
1063 2013-01-22 19:55:30 dvide has joined
1064 2013-01-22 19:56:13 D34TH has joined
1065 2013-01-22 19:56:13 D34TH has quit (Changing host)
1066 2013-01-22 19:56:13 D34TH has joined
1067 2013-01-22 19:59:27 safra has quit (Ping timeout: 248 seconds)
1068 2013-01-22 20:13:31 gjs278 has quit (Remote host closed the connection)
1069 2013-01-22 20:13:53 gjs278 has joined
1070 2013-01-22 20:14:15 khalahan has joined
1071 2013-01-22 20:16:05 datagutt has quit (Quit: kthxbai)
1072 2013-01-22 20:18:30 b4epoche has quit (Ping timeout: 245 seconds)
1073 2013-01-22 20:21:40 b4epoche has joined
1074 2013-01-22 20:23:28 safra has joined
1075 2013-01-22 20:25:38 spaz926_ is now known as away!~spaz926@69.162.111.50|spaz926_
1076 2013-01-22 20:25:44 spaz926_ is now known as spaz926
1077 2013-01-22 20:25:44 spaz926 has quit (Changing host)
1078 2013-01-22 20:25:44 spaz926 has joined
1079 2013-01-22 20:29:24 <TD> gmaxwell, sipa: leveldb 1.9 has a bugfix for out of disk space conditions
1080 2013-01-22 20:29:31 porquilho has quit ()
1081 2013-01-22 20:30:43 Diapolo has joined
1082 2013-01-22 20:31:00 <Diapolo> good evening
1083 2013-01-22 20:33:32 <HM> so SIGHASH_NONE is basically a blank check for a fixed amount, right?
1084 2013-01-22 20:33:36 <HM> good evening
1085 2013-01-22 20:34:19 spaz926_ has joined
1086 2013-01-22 20:35:55 spaz926_ has quit (Remote host closed the connection)
1087 2013-01-22 20:36:14 owowo has joined
1088 2013-01-22 20:36:17 spaz926_ has joined
1089 2013-01-22 20:36:24 <Diablo-D3> Diapolo: you know what I find funny?
1090 2013-01-22 20:36:52 <Diablo-D3> both of us did a lot of work to try to improve opencl performance
1091 2013-01-22 20:36:59 <Diablo-D3> in about 6 months, that work will not matter
1092 2013-01-22 20:37:19 spaz926 has quit (Disconnected by services)
1093 2013-01-22 20:37:22 spaz926_ is now known as spaz926
1094 2013-01-22 20:37:23 spaz926 has quit (Changing host)
1095 2013-01-22 20:37:23 spaz926 has joined
1096 2013-01-22 20:38:06 <Diapolo> Diablo-D3: Why? ASICs will be the only profitable mining solution?
1097 2013-01-22 20:38:15 <Diablo-D3> yes
1098 2013-01-22 20:38:36 <Diablo-D3> or rather, asics will spike the difficulty and make all other solutions far less profitable
1099 2013-01-22 20:38:43 <Diablo-D3> I believe FPGAs will hang on for awhile
1100 2013-01-22 20:38:45 <Diapolo> Well at least I had a whole lot of fun working on that part :). I learned much about OpenCL and micro-optimsations ^^.
1101 2013-01-22 20:38:59 <Diablo-D3> I had less fun than you
1102 2013-01-22 20:39:01 <sipa> TD: interesting, I didn't know about 1.8-1.9 yet
1103 2013-01-22 20:39:07 <sipa> TD: the change seems very small
1104 2013-01-22 20:39:10 <Diapolo> Diapolo-D3: y?
1105 2013-01-22 20:39:12 <TD> yes
1106 2013-01-22 20:39:14 <TD> it's one bugfix
1107 2013-01-22 20:39:15 <Diapolo> LOL ^^ I wrote my name
1108 2013-01-22 20:39:21 <Diapolo> sorry ;)
1109 2013-01-22 20:39:21 <Diablo-D3> lol I am not a diapolo :<
1110 2013-01-22 20:39:28 Diablo-D3 is now known as Diapolo-D3
1111 2013-01-22 20:39:31 <Diapolo-D3> hurrrrrrrrrrr
1112 2013-01-22 20:39:34 Diapolo-D3 is now known as Diablo-D3
1113 2013-01-22 20:39:43 <Diapolo> that really will confuse people even more ^^
1114 2013-01-22 20:39:49 <Diablo-D3> I had my nick first =P
1115 2013-01-22 20:39:51 <Diablo-D3> anyhow
1116 2013-01-22 20:40:01 <Diablo-D3> I spent more time swearing at AMD's shader compiler than anything
1117 2013-01-22 20:40:11 <Diablo-D3> combined with "why the fuck does this even work"
1118 2013-01-22 20:40:55 <Diapolo> Diablo-D3: I was surprised quite often too ^^ it was not that logical at all sometimes
1119 2013-01-22 20:41:05 <Diablo-D3> its logical if you understand compiler design
1120 2013-01-22 20:41:13 <Diablo-D3> AMD's compiler does not use SSA tree parsing
1121 2013-01-22 20:41:34 <Diablo-D3> however, building an SSA preoptimizer does infact work
1122 2013-01-22 20:41:56 <Diablo-D3> my most recent version of my kernel is the output of a pretty horrible perl script I wrote
1123 2013-01-22 20:42:13 <Diablo-D3> that whole entire thing took me 3 days of 16 hour a day work
1124 2013-01-22 20:42:21 <Diablo-D3> I never want to see the inside of my kernel again
1125 2013-01-22 20:42:25 <Diapolo> Diablo-D3: I stopped working with my kernel stuff when I started getting interessted in the client itself ;)
1126 2013-01-22 20:42:40 <Diablo-D3> I mean, yes, I was paid well to do the optimizations
1127 2013-01-22 20:42:43 <Diablo-D3> but dear god
1128 2013-01-22 20:42:55 <Diapolo> Diablo-D3: It was no profitable thing for me at all ... never.
1129 2013-01-22 20:43:10 <Diablo-D3> ahh, well, everyone wanted GCN support in DM
1130 2013-01-22 20:43:17 <Diablo-D3> so everyone donated a lot of bitcoins for it
1131 2013-01-22 20:43:21 <Diablo-D3> and thus, it happened
1132 2013-01-22 20:43:59 <Diapolo> Diablo-D3: I don't care now :) I have fun improving things and currently I'm not even mining anymore.
1133 2013-01-22 20:44:11 da2ce7_d has quit (Read error: Connection reset by peer)
1134 2013-01-22 20:44:13 <Diablo-D3> Ill probably quit mining next year
1135 2013-01-22 20:44:16 <Diablo-D3> well, gpu mining
1136 2013-01-22 20:44:27 <Diablo-D3> Ive been spending most of my time recently working on my own programming language
1137 2013-01-22 20:44:44 PhantomSpark has joined
1138 2013-01-22 20:44:56 <Diapolo> Diablo-D3: How is it called :-P?
1139 2013-01-22 20:44:57 <Scrat> just dont name it D3
1140 2013-01-22 20:45:11 <Diapolo> you will get sued by Blizzard I guess
1141 2013-01-22 20:45:29 da2ce7_d has joined
1142 2013-01-22 20:45:39 <Diablo-D3> its called Seaking
1143 2013-01-22 20:46:08 <Diablo-D3> Scrat: naming it D3 would be confusing because the JS graphing library is named D3
1144 2013-01-22 20:46:17 <Scrat> yep indeed
1145 2013-01-22 20:47:35 <Diablo-D3> Seaking is named after the Sikorsky SH-3 helicopter, famous for being the current Marine One fleet and Mercury/Apollo era space capsule retrieval
1146 2013-01-22 20:48:54 <Scrat> remember the moment in that epic documentary when they lost the capsule?
1147 2013-01-22 20:49:00 <Scrat> SH-3 saved their ass there
1148 2013-01-22 20:49:22 <Scrat> because it was built like a tank ;p
1149 2013-01-22 20:49:36 <Diablo-D3> I named it Seaking because its the language you want to use after coming back from outerspace
1150 2013-01-22 20:49:50 * Diablo-D3 stares at python, ruby, haskell, etc
1151 2013-01-22 20:50:01 agricocb has quit (Quit: Leaving.)
1152 2013-01-22 20:51:41 <Diapolo> not my languages
1153 2013-01-22 20:52:29 <Scrat> Diablo-D3 what do you think of Go?
1154 2013-01-22 20:52:37 <Diablo-D3> I dont like it
1155 2013-01-22 20:52:43 <Diablo-D3> I wanted to like it
1156 2013-01-22 20:52:48 <Diablo-D3> especially with whos working on it
1157 2013-01-22 20:52:59 <Diablo-D3> but theres just something rather wrong with how they designed the whole thing
1158 2013-01-22 20:53:04 <Diablo-D3> especially with how parallel code works
1159 2013-01-22 20:53:17 <Diablo-D3> its repeating the mistakes of C threading just in new clothes
1160 2013-01-22 20:53:32 <HM> you don't like Goroutines?
1161 2013-01-22 20:53:40 <Diablo-D3> nope
1162 2013-01-22 20:53:42 <Scrat> eh. how does it have anything to do with C threading?
1163 2013-01-22 20:53:51 <Diablo-D3> Scrat: internal implementation
1164 2013-01-22 20:53:53 BTCOxygen has joined
1165 2013-01-22 20:54:06 <Diablo-D3> its done massively wrong and they cant fix it because, for one, they dont realize its massively wrong
1166 2013-01-22 20:54:18 <Diablo-D3> Seaking is going to use async messaging automatically
1167 2013-01-22 20:54:31 <Diablo-D3> you wont have explicit threading because the language itself will handle it
1168 2013-01-22 20:54:48 <HM> how?
1169 2013-01-22 20:55:39 <Diablo-D3> segmented heaps related to object type, only the object manager (ie, message processor) can access the heap
1170 2013-01-22 20:55:57 <HM> That sounds vaguely like Rust
1171 2013-01-22 20:56:02 <HM> which has local heaps
1172 2013-01-22 20:56:07 <Diablo-D3> I havent looked into Rust
1173 2013-01-22 20:56:09 <HM> which i only know of vaguely
1174 2013-01-22 20:56:20 <Diablo-D3> Im aware of it its existence though
1175 2013-01-22 20:56:20 safra has quit (Quit: Leaving)
1176 2013-01-22 20:56:26 <Diablo-D3> the concept isnt new, btw
1177 2013-01-22 20:56:35 <HM> Rust has too many pointer types
1178 2013-01-22 20:56:47 <Diablo-D3> Seaking probably wont have pointers
1179 2013-01-22 20:56:56 <Diablo-D3> it WILL have stack allocated objects, but not expose them to the programmer
1180 2013-01-22 20:57:01 <Diablo-D3> the compiler will choose the best fit
1181 2013-01-22 20:57:25 <HM> what language will you implement it in? :P
1182 2013-01-22 20:57:39 <Diablo-D3> the second implementation will be in seaking
1183 2013-01-22 20:57:44 <Scrat> I'll probably get flamed for this but I like how ICS is handling async
1184 2013-01-22 20:57:51 <Diablo-D3> the first one is going to end up just being beating llvm with a crowbar
1185 2013-01-22 20:57:51 <Scrat> altho this is a very high level implementation
1186 2013-01-22 20:57:58 <Diablo-D3> Scrat: ICS?
1187 2013-01-22 20:58:21 <Scrat> IcedCoffeeScript
1188 2013-01-22 20:58:21 <HM> Iced Coffee Scripts?
1189 2013-01-22 20:58:25 <HM> :P
1190 2013-01-22 20:58:39 <Diablo-D3> is this related to coffeescript?
1191 2013-01-22 20:58:50 <Scrat> just a fork with 2 extra keywords
1192 2013-01-22 20:59:16 <Diablo-D3> lawls
1193 2013-01-22 20:59:22 <Diablo-D3> you know what else I want in seaking?
1194 2013-01-22 20:59:25 <Diablo-D3> automatic opencl usage
1195 2013-01-22 20:59:41 <Diablo-D3> and explicit parallel execution of fors/foreaches
1196 2013-01-22 20:59:41 <Scrat> I assume you'll be busy for the next 20 years
1197 2013-01-22 21:01:05 <Diapolo> TD: were you talking about a new leveldb release a little above?
1198 2013-01-22 21:01:17 <Diablo-D3> Scrat: probably
1199 2013-01-22 21:01:25 <TD> yeah
1200 2013-01-22 21:01:28 <Diablo-D3> I want to be able to extend the compiler as well using plugins
1201 2013-01-22 21:01:34 <TD> though it differs from the previous one by only one patch
1202 2013-01-22 21:01:45 <Diablo-D3> so you can do shit like @C { printf("sup motherfuckers
1203 2013-01-22 21:01:48 <Diablo-D3> er
1204 2013-01-22 21:01:53 <Diablo-D3> so you can do shit like @C { printf("sup motherfuckers\n"; }
1205 2013-01-22 21:01:56 <Diablo-D3> and its valid
1206 2013-01-22 21:02:10 <HM> what's valid? not closing your parens?
1207 2013-01-22 21:02:29 CodeInChaos has joined
1208 2013-01-22 21:02:40 <Diapolo> that corruption patch?
1209 2013-01-22 21:02:41 rich__ has quit (Quit: Leaving)
1210 2013-01-22 21:02:50 <Diapolo> TD: https://code.google.com/p/leveldb/source/detail?r=d84c825a70a843bb107de8b732cb79e584cefd17 this one?
1211 2013-01-22 21:04:14 <TD> yeah
1212 2013-01-22 21:05:07 CodesInChaos has quit (Ping timeout: 240 seconds)
1213 2013-01-22 21:05:28 CodeInChaos is now known as CodesInChaos
1214 2013-01-22 21:05:28 <grau> I wonder if timestamp of next block could be less than previous as a result of a miner using it to extend nonce and next block comes soon after?
1215 2013-01-22 21:05:45 <Diapolo> TD: seems valuable to consider adding it to the leveldb17 branch
1216 2013-01-22 21:08:07 <Diablo-D3> HM: er
1217 2013-01-22 21:08:11 <Diablo-D3> lets pretend I close that paren
1218 2013-01-22 21:16:10 <HM> so continuing to familiarise myself with the protocol. Seq nums + time locks are still unused atm, right?
1219 2013-01-22 21:16:34 <HM> well seq num in the sense they aren't fully functional for replacement
1220 2013-01-22 21:16:43 <gavinandresen> sipa: ~2,000 blocks to go, main network sync, windows XP with leveldb1.7/native windows port, and memory usage is ~400MB, peak usage ~500MB.
1221 2013-01-22 21:17:08 <sipa> that's quite high...
1222 2013-01-22 21:17:10 <kjj> if I recall correctly, the sequence numbers and time locks are checked, but you can't replace the transaction, so they aren't useful.  don't take my word for it, I think I got this question wrong once or twice before
1223 2013-01-22 21:17:33 <sipa> kjj: you're correct
1224 2013-01-22 21:17:40 <HM> what if the time lock expires?
1225 2013-01-22 21:17:53 <sipa> then the transaction becomes final
1226 2013-01-22 21:17:59 <kjj> then the transaction can be included in a block.  the locktime just prevents that from happening
1227 2013-01-22 21:18:00 <HM> right, so time locks are useful then
1228 2013-01-22 21:18:16 <HM> for non-broadcast signed trannies
1229 2013-01-22 21:18:23 <HM> *unbroadcast
1230 2013-01-22 21:18:26 <sipa> note that if nSequence = INT_MAX for all inputs, the transaction is automatically final, despite time lock
1231 2013-01-22 21:18:27 <kjj> in theory, the lock time should enable us to implement replacement, if we ever figure out how to do that
1232 2013-01-22 21:18:57 <sipa> which is the case for almost all transactions currently
1233 2013-01-22 21:19:44 <kjj> that reminds me, if I ever get some free time, I still want to implement flags for the memory pool
1234 2013-01-22 21:19:50 <HM> Database limitations the real downer?
1235 2013-01-22 21:20:41 <kjj> grau: yes, timestamps can go backwards to a limited extent.  they are not required to increase monotonically
1236 2013-01-22 21:21:21 <sipa> gavinandresen: https://bitcointalk.org/index.php?topic=129861.80 -> person got his database corrupted :)
1237 2013-01-22 21:21:26 <sipa> :( i mean
1238 2013-01-22 21:22:03 <grau> kjj: yes that was my guess, but its ugly since block timestamp is like time point the transactions in the block are final, but since they could refer to previous blocks it looks like they refer forward in time
1239 2013-01-22 21:22:25 <grau> it might be worth considering the requirement that timestamp is not less for new block
1240 2013-01-22 21:22:42 <Diapolo> sipa: what about that corruption patch TD is talking about?
1241 2013-01-22 21:22:52 <sipa> Diapolo: i really doubt that is what happened here
1242 2013-01-22 21:22:54 <TD> it's only relevant for users who run out of disk space
1243 2013-01-22 21:23:53 <TD> sipa: his hardware may be hosed
1244 2013-01-22 21:23:56 <kjj> well, there are issues with that.  the current system is to allow a window defined by the median of the last 11 blocks in the past, and +2 hours (adjusted) into the future
1245 2013-01-22 21:25:11 <grau> I mean since the new block includes hash of the previous why should it not also take its timestamp as floor
1246 2013-01-22 21:25:20 <HM> http://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
1247 2013-01-22 21:25:21 <kjj> changing the window could allow some strange attacks, and just isn't worth it.  just pretend the block time has an asterisk indicate that it is approximate
1248 2013-01-22 21:25:59 <sipa> grau: i believe the time restrictions are too weak, but also not a real problem
1249 2013-01-22 21:26:26 <sipa> grau: the 2 hour in the future was chosen to not hurt people who have their clock on a wrong timezone, afaik
1250 2013-01-22 21:26:30 <sipa> which seems stupid
1251 2013-01-22 21:26:52 <grau> The block timestamp is the only time the transactions can be sorted for people not familiar with the internals of the system. I think it would be better to have it monotonic
1252 2013-01-22 21:26:54 <sipa> just require a correct time, or have an ntp client in the program to adjust if necessary
1253 2013-01-22 21:27:26 <sipa> tightening those restrictions would be possible in a softfork, actually
1254 2013-01-22 21:27:41 <grau> I am not requiring correct time, but since the block uses the hash of the previous why not require timestamp be also at least greater?
1255 2013-01-22 21:27:57 <sipa> what if the time of the previous block was already in the future?
1256 2013-01-22 21:28:13 <grau> no problem stay in future, just be after
1257 2013-01-22 21:28:27 <sipa> how far in the future would you allow?
1258 2013-01-22 21:28:36 <kjj> but then you have to allow more futureness than you have to allow otherwise
1259 2013-01-22 21:28:42 <grau> I would not change the current window
1260 2013-01-22 21:29:44 <sipa> grau: so, someone mines a block at the limit, and you clock is a few seconds off
1261 2013-01-22 21:29:52 <sipa> -> you can't mine
1262 2013-01-22 21:30:20 <grau> I think the timestamp is already an extended nounce for the miner, they will not wait
1263 2013-01-22 21:30:44 <sipa> right now, they don't ever have to wait
1264 2013-01-22 21:30:59 Diapolo has left ()
1265 2013-01-22 21:31:16 <grau> I do not see why they would have to with my suggestion
1266 2013-01-22 21:31:56 <grau> The timestamp is just a piece of date for them, they can actually increment to extend nonce
1267 2013-01-22 21:32:07 <sipa> what if the block you receive has a timestamp that is more than 2 hours in the future?
1268 2013-01-22 21:32:18 <sipa> as clocks are never entirely in sync, this is possible
1269 2013-01-22 21:32:41 <sipa> (unlikely, and only a problem for at most seconds in reality, but it is true that currently this is not a problem)
1270 2013-01-22 21:32:50 <grau> yest it is possible but you can still use the nonce and any time from that time point to the window limit
1271 2013-01-22 21:33:22 <grau> My starting point is the following use case:
1272 2013-01-22 21:33:24 spaz926_ has joined
1273 2013-01-22 21:33:35 spaz926 has quit (Disconnected by services)
1274 2013-01-22 21:33:39 spaz926_ is now known as spaz926
1275 2013-01-22 21:33:39 spaz926 has quit (Changing host)
1276 2013-01-22 21:33:39 spaz926 has joined
1277 2013-01-22 21:33:59 <grau> I want to compile an account statement and retrieve transactions affecting an address
1278 2013-01-22 21:34:32 <grau> it would be natural to sort them by timestamp of the block, but it is not guaranteed currently to be ascending
1279 2013-01-22 21:34:50 <kjj> in bitcoin, the natural thing is to sort them by block number, and then by place within the block
1280 2013-01-22 21:34:56 <grau> if I sort by block number then it is not guaranteed that transaxtions spend money that was there before
1281 2013-01-22 21:35:02 swappermall__ has quit (Read error: Connection reset by peer)
1282 2013-01-22 21:35:34 <HM> it's not gauranteed that the money you spend in your bank account is there before either
1283 2013-01-22 21:35:37 <grau> that is why i think timestamp should increase monotonically just like block number
1284 2013-01-22 21:35:40 <kjj> ahh, you are wrong.  sorting by block number and transaction sequence is the ONLY way to guarantee that things happen in the right order.
1285 2013-01-22 21:35:49 <HM> statements show negative a lot :(
1286 2013-01-22 21:36:19 <kjj> I agree with you, I'd like the timestamps to always go up.  but the decision has benefits that outweigh the costs
1287 2013-01-22 21:36:32 spaz926 has quit (Remote host closed the connection)
1288 2013-01-22 21:36:50 <grau> kjj: yes, block number is the right order, but not the order people other than bitcoin developer think
1289 2013-01-22 21:37:14 <kjj> they'd better get used to it.  right or wrong, it seems unlikely to change
1290 2013-01-22 21:37:14 spaz926 has joined
1291 2013-01-22 21:37:23 spaz926 has quit (Client Quit)
1292 2013-01-22 21:37:39 <grau> You did not yet convienced me that the change would be disruptive
1293 2013-01-22 21:37:54 <kjj> we don't need to convince you.  you need to convince everyone
1294 2013-01-22 21:38:29 <sipa> in particular, you'll need to convince miners
1295 2013-01-22 21:38:40 <kjj> and so far, in 4+ years, no one has made any progress
1296 2013-01-22 21:38:46 <sipa> and those are the one group that has benefits from weak timestamp restrictions
1297 2013-01-22 21:39:16 <grau> We have to think like end user to make this system grow. This is also their interest
1298 2013-01-22 21:39:45 <kjj> no, it really isn't.  they gain nothing noteworthy from the change.
1299 2013-01-22 21:39:53 <sipa> yes, I understand your use case, and I agree it would be nice to have monotonically increasing timestamps
1300 2013-01-22 21:40:15 <sipa> but i think it's not important enough that you'll convince everyone about the advantage
1301 2013-01-22 21:40:21 <kjj> the only clear gain for regular users would be if the timestamp was somehow provable and accurate
1302 2013-01-22 21:41:46 <HM> If transactions had timestamps could you not use some function of the tx's in the block to come to a block stamp?
1303 2013-01-22 21:41:50 <HM> random thought
1304 2013-01-22 21:43:02 <sipa> HM: transactions do not have a defined order, so how will you assign a meaningful timestamp to them?
1305 2013-01-22 21:43:21 <sipa> well, you could, if you didn't require them to be ordered according to their timestamp in the block chain
1306 2013-01-22 21:43:30 <sipa> but that would perhaps be even more confusing :)
1307 2013-01-22 21:45:31 <HM> well grau wants to create a statement, he's never going to get that to minute accuracy anyway
1308 2013-01-22 21:46:25 <grau> HM: I am not after accuracy, just monotonic increase with the block number
1309 2013-01-22 21:47:05 <sipa> well, if you want monotonicity, you have it - first by block number, then by position within block
1310 2013-01-22 21:47:26 <sipa> the problem is that you also want timestamps that are both meaningful and compatible with transaction order
1311 2013-01-22 21:47:43 <sipa> and this simply doesn't exist
1312 2013-01-22 21:48:10 <sipa> you could use the time at which you first saw a particular block for the time of all transactions in it
1313 2013-01-22 21:48:15 <grau> sipa: yes thats the order of the accounting, but then I can not add timestamp to it since user will ask why I book occassionaly backward in time
1314 2013-01-22 21:48:37 <HM> i've seen bank statements that occasionally list things in weird orders
1315 2013-01-22 21:49:00 <grau> HM: we want to be better than a bank right ?
1316 2013-01-22 21:49:43 <HM> my point is ordering isn't important unless it has a perceivable effect
1317 2013-01-22 21:50:02 <gmaxwell> grau: regardless of how much you want monotonic timestamp, making it be monotonic would enable malicious activity and would potentially make the timestamps less accurate on average.
1318 2013-01-22 21:50:06 rdymac has joined
1319 2013-01-22 21:50:23 <HM> like a credit card company will check your spend limit when you make a transaction, but that transaction might not appear on your statement until after a later one
1320 2013-01-22 21:50:30 <HM> it's common
1321 2013-01-22 21:50:43 <gmaxwell> grau: There is no precise decenteralized view of time, and bitcoin does not create one.
1322 2013-01-22 21:51:59 <HM> maybe if your statement produces weird results, like a transaction order appears to make the wallet go negative, you just permutate the order a bit
1323 2013-01-22 21:52:09 <HM> bodge it so it looks right
1324 2013-01-22 21:53:01 <HM> tweak the timestamps :p
1325 2013-01-22 21:58:15 <grau> I wish we would think harder to please ordinary people. Until you do not convince me that this would present a security risk, this will remain at least on my wish list.
1326 2013-01-22 21:59:45 BTCOxygen has quit (Ping timeout: 245 seconds)
1327 2013-01-22 22:00:06 <HM> well someone with an atomic clock could always signed a timestamp and pump it in to the blockchain
1328 2013-01-22 22:00:11 <HM> you'd just have to recognise it and trust it
1329 2013-01-22 22:02:10 Prattler has joined
1330 2013-01-22 22:02:45 <grau> gmaxwell: in case you have an idle cycle, give me a hint what malicious activity it would enable if we would require that a new block not only contains the previous hash but has a timestamp greater than that pervious has.
1331 2013-01-22 22:04:46 <gmaxwell> grau: it would mean that someone could mine a block with the maximum acceptable future timestamp, forcing all the subsiquent miners to place their time in the future.
1332 2013-01-22 22:05:36 <gmaxwell> Even just a miner with a fast clock mining a block a few minutes in the future would force subsequent miners to mine inaccurate times.
1333 2013-01-22 22:05:40 <grau> gmaxwell: Yes that would limit the time rolling for real time for them but also for the attacker. No upside
1334 2013-01-22 22:06:10 rdymac has quit (Quit: This computer has gone to sleep)
1335 2013-01-22 22:06:44 <grau> gmaxwell: What is more incorrect ? a back and forth blocktime or one that sometimes goes ahead?
1336 2013-01-22 22:06:48 <jrmithdobbs> hey so, I'm going to make a stab at rebasing those *bsd build fixes
1337 2013-01-22 22:06:48 <gmaxwell> grau: the upside is that it allows someone to advance the clock forward to push the difficulty down without a matching correction, and that it would allow them to advance the clock to speed up the mining of locked transactions.
1338 2013-01-22 22:07:03 <jrmithdobbs> because I don't have any publically connected linux hosts any more ;p
1339 2013-01-22 22:07:17 <gmaxwell> grau: The time stamps _can not_ be precise. So given that they can't be precise it is better to have ones with lower errors.
1340 2013-01-22 22:13:15 <grau> gmaxwell: Again I am not after precision, just do not get if blocks depend on previous in a lot of ways e.g. hash and utxo, why could they not have a floor on timestamp imposed by the previous. The argument with the locked transaction is valid but extremerly unlikely to be useful for an exploit. The difficulty change depends on block height not time isnt'it?
1341 2013-01-22 22:13:31 rdymac has joined
1342 2013-01-22 22:13:55 <gmaxwell> grau: you can always monotonize the block timestamps yourself— mandating it always loses you information.
1343 2013-01-22 22:14:07 denisx has joined
1344 2013-01-22 22:14:21 <gmaxwell> grau: e.g. modified_timestamp =  max(timestamp,prev_timestamp+1)
1345 2013-01-22 22:15:04 <gmaxwell> grau: the new difficulty depends on the times, for the obvious reasons.
1346 2013-01-22 22:15:53 <grau> gmaxwell: yes I can mask it but would love to fix it.
1347 2013-01-22 22:16:33 <grau> gmaxwell: marking the block for the future lowers difficulty for everyone not just the one who plays it
1348 2013-01-22 22:17:10 <gmaxwell> grau: Your 'fix' would be a softfork, it would reduce security (if only in fringe ways), it would decrease the accurace of the timestamps— and it wouldn't give you anything you couldn't get from the modified timestamps I suggested above.
1349 2013-01-22 22:20:00 <gmaxwell> (I suppose it actually would be max(timestamp,prev_modified_timestamp+1) )
1350 2013-01-22 22:20:11 <grau> OK, I see that we would have to trade in something for it, I think it would be worth, you do not. However thanks taking the time.
1351 2013-01-22 22:22:11 <gmaxwell> grau: what is the value? How can it be worth reducing security and opening up griefing attacks when it doesn't even enable something new. We could just as well make a monotonized timestamp a well-defined thing. For what purpose would changing the blockchain be better?
1352 2013-01-22 22:22:35 rdymac has quit (Ping timeout: 248 seconds)
1353 2013-01-22 22:23:04 <grau> I gave you a use case where it is value. If I mask it I loos authenticity, that is my value.
1354 2013-01-22 22:24:08 <grau> You might argue the value is low, I say the "security" trade in is also very low.
1355 2013-01-22 22:24:24 <gmaxwell> No. I'm saying the value is zero. Perhaps I missed one of your messages?
1356 2013-01-22 22:24:43 <grau> OK, the use case is folowing:
1357 2013-01-22 22:25:31 <grau> I want to create an account statemnt for an address that lists transactions and their time. Since transaction does not have time the closest is to show the timestamp of their block.
1358 2013-01-22 22:25:53 <grau> Now if I show the transactions in timestamp order than it might appear negative balance
1359 2013-01-22 22:26:28 <sipa> grau: the best choice for that is using the local time when transactions were added to the mempool+wallet
1360 2013-01-22 22:26:36 <grau> since the right order is block order for the accounting
1361 2013-01-22 22:26:56 <grau> The statement is not neccesarily for my wallet
1362 2013-01-22 22:27:12 <sipa> ah
1363 2013-01-22 22:27:20 <gmaxwell> So, instead, show using an order from the deterministic monotonized block timestamps instead of the block timestamps. Though I warn you- because of reorginizations the order can change, which will blow up most applications which aren't savvy to how bitcoin works.
1364 2013-01-22 22:28:17 <gmaxwell> Basically what you're asking for is a soft forking rule to force miners to hide information (that they believe the time is before the last block time) from you. I say- no, better to have them not hide the data— and if you don't want it, hide it yourself. Then you can have both the most accurate time estimates _and_ a determinstic monotonized time.
1365 2013-01-22 22:28:28 <sipa> the only fully-accounting-compatible statement is one where every event is logged; the first confirmation is the +, at the time its respective block is received+verified; reorganisations cause the adding of a corresponding -
1366 2013-01-22 22:29:51 <sipa> that's not necessary for a statement about the "far past" (the part assumed to be unreorganizable)
1367 2013-01-22 22:30:48 <grau> gmaxwell: I agree with the information argument, but bitcoin is not about a true order of things but just one commonly accepted order.
1368 2013-01-22 22:31:08 sgornick has joined
1369 2013-01-22 22:31:46 <grau> sipa: I am trying to create a statement that is intuitive and correct, thats my criteria.
1370 2013-01-22 22:33:21 <gmaxwell> Intutive is good when it's not dangerous, I'd have to know more to say if using block times for something was dangerous or not.
1371 2013-01-22 22:33:38 <sipa> grau: if you're adding timestamps, but don't require them to be accurate, i don't see a problem with using "corrected block timestamps'
1372 2013-01-22 22:34:02 <sipa> if you want accurate timestamps, you'll need to gather information that is not in the block chain
1373 2013-01-22 22:34:33 <grau> sipa: Accurate in the means of commonly accepted. If I fudge it it wont be the same others fudge.
1374 2013-01-22 22:35:53 <sipa> grau: so instead of just setting a standard for interpreting block timestamps, you want everyone to agree on it in advance by having it fixed in the bitcoin protocol
1375 2013-01-22 22:35:54 <gmaxwell> grau: sure it would- I proposed a monotonization of the timestamps which is determinstic, a simple function of the chain, and also likely the same values you'd get if you forced miners to lie.
1376 2013-01-22 22:36:35 <gmaxwell> Everyone could arrive at the same monotonized time. I'd have no issue with adding that to the reference client, except I really don't see an application for it as it can still change due to reorgs.
1377 2013-01-22 22:37:25 <gmaxwell> (Already in the reference client we have multiple timestamps for transactions in the wallet)
1378 2013-01-22 22:39:20 <grau> gmaxwell, sipa: I agree, that a "standard" that allows UIs to reach common monotonization is sufficient. We should perhabs collect these recommendations. Or is there such a page ?
1379 2013-01-22 22:39:33 ovidiusoft has quit (Read error: Operation timed out)
1380 2013-01-22 22:40:05 <sipa> gmaxwell: i wonder wth bitcoind uses 1.3GB of virtual memory, right at startup, when doing a -reindex :S
1381 2013-01-22 22:40:15 agricocb has joined
1382 2013-01-22 22:40:30 <sipa> even if it's using only 200MB of RES
1383 2013-01-22 22:41:33 <sipa> grau: personally i think something like such a statement belongs in a wallet abstraction, where it is easier to implement (just use time accepted into wallet)
1384 2013-01-22 22:42:55 <gavinandresen> sipa: 300 blocks to go, memory usage down to 300MB (570MB peak)….
1385 2013-01-22 22:43:12 <grau> sipa: This is not a wallet rule. If I were extracting account statemnt for any address, I would use such rule, and it would be desirable if commonly accepted practice like the format of the address itself
1386 2013-01-22 22:43:35 <sipa> grau: yes i understand you see things differently
1387 2013-01-22 22:43:37 <gmaxwell> account statement for any address? ugh.
1388 2013-01-22 22:43:56 <grau> gmaxwell: afreaid of real life use cases :) ?
1389 2013-01-22 22:44:13 <gmaxwell> grau: addresses are not accounts.
1390 2013-01-22 22:44:29 <grau> Please do not underestimate me that badly
1391 2013-01-22 22:44:44 Guest40173 has joined
1392 2013-01-22 22:44:55 <sipa> gavinandresen: yeah, when not in IBD, the coin cache is flushed after every block, so it's excepted that the memory usage drops in the end
1393 2013-01-22 22:44:59 <grau> Think of BIP32
1394 2013-01-22 22:45:11 <grau> If implemented you have an account
1395 2013-01-22 22:45:20 <grau> made up by addresses derivable
1396 2013-01-22 22:45:46 <sipa> grau: so your use case is: i have a wallet defined by BIP32, i send your server a public extended key, and you generate a statement for the entire wallet?
1397 2013-01-22 22:46:02 <grau> neat isnt it?
1398 2013-01-22 22:46:13 <grau> pssssst.
1399 2013-01-22 22:47:57 <sipa> well, i see that as: i'm reconstructing a wallet from the block chain, i use some mechanism to do a quick rescan (electrum-like, which your server could do easily), and i compute any balance or statement from that wallet
1400 2013-01-22 22:48:21 sacredchao has quit (Ping timeout: 276 seconds)
1401 2013-01-22 22:48:27 <sipa> it's essentially the same, except the statement code is on the client side instead of the server side
1402 2013-01-22 22:49:01 Prattler has quit (Quit: ZNC - http://znc.in)
1403 2013-01-22 22:49:29 <grau> Yes, possible if there is a client capable of doing that. But let us discuss the business plan in an other channel :)
1404 2013-01-22 22:49:42 sacredchao has joined
1405 2013-01-22 22:50:57 Guest40173 has quit (Ping timeout: 276 seconds)
1406 2013-01-22 22:51:33 <grau> sorry have to go for sleep. Thanks for the input.
1407 2013-01-22 22:52:07 <sipa> gavinandresen: *exPECted
1408 2013-01-22 22:52:21 grau has quit (Remote host closed the connection)
1409 2013-01-22 22:52:23 copumpkin has quit (Ping timeout: 245 seconds)
1410 2013-01-22 22:52:57 copumpkin has joined
1411 2013-01-22 22:54:21 bitnumus_ has quit (Quit: Leaving)
1412 2013-01-22 22:56:25 denisx has quit (Quit: denisx)
1413 2013-01-22 22:57:36 <HM> the serialisation code isn't the easiest to follow
1414 2013-01-22 22:58:04 MrTiggr has joined
1415 2013-01-22 23:01:29 Hashdog has quit (Remote host closed the connection)
1416 2013-01-22 23:01:35 <HM> ah that binary map on the wiki helps
1417 2013-01-22 23:04:35 PhantomSpark has quit (Ping timeout: 276 seconds)
1418 2013-01-22 23:05:18 sgornick has quit (Ping timeout: 248 seconds)
1419 2013-01-22 23:08:15 <gavinandresen> sipa: chain sync finished, memory usage looks stable at 270MB.  I'm going to restart and then let it run overnight, see what the memory usage looks like….
1420 2013-01-22 23:19:28 sgornick has joined
1421 2013-01-22 23:22:17 <MC-Eeepc> whats a normal peer count for an open node
1422 2013-01-22 23:22:22 <MC-Eeepc> i used to get 60 ish
1423 2013-01-22 23:22:42 <Luke-Jr> it can vary
1424 2013-01-22 23:25:43 agricocb has quit (Quit: Leaving.)
1425 2013-01-22 23:25:52 rdymac has joined
1426 2013-01-22 23:26:50 TD has quit (Quit: TD)
1427 2013-01-22 23:29:13 reizuki has joined
1428 2013-01-22 23:29:56 <MC-Eeepc> got 19 :/
1429 2013-01-22 23:34:05 <HM> why does Block explorer show strange values like 464.60363 for values when the rawtransaction seems to decode to an integer?
1430 2013-01-22 23:34:41 <HM> nevermind, i'm being a tool
1431 2013-01-22 23:34:51 <gmaxwell> TD[gone]`: your responses on pull 2188 are making me very uncomfortable. You are taking an unwise approach. I was previously OKAY with the bloom filter, but your response of URGENT URGENT URGENT is making me feel that I shouldn't trust your judgement of the correctness of the specification and implementation, because you're making it clear that you'd still advance a flawed proposal
1432 2013-01-22 23:34:57 <gmaxwell> (because you consider it so urgent)
1433 2013-01-22 23:35:50 <gmaxwell> (I say it is unwise, because it makes me less comfortable with the feature and I assume this is not your goal)
1434 2013-01-22 23:41:08 bitafterbit has quit (Remote host closed the connection)
1435 2013-01-22 23:47:58 RazielZ has quit (Ping timeout: 246 seconds)
1436 2013-01-22 23:51:50 jrmithdobbs has quit (Remote host closed the connection)
1437 2013-01-22 23:52:23 one_zero has joined
1438 2013-01-22 23:53:21 jrmithdobbs has joined
1439 2013-01-22 23:53:48 <HM> https://en.bitcoin.it/w/images/en/e/e1/TxBinaryMap.png
1440 2013-01-22 23:53:51 <HM> in this diagram
1441 2013-01-22 23:53:59 <HM> what does the VI before PkScript actually count?
1442 2013-01-22 23:54:37 <HM> if it's the length of the PkScript in bytes, it doesn't seem to be correct in some raw txs i'm viewing
1443 2013-01-22 23:54:54 sgornick has quit (Ping timeout: 248 seconds)
1444 2013-01-22 23:55:57 CodesInChaos has quit (Ping timeout: 276 seconds)
1445 2013-01-22 23:56:53 <sipa> it is
1446 2013-01-22 23:57:12 <HM> well i'm viewing a transaction where it has the value of 0x19
1447 2013-01-22 23:57:28 <HM> which makes no sense because the PkScript contains a hash that is 20 bytes
1448 2013-01-22 23:57:32 <HM> this is in the block chain
1449 2013-01-22 23:58:03 BNCatDIGISHELL has quit (Ping timeout: 248 seconds)
1450 2013-01-22 23:58:28 <sipa> 0x19 = 35
1451 2013-01-22 23:58:30 BNCatDIGISHELL has joined
1452 2013-01-22 23:58:32 <sipa> eh
1453 2013-01-22 23:58:37 <sipa> 25
1454 2013-01-22 23:59:16 sgornick has joined