1 2013-01-25 00:00:46 <gmaxwell> fwiw, 'dazboyy' under another name was previously identified as a scammer in other channels.
   2 2013-01-25 00:02:19 copumpkin has quit (Ping timeout: 244 seconds)
   3 2013-01-25 00:02:54 copumpkin has joined
   4 2013-01-25 00:03:14 dvide has joined
   5 2013-01-25 00:04:25 <CodeShark> don't worry, I wasn't intending on buying from that person
   6 2013-01-25 00:04:28 <CodeShark> :p
   7 2013-01-25 00:08:51 bitnumus has joined
   8 2013-01-25 00:09:20 agricocb has joined
   9 2013-01-25 00:10:27 PhantomSpark has quit (Ping timeout: 276 seconds)
  10 2013-01-25 00:10:55 vigilyn has quit (Ping timeout: 246 seconds)
  11 2013-01-25 00:11:04 <etotheipi_> gmaxwell, I want a sanity check on my idea for incorporating bitcoind into Armory
  12 2013-01-25 00:11:24 <gmaxwell> hurrah
  13 2013-01-25 00:11:24 <etotheipi_> (or sipa ^^^)
  14 2013-01-25 00:11:44 <CodeShark> incorporating?
  15 2013-01-25 00:11:54 <etotheipi_> err.. bundling
  16 2013-01-25 00:12:08 <etotheipi_> big difference, eh
  17 2013-01-25 00:12:33 <etotheipi_> I basically want to download the binaries and bundle them with Armory
  18 2013-01-25 00:12:49 <etotheipi_> and then have Armory start and stop bitcoind in the background
  19 2013-01-25 00:12:50 <Diablo-D3> dont.
  20 2013-01-25 00:13:28 <etotheipi_> well this is why it's a sanity check
  21 2013-01-25 00:13:47 <Luke-Jr> etotheipi_: hmm, you actually have a use-case for a RPC-less bitcoind O.o
  22 2013-01-25 00:14:09 <Diablo-D3> Luke-Jr: no he doesnt
  23 2013-01-25 00:14:11 <CodeShark> I use several instances of RPC-less bitcoind
  24 2013-01-25 00:14:17 <CodeShark> and wallet-less bitcoind
  25 2013-01-25 00:14:19 <Diablo-D3> how do you tell it to stop?
  26 2013-01-25 00:14:19 <CodeShark> just p2p
  27 2013-01-25 00:14:27 <Luke-Jr> CodeShark: you have code to strip out the RPC?
  28 2013-01-25 00:14:31 <Luke-Jr> Diablo-D3: SIGINT, n00b
  29 2013-01-25 00:14:39 <Diablo-D3> on windows?
  30 2013-01-25 00:14:44 <etotheipi_> but yes, it *could* be RPC-less
  31 2013-01-25 00:14:57 <CodeShark> Luke-Jr: no, I just don't use it - but it would be rather simple to remove the RPC code entirely
  32 2013-01-25 00:15:15 <Luke-Jr> Diablo-D3: yes
  33 2013-01-25 00:15:51 <etotheipi_> though I was thinking I could setup the bitcoin.conf file with crypto-random username and password, and set bitcoind datadir inside Armory-datadir
  34 2013-01-25 00:16:09 <etotheipi_> I don't *need* RPC
  35 2013-01-25 00:16:17 <etotheipi_> but it wouldn't be bad to have the option
  36 2013-01-25 00:16:24 <gmaxwell> etotheipi_: bummer when you said incorporating I thought you meant making armory run on the rpc rather than scraping the blockchain.
  37 2013-01-25 00:16:25 <etotheipi_> unless it opens up security concerns
  38 2013-01-25 00:16:36 <CodeShark> hehe, yes, gmaxwell :)
  39 2013-01-25 00:16:39 <CodeShark> I was thinking the same
  40 2013-01-25 00:16:55 <gmaxwell> etotheipi_: p2pool autoreads the config to get the rpc info, and if you don't have a config for you it tells you what to put in it.
  41 2013-01-25 00:16:59 <etotheipi_> gmaxwell: you think it's ready to be a full backend for another app?
  42 2013-01-25 00:17:16 <etotheipi_> I mean, how am I to tell it what addresses to track
  43 2013-01-25 00:17:45 <gmaxwell> etotheipi_: With sipa's indexes ... it may be.  However— it won't ever become one unless someone is trying and reporting limitations.
  44 2013-01-25 00:18:01 rng29a has quit (Quit: Ex-Chat)
  45 2013-01-25 00:18:18 <CodeShark> etotheipi, you can use pull request 2121 :)
  46 2013-01-25 00:18:28 <etotheipi_> gmaxwell: things like importing and sweeping addresses is something Armory is doing quite well, right now
  47 2013-01-25 00:18:50 <etotheipi_> I don't know... I like the control
  48 2013-01-25 00:18:51 <gmaxwell> etotheipi_: it can optionally track all addresses (with sipa's index patchs) ... but even ignoring that, you can just get the blocks out of it instead of scraping the chain. — this has the advantage of making you chain format agnostic, and also means you'll never potentially be on a different chain than bitcoind itself.
  49 2013-01-25 00:19:43 <CodeShark> etotheipi_: I've got a database app that just grabs the blocks in reverse order from bitcoind using p2p
  50 2013-01-25 00:20:28 <etotheipi_> actually, I was also, in the somewhat near future, considering having Armory maintain its own blockchain
  51 2013-01-25 00:20:54 <etotheipi_> it would get it from bitcoind, but it would solve a lot of crashing problems I've been having, and allow remote (but trusted!) nodes to service your instance
  52 2013-01-25 00:21:27 <gmaxwell> etotheipi_: how is that going to solve your crashing problems?
  53 2013-01-25 00:21:55 <etotheipi_> gmaxwell: I have issues that I believe are related to reading the blkfile during a partial bnitcoind write
  54 2013-01-25 00:21:58 Jouke_ has quit (Ping timeout: 272 seconds)
  55 2013-01-25 00:22:00 <etotheipi_> it happens like once every 5 days
  56 2013-01-25 00:22:05 <BlueMatt> lianj: are you github @lian>
  57 2013-01-25 00:22:06 <etotheipi_> I've been trying to catch it in a debugger
  58 2013-01-25 00:22:07 <BlueMatt> ?
  59 2013-01-25 00:22:15 <etotheipi_> but now it's been like 2 weeks and it hasn't happened
  60 2013-01-25 00:22:16 <lianj> yes
  61 2013-01-25 00:22:23 <etotheipi_> though some people report it a lot more
  62 2013-01-25 00:22:25 <gmaxwell> It's still going to give you much higher resources than any other wallet software too.. except in the bad case where people randomly trust other nodes. "what bad could happen?"
  63 2013-01-25 00:22:44 <gmaxwell> etotheipi_: so fix your reader code so it doesn't crash! :P
  64 2013-01-25 00:22:52 <etotheipi_> also a problem with blkfile splits... only an issue in linux apparently
  65 2013-01-25 00:23:01 <BlueMatt> lianj: so...you have lots of fun testcases in bitcoin-ruby...why did those never come upstream?
  66 2013-01-25 00:23:14 <BlueMatt> lianj: and could I convince you to push them upstream so bitcoind/j/etc can use them too?
  67 2013-01-25 00:23:30 <etotheipi_> gmaxwell: the other aspect is that I want Armory to eventually do its own thing, not just copy bitcoind
  68 2013-01-25 00:23:46 <etotheipi_> like lite-node stuff
  69 2013-01-25 00:24:08 <gmaxwell> etotheipi_: sure, but frontend and backend seperation is a good thing. You really don't want your wallet ever talking to something untrusted or across a potentially insecure network.
  70 2013-01-25 00:24:08 <BlueMatt> lianj: it seems like the test case descriptors are actually somewhat similar
  71 2013-01-25 00:24:20 <lianj> BlueMatt: sure, although im not found of they quality, but if the come with comments, the other repo owners can decide.
  72 2013-01-25 00:24:38 <gmaxwell> etotheipi_: so what I'm suggeesting is that you hoist armory up on top of bitcoind, and then later you could support your own (or some other— like piecocoin based) backend.
  73 2013-01-25 00:25:17 <lianj> also, i plan to add/run all the bitcoind test cases, but when i started, they did have zero tests, but im really happy that they also started to gather some
  74 2013-01-25 00:25:26 <BlueMatt> lianj: there arent /that/ many test cases in bitcoind right now, and as long as they are valid...more is always better: https://github.com/bitcoin/bitcoin/blob/master/src/test/data
  75 2013-01-25 00:26:33 <lianj> hehe yep, good idea. might be my first time to contribute something upstream there, i like that :)
  76 2013-01-25 00:27:03 <BlueMatt> well its a great way to start :)
  77 2013-01-25 00:27:29 * gmaxwell pins a gold star of effective outreach on bluematt.
  78 2013-01-25 00:28:10 <BlueMatt> not my catch, I made a mistake in bitcoinj and there (appears) to be a testcase in lianj's bitcoin-ruby...frankly I just didnt want to do the work to copy the test cases over so I can fix bitcoinj :P
  79 2013-01-25 00:28:17 <lianj> BlueMatt: but give me some days, busy with other stuff :/ but yea, good suggestion
  80 2013-01-25 00:28:23 <BlueMatt> no problem
  81 2013-01-25 00:29:50 <lianj> BlueMatt: good to know someone looks at the repo, even if they dont use it ;)
  82 2013-01-25 00:29:53 Jouke has joined
  83 2013-01-25 00:30:36 <BlueMatt> it was linked to me...so someone must be doing something with it
  84 2013-01-25 00:30:40 vigilyn has joined
  85 2013-01-25 00:30:41 vigilyn has quit (Changing host)
  86 2013-01-25 00:30:41 vigilyn has joined
  87 2013-01-25 00:31:06 <mappum> when i use gettransaction on bitcoind, can i assume all the inputs are valid (the miner or bitcoind verified them already)?
  88 2013-01-25 00:31:28 <etotheipi_> gmaxwell, I have to do some work to see what I'd have to change to rely on bitcoind
  89 2013-01-25 00:31:35 <etotheipi_> I bet it would be a bit...
  90 2013-01-25 00:31:47 Guest65783 has quit (Quit: This computer has gone to sleep)
  91 2013-01-25 00:32:02 <etotheipi_> things like my "LedgerEntry" on which everything relies would not be available
  92 2013-01-25 00:33:22 <etotheipi_> gmaxwell: I guess, if I was starting from scratch, it would be a fantastic option, but since I already have all these utilities built, I get a lot of extra flexibility using them
  93 2013-01-25 00:35:32 <etotheipi_> gmaxwell: either way, I think it's a very short path between what I've got, and simply managing bitcoind myself (especially in python)
  94 2013-01-25 00:35:45 <etotheipi_> so I will start there, and in the future, I may find it worth exploring that
  95 2013-01-25 00:38:26 TD has quit (Quit: TD)
  96 2013-01-25 00:44:21 <etotheipi_> gmaxwell, sipa, Luke-Jr : in either case, I would still be distributing bitcoind with my app, and having Armory manage it
  97 2013-01-25 00:45:04 <etotheipi_> if it uses the RPC interface, how is it going to connect securely?  should I create a random bitcoin.conf
  98 2013-01-25 00:45:04 <etotheipi_> ?
  99 2013-01-25 00:45:40 <etotheipi_> and then I have to decide how to interact with the likely scenario that bitcoind/-qt is already installed and has been used...
 100 2013-01-25 00:46:50 D34TH has joined
 101 2013-01-25 00:46:57 <etotheipi_> I suppose if they already have a ~/.bitcoin (or similar in windows) directory, then I just run it with default datadir and use the bitcoin.conf that's already there
 102 2013-01-25 01:01:44 <gavinandresen> etotheipi_: I wrote some python bitcoin.conf-reading code that you might find useful
 103 2013-01-25 01:03:01 <Luke-Jr> while(<>){m/rpc(user|password)\=(.*)/&&$rpc{$1}=$2} <-- read bitcoin.conf in perl! :P
 104 2013-01-25 01:04:50 Impaler has joined
 105 2013-01-25 01:04:51 <etotheipi_> why is reading bitcoin.conf difficult?
 106 2013-01-25 01:05:04 <gavinandresen> it's not….
 107 2013-01-25 01:05:30 <gavinandresen> … it is just always easier to not write code than to write new code.  Anyway:  https://github.com/gavinandresen/bitcoin-git/blob/spendfrom/contrib/spendfrom/spendfrom.py
 108 2013-01-25 01:05:30 <etotheipi_> gavinandresen, do you think I need more than just username and password?
 109 2013-01-25 01:05:38 <gavinandresen> rpcport....
 110 2013-01-25 01:06:00 <gavinandresen> actually, 'port' too.  Do you assume 8333 now?
 111 2013-01-25 01:06:13 <etotheipi_> gavinandresen: yes, 8333
 112 2013-01-25 01:06:47 <etotheipi_> okay, so there's a few params to read
 113 2013-01-25 01:07:00 B0g4r7 has quit (Ping timeout: 276 seconds)
 114 2013-01-25 01:07:16 <etotheipi_> gavinandresen: what do you think of the idea of bundling bitcoind?
 115 2013-01-25 01:07:21 <gavinandresen> anyway, that spendfrom.py script does All the Right Things
 116 2013-01-25 01:07:32 <etotheipi_> gavinandresen: I'm looking at it now.  thanks
 117 2013-01-25 01:08:04 <gavinandresen> bundling bitcoind: sure, I think Armory would be a lot more popular if it was better packaged
 118 2013-01-25 01:08:16 <etotheipi_> gavin, you should use the getpass module
 119 2013-01-25 01:08:41 <etotheipi_> (I noticed raw_input() in the unlock_wallet method)
 120 2013-01-25 01:08:53 <gavinandresen> thanks, didn't know python had a get pass module
 121 2013-01-25 01:09:20 <etotheipi_> gavinandresen: yeah, it's no-echo pasword collection
 122 2013-01-25 01:09:46 <etotheipi_> import getpass;   myPass = getpass.getpass("Please enter password: ")
 123 2013-01-25 01:10:02 <gavinandresen> outrageously difficult I see, like EVERYTHING in python.
 124 2013-01-25 01:10:11 <gavinandresen> :)
 125 2013-01-25 01:10:12 <etotheipi_> exactly
 126 2013-01-25 01:10:20 <etotheipi_> haha
 127 2013-01-25 01:10:51 OneFixt has quit (Remote host closed the connection)
 128 2013-01-25 01:12:32 <etotheipi_> so yeah... I kind of want a sanity check on how I'm going to do this... it seems like I can just asynchronously launch the bitcoind binary from python, and I think it will shutdown when Armory exits (though I have to investigate a little more)
 129 2013-01-25 01:12:54 B0g4r7 has joined
 130 2013-01-25 01:13:32 OneFixt has joined
 131 2013-01-25 01:13:36 <HM> you could wrap Bitcoin C++ code in python
 132 2013-01-25 01:13:40 <HM> using Boost.Python
 133 2013-01-25 01:14:03 Seeraber is now known as Seeraber|away
 134 2013-01-25 01:14:04 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 135 2013-01-25 01:14:19 <etotheipi_> I'd prefer not to touch the code... I want it to be as easy as possible to upgrade Armory with the new bitcoind versions
 136 2013-01-25 01:14:29 <etotheipi_> I already have enough hoops to jump through to release new versions
 137 2013-01-25 01:14:54 <etotheipi_> although if there's some super-clear advantage (like security issues with what I'm proposing), I will of course entertain them :)
 138 2013-01-25 01:15:11 <HM> IPC is always painful
 139 2013-01-25 01:15:13 <HM> no exceptions
 140 2013-01-25 01:17:27 <CodeShark> would you necessarily want it to shut down when Armory exits?
 141 2013-01-25 01:18:06 <CodeShark> I'd like to have bitcoind run as a service in the background that UI processes can connect to as needed
 142 2013-01-25 01:18:39 JZavala has joined
 143 2013-01-25 01:18:52 <CodeShark> I envision at least three different types of UI apps: wallets, network monitoring tools, and database query tools
 144 2013-01-25 01:20:48 <gavinandresen> man bitcoin transactions are fast, I'm always surprised when I send a test transaction from bitcoind on my machine to my blockchain.info wallet; poke return and get a "beep, new transaction" right away….
 145 2013-01-25 01:21:41 <CodeShark> what's the average hop number?
 146 2013-01-25 01:22:11 <HM> this reminds me, i need to look in to the networking code of bitcoind
 147 2013-01-25 01:22:36 <HM> how are messages routed? is it just flood with a hop count?
 148 2013-01-25 01:22:57 <gavinandresen> CodeShark: good question.  If I took a networking class in college I'd probably know the approximate answer for a randomly connected mesh network....
 149 2013-01-25 01:23:07 <gavinandresen> HM: it is just flood.  No hop count.
 150 2013-01-25 01:23:45 <HM> So a timeout?
 151 2013-01-25 01:23:50 <HM> :\
 152 2013-01-25 01:25:35 <gavinandresen> no, you tell all your peers when you have new data.  If they already know about the data, then they ignore the message.  If the don't, then they ask you for the data, then flood the "there is new data" message to their peers
 153 2013-01-25 01:25:49 <gavinandresen> (who either ignore it or request the data… etc)
 154 2013-01-25 01:26:46 <HM> makes sense
 155 2013-01-25 01:26:59 <gavinandresen> the new data ('inv') messages are tiny, so receiving them repeatedly isn't a big deal.
 156 2013-01-25 01:27:03 coblee_ has joined
 157 2013-01-25 01:28:01 <gavinandresen> And I may have the details wrong, the networking code isn't my strong suit
 158 2013-01-25 01:28:16 <HM> right, and the chance of a tree topology to connections where all the leaves come back to you is slim
 159 2013-01-25 01:29:05 <gavinandresen> yes, random-ness for the win
 160 2013-01-25 01:29:20 <HM> not to you rather, but to one poor SOAB
 161 2013-01-25 01:30:29 coblee has quit (Ping timeout: 252 seconds)
 162 2013-01-25 01:30:29 coblee_ is now known as coblee
 163 2013-01-25 01:32:53 <HM> the network bootstrapping looks gnarly
 164 2013-01-25 01:34:35 <etotheipi_> CodeShark: leaving it open is easy... I can have it specified in the options
 165 2013-01-25 01:35:55 <etotheipi_> so if the user has never installed Bitcoin-Qt, do I just bundle bitcoind binary, and run it in the default datadir?  also create a random bitcoin.conf username/pass?  rpc port should be standard so that trying to run installed bitcoin-qt fails
 166 2013-01-25 01:37:27 <CodeShark> I usually just create a random password and block external access to RPC
 167 2013-01-25 01:38:25 <CodeShark> and if I'm really paranoid, I create a special user just for the bitcoind instance and only give that user permissions to the datadir
 168 2013-01-25 01:38:43 <etotheipi_> oh, is there a way to specify a specific wallet.dat?  I want to make sure my bitcoind does not use their wallet.day
 169 2013-01-25 01:38:58 <CodeShark> specify a specific :)
 170 2013-01-25 01:39:18 <CodeShark> no, unfortunately the datadir is the datadir...for now
 171 2013-01-25 01:39:33 <CodeShark> but you can change the datadir in your own custom build
 172 2013-01-25 01:40:09 <etotheipi_> CodeShark: yes, but I want to avoid having blk files duplicated
 173 2013-01-25 01:41:53 <CodeShark> yeah, unfortunately the wallet stuff is mixed in with the blk stuff in the data dir right now
 174 2013-01-25 01:41:58 <CodeShark> it would be nice to decouple the two
 175 2013-01-25 01:42:14 <CodeShark> it would be entirely possible to do so
 176 2013-01-25 01:42:19 <CodeShark> they aren't even using the same db env
 177 2013-01-25 01:43:19 <CodeShark> the multiwallet version of bitcoin-qt I made can load arbitrary wallet files anywhere on the file system
 178 2013-01-25 01:57:45 da2ce7_d is now known as da2ce7
 179 2013-01-25 02:08:10 <etotheipi_> CodeShark: does it need the wallet before it loads?  does it need to do a rescan?  how long does the rescan take?
 180 2013-01-25 02:08:12 forloop has quit (Quit: Page closed)
 181 2013-01-25 02:08:44 EPiSKiNG- has joined
 182 2013-01-25 02:10:00 petertodd has quit (Remote host closed the connection)
 183 2013-01-25 02:12:13 petertodd has joined
 184 2013-01-25 02:14:24 darkskiez has quit (Ping timeout: 245 seconds)
 185 2013-01-25 02:15:46 petertodd has quit (Client Quit)
 186 2013-01-25 02:16:10 petertodd has joined
 187 2013-01-25 02:17:03 darkskiez has joined
 188 2013-01-25 02:25:38 Seeraber is now known as Seeraber|away
 189 2013-01-25 02:33:59 paraipan has quit (Quit: Saliendo)
 190 2013-01-25 02:34:55 <CodeShark> etotheipi_: "does it need the wallet before it loads?" not sure what you mean. "does it need to do a rescan?" it does if you want to know about transactions that occured since the last time you loaded that particular wallet. "how long dies the rescan take?" it only needs to rescan since the last block the wallet remembers, so not that long.
 191 2013-01-25 02:37:00 <etotheipi_> ugh, the "rescan from last block" scares me
 192 2013-01-25 02:37:28 <etotheipi_> i.e. wallet is created from offline computer whose clock was never synchrnoized
 193 2013-01-25 02:37:49 <etotheipi_> wallet is recovered after HDD failure and reports zero balance
 194 2013-01-25 02:38:15 <etotheipi_> or only partial balance, and maybe they don't notice...
 195 2013-01-25 02:38:56 <CodeShark> in principle it would be possible to only scan the utxo
 196 2013-01-25 02:39:10 <CodeShark> if all you're interested in is balance
 197 2013-01-25 02:39:59 <CodeShark> well, perhaps not...
 198 2013-01-25 02:40:06 <CodeShark> you need all unspent transactions - not just txouts
 199 2013-01-25 02:40:21 <CodeShark> wait, no...you also need the transactions that you've spent :p
 200 2013-01-25 02:40:37 JZavala has quit (Ping timeout: 240 seconds)
 201 2013-01-25 02:40:55 <etotheipi_> CodeShark: yeah, this is why I really want to see the Ultimate compression/trust-free lite nodes
 202 2013-01-25 02:40:57 toffoo has quit (Ping timeout: 276 seconds)
 203 2013-01-25 02:41:03 <etotheipi_> it totally changes the CONOPs for using Bitcoin, period
 204 2013-01-25 02:41:06 <etotheipi_> never need to rescan
 205 2013-01-25 02:41:14 <etotheipi_> no resource requirements for regular users
 206 2013-01-25 02:41:54 <CodeShark> the rescan isn't too terrible if you're not concerned with doing signature validation, though
 207 2013-01-25 02:41:57 <etotheipi_> but until then... I'm always rescanning because it sounds like a mess to risk losing coins like that
 208 2013-01-25 02:42:24 <etotheipi_> well presumably, even bitcoin-qt doesn't need to do signature validation on a sweep/import rescan
 209 2013-01-25 02:42:26 <CodeShark> you use a sliding checkpoint (say, 10 blocks ago)
 210 2013-01-25 02:42:30 toffoo has joined
 211 2013-01-25 02:42:34 <etotheipi_> since it's already verified the blockchain
 212 2013-01-25 02:43:12 <CodeShark> yeah
 213 2013-01-25 02:48:03 <CodeShark> actually, I take that back about knowing transactions you spent - if all you care about is balance (you don't care about history) then unspent outputs is enough
 214 2013-01-25 02:48:53 <CodeShark> in practice, users won't really find the block chain to give them much useful history
 215 2013-01-25 02:49:17 <CodeShark> they'll need to store account names and transaction history themselves
 216 2013-01-25 02:49:20 <CodeShark> and back it up
 217 2013-01-25 02:51:14 oMoMo has quit (Quit: sayonara)
 218 2013-01-25 02:51:58 <CodeShark> about the only clues that the block chain would provide are amounts and timestamp
 219 2013-01-25 02:52:41 <CodeShark> in practice, they won't remember to whom they gave the receiving address 1GtrAiHQLoMFV2WTLJkETsvcw4YeUj326B
 220 2013-01-25 02:53:25 <gmaxwell> gah
 221 2013-01-25 02:53:30 <gmaxwell> virgins debating sex
 222 2013-01-25 02:53:47 <gmaxwell> The rescan required to update the walt has ABSOLUTELY NOTHING TO DO WITH SIGNATURE VALIDATION
 223 2013-01-25 02:54:01 <CodeShark> that's what we both agreed upon
 224 2013-01-25 02:54:12 <gmaxwell> In the wallet it's by height— and scans a little before the recorded height. So there is no risk of clockwhatever.
 225 2013-01-25 02:54:37 <CodeShark> but we're not just talking about bitcoind
 226 2013-01-25 02:54:38 <gmaxwell> A scan of the whole chain (not just the recent blocks) is fairly fast— it takes a couple minutes.
 227 2013-01-25 02:55:06 <gmaxwell> Once the optional indexes are merged then those could be used if available.
 228 2013-01-25 02:57:17 <CodeShark> the rescan isn't a serious issue for the multiwallet bitcoin-qt stuff as of yet...at most it takes a few seconds to load a wallet
 229 2013-01-25 02:57:26 swappermall_ has joined
 230 2013-01-25 02:58:06 <CodeShark> even without the extra index stuff
 231 2013-01-25 02:58:28 <etotheipi_> gmaxwell: at least in my case, most of the wallets have never seen the blockchain
 232 2013-01-25 02:58:34 copumpkin has quit (Ping timeout: 245 seconds)
 233 2013-01-25 02:58:45 <CodeShark> etotheipi_ was referring to a difference scenario, though
 234 2013-01-25 02:58:55 <etotheipi_> and since rescanning the full chain takes 1-2 min, I just do it anyway... but I know it's not sustainable
 235 2013-01-25 02:59:09 copumpkin has joined
 236 2013-01-25 03:00:23 <CodeShark> you only really need to do that the first time - or you could give the user the option to either not rescan or give a height
 237 2013-01-25 03:00:51 <etotheipi_> eventually...
 238 2013-01-25 03:01:01 <etotheipi_> right now it's so fast it's not worth bothering the user about it
 239 2013-01-25 03:01:04 darkskiez has quit (Ping timeout: 245 seconds)
 240 2013-01-25 03:01:35 <etotheipi_> but I do know I'll need to address it eventually... I was hoping by just convincing the Bitcoin world to adopt ultimate blockchain compression and then no one deals with it ever again :)
 241 2013-01-25 03:01:46 <gmaxwell> etotheipi_: For your use case I'd expect you to require the bitcoind to have the optional indexes enabled.
 242 2013-01-25 03:02:28 <etotheipi_> but gmaxwell rightfully points out that's a big burden for miners... but I still think we should push for it anyway
 243 2013-01-25 03:03:00 <gmaxwell> You 'ultimate blockchain compression' doesn't solve this— you wouldn't get the history... and if you don't want the history things could already be obtained fast from the utxo set.
 244 2013-01-25 03:03:02 <etotheipi_> gmaxwell: well for me, I'm only using bitcoind as a regular peer...
 245 2013-01-25 03:03:16 <gmaxwell> etotheipi_: ah, well I mean assuming you used it over rpc.
 246 2013-01-25 03:03:25 darkskiez has joined
 247 2013-01-25 03:03:34 <etotheipi_> gmaxwell: yes, it only gets the balance
 248 2013-01-25 03:03:41 <etotheipi_> but the utxo set is indexed by txid, not address
 249 2013-01-25 03:03:48 <etotheipi_> so you still have to scan the whole thing
 250 2013-01-25 03:04:00 <etotheipi_> so lite nodes get no benefit unless peers are willing to scan the whole thing for you
 251 2013-01-25 03:04:43 <gmaxwell> etotheipi_: I'm not referring to lite nodes— indeed thats different. But nothing prevents a node for keeping whatever indexes it wants for its own usage, without burdening the network.
 252 2013-01-25 03:05:20 PhantomSpark has joined
 253 2013-01-25 03:06:13 toffoo has quit (Ping timeout: 256 seconds)
 254 2013-01-25 03:07:03 <etotheipi_> meh, well then you get centralization of the network around the few super-nodes that are willing to supply address indexes to all the lite nodes
 255 2013-01-25 03:07:16 <gmaxwell> As far as burdening miners go.... well it starts by ~doubling the storage and working set required... and makes a bunch of theoretically O(1)ish operations O(log n)ish.  I think it's hard to even talk about it being worth it without some difficult assumptions about the future uxto size.
 256 2013-01-25 03:08:14 <etotheipi_> gmaxwell: we've been through this before... I was just kind of recapping for CodeShark ... I don't have time to debate this again
 257 2013-01-25 03:08:16 <gmaxwell> etotheipi_: the price of index centeralization is a DOS attack on lite nodes though.. SPV security alone means all they could do is hide parts of the balance... and if the resonses are signed its easy to prove when someone lied.
 258 2013-01-25 03:09:12 <gmaxwell> oohkay.
 259 2013-01-25 03:09:17 <etotheipi_> I just think it's worth an awful lot to have a network that is usable by default in a fully decentralized fashion
 260 2013-01-25 03:09:33 <gmaxwell> I am giving you a dirty look.
 261 2013-01-25 03:09:38 <CodeShark> lol
 262 2013-01-25 03:09:47 <etotheipi_> haha
 263 2013-01-25 03:10:00 * etotheipi_ runs back to his quadruple vim session
 264 2013-01-25 03:10:18 <gmaxwell> I think it's worth an awful lot to have a decenteralized network at all— rather than having a centeralized one because an additional mandatory index increased update costs by as much as 50x.
 265 2013-01-25 03:10:40 <etotheipi_> gmaxwell: if it was 50x, I would agree with you
 266 2013-01-25 03:11:05 <gmaxwell> Thats log2(21e14)/1. It's an insanse example but its on the order of the upper bound possible.
 267 2013-01-25 03:11:09 <etotheipi_> but I guess I haven't plotted out worst cases yet
 268 2013-01-25 03:11:11 <etotheipi_> I'm too buy
 269 2013-01-25 03:11:13 jaakkos has joined
 270 2013-01-25 03:11:18 <etotheipi_> *busy
 271 2013-01-25 03:11:53 <etotheipi_> gmaxwell: you are not oging to have more addresses than utxos
 272 2013-01-25 03:12:02 <gmaxwell> Realistically O(1) isn't quite the right case... making atomic group updates to non-tree datastrutures without writing the whole thing is hard.
 273 2013-01-25 03:12:15 <gmaxwell> etotheipi_: yes, thats assuming there is 1 address per 1 utxo per 1 satoshi.
 274 2013-01-25 03:12:32 toffoo has joined
 275 2013-01-25 03:12:41 <etotheipi_> gmaxwell: where does the 50x come from, then?
 276 2013-01-25 03:12:51 <CodeShark> don't forget it's also possible to send 0 satoshis :p
 277 2013-01-25 03:12:57 <gmaxwell> And in that case being forced to use a tree (for a efficient merkelized data structure) over a hash table lookup is a factor of 50.
 278 2013-01-25 03:13:06 <jaakkos> I was thinking, transaction scripts could be used to implement a potentially powerful password cracking service. the script implements a hash function that is being attacked, requiring the input to be the plaintext that's hashed into the target hash. to claim the transaction's value, the plain password needs to be recovered and published.
 279 2013-01-25 03:13:26 <gmaxwell> jaakkos: https://en.bitcoin.it/wiki/User:Gmaxwell/why_hash_locked
 280 2013-01-25 03:13:51 <gmaxwell> CodeShark: yea, my evil roadmap has removing that on it.
 281 2013-01-25 03:14:02 <gmaxwell> (or rather making it impossible to create zero value outputs)
 282 2013-01-25 03:14:34 <gmaxwell> Dunno if that'll ever happen, but I think it should. It would be premature to do it now.
 283 2013-01-25 03:14:53 <CodeShark> it should have been done from the beginning, IMHO
 284 2013-01-25 03:14:58 <etotheipi_> gmaxwell: I still don't see it... PATRICIA trees are O(1) for query, insert and delete
 285 2013-01-25 03:15:03 <etotheipi_> it's more a question of constant factors
 286 2013-01-25 03:15:13 <gmaxwell> CodeShark: it was an oversight. The refernce code will never create one.
 287 2013-01-25 03:15:30 <gmaxwell> etotheipi_: they are not O(1) I/O for query. you have to visit the intermediate nodes.
 288 2013-01-25 03:15:32 <etotheipi_> I agree there may be a large constant factor on the patricia ops
 289 2013-01-25 03:15:50 <gmaxwell> Well okay, you're just hiding it in the constant factors then.
 290 2013-01-25 03:16:05 <etotheipi_> gmaxwell: if you use a 256-way trie, you do exactly 20 hops every time no matter how many nodes there are
 291 2013-01-25 03:16:21 <etotheipi_> the fact that patricia trees are compressed is a bonus... even though it looks like you're doing more work with more nodes
 292 2013-01-25 03:16:30 <etotheipi_> it's bounded by O(1)
 293 2013-01-25 03:17:16 <gmaxwell> Everything is bounded by O(1)— we have one universe. Everything we do can be completely during its life.   Step. {run universe} done. :P
 294 2013-01-25 03:17:29 <gmaxwell> etotheipi_: in any case, thats my concern.
 295 2013-01-25 03:17:48 <etotheipi_> gmaxwell: my point is you wouldn't be making that statement if I was using a trie
 296 2013-01-25 03:17:54 <etotheipi_> because there's no question a trie is O(1)
 297 2013-01-25 03:18:00 <etotheipi_> and it would be on average 6 hops
 298 2013-01-25 03:18:08 <etotheipi_> to get from root to node
 299 2013-01-25 03:18:10 <CodeShark> gmaxwell, does lim{n->oo} exist in that universe?
 300 2013-01-25 03:18:45 <etotheipi_> the maximum is probably 10 (if two addresses have the same first 10 bytes)
 301 2013-01-25 03:19:09 <etotheipi_> (err 6 avg, probably 10 max... for the compressed trie)
 302 2013-01-25 03:19:15 <gmaxwell> etotheipi_: and perhaps you've forgotten— I proposed a committed utxo query a long time before you— its not that I don't like the idea. I'm just concerned that it may not quite be viable.
 303 2013-01-25 03:19:31 <etotheipi_> gmaxwell: I know you have proposed such ideas
 304 2013-01-25 03:19:47 <etotheipi_> I just think you're overstating the resource requirements for it
 305 2013-01-25 03:19:52 <etotheipi_> I don't disagree it's a burden
 306 2013-01-25 03:19:59 <jaakkos> gmaxwell: indeed that is a major problem with such service ;) thanks for your interesting wiki article!
 307 2013-01-25 03:20:15 PhantomSpark has quit (Ping timeout: 276 seconds)
 308 2013-01-25 03:20:20 <etotheipi_> but I think it's worth consideration, given the optimality it provides all other users of the network
 309 2013-01-25 03:20:35 <gmaxwell> jaakkos: we don't actually have hash functions that are useful for password cracking, though as I show— with some deep crypto magic, we don't have to.
 310 2013-01-25 03:20:58 <jaakkos> gmaxwell: perhaps you could implement them in the script.
 311 2013-01-25 03:21:09 <jaakkos> gmaxwell: you could unroll loops unless it's something like pbkdf2
 312 2013-01-25 03:21:09 <gmaxwell> jaakkos: Totally undesirable and unneeded.
 313 2013-01-25 03:21:49 <gmaxwell> Bitcoin is a currency not a password cracking service— many bitcoin users would be _opposed_ to it being used for that, but besides, increasing the cost of script validation would harm the network.
 314 2013-01-25 03:22:30 <gmaxwell> But as I pointed out, existing script is at least theoretically sufficient to bind any computer proof to a transaction.
 315 2013-01-25 03:23:38 <gmaxwell> etotheipi_: absolutely. It's certantly worth consideration— I think at this point it needs implementation, not consideration.
 316 2013-01-25 03:24:14 <etotheipi_> gmaxwell: fair enough
 317 2013-01-25 03:24:24 <etotheipi_> I thought you had pretty much just written it off
 318 2013-01-25 03:24:24 <gmaxwell> There are a bunch of questions like "how does lookup not become linear complexity— and totally unbalance the hash tree— when many txn are sent to one address" which are probably easily answered with an implementation.
 319 2013-01-25 03:25:13 <etotheipi_> gmaxwell: I totally want to make an implementation, I just want to make sure you understand the properties of what I'm proposing... you're welcome to still not like it after that
 320 2013-01-25 03:25:14 <etotheipi_> :)
 321 2013-01-25 03:25:26 <etotheipi_> how does it get unbalanced?
 322 2013-01-25 03:25:37 <etotheipi_> you can't have an unbalanced trie-structure
 323 2013-01-25 03:25:46 <etotheipi_> or rather, you can't have anything that would cause greater than 20 hops
 324 2013-01-25 03:25:47 <gmaxwell> etotheipi_: what happens when you have 1000 million outputs assigned to the same key?
 325 2013-01-25 03:25:51 <jaakkos> gmaxwell: note that i wasn't proposing any modifications to the language, though (except perhaps enabling some of the disabled functions). but of course the validation would be very expensive when it gets complicated.
 326 2013-01-25 03:26:22 <etotheipi_> gmaxwell: those outputs are stored in the same O(1)-bounded data structure
 327 2013-01-25 03:26:28 <gmaxwell> jaakkos: we don't have looping for a reason, likewise the small maximum size. :P
 328 2013-01-25 03:27:14 <etotheipi_> it still feels like you are taking a one-time 2x increase in HDD consumption...
 329 2013-01-25 03:27:16 <petertodd> jakkos: that's the problem with your idea: password algorithms are designed to be difficult to evaluate, and it's unacceptable for any tx operation to take any length of time
 330 2013-01-25 03:27:31 <asoltys> hi, i'm running a relay-only node on a vps and i just ran out of disk space.  is there anything i can do yet to prune or compress the blockchain? any documentation you can point me to?
 331 2013-01-25 03:27:37 <gmaxwell> asoltys: No.
 332 2013-01-25 03:27:46 <asoltys> gmaxwell: ok, thanks. coming soon though right?
 333 2013-01-25 03:27:49 <gmaxwell> asoltys: No.
 334 2013-01-25 03:27:52 <asoltys> doh
 335 2013-01-25 03:28:14 <gmaxwell> (0.8.x does use a little less space, but it won't buy you much time on its own)
 336 2013-01-25 03:29:33 <gmaxwell> etotheipi_: if I thought it were only the 2x increase... Bt I don't see how you're 20 hop bounded if an address can have a trillion payments assigned to it. Think about updating the hash root when adding one more. Also, of course, when you query that node you get an instant dos attack... but thats an implementation more than a datastructure issue.
 337 2013-01-25 03:30:34 <etotheipi_> gmaxwell... if you were using raw tries... it would be 20 hops to get to any address leaf, and then 32 hops to get the whichever utxo you're looking for in the subtree
 338 2013-01-25 03:30:41 toffoo has quit (Ping timeout: 255 seconds)
 339 2013-01-25 03:30:53 <etotheipi_> but you're right, it's not 2x, because I didn't realize you were using hashtables for the tx-indexed UTXO set
 340 2013-01-25 03:31:10 <gmaxwell> We're not currently. We _could_.
 341 2013-01-25 03:31:17 <etotheipi_> err.. yeah
 342 2013-01-25 03:31:24 <etotheipi_> I know you're not, but I didn't know that's what you were comparing against
 343 2013-01-25 03:32:19 <etotheipi_> err.. 20 + 36 actually
 344 2013-01-25 03:32:52 <gmaxwell> okay, so if you make the txid/vout part of the key then yes, I see that staying balanced at least... but yor constant factor goes up a lot.
 345 2013-01-25 03:32:53 <etotheipi_> even if you used a raw trie... in terms of computation time (not HDD, which would be a disaster for a raw trie), your doing 56 dereferences to get to your UTXO
 346 2013-01-25 03:33:26 <etotheipi_> in reality, most addresses will only have a couple UTXOs and it will be 2 hops...
 347 2013-01-25 03:33:42 <gmaxwell> no no, can't think that way. Assume the data is malicious.
 348 2013-01-25 03:34:01 <etotheipi_> gmaxwell: not sure about that
 349 2013-01-25 03:34:02 devrandom has joined
 350 2013-01-25 03:34:18 <etotheipi_> unless you're assuming that the *majority* of your nodes are malicious
 351 2013-01-25 03:34:21 <gmaxwell> etotheipi_: an implementation of just the core— some dookhicky which could take atomic updates and return a hash root, and queries and return a SPV fragment and result..  expose it to the internet and we get bounties on breaking it. :P
 352 2013-01-25 03:35:03 <etotheipi_> my point was that worst case is still nicely bounded (in compute time, not HDD space)... and thus malicious entities creating addresses will 100million UTXOs are not to be feared
 353 2013-01-25 03:35:04 <gmaxwell> etotheipi_: I don't see how majority of nodes matters, I mean— I can buy that attackers can't get a lot of off-by-one txids or addresses... but they can surely send lots of txs to a single address.
 354 2013-01-25 03:35:25 <etotheipi_> gmaxwell: my point is that a majority of addresses will not have 100 million addresses
 355 2013-01-25 03:35:50 <etotheipi_> I'm only concerned that worst case is nicely bounded so that there's no real threat from some malicious people doing htis
 356 2013-01-25 03:36:05 b4epoche has quit (Ping timeout: 245 seconds)
 357 2013-01-25 03:36:20 <gmaxwell> etotheipi_: if having one breaks you, I create one that is like that.. and I query it a lot and knock over nodes. ... and sure, so long as you're worrying about the bounds of the worst case thats fine— your statement that the average won't be like that was what concerned me.
 358 2013-01-25 03:36:24 <etotheipi_> but even if 100 people started cramming 100 addresses each with millions of UTXOs, the majority of the network is still operating with non-mailicious nodes
 359 2013-01-25 03:37:12 <gmaxwell> I think we're talking past each other. I apparently misunderstood you when you mentioned average.
 360 2013-01-25 03:37:14 <etotheipi_> some of your transactions take 20 hops after finding the address... but most only take 2
 361 2013-01-25 03:37:57 <etotheipi_> gmaxwell: okay... I'm a little brain-cluttered tonight
 362 2013-01-25 03:38:11 <etotheipi_> I keep mistyping things too... but I think this is constructive
 363 2013-01-25 03:38:32 b4epoche has joined
 364 2013-01-25 03:38:39 <etotheipi_> gmaxwell: my operating assumption was that computation should not be an issue at all... only disk space
 365 2013-01-25 03:39:05 <gmaxwell> I think that I/O bandwidth is by far more concerning that space, assuming that space is at least vaguely reasonable.
 366 2013-01-25 03:39:06 <etotheipi_> you're challenging it and making me justify it, but I still think it's valid
 367 2013-01-25 03:39:34 <etotheipi_> disk I/O?  or network I/O?
 368 2013-01-25 03:39:37 <gmaxwell> Overall growths of storage and local computation have been very rapid.. memory and storage bandwidth seem to be growing hardly better than linearly.
 369 2013-01-25 03:40:22 <gmaxwell> disk/memory IO.  Less so network (or at leat that matters too, but if you don't have horrible disk IO requirements the network won't be bad)
 370 2013-01-25 03:40:52 <gmaxwell> E.g. if your alg has to visit 100 nodes then the SPV proof will be quite big.
 371 2013-01-25 03:41:07 <gmaxwell> But before you'd even care about the proof size— doing 100 seeks would already kill you.
 372 2013-01-25 03:41:15 <etotheipi_> well how bad can it be?  what are plans for expanding block sizes
 373 2013-01-25 03:41:42 <etotheipi_> I mean, 1 MB every 10 minutes (expanded maybe 10x for space-inefficient algorithms) doesn't seem like a lot
 374 2013-01-25 03:42:14 <gmaxwell> There are currently no plans, and I'm of the opinion that it should either never be done, or only be done very conservatively.  But obviously it shouldn't be designed assuming that it won't be increased.
 375 2013-01-25 03:42:24 <gmaxwell> 1MB/10minutes does add up!
 376 2013-01-25 03:42:48 <etotheipi_> gmaxwell: but that's only 10MB/10min of *updates*
 377 2013-01-25 03:42:53 <etotheipi_> not space increase
 378 2013-01-25 03:43:26 <etotheipi_> I like visualizing the network as a bubble... the blockchain is its area, and the UTXO set is the outer surface
 379 2013-01-25 03:43:26 <gmaxwell> Yes, though right now most txn are increasing the utxo set size. :(
 380 2013-01-25 03:43:46 <gmaxwell> etotheipi_: that scaling law doesn't reflect current behavior. :(
 381 2013-01-25 03:43:57 <gmaxwell> But maybe thats short term.
 382 2013-01-25 03:44:18 <etotheipi_> gmaxwell: yes, there is probably some constant growth term
 383 2013-01-25 03:44:22 <etotheipi_> added on
 384 2013-01-25 03:44:53 <gmaxwell> well if we don't find a way to discourage blockchain-for-IM (e.g. by providing alternatives) that term will be large and become larger.
 385 2013-01-25 03:45:03 <etotheipi_> lol
 386 2013-01-25 03:45:14 <etotheipi_> I already had someone pushing me to help implement that in Armory
 387 2013-01-25 03:45:30 <gmaxwell> Bitcoin accidentally invented another kind of network service that doesn't otherwise exist: an anonymous flooding messaging network.
 388 2013-01-25 03:46:02 <gmaxwell> etotheipi_: you laugh but effectively thats what SD is doing with their 1e-8 payments to signify 'you lost'.. They never get spent. They're just am IM in the blockchain.
 389 2013-01-25 03:46:18 <gmaxwell> and of course lots of other people are trying to do it— and either failing or getting talked out of it.
 390 2013-01-25 03:47:52 <etotheipi_> gmaxwell: I bet there's a way to actually pay users to clean up their dust
 391 2013-01-25 03:48:12 <etotheipi_> find a way to actually give users money for transactions that have 300 inputs and 1-2 outputs
 392 2013-01-25 03:48:15 <gmaxwell> Yep. The problem is how to align the incentives for both users and miners.
 393 2013-01-25 03:48:40 <gmaxwell> One thing I want us to do very soon (perhaps for 0.8) is changing the priority for free transactions to be strongly based on the UTXO impact.
 394 2013-01-25 03:49:00 <gmaxwell> Once thats done it'll be very justifyable for wallet software to pick inputs heedful of that.
 395 2013-01-25 03:49:30 <gmaxwell> etotheipi_: one thing you need to worry about though is whatever you do you don't want people to create utxos just to later spend them for whatever benefit you provide.
 396 2013-01-25 03:49:48 <etotheipi_> like maybe miners can have a gentleman's agreement that they will add a 0.05 output from their coinbase to an address that combines hundreds of outputs into exactly 1 output
 397 2013-01-25 03:50:33 <etotheipi_> given how crazy phobic users are from paying a $0.001 fee... I bet they would get irrationally excited about making $0.001 for simply executing a tx
 398 2013-01-25 03:50:37 <petertodd> It's too bad the core algorithms aren't such that reducing the UTXO out set actually makes a block inherently more likely to be confirmed... possibly something worth thinking about for any UTXO proposals.
 399 2013-01-25 03:50:41 fiesh has quit (Ping timeout: 244 seconds)
 400 2013-01-25 03:51:16 <etotheipi_> it would definitely cost you more to create 300 outputs than you would gain for converting 300->1
 401 2013-01-25 03:51:26 <petertodd> For instance, deletions of the UTXO set need to be at least as efficient, and preferably more, than adding.
 402 2013-01-25 03:52:00 <petertodd> etotheipi: So that's inherently true with these trie and what not data structures?
 403 2013-01-25 03:52:23 HM has quit (Ping timeout: 252 seconds)
 404 2013-01-25 03:52:37 <etotheipi_> petertodd: yes, they're strictly bounded O(1) for query, insert and deletion
 405 2013-01-25 03:52:48 <etotheipi_> the question is whether feasible worst case is too much, evne if it's O(1)
 406 2013-01-25 03:52:52 <gmaxwell> etotheipi_: unfortunately most miners are not thinking deeply about the long term future of the network.
 407 2013-01-25 03:53:00 <petertodd> etotheipi: good to hear
 408 2013-01-25 03:53:04 <gmaxwell> "MY GPU SHITS MONEY! HURRAY!"
 409 2013-01-25 03:53:15 <petertodd> Long-term is someone elses problem.
 410 2013-01-25 03:53:34 CodesInChaos has quit (Ping timeout: 245 seconds)
 411 2013-01-25 03:53:35 <petertodd> The mining section of the forums is one of the worst cesspits.
 412 2013-01-25 03:53:38 <etotheipi_> petertodd: it's true that even if there were 1e30 UTXOs it would be less than 100 disk seeks
 413 2013-01-25 03:53:49 <etotheipi_> but 100 disk seeks is probably too much
 414 2013-01-25 03:53:59 <etotheipi_> we.. 56 disk seeks would be the max
 415 2013-01-25 03:54:04 <petertodd> Yeah, 100*1mS=0.1s...
 416 2013-01-25 03:54:14 D34TH has quit (Read error: Connection reset by peer)
 417 2013-01-25 03:54:21 <gmaxwell> etotheipi_: maybe we can get away with default fee rules that increase the fees required for bloating txn... Maybe. But the first time someone sees a txn with 0.1 BTC fees and 400 outputs not get mined they'll be looking for the switch to disable that feature.
 418 2013-01-25 03:54:36 fiesh has joined
 419 2013-01-25 03:54:52 <petertodd> Keep in mind that there are solid physical reasons why io for *any* storage type will increase much slower than storage capacity. Basically, the world is 3d, and heat dissippation is limited by surface area.
 420 2013-01-25 03:55:27 denisx has quit (Quit: denisx)
 421 2013-01-25 03:55:28 <petertodd> Ultimately the problem is there aren't any other ways of doing BTC micropayments, and there won't be for some time.
 422 2013-01-25 03:55:31 <etotheipi_> petertodd: but it looks like even for 21e14 UTXOs, there would be a max of 8 seeks, period
 423 2013-01-25 03:55:40 <etotheipi_> not max, but like 95th percentile
 424 2013-01-25 03:55:51 HM has joined
 425 2013-01-25 03:55:53 <etotheipi_> and it might be possible to optimize the disk layout to make it very efficient
 426 2013-01-25 03:56:10 <petertodd> So long as you can keep the disk layout efficient as it gets updated...
 427 2013-01-25 03:56:16 <etotheipi_> and on the upside, it's very easy to parallelize, but you don't want to rely on that
 428 2013-01-25 03:56:29 <etotheipi_> the parallelization should be a bonus, not a requirement
 429 2013-01-25 03:56:59 <petertodd> Parallization will come naturally as we move away from harddrives anyway, but the underlying 3d vs 2d surface area will be a constraint.
 430 2013-01-25 03:57:11 andytoshi has quit (Quit: WeeChat 0.3.9.2)
 431 2013-01-25 03:57:57 <petertodd> Personally I think we're getting off focusing on making ways for people to move away from working with Bitcon proper directly, and moving to stuff linked to it. Or at least having that as an option.
 432 2013-01-25 03:58:06 <etotheipi_> on the upside.... as I just pointed out... the number of seeks/hops is pretty much constant
 433 2013-01-25 03:58:13 <kjj> in Hausdorff terms, most storage is very nearly 2d, and the busses are 1d
 434 2013-01-25 03:58:16 andytoshi has joined
 435 2013-01-25 03:58:18 <etotheipi_> the question is whether that constant fits into the current systems
 436 2013-01-25 03:58:31 <etotheipi_> if it does, it should only get better relative to future growth
 437 2013-01-25 03:59:24 <etotheipi_> dammit... I ended up spending half my night debating UTXO trees again!
 438 2013-01-25 04:00:05 <petertodd> kjj: yup, we still make IC's by stacking a relatively small number of layers. We may never find ways to make the Z axis density anything like the X and Y.
 439 2013-01-25 04:00:55 <etotheipi_> gmaxwell: I don't get it.... " But the first time someone sees a txn with 0.1 BTC fees and 400 outputs not get mined they'll be looking for the switch to disable that feature."
 440 2013-01-25 04:01:06 <kjj> still lots of room at the bottom.  the cool part is that 2d interfaces are coming soon
 441 2013-01-25 04:01:28 <etotheipi_> who turns off what feature?
 442 2013-01-25 04:01:51 <petertodd> kjj: even the limited extent that 2d interfaces already exist is a horrid nightmare: what axis do you use for your test probes?
 443 2013-01-25 04:01:53 <kjj> the user.  they want that 0.1 BTC fee.  that's friggin huge
 444 2013-01-25 04:02:21 <petertodd> Well, the user will find a miner who have turned the feature off.
 445 2013-01-25 04:03:00 <petertodd> The problem is that the only incentive for miners is not to create big blocks, the block's effect ont he utxo set is irrelevant.
 446 2013-01-25 04:03:31 <etotheipi_> petertodd: that's not true... in the future miners will be able to operate with only the UTXO set
 447 2013-01-25 04:03:36 <petertodd> You could try systems that discourage blocks, but they risk forking the chain.
 448 2013-01-25 04:04:22 <petertodd> etotheipi: Right, but the miner operating the the UTXO set only has nothing to do with the content of the block.
 449 2013-01-25 04:04:43 <petertodd> etotheipi: Any individual block changes the set so little that it's hard to have a real reason to discourage.
 450 2013-01-25 04:05:40 meLon has joined
 451 2013-01-25 04:05:41 meLon has quit (Changing host)
 452 2013-01-25 04:05:41 meLon has joined
 453 2013-01-25 04:10:12 toffoo has joined
 454 2013-01-25 04:11:54 Cory has quit (Ping timeout: 245 seconds)
 455 2013-01-25 04:14:35 Cory has joined
 456 2013-01-25 04:18:20 * jgarzik karma-tips gmaxwell, for having the patience to bother arguing with kano
 457 2013-01-25 04:19:12 <SomeoneWeird> lol
 458 2013-01-25 04:19:16 bitafterbit has quit (Read error: Connection reset by peer)
 459 2013-01-25 04:21:49 dust-otc has joined
 460 2013-01-25 04:23:10 darkskiez has quit (Ping timeout: 245 seconds)
 461 2013-01-25 04:23:51 swappermall_ has quit (Ping timeout: 256 seconds)
 462 2013-01-25 04:24:17 HM has quit (Ping timeout: 252 seconds)
 463 2013-01-25 04:25:31 darkskiez has joined
 464 2013-01-25 04:25:57 HM has joined
 465 2013-01-25 04:32:48 dust-otc has quit (Read error: Connection reset by peer)
 466 2013-01-25 04:33:20 dust-otc has joined
 467 2013-01-25 04:34:38 [7] has quit (Disconnected by services)
 468 2013-01-25 04:34:47 TheSeven has joined
 469 2013-01-25 04:36:30 ThomasV has joined
 470 2013-01-25 04:39:38 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 471 2013-01-25 04:39:46 Seeraber is now known as Seeraber|away
 472 2013-01-25 04:39:47 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 473 2013-01-25 04:51:04 <Luke-Jr> whoa, it's *possible* to argue with kano?
 474 2013-01-25 04:58:35 <vazakl> sup
 475 2013-01-25 05:09:47 Seeraber is now known as Seeraber|away
 476 2013-01-25 05:18:21 RainbowDashh has joined
 477 2013-01-25 05:32:07 RainbowDashh has quit (Quit: Computer has gone to sleep.)
 478 2013-01-25 05:35:45 [\\\] has quit (Remote host closed the connection)
 479 2013-01-25 05:37:31 [\\\] has joined
 480 2013-01-25 05:42:12 yareyare has joined
 481 2013-01-25 05:43:26 toffoo has quit (Ping timeout: 255 seconds)
 482 2013-01-25 05:44:35 toffoo has joined
 483 2013-01-25 05:52:27 RainbowDashh has joined
 484 2013-01-25 05:57:40 grau has joined
 485 2013-01-25 06:00:09 LargoG has quit (Remote host closed the connection)
 486 2013-01-25 06:05:55 Belkaar has quit (Ping timeout: 248 seconds)
 487 2013-01-25 06:08:47 Belkaar has joined
 488 2013-01-25 06:09:46 <JyZyXEL> i wonder if its normal to have the blockchain download and verify take days
 489 2013-01-25 06:10:49 <yareyare> yes
 490 2013-01-25 06:11:31 archy has joined
 491 2013-01-25 06:13:16 <JyZyXEL> isn't this a problem?
 492 2013-01-25 06:14:21 <CodeShark> yes, it is - which is why in the future, most clients probably won't be doing a full verification of the entire block chain
 493 2013-01-25 06:16:02 <andytoshi> JyZyXEL: version 0.8 will have some dramatic speedups
 494 2013-01-25 06:16:09 <andytoshi> but yes, there will be a transition to lite clients
 495 2013-01-25 06:16:15 <JyZyXEL> it would seem it is a storage i/o bandwidth limited operation
 496 2013-01-25 06:18:27 <CodeShark> the biggest bottleneck is actually the signature validation
 497 2013-01-25 06:18:49 <andytoshi> i don't think it needs to be so I/O limited..the new database should improve that
 498 2013-01-25 06:19:00 <andytoshi> it is validation that takes forever, but you can see the HDD light blinking
 499 2013-01-25 06:19:06 <andytoshi> so i dunno what it's up to
 500 2013-01-25 06:19:41 <CodeShark> it could use a sliding checkpoint - say, only validate signatures for the last n blocks
 501 2013-01-25 06:19:42 <JyZyXEL> well at least in 0.6.2 i don't see much CPU usage but the hard disks are making noises that sound like they are under a serious load
 502 2013-01-25 06:20:09 <JyZyXEL> and the whole OS is a bit sluggish because of it
 503 2013-01-25 06:21:20 <CodeShark> 6.2 is still using berkeley db for blktree, right?
 504 2013-01-25 06:21:34 <JyZyXEL> ill try upgrading to 0.7.2
 505 2013-01-25 06:21:43 <CodeShark> JyZyXEL: the latest version is using leveldb instead of berkeley db
 506 2013-01-25 06:21:52 Belkaar has quit (Ping timeout: 252 seconds)
 507 2013-01-25 06:22:09 <CodeShark> it's a lot faster
 508 2013-01-25 06:25:19 Belkaar has joined
 509 2013-01-25 06:33:05 grau has quit (Remote host closed the connection)
 510 2013-01-25 06:37:15 <SomeoneWeird> oh it's not berkeley db anymore?
 511 2013-01-25 06:37:17 <SomeoneWeird> TIL
 512 2013-01-25 06:37:54 <andytoshi> SomeoneWeird: it's berkeley up to v0.8
 513 2013-01-25 06:37:59 <gmaxwell> CodeShark: no, the not yet released version.  0.7.2 is the same as 0.6.2 except less horrible fatal bugs.
 514 2013-01-25 06:38:00 <andytoshi> which i don't think is out yet
 515 2013-01-25 06:38:15 <gmaxwell> as andytoshi says
 516 2013-01-25 06:38:21 Belkaar has quit (Ping timeout: 252 seconds)
 517 2013-01-25 06:38:31 <gmaxwell> 21:57 < CodeShark> yes, it is - which is why in the future, most clients probably won't be doing a full verification of the entire block chain
 518 2013-01-25 06:38:51 mariusursache has joined
 519 2013-01-25 06:38:54 <gmaxwell> There is absolutely no plan for that.
 520 2013-01-25 06:39:06 <gmaxwell> (in the reference software)
 521 2013-01-25 06:39:32 <gmaxwell> Things like starting off as SPV and verifying the chain in the background is a fine sort of thing.
 522 2013-01-25 06:39:39 <SomeoneWeird> ah, right
 523 2013-01-25 06:39:49 Belkaar has joined
 524 2013-01-25 06:39:49 <CodeShark> gmaxwell: I wasn't speaking of bitcoind
 525 2013-01-25 06:40:05 <gmaxwell> CodeShark: Yes, and there is no plan for that in bitcoind.
 526 2013-01-25 06:40:17 <CodeShark> I didn't say there was
 527 2013-01-25 06:40:45 <CodeShark> although bitcoind does have checkpoints
 528 2013-01-25 06:41:00 <gmaxwell> CodeShark: which do not disable validation.
 529 2013-01-25 06:41:13 <gmaxwell> E.g. you can't inflate the currency with fradulent checkpoints.
 530 2013-01-25 06:41:16 <CodeShark> so it isn't too big a stretch to think that eventually the checkpoint might just be n blocks ago
 531 2013-01-25 06:41:23 <SomeoneWeird> why don't they, gmaxwell ?
 532 2013-01-25 06:41:27 <CodeShark> whatever the current block is
 533 2013-01-25 06:41:43 bitnumus has quit (Read error: Connection reset by peer)
 534 2013-01-25 06:41:44 <gmaxwell> CodeShark: Yes actually it's an enormous streach... since they don't actually do what you seem to be thinking they do.
 535 2013-01-25 06:42:01 bitnumus has joined
 536 2013-01-25 06:42:18 <andytoshi> SomeoneWeird: it wouldn't fit with the trust model of bitcoin
 537 2013-01-25 06:42:31 <gmaxwell> You can't actually verify _any_ blocks unless you've observed all of them and advanced a coins database up to current.
 538 2013-01-25 06:43:40 <gmaxwell> as andytoshi says, philosophically— bitcoin is based on zero trust. Even the software is totally transparent and auditable, you're not depending on any magic numbers.  But more technically, it doesn't buy you much— as you can't validate new blocks without doing all the work on old ones in any case.
 539 2013-01-25 06:44:08 <SomeoneWeird> right
 540 2013-01-25 06:44:15 <SomeoneWeird> except depending on the genesis block :PP
 541 2013-01-25 06:44:24 Belkaar has quit (Ping timeout: 252 seconds)
 542 2013-01-25 06:45:02 <gmaxwell> CodeShark: And generally— it's not a question of startup time, it's a question of bandwidth (mostly) and storage (for the coins database).  There is no reason that all the validation can't be backgrounded in any client... but what security model you're able to use depends on the system capacity.
 543 2013-01-25 06:45:18 <gmaxwell> SomeoneWeird: the genesis block is actually created by the node at startup. :P
 544 2013-01-25 06:45:18 Belkaar has joined
 545 2013-01-25 06:45:25 <gmaxwell> the onlything magic in it is the nonce.
 546 2013-01-25 06:45:34 <SomeoneWeird> lmao
 547 2013-01-25 06:47:50 MrTiggr has quit (Ping timeout: 256 seconds)
 548 2013-01-25 06:51:15 <CodeShark> gmaxwell: I'm looking right now at the code for CTransaction::CheckInputs() - and I see it skips ECDSA verification for blocks before the last checkpoint
 549 2013-01-25 06:51:28 <CodeShark> so how is it different from the way I was understanding it?
 550 2013-01-25 06:51:43 <gmaxwell> checkpoints do a two fold thing— they force a particular chain— which mostly has the benefit of preventing a bunch of idiotic dos attacks where someone floods you with tens of gigabytes of blocks at difficulty 1 forked off the genesis.  And they disable the scriptsig (ECDSA) checks because they're computationally slow.
 551 2013-01-25 06:52:12 Belkaar has quit (Ping timeout: 255 seconds)
 552 2013-01-25 06:52:13 <gmaxwell> But all the other checks— including, importantly, the checks that coins are not double spent, that outputs sum to inputs, that the subsidy is correct are the same.
 553 2013-01-25 06:53:10 ithinktoomuch has joined
 554 2013-01-25 06:53:17 <CodeShark> I was only speaking of signature verification
 555 2013-01-25 06:53:44 <andytoshi> in theory, could you disable those checks and only do the merkle tree? would that give you something to compare against the checkpoint hash?
 556 2013-01-25 06:54:00 <gmaxwell> CodeShark: Then you're confused about how slow signature verification is... on a system here is only increases the time to sync by about 40% without checkpoints.
 557 2013-01-25 06:54:18 Belkaar has joined
 558 2013-01-25 06:54:26 HM has quit (Ping timeout: 252 seconds)
 559 2013-01-25 06:54:32 <CodeShark> 40% isn't insignificant and will probably grow as the average block size increases
 560 2013-01-25 06:55:04 <gmaxwell> It's cpu bound, it's much smaller with more cores.
 561 2013-01-25 06:55:23 <gmaxwell> on the 0.6.2 code you're talking about before it hardly makes a difference, all the time is spent on the DB.
 562 2013-01-25 06:55:45 brwyatt is now known as brwyatt|Away
 563 2013-01-25 06:55:57 <CodeShark> actually, JyZyXEL was talking about 0.6.2
 564 2013-01-25 06:56:07 HM has joined
 565 2013-01-25 06:56:13 <CodeShark> I quickly pointed out that 0.7.2's DB code is much faster
 566 2013-01-25 06:58:34 <gmaxwell> CodeShark: Well I guess I misunderstood you.  Someone complained it was taking days to validate, you responded "most clients probably won't be doing a full verification of the entire block chain" ... but performing the signature can't result in in that kind of slowness. There is only one the order of one cpu hour of signatures in the whole chain. So I mistakingly assumed you meant it wouldn't validate doublespends.
 567 2013-01-25 06:58:42 Belkaar has quit (Ping timeout: 252 seconds)
 568 2013-01-25 06:59:32 <CodeShark> SVP clients won't
 569 2013-01-25 06:59:40 <gmaxwell> SPV
 570 2013-01-25 06:59:49 <CodeShark> that's what I meant :p
 571 2013-01-25 07:00:11 <gmaxwell> CodeShark: ah, well if you want a spv client you can have one today. No future tense.
 572 2013-01-25 07:00:14 <gmaxwell> :P
 573 2013-01-25 07:00:23 <CodeShark> future tense on the "most"
 574 2013-01-25 07:00:39 <CodeShark> in the future, most clients will probably be SPV
 575 2013-01-25 07:00:44 <gmaxwell> Sorry. Been having a bad day here.
 576 2013-01-25 07:00:48 Belkaar has joined
 577 2013-01-25 07:00:58 <CodeShark> it's ok, gmaxwell - all's good :)
 578 2013-01-25 07:02:56 <CodeShark> I sold bitcoins yesterday at 18.5 and bought back at 16.3 today :)
 579 2013-01-25 07:03:33 <gmaxwell> Spiffy.
 580 2013-01-25 07:03:35 <gmaxwell> ;;ticker
 581 2013-01-25 07:03:35 <gribble> BTCUSD ticker | Best bid: 16.34848, Best ask: 16.46900, Bid-ask spread: 0.12052, Last trade: 16.34848, 24 hour volume: 172154.00718409, 24 hour low: 15.38613, 24 hour high: 19.18999, 24 hour vwap: 17.29215
 582 2013-01-25 07:04:06 <gmaxwell> ;;calc [ticker --last]/[ticker --high]
 583 2013-01-25 07:04:07 <gribble> 0.85192748928
 584 2013-01-25 07:04:59 Belkaar has quit (Ping timeout: 246 seconds)
 585 2013-01-25 07:07:21 ithinktoomuch has quit (Ping timeout: 245 seconds)
 586 2013-01-25 07:11:20 Belkaar has joined
 587 2013-01-25 07:13:49 spaz926 has joined
 588 2013-01-25 07:18:10 ovidiusoft has joined
 589 2013-01-25 07:20:17 HM has quit (Ping timeout: 252 seconds)
 590 2013-01-25 07:25:51 HM has joined
 591 2013-01-25 07:31:32 Belkaar has quit (Read error: Connection reset by peer)
 592 2013-01-25 07:32:23 HM has quit (Ping timeout: 252 seconds)
 593 2013-01-25 07:34:23 spaz926_ has joined
 594 2013-01-25 07:34:33 spaz926_ has quit (Client Quit)
 595 2013-01-25 07:35:50 HM has joined
 596 2013-01-25 07:38:26 spaz926 has quit (Ping timeout: 252 seconds)
 597 2013-01-25 07:38:48 Belkaar has joined
 598 2013-01-25 07:41:25 Spacey has joined
 599 2013-01-25 07:42:12 mappum has quit (Ping timeout: 256 seconds)
 600 2013-01-25 07:43:23 Belkaar has quit (Ping timeout: 252 seconds)
 601 2013-01-25 07:45:18 Belkaar has joined
 602 2013-01-25 07:50:37 b4epoche has quit (Ping timeout: 240 seconds)
 603 2013-01-25 07:52:12 Belkaar has quit (Ping timeout: 264 seconds)
 604 2013-01-25 07:52:49 Belkaar has joined
 605 2013-01-25 07:53:54 b4epoche has joined
 606 2013-01-25 07:58:47 toffoo has quit ()
 607 2013-01-25 08:03:52 pooler has joined
 608 2013-01-25 08:15:35 Insu has joined
 609 2013-01-25 08:16:44 <CodeShark> Say you have a resource R which is accessed by A, B, and C. Furthermore, say you don't care if B and C access it at the same time but don't want either of these accessing it at the same time as A. What's the best synchronization structure to use?
 610 2013-01-25 08:17:51 <CodeShark> you could use two separate mutexes - but it seems there must be a better way
 611 2013-01-25 08:18:18 <CodeShark> moreover, using two mutexes won't really handle the general case
 612 2013-01-25 08:18:28 <ThomasV> A needs two locks to access it, lockB and lockC
 613 2013-01-25 08:19:08 <CodeShark> but that won't really handle the general case
 614 2013-01-25 08:19:17 <ThomasV> define the general case
 615 2013-01-25 08:20:05 archy has quit (Quit: Page closed)
 616 2013-01-25 08:20:40 <CodeShark> ok, you have entities E = {A1, A2, A3, ...} which access resource R. define F(subset of E) == true iff all entities in the subset are allowed to access R at the same time
 617 2013-01-25 08:21:05 <SomeoneWeird> 0_o
 618 2013-01-25 08:21:06 <ThomasV> use an incremented lock
 619 2013-01-25 08:21:46 <CodeShark> how would incrementing help? it's not the number of accesses that's restricted - it's the combination of accesses
 620 2013-01-25 08:22:57 <CodeShark> I guess perhaps you need a separate lock for each maximal subset of E such that F(subset) == true
 621 2013-01-25 08:23:38 <CodeShark> seems like it could be optimized by using some sort of bitmask, though
 622 2013-01-25 08:26:48 <CodeShark> the actual use scenario I envision is not quite so general, though. For instance, say you have a function A which inserts an object into a list and function B which removes an object from a list. and functions f1, f2, f3, f4, ... which iterate over the objects in the list but don't alter the list itself
 623 2013-01-25 08:27:19 <CodeShark> you don't care if any of the f's run concurrently with other f's
 624 2013-01-25 08:27:33 rdymac has joined
 625 2013-01-25 08:27:48 <CodeShark> but you certainly never want an f running concurrently with either A nor B...nor would you want A and B running concurrently
 626 2013-01-25 08:28:22 <SomeoneWeird> when a starts increment a variable and when b starts increment it again and decrement when both are done, then when f{1-4} run check that the variable != 2
 627 2013-01-25 08:28:23 <SomeoneWeird> or something
 628 2013-01-25 08:28:24 <SomeoneWeird> idno
 629 2013-01-25 08:30:27 jdnavarro has joined
 630 2013-01-25 08:30:45 <CodeShark> a wait condition?
 631 2013-01-25 08:31:00 <CodeShark> sounds about right
 632 2013-01-25 08:32:05 <CodeShark> hmmm - so when A or B start, they own a lock. fns all wait until a condition variable is signaled, which occurs when A and B exit.
 633 2013-01-25 08:33:08 <CodeShark> but A and B also need to know when the f has exited. I know this is probably something covered in multithreading101...but I haven't really worked through many of these examples
 634 2013-01-25 08:33:57 CodesInChaos has joined
 635 2013-01-25 08:38:13 MaxSan1 has quit (Quit: Leaving.)
 636 2013-01-25 08:38:18 porquilho has joined
 637 2013-01-25 08:38:37 spaz926 has joined
 638 2013-01-25 08:52:05 rdymac has quit (Remote host closed the connection)
 639 2013-01-25 08:53:23 ThomasV has quit (Ping timeout: 248 seconds)
 640 2013-01-25 08:59:17 <sipa> CodeShark: there is something called a shared mutex
 641 2013-01-25 09:00:15 <sipa> which supports any number of threads taking a shared lock, or one process taking an exclusive lock
 642 2013-01-25 09:00:49 <sipa> but not shared and exclusive locks at the same time
 643 2013-01-25 09:01:02 <CodeShark> aha, I knew sipa would have the answer :)
 644 2013-01-25 09:04:00 <CodeShark> you're talking about boost::shared_lock?
 645 2013-01-25 09:07:01 jgarzik has quit (Read error: Operation timed out)
 646 2013-01-25 09:07:19 jgarzik has joined
 647 2013-01-25 09:07:43 jgarzik is now known as Guest84812
 648 2013-01-25 09:09:07 <sipa> CodeShark: yes, that's one implementation
 649 2013-01-25 09:09:23 agath has quit (Remote host closed the connection)
 650 2013-01-25 09:09:35 <CodeShark> just making sure it refers to the same concept
 651 2013-01-25 09:09:41 agath has joined
 652 2013-01-25 09:22:51 <CodeShark> strange...on a separate note, I've got a function written in two ways: one way takes the output as a reference parameter, the other returns the output. For some reason, returning the output is a lot faster and I'm not sure why: http://pastebin.com/LNjnyvdQ
 653 2013-01-25 09:24:35 <CodeShark> I would think that the for loop is where it spends the bulk of its time
 654 2013-01-25 09:25:32 <CodeShark> is accessing the referenced variable slower than accessing a local variable?
 655 2013-01-25 09:36:11 rdymac has joined
 656 2013-01-25 09:40:51 grau has joined
 657 2013-01-25 09:41:26 grau has quit (Remote host closed the connection)
 658 2013-01-25 09:42:38 JZavala has joined
 659 2013-01-25 09:46:03 <CodeShark> hmmm, in ubuntu the difference isn't as stark as in OS X
 660 2013-01-25 09:49:25 rdymac has quit (Ping timeout: 252 seconds)
 661 2013-01-25 09:58:41 copumpkin has quit (Ping timeout: 252 seconds)
 662 2013-01-25 09:59:16 copumpkin has joined
 663 2013-01-25 10:00:31 RazielZ has joined
 664 2013-01-25 10:03:19 rdponticelli has quit (Remote host closed the connection)
 665 2013-01-25 10:06:35 <sipa> CodeShark: which are 32 and 64 bit?
 666 2013-01-25 10:06:42 <CodeShark> 64 bit
 667 2013-01-25 10:06:43 rdponticelli has joined
 668 2013-01-25 10:06:45 <CodeShark> both
 669 2013-01-25 10:06:50 <sipa> hmm
 670 2013-01-25 10:06:54 <sipa> weird
 671 2013-01-25 10:07:06 <sipa> (that there's a difference)
 672 2013-01-25 10:07:33 <CodeShark> yeah, and I ran it several times and even swapped the order in which I did the two and consistently passing the reference variable takes longer
 673 2013-01-25 10:08:35 ByronJohnson has quit (Ping timeout: 252 seconds)
 674 2013-01-25 10:08:43 Impaler has quit (Read error: Connection reset by peer)
 675 2013-01-25 10:09:08 <CodeShark> here's another weird one: http://pastebin.com/6x1rZhee
 676 2013-01-25 10:09:50 Impaler has joined
 677 2013-01-25 10:10:07 <CodeShark> this one makes absolutely no sense whatsoever
 678 2013-01-25 10:10:25 <CodeShark> I even checked the CPU utilization to make sure that two cores are being used
 679 2013-01-25 10:11:36 one_zero has quit (Ping timeout: 245 seconds)
 680 2013-01-25 10:12:27 Belkaar has quit (Ping timeout: 255 seconds)
 681 2013-01-25 10:13:21 Belkaar has joined
 682 2013-01-25 10:14:28 rdymac has joined
 683 2013-01-25 10:17:44 Belkaar has quit (Ping timeout: 245 seconds)
 684 2013-01-25 10:19:52 Belkaar has joined
 685 2013-01-25 10:22:07 B0g4r7 has quit (Ping timeout: 276 seconds)
 686 2013-01-25 10:23:59 <CodeShark> it takes almost twice as long to do it with two threads than with one? WTF?!?!?!
 687 2013-01-25 10:24:10 <SomeoneWeird> lols
 688 2013-01-25 10:24:45 FredEE has quit (Quit: FredEE)
 689 2013-01-25 10:26:04 MC-Eeepc has quit (Ping timeout: 256 seconds)
 690 2013-01-25 10:26:30 Belkaar has quit (Ping timeout: 255 seconds)
 691 2013-01-25 10:26:35 B0g4r7 has joined
 692 2013-01-25 10:29:43 <sipa> CodeShark: is that in a VM or not?
 693 2013-01-25 10:29:51 Belkaar has joined
 694 2013-01-25 10:29:54 <CodeShark> I tried it both in and out of a VM
 695 2013-01-25 10:30:00 <sipa> ok
 696 2013-01-25 10:30:02 <CodeShark> in both cases, there was nearly a factor of 2
 697 2013-01-25 10:30:11 <CodeShark> and I'm sure I'm giving the VM two processors
 698 2013-01-25 10:30:29 <sipa> oo, that means the limiting factor is not CPU but memory access?
 699 2013-01-25 10:30:51 <sipa> seems reasonable for such a tight loop
 700 2013-01-25 10:31:09 <CodeShark> but the number of memory accesses is about the same in both cases, no?
 701 2013-01-25 10:31:34 <CodeShark> besides, for such a tight loop, wouldn't CPU registers be used?
 702 2013-01-25 10:31:38 <CodeShark> and the CPU cache?
 703 2013-01-25 10:31:42 ByronJohnson has joined
 704 2013-01-25 10:32:07 <CodeShark> I mean, unless the compiler absolutely sucks
 705 2013-01-25 10:32:41 <sipa> if both memory addresses are in the same cache row, the per-core cache becomes useless
 706 2013-01-25 10:33:13 <sipa> and i don't think the compiler can just turn explicit memory accesses into register updates
 707 2013-01-25 10:33:41 <CodeShark> so you're saying that it might be faster to use a local variable and then copy the result?
 708 2013-01-25 10:34:01 <sipa> yes
 709 2013-01-25 10:34:20 <CodeShark> let's test that hypothesis then :)
 710 2013-01-25 10:35:17 rdymac has quit (Remote host closed the connection)
 711 2013-01-25 10:35:53 <CodeShark> oh wow!
 712 2013-01-25 10:36:04 <CodeShark> you're right :)
 713 2013-01-25 10:36:26 <SomeoneWeird> sipa's always right
 714 2013-01-25 10:36:53 <sipa> 0 + 1 = 2
 715 2013-01-25 10:37:02 <SomeoneWeird> holy shit you broke maths
 716 2013-01-25 10:37:11 HM has quit (Ping timeout: 252 seconds)
 717 2013-01-25 10:38:41 <CodeShark> http://pastebin.com/Mi9mnfKz
 718 2013-01-25 10:39:01 <CodeShark> I still don't understand why such a difference, though
 719 2013-01-25 10:39:08 <CodeShark> more than three times as fast using two threads
 720 2013-01-25 10:39:21 <CodeShark> nearly four times faster
 721 2013-01-25 10:40:20 <CodeShark> wide variations, though
 722 2013-01-25 10:40:29 <CodeShark> I ran it again and it only took 10.5 secs to do one thread
 723 2013-01-25 10:40:46 <CodeShark> but that's inside a VM
 724 2013-01-25 10:40:50 <CodeShark> so it might be a scheduling issue
 725 2013-01-25 10:41:20 <CodeShark> but yeah, in general I'm getting > 2x
 726 2013-01-25 10:41:23 <CodeShark> which is strange
 727 2013-01-25 10:41:36 <CodeShark> I would think it would be slightly less than 2x
 728 2013-01-25 10:42:47 reizuki__ has quit (Read error: Connection reset by peer)
 729 2013-01-25 10:43:13 reizuki__ has joined
 730 2013-01-25 10:43:13 reizuki__ has quit (Changing host)
 731 2013-01-25 10:43:13 reizuki__ has joined
 732 2013-01-25 10:45:17 ThomasV has joined
 733 2013-01-25 10:45:34 FredEE has joined
 734 2013-01-25 10:46:28 <CodeShark> that might have to do with virtualization and scheduling, though
 735 2013-01-25 10:46:28 HM has joined
 736 2013-01-25 10:46:29 <CodeShark> dunno
 737 2013-01-25 10:46:38 <ThomasV> blockchain.info does display multisig addresses, but it seems to fail with recent (unconfirmed) ones: http://blockchain.info/address/3Lip6sxQymNr9LD2cAVp6wLrw8xdKBdYFG
 738 2013-01-25 10:47:06 <CodeShark> when I run it on the host OS, I do get a factor slightly below 2x
 739 2013-01-25 10:48:37 iwoter has quit (Ping timeout: 240 seconds)
 740 2013-01-25 10:49:31 drizztbsd has joined
 741 2013-01-25 10:53:28 pooler has quit (Remote host closed the connection)
 742 2013-01-25 10:53:36 porquilho_ has joined
 743 2013-01-25 10:53:47 porquilho has quit (Read error: Connection reset by peer)
 744 2013-01-25 10:58:31 gigavps has joined
 745 2013-01-25 11:00:10 HobGoblin has joined
 746 2013-01-25 11:00:34 HobGoblin is now known as Guest30912
 747 2013-01-25 11:00:48 <CodeShark> anyhow, you solved the first issue as well, sipa
 748 2013-01-25 11:01:00 Guest30912 has quit (Changing host)
 749 2013-01-25 11:01:00 Guest30912 has joined
 750 2013-01-25 11:01:01 mortikia has quit (Remote host closed the connection)
 751 2013-01-25 11:01:13 mortikia has joined
 752 2013-01-25 11:01:17 <CodeShark> moral of the story: use local variables whenever performing CPU-intensive operations on primitive types whenever possible :)
 753 2013-01-25 11:02:01 UukGoblin has quit (Read error: Connection reset by peer)
 754 2013-01-25 11:02:03 <CodeShark> avoid dereferencing
 755 2013-01-25 11:02:08 Guest30912 is now known as UukGoblin
 756 2013-01-25 11:03:31 pooler has joined
 757 2013-01-25 11:03:53 valparaiso is now known as valparaiso_afk
 758 2013-01-25 11:04:04 nus has quit (Ping timeout: 276 seconds)
 759 2013-01-25 11:04:57 Belkaar has quit (Ping timeout: 252 seconds)
 760 2013-01-25 11:05:17 nus has joined
 761 2013-01-25 11:05:53 Belkaar has joined
 762 2013-01-25 11:06:19 random_cat has quit (Ping timeout: 276 seconds)
 763 2013-01-25 11:08:39 MC1984 has joined
 764 2013-01-25 11:08:58 FredEE has quit (Quit: FredEE)
 765 2013-01-25 11:12:32 knotwork__ has joined
 766 2013-01-25 11:14:11 knotwork_ has quit (Ping timeout: 248 seconds)
 767 2013-01-25 11:14:35 FredEE has joined
 768 2013-01-25 11:15:09 <gigavps> can anyone help me understand what happened in this debug.log from bitcoind -> http://pastebin.com/zeHUdncX
 769 2013-01-25 11:15:14 FredEE has quit (Client Quit)
 770 2013-01-25 11:15:46 nus has quit (Ping timeout: 276 seconds)
 771 2013-01-25 11:24:02 random_cat has joined
 772 2013-01-25 11:25:16 <gmaxwell> gigavps: that node mined block 217900 successfully (well, a poolsever rpc connected to that node at least)
 773 2013-01-25 11:26:26 <gmaxwell> gigavps: other than solving a block (which is not normally considered a bad thing, esp was it wasn't orphaned) nothing looks unusual there.
 774 2013-01-25 11:26:37 <gmaxwell> s/was/as/
 775 2013-01-25 11:26:55 dust-otc has quit (Remote host closed the connection)
 776 2013-01-25 11:26:55 nus has joined
 777 2013-01-25 11:28:31 tonikt has joined
 778 2013-01-25 11:31:10 freakazoid has quit (Read error: Operation timed out)
 779 2013-01-25 11:34:20 MrTiggr has joined
 780 2013-01-25 11:36:50 paraipan has joined
 781 2013-01-25 11:37:07 BTCOxygen has quit (1!~kvirc@68.233.247.240|Ping timeout: 248 seconds)
 782 2013-01-25 11:37:28 Impaler has quit (Remote host closed the connection)
 783 2013-01-25 11:38:27 tonikt has quit (Read error: Connection reset by peer)
 784 2013-01-25 11:40:10 <gigavps> gmaxwell, thanks
 785 2013-01-25 11:40:27 <gigavps> i guess the log shows that i received a block directly before finding one
 786 2013-01-25 11:40:43 <gigavps> what is weird is that bitcoind reported back that the block was accepted
 787 2013-01-25 11:44:02 bitnumus_ has joined
 788 2013-01-25 11:52:11 porquilho has joined
 789 2013-01-25 11:52:25 porquilho_ has quit (Read error: Connection reset by peer)
 790 2013-01-25 12:01:03 Cylta has joined
 791 2013-01-25 12:05:02 b4epoche has quit (Read error: Operation timed out)
 792 2013-01-25 12:09:17 b4epoche has joined
 793 2013-01-25 12:16:34 gjs278 has quit (Remote host closed the connection)
 794 2013-01-25 12:34:53 gjs278 has joined
 795 2013-01-25 12:43:46 Ken` has joined
 796 2013-01-25 12:48:41 yareyare has quit (Quit: zzzzzzzz)
 797 2013-01-25 13:01:53 Guest84812 has quit (Changing host)
 798 2013-01-25 13:01:53 Guest84812 has joined
 799 2013-01-25 13:01:58 Guest84812 is now known as jgarzik
 800 2013-01-25 13:02:14 WolfAlex has joined
 801 2013-01-25 13:05:07 WolfAlex_ has quit (Ping timeout: 248 seconds)
 802 2013-01-25 13:06:24 GMP has quit (Read error: Connection reset by peer)
 803 2013-01-25 13:13:00 daybyter has joined
 804 2013-01-25 13:13:03 jdnavarro has quit (Remote host closed the connection)
 805 2013-01-25 13:14:18 jdnavarro has joined
 806 2013-01-25 13:14:23 Diapolo has joined
 807 2013-01-25 13:16:06 agricocb has quit (Quit: Leaving.)
 808 2013-01-25 13:20:37 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 809 2013-01-25 13:31:57 jdnavarro has quit (Remote host closed the connection)
 810 2013-01-25 13:34:31 Diapolo has left ()
 811 2013-01-25 13:34:59 jdnavarro has joined
 812 2013-01-25 13:35:50 rdymac has joined
 813 2013-01-25 13:38:39 JZavala has quit (Ping timeout: 256 seconds)
 814 2013-01-25 13:39:52 datagutt has joined
 815 2013-01-25 13:40:38 Seeraber is now known as Seeraber|away
 816 2013-01-25 13:43:13 comepradz has joined
 817 2013-01-25 13:46:45 rdymac has quit (Remote host closed the connection)
 818 2013-01-25 13:47:14 comepradz has left ()
 819 2013-01-25 13:52:03 Seeraber is now known as away!~Seerauber@pool-100-2-31-168.nycmny.fios.verizon.net|Seeraber
 820 2013-01-25 13:58:48 Seeraber has quit (Quit: Bye!)
 821 2013-01-25 14:00:45 daybyter has quit (Quit: Konversation terminated!)
 822 2013-01-25 14:01:55 bitmarco has joined
 823 2013-01-25 14:02:25 <Cylta> What the relation between this two type of how to show transaction number: abe526a03baf86e212b21da8f424cdae5c258b2568723e2bc3b1ca88e9cdaaa2 (from blockchain.info) and a2aacde988cab1c32b3e7268258b255caecd24f4a81db212e286af3ba026e5ab (from other service). Looks like it's the same number but mixed and reversed...
 824 2013-01-25 14:04:41 tonikt has joined
 825 2013-01-25 14:07:07 torsthaldo has quit (Read error: Connection reset by peer)
 826 2013-01-25 14:07:48 torsthaldo has joined
 827 2013-01-25 14:17:05 <kjj> just different endianness
 828 2013-01-25 14:18:09 bitnumus_ has quit (Quit: Leaving)
 829 2013-01-25 14:18:20 <kjj> In both numbers, each pair of digits is a byte.  one number has the biggest byte at the beginning, the other starts with the smallest
 830 2013-01-25 14:20:01 <kjj> biggest here means "highest power".  in the number 19, the 1 is bigger (has the higher power) because it means 1*10^1, while the 9 means 9*10^0
 831 2013-01-25 14:25:47 <HM> i hate bigints
 832 2013-01-25 14:26:03 <HM> 64 bits should be enough for every one
 833 2013-01-25 14:28:33 lumberjak has quit (Read error: Connection reset by peer)
 834 2013-01-25 14:28:46 lumberjak has joined
 835 2013-01-25 14:32:30 agricocb has joined
 836 2013-01-25 14:35:46 <Cylta> HM: 640Kb of memory will be enough for everyone --- Sounds similar, eh?
 837 2013-01-25 14:36:08 <sipa> there's maybe place for 5 computers in this world
 838 2013-01-25 14:36:30 <SomeoneWeird> or 5 billion
 839 2013-01-25 14:36:30 <Cylta> HM: just wait untill we will have golographic memory spheres with exzabytes of data, and 64bits will not be enough to address all that memory.
 840 2013-01-25 14:44:38 <HM> OK, but i'd be grateful if we could keep it to powers of 2
 841 2013-01-25 14:44:47 <HM> Base58 :| who's idea was that?
 842 2013-01-25 14:45:51 <SomeoneWeird> SATOSHIS
 843 2013-01-25 14:46:56 <HM> Base32 is case insensitive and only 17% longer
 844 2013-01-25 14:47:12 <SomeoneWeird> a whole 17%
 845 2013-01-25 14:47:13 <SomeoneWeird> >.>
 846 2013-01-25 14:47:15 <HM> it hardly seems that many people are hand typing Base58 addresses anyway
 847 2013-01-25 14:47:26 <SomeoneWeird> qr ftw
 848 2013-01-25 14:47:32 <HM> alternatively Base64 only requires 2 characters outside alphanum
 849 2013-01-25 14:48:59 <Cylta> do not even think about typing addresses manually, in any encoding :P
 850 2013-01-25 14:49:15 <HM> well there's a check digit isn't there? and the Base58 encoded excludes I
 851 2013-01-25 14:49:21 <SomeoneWeird> yes
 852 2013-01-25 14:49:21 <HM> it seems that was the intent, or at least for OCR
 853 2013-01-25 14:49:31 <HM> *encoding
 854 2013-01-25 14:49:50 lumberjak has quit (Read error: Connection reset by peer)
 855 2013-01-25 14:50:00 lumberjak has joined
 856 2013-01-25 14:50:30 <HM> Crockfords base32 seems to be a better balance between simple encoding and decoding and human typo protection
 857 2013-01-25 14:55:00 <sipa> i'd have liked base32
 858 2013-01-25 14:55:22 <sipa> that would also mean we could use e.g. a CRC-30 instead of truncated-double-SHA256 for checksums
 859 2013-01-25 14:55:48 <sipa> and have strong guarantees on the errors that would be caught
 860 2013-01-25 15:03:32 <kuzetsa> really, OCR on base32 / base58 seems silly when you could just use ISO standard #18004 with 65http://goo.gl/7CPKx
 861 2013-01-25 15:03:35 <kuzetsa> ack
 862 2013-01-25 15:03:53 <kuzetsa> 65% (level H) error correction, THEN the link after a space. --> http://goo.gl/7CPKx
 863 2013-01-25 15:03:56 <kuzetsa> stupid mouse
 864 2013-01-25 15:04:54 <HM> QR codes and such are great but you always run in to the case where the user doesn't have a cell phone or a printer
 865 2013-01-25 15:05:15 <HM> if you have a pen and some skin you can record a string :P
 866 2013-01-25 15:05:19 <kuzetsa> right, but QR code is just a way of encoding / representing it.
 867 2013-01-25 15:06:09 <kuzetsa> the 160 bits can be encoded in hex or base32 or base58 and written with pen and paper same as it could be converted to qr code (in raw 160 bit format or a qr code representing the hex or base32 or base58. either way is fine)
 868 2013-01-25 15:07:07 <kuzetsa> and at that point, handwriting styles and kerning can throw off the OCR anyway
 869 2013-01-25 15:09:33 <sipa> for optimal efficiency when encoding as a QR code, you need base36
 870 2013-01-25 15:10:35 <HM> Morse code is another option
 871 2013-01-25 15:10:42 <kuzetsa> haha
 872 2013-01-25 15:11:04 <kuzetsa> they don't force radio operators to know morse code anymore
 873 2013-01-25 15:11:12 <kuzetsa> it's a dying practice to use morse code
 874 2013-01-25 15:11:21 <HM> Morse code is base36 , i think
 875 2013-01-25 15:11:35 <kuzetsa> no, it's really not
 876 2013-01-25 15:11:47 <HM> it's only alphanum though isn't it
 877 2013-01-25 15:12:02 <HM> 36 symbols
 878 2013-01-25 15:12:13 <HM> well 2 symbols
 879 2013-01-25 15:12:16 <HM> whatever
 880 2013-01-25 15:12:22 mariusursache has quit (Quit: mariusursache)
 881 2013-01-25 15:12:34 <HM> i'm busy thinking about converting QR codes to morse code
 882 2013-01-25 15:13:19 lumberjak has quit (Read error: Connection reset by peer)
 883 2013-01-25 15:13:29 lumberjak has joined
 884 2013-01-25 15:13:53 <kuzetsa> HM: morse code has extensions for non-roman letters, and punctuatin too :P
 885 2013-01-25 15:15:15 <HM> cool
 886 2013-01-25 15:15:45 <kuzetsa> I suspect you were being satirical though / dead-pan humor & not serious.
 887 2013-01-25 15:17:02 <HM> well, it's interesting
 888 2013-01-25 15:18:05 <kuzetsa> fair enough
 889 2013-01-25 15:18:12 <gavinandresen> There's another good April 1 BIP :   "Bitcoin Addresses version --.---.-.  : Morse-Encoded"
 890 2013-01-25 15:18:38 <HM> . and - aren't optimal for tapping though, too far away from one another on the keyboard
 891 2013-01-25 15:18:48 <HM> should use , and .
 892 2013-01-25 15:18:53 <HM> :D
 893 2013-01-25 15:19:04 <gavinandresen> … put that in the Issues section...
 894 2013-01-25 15:21:00 <HM> I'll put it after my idea for a wrinkle resistant tatoo encoding for private keys
 895 2013-01-25 15:21:02 <HM> brb
 896 2013-01-25 15:21:39 HM has quit ()
 897 2013-01-25 15:23:50 sgornick has joined
 898 2013-01-25 15:26:01 reizuki__ has quit (Ping timeout: 276 seconds)
 899 2013-01-25 15:28:18 Diapolo has joined
 900 2013-01-25 15:31:43 gigavps has quit (Quit: Leaving)
 901 2013-01-25 15:35:07 HM has joined
 902 2013-01-25 15:36:22 <jgarzik> hmmm, I could tattoo the kids' saving accounts on their bum
 903 2013-01-25 15:36:34 <jgarzik> with bitcoin, possibilities are endless
 904 2013-01-25 15:36:51 andytoshi has quit (Quit: WeeChat 0.3.9.2)
 905 2013-01-25 15:37:21 <SomeoneWeird> lollllll
 906 2013-01-25 15:44:27 hasha has quit (Ping timeout: 256 seconds)
 907 2013-01-25 15:44:46 tonikt has quit (Read error: Connection reset by peer)
 908 2013-01-25 15:47:43 gigavps has joined
 909 2013-01-25 15:47:45 denisx has joined
 910 2013-01-25 15:51:32 hasha has joined
 911 2013-01-25 15:54:50 copumpkin has quit (Ping timeout: 245 seconds)
 912 2013-01-25 15:56:00 copumpkin has joined
 913 2013-01-25 15:58:15 bitnumus_ has joined
 914 2013-01-25 15:58:31 rdymac has joined
 915 2013-01-25 15:59:39 <ThomasV> is it posible to redeem multisig and classical op_checksig inputs in the same tx?
 916 2013-01-25 16:00:50 <kjj> yes
 917 2013-01-25 16:02:40 rdymac has quit (Remote host closed the connection)
 918 2013-01-25 16:05:45 rdymac has joined
 919 2013-01-25 16:06:26 owowo has joined
 920 2013-01-25 16:09:40 dust-otc has joined
 921 2013-01-25 16:10:21 reizuki__ has joined
 922 2013-01-25 16:10:21 reizuki__ has quit (Changing host)
 923 2013-01-25 16:10:21 reizuki__ has joined
 924 2013-01-25 16:18:41 <SomeoneWeird> https://www.destroyallsoftware.com/talks/wat
 925 2013-01-25 16:18:44 <SomeoneWeird> this should be added to the topic
 926 2013-01-25 16:19:12 <sipa> what's that?
 927 2013-01-25 16:19:24 <SomeoneWeird> lol
 928 2013-01-25 16:19:26 <SomeoneWeird> watch it
 929 2013-01-25 16:19:28 <SomeoneWeird> best talk ever
 930 2013-01-25 16:19:40 <sipa> This webpage has a redirect loop
 931 2013-01-25 16:19:41 <sipa> The webpage at https://www.destroyallsoftware.com/talks/wat has resulted in too many redirects.
 932 2013-01-25 16:19:47 <SomeoneWeird> 0.o
 933 2013-01-25 16:19:49 <SomeoneWeird> works for me
 934 2013-01-25 16:20:16 <SomeoneWeird> https://s3.amazonaws.com/destroyallsoftware-talks/wat.mov?AWSAccessKeyId=AKIAIKRVCECXBC4ZGHIQ&Expires=1359131526&Signature=hoa%2Ffi0fPnOh1jViQysFMWzaoeo%3D
 935 2013-01-25 16:21:56 b4epoche has quit (Ping timeout: 244 seconds)
 936 2013-01-25 16:24:38 b4epoche has joined
 937 2013-01-25 16:30:21 Diapolo has left ()
 938 2013-01-25 16:31:43 yellowhat has joined
 939 2013-01-25 16:34:50 owowo has quit (Remote host closed the connection)
 940 2013-01-25 16:38:45 RainbowDashh has quit (Remote host closed the connection)
 941 2013-01-25 16:40:37 MrTiggr has quit (Ping timeout: 240 seconds)
 942 2013-01-25 16:45:25 toffoo has joined
 943 2013-01-25 16:46:13 toffoo has quit (Client Quit)
 944 2013-01-25 16:46:29 toffoo has joined
 945 2013-01-25 16:46:44 toffoo has quit (Client Quit)
 946 2013-01-25 16:48:21 twixed has joined
 947 2013-01-25 16:48:41 mappum has joined
 948 2013-01-25 16:50:11 <BlueMatt> gmaxwell: did github kill search in response to you?
 949 2013-01-25 16:50:17 <BlueMatt> or was it just a coincidence?
 950 2013-01-25 16:50:44 <BlueMatt> or did you see a link and post here?
 951 2013-01-25 16:52:46 valparaiso_afk is now known as valparaiso
 952 2013-01-25 16:57:37 panzer has quit (Ping timeout: 264 seconds)
 953 2013-01-25 16:58:07 panzer has joined
 954 2013-01-25 16:58:27 <SomeoneWeird> coincidence
 955 2013-01-25 17:03:27 <sipa> coin cidence?
 956 2013-01-25 17:04:13 da2ce7_d has joined
 957 2013-01-25 17:06:30 da2ce7 has quit (Ping timeout: 245 seconds)
 958 2013-01-25 17:08:19 cheebydi has quit (Ping timeout: 256 seconds)
 959 2013-01-25 17:11:58 DaQatz has quit (Ping timeout: 252 seconds)
 960 2013-01-25 17:11:59 owowo has joined
 961 2013-01-25 17:12:01 <SomeoneWeird> possibly
 962 2013-01-25 17:20:03 rdymac has quit (Ping timeout: 255 seconds)
 963 2013-01-25 17:20:44 rdymac has joined
 964 2013-01-25 17:21:45 ThomasV has quit (Quit: Leaving)
 965 2013-01-25 17:21:57 cheebydi has joined
 966 2013-01-25 17:23:09 Ken` has quit (Quit: leaving)
 967 2013-01-25 17:24:34 CodeShark has quit (Remote host closed the connection)
 968 2013-01-25 17:28:13 vampireb has joined
 969 2013-01-25 17:28:55 denisx has quit (Quit: denisx)
 970 2013-01-25 17:29:32 Hashdog has joined
 971 2013-01-25 17:30:34 rdymac has quit (Remote host closed the connection)
 972 2013-01-25 17:36:35 rdymac has joined
 973 2013-01-25 17:36:56 stalled has quit (Ping timeout: 245 seconds)
 974 2013-01-25 17:40:40 rdymac has quit (Ping timeout: 245 seconds)
 975 2013-01-25 17:40:43 twixed has quit (Quit: Leaving)
 976 2013-01-25 17:40:45 stalled has joined
 977 2013-01-25 17:50:28 Gladamas has quit (Ping timeout: 252 seconds)
 978 2013-01-25 17:54:18 <mappum> i'm keeping track of address balances manually via getblock, but i want to make sure i'm doing this correctly
 979 2013-01-25 17:54:59 <mappum> for each new block, i'm going through the transactions, and checking each input. if it is from an address i am tracking, i subtract that from the balance
 980 2013-01-25 17:55:19 <mappum> then i go through the outputs, and if one is for an address i am tracking, i add it to the balance
 981 2013-01-25 17:55:39 Diapolo has joined
 982 2013-01-25 17:55:45 <mappum> am i doing any of that incorrectly?
 983 2013-01-25 17:56:51 <sipa> that's correct, but be sure to deal with reorganisations
 984 2013-01-25 17:56:57 <mappum> yep
 985 2013-01-25 17:57:29 <mappum> if i detect one, i go backwards through the blocks, reversing the txs until i get to where it branched
 986 2013-01-25 17:57:48 <sipa> yes, that's correct
 987 2013-01-25 17:58:23 <mappum> anything else like that i have to think about?
 988 2013-01-25 17:58:51 porquilho has quit (Read error: Connection reset by peer)
 989 2013-01-25 17:59:08 porquilho has joined
 990 2013-01-25 18:01:01 <sipa> no, that's basically what happens internally as well
 991 2013-01-25 18:01:09 <sipa> except it's not indexed by address
 992 2013-01-25 18:04:02 Gladamas has joined
 993 2013-01-25 18:06:02 DaQatz has joined
 994 2013-01-25 18:11:18 osmosis has joined
 995 2013-01-25 18:14:59 daybyter has joined
 996 2013-01-25 18:18:10 sgornick has quit (Quit: Ex-Chat)
 997 2013-01-25 18:18:39 Joric has joined
 998 2013-01-25 18:19:02 grau has joined
 999 2013-01-25 18:20:29 FredEE has joined
1000 2013-01-25 18:23:08 <kuzetsa> helo / gmaxwell --> the thing I was saying about block limit, I just realized something (I think... but I'm not sure my understanding of the math is right)
1001 2013-01-25 18:23:12 <muhoo> what's the status of making the fee behavior in bitcoij match that of the c++ client?
1002 2013-01-25 18:23:26 <muhoo> er bitcoinj (slow ssh connection)
1003 2013-01-25 18:23:39 tsche has quit ()
1004 2013-01-25 18:24:41 <kuzetsa> ...basically, the value of MAX_BLOCK_SIZE ... can it be exceeded?
1005 2013-01-25 18:25:09 <helo> kuzetsa: nope. blocks that are larger than that aren't valid
1006 2013-01-25 18:25:18 <kuzetsa> oh my
1007 2013-01-25 18:25:29 <kuzetsa> ... then ultimately, my argument was valid after all
1008 2013-01-25 18:25:39 Belkaar has quit (Ping timeout: 248 seconds)
1009 2013-01-25 18:25:47 <kuzetsa> bitcoin could theoretically break if it was suddenly being used for high volume and needed more than would fit in blocks
1010 2013-01-25 18:26:25 <kuzetsa> and raising fees and/or using coins that are more aged (higher priority) would only be a stopgap measure to make transactions go in the block first
1011 2013-01-25 18:26:34 <muhoo> more miners then?
1012 2013-01-25 18:27:01 <Cylta> I sthere any limit about amount of transactions per block?
1013 2013-01-25 18:27:02 <kuzetsa> muhoo: not really. the network would adjust difficulty, and blocks would slow back down to aprox 144 blocks per day
1014 2013-01-25 18:27:10 <kuzetsa> Cylta: yes.
1015 2013-01-25 18:27:14 <helo> kuzetsa: it wouldn't break... i think the devs have addressed the DOS concerns of a bunch of unconfirmed transactions
1016 2013-01-25 18:27:25 <Cylta> kuzetsa: how much of that limit are we using right now?
1017 2013-01-25 18:27:27 <helo> rather, i should say "how could it break?"
1018 2013-01-25 18:27:33 <lianj> Cylta: the block has a max size
1019 2013-01-25 18:27:35 Belkaar has joined
1020 2013-01-25 18:27:41 <lianj> (in bytes that is)
1021 2013-01-25 18:27:51 <kuzetsa> Cylta: we often hit 1/4 full blocks on like a daily basis from what I've seen
1022 2013-01-25 18:28:00 <jgarzik> kuzetsa: MAX_BLOCK_SIZE cannot be exceeded.  Clients will reject blocks larger than that as invalid.
1023 2013-01-25 18:28:10 <muhoo> i don't remember if it's possible to generate a transaction that spends outputs that haven't been in a block yet
1024 2013-01-25 18:28:16 <kuzetsa> jgarzik: this seems like a systemic design flaw to me
1025 2013-01-25 18:28:40 <kuzetsa> ... unless the difficulty adjustment algorithm could be adjusted to have blocks come out faster
1026 2013-01-25 18:28:40 <sipa> muhoo: it is possible to spend unconfirmed outputs (according to the protocol, the client only allows this in specific circumstances)
1027 2013-01-25 18:28:42 <helo> kuzetsa: limiting the data growth of a decentralized system is the only way to keep a system decentralized
1028 2013-01-25 18:28:48 <Cylta> So, why not simply increase MAX_BLOCK_SIZE?
1029 2013-01-25 18:28:59 <sipa> Cylta: requires a hard fork
1030 2013-01-25 18:29:01 <lianj> Cylta: fork
1031 2013-01-25 18:29:15 <Cylta> sipa: lianj: just update all clients simultaniously
1032 2013-01-25 18:29:28 <sipa> Cylta: that is indeed what would be necessary
1033 2013-01-25 18:29:38 <helo> Cylta: presently the current MAX_BLOCK_SIZE is high enough
1034 2013-01-25 18:29:43 <lianj> works well with new windows versions too
1035 2013-01-25 18:29:51 <kuzetsa> hmm
1036 2013-01-25 18:30:08 <Cylta> IF we already hit 25% of MAX_BLOCK_SIZE, it mean that bitcoin will die in several years...
1037 2013-01-25 18:30:11 <sipa> jgarzik: has you asic arrived yet?
1038 2013-01-25 18:30:19 <Cylta> I mean, smaller transactions will not be accepted
1039 2013-01-25 18:30:26 <sipa> Cylta: no, it means that either there will be a hard fork, or more transactions will happen off-chain
1040 2013-01-25 18:30:43 <helo> Cylta: and increasing it once it isn't "high enough" would cut into mining profits, reducing the hashrate... and also ultimately reduce decentralization due to increased resource requirements
1041 2013-01-25 18:30:46 <muhoo> won't that cause re-orgs though?
1042 2013-01-25 18:30:49 <jgarzik> sipa: https://bitcointalk.org/index.php?topic=137534.msg1478626#msg1478626
1043 2013-01-25 18:30:51 <Cylta> sipa: I think simply increasing fees for the transaction could help
1044 2013-01-25 18:30:52 <jgarzik> short answer: no
1045 2013-01-25 18:31:04 <Cylta> (just stop satoshidice)
1046 2013-01-25 18:31:13 <helo> Cylta: when the blocks are full, people just have to pay more fees to get a transaction in a block
1047 2013-01-25 18:31:14 <sipa> Cylta: fees will automatically increase if block space becomes scarce
1048 2013-01-25 18:31:23 <muhoo> a ton of transactions happpening off-chain, unconfirmed outpus being spent, and then someone tries to get those into a chain?
1049 2013-01-25 18:31:40 <kuzetsa> Cylta: that sort of policitcally motivated censorship doesn't seem to set a good precedent.
1050 2013-01-25 18:31:44 FredEE has quit (Quit: FredEE)
1051 2013-01-25 18:31:47 <helo> Cylta: think of it like a market for block space... miners have 1MB of transactions, so they pick the ones with the highest fees
1052 2013-01-25 18:31:48 <kuzetsa> "stop satoshidice" ... meh
1053 2013-01-25 18:32:13 <jgarzik> muhoo: that's fine
1054 2013-01-25 18:32:19 <jgarzik> muhoo: as long as the dependencies are all in the chain
1055 2013-01-25 18:32:25 Belkaar has quit (Ping timeout: 264 seconds)
1056 2013-01-25 18:32:34 <Cylta> helo: I understand this. 1M is max? So, simply pay more for your transaction and it will be instant...
1057 2013-01-25 18:32:35 <jgarzik> muhoo: You are allowed to have a bunch of off-chain transactions
1058 2013-01-25 18:32:43 drizztbsd has quit (Remote host closed the connection)
1059 2013-01-25 18:32:47 <jgarzik> muhoo: It's only when decentralized consensus is required, that the chain is required
1060 2013-01-25 18:32:57 <Luke-Jr> kuzetsa: it's not political to stop a DDoS
1061 2013-01-25 18:33:14 bitnumus has quit (Read error: Connection reset by peer)
1062 2013-01-25 18:33:26 <sipa> and decentralized consensus is only required when you do not want to trust anyone
1063 2013-01-25 18:33:30 <helo> Cylta: it won't be instant, but it will make it into an upcoming block if the fee is high enough
1064 2013-01-25 18:33:36 <jgarzik> tcatm: bitcoinwatch.com block counter is stuck
1065 2013-01-25 18:33:43 bitnumus has joined
1066 2013-01-25 18:34:05 Belkaar has joined
1067 2013-01-25 18:34:12 <helo> Cylta: if blocks are persistently full, and the fee isn't high enough, it may never make it into a block
1068 2013-01-25 18:34:42 <Cylta>  helo: I get it. So, there will be "free-market" fee
1069 2013-01-25 18:34:47 <helo> yup
1070 2013-01-25 18:34:47 <Cylta>  helo: as for me that's okay
1071 2013-01-25 18:34:57 <muhoo> oh, i see. this so reminds me of git. can run it in decentralized mode, or use github, same protocol, can be used either way
1072 2013-01-25 18:35:00 <kuzetsa> Luke-Jr: calling it a pejorative term like DoS isn't based on a clear, universally accepted definition. The exchange of bitcoin for satoshi dice is a valid use / business model which is just as valid as people exchanging on mtgox, or renting advertizing impressions for bitcoin, or buying a pizza or anything else
1073 2013-01-25 18:35:01 <sipa> yes, fees are intended to evolve to a free market
1074 2013-01-25 18:35:03 <Cylta> stop the satochidice! hehe
1075 2013-01-25 18:35:26 <Cylta> I think SD are making about half of current transactions
1076 2013-01-25 18:35:41 <helo> probably the biggest consequence will be that lower-valued transactions will be less viable
1077 2013-01-25 18:35:47 <muhoo> i keep forgetting that the chain is not the only way bitcoin can be used
1078 2013-01-25 18:35:50 <Luke-Jr> kuzetsa: SD doesn't use transactions as exchange, they use it as an action signal
1079 2013-01-25 18:36:24 <sipa> muhoo: the chain is the only way bitcoin-the-technology can be used
1080 2013-01-25 18:36:32 <sipa> muhoo: but bitcoin-the-currency is wider
1081 2013-01-25 18:37:11 <kuzetsa> Luke-Jr: no, I'm pretty sure they transactions are actually exchanging bitcoin.. as a side effect, they're using the blockchain as an entropy source for their "provably fair gambling" business model
1082 2013-01-25 18:37:17 <Luke-Jr> kuzetsa: and it does fit the clear objective definition of DDoS in fact
1083 2013-01-25 18:37:46 <sipa> calling it a DoS imho implies malicious intent, and it is ridiculous to claim this is the case, imho
1084 2013-01-25 18:38:07 Belkaar has quit (Ping timeout: 240 seconds)
1085 2013-01-25 18:38:09 <sipa> they may be damaging in unintentional way nonetheless, though
1086 2013-01-25 18:38:16 <muhoo> in taht case, porn is a DDos agains the interenet
1087 2013-01-25 18:38:44 <sipa> or perhaps better, an ununderstood way
1088 2013-01-25 18:38:49 <muhoo> gawd, character munching. in that case, porn is a DDoS against the internet
1089 2013-01-25 18:39:13 <Luke-Jr> muhoo: how is porn denying service to the internet?
1090 2013-01-25 18:39:15 <kuzetsa> "...an attempt to make a machine or network resource unavailable to its intended users." <--- it's only an attack if you don't intend for gambling small amounts to be allowed, therefore applying a definition to satoshi dice business model as "not a valid service or use / unauthorized user / not an intented user"
1091 2013-01-25 18:39:24 <kuzetsa> that's a formal definition of DoS
1092 2013-01-25 18:40:02 Diapolo has left ()
1093 2013-01-25 18:40:24 <Luke-Jr> kuzetsa: and SD does in fact make the Bitcoin network degraded for its intended uses.
1094 2013-01-25 18:40:26 <helo> miners should probably be happy about SD, given that it will drive up fees
1095 2013-01-25 18:40:35 <muhoo> Luke-Jr: i was around in the 90s. ISPs did consider porn, and then napster, and bittorrent, etc, to be a DDoS. it cloged up the pipes so that "legitimate" traffic was slowed or hampered. i remember selling gear to ISPs t try to cope with this. lots of it.
1096 2013-01-25 18:40:56 vampireb has quit (Quit: Lost terminal)
1097 2013-01-25 18:41:31 t7 has joined
1098 2013-01-25 18:41:33 <Luke-Jr> muhoo: I guess you could argue that… except that ISPs just sell connectivity in theory
1099 2013-01-25 18:41:51 <Luke-Jr> muhoo: Bitcoin, on the other hand, was intended specifically for financial transactions
1100 2013-01-25 18:41:51 <muhoo> even before that, in the late 80s and early 90s, anything that was not related to government or academic use was considered to be a DDoS. i knew guys who ran NNTP servers in those days.
1101 2013-01-25 18:42:09 <muhoo> you would not believe the shit they went through.
1102 2013-01-25 18:42:22 <kuzetsa> right
1103 2013-01-25 18:42:31 <kuzetsa> progressive, creative, artistic new-use for existing platforms
1104 2013-01-25 18:42:52 <kuzetsa> political evolution of culture and practice
1105 2013-01-25 18:43:31 <muhoo> my point is, this argument has been had several times before. might be helpful to look at the prior art, what happened, how people coped, and how we got here today. it's not an easy problem, but it's solvable.
1106 2013-01-25 18:43:35 Belkaar has joined
1107 2013-01-25 18:44:43 <helo> i think, if the blockchain growing at 1MB is sustainable, SD traffic is tolerable
1108 2013-01-25 18:44:54 Joric has quit ()
1109 2013-01-25 18:45:28 <kuzetsa> muhoo: ultimately, I'm pretty sure that creating disparity / unfair advantage or disadvantage, or even outright setting a censorship policy for certain practices and/or uses for bitcoin is not an actual goal anyone will openly admit to having.
1110 2013-01-25 18:45:45 <Luke-Jr> helo: SD would just flood more
1111 2013-01-25 18:46:58 <Luke-Jr> muhoo: there really is no preceding case like Bitcoin though
1112 2013-01-25 18:47:12 <kuzetsa> oh... now I feel silly. the DVR has been on pause for the past half hour / was watching a show.
1113 2013-01-25 18:47:29 <Luke-Jr> probably Bitcoin will survive because Erik gets arrested finally
1114 2013-01-25 18:48:14 <muhoo> Luke-Jr: as a technology, it's prety innovative. but the general problems you're coping with are essentially capacity problems, not new to the internet, or to engineering in general.
1115 2013-01-25 18:48:15 Belkaar has quit (Ping timeout: 255 seconds)
1116 2013-01-25 18:48:18 <kuzetsa> ok, before I go...
1117 2013-01-25 18:48:46 <Luke-Jr> muhoo: when has something ever had "data that must be stored by all peers forever and grows with time"?
1118 2013-01-25 18:49:02 <muhoo> Luke-Jr: porn? :-)
1119 2013-01-25 18:49:24 <kuzetsa> up until the (currently hard-coded) MAX_BLOCK_SIZE = 1000000 is reached, basically, the transactions with higher priority (coins which have been aged longer, and/or higher fees on the transaction) will be included first, right?
1120 2013-01-25 18:49:26 <Luke-Jr> porn can easily be deleted
1121 2013-01-25 18:49:28 <jgarzik> Luke-Jr: sadly I think Erik will eventually taint Bitcoin Foundation
1122 2013-01-25 18:49:48 <Luke-Jr> jgarzik: hopefully the first election round replaces BitInstant with BitPay
1123 2013-01-25 18:49:53 <Luke-Jr> my hope, at least
1124 2013-01-25 18:49:56 <jgarzik> kuzetsa: there is only a small area (27k?) for free transactions
1125 2013-01-25 18:50:07 <jgarzik> kuzetsa: and inside that "free zone", transactions are sorted by priority
1126 2013-01-25 18:50:23 <kuzetsa> jgarzik: priority doesn't matter except for "free" transactions?
1127 2013-01-25 18:50:34 Belkaar has joined
1128 2013-01-25 18:50:58 <jgarzik> kuzetsa: outside the free pool, it's largely sorted by fee-per-kb, IIRC
1129 2013-01-25 18:50:58 <helo> Luke-Jr: it won't ever flood more than 1MB, though... if MAX_BLOCK_SIZE is the appropriate value, then the system will be fine with SD or without it
1130 2013-01-25 18:51:06 <jgarzik> but each miner chooses, and may not have the latest rules
1131 2013-01-25 18:51:31 <kuzetsa> jgarzik: right, and "fee-per-kb" is basically also linked to the age of the source coins in the blockchain I thought.
1132 2013-01-25 18:51:42 <helo> if block space starts to become more scarce, SD will probably fix its system to not send the satoshi notification
1133 2013-01-25 18:51:50 <jgarzik> kuzetsa: not AFAIK
1134 2013-01-25 18:51:50 <helo> just to stay viable
1135 2013-01-25 18:51:50 FredEE has joined
1136 2013-01-25 18:52:09 <kuzetsa> jgarzik: oh, then the "age" only affects free transactions? ... huh, weird.
1137 2013-01-25 18:52:28 <Luke-Jr> jgarzik: and Matonis is picking a fight with the IRS in Feb Bitcoin Magazine (unless Mihai takes it out)
1138 2013-01-25 18:52:30 <jgarzik> kuzetsa: fee == you are paying to avoid all those pesky anti-spam and age rules :)
1139 2013-01-25 18:52:45 <jgarzik> Luke-Jr: not new.  Matonis is vocally anti-tax
1140 2013-01-25 18:52:48 <jgarzik> sadly
1141 2013-01-25 18:52:59 <Luke-Jr> jgarzik: I mean explicitly encouraging tax evasion
1142 2013-01-25 18:53:12 ThomasV has joined
1143 2013-01-25 18:53:14 <jgarzik> I've yelled about that before
1144 2013-01-25 18:53:18 <jgarzik> c'est la vie
1145 2013-01-25 18:53:22 <kuzetsa> hmm
1146 2013-01-25 18:53:36 <jgarzik> Luke-Jr: He's done that, or close, in at least one Forbes article
1147 2013-01-25 18:53:58 <Luke-Jr> sigh
1148 2013-01-25 18:54:04 <jgarzik> I think it's bollocks, but he's high profile and this damages bitcoin's image, IMO
1149 2013-01-25 18:54:09 <kuzetsa> I coulda sworn the age rules affected priority for being included in a block when the blocksize was getting higher than 250k as it approaches the 1M limit
1150 2013-01-25 18:54:24 <Luke-Jr> jgarzik: more worrisome, it gives the government a reason to go after Bitcoin
1151 2013-01-25 18:54:25 <jgarzik> kuzetsa: I don't see any code that does that
1152 2013-01-25 18:54:33 <kuzetsa> ouch
1153 2013-01-25 18:54:59 <kuzetsa> ... this seems even less sustainable than I thought it looked yesterday :(
1154 2013-01-25 18:55:34 <jgarzik> kuzetsa: right now SatoshiDICE happily pays a fee and spams the shit out of the blockchain
1155 2013-01-25 18:55:35 freewil has quit (Remote host closed the connection)
1156 2013-01-25 18:55:38 <helo> kuzetsa: bitcoin was never supposed to be used for everyday transactions by the entire population of the earth
1157 2013-01-25 18:55:56 <kuzetsa> helo: who said so?
1158 2013-01-25 18:56:08 <kuzetsa> ... also, the internet was originally for academic / government use :P
1159 2013-01-25 18:56:22 <jgarzik> it is inherent in the bitcoin design
1160 2013-01-25 18:56:24 <helo> kuzetsa: the existential realities of a decentralized system say so
1161 2013-01-25 18:56:48 <kuzetsa> helo: tossing the word "existential" in there doesn't help explain anything
1162 2013-01-25 18:56:49 <helo> kuzetsa: there's no way to be decentralized with terabytes of data per day being added to the blockchain
1163 2013-01-25 18:57:06 <kuzetsa> helo: sure there is
1164 2013-01-25 18:57:49 <kuzetsa> ... storage is gonna be cheaper in 100 years, that might be a fraction of a penny worth of storage when you already have a few exabytes to work with
1165 2013-01-25 18:58:12 <helo> kuzetsa: it decentralization can't exist if the data grows too quickly. thus, "existential"
1166 2013-01-25 18:58:18 toffoo has joined
1167 2013-01-25 18:58:51 * muhoo suspects he's the only old fart here who remembers when a terabyte drive was science fiction.
1168 2013-01-25 18:59:00 <kuzetsa> muhoo: same
1169 2013-01-25 18:59:06 <kuzetsa> I remember when a gigabyte was a big deal
1170 2013-01-25 18:59:18 <kuzetsa> ... I'll be 32 years young in a couple years *shrug*
1171 2013-01-25 18:59:41 freakazoid has joined
1172 2013-01-25 18:59:43 <kuzetsa> blah I really need to get back to watching this show. sorry for such a lengthy diversion
1173 2013-01-25 19:00:17 <kuzetsa> helo: also, terabytes per day won't happen
1174 2013-01-25 19:00:47 dvide has quit ()
1175 2013-01-25 19:01:26 <kuzetsa> even if the population of the planet was somehow increased 10 fold, the overall volume of transaction in ANY currency (fiat, commodities, bartering or otherwise) wouldn't likely generate terabytes per day
1176 2013-01-25 19:02:00 <helo> three transactions per day per human over the age of 15 will be a lot of data
1177 2013-01-25 19:02:17 <muhoo> back to more mundane things: fees. should i implement fees on my own outside of bitcoinj (transliterating the code in the c++ client), submit a patch to bitcoinj to do it, or wait for bitcoinj to implement it?
1178 2013-01-25 19:02:48 <muhoo> is it sitting in someone's branch somwhere waiting to be merged?
1179 2013-01-25 19:03:09 dust-otc has quit (Remote host closed the connection)
1180 2013-01-25 19:03:21 <helo> kuzetsa: 6 billion * 3 * 0.5kb = 8 terabytes
1181 2013-01-25 19:03:36 <kuzetsa> helo yeah, I just fact-checked that math myself... touche
1182 2013-01-25 19:04:34 freewil has joined
1183 2013-01-25 19:05:20 <helo> kuzetsa: there is plenty of a market for higher-valued financial transactions that bitcoin's 1MB blocks could handle
1184 2013-01-25 19:05:25 <kuzetsa> now I just find myself wondering why there's still no pruning algorithm or compression or other space-saving algorithm(s) on the horizon for older transactions in the blockchain
1185 2013-01-25 19:05:57 <muhoo> wait, i thought pruning was coming soon?
1186 2013-01-25 19:05:57 <sturles> From the wiki: If the blocksize is more than 250 kB, transactions get increasingly more expensive as the blocksize approaches the limit of 500 kB. Sending a transaction when the blocksize is 400 kB will cost 5 times the normal amount; sending when it's 499 kB will cost 500x, etc.
1187 2013-01-25 19:06:04 <helo> there is pruning
1188 2013-01-25 19:06:06 <kuzetsa> it is? oh neat.
1189 2013-01-25 19:06:11 <kuzetsa> that'll be nice
1190 2013-01-25 19:06:14 <sturles> Perhaps the progressive fees should start earlier?
1191 2013-01-25 19:06:22 <sturles> E.g. at 100 kB?
1192 2013-01-25 19:07:29 <kuzetsa> iunno... I'm gonna drop this subject until pruning or other space-saving measures have been tested and deployed
1193 2013-01-25 19:08:16 <Luke-Jr> sturles: they're not in effect anymore since 0.6 IIRC
1194 2013-01-25 19:08:54 <jgarzik> muhoo: I think bitcoinj + better fee handling is in the "todo/anybody" category. TD[gone]`
1195 2013-01-25 19:09:25 <Luke-Jr> jgarzik: it's in the "code exists and is tested, but needs formal unit tests" category
1196 2013-01-25 19:09:31 <jgarzik> ah, cool
1197 2013-01-25 19:09:40 <Luke-Jr> of course, it can always be improved even more I'm sure
1198 2013-01-25 19:09:53 <Luke-Jr> (the existing code has been sitting idle for months)
1199 2013-01-25 19:10:30 <jgarzik> Luke-Jr: url?
1200 2013-01-25 19:11:20 forloop has joined
1201 2013-01-25 19:11:26 <Luke-Jr> jgarzik: https://github.com/bitcoin/bitcoin/pull/1647
1202 2013-01-25 19:12:59 <jgarzik> Luke-Jr: The discussion was about bitcoinj
1203 2013-01-25 19:13:49 Cylta has quit (Ping timeout: 264 seconds)
1204 2013-01-25 19:14:09 tonikt has joined
1205 2013-01-25 19:14:50 FredEE_ has joined
1206 2013-01-25 19:15:20 <Luke-Jr> jgarzik: oh, I get it. nm
1207 2013-01-25 19:15:39 tonikt has quit (Read error: Operation timed out)
1208 2013-01-25 19:16:03 tonikt has joined
1209 2013-01-25 19:16:51 Detritus has quit (Remote host closed the connection)
1210 2013-01-25 19:17:36 forloop has quit (Quit: Page closed)
1211 2013-01-25 19:18:20 FredEE has quit (Ping timeout: 256 seconds)
1212 2013-01-25 19:18:21 FredEE_ is now known as FredEE
1213 2013-01-25 19:19:04 freewil has quit (Remote host closed the connection)
1214 2013-01-25 19:23:20 <muhoo> right, it looks like bitcoind already supports it. i guess i'll try to confirm later when td or bluematt are around
1215 2013-01-25 19:23:49 <muhoo> what the status of bitcoinj implementation is
1216 2013-01-25 19:24:11 twixed has joined
1217 2013-01-25 19:24:18 <gavinandresen> status of bitcoinj implementation is "healthy, good"
1218 2013-01-25 19:24:46 <muhoo> gavinandresen: of fee handling?
1219 2013-01-25 19:25:00 <gavinandresen> oh, of fee handling: I believe that is near the top of TD's TODO
1220 2013-01-25 19:25:54 <muhoo> right, i was trying to find out if i should wait, submit a patch, or hack around it outside the library
1221 2013-01-25 19:26:36 <muhoo> i'll ask when he's around
1222 2013-01-25 19:28:12 * muhoo just got confirmation of  his first 2 transactions via bitcoinj (on testnet)
1223 2013-01-25 19:30:16 <BlueMatt> muhoo: whats up?
1224 2013-01-25 19:31:01 <BlueMatt> oh, bitcoinj fee stuff...I dunno exactly, but its up there (if not in master...)
1225 2013-01-25 19:37:19 D34TH has joined
1226 2013-01-25 19:38:55 jdnavarro has quit (Remote host closed the connection)
1227 2013-01-25 19:50:06 root2_ has joined
1228 2013-01-25 19:50:17 twobitcoins__ has joined
1229 2013-01-25 20:00:37 pecket has joined
1230 2013-01-25 20:04:25 skeledrew has joined
1231 2013-01-25 20:04:26 techlife has quit (Ping timeout: 272 seconds)
1232 2013-01-25 20:05:12 techlife has joined
1233 2013-01-25 20:05:13 techlife has quit (Max SendQ exceeded)
1234 2013-01-25 20:05:34 bitnumus_ has quit (Quit: Leaving)
1235 2013-01-25 20:06:20 techlife has joined
1236 2013-01-25 20:06:21 techlife has quit (Max SendQ exceeded)
1237 2013-01-25 20:07:42 techlife has joined
1238 2013-01-25 20:07:43 techlife has quit (Max SendQ exceeded)
1239 2013-01-25 20:07:51 Hashdog has joined
1240 2013-01-25 20:09:02 techlife has joined
1241 2013-01-25 20:09:03 techlife has quit (Max SendQ exceeded)
1242 2013-01-25 20:09:51 techlife has joined
1243 2013-01-25 20:09:52 techlife has quit (Max SendQ exceeded)
1244 2013-01-25 20:10:18 techlife has joined
1245 2013-01-25 20:10:18 techlife has quit (Max SendQ exceeded)
1246 2013-01-25 20:11:05 techlife has joined
1247 2013-01-25 20:11:06 techlife has quit (Max SendQ exceeded)
1248 2013-01-25 20:11:50 techlife has joined
1249 2013-01-25 20:13:21 <grau> Will you be in Bratislava on Sunday ?
1250 2013-01-25 20:14:08 occulta has joined
1251 2013-01-25 20:14:18 <grau> I mean this event: http://www.facebook.com/events/425780117494016/
1252 2013-01-25 20:19:13 <gmaxwell> grau: non-facebook users can't even get a subject line from what you're linking to there.
1253 2013-01-25 20:19:38 <Luke-Jr> UNsystem Bitcoin Conference Preview 2013
1254 2013-01-25 20:19:54 <Luke-Jr> On Sunday 27th January 2013, we will have a great opportunity to see and meet core organizers of the upcoming Bitcoin conference 2013 in our new shiny Progressbar at Michalská 3 in the centre of Bratislava:
1255 2013-01-25 20:19:57 <Luke-Jr> Amir Taaki (Bitcoin developer, Bitcoin conference organizer)
1256 2013-01-25 20:20:01 <Luke-Jr> Cody R Wilson (The Wiki Weapon Project) - Crypto-banking / mutualist political economy
1257 2013-01-25 20:21:05 <Luke-Jr> Juraj Variny, Marek "slush" Palatinus, Mihai Alisie, Mike Gogulski, Nicolas Fischer , Pavol Rusnak, Peter Surda, yossarian, Jamileh Taaki , Mark David Lamb, Stefan Thomas, Andreas Schildbach, Frank Braun , Joerg Platzer
1258 2013-01-25 20:21:09 <grau> Juraj Variny - How to invest into the biggest bitcoin stock exchange and the broker service coinbr.com
1259 2013-01-25 20:21:09 <grau> Marek "slush" Palatinus (Author of Bitcoin.cz pool) - Trezor hardware bitcoin wallet
1260 2013-01-25 20:21:09 <grau> Mihai Alisie (Bitcoin magazine)
1261 2013-01-25 20:21:11 <grau> Mike Gogulski (Bitcoin laundry) - panel moderator
1262 2013-01-25 20:21:13 <grau> Nicolas Fischer (Bitcoin conference organizer)
1263 2013-01-25 20:21:15 <grau> Pavol Rusnak - Trezor hardware bitcoin wallet
1264 2013-01-25 20:21:17 <grau> Peter Surda - Economics of Bitcoin
1265 2013-01-25 20:21:19 <grau> yossarian - lawyer and Bitcoin conference organiser. He's a big local dealer in Berlin with lots of interesting stories.
1266 2013-01-25 20:21:21 <grau> Jamileh Taaki - studying astrophysics at London university
1267 2013-01-25 20:21:23 <grau> Mark David Lamb - Bitcoin entrepreneur from London
1268 2013-01-25 20:21:25 <grau> Stefan Thomas - author of BitcoinJS and WeUseCoins Bitcoin video / website
1269 2013-01-25 20:21:27 <grau> Andreas Schildbach - created Bitcoin for Android and developer for BitcoinJ (he's recently taken over) which is the Bitcoinimplementation used on most phone clients and MultiBit. Bitcoin Wallet for Android
1270 2013-01-25 20:21:29 <grau> Frank Braun - the masked privacy extremist who was at the London conference doing a lecture on cryptoanarchism. Also his buddy Smuggler.
1271 2013-01-25 20:21:31 <grau> Joerg Platzer - started accepting Bitcoin at his restaurant; Room77. It's famous for its delicious hamburgers in a posh part of Berlin called Kreuzberg. The area was bohemian and retains that feel. Local shops dominate. Joerg was getting popular in the press, and other curious shop-owners became interested. All along the road, shops are now accepting Bitcoin. You can walk the Bitcoin mile in
1272 2013-01-25 20:21:33 <grau> Berlin's Kreuzberg.
1273 2013-01-25 20:21:33 <Luke-Jr> …
1274 2013-01-25 20:21:39 <Luke-Jr> grau: I intentionally avoided doing that :P
1275 2013-01-25 20:21:51 <grau> why?
1276 2013-01-25 20:22:00 <Luke-Jr> it's considered bad ettiquite on IRC :P
1277 2013-01-25 20:22:08 <BlueMatt> because you just pasted like 30 lines....
1278 2013-01-25 20:22:28 <grau> I know, since I was asked to carry over what was not visible.
1279 2013-01-25 20:22:52 <grau> will I now be banned :)?
1280 2013-01-25 20:23:38 <Luke-Jr> if you weren't grau, you might have been. instead now we're all just glaring at you :P
1281 2013-01-25 20:24:05 <grau> ok, shaming...
1282 2013-01-25 20:25:01 <grau> I will be there and, so I was curious who else
1283 2013-01-25 20:25:39 <Luke-Jr> grau: the Foundation is doing a different Bitcoin Conference I think
1284 2013-01-25 20:25:51 <Luke-Jr> perhaps they should say "of America" and "of Europe" :p
1285 2013-01-25 20:26:13 <HM> Konversation (KDE irc client) warns you if you paste too many lines, and gives you the option to cancel or edit. It's awesome
1286 2013-01-25 20:26:13 <grau> I know. I will be there too likely but this one is considerably closer to me
1287 2013-01-25 20:27:32 tonikt has quit (Read error: Connection reset by peer)
1288 2013-01-25 20:28:07 * jgarzik glares at grau :)
1289 2013-01-25 20:28:39 <grau> I do not think Amir's conference represents Europe. Its an other flavor. I would have preferred the Foundation one closer to me.
1290 2013-01-25 20:30:20 <Luke-Jr> well, technically nobody represents any country - but that's where they're located :P
1291 2013-01-25 20:31:33 <ThomasV> grau: the bitcoin mile, really? how many shops?
1292 2013-01-25 20:32:35 <grau> Cant tell, I was not in Berlin since I heard about that.
1293 2013-01-25 20:33:56 <grau> Do you also like to watch the bitcoin globe? I love to see that it is all over, and am especially proud that eastern Europe is well represented.
1294 2013-01-25 20:34:57 <HM> no Bitcoin in Antartica :(
1295 2013-01-25 20:35:29 <grau> Its the promised land for mining!
1296 2013-01-25 20:36:42 b4epoche has quit (Ping timeout: 255 seconds)
1297 2013-01-25 20:37:38 <muhoo> hmm it seems that bitcoinj doesn't generate new addresses for change by default either Sends 0.00001 and receives 0.00000999, total value -0.00000001.
1298 2013-01-25 20:37:41 <muhoo>   fb93dd31f58293d478ec947924b3448ac88b816e6a4afe95a31ca87407edf7e0: Not seen in chain.
1299 2013-01-25 20:37:44 <muhoo>      from mrQtGtxwzLLqLxFUn3DobtvQuY7kaMJJuv / outpoint 1a1ed8305f804245bb12da580f7787cdc8d746af4f4d33911b74dbdf1601b7f4:1
1300 2013-01-25 20:37:47 <muhoo>        to n19t3dQYNCeuUhwCbk7GaDpjeYGbwBL8Kb 0.00000001 BTC
1301 2013-01-25 20:37:49 <muhoo>        to mrQtGtxwzLLqLxFUn3DobtvQuY7kaMJJuv 0.00000999 BTC
1302 2013-01-25 20:38:10 <muhoo> auugh, that was supposed to be the paste link, https://www.refheap.com/paste/8962
1303 2013-01-25 20:39:28 b4epoche has joined
1304 2013-01-25 20:45:14 FredEE has quit (Quit: FredEE)
1305 2013-01-25 20:45:20 bitnumus has quit (Read error: Connection reset by peer)
1306 2013-01-25 20:46:11 bitnumus has joined
1307 2013-01-25 20:50:42 <gavinandresen> kuzetsa: I just rewrote the Transaction Fees wiki page to hopefully be clearer and more accurate.  https://en.bitcoin.it/wiki/Transaction_fees
1308 2013-01-25 20:55:00 skeledrew has quit (Ping timeout: 248 seconds)
1309 2013-01-25 20:57:45 Luke-Jr has quit (Ping timeout: 245 seconds)
1310 2013-01-25 21:05:14 skeledrew has joined
1311 2013-01-25 21:06:58 JZavala has joined
1312 2013-01-25 21:07:17 toffoo has quit ()
1313 2013-01-25 21:09:13 gigavps has quit (Quit: Leaving)
1314 2013-01-25 21:12:21 <muhoo> hmm http://code.google.com/p/bitcoinj/issues/detail?id=107&colspec=ID%20Type%20Status%20Priority%20Component%20Owner%20Summary  so it's still open. didn't find any branch that looked like it had it
1315 2013-01-25 21:12:53 daybyter has quit (Quit: Konversation terminated!)
1316 2013-01-25 21:16:05 ThomasV has quit (Ping timeout: 245 seconds)
1317 2013-01-25 21:17:06 occulta has quit (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/)
1318 2013-01-25 21:19:22 <helo> would be neat if there was a mining pool that donated the tx fees to the foundation
1319 2013-01-25 21:19:37 Belkaar has quit (Ping timeout: 240 seconds)
1320 2013-01-25 21:19:47 ThomasV has joined
1321 2013-01-25 21:20:37 Belkaar has joined
1322 2013-01-25 21:21:14 <helo> wouldn't exactly last the test of time as fees become more substantial...
1323 2013-01-25 21:22:32 occulta has joined
1324 2013-01-25 21:23:04 FredEE has joined
1325 2013-01-25 21:24:35 MaxSan has joined
1326 2013-01-25 21:24:35 FredEE has quit (Client Quit)
1327 2013-01-25 21:25:30 FredEE has joined
1328 2013-01-25 21:29:03 <HM> are there any theories as to how high fees will reach?
1329 2013-01-25 21:29:49 root2_ is now known as root2
1330 2013-01-25 21:29:51 <HM> i take it the adaptive difficulty will keep them capped
1331 2013-01-25 21:31:21 <helo> HM: the fees will determine the difficulty
1332 2013-01-25 21:31:47 <helo> HM: rather than the other way around
1333 2013-01-25 21:32:51 <helo> i suppose the upper bound on fees would be the cost to transfer large sums of money using competing/traditional systems
1334 2013-01-25 21:34:09 <helo> plus the value of bitcoin's advantages over those systems
1335 2013-01-25 21:36:29 <HM> How quickly does the difficulty change?
1336 2013-01-25 21:36:38 <HM> is it recalculated after ever block?
1337 2013-01-25 21:37:01 <helo> every 2016 blocks (~2 weeks)
1338 2013-01-25 21:37:14 <helo> based on the average hashrate for the prior 2016 blocks
1339 2013-01-25 21:37:31 <helo> so that, if that hashrate continued, blocks would come out every 10 minutes
1340 2013-01-25 21:37:37 <HM> so it doesn't really respond well to sudden surges or slumps in the # of transactions
1341 2013-01-25 21:37:55 <HM> regular trading has low volume periods
1342 2013-01-25 21:38:34 <HM> it seems to me when the block reward is marginal but the difficulty is high it might stall the system a bit for people offering relatively low fees
1343 2013-01-25 21:40:14 <helo> yeah, that is possible
1344 2013-01-25 21:40:53 <helo> whether it will happen to the extent that it harms bitcoin's usability/popularity is up for debate though
1345 2013-01-25 21:41:26 <HM> yeah and many models will adapt
1346 2013-01-25 21:41:54 <HM> the spread on exchanges will always widen in times of low volume anyway
1347 2013-01-25 21:42:59 freewil has joined
1348 2013-01-25 21:43:30 FredEE has quit (Remote host closed the connection)
1349 2013-01-25 21:43:50 <HM> and traditional banking models and online wallets will short circuit many transactions
1350 2013-01-25 21:43:52 <helo> i'm not sure that exchange volume is a huge part of bitcoin transaction volume
1351 2013-01-25 21:43:54 FredEE has joined
1352 2013-01-25 21:44:58 <helo> most exchanges track user balances using internal databases, and only send a transaction when a user cashes out
1353 2013-01-25 21:46:01 <helo> yeah, as you said 'short circuit'
1354 2013-01-25 21:47:48 <HM> the slower it is to make small transactions the more people will go for those 'internal database' hosted solutions
1355 2013-01-25 21:49:56 <HM> it'll be an interesting aspect to follow anyway
1356 2013-01-25 21:50:18 <kuzetsa> gavinandresen: I didn't actually see how the new revision is any clearer, but it looks nicer / thanks.
1357 2013-01-25 21:51:00 <kuzetsa> either way, it's less clutter & better presented.
1358 2013-01-25 22:05:41 ThomasV has quit (Ping timeout: 252 seconds)
1359 2013-01-25 22:08:40 freewil has quit (Remote host closed the connection)
1360 2013-01-25 22:12:43 ThomasV has joined
1361 2013-01-25 22:12:59 freewil has joined
1362 2013-01-25 22:13:27 MaxSan has left ()
1363 2013-01-25 22:25:14 spaz926_ has joined
1364 2013-01-25 22:25:15 spaz926_ has quit (Client Quit)
1365 2013-01-25 22:25:32 sgornick has joined
1366 2013-01-25 22:27:51 rdymac has joined
1367 2013-01-25 22:29:24 spaz926 has quit (Ping timeout: 260 seconds)
1368 2013-01-25 22:42:07 rdymac has quit (Ping timeout: 240 seconds)
1369 2013-01-25 22:42:39 ThomasV has quit (Ping timeout: 252 seconds)
1370 2013-01-25 22:53:16 int0x27h has quit (Quit: bye)
1371 2013-01-25 22:54:46 int0x27h has joined
1372 2013-01-25 22:55:50 sgornick has quit (Ping timeout: 276 seconds)
1373 2013-01-25 22:57:56 one_zero has joined
1374 2013-01-25 23:04:36 sgornick has joined
1375 2013-01-25 23:10:15 gavinandresen has quit (Quit: gavinandresen)
1376 2013-01-25 23:12:39 grau has quit (Remote host closed the connection)
1377 2013-01-25 23:21:39 rich__ has joined
1378 2013-01-25 23:23:06 ageis has quit (Quit: http://ageispolis.net)
1379 2013-01-25 23:25:10 ageis has joined
1380 2013-01-25 23:33:37 agricocb has quit (Quit: Leaving.)
1381 2013-01-25 23:34:45 porquilho has quit ()
1382 2013-01-25 23:40:11 CodeInChaos has joined
1383 2013-01-25 23:42:06 CodesInChaos has quit (Ping timeout: 255 seconds)
1384 2013-01-25 23:45:40 ovidiusoft has quit (Ping timeout: 248 seconds)
1385 2013-01-25 23:47:12 yareyare has joined
1386 2013-01-25 23:48:28 WolfAlex has quit (Remote host closed the connection)
1387 2013-01-25 23:49:20 WolfAlex has joined
1388 2013-01-25 23:54:46 BTCOxygen has joined
1389 2013-01-25 23:56:29 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
1390 2013-01-25 23:57:10 tsche has joined
1391 2013-01-25 23:57:13 BTCOxygen has quit (Client Quit)
1392 2013-01-25 23:57:24 BTCOxygen has joined