1 2012-07-03 00:01:14 <nanotube> if the fire ants are that much different in poison susceptibility than other ants, you might do better to look specifically for fire-ant products. this is where google comes in handy. :)
   2 2012-07-03 00:01:29 <jrmithdobbs> nanotube: oh i know what products to use
   3 2012-07-03 00:01:43 <jrmithdobbs> nanotube: it was more how/where to apply/etc
   4 2012-07-03 00:02:21 <jrmithdobbs> nanotube: i think between yours and gmaxwell's suggestion to strangle the pass, so to speak, i've got a plan of action
   5 2012-07-03 00:02:28 <nanotube> ah ic. well, behind the panel is it, i think. :)
   6 2012-07-03 00:02:41 <jrmithdobbs> noone i've been asking all day came up with anything as simple/effective ;p
   7 2012-07-03 00:02:56 <jrmithdobbs> exterminator told me they'd want to spray the whole thing and make me clean it again :(
   8 2012-07-03 00:02:58 <nanotube> you don't want to strangle the pass /and/ put poison there - because if strangling is effective, they'll find another way in and miss the poison.
   9 2012-07-03 00:03:18 <sipa> this is certainly not the most common type of discussion here :)
  10 2012-07-03 00:03:36 <nanotube> try the poison first and give it a few days, if that has no effect, then you can try resorting to physical barriers.
  11 2012-07-03 00:03:39 <jrmithdobbs> nanotube: yes, but i can narrow it so it's only an exit from where they're going instead of to the rest of the frame of the car and put the bait in the narrowed section
  12 2012-07-03 00:03:44 <sipa> maybe they're talking about some ant colony optimization algorithm for improving network connectivity?
  13 2012-07-03 00:03:49 <nanotube> sipa: er... i mean... try installing bdb 4.8 :)
  14 2012-07-03 00:04:05 <sipa> nanotube: i'm not complaining :)
  15 2012-07-03 00:04:09 <nanotube> heh
  16 2012-07-03 00:04:30 <jrmithdobbs> sipa: heh, sorry, frustrated and running out of people to ask, everyone seems to find it an interesting topic, this is the first time anyone's had helpful ideas though ;p
  17 2012-07-03 00:05:01 <jrmithdobbs> sipa: there's ants in my (fuckin) car if you missed that part, lol
  18 2012-07-03 00:05:07 <sipa> meh, as long as nobody has real dev talk to do here, i don't really care :)
  19 2012-07-03 00:06:11 <jrmithdobbs> sipa: setting up an onion-accessible node has taught me that i have way too many personal cpus
  20 2012-07-03 00:06:22 <sipa> heh
  21 2012-07-03 00:06:40 <jrmithdobbs> Found matching domain after 41971237735 tries: deezbtcqqbzngaee.onion
  22 2012-07-03 00:06:48 * sipa stares at the list of 60 compile errors in main.cpp, and decides to go to sleep
  23 2012-07-03 00:06:48 <jrmithdobbs> (not up right this second)
  24 2012-07-03 00:07:22 <jrmithdobbs> (was running on ~10 boxes so the search domain is 20x too, ha)
  25 2012-07-03 00:10:15 tadas has joined
  26 2012-07-03 00:11:23 Prattler has quit (Quit: Ex-Chat)
  27 2012-07-03 00:12:03 Prattler has joined
  28 2012-07-03 00:12:43 hattorihanzo has quit (Read error: Connection reset by peer)
  29 2012-07-03 00:12:51 Prattler has quit (Client Quit)
  30 2012-07-03 00:13:29 hattorihanzo has joined
  31 2012-07-03 00:17:12 tadas is now known as Prattler
  32 2012-07-03 00:17:20 Karmaon__ is now known as Karmaon
  33 2012-07-03 00:17:35 Karmaon has quit (Changing host)
  34 2012-07-03 00:17:35 Karmaon has joined
  35 2012-07-03 00:19:16 [7] has quit (Ping timeout: 248 seconds)
  36 2012-07-03 00:25:19 TheSeven has joined
  37 2012-07-03 00:25:55 abracadab is now known as abracadabra
  38 2012-07-03 00:32:10 Prattler2 has joined
  39 2012-07-03 00:32:26 graingert has quit (Read error: Connection reset by peer)
  40 2012-07-03 00:42:45 toffoo has quit ()
  41 2012-07-03 00:43:35 Prattler has quit (Quit: ZNC - http://znc.in)
  42 2012-07-03 00:44:13 Prattler has joined
  43 2012-07-03 00:47:14 jurov is now known as jurov|away
  44 2012-07-03 00:47:32 imsaguy has quit (Ping timeout: 248 seconds)
  45 2012-07-03 00:48:04 Prattler2 has quit (Quit: Ex-Chat)
  46 2012-07-03 00:52:33 Turingi has quit (Read error: Connection reset by peer)
  47 2012-07-03 01:03:23 dvide has quit ()
  48 2012-07-03 01:11:53 rdponticelli_ has joined
  49 2012-07-03 01:12:39 rdponticelli has quit (Ping timeout: 255 seconds)
  50 2012-07-03 01:21:02 Elio19 has joined
  51 2012-07-03 01:27:56 rdponticelli_ has quit (Read error: Connection reset by peer)
  52 2012-07-03 01:28:37 BeTep has quit (Ping timeout: 240 seconds)
  53 2012-07-03 01:28:40 Elio19 has quit (Ping timeout: 244 seconds)
  54 2012-07-03 01:29:36 weather has joined
  55 2012-07-03 01:32:42 rdponticelli has joined
  56 2012-07-03 01:33:26 weather is now known as BeTep
  57 2012-07-03 01:41:14 Elio19 has joined
  58 2012-07-03 01:43:14 <gribble> New news from bitcoinrss: TheBlueMatt opened issue 1550 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1550>
  59 2012-07-03 01:43:49 imsaguy has joined
  60 2012-07-03 01:51:08 rdponticelli_ has joined
  61 2012-07-03 01:51:37 yellowhat_ has joined
  62 2012-07-03 01:51:41 rdponticelli has quit (Ping timeout: 246 seconds)
  63 2012-07-03 01:53:26 yellowhat has quit (Ping timeout: 246 seconds)
  64 2012-07-03 01:53:28 osmosis has quit (Read error: Connection reset by peer)
  65 2012-07-03 01:53:32 yellowhat_ is now known as yellowhat
  66 2012-07-03 02:05:50 Elio19 has quit (Changing host)
  67 2012-07-03 02:05:50 Elio19 has joined
  68 2012-07-03 02:06:50 TheSeven has quit (Read error: Operation timed out)
  69 2012-07-03 02:08:33 TheSeven has joined
  70 2012-07-03 02:11:31 avengre has joined
  71 2012-07-03 02:25:18 agricocb has quit (Remote host closed the connection)
  72 2012-07-03 02:26:12 agricocb has joined
  73 2012-07-03 02:41:29 eoss has quit (Remote host closed the connection)
  74 2012-07-03 02:51:34 jimbit_ is now known as jjiimm_64
  75 2012-07-03 02:53:08 jjiimm_64 is now known as jimbit
  76 2012-07-03 02:59:35 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1551 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1551>
  77 2012-07-03 03:03:32 TheSeven has quit (Disconnected by services)
  78 2012-07-03 03:03:42 [7] has joined
  79 2012-07-03 03:04:22 Transformer has joined
  80 2012-07-03 03:06:13 Transformer has quit (Excess Flood)
  81 2012-07-03 03:41:59 tgs3 has joined
  82 2012-07-03 03:42:21 <tgs3> bitcoind is unbearably slow, every program on compyter that touches hard drive freezes for many seconds
  83 2012-07-03 03:42:25 <tgs3> linux 2.6 kernel debian
  84 2012-07-03 03:42:37 <tgs3> 0.6.3 bitcoind, catching up to chain
  85 2012-07-03 03:43:30 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
  86 2012-07-03 03:44:31 <tgs3> bitcoind getinfo command takes 47 second to execute, teach time (more or less)
  87 2012-07-03 03:46:51 Karmaon has quit (Read error: Connection reset by peer)
  88 2012-07-03 03:47:17 Karmaon has joined
  89 2012-07-03 03:47:17 Karmaon has quit (Changing host)
  90 2012-07-03 03:47:17 Karmaon has joined
  91 2012-07-03 03:47:38 Tykling has quit (Excess Flood)
  92 2012-07-03 03:48:28 Tykling has joined
  93 2012-07-03 03:49:34 Tykling has quit (Excess Flood)
  94 2012-07-03 03:55:27 Tykling has joined
  95 2012-07-03 03:55:55 rdponticelli has joined
  96 2012-07-03 03:56:38 rdponticelli_ has quit (Ping timeout: 246 seconds)
  97 2012-07-03 03:57:05 agricocb has quit (Remote host closed the connection)
  98 2012-07-03 03:57:52 agricocb has joined
  99 2012-07-03 04:00:59 minimoose has joined
 100 2012-07-03 04:06:05 <gmaxwell> tgs time to fix your failing drive.
 101 2012-07-03 04:08:25 <tgs3> gmaxwell: no problems with other disk trashing applications
 102 2012-07-03 04:08:38 <tgs3> remarkably even freenet causes less trouble
 103 2012-07-03 04:11:10 * tgs3 runs smart to be sure
 104 2012-07-03 04:16:11 <gmaxwell> tgs3: in any case, during initial sync bitcoin does a ton of both reading and writing.  Making your computer freeze for many seconds isn't expected, or what, e.g. I expirence.
 105 2012-07-03 04:19:19 RainbowDashh has joined
 106 2012-07-03 04:19:37 <tgs3> me neither with previous versions of bitcoin
 107 2012-07-03 04:25:21 <doublec> tgs3: I experience the same
 108 2012-07-03 04:26:18 <doublec> but large amounts of i/o tend to cause long delays in other apps for me so I assume it's just that
 109 2012-07-03 04:35:53 <gmaxwell> tgs3: whats previous for you?
 110 2012-07-03 04:36:26 <gmaxwell> Older versions of bitcoin were much less efficient and spent a lot of time doing nothing.
 111 2012-07-03 04:38:34 minimoose has quit (Quit: minimoose)
 112 2012-07-03 04:38:45 MobiusL has quit (Ping timeout: 276 seconds)
 113 2012-07-03 04:38:46 darkee has quit (!~darkee@gateway/tor-sasl/darkee|Ping timeout: 276 seconds)
 114 2012-07-03 04:38:46 guruvan_ has quit (Ping timeout: 276 seconds)
 115 2012-07-03 04:39:27 osmosis has joined
 116 2012-07-03 04:41:05 darkee has joined
 117 2012-07-03 04:43:33 guruvan_ has joined
 118 2012-07-03 04:46:45 <tgs3> gmaxwell: certainly that is better then making uses thing btc is making their computer useless
 119 2012-07-03 04:46:49 <tgs3> *users
 120 2012-07-03 04:50:52 MobiusL has joined
 121 2012-07-03 04:51:14 * luke-jr wonders if we should make bitcoin ionice itself on Linux
 122 2012-07-03 04:52:25 <tgs3> luke-jr that does not help much
 123 2012-07-03 04:52:38 <luke-jr> I know, Linux sucks at IO management -.-
 124 2012-07-03 04:52:43 <tgs3> programs should moderate themselves
 125 2012-07-03 04:52:45 <tgs3> it doe
 126 2012-07-03 04:53:11 <tgs3> linux IO is quite a fail, but applications too should moderate and optimize
 127 2012-07-03 04:54:05 <tgs3> io-miss-managment is worsened in case of disk encryption, a quite possible option among possible btc users
 128 2012-07-03 04:54:28 <gmaxwell> tgs3: As I mentioned it doesn't have that behavior for me. — even testing on a system with dmcrypt.
 129 2012-07-03 04:54:40 <luke-jr> gmaxwell: you have SSD? :P
 130 2012-07-03 04:54:43 <tgs3> gmaxwell: it seems doublec experiences the same problem
 131 2012-07-03 04:55:16 <gmaxwell> luke-jr: no— testing on a spinning disk + dmcrypt. It makes the disk busy but doesn't make the system noticably unresponsive.
 132 2012-07-03 04:55:43 <tgs3> try debian stable
 133 2012-07-03 04:56:25 <gmaxwell> Sorry, I like my software to come from later than the mid 1780s.
 134 2012-07-03 04:56:45 <gmaxwell> (my spinning disk system is Fedora 16)
 135 2012-07-03 04:57:15 <gjs278> I have 5 ssds in a raid5, I don't get any slowdown
 136 2012-07-03 04:57:21 <gjs278> that's probably the minimum requirements
 137 2012-07-03 04:57:27 <tgs3> maybe program should be upgraded to work even on debian stable, instead of requiring users to move
 138 2012-07-03 04:57:42 <tgs3> debian is not that 'rare' among geeks, servers ops and cryptoalike folk
 139 2012-07-03 04:57:51 <gmaxwell> seriously, luke got in a fight with the debian mainters because they wouldn't upgrade from their vulnerable bitcoin version— because the new versions failed on LE-MIPS and SPARC, nevermind that no version of the reference client has ever worked on those platforms.  This isn't software you want to run.
 140 2012-07-03 04:58:25 <luke-jr> gmaxwell: well, that doesn't make all of Debian bad :p
 141 2012-07-03 04:58:38 <tgs3> is it their fault the package failed on sparc?
 142 2012-07-03 04:58:55 <gmaxwell> tgs3: Big endian is not supported by the software.
 143 2012-07-03 04:58:57 <luke-jr> tgs3: Bitcoin has *never* worked on SPARC
 144 2012-07-03 04:59:00 <tgs3> I don't want to point fingers but I thought you guys develop and they pack/pull
 145 2012-07-03 04:59:02 <gmaxwell> It has never been supported, it never worked.
 146 2012-07-03 04:59:28 <tgs3> luke-jr: funny.. so that is a problem to upgrade a thing but not to release it initially? what?
 147 2012-07-03 05:00:29 <gmaxwell> tgs3: Early versions of bitcoin had no tests. Because no one connected to debian ever bothered even starting it on the systems they were targeting they didn't _know_ it didn't work there until we added tests that told them.
 148 2012-07-03 05:00:42 <gmaxwell> And as a result, they wouldn't upgrade.
 149 2012-07-03 05:00:44 <tgs3> is it actually that impossible to run on LE? what pleaces depend on it, with mining out.. some controll-sums?
 150 2012-07-03 05:01:15 <tgs3> well that decissions seems obviously illogical...
 151 2012-07-03 05:01:16 <luke-jr> tgs3: not impossible, just difficult because Satoshi can't code and nobody has time to fix it
 152 2012-07-03 05:01:37 <gmaxwell> er BE.
 153 2012-07-03 05:01:50 <gmaxwell> (of course)
 154 2012-07-03 05:01:51 <tgs3> mythical characters usually are not good at real life coding
 155 2012-07-03 05:02:07 <luke-jr> lol
 156 2012-07-03 05:03:18 <gmaxwell> tgs3: Most people who've audited the codebase have been generally pretty complementary about it. ::shrugs:: in any case, there is a bunch of straight transformations that expect the in memory and on wire formats to be the same. Which isn't grand. It's also not that big a deal. But chasing all of them down takes work which no one cares to work on because there are so many other things to do.
 157 2012-07-03 05:03:22 <tgs3> like my Faun
 158 2012-07-03 05:03:35 <tgs3> can't get that damn bastard to fix bugs in kernel we run on our pc
 159 2012-07-03 05:04:30 <tgs3> no one cares to do it... oh well.  Too bad we do not have any open source micro donations and payment systems or something, if only we had developed something like that instea
 160 2012-07-03 05:04:39 <tgs3> it would be totally handy now
 161 2012-07-03 05:04:43 <gmaxwell> yuck.
 162 2012-07-03 05:04:45 brwyatt is now known as brwyatt|Away
 163 2012-07-03 05:05:10 <luke-jr> tgs3: well, what do you need micropayments for?
 164 2012-07-03 05:05:18 <gmaxwell> In any case, no one actually cares about it... if they did it would get fixed.
 165 2012-07-03 05:05:29 <tgs3> well if we would have any micropayments, one could make a bounty.
 166 2012-07-03 05:05:49 <luke-jr> tgs3: no programmer is going to spend time on something they don't care about for micropayment bounties
 167 2012-07-03 05:05:54 <luke-jr> you need something more real
 168 2012-07-03 05:06:08 <tgs3> I assumes SPARC incompatibility will be roadblock for further debian releases. That seems problematic considering what is popular on servers
 169 2012-07-03 05:06:11 MysteryBanshee has joined
 170 2012-07-03 05:06:24 <luke-jr> tgs3: x86 is pretty popular on servers these days
 171 2012-07-03 05:06:31 <luke-jr> ARM is trying to get in, but that's LE too
 172 2012-07-03 05:06:31 MysteryBanshee has quit (Changing host)
 173 2012-07-03 05:06:31 MysteryBanshee has joined
 174 2012-07-03 05:06:36 <tgs3> but debian will refuse to get it
 175 2012-07-03 05:06:41 <tgs3> and I can sympathaise
 176 2012-07-03 05:06:48 <gmaxwell> And attaching real money to BE support .. for the sake of it, is BS distortion of development incentives.
 177 2012-07-03 05:06:53 <tgs3> SPARC is related to open-sparc is it not?
 178 2012-07-03 05:07:26 <luke-jr> shrug
 179 2012-07-03 05:07:35 <tgs3> if thats the thing, then, if I would really want one software in the world to be run on open hardware (not controlled by biggest govs&corps) it might be ecurrency wallet if anything
 180 2012-07-03 05:07:43 <luke-jr> if someone wants to pay me 10+ BTC/hr to fix BE, I'd do it :p
 181 2012-07-03 05:07:45 <gmaxwell> In _general_ debian stable's update policy is incompatible with Bitcoin.. Bitcoin is evolving beta software. It doesn't belong in a stable distribution that only rarely gets updates.
 182 2012-07-03 05:08:09 <luke-jr> gmaxwell: no, they can use stable branches
 183 2012-07-03 05:08:31 <tgs3> gmaxwell: I think making bitcoin more stable and portable would speed up adoption. and the hdd thing (affecting at least some users). THEN users will apt-get install bitcoin. Unless we do not want many users/nodes... but then we are doing it wrong
 184 2012-07-03 05:09:10 <gmaxwell> luke-jr: Yea, ones that incorrectly handle BIP16 for months? :(   I don't intend to insult the effort you put into that, but I wouldn't generally recommend them to anyone who didn't have a big patch load. They are not clearly safer by any metric.
 185 2012-07-03 05:09:21 <luke-jr> tgs3: choose one: 1) slightly worse system responsiveness during blockchain download, or 2) multi-day initial blockchain sync
 186 2012-07-03 05:09:25 <tgs3> what I liked in bitcoin is that its streight forward tool to verify sha256 + signs + p2p net.  Should be uniersal and VERY stable, like the underlying math of bitcoin
 187 2012-07-03 05:09:54 <luke-jr> gmaxwell: I blame BIP16 for that.
 188 2012-07-03 05:09:58 MobiusL has quit (Ping timeout: 276 seconds)
 189 2012-07-03 05:10:06 <gmaxwell> tgs3: bitcoin taking multiple days to sync up was not good. Fix your computer. seriously. This isn't bitcoin's problem.
 190 2012-07-03 05:10:08 <tgs3> luke-jr: 2) or  3) I uninstall bitcoin and use real money
 191 2012-07-03 05:10:12 <luke-jr> gmaxwell: if it wasn't such an overly complicated protocol change, it wouldn't have had a huge gap for new bugs
 192 2012-07-03 05:10:54 <tgs3> gmaxwell: well you do not look from end user perspective. or is bitcoin intended to reach only few cryptogeeks instead of general population that thinks internet = facebook and stuffs hamburgers in their faces
 193 2012-07-03 05:10:55 MobiusL has joined
 194 2012-07-03 05:11:26 <luke-jr> tgs3: are you offering to improve the status quo?
 195 2012-07-03 05:11:32 <tgs3> if the later, then trashing hard drive speed, reducing hdd life-time, or not heaving a nice GUI and icon = no go.
 196 2012-07-03 05:11:35 <luke-jr> tgs3: besides, Electrum.
 197 2012-07-03 05:11:42 <tgs3> luke-jr: Elewhat?
 198 2012-07-03 05:11:45 <gmaxwell> tgs3: Please don't insult me.
 199 2012-07-03 05:11:58 <luke-jr> tgs3: Electrum is a lighter Bitcoin client
 200 2012-07-03 05:12:03 <luke-jr> http://bitcoin.org/clients.html
 201 2012-07-03 05:12:21 <tgs3> gmaxwell: what again? I dont :)
 202 2012-07-03 05:12:24 <gmaxwell> tgs3: I and a lot of other people spent a lot of time trying to figure out how to reduce the multiday syncup times that the last guy was screaming made bitcoin only usable for cryptogeeks.
 203 2012-07-03 05:12:26 <luke-jr> … why does that attribute Bitcoin-Qt to Satoshi? he didn't write that -.-
 204 2012-07-03 05:14:08 <tgs3> or did he
 205 2012-07-03 05:16:51 <galambo> might have well as been "john smith" right
 206 2012-07-03 05:16:59 <gmaxwell> tgs3: in any case, sorry if I came off harsh. It's been a long month.  As far as your problem goes— try ionicing it.
 207 2012-07-03 05:18:06 <gmaxwell> tgs3: beyond that I can only report that on my one spinning disk + dmcrypt test system I don't notice any adverse interactivity problems during syncup. But it fairly IO intensive by its very nature. Improving IO is a long term thing with many steps constantly being worked on along the way.
 208 2012-07-03 05:20:29 <tgs3> gmaxwell: hope it progresses then. At some later time I might try to check again ionice
 209 2012-07-03 05:21:17 <gmaxwell> tgs3: How much ram does your system have?
 210 2012-07-03 05:22:43 <tgs3> 8 gb
 211 2012-07-03 05:23:14 <gmaxwell> ha. okay scratch that theory.
 212 2012-07-03 05:23:42 <gmaxwell> (I was wondering if perhaps you were going to tell me "128mb" or something like that— :))
 213 2012-07-03 05:24:03 maaku has joined
 214 2012-07-03 05:24:24 <gmaxwell> tgs3: well, to end your pain temporarily— do your syncup using tmpfs.
 215 2012-07-03 05:24:29 <gmaxwell> You will be quite happy. :)
 216 2012-07-03 05:28:46 hnz has joined
 217 2012-07-03 05:29:50 <tgs3> my 128mb is more responsible then this+bitcoind ;)
 218 2012-07-03 05:30:21 <tgs3> tmpfs might be a good idea. gotta backup wallet too
 219 2012-07-03 05:31:17 <gmaxwell> well, you'd run with tmpfs (and -detatchdb) option just for sync.. then shut down and move everything back to the normal location.  With good and lucky network connectivity and a moderately fast cpu you can happily sync in under an hour on tmpfs.
 220 2012-07-03 05:34:15 RainbowDashh has quit (Quit: SLEEP MODE.  [NSFW!]  [WIERD] [WTF] http://pastebin.com/6L0WjKRk)
 221 2012-07-03 06:06:14 D34TH has quit (Read error: Connection reset by peer)
 222 2012-07-03 06:08:00 osmosis has quit (Quit: Leaving)
 223 2012-07-03 06:23:05 Prattler has quit (Quit: ZNC - http://znc.in)
 224 2012-07-03 06:28:17 ovidiusoft has joined
 225 2012-07-03 06:29:05 devrandom has quit (Remote host closed the connection)
 226 2012-07-03 06:29:37 devrandom has joined
 227 2012-07-03 06:32:44 maaku has quit (Quit: maaku)
 228 2012-07-03 06:33:12 maaku has joined
 229 2012-07-03 06:34:23 Prattler has joined
 230 2012-07-03 06:48:29 RazielZ has joined
 231 2012-07-03 06:53:32 one_zero has joined
 232 2012-07-03 06:59:55 word_ has joined
 233 2012-07-03 07:00:53 taisun has joined
 234 2012-07-03 07:02:50 word has quit (Ping timeout: 246 seconds)
 235 2012-07-03 07:04:06 rdponticelli has quit (Ping timeout: 264 seconds)
 236 2012-07-03 07:05:03 paul0 has joined
 237 2012-07-03 07:12:30 molecular has quit (Ping timeout: 264 seconds)
 238 2012-07-03 07:13:29 molecular has joined
 239 2012-07-03 07:22:57 sirk390 has joined
 240 2012-07-03 07:24:19 Karmaon has quit (Read error: Connection reset by peer)
 241 2012-07-03 07:24:42 Karmaon has joined
 242 2012-07-03 07:24:42 Karmaon has quit (Changing host)
 243 2012-07-03 07:24:42 Karmaon has joined
 244 2012-07-03 07:29:01 pickett has quit (Remote host closed the connection)
 245 2012-07-03 07:33:30 taisun has quit (Quit: Leaving)
 246 2012-07-03 07:36:02 sirk390 has quit (Quit: Leaving.)
 247 2012-07-03 07:44:06 rcorreia has joined
 248 2012-07-03 07:47:14 ThomasV has joined
 249 2012-07-03 08:04:44 word_ is now known as word
 250 2012-07-03 08:04:58 word has quit (Changing host)
 251 2012-07-03 08:04:58 word has joined
 252 2012-07-03 08:12:04 pickett has joined
 253 2012-07-03 08:14:48 maaku has quit (Quit: maaku)
 254 2012-07-03 08:16:30 t7 has joined
 255 2012-07-03 08:23:01 pickett has quit (Ping timeout: 276 seconds)
 256 2012-07-03 08:25:26 MC1984 has quit (Ping timeout: 246 seconds)
 257 2012-07-03 08:26:21 MC1984 has joined
 258 2012-07-03 08:31:25 Marf has joined
 259 2012-07-03 08:41:49 <luke-jr> ;;bc,blocks
 260 2012-07-03 08:41:50 <gribble> 187310
 261 2012-07-03 08:50:20 JStoker has quit (Excess Flood)
 262 2012-07-03 08:52:26 PK has joined
 263 2012-07-03 08:57:48 JStoker has joined
 264 2012-07-03 08:59:35 ThomasV has quit (Read error: Operation timed out)
 265 2012-07-03 09:04:07 welterde has quit (Ping timeout: 264 seconds)
 266 2012-07-03 09:11:30 <t7> ;;bc;reward
 267 2012-07-03 09:11:30 <gribble> Error: "bc;reward" is not a valid command.
 268 2012-07-03 09:11:36 <t7> ;;bc,reward
 269 2012-07-03 09:11:36 <gribble> Error: "bc,reward" is not a valid command.
 270 2012-07-03 09:11:47 <sipa> ;;bc,gen
 271 2012-07-03 09:11:47 <gribble> (bc,gen <an alias, 1 argument>) -- Alias for "echo The expected generation output, at $1 Khps, given current difficulty of [bc,diff], is [math calc 50*24*60*60 / (1/((2**224-1)/[bc,diff]*$1*1000/2**256))] BTC per day and [math calc 50*60*60 / (1/((2**224-1)/[bc,diff]*$1*1000/2**256))] BTC per hour.".
 272 2012-07-03 09:35:53 apex-alt has joined
 273 2012-07-03 09:37:09 Apexseals has quit (Ping timeout: 248 seconds)
 274 2012-07-03 09:43:24 Apexseals has joined
 275 2012-07-03 09:44:29 datagutt has joined
 276 2012-07-03 09:44:29 datagutt has quit (Changing host)
 277 2012-07-03 09:44:29 datagutt has joined
 278 2012-07-03 09:44:52 apex-alt has quit (Ping timeout: 252 seconds)
 279 2012-07-03 09:50:05 drizztbsd has joined
 280 2012-07-03 09:53:17 Motest031 has quit (Ping timeout: 246 seconds)
 281 2012-07-03 09:56:08 Motest003 has joined
 282 2012-07-03 10:23:17 setkeh has quit (Quit: Love Linux ?? and Sharing Experiance ?? Come Join us on Freenode at #linuxdistrocommunity)
 283 2012-07-03 10:23:28 setkeh has joined
 284 2012-07-03 10:34:00 agricocb has quit (Quit: Leaving.)
 285 2012-07-03 10:39:06 leotreasure has joined
 286 2012-07-03 10:41:35 t7 has quit (Ping timeout: 246 seconds)
 287 2012-07-03 10:44:06 paul0 has quit (Quit: paul0)
 288 2012-07-03 10:48:25 drizztbsd has quit (Quit: Konversation terminated!)
 289 2012-07-03 10:48:32 t7 has joined
 290 2012-07-03 10:49:50 ThomasV has joined
 291 2012-07-03 10:57:20 drizztbsd has joined
 292 2012-07-03 10:57:49 imsaguy has quit (Read error: Connection reset by peer)
 293 2012-07-03 10:59:33 imsaguy has joined
 294 2012-07-03 10:59:46 hnz has quit (Ping timeout: 246 seconds)
 295 2012-07-03 11:00:09 hnz has joined
 296 2012-07-03 11:05:07 one_zero has quit ()
 297 2012-07-03 11:07:59 paraipan has joined
 298 2012-07-03 11:11:57 <Cubox> ;;bc,gen 40
 299 2012-07-03 11:11:58 <gribble> The expected generation output, at 40 Khps, given current difficulty of 1726566.5591935 , is 2.33023945756e-05 BTC per day and 9.70933107317e-07 BTC per hour.
 300 2012-07-03 11:12:10 <Cubox> xD
 301 2012-07-03 11:12:24 <sipa> mining on a raspberry pi?
 302 2012-07-03 11:14:42 <Cubox> mining on cpu only
 303 2012-07-03 11:15:22 agricocb has joined
 304 2012-07-03 11:15:38 <sipa> what cpu is that, and what program?
 305 2012-07-03 11:15:55 <jine> 40 *K*hash?
 306 2012-07-03 11:15:59 <sipa> you should be able to do a few Mhash/s on a desktop cpu
 307 2012-07-03 11:16:35 <Cubox> jine: y
 308 2012-07-03 11:16:38 ThomasV has quit (Ping timeout: 240 seconds)
 309 2012-07-03 11:16:44 <Cubox> sipa: i'm mining litecoin ...
 310 2012-07-03 11:16:47 <sipa> ah
 311 2012-07-03 11:17:11 <Cubox> and bbqcoins but it's an other story :P
 312 2012-07-03 11:19:36 <ersi> Hah, nice.. eh, anti-earning per day
 313 2012-07-03 11:20:01 <Cubox> ersi: o.O
 314 2012-07-03 11:20:24 <ersi> 2.33023945756e-05 BTC is actually a negative amount, if I'm not mistaken?
 315 2012-07-03 11:20:37 <Cubox> no
 316 2012-07-03 11:20:50 <Cubox> it's 2.3302^-5
 317 2012-07-03 11:20:59 <Cubox> or in python
 318 2012-07-03 11:21:06 <Cubox> 2.3302**-5
 319 2012-07-03 11:21:13 <ersi> shrug
 320 2012-07-03 11:21:17 <Cubox> look at the e-05
 321 2012-07-03 11:21:21 <ersi> I loath scientific notation
 322 2012-07-03 11:21:23 <Cubox> e = ^
 323 2012-07-03 11:21:26 <ersi> yeah
 324 2012-07-03 11:21:27 <Cubox> :
 325 2012-07-03 11:21:30 <Cubox> :)*
 326 2012-07-03 11:21:38 <sipa> Cubox: no
 327 2012-07-03 11:21:58 <sipa> it is 2.33 * 10^-5
 328 2012-07-03 11:22:04 <Cubox> hmm, right
 329 2012-07-03 11:27:11 da2ce7 has joined
 330 2012-07-03 11:31:31 paraipan has quit (Ping timeout: 276 seconds)
 331 2012-07-03 11:32:20 <zab_> math is hard and for nerds (TM - Barbie corp.)
 332 2012-07-03 11:36:23 paraipan has joined
 333 2012-07-03 11:37:44 TD has joined
 334 2012-07-03 11:40:39 da2ce7 has quit (Ping timeout: 255 seconds)
 335 2012-07-03 11:41:22 pickett has joined
 336 2012-07-03 11:47:04 <Cubox> hmm, where does bitcoin store his temp files ? If there are temp file put in an other place than .bitcoin
 337 2012-07-03 11:48:05 <sipa> temp files?
 338 2012-07-03 11:48:13 <Cubox> hmm
 339 2012-07-03 11:48:23 <sipa> everything is in ~/.bitcoin
 340 2012-07-03 11:48:33 <Cubox> yes, I saw that the client remember the last connections, and i deleted all the .bitcoin
 341 2012-07-03 11:48:48 <Cubox> idea, lsof on the process
 342 2012-07-03 11:49:17 <sipa> i just told you; it stores everything in ~/.bitcoin
 343 2012-07-03 11:50:06 <Cubox> hmm
 344 2012-07-03 11:50:45 <Cubox> because after changed the source code, and some other stuff the rpc tell me a 500 error and setgenerate true start threads but thet don't mine anything
 345 2012-07-03 11:51:03 ThomasV has joined
 346 2012-07-03 11:51:22 <sipa> if you changed the source, you're on your own :)
 347 2012-07-03 11:51:35 <Cubox> sipa: oh, i forgot, it's for a fork :)
 348 2012-07-03 11:51:54 setkeh has quit (Ping timeout: 255 seconds)
 349 2012-07-03 11:52:09 <Cubox> but bitcoin have remembered the last connection, after deleting the .bitcoin
 350 2012-07-03 11:52:29 <sipa> did you delete .bitcoin while it was running?
 351 2012-07-03 11:53:42 <Cubox> no
 352 2012-07-03 11:53:52 <sipa> in that case it cannot have remembered anything
 353 2012-07-03 11:54:00 <Cubox> Just keep the conf, deleted all other stuff
 354 2012-07-03 11:54:17 <sipa> why do you think it did?
 355 2012-07-03 11:55:35 <Cubox> sipa: i started it with -printtoconsole and i saw like "last seen -10h"
 356 2012-07-03 11:55:57 <sipa> yes, lastseen info propagates through the network
 357 2012-07-03 11:56:18 <sipa> and addresses retrieved from DNS seeds also get a random lastseen tag
 358 2012-07-03 11:57:16 <Cubox> trying connection 176.9.149.152:5233 lastseen=-0.8hrs
 359 2012-07-03 11:57:24 <Cubox> oh
 360 2012-07-03 11:57:26 <Cubox> okey
 361 2012-07-03 11:57:46 <sipa> peer ip addresses are stored in addr.dat in <=0.6.3
 362 2012-07-03 11:57:47 <Cubox> [2012-07-03 13:53:38] HTTP request failed: The requested URL returned error: 500
 363 2012-07-03 11:57:59 <Cubox> sipa: i deleted addr.dat too
 364 2012-07-03 12:04:25 pickett has quit (Remote host closed the connection)
 365 2012-07-03 12:06:27 setkeh has joined
 366 2012-07-03 12:09:17 _flow_ has quit (Ping timeout: 248 seconds)
 367 2012-07-03 12:09:54 apex-alt has joined
 368 2012-07-03 12:10:45 Apexseals has quit (Ping timeout: 265 seconds)
 369 2012-07-03 12:14:13 pickett has joined
 370 2012-07-03 12:16:59 _flow_ has joined
 371 2012-07-03 12:22:22 m0mchil has joined
 372 2012-07-03 12:27:09 iddo has joined
 373 2012-07-03 12:27:26 rdponticelli has joined
 374 2012-07-03 12:28:21 MC1984 has quit (Ping timeout: 248 seconds)
 375 2012-07-03 12:30:48 ThomasV has quit (Quit: Quitte)
 376 2012-07-03 12:36:35 pickett has quit (Remote host closed the connection)
 377 2012-07-03 12:36:46 welterde has joined
 378 2012-07-03 12:36:48 d4de has quit (Read error: Connection reset by peer)
 379 2012-07-03 12:36:59 minimoose has joined
 380 2012-07-03 12:43:59 PK has quit (Read error: Connection reset by peer)
 381 2012-07-03 12:45:22 <gribble> New news from bitcoinrss: Diapolo opened pull request 1552 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1552>
 382 2012-07-03 12:50:10 d4de has joined
 383 2012-07-03 12:51:54 pickett has joined
 384 2012-07-03 12:54:14 rdponticelli has quit (Ping timeout: 246 seconds)
 385 2012-07-03 12:58:06 RainbowDashh has joined
 386 2012-07-03 12:59:25 pickett has quit (Remote host closed the connection)
 387 2012-07-03 13:04:23 Karmaon has quit (Read error: Connection reset by peer)
 388 2012-07-03 13:04:45 Karmaon has joined
 389 2012-07-03 13:04:46 Karmaon has quit (Changing host)
 390 2012-07-03 13:04:46 Karmaon has joined
 391 2012-07-03 13:05:22 ThomasV has joined
 392 2012-07-03 13:11:44 pickett has joined
 393 2012-07-03 13:12:23 TD has quit (Quit: TD)
 394 2012-07-03 13:23:19 pickett has quit (Ping timeout: 276 seconds)
 395 2012-07-03 13:24:08 pickett has joined
 396 2012-07-03 13:33:15 pickett has quit (Remote host closed the connection)
 397 2012-07-03 13:36:22 ThomasV has quit (Quit: Quitte)
 398 2012-07-03 13:36:56 PK has joined
 399 2012-07-03 13:37:02 dvide has joined
 400 2012-07-03 13:38:37 pickett has joined
 401 2012-07-03 13:39:55 <abracadabra> meh
 402 2012-07-03 13:43:28 MC1984 has joined
 403 2012-07-03 13:45:16 X-Scale has quit (Ping timeout: 272 seconds)
 404 2012-07-03 13:46:04 pickett has quit (Ping timeout: 276 seconds)
 405 2012-07-03 13:46:31 X-Scale has joined
 406 2012-07-03 13:46:51 X-Scale is now known as Guest78616
 407 2012-07-03 13:48:24 Guest78616 is now known as X-Scale
 408 2012-07-03 13:49:50 <Cubox> Hi, I am trying to make a fork of litecoin, and after a lot of tries, my bitcoind don't want to mine. rpc request from minerd give an error 500 and setgenerate true start threads but don't use cpu ... What is wrong with my code ? I changed so much and spent so much time... https://github.com/Cubox-/BBQCoin/commits/master Thanks
 409 2012-07-03 13:54:23 <ersi> You might want to take your fork to the forum, instead of the chat. Most people here are pretty busy just with Bitcoin. And there's a lot of people on the forum that has been fippling around with forks and development as well.
 410 2012-07-03 13:54:31 <ersi> Just a friendly tip
 411 2012-07-03 13:54:46 tg has quit (Ping timeout: 272 seconds)
 412 2012-07-03 13:54:48 copumpkin has quit (Quit: Computer has gone to sleep.)
 413 2012-07-03 13:54:52 pickett has joined
 414 2012-07-03 13:55:13 <gmaxwell> Cubox: you need to be running two nodes to mine. You need to not be in initial download.
 415 2012-07-03 13:57:21 <Cubox> gmaxwell: we are 2 nodes mining
 416 2012-07-03 13:57:38 <Cubox> ersi: thanks, i'm not familiar with forums
 417 2012-07-03 13:57:40 <gmaxwell> Okay, you've exausted my quick advice, see ersi's comments.
 418 2012-07-03 13:58:52 <Cubox> gmaxwell: :/ Thanks
 419 2012-07-03 13:59:57 <Cubox> But yeah, will ask in the forum
 420 2012-07-03 14:00:41 <ersi> Cubox: The general rule when posting to a forum is, think through what you want to accomplish - make it as simple as possible to understand what it is you have done, and what you think might be wrong. It takes longer time, but you can get "better help" - since one usually takes more time to write on forums.
 421 2012-07-03 14:01:03 <Cubox> ersi: thanks :)
 422 2012-07-03 14:01:24 <ersi> there's mostly just "lightweight" conversations that happen on chats - since it's so simple to just type a sentense or a quick tip :)
 423 2012-07-03 14:01:34 <ersi> you're very welcome, especially if you read/listened to me :D
 424 2012-07-03 14:01:55 <Cubox> I always read/listen :)
 425 2012-07-03 14:02:24 <ersi> there's suprisingly a lot of people who don't, that's why I'm happy you do
 426 2012-07-03 14:02:47 tg has joined
 427 2012-07-03 14:09:04 rms78070 has joined
 428 2012-07-03 14:09:36 <rms78070> can anyone tell me how to get bitcoins?
 429 2012-07-03 14:10:01 <sipa> buy them?
 430 2012-07-03 14:10:06 <sipa> see #bitcoin
 431 2012-07-03 14:10:28 <ersi> Yeah, #bitcoin is the place for discussing that. This is where developers/programmers hang and talk other techy stuff
 432 2012-07-03 14:10:45 <rms78070> lol, i am new to them. I was wanting to use them on TOR, I have a hidden website link for currency rates but I am not sure if I trust the system
 433 2012-07-03 14:10:51 <rms78070> Oh I see, thank ersi
 434 2012-07-03 14:11:39 MiningBuddy- is now known as MiningBuddy
 435 2012-07-03 14:12:07 rms78070 has quit (Client Quit)
 436 2012-07-03 14:13:48 copumpkin has joined
 437 2012-07-03 14:17:53 cuqa has quit (Quit: Reconnecting)
 438 2012-07-03 14:19:29 <doublec> Cubox: try the alternate cryptocurrencies sub-forum
 439 2012-07-03 14:19:38 <doublec> Cubox: https://bitcointalk.org/index.php?board=67.0
 440 2012-07-03 14:19:43 <ersi> That's a very good suggestion ^
 441 2012-07-03 14:19:49 <doublec> Cubox: the litecoin dev hangs out there and could help
 442 2012-07-03 14:22:08 <doublec> Cubox: also look in your debug.log for errors. You'll probably find issues with your genesis block or checkpoints
 443 2012-07-03 14:23:06 <jgarzik> doublec: I think there's #litecoin-dev or similar
 444 2012-07-03 14:23:13 <jgarzik> Cubox: ^
 445 2012-07-03 14:24:01 MiningBuddy has quit (Ping timeout: 252 seconds)
 446 2012-07-03 14:24:19 PK has quit ()
 447 2012-07-03 14:24:55 <doublec> Cubox: you might want to work on your commit messages - one day you'll use them to track down bugs and wonder what "kill me" and  "What ?" meant :)
 448 2012-07-03 14:36:27 <Cubox> doublec: omg
 449 2012-07-03 14:36:31 <Cubox> checkpoints
 450 2012-07-03 14:36:42 <Cubox> doublec: will check this
 451 2012-07-03 14:36:56 RainbowDashh has quit (Quit: SLEEP MODE.  [NSFW!]  [WIERD] [WTF] http://pastebin.com/6L0WjKRk)
 452 2012-07-03 14:36:57 Lolcust has joined
 453 2012-07-03 14:37:05 Joric has joined
 454 2012-07-03 14:37:26 <Cubox> jgarzik: they don't answer :) and bitcoin is the base
 455 2012-07-03 14:37:40 <Cubox> jgarzik: so, i'm telling that i'm forking bitcoin, because it's more known
 456 2012-07-03 14:38:13 <sipa> and what are you trying to accomplice?
 457 2012-07-03 14:38:38 <Cubox> sipa: mine a block :)
 458 2012-07-03 14:38:40 malaimo has quit (Ping timeout: 244 seconds)
 459 2012-07-03 14:46:19 malaimo has joined
 460 2012-07-03 14:48:18 rdponticelli has joined
 461 2012-07-03 14:54:54 m00p has joined
 462 2012-07-03 14:57:26 guruvan_ has quit (Remote host closed the connection)
 463 2012-07-03 14:58:41 guruvan_ has joined
 464 2012-07-03 15:00:12 wtfman[away] has quit (Ping timeout: 252 seconds)
 465 2012-07-03 15:02:07 devrandom has quit (Ping timeout: 276 seconds)
 466 2012-07-03 15:02:47 devrandom has joined
 467 2012-07-03 15:05:17 wtfman[away] has joined
 468 2012-07-03 15:06:41 MC1984 has quit (Ping timeout: 265 seconds)
 469 2012-07-03 15:08:06 <doublec> Cubox: make sure you're using a litecoin miner and not a bitcoin miner
 470 2012-07-03 15:08:19 <doublec> Cubox: if you're basing on litecoin - they use different mining algorithms
 471 2012-07-03 15:08:25 <Cubox> doublec: ofc, i use the intern litecoin miner
 472 2012-07-03 15:08:28 <Cubox> setgenerate true :)
 473 2012-07-03 15:08:34 <doublec> yeah, just thought I'd check
 474 2012-07-03 15:08:38 <Cubox> doublec: i know, sha256 ans scrupt :)
 475 2012-07-03 15:08:42 <Cubox> scrypt*
 476 2012-07-03 15:08:59 <doublec> saying its based on bitcoin though and then "setgenerate true" confuses people since bitcoin doesn't support setgenerate
 477 2012-07-03 15:09:12 <doublec> so best to stick with "based on litecoin"
 478 2012-07-03 15:09:13 <Cubox> oh
 479 2012-07-03 15:09:42 <Cubox> doublec: but i founded the issue, it was checkpoints
 480 2012-07-03 15:09:48 <doublec> ok, cool
 481 2012-07-03 15:10:04 <sipa> doublec: sure bitcoin supports setgenerate?
 482 2012-07-03 15:10:12 <sipa> it's not useful for anything but testing though
 483 2012-07-03 15:10:31 <doublec> sipa: I thought it was removed? Sorry for giving bad info!
 484 2012-07-03 15:10:42 <sipa> doublec: it was removed from the GUI a long time ago
 485 2012-07-03 15:10:50 <doublec> ah, that's what I was thinking of
 486 2012-07-03 15:10:54 <sipa> and the optimized assembly implementations have been removed as well
 487 2012-07-03 15:11:02 <sipa> but there's still reference mining code
 488 2012-07-03 15:29:32 MiningBuddy has joined
 489 2012-07-03 15:31:03 Marf has quit (Ping timeout: 246 seconds)
 490 2012-07-03 15:38:28 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1553 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1553>
 491 2012-07-03 15:38:53 <Cubox> Whyyyyyyyy, the hashmerkleroot is not the good one :(
 492 2012-07-03 15:41:06 <helo> for fun, and to learn a little, i'm thinking about writing a bitcoin network visualization tool
 493 2012-07-03 15:41:58 <helo> to show competing chains, visualize reorgs, compare nodes
 494 2012-07-03 15:42:40 <helo> show a representation of transactions as they are received, and show them being integrated into new blocks
 495 2012-07-03 15:43:36 <Joric> helo, btclook.com had cool charts won't open now
 496 2012-07-03 15:43:46 <helo> i was hoping to get 1) confirmation that this isn't a complete waste of time, and 2) other feature ideas
 497 2012-07-03 15:44:20 <Joric> there was a realtime svg visualization with arrows and verlet physics
 498 2012-07-03 15:44:21 Maccer is now known as MaccerBNC
 499 2012-07-03 15:46:19 m00p has quit (Ping timeout: 265 seconds)
 500 2012-07-03 15:46:40 <helo> hopefully something like that ^
 501 2012-07-03 15:47:21 <Joric> SVG. Generated by d3.js
 502 2012-07-03 15:48:05 <Joric> something like that http://mbostock.github.com/d3/ex/force.html
 503 2012-07-03 15:48:56 <Joric> or that http://mbostock.github.com/d3/talk/20111116/force-collapsible.html
 504 2012-07-03 15:50:37 m0mchil has quit ()
 505 2012-07-03 15:51:03 <Cubox> ersi: can i ask for your help again ?
 506 2012-07-03 15:51:04 <helo> i'm not a big fan of web development, so i was going to make a standalone client... although it would see a lot more use if it was a website
 507 2012-07-03 15:51:18 <Cubox> ersi: I don't find the "create a topic" button on the forum :(
 508 2012-07-03 15:51:46 <helo> are there any python libraries that can do node discovery, and receive transactions, process blocks, etc?
 509 2012-07-03 15:53:17 <helo> if i could use python to do the backend, it would offset the pain of web development :)
 510 2012-07-03 15:53:25 <Joric> helo, i was trying to write an universal blockchain parser on python https://github.com/joric/pyblockchain
 511 2012-07-03 15:54:02 <helo> Socket?
 512 2012-07-03 15:54:18 <Joric> just parses blockchain
 513 2012-07-03 15:54:41 <Joric> there's a semi-functional pure-python client https://github.com/samrushing/caesure
 514 2012-07-03 15:55:14 <helo> ahh cool
 515 2012-07-03 15:55:42 <sipa> Cubox: are you new on the forum? in that case you're restricted to some boards
 516 2012-07-03 15:56:48 <Cubox> sipa: oh
 517 2012-07-03 15:57:20 <Cubox> sipa: how can i do for get this restriction out ?
 518 2012-07-03 15:58:03 t7 has quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0/20120624012213])
 519 2012-07-03 15:58:24 mmoya has joined
 520 2012-07-03 16:00:00 <gavinandresen> gmaxwell: you available to brainstorm on transaction fees? Or anybody else around interested?
 521 2012-07-03 16:03:29 jeremias has quit (Read error: Operation timed out)
 522 2012-07-03 16:03:36 jeremias has joined
 523 2012-07-03 16:03:53 <helo> ahh... caesure looks like a decent starting point
 524 2012-07-03 16:04:32 <sipa> gavinandresen: gtg soon
 525 2012-07-03 16:04:40 <luke-jr> I'm here
 526 2012-07-03 16:04:54 <gavinandresen> sipa: ok
 527 2012-07-03 16:05:02 <luke-jr> gavinandresen: did check txn_prio yet?
 528 2012-07-03 16:06:09 <gavinandresen> luke-jr: yes, I looked at it.  Haven't convinced myself your code is correct, and I'm thinking more of higher-level "how should fees work" stuff
 529 2012-07-03 16:06:15 <luke-jr> ah
 530 2012-07-03 16:06:22 <luke-jr> I know that code is probably far from ideal
 531 2012-07-03 16:06:45 <luke-jr> I'm just not sure how to do it better, but if someone wants to rewrite it, go for it ;)
 532 2012-07-03 16:06:52 <gavinandresen> In particular, right now I'm trying to come up with a way of getting rid of ALL of the magical constants we have surrounding fees
 533 2012-07-03 16:07:57 <sipa> gavinandresen: i doubt that is possible
 534 2012-07-03 16:08:02 <gavinandresen> luke-jr: in general, do you like the direction of https://gist.github.com/2961409  ?   Letting miners specify "this is the size blocks I'll create and this is how many fees I'm willing to forgo"
 535 2012-07-03 16:08:45 <gavinandresen> sipa: I'm thinking that choosing defaults based on recent blockchain history could work nicely.
 536 2012-07-03 16:09:19 <jgarzik> gavinandresen: I find there is a relationship between a useful dust spam fee, and real world price
 537 2012-07-03 16:09:21 <gavinandresen> sipa: yesterday I dug out some statistics from a sample of 45 recent blocks:  https://docs.google.com/spreadsheet/ccc?key=0Ar4FtkFP4j73dGpCRnlucHVuSXl3VjhsTk5XaTBIV3c
 538 2012-07-03 16:09:27 <jgarzik> gavinandresen: it is difficult to find a feedback mechanism that echoes that
 539 2012-07-03 16:09:38 <luke-jr> gavinandresen: can't hurt - probably want a minimum on block size though
 540 2012-07-03 16:10:24 <gavinandresen> luke-jr: blocks get filled with highest-pending-priority transactions (that are above a priority minimum cutoff, so spammers can't just fill the empty space for free)
 541 2012-07-03 16:11:20 <sipa> gavinandresen: the priority rule based on size/age is one that stems from the "fees to prevent spam" idea
 542 2012-07-03 16:12:09 <jgarzik> yes
 543 2012-07-03 16:12:19 <gavinandresen> sipa: yes, I know (Satoshi was very excited when I suggested computing priority that way)
 544 2012-07-03 16:12:31 <sipa> i prefer priorities based on network cost, and keep the spam prevention separate
 545 2012-07-03 16:12:44 <gavinandresen> what do you mean by network cost?
 546 2012-07-03 16:13:04 <sipa> size, number of outputs created and spent, ...
 547 2012-07-03 16:13:40 <BlueMatt> do many of those criteria not intersec with anti-spam?
 548 2012-07-03 16:13:49 <gavinandresen> "size" is meant to be a rough estimate of all of that, and with the 'standard' transactions we have now, is a pretty good measure.
 549 2012-07-03 16:14:28 <sipa> a transaction that consumes 100 coins and creates 1 has a very positive effect for the network
 550 2012-07-03 16:14:36 <sipa> in the long term
 551 2012-07-03 16:14:56 <sipa> while the opposite is terrible
 552 2012-07-03 16:14:59 <gavinandresen> I'm not against multiplying priority by ratio of outputs/inputs
 553 2012-07-03 16:15:31 <gavinandresen> (err, the inverse of that I mean)
 554 2012-07-03 16:16:02 <sipa> if you reason from the viewpoint of network cost, it'd have to be A*size + B*(txouts - txins)
 555 2012-07-03 16:16:15 <sipa> for some very hard to estimate constants A and B
 556 2012-07-03 16:16:48 <jgarzik> don't forget age
 557 2012-07-03 16:17:00 <BlueMatt> where txouts/txins also takes into account size and num sigops
 558 2012-07-03 16:17:15 <sipa> account size?
 559 2012-07-03 16:17:15 <BlueMatt> ehh...no txins doesnt care about size, txouts do
 560 2012-07-03 16:17:25 <luke-jr> sipa: txn_prio has miner-configurable constants for "fee weight" and "age weight", so adding "size weight" and "pruning weight" would be easy IMO
 561 2012-07-03 16:17:37 <BlueMatt> txout size, have to count it from the point of view of network transmission and storage costs
 562 2012-07-03 16:18:06 <BlueMatt> ie big txout is worse than big tx in general
 563 2012-07-03 16:18:07 <sipa> jgarzik: do you think age plays a large role for long-term cost?
 564 2012-07-03 16:18:13 <sipa> BlueMatt: indeed
 565 2012-07-03 16:18:30 <gavinandresen> I think priority would be =  sum(input_value_in_base_units * age) * B*(inputs/outputs) / (A*size)
 566 2012-07-03 16:18:32 <jgarzik> sipa: slows velocity
 567 2012-07-03 16:18:32 <luke-jr> sipa: age is important so spammers can't just keep flipping the same coin in and out
 568 2012-07-03 16:18:56 <gavinandresen> ... and I'd suggest A and B are both 1.0
 569 2012-07-03 16:18:57 <kinlo> I think age should increase the chance of being included, so if you include a very low or no fee, it will get mined eventually, just not very soon
 570 2012-07-03 16:18:58 <sipa> luke-jr: yes, but imho spam prevention is a separate concern that needs separate rules
 571 2012-07-03 16:19:02 <jgarzik> sipa: which hopefully slows block chain growth, or at least requires high producers to pay fees
 572 2012-07-03 16:19:36 <gavinandresen> spam prevention is all about priority, which IS separate from fees.
 573 2012-07-03 16:19:40 <luke-jr> gavinandresen: adding the input/output ratio might be tricky with dependency trees
 574 2012-07-03 16:20:05 <sipa> afaict, A*size + B*(txout size - consumed txout size) + C*sigops
 575 2012-07-03 16:20:05 <gavinandresen> luke-jr: shouldn't be, a dependency tree has X inputs and Y outputs total....
 576 2012-07-03 16:20:23 <sipa> is the most accurate representation of network cost
 577 2012-07-03 16:20:26 <jgarzik> gavinandresen: to an extent, yes.  but if you want to get around spam prevention, you must pay a fee.  but what fee is right for spam?  </rhetorical>
 578 2012-07-03 16:20:34 <luke-jr> gavinandresen: yes, but you need to walk the tree to figure out the effective inputs
 579 2012-07-03 16:21:04 <jgarzik> "spam prevention" is another way to rephrase "we find this behavior annoying enough to require additional fees"
 580 2012-07-03 16:21:07 <jgarzik> nothing more
 581 2012-07-03 16:21:07 <sipa> luke-jr: i hope to make that operation cheap
 582 2012-07-03 16:21:55 <BlueMatt> sipa: I dont see we cant punish the priority of spammy txes, spam prevention may need more than that in terms of relay stuff as priority would be used only by miners to include txes out of the goodness of their hearts...
 583 2012-07-03 16:21:59 <jgarzik> on the flip side, we want to _positively_ incentivize old age
 584 2012-07-03 16:22:03 <jgarzik> it's not just spam prevention
 585 2012-07-03 16:22:03 <BlueMatt> and if you are doing that, why include spammy txes
 586 2012-07-03 16:22:11 <jgarzik> you can prune some old transactions
 587 2012-07-03 16:22:23 <jgarzik> keep longtime users invested
 588 2012-07-03 16:22:31 <sipa> that's why txout size is more important than tx size
 589 2012-07-03 16:23:40 <gavinandresen> Automatically choosing a fee/priority floor for clients to decide "this really looks like spam, I'm not going to relay it" is one of the things I want to brainstorm
 590 2012-07-03 16:24:10 <gavinandresen> I'd like to put aside how, exactly, priority is calculated.  The way we're doing it now seems to work well enough, it can be improved later.
 591 2012-07-03 16:24:12 <jgarzik> we definitely want to encourage txout reduction
 592 2012-07-03 16:24:29 danbri has quit (Remote host closed the connection)
 593 2012-07-03 16:24:42 rdponticelli_ has joined
 594 2012-07-03 16:25:06 <BlueMatt> gavinandresen: As a client, I dont care what the fee of a tx is, I want to relay things with high prio whether or not they have a fee, though thats bad policy
 595 2012-07-03 16:25:18 rdponticelli has quit (Ping timeout: 246 seconds)
 596 2012-07-03 16:25:29 <BlueMatt> gavinandresen: so, my suggestion would be prio per fee floor
 597 2012-07-03 16:26:12 <gavinandresen> BlueMatt: I was thinking it would be "either fee/kb above a fee floor, OR priority above a priority floor."
 598 2012-07-03 16:26:37 <gavinandresen> ... because priority=0 but-carries-a-reasonable-fee transactions will probably be common
 599 2012-07-03 16:26:41 <jgarzik> from a higher level... shouldn't we prioritize fiddling with fees below the bitcoin user experience (picking a good fee)?  Picking-A-Good-Fee code would be equally applicable to any existing or new fee/prioritization structure.
 600 2012-07-03 16:27:00 <jgarzik> that has been a bitcoin Big Problem from day one.
 601 2012-07-03 16:27:16 <gavinandresen> jgarzik: I'm not following
 602 2012-07-03 16:27:34 <BlueMatt> gavinandresen: not sure about fee/kb, maybe "fee/prio or prio"
 603 2012-07-03 16:27:37 <gavinandresen> jgarzik: do you mean code to automatically figure out what A Reasonable Fee is?
 604 2012-07-03 16:27:53 <gavinandresen> (where Reasonable means "likely to get into the next block")
 605 2012-07-03 16:28:03 <jgarzik> gavinandresen: yes
 606 2012-07-03 16:28:09 <BlueMatt> eh s|fee/prio|fee*prio|
 607 2012-07-03 16:28:16 Zarutian has joined
 608 2012-07-03 16:28:35 <gavinandresen> jgarzik: ACK on that, I agree that is important.  But it is tied into figuring out fee/priority floors
 609 2012-07-03 16:28:39 <jgarzik> A bitcoin user largely guesses at fees today (or lets the client guess, based on precompiled constants).
 610 2012-07-03 16:28:44 <luke-jr> jgarzik: gmaxwell had a good idea for that: watch the txns that *don't* get confirmed
 611 2012-07-03 16:28:50 <jgarzik> If they guess wrong,their transaction is in limbo and cannot be cancelled.
 612 2012-07-03 16:29:00 <BlueMatt> jgarzik: absolutely
 613 2012-07-03 16:29:14 <gavinandresen> jgarzik: exactly, I'm trying to brainstorm how to get rid of the compiled-in guesses.
 614 2012-07-03 16:29:17 danbri has joined
 615 2012-07-03 16:29:46 <gavinandresen> It looks like looking at average fee/kb of the last 50 or 100 blocks gives a reasonable number
 616 2012-07-03 16:30:03 <jgarzik> gavinandresen: compiled-in guesses will remain in the field, though.  IMO the code should -- as some current research already speculates -- inform its fee decision based on looking at the last X blocks, looking into TX mempool, etc., etc.
 617 2012-07-03 16:30:20 <jgarzik> dynamic observation
 618 2012-07-03 16:30:25 <BlueMatt> Id really like to give spv clients a good way to get fee info in a decentralized manner, though thats probably an unreasonable desire
 619 2012-07-03 16:30:46 <jgarzik> BlueMatt: it's a very reasonable desire -- we must plan for that, for the future
 620 2012-07-03 16:31:03 <jgarzik> BlueMatt: when SPV clients are the majority... how to do that?
 621 2012-07-03 16:31:13 <BlueMatt> gavinandresen: either fee/kb of last 50 blocks that we had already seen in mempool, or look at avg fee/kb of txes that didnt get confirmed
 622 2012-07-03 16:31:22 <BlueMatt> (to avoid miner stuffing their own high-fee txes)
 623 2012-07-03 16:31:56 <BlueMatt> jgarzik: the issue is you dont have any knowledge of tx fees paid by any txes that weren't yours...
 624 2012-07-03 16:32:11 <jgarzik> BlueMatt: ...without downloading full blocks anyway
 625 2012-07-03 16:32:17 <BlueMatt> jgarzik: yea
 626 2012-07-03 16:32:26 <BlueMatt> jgarzik: so...the reasonable solution is probably to just let them get fee info from trusted 3rd-parties that run full nodes... :(
 627 2012-07-03 16:32:38 <Eliel_> unless there's some data for it that can be verified through blockchain.
 628 2012-07-03 16:33:01 <gavinandresen> blockchain is controlled by miners, that have an incentive to make fees higher if they can
 629 2012-07-03 16:33:17 ovidiusoft has quit (Ping timeout: 246 seconds)
 630 2012-07-03 16:33:20 <BlueMatt> gavinandresen: yep, thats why gmaxwell suggested looking at unconfirmed txes
 631 2012-07-03 16:33:24 <luke-jr> gavinandresen: that can do so regardless of lying
 632 2012-07-03 16:34:21 <luke-jr> what's the practical difference between lying about "I require 0.01 BTC per KB" and actually requiring it?
 633 2012-07-03 16:34:23 <gavinandresen> luke-jr: sure, every miner could just take the 32 highest-paying transactions and put them in their blocks and kill Bitcoin....
 634 2012-07-03 16:34:30 <jgarzik> gavinandresen: honestly that is one of my worries.  I think they have an incentive to raise fees to the point just before they chase away a majority of bitcoin users.
 635 2012-07-03 16:34:38 <gavinandresen> ... but there's an incentive for miners to take all fee-paying transactions...
 636 2012-07-03 16:35:08 <BlueMatt> gavinandresen: yea, I dont think miners will just only accept the highest-paying ones or they will lose all the fees
 637 2012-07-03 16:35:09 <gavinandresen> (assuming it costs them less to include them than the fees)
 638 2012-07-03 16:35:18 <BlueMatt> and then some smaller miner will pick it up and send the average back down anyway...
 639 2012-07-03 16:35:19 <jgarzik> in a T+10 year future, I always assumed that fees would simply be a requirement
 640 2012-07-03 16:35:54 <jgarzik> and that fees might be so high that it incentivizes off-network transactions, only occasionally publishing on the official blockchain network
 641 2012-07-03 16:36:10 <sipa> 10 years in the future, i hope we have payment protocols that allow transactions that are sent to merchants directly, who pay miners to get their transactions included
 642 2012-07-03 16:36:24 <jgarzik> i.e. a payment house flushes transactions to the blockchain on a nightly basis, paying requisite fees
 643 2012-07-03 16:36:35 <jgarzik> sipa: yep
 644 2012-07-03 16:36:44 * luke-jr notes Eligius already supports merchants footing the txn fees
 645 2012-07-03 16:36:55 <phantomcircuit> sipa, shh you'll ruin my business model
 646 2012-07-03 16:37:05 * phantomcircuit evil laughs
 647 2012-07-03 16:37:07 <BlueMatt> yes, but users should still be able to send their own txes via p2p without using a payment protocol to send to a non-trusted individual across the globe
 648 2012-07-03 16:37:12 <sipa> and no light client would need to know anything about fees or mining
 649 2012-07-03 16:37:12 <jgarzik> TD's suggestion of transaction chains covered by one fee is nice, and seems to have consensus
 650 2012-07-03 16:37:19 <jgarzik> indeed
 651 2012-07-03 16:37:30 <sipa> BlueMatt: sure
 652 2012-07-03 16:37:34 PK has joined
 653 2012-07-03 16:37:42 <luke-jr> jgarzik: that's what my txn_prio branch does
 654 2012-07-03 16:37:58 <gavinandresen> so.... coblee's micro-transaction pull and thinking about bootstrapping from a blockchain like litecoin has me thinking about fees and blocksizes and priorities, and wishing I'd taken some engineering classes about control theory
 655 2012-07-03 16:38:01 <BlueMatt> so discussing the T+10 year future of merchants putting txes into blocks through big mining companies I find irrelevant...
 656 2012-07-03 16:38:15 <BlueMatt> yes, it should happen but its not really a part of fee discussions now?
 657 2012-07-03 16:38:15 <jgarzik> so the block chain would be a merchant network w/ high fees, plus the odd duck willing to pay high fees to directly publish
 658 2012-07-03 16:38:25 <sipa> BlueMatt: exactly
 659 2012-07-03 16:38:53 danbri_ has joined
 660 2012-07-03 16:39:02 * sipa gone
 661 2012-07-03 16:39:09 <jgarzik> well -- as gavinandresen pointed out, looking at dynamic inputs does have consequences
 662 2012-07-03 16:39:29 <jgarzik> I imagine any fee structure major-rewrite will have years-long consequences
 663 2012-07-03 16:39:37 danbri__ has joined
 664 2012-07-03 16:39:48 <gavinandresen> yes, that's why I'd like to get it right the first time
 665 2012-07-03 16:40:18 <phantomcircuit> lol terrible coffee
 666 2012-07-03 16:40:21 Prattler has quit (Ping timeout: 246 seconds)
 667 2012-07-03 16:41:05 <BlueMatt> jgarzik: ofc it does, but when you look at txes that you have seen that dont get confirmed, you are looking at statistics of txes which are what you are about to do - submit to mempools of miners
 668 2012-07-03 16:41:24 <BlueMatt> jgarzik: so even if the market shifts hugely so that getting into a block requires huge fees, it will still apply
 669 2012-07-03 16:41:25 <gavinandresen> so if I were to go back in time to when Bitcoin was handling just a few transactions per block, can we come up with automatic policies that make transactions confirm reasonably quickly but also prevent spam?
 670 2012-07-03 16:41:28 <BlueMatt> even if it does take huge fee
 671 2012-07-03 16:41:29 <BlueMatt> s
 672 2012-07-03 16:42:25 <gavinandresen> I'm thinking that if miners artificially limited the size of the blocks they created, and then included only the highest-fee or highest-priority transactions, that might work nicely.
 673 2012-07-03 16:42:35 <jgarzik> AFAICT we exist today on the tacit miner agreement that fee enforcement would strangle bitcoin usage in its infancy.
 674 2012-07-03 16:42:40 danbri has quit (Ping timeout: 244 seconds)
 675 2012-07-03 16:43:16 <jgarzik> the bitcoin client with its policies of non-relaying is the only powerful counterbalance
 676 2012-07-03 16:43:34 <BlueMatt> gavinandresen: then a p2pool miner doesnt limit their blocks and gets a ton of fees?
 677 2012-07-03 16:43:42 danbri_ has quit (Ping timeout: 244 seconds)
 678 2012-07-03 16:44:03 <gavinandresen> BlueMatt: not a ton, no, I don't imagine any miner would forgo tons of fees to limit their blocksize.
 679 2012-07-03 16:44:29 D34TH has joined
 680 2012-07-03 16:44:30 D34TH has quit (Changing host)
 681 2012-07-03 16:44:30 D34TH has joined
 682 2012-07-03 16:44:39 <BlueMatt> oh, you mean today/as long as you couldn't fill a block with your entire mempool...
 683 2012-07-03 16:44:46 igetgames_ has joined
 684 2012-07-03 16:44:48 <jgarzik> thankfully block size is hard fork limited at present
 685 2012-07-03 16:45:17 <gavinandresen> Average block size is still pretty small (50K or so in my sample)
 686 2012-07-03 16:46:42 <BlueMatt> gavinandresen: yes, I think relying on miners to limit low-prio+low-fee txes is reasonable
 687 2012-07-03 16:47:03 igetgames has quit (Ping timeout: 250 seconds)
 688 2012-07-03 16:47:14 <BlueMatt> not sure about artificially limiting block size, but given a "forgo up to n fees to prevent chain spam" seems like a reasonable setting
 689 2012-07-03 16:47:54 <jgarzik> BlueMatt: seems like a setting that people would read and immediately set to zero
 690 2012-07-03 16:48:13 <BlueMatt> jgarzik: was just thinking that...but it could be framed better...
 691 2012-07-03 16:49:19 igetgames_ is now known as igetgames
 692 2012-07-03 16:49:19 <BlueMatt> jgarzik: also, if every node on the network already limits relay of eg "fee*prio < X && prio < Y" it could further help
 693 2012-07-03 16:49:40 <gavinandresen> We could take away that knob, if we can figure out a reasonable default (make miners jump through the little hoop of recompiling, with a big comment on WHY we don't give people the knob in the first place)
 694 2012-07-03 16:50:31 <phantomcircuit> gavinandresen, in british english that sentence is hilarious
 695 2012-07-03 16:50:34 <BlueMatt> or put the "fee*prio < X && prio < Y" a mempool limit and take away the knobs for X and Y
 696 2012-07-03 16:50:42 <gavinandresen> Straw-man reasonable default:   be willing to forgo 5% of the average fees in the last 100 blocks.
 697 2012-07-03 16:51:09 <BlueMatt> given that average users arent gonna care about it, Id think thats perfectly reasonable
 698 2012-07-03 16:51:25 <gavinandresen> phantomcircuit: does pulling your knob mean something different in british english?
 699 2012-07-03 16:51:32 <phantomcircuit> yes it does
 700 2012-07-03 16:51:47 <phantomcircuit> something dirty
 701 2012-07-03 16:51:57 <gavinandresen> I'm shocked!
 702 2012-07-03 16:52:01 <phantomcircuit> :)
 703 2012-07-03 16:52:14 <BlueMatt> gavinandresen: its listed at a DoS limit in the code anyway
 704 2012-07-03 16:52:56 <jgarzik> Still think the PR is terrible.  Let them figure out the math itself.  Just come up with a good definition of spam, what the client won't relay (and obviously, not CreateNewBlock for, either).  If a miner wants to disable anti-spam, they can disable the anti-spam code...
 705 2012-07-03 16:53:18 <BlueMatt> "them"?
 706 2012-07-03 16:53:30 <jgarzik> miners
 707 2012-07-03 16:53:34 <gavinandresen> jgarzik: good point
 708 2012-07-03 16:54:30 <BlueMatt> jgarzik: are you saying forgoing N fees to avoid spam is bad pr?
 709 2012-07-03 16:54:38 <jgarzik> BlueMatt: yes
 710 2012-07-03 16:54:45 <gavinandresen> jgarzik: so it would be "Fill up the block with as many non-spammy fee-paying transactions as possible, starting with the ones that pay the highest fee/kb.  Then, if there's room, take transactions by priority."
 711 2012-07-03 16:54:58 <jgarzik> gavinandresen: ack
 712 2012-07-03 16:55:05 <gavinandresen> and just drop spammy transactions entirely, they never enter the mempool
 713 2012-07-03 16:55:12 <jgarzik> ack
 714 2012-07-03 16:55:18 <BlueMatt> jgarzik: dunno, if you forgo N fees, yea probably, but if its written as DOS in mempool...
 715 2012-07-03 16:55:23 <BlueMatt> yea
 716 2012-07-03 16:55:52 <gavinandresen> give miners a great big knob (everybody wants a big knob) for how much space to give high-priority "free" transactions ?
 717 2012-07-03 16:56:00 <BlueMatt> ack
 718 2012-07-03 16:56:05 <jgarzik> BlueMatt: But having the dev team talk about "forgoing N fees" isn't the best messaging.  That's largely in the economic realm, while we are trying to solve technical not economic problems.
 719 2012-07-03 16:56:10 <jgarzik> gavinandresen: ack
 720 2012-07-03 16:56:38 <gavinandresen> Again, I wonder if we can figure out what "high priority" and "spammy" means automatically
 721 2012-07-03 16:56:39 * phantomcircuit snickers @ gavinandresen 
 722 2012-07-03 16:56:41 <BlueMatt> jgarzik: yea, <BlueMatt> or put the "fee*prio < X && prio < Y" a mempool limit and take away the knobs for X and Y
 723 2012-07-03 16:56:56 <phantomcircuit> gavinandresen, s/knob/tunable/
 724 2012-07-03 16:57:04 <phantomcircuit> tuneable*
 725 2012-07-03 16:57:36 <BlueMatt> gavinandresen: high prio is just "sorted by prio" according to something like sipa's suggestion
 726 2012-07-03 16:57:47 <BlueMatt> gavinandresen: spammy is the only one we really have to figure out
 727 2012-07-03 16:57:50 <gavinandresen> I mean, "above the priority cut-off"
 728 2012-07-03 16:58:13 <jgarzik> BlueMatt: ack
 729 2012-07-03 16:58:21 <jgarzik> lunchtime
 730 2012-07-03 16:58:26 * BlueMatt dinner
 731 2012-07-03 16:58:41 <gavinandresen> swimming with the kids
 732 2012-07-03 16:58:55 <BlueMatt> later Im gonna write up what I think is a solution
 733 2012-07-03 16:59:05 <BlueMatt> or someone else can
 734 2012-07-03 16:59:07 <BlueMatt> whatever...dinner
 735 2012-07-03 16:59:07 <gavinandresen> thanks for the brainstorm...
 736 2012-07-03 16:59:30 <gavinandresen> BlueMatt: go for it, I'm going to keep thinking....
 737 2012-07-03 17:09:00 <xorgate> i just sent some coins to a friend using standard client. why is a second output generated? http://blockchain.info/address/12J8rGZ2eQW5AEEZruJ6ZEv3RLDiGagUE8
 738 2012-07-03 17:09:41 <forrestv> xorgate, it's change left over from the input
 739 2012-07-03 17:10:50 <xorgate> sure but there's plenty of txs that don't do this
 740 2012-07-03 17:12:05 gavinandresen has quit (Quit: gavinandresen)
 741 2012-07-03 17:12:13 <xorgate> or maybe i'm missing something
 742 2012-07-03 17:13:29 <Joric> xorgate, if you send less than a full balance you get change (mostly on another address)
 743 2012-07-03 17:14:22 <Joric> transactions work this way, you cant just send a fraction
 744 2012-07-03 17:15:19 <xorgate> so my wallet now has this new address as well? i fear my knowledge of btc is not what i thought it was
 745 2012-07-03 17:17:36 <Joric> yep every send creates a new address for change
 746 2012-07-03 17:20:30 PK has quit ()
 747 2012-07-03 17:21:23 osmosis has joined
 748 2012-07-03 17:25:00 khalahan has quit (Quit: Bye)
 749 2012-07-03 17:25:28 t7 has joined
 750 2012-07-03 17:27:43 Elio19 has quit (Quit: Leaving)
 751 2012-07-03 17:29:21 paul0 has joined
 752 2012-07-03 17:31:56 <BlueMatt> gavinandresen: I meant as a "here is a current semi-consensus and summary of ideas that have resulted from the brainstorming" to continue to work from
 753 2012-07-03 17:39:55 minimoose has quit (Quit: minimoose)
 754 2012-07-03 17:40:25 setkeh has quit (Read error: Connection reset by peer)
 755 2012-07-03 17:40:41 setkeh has joined
 756 2012-07-03 17:43:58 drizztbsd has quit (Remote host closed the connection)
 757 2012-07-03 17:49:12 khalahan has joined
 758 2012-07-03 17:49:43 Joric has quit (Ping timeout: 264 seconds)
 759 2012-07-03 17:58:17 MobiusL has quit (Quit: Ex-Chat)
 760 2012-07-03 18:09:10 MobiusL has joined
 761 2012-07-03 18:10:53 mmoya has quit (Ping timeout: 248 seconds)
 762 2012-07-03 18:13:49 leotreasure has quit (Quit: leotreasure)
 763 2012-07-03 18:18:56 sirk390 has joined
 764 2012-07-03 18:20:26 bitllc has quit (Remote host closed the connection)
 765 2012-07-03 18:24:39 t7 has quit (Ping timeout: 246 seconds)
 766 2012-07-03 18:33:41 t7 has joined
 767 2012-07-03 18:39:59 Diablo-D3 has quit (Ping timeout: 244 seconds)
 768 2012-07-03 18:41:32 rdponticelli has joined
 769 2012-07-03 18:42:09 rdponticelli_ has quit (Ping timeout: 246 seconds)
 770 2012-07-03 18:45:46 TD has joined
 771 2012-07-03 18:53:30 <BlueMatt> https://gist.github.com/3041216
 772 2012-07-03 18:53:50 <BlueMatt> my combination of other people's ideas on fee policy ^
 773 2012-07-03 18:53:53 sgornick has joined
 774 2012-07-03 18:56:01 darkee is now known as !~darkee@gateway/tor-sasl/darkee|darkee
 775 2012-07-03 18:58:29 phungus- is now known as phungus
 776 2012-07-03 19:10:39 Vitas has joined
 777 2012-07-03 19:13:48 Vitas has quit (Read error: Connection reset by peer)
 778 2012-07-03 19:16:34 <gmaxwell> BlueMatt: yuck on the mega complicated priority algorithm.
 779 2012-07-03 19:16:57 <BlueMatt> gmaxwell: suggestions?
 780 2012-07-03 19:17:26 <BlueMatt> gmaxwell: Im assuming you are against the B part...well you could ignore the txout size part and just use txout count and txout age
 781 2012-07-03 19:17:31 <gmaxwell> One thing that you need to consider is the complexity of coin selection which makes "good" decisions relative to the priority.  Or existing one is already a MINLP, though at least a pretty simple one.
 782 2012-07-03 19:18:40 RazielZ has quit (Quit: Leaving)
 783 2012-07-03 19:18:48 Prattler has joined
 784 2012-07-03 19:19:09 <BlueMatt> MINLP?
 785 2012-07-03 19:19:28 <gmaxwell> At the moment I'm a fan of   sum(value*age)/max(size/2,2*size-tx_outs_consumed_size)   optionally changing the 2* with some other coefficient. But my opinion changes over time. Size actually captures CPU cost, up to some worst case constant.
 786 2012-07-03 19:20:39 <BlueMatt> why weight age by value?
 787 2012-07-03 19:21:48 <gmaxwell> Because priority is spending coins days destroyed as a scarce resource to prevent spamming.
 788 2012-07-03 19:22:28 <gmaxwell> BlueMatt: Also, your 'Client minimum fee/priority determination' totally misses the interesting revelation wrt client fees that we came up with a few weeks ago.
 789 2012-07-03 19:22:40 <BlueMatt> what'd I miss there?
 790 2012-07-03 19:22:41 <gmaxwell> (and I'm sorry I was in meetings all day and couldn't respond to gavins query to talk about fees)
 791 2012-07-03 19:23:31 <BlueMatt> in terms of using bitcoin days destroyed, Im really not a big fan of such measurements
 792 2012-07-03 19:24:01 <gmaxwell> The longstanding objection to using TXN which made it into blocks to drive the clients fee logic is that people already have network-invisible agreements with miners to mine particular transactions. Median provides some protection there, but it's a hack and can still be seriously distorted by these arrangements.
 793 2012-07-03 19:24:10 <BlueMatt> In the end, txout/in value has no effect on network load, it only tries to make it more expensive to make tons of txouts
 794 2012-07-03 19:24:19 <BlueMatt> but that can be done other ways
 795 2012-07-03 19:24:34 <BlueMatt> gmaxwell: it doesnt
 796 2012-07-03 19:24:45 <BlueMatt> oh, you mean txes that didnt make it
 797 2012-07-03 19:24:49 <BlueMatt> sorry, meant to do that...
 798 2012-07-03 19:24:50 <BlueMatt> oops
 799 2012-07-03 19:24:50 <gmaxwell> — so,  instead make the client decision based only on TXN which were _not_ mined.
 800 2012-07-03 19:24:53 <gmaxwell> right
 801 2012-07-03 19:24:54 <gmaxwell> okay.
 802 2012-07-03 19:25:55 <gmaxwell> forget the value it's not a value, it's about expending a naturally scarce resource to pay your way to access capacity, but without taking from you anything that you value.
 803 2012-07-03 19:26:56 <gmaxwell> BlueMatt: Without doing that the priority doesn't systematically distinguish an abusive user who is rapidly recycling the same coins in order to bloat the network, from someone who just moves a lot of data.
 804 2012-07-03 19:26:58 <BlueMatt> even still, it punishes low-value txes when we really dont need to
 805 2012-07-03 19:27:48 <gmaxwell> BlueMatt: not disproportionally—  only in so far as making it so you can't create more DOS-load by picking smaller txn values.
 806 2012-07-03 19:28:15 <BlueMatt> my point is it shouldn't.  If we can make micro-payments as legitimate as someone paying out 500 50bts payments, thats a plus...and I dont see why we cant
 807 2012-07-03 19:28:28 <gmaxwell> otherwise I get 1 btc, split it into 1e8 parts, and bounce each around in turn creating 4000 txn per second all with reasonable priority.
 808 2012-07-03 19:28:54 <gmaxwell> BlueMatt: er, also, ... sounds like you're misunderstaing routing.
 809 2012-07-03 19:28:59 imsaguy has quit ()
 810 2012-07-03 19:29:05 <BlueMatt> "Note that the attack vector of splitting a huge number of bitcoins into as many 1-satoshi outputs as possible, letting them age, and them spending them to create a huge number of sigops is addressed by the counting of txout count, however that may need a bigger/lower weight to address this specific issue."
 811 2012-07-03 19:29:27 [\\\] has joined
 812 2012-07-03 19:29:30 [\\\] has quit (Changing host)
 813 2012-07-03 19:29:30 [\\\] has joined
 814 2012-07-03 19:29:33 <BlueMatt> true, after its created it is just as easy to spend as a big value
 815 2012-07-03 19:30:15 <gmaxwell> s/routing/value/ sorry, talking at the same time and had some bleedthrough.
 816 2012-07-03 19:30:18 <BlueMatt> but then I would just take my 500 btc and split it into .5 btc parts and make 4000 txn/second
 817 2012-07-03 19:30:29 <gmaxwell> The point being is that even with strong age*value you can _still_ make 1e-8 payments painlessly!
 818 2012-07-03 19:30:52 <gmaxwell> You just attach 1 BTC of _additional_ input, and take it back as change, buring its bitcoin days destroyed in the process to pay for your txn.
 819 2012-07-03 19:31:16 <gmaxwell> It's not the priority system's fault that our current coin selector was written before it, and thus doesn't know how to do that.
 820 2012-07-03 19:32:42 <BlueMatt> agreed, the priority system design shouldn't take into account the coin selection algorithm, but...I dont think we should force users to have btc lying around before they can make microdonations to the eff
 821 2012-07-03 19:33:11 <gmaxwell> BlueMatt: they can make a microdonation to the eff— it just may take a long time to confirm, though what do you care about that for that case?
 822 2012-07-03 19:34:21 <gmaxwell> also, so long as the eff gets a copy of it, they could spend the unconfirmed input with either a fee or enough high priority other inputs (perhaps their own fun) - so long as miners get rational grouping.
 823 2012-07-03 19:34:27 <BlueMatt> my goal is that if we can avoid making it any harder by punishing spam txes other ways, why not?
 824 2012-07-03 19:35:04 <gmaxwell> But you're not punishing spam transactions at all with your suggestion because you're consuming no finite resource.
 825 2012-07-03 19:35:41 <gmaxwell> Basically once txn are laid out right the users can create unbounded load by simpuating ∞ users each undertaking the least expensive operation.
 826 2012-07-03 19:36:08 <BlueMatt> block size/free tx area is the finite resource, yes they charged, but they cant create a huge load
 827 2012-07-03 19:36:31 <BlueMatt> s/they charged/they arent required to do really anything/
 828 2012-07-03 19:36:34 <gmaxwell> Then they can trivially deny all access to the free txn area with a single commandline. Why bother offering it at all.
 829 2012-07-03 19:36:45 <BlueMatt> they?
 830 2012-07-03 19:36:54 <gmaxwell> Byzantine attacker.
 831 2012-07-03 19:37:10 <BlueMatt> the point is to make their tx lower prio than others, meaning they cant?
 832 2012-07-03 19:37:46 <gmaxwell> By making priority depend on burning a finite resource you make it so that someone who just wants to make the world burn can't boundlessly get ahead of all the normal users (at least not unless they have unbounded resources)
 833 2012-07-03 19:38:03 <gmaxwell> any system of priority that does not consume a resource owned by the user can't achieve that.
 834 2012-07-03 19:39:34 <BlueMatt> you cant make them not boundlessly fill what they have the resources to get access to, but you can prioritize their txes lower than legitimate ones, meaning the legitimate ones arent actually effected
 835 2012-07-03 19:40:20 <gmaxwell> you can't because you can't distinguish legimate from illegitimate— no line of code can see into the heart of a man. :)
 836 2012-07-03 19:40:43 <gmaxwell> all you can do is distinguish more costly vs less, but they'll just pretend to be N users making the least costly kind of txn.
 837 2012-07-03 19:41:11 <gmaxwell> and you can't tell if they are 1 person or N because of our privacy model.
 838 2012-07-03 19:41:13 Marf has joined
 839 2012-07-03 19:42:54 <gmaxwell> Have I driven you mad yet? :)
 840 2012-07-03 19:43:01 <BlueMatt> no, sorry distracted
 841 2012-07-03 19:43:51 <gmaxwell> s'fine.  Sorry to be pig headed about this, I previously thought what you thought and then I had some priority religious expirence and now you're just a heretic that needs to be converted. ;)
 842 2012-07-03 19:43:53 <BlueMatt> if you have enough 1 satoshi outputs to always have very new txouts lying around to spend, then you could have very large txes with low btc*days that you can spend around just as easily
 843 2012-07-03 19:45:35 <gmaxwell> BlueMatt: yes, but then once I've spent them they're gone. And the only way I can advantage myself in this regard is by sitting on lots of bitcoin. ... which simultaniously means I'm not likely to gain from attacking bitcoin. ... and the advantage is only linear. E.g. sitting on 500x bitcoin or for 500x longer gives me a one time 500x larger attack.
 844 2012-07-03 19:46:23 <gmaxwell> vs step (1) rain 1e-8 outputs now. ... N months later.. be able to saturate the highest prior list for the rest of time.
 845 2012-07-03 19:46:39 <gmaxwell> s/prior/prio/
 846 2012-07-03 19:46:45 datagutt has quit (Quit: Computer has gone to sleep.)
 847 2012-07-03 19:47:43 <gmaxwell> (because once I have a million 1e-8 outputs .. by the time I spend all of them again once at maximum rate the first will be old enough to respend again and get me to the front of the line)
 848 2012-07-03 19:51:38 <BlueMatt> gmaxwell: and once Ive spent my 1satoshi output, they are no longer as old, so my resource of txout age (instead of btc*txout age) is now gone...
 849 2012-07-03 19:52:06 <gmaxwell> for first 1 satoshi output which you respend before is already old again, so long as you made enough 1e-8 outputs to begin with.
 850 2012-07-03 19:52:11 <BlueMatt> gmaxwell: instead of sum(value*age), use sum(min(value, 1BTC)*age)
 851 2012-07-03 19:52:15 <BlueMatt> or some other constant
 852 2012-07-03 19:52:34 Zarutian has quit (Quit: Zarutian)
 853 2012-07-03 19:52:36 <BlueMatt> s/: instead of/: proposal: instead of/
 854 2012-07-03 19:53:10 <BlueMatt> so that you never end up in a situation where you need 1000btc-days to donate your 1 satoshi to the eff
 855 2012-07-03 19:53:11 <gmaxwell> I'd have to ruminate there. Generally adding _any_ non-linearity to this system favors attackers over honest users.
 856 2012-07-03 19:53:40 <gmaxwell> BlueMatt: the only resason you'd need that is because there is more compeition for free slots than there is room.
 857 2012-07-03 19:54:05 <BlueMatt> and my point is in such a case, we dont want to favor people who dont have as many btc as those who are btc-rich
 858 2012-07-03 19:54:14 <gmaxwell> and if there isn't room there isn't room. Someone gets left behind. Why shouldn't it be the txn with the greatest resources expended to make it happen?
 859 2012-07-03 19:54:21 <BlueMatt> whether its btc-days or not, it still favors those who have more btc
 860 2012-07-03 19:54:47 <BlueMatt> the whole point of the free-tx-area isnt to be capitalist, its to be out of the good of the hearts of the miners ;)
 861 2012-07-03 19:54:57 <gmaxwell> You're no less rich favored by making people burn fees. You've just replaced a scarece resource people didn't care about losing for one they did.
 862 2012-07-03 19:55:26 <gmaxwell> free tx area is not altruist, or at least not more than slightly.
 863 2012-07-03 19:55:38 <gmaxwell> It's an investment in the future of bitcoin. Everyone understands it that way.
 864 2012-07-03 19:56:01 <BlueMatt> then what is it? the point of the free tx area is to " keep Bitcoin's reputation as the "usually free payment solution.""
 865 2012-07-03 19:56:07 <gmaxwell> besides, priority should tiebreak txn with equal fee/byte.
 866 2012-07-03 19:56:20 <BlueMatt> if you have to have 100 btc lying around that is a month old to get into that area, it defeats the purpose
 867 2012-07-03 19:56:31 <BlueMatt> especially since the most gain there is for new users who are just trying it out
 868 2012-07-03 19:57:04 <BlueMatt> if new users never see the "usually free payment" part, it entirely defeats the purpose
 869 2012-07-03 19:57:09 <gmaxwell> If _no one_ can get into the area because one jackass who typed while true ; do spam ; done is both bloating the chain and using the space then it also does not good.
 870 2012-07-03 19:57:46 <gmaxwell> Adding nonlinearies increases the benefit to attackers precisely because they choose their behavior to be the most attack per unit work, while regular users can't easily choose their behavior to enjoy the most benefit.
 871 2012-07-03 19:58:49 <gmaxwell> And I don't agree that it's to 'keep Bitcoin's reputation as the "usually free payment solution."'  thats a claim which as been specifically avoided. For example in the weusecoins video it claims "low fees" and shows a 0.01 btc fee, in the section for advantages to consumers.
 872 2012-07-03 19:59:15 <BlueMatt> yes, but, by making it entirely linear you have to have 1 bill. btc to attack, and the benifit of the free tx area is entirely gone...if you add a bit, it costs 1mill btc to attack, and we still get the benifit
 873 2012-07-03 19:59:30 <gmaxwell> Moreover, if people are concerned about that why is no one bothering to change coin selection so that it even _attempts_ to create a free txn?
 874 2012-07-03 19:59:55 <BlueMatt> (that was a quote from gavin's tx-fee gist)
 875 2012-07-03 20:00:24 <BlueMatt> and I see little other reason why it would be an investment in bitcoin's future...its an investment in bitcoin's future by allowing it to keep low-fees for longer, we get more users
 876 2012-07-03 20:01:19 <gmaxwell> Because there is a difference between "I make a free transaction and it gets processed eventually" and "I make a free transaction and it's simply free and processed right away"
 877 2012-07-03 20:01:33 <gmaxwell> the latter is very close to being dead already.
 878 2012-07-03 20:01:47 <BlueMatt> who said anything about being processed right away?
 879 2012-07-03 20:02:54 <BlueMatt> Id expect some miners to not have a free-tx area and some to have a huge one, confirmation times for free txes will vary widely
 880 2012-07-03 20:03:10 <gmaxwell> It's implicit in saying bitcoin transactions are free. If your txn takes a week to confirm, you paid for it in waiting time.
 881 2012-07-03 20:03:36 <gmaxwell> (and/or uncertanty in your waiting time)
 882 2012-07-03 20:04:01 <BlueMatt> ok s/allowing it to keep low-fees for longer/allowing users to continue to make free txes confirm eventually longer/
 883 2012-07-03 20:05:03 <gmaxwell> And a priority system which is O(1) for an attacker who has paid a constant preperation cost doesn't have that property (however we'd like to name it specifically), not in the fact of attackers who screw things up for the hell of it.
 884 2012-07-03 20:05:29 m00p has joined
 885 2012-07-03 20:06:16 <gmaxwell> And yes, if you stick value in your equation you fix this.  I just declined to comment on the particular min(value,1) because I have to think harder to see if thats easily a mess. I would note that putting _any_ btc constant into the formula means it will not be durable with changing value of bitcoin.
 886 2012-07-03 20:07:18 <gmaxwell> Maybe there is a way to do something like min(value,avg_of_inputs_over_last_N_blocks) which is more durable.
 887 2012-07-03 20:07:27 <BlueMatt> an attacker with limited resources (in the form of N Xbtc outputs of a given age (where X is the constant in the suggestion and the given age is the age needed to beat the average free tx) ) doesnt have O(1) for an attacker
 888 2012-07-03 20:07:46 <BlueMatt> gmaxwell: I came around to sticking value in the equasion like 30 minutes ago...
 889 2012-07-03 20:08:10 <gmaxwell> Yes, and I said:
 890 2012-07-03 20:08:11 <gmaxwell> 12:49 < gmaxwell> I'd have to ruminate there. Generally adding _any_ non-linearity to this system favors attackers over honest users.
 891 2012-07-03 20:08:50 <BlueMatt> As long as its still very expensive for attackers, meh...you can make it cost 1mill btc for a reasonable attack compared to 1bill, so what?
 892 2012-07-03 20:09:03 <BlueMatt> ok, /1000
 893 2012-07-03 20:10:58 <gmaxwell> Perhaps! but then say bitcoin deflates to $1000/1BTC ... and then this is exactly the same as age*value. Or it inflates to $0.01/btc... and it's the same as age*constant and vulnerable (though I suppose we have other issues in that case).   You've also inserted a non-linearity inside a multiply which means that optimal coin solving is much harder.
 894 2012-07-03 20:11:53 danbri has joined
 895 2012-07-03 20:11:54 <gmaxwell> So I need to ponder it. I'm unconvinced you can put the nonlinearity at a point where it won't be ~the same as age*value while not also making attacks easy.
 896 2012-07-03 20:12:24 <BlueMatt> the point is to be the same as age (without value) unless you have a tiny amount
 897 2012-07-03 20:12:46 <BlueMatt> but yea, it would have to scale somehow
 898 2012-07-03 20:13:22 <gmaxwell> That makes attacks easy unless tiny is defined correctly.
 899 2012-07-03 20:13:47 <gmaxwell> I take back the solver comment min(value,1) * age can be preprocessed so to the solver it's the same as value*age.
 900 2012-07-03 20:13:51 danbri__ has quit (Ping timeout: 246 seconds)
 901 2012-07-03 20:14:29 <BlueMatt> yes, defining tiny wouldn't be easy, but I do believe its possible
 902 2012-07-03 20:15:17 <BlueMatt> gmaxwell: what do you suggest for a hard algorithm that pays attention to non-spent txes in mempool?
 903 2012-07-03 20:16:04 <BlueMatt> avg fee/kb among highest N txes sorted according to fee/kb that have been ignore for >=6 blocks is what I wrote, but that was just a straw-man, there should be something better
 904 2012-07-03 20:16:40 Turingi has joined
 905 2012-07-03 20:17:31 <gmaxwell> I don't know. There are a lot of ways and I don't know which is best, what I want to do is instrument a node and measure them.. and see which, retrospectively predicts best how long until a txn gets mined. But I forgot to do this.
 906 2012-07-03 20:18:11 <gmaxwell> BlueMatt: so another issue with age*min(value,constant) is that that it will produce a lot of ties, how should they be resolved?
 907 2012-07-03 20:19:13 topace has joined
 908 2012-07-03 20:19:15 <BlueMatt> I wouldnt think so, high-prio txes would have pretty old inputs, Id think, so ties would be (somewhat) rare...after that...meh random?
 909 2012-07-03 20:19:29 <BlueMatt> whichever has been in mempool the longest or whatever, doesnt really matter
 910 2012-07-03 20:20:22 <gmaxwell> age is an integer.
 911 2012-07-03 20:20:37 <gmaxwell> oh I see your point.
 912 2012-07-03 20:20:40 <BlueMatt> yes, age in block count
 913 2012-07-03 20:20:43 <BlueMatt> if its high...
 914 2012-07-03 20:20:45 <gmaxwell> maybe. ties for low prio don't matter.
 915 2012-07-03 20:20:50 <BlueMatt> yep
 916 2012-07-03 20:20:51 <gmaxwell> If it's high the age has high entropy.
 917 2012-07-03 20:21:28 <BlueMatt> ties doesnt really matter in any case imho...I dont see why anyone should have to care whether they picked the better of two txes that tied in prio and fee
 918 2012-07-03 20:21:38 <gmaxwell> I'm, ... slipping on my acceptance of this.
 919 2012-07-03 20:21:44 <BlueMatt> it happened to be near the cutoff, sucks for you
 920 2012-07-03 20:22:02 <gmaxwell> Lets say you have lots of >1 btc txn. If you don't then your concern driving min(1,value) is irrelevant.
 921 2012-07-03 20:22:37 <gmaxwell> So you do. This means that which txn gets mined is just random. So instead of people with lots of age coin to burn for days destroyed getting first dibs it goes randomly.
 922 2012-07-03 20:22:54 <gmaxwell> I think this is a worse outcome. Slow is bad, non-determinstic and slow is worse.
 923 2012-07-03 20:23:45 <BlueMatt> ok, so in the case of ties you sort by value? thats fine by me...though it just complicates it further, and Id like to keep it dead-simple
 924 2012-07-03 20:24:23 <gmaxwell> hahah
 925 2012-07-03 20:24:31 <gmaxwell> thats the same as value*age.
 926 2012-07-03 20:25:03 <BlueMatt> only if you are near the cutoff to the free tx area, if you arent then its not
 927 2012-07-03 20:25:09 <BlueMatt> and that sounds perfectly fine to me
 928 2012-07-03 20:26:12 jurov is now known as away!aktooj@84.245.71.31|jurov
 929 2012-07-03 20:28:39 faster has quit (Quit: WeeChat 0.3.7)
 930 2012-07-03 20:29:25 agricocb has quit (Quit: Leaving.)
 931 2012-07-03 20:35:09 maaku has joined
 932 2012-07-03 20:39:18 TD has quit (Quit: TD)
 933 2012-07-03 20:43:20 InabaEMC has quit ()
 934 2012-07-03 20:51:12 <BlueMatt> gmaxwell: assuming some value of A can be sanely agreed upon, what about something like:
 935 2012-07-03 20:51:12 <BlueMatt> sum(age of txout * min(value of txout, A) * sigops to verify txout) * sum((size of txout created)^2)/sum((size of txout spent)^2)
 936 2012-07-03 20:51:33 <BlueMatt> probably need to tweak the 2's to something bigger/smaller
 937 2012-07-03 20:52:01 <luke-jr> wouldn't that give you better priority for more sigops?
 938 2012-07-03 20:52:09 <BlueMatt> oops, sorry
 939 2012-07-03 20:52:11 <BlueMatt> 1/sigops
 940 2012-07-03 20:52:24 <gmaxwell> bleh.
 941 2012-07-03 20:52:27 <gmaxwell> Thats overly complicated.
 942 2012-07-03 20:52:45 <gmaxwell> And the ^2/^2 ratio is ugly.
 943 2012-07-03 20:53:05 <BlueMatt> how so? you still need to address the sigop count, num of txouts created/destroyed and size of txouts created/destroyed
 944 2012-07-03 20:53:14 <BlueMatt> to address that list, that algo is about as simple as it gets
 945 2012-07-03 20:53:33 <gmaxwell> again, _nonlinearies benefit abusive users_. Because instead of creating two txn that create X size, they'll create four txn with X/2 size, and get a benefit over normal users who aren't crafting their txn.
 946 2012-07-03 20:54:57 <gmaxwell> And you do not need the opcount because size is proportional to op count, up to a constant.
 947 2012-07-03 20:55:02 <BlueMatt> so now you get four txes with ~ the same prio as the original 2?
 948 2012-07-03 20:55:24 <BlueMatt> size isnt proportional to opcount if people add messages
 949 2012-07-03 20:55:29 <BlueMatt> and if that isnt punished, people will
 950 2012-07-03 20:55:49 <BlueMatt> well, it shouldnt be punished as sigops
 951 2012-07-03 20:56:18 <BlueMatt> wait, no, size isnt proportional to sigops
 952 2012-07-03 20:56:24 <BlueMatt> we arent looking at tx size, only txout size
 953 2012-07-03 20:56:32 <BlueMatt> if (p2sh) txout size is constant
 954 2012-07-03 20:57:18 <luke-jr> we should look at tx size too
 955 2012-07-03 20:57:30 <BlueMatt> Im torn as to whether or not to
 956 2012-07-03 20:57:36 <BlueMatt> its a one-time-cost
 957 2012-07-03 20:57:45 <BlueMatt> and has only very minor effects, in the end
 958 2012-07-03 20:57:55 <BlueMatt> compared to txout size and txout count
 959 2012-07-03 20:59:24 <BlueMatt> gmaxwell: no, if you split your tx to create more volume, your tx would have lower prio here
 960 2012-07-03 20:59:46 danbri has quit (Remote host closed the connection)
 961 2012-07-03 21:00:19 <BlueMatt> gmaxwell: a. you dont have infinite txout of a given age, b. if you did, unless your txouts divide evenly to match your target total, you'll end up with more inputs, which is punished here
 962 2012-07-03 21:04:31 m00p has quit (Quit: Leaving)
 963 2012-07-03 21:14:48 <gmaxwell> BlueMatt: 0_o  you really shouldn't include sigops. Another reason is because the cost factor isn't constant. At some point we'll get gpu sigvalidation and get a million sigops per second or something. And even if not, sigops scales with mooreslaw but bandwidth grows much more slowly.
 964 2012-07-03 21:16:24 agricocb has joined
 965 2012-07-03 21:17:16 <BlueMatt> gmaxwell: however, sigops are one of the current bottlenecks for verifying the chain
 966 2012-07-03 21:17:21 <BlueMatt> even after its threaded, it still is
 967 2012-07-03 21:17:50 <BlueMatt> including total tx size is a separate issue, and you may be right there
 968 2012-07-03 21:18:23 <gmaxwell> BlueMatt: sure, but you can represent that with size purely. You don't can't get more than about more sigops dense than average transactions.
 969 2012-07-03 21:18:48 <gmaxwell> So all you could do with that is give a free pass to txn that are stuffing random data in their scripts.
 970 2012-07-03 21:19:26 <BlueMatt> is there no difference between sigops/byte of multisig and regular?
 971 2012-07-03 21:19:43 <BlueMatt> what about p2sh and regular or send-to-address vs send-to-pubkey
 972 2012-07-03 21:19:49 <BlueMatt> there are some pretty big variations there
 973 2012-07-03 21:20:03 <gmaxwell> They increase the redeeming transaction sizes. Signatures are huge.
 974 2012-07-03 21:20:53 <gmaxwell> BlueMatt: sigops are a bottleneck with the historic chain, but if it really bothers you can only validate 1 in N of them at random. for an N fold speedup, anywhere up to say 100 blocks from the top.
 975 2012-07-03 21:21:58 <BlueMatt> sigops are the bottleneck downloading the chain, but that doesnt bother me...what bothers me is that they are the bottleneck getting new txes and processing them for mining
 976 2012-07-03 21:22:09 <BlueMatt> and as tx volume continues to grow, that may actually become important
 977 2012-07-03 21:22:29 <BlueMatt> (because tx volume has, in the past, grown way faster than more's law)
 978 2012-07-03 21:23:27 <gmaxwell> er. any random desktop today can process signatures FAR FAR faster than the current maximum block size allows.
 979 2012-07-03 21:23:36 <gmaxwell> (at least if you use all the cores)
 980 2012-07-03 21:24:40 <gmaxwell> and if you're hardforking to change that you can replace ecdsa with a much faster curve. :-/
 981 2012-07-03 21:25:20 <gmaxwell> And again, because signatures are already huge the only thing you count can do beyond charging for size is give a free pass to txn which are stuffing non-txn data.
 982 2012-07-03 21:26:02 <BlueMatt> meh, fair enough
 983 2012-07-03 21:27:18 minimoose has joined
 984 2012-07-03 21:28:01 <BlueMatt> gmaxwell: sum(age of txout * min(value of txout, A) * txin size to spend txout) * sum((size of txout created)^2)/sum((size of txout spent)^2)
 985 2012-07-03 21:28:10 <BlueMatt> makes the coin selection simpler as you add txin
 986 2012-07-03 21:28:31 <BlueMatt> though doing tx size itself works, its not as directly connected with txout selection
 987 2012-07-03 21:28:39 <BlueMatt> though Im not sure it actually matters...meh
 988 2012-07-03 21:28:45 rdponticelli has quit (Ping timeout: 246 seconds)
 989 2012-07-03 21:29:32 <gmaxwell> What is your objection to a simple mostly linear size cost?  e.g.   like  2*size-size_spent?
 990 2012-07-03 21:30:00 <BlueMatt> it doesnt take into account the actual number of txouts created
 991 2012-07-03 21:30:12 <BlueMatt> which is important as thats what you have to use to lookup the txout
 992 2012-07-03 21:30:29 <BlueMatt> disk space is pretty cheap, using the size is mostly for network costs
 993 2012-07-03 21:30:55 <gmaxwell> It _does_ take into account the size, since there is a minimum size and most tx out are near the minimum regardless.
 994 2012-07-03 21:31:13 <gmaxwell> Also, the ^2 does the opposite of what you seem to be saying.
 995 2012-07-03 21:31:38 <gmaxwell> (in that it make the initial byte much cheaper than the Nth byte)
 996 2012-07-03 21:32:16 <gmaxwell> (marginally, of course)
 997 2012-07-03 21:39:01 toffoo has joined
 998 2012-07-03 21:40:07 <gmaxwell> er. well, it would if you had a / where I thought you should.  As you actually wrote it you get an enormous priority boost foo just padding junk data in your txn. I give up. Talk to me again when you've had some more time to think about this.
 999 2012-07-03 21:43:13 jurov is now known as jurov|away
1000 2012-07-03 21:47:07 [\\\] is now known as \\\\\\\\\\\\\\\\
1001 2012-07-03 21:47:20 \\\\\\\\\\\\\\\\ is now known as imsaguy
1002 2012-07-03 21:48:07 tcatm has joined
1003 2012-07-03 21:48:08 tcatm has quit (Changing host)
1004 2012-07-03 21:48:08 tcatm has joined
1005 2012-07-03 21:49:34 O2made has joined
1006 2012-07-03 21:49:59 O2made has quit (Remote host closed the connection)
1007 2012-07-03 21:50:53 imsaguy is now known as [\\\\\\\\\\\\\\]
1008 2012-07-03 21:51:56 <freewil> what version was safe mode introduced?
1009 2012-07-03 21:53:13 topace has quit (Read error: Connection reset by peer)
1010 2012-07-03 21:53:55 topace has joined
1011 2012-07-03 21:53:56 Motest003 has quit (Ping timeout: 264 seconds)
1012 2012-07-03 21:55:10 Motest003 has joined
1013 2012-07-03 21:55:10 sirk390 has quit (Quit: Leaving.)
1014 2012-07-03 21:59:13 eoss has joined
1015 2012-07-03 21:59:14 eoss has quit (Changing host)
1016 2012-07-03 21:59:14 eoss has joined
1017 2012-07-03 22:06:35 sirk390 has joined
1018 2012-07-03 22:07:50 sirk390 has quit (Client Quit)
1019 2012-07-03 22:16:08 copumpkin has quit (Quit: Computer has gone to sleep.)
1020 2012-07-03 22:20:38 TD has joined
1021 2012-07-03 22:21:38 maaku has quit (Quit: maaku)
1022 2012-07-03 22:26:01 rdponticelli has joined
1023 2012-07-03 22:28:14 mmoya has joined
1024 2012-07-03 22:31:54 [\\\\\\\\\\\\\\] is now known as imsaguy
1025 2012-07-03 22:34:07 danbri has joined
1026 2012-07-03 22:35:13 copumpkin has joined
1027 2012-07-03 22:35:16 Prattler has quit (Read error: Connection reset by peer)
1028 2012-07-03 22:37:24 <avengre> anyone know the guys name who runs blockchain.info?
1029 2012-07-03 22:37:42 danbri has quit (Remote host closed the connection)
1030 2012-07-03 22:39:07 ThomasV has joined
1031 2012-07-03 22:40:55 <lianj> avengre: https://github.com/zootreeves/blockchain.info
1032 2012-07-03 22:42:03 Hunner has joined
1033 2012-07-03 22:44:29 ThomasV has quit (Quit: Quitte)
1034 2012-07-03 22:47:17 RainbowDashh has joined
1035 2012-07-03 22:47:24 Tykling has quit (Ping timeout: 272 seconds)
1036 2012-07-03 22:49:49 RainbowDashh has quit (Client Quit)
1037 2012-07-03 22:51:30 Tykling has joined
1038 2012-07-03 22:58:10 Tykling has quit (Ping timeout: 272 seconds)
1039 2012-07-03 23:00:30 Tykling has joined
1040 2012-07-03 23:03:23 da2ce7 has joined
1041 2012-07-03 23:04:53 ronaz has quit (Ping timeout: 245 seconds)
1042 2012-07-03 23:05:29 ronaz has joined
1043 2012-07-03 23:06:09 paul0 has quit (Quit: paul0)
1044 2012-07-03 23:13:30 Keefe has quit (Ping timeout: 252 seconds)
1045 2012-07-03 23:18:05 maaku has joined
1046 2012-07-03 23:23:26 mmoya has quit (Ping timeout: 248 seconds)
1047 2012-07-03 23:25:24 da2ce7 has quit (Changing host)
1048 2012-07-03 23:25:24 da2ce7 has joined
1049 2012-07-03 23:33:09 maaku has quit (Quit: maaku)
1050 2012-07-03 23:34:38 Karmaon has quit (Read error: Connection reset by peer)
1051 2012-07-03 23:34:46 Karmaon has joined
1052 2012-07-03 23:34:47 Karmaon has quit (Changing host)
1053 2012-07-03 23:34:47 Karmaon has joined
1054 2012-07-03 23:37:03 bvh has quit (Ping timeout: 244 seconds)
1055 2012-07-03 23:42:30 da2ce7 has quit (Ping timeout: 248 seconds)
1056 2012-07-03 23:43:41 tcatm has quit (Remote host closed the connection)
1057 2012-07-03 23:50:24 DBordello has quit (Quit: ZNC - http://znc.in)
1058 2012-07-03 23:54:54 TD has quit (Quit: TD)