1 2012-07-03 00:55:34 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1551 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1551>
  2 2012-07-03 01:38:21 <tgs3> bitcoind is unbearably slow, every program on compyter that touches hard drive freezes for many seconds
  3 2012-07-03 01:38:25 <tgs3> linux 2.6 kernel debian
  4 2012-07-03 01:38:37 <tgs3> 0.6.3 bitcoind, catching up to chain
  5 2012-07-03 01:40:30 <tgs3> bitcoind getinfo command takes 47 second to execute, teach time (more or less)
  6 2012-07-03 02:02:04 <gmaxwell> tgs time to fix your failing drive.
  7 2012-07-03 02:04:24 <tgs3> gmaxwell: no problems with other disk trashing applications
  8 2012-07-03 02:04:38 <tgs3> remarkably even freenet causes less trouble
  9 2012-07-03 02:12: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.
 10 2012-07-03 02:15:36 <tgs3> me neither with previous versions of bitcoin
 11 2012-07-03 02:21:20 <doublec> tgs3: I experience the same
 12 2012-07-03 02:22: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
 13 2012-07-03 02:31:52 <gmaxwell> tgs3: whats previous for you?
 14 2012-07-03 02:32:25 <gmaxwell> Older versions of bitcoin were much less efficient and spent a lot of time doing nothing.
 15 2012-07-03 02:42:45 <tgs3> gmaxwell: certainly that is better then making uses thing btc is making their computer useless
 16 2012-07-03 02:42:49 <tgs3> *users
 17 2012-07-03 02:48:24 <tgs3> luke-jr that does not help much
 18 2012-07-03 02:48:38 <luke-jr> I know, Linux sucks at IO management -.-
 19 2012-07-03 02:48:42 <tgs3> programs should moderate themselves
 20 2012-07-03 02:48:44 <tgs3> it doe
 21 2012-07-03 02:49:11 <tgs3> linux IO is quite a fail, but applications too should moderate and optimize
 22 2012-07-03 02:50:04 <tgs3> io-miss-managment is worsened in case of disk encryption, a quite possible option among possible btc users
 23 2012-07-03 02:50:28 <gmaxwell> tgs3: As I mentioned it doesn't have that behavior for me.  even testing on a system with dmcrypt.
 24 2012-07-03 02:50:40 <luke-jr> gmaxwell: you have SSD? :P
 25 2012-07-03 02:50:43 <tgs3> gmaxwell: it seems doublec experiences the same problem
 26 2012-07-03 02:51:15 <gmaxwell> luke-jr: no testing on a spinning disk + dmcrypt. It makes the disk busy but doesn't make the system noticably unresponsive.
 27 2012-07-03 02:51:43 <tgs3> try debian stable
 28 2012-07-03 02:52:25 <gmaxwell> Sorry, I like my software to come from later than the mid 1780s.
 29 2012-07-03 02:52:45 <gmaxwell> (my spinning disk system is Fedora 16)
 30 2012-07-03 02:53:14 <gjs278> I have 5 ssds in a raid5, I don't get any slowdown
 31 2012-07-03 02:53:20 <gjs278> that's probably the minimum requirements
 32 2012-07-03 02:53:27 <tgs3> maybe program should be upgraded to work even on debian stable, instead of requiring users to move
 33 2012-07-03 02:53:41 <tgs3> debian is not that 'rare' among geeks, servers ops and cryptoalike folk
 34 2012-07-03 02:53: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.
 35 2012-07-03 02:54:24 <luke-jr> gmaxwell: well, that doesn't make all of Debian bad :p
 36 2012-07-03 02:54:38 <tgs3> is it their fault the package failed on sparc?
 37 2012-07-03 02:54:54 <gmaxwell> tgs3: Big endian is not supported by the software.
 38 2012-07-03 02:54:57 <luke-jr> tgs3: Bitcoin has *never* worked on SPARC
 39 2012-07-03 02:55:00 <tgs3> I don't want to point fingers but I thought you guys develop and they pack/pull
 40 2012-07-03 02:55:01 <gmaxwell> It has never been supported, it never worked.
 41 2012-07-03 02:55:28 <tgs3> luke-jr: funny.. so that is a problem to upgrade a thing but not to release it initially? what?
 42 2012-07-03 02:56:28 <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.
 43 2012-07-03 02:56:41 <gmaxwell> And as a result, they wouldn't upgrade.
 44 2012-07-03 02:56:44 <tgs3> is it actually that impossible to run on LE? what pleaces depend on it, with mining out.. some controll-sums?
 45 2012-07-03 02:57:14 <tgs3> well that decissions seems obviously illogical...
 46 2012-07-03 02:57:15 <luke-jr> tgs3: not impossible, just difficult because Satoshi can't code and nobody has time to fix it
 47 2012-07-03 02:57:36 <gmaxwell> er BE.
 48 2012-07-03 02:57:50 <gmaxwell> (of course)
 49 2012-07-03 02:57:50 <tgs3> mythical characters usually are not good at real life coding
 50 2012-07-03 02:58:07 <luke-jr> lol
 51 2012-07-03 02:59:17 <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.
 52 2012-07-03 02:59:21 <tgs3> like my Faun
 53 2012-07-03 02:59:34 <tgs3> can't get that damn bastard to fix bugs in kernel we run on our pc
 54 2012-07-03 03:00:29 <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
 55 2012-07-03 03:00:39 <tgs3> it would be totally handy now
 56 2012-07-03 03:00:43 <gmaxwell> yuck.
 57 2012-07-03 03:01:09 <luke-jr> tgs3: well, what do you need micropayments for?
 58 2012-07-03 03:01:17 <gmaxwell> In any case, no one actually cares about it... if they did it would get fixed.
 59 2012-07-03 03:01:28 <tgs3> well if we would have any micropayments, one could make a bounty.
 60 2012-07-03 03:01:49 <luke-jr> tgs3: no programmer is going to spend time on something they don't care about for micropayment bounties
 61 2012-07-03 03:01:53 <luke-jr> you need something more real
 62 2012-07-03 03:02:07 <tgs3> I assumes SPARC incompatibility will be roadblock for further debian releases. That seems problematic considering what is popular on servers
 63 2012-07-03 03:02:23 <luke-jr> tgs3: x86 is pretty popular on servers these days
 64 2012-07-03 03:02:30 <luke-jr> ARM is trying to get in, but that's LE too
 65 2012-07-03 03:02:35 <tgs3> but debian will refuse to get it
 66 2012-07-03 03:02:41 <tgs3> and I can sympathaise
 67 2012-07-03 03:02:47 <gmaxwell> And attaching real money to BE support .. for the sake of it, is BS distortion of development incentives.
 68 2012-07-03 03:02:52 <tgs3> SPARC is related to open-sparc is it not?
 69 2012-07-03 03:03:26 <luke-jr> shrug
 70 2012-07-03 03:03: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
 71 2012-07-03 03:03:42 <luke-jr> if someone wants to pay me 10+ BTC/hr to fix BE, I'd do it :p
 72 2012-07-03 03:03:44 <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.
 73 2012-07-03 03:04:08 <luke-jr> gmaxwell: no, they can use stable branches
 74 2012-07-03 03:04: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
 75 2012-07-03 03:05:09 <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.
 76 2012-07-03 03:05:20 <luke-jr> tgs3: choose one: 1) slightly worse system responsiveness during blockchain download, or 2) multi-day initial blockchain sync
 77 2012-07-03 03:05:24 <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
 78 2012-07-03 03:05:54 <luke-jr> gmaxwell: I blame BIP16 for that.
 79 2012-07-03 03:06:06 <gmaxwell> tgs3: bitcoin taking multiple days to sync up was not good. Fix your computer. seriously. This isn't bitcoin's problem.
 80 2012-07-03 03:06:07 <tgs3> luke-jr: 2) or  3) I uninstall bitcoin and use real money
 81 2012-07-03 03:06: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
 82 2012-07-03 03:06: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
 83 2012-07-03 03:07:25 <luke-jr> tgs3: are you offering to improve the status quo?
 84 2012-07-03 03:07:32 <tgs3> if the later, then trashing hard drive speed, reducing hdd life-time, or not heaving a nice GUI and icon = no go.
 85 2012-07-03 03:07:35 <luke-jr> tgs3: besides, Electrum.
 86 2012-07-03 03:07:41 <tgs3> luke-jr: Elewhat?
 87 2012-07-03 03:07:45 <gmaxwell> tgs3: Please don't insult me.
 88 2012-07-03 03:07:58 <luke-jr> tgs3: Electrum is a lighter Bitcoin client
 89 2012-07-03 03:08:02 <luke-jr> http://bitcoin.org/clients.html
 90 2012-07-03 03:08:20 <tgs3> gmaxwell: what again? I dont :)
 91 2012-07-03 03:08: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.
 92 2012-07-03 03:08:25 <luke-jr> & why does that attribute Bitcoin-Qt to Satoshi? he didn't write that -.-
 93 2012-07-03 03:10:08 <tgs3> or did he
 94 2012-07-03 03:12:50 <galambo> might have well as been "john smith" right
 95 2012-07-03 03:12:58 <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.
 96 2012-07-03 03:14: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.
 97 2012-07-03 03:16:29 <tgs3> gmaxwell: hope it progresses then. At some later time I might try to check again ionice
 98 2012-07-03 03:17:17 <gmaxwell> tgs3: How much ram does your system have?
 99 2012-07-03 03:18:42 <tgs3> 8 gb
100 2012-07-03 03:19:13 <gmaxwell> ha. okay scratch that theory.
101 2012-07-03 03:19:41 <gmaxwell> (I was wondering if perhaps you were going to tell me "128mb" or something like that :))
102 2012-07-03 03:20:24 <gmaxwell> tgs3: well, to end your pain temporarily do your syncup using tmpfs.
103 2012-07-03 03:20:29 <gmaxwell> You will be quite happy. :)
104 2012-07-03 03:25:49 <tgs3> my 128mb is more responsible then this+bitcoind ;)
105 2012-07-03 03:26:20 <tgs3> tmpfs might be a good idea. gotta backup wallet too
106 2012-07-03 03:27: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.
107 2012-07-03 06:37:48 <luke-jr> ;;bc,blocks
108 2012-07-03 06:37:49 <gribble> 187310
109 2012-07-03 07:07:29 <t7> ;;bc;reward
110 2012-07-03 07:07:30 <gribble> Error: "bc;reward" is not a valid command.
111 2012-07-03 07:07:35 <gribble> Error: "bc,reward" is not a valid command.
112 2012-07-03 07:07:35 <t7> ;;bc,reward
113 2012-07-03 07:07:46 <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.".
114 2012-07-03 07:07:46 <sipa> ;;bc,gen
115 2012-07-03 09:07:56 <Cubox> ;;bc,gen 40
116 2012-07-03 09:07:57 <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.
117 2012-07-03 09:08:09 <Cubox> xD
118 2012-07-03 09:08:23 <sipa> mining on a raspberry pi?
119 2012-07-03 09:10:41 <Cubox> mining on cpu only
120 2012-07-03 09:11:37 <sipa> what cpu is that, and what program?
121 2012-07-03 09:11:54 <jine> 40 *K*hash?
122 2012-07-03 09:11:58 <sipa> you should be able to do a few Mhash/s on a desktop cpu
123 2012-07-03 09:12:34 <Cubox> jine: y
124 2012-07-03 09:12:43 <Cubox> sipa: i'm mining litecoin ...
125 2012-07-03 09:12:46 <sipa> ah
126 2012-07-03 09:13:10 <Cubox> and bbqcoins but it's an other story :P
127 2012-07-03 09:15:35 <ersi> Hah, nice.. eh, anti-earning per day
128 2012-07-03 09:16:00 <Cubox> ersi: o.O
129 2012-07-03 09:16:22 <ersi> 2.33023945756e-05 BTC is actually a negative amount, if I'm not mistaken?
130 2012-07-03 09:16:36 <Cubox> no
131 2012-07-03 09:16:49 <Cubox> it's 2.3302^-5
132 2012-07-03 09:16:58 <Cubox> or in python
133 2012-07-03 09:17:05 <Cubox> 2.3302**-5
134 2012-07-03 09:17:12 <ersi> shrug
135 2012-07-03 09:17:16 <Cubox> look at the e-05
136 2012-07-03 09:17:20 <ersi> I loath scientific notation
137 2012-07-03 09:17:22 <Cubox> e = ^
138 2012-07-03 09:17:25 <ersi> yeah
139 2012-07-03 09:17:26 <Cubox> :
140 2012-07-03 09:17:29 <Cubox> :)*
141 2012-07-03 09:17:37 <sipa> Cubox: no
142 2012-07-03 09:17:57 <sipa> it is 2.33 * 10^-5
143 2012-07-03 09:18:03 <Cubox> hmm, right
144 2012-07-03 09:28:19 <zab_> math is hard and for nerds (TM - Barbie corp.)
145 2012-07-03 09:43:03 <Cubox> hmm, where does bitcoin store his temp files ? If there are temp file put in an other place than .bitcoin
146 2012-07-03 09:44:04 <sipa> temp files?
147 2012-07-03 09:44:12 <Cubox> hmm
148 2012-07-03 09:44:22 <sipa> everything is in ~/.bitcoin
149 2012-07-03 09:44:32 <Cubox> yes, I saw that the client remember the last connections, and i deleted all the .bitcoin
150 2012-07-03 09:44:47 <Cubox> idea, lsof on the process
151 2012-07-03 09:45:16 <sipa> i just told you; it stores everything in ~/.bitcoin
152 2012-07-03 09:46:05 <Cubox> hmm
153 2012-07-03 09:46:44 <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
154 2012-07-03 09:47:21 <sipa> if you changed the source, you're on your own :)
155 2012-07-03 09:47:34 <Cubox> sipa: oh, i forgot, it's for a fork :)
156 2012-07-03 09:48:08 <Cubox> but bitcoin have remembered the last connection, after deleting the .bitcoin
157 2012-07-03 09:48:28 <sipa> did you delete .bitcoin while it was running?
158 2012-07-03 09:49:41 <Cubox> no
159 2012-07-03 09:49:51 <sipa> in that case it cannot have remembered anything
160 2012-07-03 09:49:59 <Cubox> Just keep the conf, deleted all other stuff
161 2012-07-03 09:50:16 <sipa> why do you think it did?
162 2012-07-03 09:51:34 <Cubox> sipa: i started it with -printtoconsole and i saw like "last seen -10h"
163 2012-07-03 09:51:56 <sipa> yes, lastseen info propagates through the network
164 2012-07-03 09:52:17 <sipa> and addresses retrieved from DNS seeds also get a random lastseen tag
165 2012-07-03 09:53:14 <Cubox> trying connection 176.9.149.152:5233 lastseen=-0.8hrs
166 2012-07-03 09:53:23 <Cubox> oh
167 2012-07-03 09:53:24 <Cubox> okey
168 2012-07-03 09:53:45 <sipa> peer ip addresses are stored in addr.dat in <=0.6.3
169 2012-07-03 09:53:46 <Cubox> [2012-07-03 13:53:38] HTTP request failed: The requested URL returned error: 500
170 2012-07-03 09:53:58 <Cubox> sipa: i deleted addr.dat too
171 2012-07-03 10:41:21 <gribble> New news from bitcoinrss: Diapolo opened pull request 1552 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1552>
172 2012-07-03 11:35:54 <abracadabra> meh
173 2012-07-03 11:45:49 <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
174 2012-07-03 11:50:22 <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.
175 2012-07-03 11:50:30 <ersi> Just a friendly tip
176 2012-07-03 11:51:12 <gmaxwell> Cubox: you need to be running two nodes to mine. You need to not be in initial download.
177 2012-07-03 11:53:20 <Cubox> gmaxwell: we are 2 nodes mining
178 2012-07-03 11:53:37 <Cubox> ersi: thanks, i'm not familiar with forums
179 2012-07-03 11:53:39 <gmaxwell> Okay, you've exausted my quick advice, see ersi's comments.
180 2012-07-03 11:54:51 <Cubox> gmaxwell: :/ Thanks
181 2012-07-03 11:55:56 <Cubox> But yeah, will ask in the forum
182 2012-07-03 11:56:40 <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.
183 2012-07-03 11:57:01 <Cubox> ersi: thanks :)
184 2012-07-03 11:57:22 <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 :)
185 2012-07-03 11:57:33 <ersi> you're very welcome, especially if you read/listened to me :D
186 2012-07-03 11:57:54 <Cubox> I always read/listen :)
187 2012-07-03 11:58:23 <ersi> there's suprisingly a lot of people who don't, that's why I'm happy you do
188 2012-07-03 12:05:34 <rms78070> can anyone tell me how to get bitcoins?
189 2012-07-03 12:05:59 <sipa> buy them?
190 2012-07-03 12:06:05 <sipa> see #bitcoin
191 2012-07-03 12:06:27 <ersi> Yeah, #bitcoin is the place for discussing that. This is where developers/programmers hang and talk other techy stuff
192 2012-07-03 12:06:44 <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
193 2012-07-03 12:06:50 <rms78070> Oh I see, thank ersi
194 2012-07-03 12:15:28 <doublec> Cubox: try the alternate cryptocurrencies sub-forum
195 2012-07-03 12:15:37 <doublec> Cubox: https://bitcointalk.org/index.php?board=67.0
196 2012-07-03 12:15:41 <ersi> That's a very good suggestion ^
197 2012-07-03 12:15:48 <doublec> Cubox: the litecoin dev hangs out there and could help
198 2012-07-03 12:18:07 <doublec> Cubox: also look in your debug.log for errors. You'll probably find issues with your genesis block or checkpoints
199 2012-07-03 12:19:04 <jgarzik> doublec: I think there's #litecoin-dev or similar
200 2012-07-03 12:19:11 <jgarzik> Cubox: ^
201 2012-07-03 12:20:54 <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 :)
202 2012-07-03 12:32:26 <Cubox> doublec: omg
203 2012-07-03 12:32:29 <Cubox> checkpoints
204 2012-07-03 12:32:41 <Cubox> doublec: will check this
205 2012-07-03 12:33:25 <Cubox> jgarzik: they don't answer :) and bitcoin is the base
206 2012-07-03 12:33:39 <Cubox> jgarzik: so, i'm telling that i'm forking bitcoin, because it's more known
207 2012-07-03 12:34:12 <sipa> and what are you trying to accomplice?
208 2012-07-03 12:34:37 <Cubox> sipa: mine a block :)
209 2012-07-03 13:04:04 <doublec> Cubox: make sure you're using a litecoin miner and not a bitcoin miner
210 2012-07-03 13:04:17 <doublec> Cubox: if you're basing on litecoin - they use different mining algorithms
211 2012-07-03 13:04:23 <Cubox> doublec: ofc, i use the intern litecoin miner
212 2012-07-03 13:04:27 <Cubox> setgenerate true :)
213 2012-07-03 13:04:32 <doublec> yeah, just thought I'd check
214 2012-07-03 13:04:36 <Cubox> doublec: i know, sha256 ans scrupt :)
215 2012-07-03 13:04:40 <Cubox> scrypt*
216 2012-07-03 13:04:58 <doublec> saying its based on bitcoin though and then "setgenerate true" confuses people since bitcoin doesn't support setgenerate
217 2012-07-03 13:05:11 <Cubox> oh
218 2012-07-03 13:05:11 <doublec> so best to stick with "based on litecoin"
219 2012-07-03 13:05:41 <Cubox> doublec: but i founded the issue, it was checkpoints
220 2012-07-03 13:05:47 <doublec> ok, cool
221 2012-07-03 13:06:03 <sipa> doublec: sure bitcoin supports setgenerate?
222 2012-07-03 13:06:11 <sipa> it's not useful for anything but testing though
223 2012-07-03 13:06:30 <doublec> sipa: I thought it was removed? Sorry for giving bad info!
224 2012-07-03 13:06:41 <sipa> doublec: it was removed from the GUI a long time ago
225 2012-07-03 13:06:49 <doublec> ah, that's what I was thinking of
226 2012-07-03 13:06:53 <sipa> and the optimized assembly implementations have been removed as well
227 2012-07-03 13:07:01 <sipa> but there's still reference mining code
228 2012-07-03 13:34:26 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 1553 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1553>
229 2012-07-03 13:34:51 <Cubox> Whyyyyyyyy, the hashmerkleroot is not the good one :(
230 2012-07-03 13:37:05 <helo> for fun, and to learn a little, i'm thinking about writing a bitcoin network visualization tool
231 2012-07-03 13:37:57 <helo> to show competing chains, visualize reorgs, compare nodes
232 2012-07-03 13:38:39 <helo> show a representation of transactions as they are received, and show them being integrated into new blocks
233 2012-07-03 13:39:34 <Joric> helo, btclook.com had cool charts won't open now
234 2012-07-03 13:39:44 <helo> i was hoping to get 1) confirmation that this isn't a complete waste of time, and 2) other feature ideas
235 2012-07-03 13:40:19 <Joric> there was a realtime svg visualization with arrows and verlet physics
236 2012-07-03 13:42:38 <helo> hopefully something like that ^
237 2012-07-03 13:43:20 <Joric> SVG. Generated by d3.js
238 2012-07-03 13:44:04 <Joric> something like that http://mbostock.github.com/d3/ex/force.html
239 2012-07-03 13:44:54 <Joric> or that http://mbostock.github.com/d3/talk/20111116/force-collapsible.html
240 2012-07-03 13:47:02 <Cubox> ersi: can i ask for your help again ?
241 2012-07-03 13:47:03 <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
242 2012-07-03 13:47:17 <Cubox> ersi: I don't find the "create a topic" button on the forum :(
243 2012-07-03 13:47:44 <helo> are there any python libraries that can do node discovery, and receive transactions, process blocks, etc?
244 2012-07-03 13:49:15 <helo> if i could use python to do the backend, it would offset the pain of web development :)
245 2012-07-03 13:49:24 <Joric> helo, i was trying to write an universal blockchain parser on python https://github.com/joric/pyblockchain
246 2012-07-03 13:50:01 <helo> Socket?
247 2012-07-03 13:50:16 <Joric> just parses blockchain
248 2012-07-03 13:50:40 <Joric> there's a semi-functional pure-python client https://github.com/samrushing/caesure
249 2012-07-03 13:51:13 <helo> ahh cool
250 2012-07-03 13:51:40 <sipa> Cubox: are you new on the forum? in that case you're restricted to some boards
251 2012-07-03 13:52:46 <Cubox> sipa: oh
252 2012-07-03 13:53:18 <Cubox> sipa: how can i do for get this restriction out ?
253 2012-07-03 13:55:58 <gavinandresen> gmaxwell: you available to brainstorm on transaction fees? Or anybody else around interested?
254 2012-07-03 13:59:52 <helo> ahh... caesure looks like a decent starting point
255 2012-07-03 14:00:31 <sipa> gavinandresen: gtg soon
256 2012-07-03 14:00:39 <luke-jr> I'm here
257 2012-07-03 14:00:52 <gavinandresen> sipa: ok
258 2012-07-03 14:01:00 <luke-jr> gavinandresen: did check txn_prio yet?
259 2012-07-03 14:02:07 <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
260 2012-07-03 14:02:13 <luke-jr> ah
261 2012-07-03 14:02:21 <luke-jr> I know that code is probably far from ideal
262 2012-07-03 14:02:44 <luke-jr> I'm just not sure how to do it better, but if someone wants to rewrite it, go for it ;)
263 2012-07-03 14:02:50 <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
264 2012-07-03 14:03:55 <sipa> gavinandresen: i doubt that is possible
265 2012-07-03 14:04:00 <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"
266 2012-07-03 14:04:44 <gavinandresen> sipa: I'm thinking that choosing defaults based on recent blockchain history could work nicely.
267 2012-07-03 14:05:17 <jgarzik> gavinandresen: I find there is a relationship between a useful dust spam fee, and real world price
268 2012-07-03 14:05:19 <gavinandresen> sipa: yesterday I dug out some statistics from a sample of 45 recent blocks:  https://docs.google.com/spreadsheet/ccc?key=0Ar4FtkFP4j73dGpCRnlucHVuSXl3VjhsTk5XaTBIV3c
269 2012-07-03 14:05:26 <jgarzik> gavinandresen: it is difficult to find a feedback mechanism that echoes that
270 2012-07-03 14:05:36 <luke-jr> gavinandresen: can't hurt - probably want a minimum on block size though
271 2012-07-03 14:06:23 <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)
272 2012-07-03 14:07:18 <sipa> gavinandresen: the priority rule based on size/age is one that stems from the "fees to prevent spam" idea
273 2012-07-03 14:08:07 <jgarzik> yes
274 2012-07-03 14:08:17 <gavinandresen> sipa: yes, I know (Satoshi was very excited when I suggested computing priority that way)
275 2012-07-03 14:08:30 <sipa> i prefer priorities based on network cost, and keep the spam prevention separate
276 2012-07-03 14:08:43 <gavinandresen> what do you mean by network cost?
277 2012-07-03 14:09:02 <sipa> size, number of outputs created and spent, ...
278 2012-07-03 14:09:38 <BlueMatt> do many of those criteria not intersec with anti-spam?
279 2012-07-03 14:09:48 <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.
280 2012-07-03 14:10:27 <sipa> a transaction that consumes 100 coins and creates 1 has a very positive effect for the network
281 2012-07-03 14:10:35 <sipa> in the long term
282 2012-07-03 14:10:55 <sipa> while the opposite is terrible
283 2012-07-03 14:10:57 <gavinandresen> I'm not against multiplying priority by ratio of outputs/inputs
284 2012-07-03 14:11:29 <gavinandresen> (err, the inverse of that I mean)
285 2012-07-03 14:12:01 <sipa> if you reason from the viewpoint of network cost, it'd have to be A*size + B*(txouts - txins)
286 2012-07-03 14:12:13 <sipa> for some very hard to estimate constants A and B
287 2012-07-03 14:12:46 <jgarzik> don't forget age
288 2012-07-03 14:12:59 <BlueMatt> where txouts/txins also takes into account size and num sigops
289 2012-07-03 14:13:13 <BlueMatt> ehh...no txins doesnt care about size, txouts do
290 2012-07-03 14:13:13 <sipa> account size?
291 2012-07-03 14:13:24 <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
292 2012-07-03 14:13:35 <BlueMatt> txout size, have to count it from the point of view of network transmission and storage costs
293 2012-07-03 14:14:04 <BlueMatt> ie big txout is worse than big tx in general
294 2012-07-03 14:14:05 <sipa> jgarzik: do you think age plays a large role for long-term cost?
295 2012-07-03 14:14:11 <sipa> BlueMatt: indeed
296 2012-07-03 14:14:29 <gavinandresen> I think priority would be =  sum(input_value_in_base_units * age) * B*(inputs/outputs) / (A*size)
297 2012-07-03 14:14:30 <jgarzik> sipa: slows velocity
298 2012-07-03 14:14:31 <luke-jr> sipa: age is important so spammers can't just keep flipping the same coin in and out
299 2012-07-03 14:14:55 <gavinandresen> ... and I'd suggest A and B are both 1.0
300 2012-07-03 14:14:56 <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
301 2012-07-03 14:14:57 <sipa> luke-jr: yes, but imho spam prevention is a separate concern that needs separate rules
302 2012-07-03 14:15:00 <jgarzik> sipa: which hopefully slows block chain growth, or at least requires high producers to pay fees
303 2012-07-03 14:15:35 <gavinandresen> spam prevention is all about priority, which IS separate from fees.
304 2012-07-03 14:15:38 <luke-jr> gavinandresen: adding the input/output ratio might be tricky with dependency trees
305 2012-07-03 14:16:03 <sipa> afaict, A*size + B*(txout size - consumed txout size) + C*sigops
306 2012-07-03 14:16:04 <gavinandresen> luke-jr: shouldn't be, a dependency tree has X inputs and Y outputs total....
307 2012-07-03 14:16:22 <sipa> is the most accurate representation of network cost
308 2012-07-03 14:16:24 <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>
309 2012-07-03 14:16:33 <luke-jr> gavinandresen: yes, but you need to walk the tree to figure out the effective inputs
310 2012-07-03 14:17:03 <jgarzik> "spam prevention" is another way to rephrase "we find this behavior annoying enough to require additional fees"
311 2012-07-03 14:17:05 <jgarzik> nothing more
312 2012-07-03 14:17:06 <sipa> luke-jr: i hope to make that operation cheap
313 2012-07-03 14:17:54 <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...
314 2012-07-03 14:17:57 <jgarzik> on the flip side, we want to _positively_ incentivize old age
315 2012-07-03 14:18:01 <BlueMatt> and if you are doing that, why include spammy txes
316 2012-07-03 14:18:01 <jgarzik> it's not just spam prevention
317 2012-07-03 14:18:10 <jgarzik> you can prune some old transactions
318 2012-07-03 14:18:22 <jgarzik> keep longtime users invested
319 2012-07-03 14:18:30 <sipa> that's why txout size is more important than tx size
320 2012-07-03 14:19:38 <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
321 2012-07-03 14:20:08 <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.
322 2012-07-03 14:20:10 <jgarzik> we definitely want to encourage txout reduction
323 2012-07-03 14:21:05 <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
324 2012-07-03 14:21:28 <BlueMatt> gavinandresen: so, my suggestion would be prio per fee floor
325 2012-07-03 14:22:11 <gavinandresen> BlueMatt: I was thinking it would be "either fee/kb above a fee floor, OR priority above a priority floor."
326 2012-07-03 14:22:35 <gavinandresen> ... because priority=0 but-carries-a-reasonable-fee transactions will probably be common
327 2012-07-03 14:22:40 <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.
328 2012-07-03 14:22:59 <jgarzik> that has been a bitcoin Big Problem from day one.
329 2012-07-03 14:23:15 <gavinandresen> jgarzik: I'm not following
330 2012-07-03 14:23:33 <BlueMatt> gavinandresen: not sure about fee/kb, maybe "fee/prio or prio"
331 2012-07-03 14:23:36 <gavinandresen> jgarzik: do you mean code to automatically figure out what A Reasonable Fee is?
332 2012-07-03 14:23:51 <gavinandresen> (where Reasonable means "likely to get into the next block")
333 2012-07-03 14:24:02 <jgarzik> gavinandresen: yes
334 2012-07-03 14:24:08 <BlueMatt> eh s|fee/prio|fee*prio|
335 2012-07-03 14:24:33 <gavinandresen> jgarzik: ACK on that, I agree that is important.  But it is tied into figuring out fee/priority floors
336 2012-07-03 14:24:38 <jgarzik> A bitcoin user largely guesses at fees today (or lets the client guess, based on precompiled constants).
337 2012-07-03 14:24:42 <luke-jr> jgarzik: gmaxwell had a good idea for that: watch the txns that *don't* get confirmed
338 2012-07-03 14:24:49 <jgarzik> If they guess wrong,their transaction is in limbo and cannot be cancelled.
339 2012-07-03 14:24:58 <BlueMatt> jgarzik: absolutely
340 2012-07-03 14:25:13 <gavinandresen> jgarzik: exactly, I'm trying to brainstorm how to get rid of the compiled-in guesses.
341 2012-07-03 14:25:45 <gavinandresen> It looks like looking at average fee/kb of the last 50 or 100 blocks gives a reasonable number
342 2012-07-03 14:26:01 <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.
343 2012-07-03 14:26:19 <jgarzik> dynamic observation
344 2012-07-03 14:26:23 <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
345 2012-07-03 14:26:44 <jgarzik> BlueMatt: it's a very reasonable desire -- we must plan for that, for the future
346 2012-07-03 14:27:02 <jgarzik> BlueMatt: when SPV clients are the majority... how to do that?
347 2012-07-03 14:27:11 <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
348 2012-07-03 14:27:20 <BlueMatt> (to avoid miner stuffing their own high-fee txes)
349 2012-07-03 14:27:55 <BlueMatt> jgarzik: the issue is you dont have any knowledge of tx fees paid by any txes that weren't yours...
350 2012-07-03 14:28:09 <jgarzik> BlueMatt: ...without downloading full blocks anyway
351 2012-07-03 14:28:15 <BlueMatt> jgarzik: yea
352 2012-07-03 14:28:25 <BlueMatt> jgarzik: so...the reasonable solution is probably to just let them get fee info from trusted 3rd-parties that run full nodes... :(
353 2012-07-03 14:28:37 <Eliel_> unless there's some data for it that can be verified through blockchain.
354 2012-07-03 14:28:59 <gavinandresen> blockchain is controlled by miners, that have an incentive to make fees higher if they can
355 2012-07-03 14:29:18 <BlueMatt> gavinandresen: yep, thats why gmaxwell suggested looking at unconfirmed txes
356 2012-07-03 14:29:22 <luke-jr> gavinandresen: that can do so regardless of lying
357 2012-07-03 14:30:20 <luke-jr> what's the practical difference between lying about "I require 0.01 BTC per KB" and actually requiring it?
358 2012-07-03 14:30:22 <gavinandresen> luke-jr: sure, every miner could just take the 32 highest-paying transactions and put them in their blocks and kill Bitcoin....
359 2012-07-03 14:30:28 <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.
360 2012-07-03 14:30:36 <gavinandresen> ... but there's an incentive for miners to take all fee-paying transactions...
361 2012-07-03 14:31:07 <BlueMatt> gavinandresen: yea, I dont think miners will just only accept the highest-paying ones or they will lose all the fees
362 2012-07-03 14:31:08 <gavinandresen> (assuming it costs them less to include them than the fees)
363 2012-07-03 14:31:17 <BlueMatt> and then some smaller miner will pick it up and send the average back down anyway...
364 2012-07-03 14:31:17 <jgarzik> in a T+10 year future, I always assumed that fees would simply be a requirement
365 2012-07-03 14:31:52 <jgarzik> and that fees might be so high that it incentivizes off-network transactions, only occasionally publishing on the official blockchain network
366 2012-07-03 14:32:08 <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
367 2012-07-03 14:32:23 <jgarzik> i.e. a payment house flushes transactions to the blockchain on a nightly basis, paying requisite fees
368 2012-07-03 14:32:33 <jgarzik> sipa: yep
369 2012-07-03 14:32:54 <phantomcircuit> sipa, shh you'll ruin my business model
370 2012-07-03 14:33:06 <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
371 2012-07-03 14:33:11 <jgarzik> TD's suggestion of transaction chains covered by one fee is nice, and seems to have consensus
372 2012-07-03 14:33:11 <sipa> and no light client would need to know anything about fees or mining
373 2012-07-03 14:33:18 <jgarzik> indeed
374 2012-07-03 14:33:28 <sipa> BlueMatt: sure
375 2012-07-03 14:33:41 <luke-jr> jgarzik: that's what my txn_prio branch does
376 2012-07-03 14:33:57 <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
377 2012-07-03 14:34:00 <BlueMatt> so discussing the T+10 year future of merchants putting txes into blocks through big mining companies I find irrelevant...
378 2012-07-03 14:34:14 <BlueMatt> yes, it should happen but its not really a part of fee discussions now?
379 2012-07-03 14:34:14 <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
380 2012-07-03 14:34:24 <sipa> BlueMatt: exactly
381 2012-07-03 14:35:08 <jgarzik> well -- as gavinandresen pointed out, looking at dynamic inputs does have consequences
382 2012-07-03 14:35:28 <jgarzik> I imagine any fee structure major-rewrite will have years-long consequences
383 2012-07-03 14:35:46 <gavinandresen> yes, that's why I'd like to get it right the first time
384 2012-07-03 14:36:16 <phantomcircuit> lol terrible coffee
385 2012-07-03 14:37:04 <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
386 2012-07-03 14:37:23 <BlueMatt> jgarzik: so even if the market shifts hugely so that getting into a block requires huge fees, it will still apply
387 2012-07-03 14:37:24 <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?
388 2012-07-03 14:37:27 <BlueMatt> even if it does take huge fee
389 2012-07-03 14:37:28 <BlueMatt> s
390 2012-07-03 14:38:23 <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.
391 2012-07-03 14:38:33 <jgarzik> AFAICT we exist today on the tacit miner agreement that fee enforcement would strangle bitcoin usage in its infancy.
392 2012-07-03 14:39:15 <jgarzik> the bitcoin client with its policies of non-relaying is the only powerful counterbalance
393 2012-07-03 14:39:33 <BlueMatt> gavinandresen: then a p2pool miner doesnt limit their blocks and gets a ton of fees?
394 2012-07-03 14:40:01 <gavinandresen> BlueMatt: not a ton, no, I don't imagine any miner would forgo tons of fees to limit their blocksize.
395 2012-07-03 14:40:38 <BlueMatt> oh, you mean today/as long as you couldn't fill a block with your entire mempool...
396 2012-07-03 14:40:47 <jgarzik> thankfully block size is hard fork limited at present
397 2012-07-03 14:41:15 <gavinandresen> Average block size is still pretty small (50K or so in my sample)
398 2012-07-03 14:42:40 <BlueMatt> gavinandresen: yes, I think relying on miners to limit low-prio+low-fee txes is reasonable
399 2012-07-03 14:43:13 <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
400 2012-07-03 14:43:53 <jgarzik> BlueMatt: seems like a setting that people would read and immediately set to zero
401 2012-07-03 14:44:12 <BlueMatt> jgarzik: was just thinking that...but it could be framed better...
402 2012-07-03 14:45:18 <BlueMatt> jgarzik: also, if every node on the network already limits relay of eg "fee*prio < X && prio < Y" it could further help
403 2012-07-03 14:45:39 <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)
404 2012-07-03 14:46:30 <phantomcircuit> gavinandresen, in british english that sentence is hilarious
405 2012-07-03 14:46:33 <BlueMatt> or put the "fee*prio < X && prio < Y" a mempool limit and take away the knobs for X and Y
406 2012-07-03 14:46:41 <gavinandresen> Straw-man reasonable default:   be willing to forgo 5% of the average fees in the last 100 blocks.
407 2012-07-03 14:47:08 <BlueMatt> given that average users arent gonna care about it, Id think thats perfectly reasonable
408 2012-07-03 14:47:23 <gavinandresen> phantomcircuit: does pulling your knob mean something different in british english?
409 2012-07-03 14:47:30 <phantomcircuit> yes it does
410 2012-07-03 14:47:46 <phantomcircuit> something dirty
411 2012-07-03 14:47:55 <gavinandresen> I'm shocked!
412 2012-07-03 14:47:59 <phantomcircuit> :)
413 2012-07-03 14:48:12 <BlueMatt> gavinandresen: its listed at a DoS limit in the code anyway
414 2012-07-03 14:48:54 <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...
415 2012-07-03 14:49:17 <BlueMatt> "them"?
416 2012-07-03 14:49:28 <jgarzik> miners
417 2012-07-03 14:49:32 <gavinandresen> jgarzik: good point
418 2012-07-03 14:50:29 <BlueMatt> jgarzik: are you saying forgoing N fees to avoid spam is bad pr?
419 2012-07-03 14:50:36 <jgarzik> BlueMatt: yes
420 2012-07-03 14:50:43 <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."
421 2012-07-03 14:50:57 <jgarzik> gavinandresen: ack
422 2012-07-03 14:51:03 <gavinandresen> and just drop spammy transactions entirely, they never enter the mempool
423 2012-07-03 14:51:11 <jgarzik> ack
424 2012-07-03 14:51:16 <BlueMatt> jgarzik: dunno, if you forgo N fees, yea probably, but if its written as DOS in mempool...
425 2012-07-03 14:51:21 <BlueMatt> yea
426 2012-07-03 14:51:51 <gavinandresen> give miners a great big knob (everybody wants a big knob) for how much space to give high-priority "free" transactions ?
427 2012-07-03 14:51:59 <BlueMatt> ack
428 2012-07-03 14:52:04 <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.
429 2012-07-03 14:52:08 <jgarzik> gavinandresen: ack
430 2012-07-03 14:52:37 <gavinandresen> Again, I wonder if we can figure out what "high priority" and "spammy" means automatically
431 2012-07-03 14:52:40 <BlueMatt> jgarzik: yea, <BlueMatt> or put the "fee*prio < X && prio < Y" a mempool limit and take away the knobs for X and Y
432 2012-07-03 14:52:54 <phantomcircuit> gavinandresen, s/knob/tunable/
433 2012-07-03 14:53:03 <phantomcircuit> tuneable*
434 2012-07-03 14:53:35 <BlueMatt> gavinandresen: high prio is just "sorted by prio" according to something like sipa's suggestion
435 2012-07-03 14:53:46 <BlueMatt> gavinandresen: spammy is the only one we really have to figure out
436 2012-07-03 14:53:48 <gavinandresen> I mean, "above the priority cut-off"
437 2012-07-03 14:54:12 <jgarzik> BlueMatt: ack
438 2012-07-03 14:54:20 <jgarzik> lunchtime
439 2012-07-03 14:54:40 <gavinandresen> swimming with the kids
440 2012-07-03 14:54:54 <BlueMatt> later Im gonna write up what I think is a solution
441 2012-07-03 14:55:03 <BlueMatt> or someone else can
442 2012-07-03 14:55:05 <BlueMatt> whatever...dinner
443 2012-07-03 14:55:06 <gavinandresen> thanks for the brainstorm...
444 2012-07-03 14:55:28 <gavinandresen> BlueMatt: go for it, I'm going to keep thinking....
445 2012-07-03 15:04:58 <xorgate> i just sent some coins to a friend using standard client. why is a second output generated? http://blockchain.info/address/12J8rGZ2eQW5AEEZruJ6ZEv3RLDiGagUE8
446 2012-07-03 15:05:40 <forrestv> xorgate, it's change left over from the input
447 2012-07-03 15:06:49 <xorgate> sure but there's plenty of txs that don't do this
448 2012-07-03 15:08:12 <xorgate> or maybe i'm missing something
449 2012-07-03 15:09:27 <Joric> xorgate, if you send less than a full balance you get change (mostly on another address)
450 2012-07-03 15:10:20 <Joric> transactions work this way, you cant just send a fraction
451 2012-07-03 15:11:17 <xorgate> so my wallet now has this new address as well? i fear my knowledge of btc is not what i thought it was
452 2012-07-03 15:13:35 <Joric> yep every send creates a new address for change
453 2012-07-03 15:27:55 <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
454 2012-07-03 16:49:28 <BlueMatt> https://gist.github.com/3041216
455 2012-07-03 16:49:48 <BlueMatt> my combination of other people's ideas on fee policy ^
456 2012-07-03 17:12:33 <gmaxwell> BlueMatt: yuck on the mega complicated priority algorithm.
457 2012-07-03 17:12:56 <BlueMatt> gmaxwell: suggestions?
458 2012-07-03 17:13:25 <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
459 2012-07-03 17:13:29 <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.
460 2012-07-03 17:15:07 <BlueMatt> MINLP?
461 2012-07-03 17:15:27 <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.
462 2012-07-03 17:16:37 <BlueMatt> why weight age by value?
463 2012-07-03 17:17:46 <gmaxwell> Because priority is spending coins days destroyed as a scarce resource to prevent spamming.
464 2012-07-03 17:18:26 <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.
465 2012-07-03 17:18:39 <BlueMatt> what'd I miss there?
466 2012-07-03 17:18:39 <gmaxwell> (and I'm sorry I was in meetings all day and couldn't respond to gavins query to talk about fees)
467 2012-07-03 17:19:29 <BlueMatt> in terms of using bitcoin days destroyed, Im really not a big fan of such measurements
468 2012-07-03 17:20:00 <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.
469 2012-07-03 17:20:09 <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
470 2012-07-03 17:20:17 <BlueMatt> but that can be done other ways
471 2012-07-03 17:20:33 <BlueMatt> gmaxwell: it doesnt
472 2012-07-03 17:20:43 <BlueMatt> oh, you mean txes that didnt make it
473 2012-07-03 17:20:47 <BlueMatt> sorry, meant to do that...
474 2012-07-03 17:20:48 <BlueMatt> oops
475 2012-07-03 17:20:48 <gmaxwell>  so,  instead make the client decision based only on TXN which were _not_ mined.
476 2012-07-03 17:20:51 <gmaxwell> right
477 2012-07-03 17:20:52 <gmaxwell> okay.
478 2012-07-03 17:21:53 <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.
479 2012-07-03 17:22:54 <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.
480 2012-07-03 17:22:56 <BlueMatt> even still, it punishes low-value txes when we really dont need to
481 2012-07-03 17:23:46 <gmaxwell> BlueMatt: not disproportionally  only in so far as making it so you can't create more DOS-load by picking smaller txn values.
482 2012-07-03 17:24:13 <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
483 2012-07-03 17:24:26 <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.
484 2012-07-03 17:24:52 <gmaxwell> BlueMatt: er, also, ... sounds like you're misunderstaing routing.
485 2012-07-03 17:25:03 <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."
486 2012-07-03 17:25:31 <BlueMatt> true, after its created it is just as easy to spend as a big value
487 2012-07-03 17:26:14 <gmaxwell> s/routing/value/ sorry, talking at the same time and had some bleedthrough.
488 2012-07-03 17:26:16 <BlueMatt> but then I would just take my 500 btc and split it into .5 btc parts and make 4000 txn/second
489 2012-07-03 17:26:28 <gmaxwell> The point being is that even with strong age*value you can _still_ make 1e-8 payments painlessly!
490 2012-07-03 17:26:51 <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.
491 2012-07-03 17:27:14 <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.
492 2012-07-03 17:28:41 <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
493 2012-07-03 17:29:09 <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?
494 2012-07-03 17:30:19 <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.
495 2012-07-03 17:30:26 <BlueMatt> my goal is that if we can avoid making it any harder by punishing spam txes other ways, why not?
496 2012-07-03 17:31:02 <gmaxwell> But you're not punishing spam transactions at all with your suggestion because you're consuming no finite resource.
497 2012-07-03 17:31:40 <gmaxwell> Basically once txn are laid out right the users can create unbounded load by simpuating
498 2012-07-03 17:32:06 <BlueMatt> block size/free tx area is the finite resource, yes they charged, but they cant create a huge load
499 2012-07-03 17:32:30 <BlueMatt> s/they charged/they arent required to do really anything/
500 2012-07-03 17:32:33 <gmaxwell> Then they can trivially deny all access to the free txn area with a single commandline. Why bother offering it at all.
501 2012-07-03 17:32:43 <BlueMatt> they?
502 2012-07-03 17:32:52 <gmaxwell> Byzantine attacker.
503 2012-07-03 17:33:09 <BlueMatt> the point is to make their tx lower prio than others, meaning they cant?
504 2012-07-03 17:33:45 <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)
505 2012-07-03 17:34:02 <gmaxwell> any system of priority that does not consume a resource owned by the user can't achieve that.
506 2012-07-03 17:35:32 <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
507 2012-07-03 17:36:18 <gmaxwell> you can't because you can't distinguish legimate from illegitimate no line of code can see into the heart of a man. :)
508 2012-07-03 17:36:42 <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.
509 2012-07-03 17:37:10 <gmaxwell> and you can't tell if they are 1 person or N because of our privacy model.
510 2012-07-03 17:38:52 <gmaxwell> Have I driven you mad yet? :)
511 2012-07-03 17:39:00 <BlueMatt> no, sorry distracted
512 2012-07-03 17:39:49 <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. ;)
513 2012-07-03 17:39:51 <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
514 2012-07-03 17:41:34 <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.
515 2012-07-03 17:42:22 <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.
516 2012-07-03 17:42:37 <gmaxwell> s/prior/prio/
517 2012-07-03 17:43:42 <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)
518 2012-07-03 17:47:36 <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...
519 2012-07-03 17:48:04 <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.
520 2012-07-03 17:48:10 <BlueMatt> gmaxwell: instead of sum(value*age), use sum(min(value, 1BTC)*age)
521 2012-07-03 17:48:14 <BlueMatt> or some other constant
522 2012-07-03 17:48:34 <BlueMatt> s/: instead of/: proposal: instead of/
523 2012-07-03 17:49:08 <BlueMatt> so that you never end up in a situation where you need 1000btc-days to donate your 1 satoshi to the eff
524 2012-07-03 17:49:09 <gmaxwell> I'd have to ruminate there. Generally adding _any_ non-linearity to this system favors attackers over honest users.
525 2012-07-03 17:49:38 <gmaxwell> BlueMatt: the only resason you'd need that is because there is more compeition for free slots than there is room.
526 2012-07-03 17:50:03 <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
527 2012-07-03 17:50:12 <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?
528 2012-07-03 17:50:20 <BlueMatt> whether its btc-days or not, it still favors those who have more btc
529 2012-07-03 17:50:45 <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 ;)
530 2012-07-03 17:50:55 <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.
531 2012-07-03 17:51:24 <gmaxwell> free tx area is not altruist, or at least not more than slightly.
532 2012-07-03 17:51:36 <gmaxwell> It's an investment in the future of bitcoin. Everyone understands it that way.
533 2012-07-03 17:51:59 <BlueMatt> then what is it? the point of the free tx area is to " keep Bitcoin's reputation as the "usually free payment solution.""
534 2012-07-03 17:52:05 <gmaxwell> besides, priority should tiebreak txn with equal fee/byte.
535 2012-07-03 17:52:19 <BlueMatt> if you have to have 100 btc lying around that is a month old to get into that area, it defeats the purpose
536 2012-07-03 17:52:30 <BlueMatt> especially since the most gain there is for new users who are just trying it out
537 2012-07-03 17:53:02 <BlueMatt> if new users never see the "usually free payment" part, it entirely defeats the purpose
538 2012-07-03 17:53:08 <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.
539 2012-07-03 17:53:44 <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.
540 2012-07-03 17:54:48 <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.
541 2012-07-03 17:55:13 <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
542 2012-07-03 17:55:28 <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?
543 2012-07-03 17:55:53 <BlueMatt> (that was a quote from gavin's tx-fee gist)
544 2012-07-03 17:56:22 <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
545 2012-07-03 17:57:17 <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"
546 2012-07-03 17:57:31 <gmaxwell> the latter is very close to being dead already.
547 2012-07-03 17:57:46 <BlueMatt> who said anything about being processed right away?
548 2012-07-03 17:58:53 <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
549 2012-07-03 17:59:08 <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.
550 2012-07-03 17:59:35 <gmaxwell> (and/or uncertanty in your waiting time)
551 2012-07-03 17:59:59 <BlueMatt> ok s/allowing it to keep low-fees for longer/allowing users to continue to make free txes confirm eventually longer/
552 2012-07-03 18:01:01 <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.
553 2012-07-03 18:02:14 <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.
554 2012-07-03 18:03:16 <gmaxwell> Maybe there is a way to do something like min(value,avg_of_inputs_over_last_N_blocks) which is more durable.
555 2012-07-03 18:03:25 <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
556 2012-07-03 18:03:44 <BlueMatt> gmaxwell: I came around to sticking value in the equasion like 30 minutes ago...
557 2012-07-03 18:04:09 <gmaxwell> Yes, and I said: