1 2013-03-07 00:01:30 <HM> gmaxwell: clearly petertodd burning his coins to create bonds :P
2 2013-03-07 00:14:10 <PRab> Anyone know if blockexplorer.com has an API to their /block pages?
3 2013-03-07 00:14:57 <PRab> I'm looking for the same data, but in an easier to parse format (JSON, XML, CSV, etc.)
4 2013-03-07 00:15:26 <OMGMTGOX> bitcoind is hogging 100% cpu
5 2013-03-07 00:16:19 <gmaxwell> OMGMTGOX: doing a new install?
6 2013-03-07 00:16:43 <OMGMTGOX> gmaxwell: I already remade it from source, I'm on ubuntu 12.04
7 2013-03-07 00:17:25 <OMGMTGOX> ./bitcoind -getinfo doesn't return anything either
8 2013-03-07 00:18:13 <gmaxwell> OMGMTGOX: the command is ./bitcoind getinfo
9 2013-03-07 00:18:14 <sipa> OMGMTGOX: you didn't answer gmaxwell's question
10 2013-03-07 00:18:44 <gmaxwell> and indeed, you didn't??? it's normal and expected for it to use all the available cpu while doing its syncup (esp at the end when the sync process is cpu bound)
11 2013-03-07 00:19:25 <OMGMTGOX> sorry, yes it's a new install of bitcoind however at first it was working, downloading blocks, etc
12 2013-03-07 00:19:42 <OMGMTGOX> it had about 20k to go last night. today, communicating via JSON-RPC gives me an exception
13 2013-03-07 00:19:42 <sipa> perfectly expected in that case
14 2013-03-07 00:19:54 <sipa> oh, which one?
15 2013-03-07 00:22:10 <OMGMTGOX> sipa: php doesn't tell me anything, I'm going to see what I get
16 2013-03-07 00:22:57 <OMGMTGOX> ~/bitcoin/src$ ./bitcoind getinfo error: couldn't connect to server
17 2013-03-07 00:23:17 <gmaxwell> OMGMTGOX: tail ~/.bitcoin/debug.log
18 2013-03-07 00:23:34 <doublec> isn't that error normal when it's downloading the blockchain?
19 2013-03-07 00:23:40 <sipa> no
20 2013-03-07 00:23:52 <sipa> it would refuse to do some things, like getwork
21 2013-03-07 00:23:58 <OMGMTGOX> wallet.dat closed DBFlush(false) ended 33ms StopNode() ThreadOpenConnections exited Flushed 7171 addresses to peers.dat 51ms Committing 36519 changed transactions to coin database... Flush(true) DBFlush(true) ended 0ms Bitcoin exited
22 2013-03-07 00:24:05 <sipa> seems like it exited
23 2013-03-07 00:24:09 <sipa> cleanlt
24 2013-03-07 00:24:10 <OMGMTGOX> I'll look more at it
25 2013-03-07 00:24:12 <sipa> *cleanly
26 2013-03-07 00:24:47 <sipa> sure it's still hogging your CPU...?
27 2013-03-07 00:25:35 <OMGMTGOX> nope, it's shut down now
28 2013-03-07 00:25:59 <OMGMTGOX> I'm going to start clean from a new wallet.dat and see how it goes.
29 2013-03-07 00:26:27 <sipa> just so you understand: from what i can tell, there was nothing wrong
30 2013-03-07 00:27:30 <OMGMTGOX> ahh
31 2013-03-07 00:27:37 <OMGMTGOX> looked at debug.log earlier, low disk space
32 2013-03-07 00:27:54 <sipa> ok, that is a problem of course
33 2013-03-07 00:27:57 <OMGMTGOX> that must be why json-rpc stopped working after it dl'd more blocks.
34 2013-03-07 00:28:07 <sipa> and it shuts down automatically when that is the case
35 2013-03-07 00:46:07 <Luke-Jr> https://twitter.com/gavinandresen/status/309345069461303296 <-- is this why the price drop? -.-
36 2013-03-07 00:46:36 <lianj> yea guessed so too
37 2013-03-07 00:47:33 <lianj> congrats on your big fee block though
38 2013-03-07 00:47:34 <Luke-Jr> gavin should give us some warning next time :p
39 2013-03-07 00:48:50 <warren> Wall street traders watch a IRC channel for price signals.
40 2013-03-07 00:50:45 <HM> lol @ gavin
41 2013-03-07 00:50:52 <HM> such an optimist :)
42 2013-03-07 00:51:53 <gmaxwell> Luke-Jr: you weren't BCCed on that email?
43 2013-03-07 00:53:24 <Luke-Jr> gmaxwell: O.o?
44 2013-03-07 01:07:54 <saivann> Can some one explain me how you get github to build bitcoin.org using your custom plugins (contributors.rb and less.rb)?
45 2013-03-07 01:08:12 <saivann> Github pages run jekyll in safe mode.. And each time I tried, the plugins were ignored.
46 2013-03-07 01:08:30 <gmaxwell> saivann: jekyll is run externally, not on github.
47 2013-03-07 01:08:40 <gmaxwell> There are two repositories, a real one and the displayed one.
48 2013-03-07 01:08:58 <gmaxwell> A script on a remote server picks up commits from one runs the parser and updates the other.
49 2013-03-07 01:09:18 <saivann> All of this is done automatically?
50 2013-03-07 01:09:27 <gmaxwell> Yes.
51 2013-03-07 01:09:32 <saivann> Perfect, thanks
52 2013-03-07 01:10:09 <gavinandresen> saivann: it seemed to be broken a week or so ago, but I think tcatm or BlueMatt fixed it
53 2013-03-07 01:12:08 <saivann> I've succesfully replaced everything Apache/PHP related and added javascript redirections instead. So it should now be OK for github pages
54 2013-03-07 01:12:21 <saivann> There is three orphan pages I didn't include :
55 2013-03-07 01:12:22 <saivann> http://bitcoin.org/critfix.html
56 2013-03-07 01:12:22 <saivann> http://bitcoin.org/dos.html
57 2013-03-07 01:12:22 <saivann> http://bitcoin.org/feb20.html
58 2013-03-07 01:12:38 <saivann> Are you OK to trash them, or are they still necessary?
59 2013-03-07 01:12:57 <gmaxwell> these are messages that were linked from alerts.
60 2013-03-07 01:12:59 <phantomcircuit> there are links to them from all over the web
61 2013-03-07 01:14:32 <BCB> ;;rated appendage
62 2013-03-07 01:14:32 <gribble> You rated user appendage on Wed Mar 6 18:05:56 2013, giving him a rating of 1, and supplied these additional notes: small Dwolla to Paypal trade.
63 2013-03-07 01:14:49 <BCB> ;;rate appendage 1 Small Dwolla to Bitcoin Trade. Smooth.
64 2013-03-07 01:14:50 <gribble> Rating entry successful. Your rating for user appendage has changed from 1 to 1.
65 2013-03-07 01:15:12 <gmaxwell> bcb: wrong channel.
66 2013-03-07 01:17:36 <saivann> Good
67 2013-03-07 01:17:53 <saivann> Concerning the press mailing list, do you still want to keep it? Or rather point to https://bitcoinfoundation.org/contact
68 2013-03-07 01:20:35 <jgarzik> BCB: wrong channel, and, please "/msg gribble ..." instead
69 2013-03-07 01:21:13 <BCB> sorry
70 2013-03-07 01:22:54 <brent5001> does anyone know if the API calls have change from version 0.5.1 to 0.8?
71 2013-03-07 01:23:11 <Luke-Jr> brent5001: not majorly
72 2013-03-07 01:23:18 <brent5001> and/or are the old calls backwards compatible?
73 2013-03-07 01:23:29 <Luke-Jr> brent5001: I think the only change was accounting generation into accounts
74 2013-03-07 01:24:41 <brent5001> where is the api documentation for the different versions?
75 2013-03-07 01:24:55 <jgarzik> brent5001: mainly the wiki, sadly
76 2013-03-07 01:25:02 <Luke-Jr> sadly? O.o
77 2013-03-07 01:25:03 <jgarzik> brent5001: plus release announcements
78 2013-03-07 01:25:19 <jgarzik> Luke-Jr: in an ideal world there would be signed, sealed, delivered API docs for each version
79 2013-03-07 01:25:44 <jgarzik> Luke-Jr: many softwares do that (usually the ones with semi-generated docs, not surprisingly)
80 2013-03-07 01:26:11 <jgarzik> ideal world, click on http://bitcoin.org/bitcoind/api/0.7.2/ etc.
81 2013-03-07 01:26:18 <jrmithdobbs> jgarzik: i've not seen that for anything without auto-generation in like a decade, noone cares about documentation for customers/users any more
82 2013-03-07 01:26:24 <jrmithdobbs> :(
83 2013-03-07 01:26:50 <jrmithdobbs> (so maybe bitcoin needs an automated way of generating it! ;p)
84 2013-03-07 01:26:56 <jgarzik> Easy examples: libevent, mysql, python, ...
85 2013-03-07 01:27:03 <jgarzik> all publish multiple versions of docs
86 2013-03-07 01:27:13 <jgarzik> and archive old, in browseable fashion
87 2013-03-07 01:27:26 <jrmithdobbs> ya, they're mostly generated off the code (all of python is)
88 2013-03-07 01:28:31 <brent5001> do you know if upgrading from 0.5.1(non deterministic wallet) to 0.8 will cause excessive downtime?
89 2013-03-07 01:29:37 <Luke-Jr> brent5001: likely a few hours
90 2013-03-07 01:29:49 <Luke-Jr> also note 0.8 also has no deterministic wallet
91 2013-03-07 01:36:02 <BTC_Bear> Not sure why people 'want' deterministic wallets but meh...
92 2013-03-07 01:36:24 <gmaxwell> BTC_Bear: because maintaining backups takes work.
93 2013-03-07 01:36:27 <Luke-Jr> BTC_Bear: it makes wallets managable
94 2013-03-07 01:38:43 <brent5001> anyone know if 0.8 is compatible with debian 5?
95 2013-03-07 01:38:57 <jgarzik> brent5001: should be...
96 2013-03-07 01:43:42 <road33> are there good standard trading bots? I need something simple
97 2013-03-07 01:45:45 <jgarzik> road33: try #bitcoin-otc
98 2013-03-07 01:46:49 <road33> thanks
99 2013-03-07 02:20:15 <freewil> 0.8.x starts up so much quicker
100 2013-03-07 02:20:24 <freewil> used to have to wait like 2mins+ before the rpc became responsive
101 2013-03-07 03:18:27 <jaekwon> does bitcoin have a scalability problem?
102 2013-03-07 03:20:59 <hsmiths> bitcoin is holding up just fine. it is all the exchanges that are not scaling to match the volume.
103 2013-03-07 03:23:36 <Luke-Jr> jaekwon: eventually, yes
104 2013-03-07 03:25:16 <jaekwon> thanks hsmiths. also, why are there hours+ gaps in blockchain generation? i've seen two in two days now.
105 2013-03-07 03:29:51 <hsmiths> block generation is a random process. difficulty is set to make generation average out to 10 minutes each, but there will be variation -- some blocks are generated within seconds of the previous block, while others take many times the average. it is a normal distribution, and there will be points in the tails from time to time. also there is a pretty large change going on in the mining community with the roll
106 2013-03-07 03:29:51 <hsmiths> out of ASIC chips, so the current difficulty is probably not exactly righ to give the 10 minute block time.
107 2013-03-07 03:55:48 <dkog> Hi there. In theory is it possible to lose coins in a forever unconfirmed transaction? I sent over an hour ago, txn shows up in blockchain.info, but still has 0 confirmations... Am getting a bit concerned.
108 2013-03-07 03:57:11 <andytoshi> dkog: no, not possible, but bitcoind doesn't support you removing it from your local database
109 2013-03-07 03:57:24 <andytoshi> so you'll need some trickery to convince your client the money has not been spent
110 2013-03-07 03:57:33 <andytoshi> ...however, 1 hour is not cause for concern, only annoyance
111 2013-03-07 03:58:01 <weex> i learned last night that blockchain.info wallet can import an entire pywallet dump
112 2013-03-07 03:58:13 <dkog> andytoshi: OK that's good to know. I'm using standard bitcoin-qt. I had default 0 txn fee set, and didn't realize. Just bumped it up, but these coins be stuck :) At what point should I be more concerned?
113 2013-03-07 03:58:46 <andytoshi> 4-5 hours -- there are plenty of miners out there still who don't require fees
114 2013-03-07 04:00:31 <dkog> OK thank you. I bumped up my fee for the future anyway. Maybe the client should explain clearly about that it's defaulting to 0 fees and what the issues can be with that.
115 2013-03-07 04:01:52 <andytoshi> yeah, times are a-changing and i think bitcoin-qt needs some better facilities for this
116 2013-03-07 04:02:16 <andytoshi> it would also be nice if there was a "cancel transaction" feature that many miners would respect, after an hour or so
117 2013-03-07 04:02:25 <andytoshi> but it's not really clear what exactly to do
118 2013-03-07 04:04:59 <mogri> i wonder how abuse is for bitcoin-accepting it providers
119 2013-03-07 04:05:31 <gmaxwell> ::sigh::
120 2013-03-07 04:06:08 <gmaxwell> I'd say we should just ship it out with a non-zero default fee... but if we set it to 0.0001 that won't be enough to get in front of the flood of 0.001 fee txn.
121 2013-03-07 04:06:49 <gmaxwell> And if we set it to 0.001 then on a 100KB transaction it'll have 0.1 BTC fees, which is a bit extreme, esp since the 100KB ones are inevitably some fool sending 0.01 BTC with dust. :P
122 2013-03-07 04:07:37 <gmaxwell> it's really annoying that the bitcoinj txn just have a @#$@# constant fee instead of a size proportional one.
123 2013-03-07 04:08:10 <gmaxwell> as to keep up we'd need to put a constant fee in bitcoin-qt that makes no sense because miners prioritize on fee/kb.
124 2013-03-07 04:08:44 <mogri> andytoshi, i am not sure how 'cnacel transaction' could work, transactions are provably one-way due to the usage of merkel trees
125 2013-03-07 04:09:00 <dkog> Well I was suggesting to at least let the user make a choice. Currently you have to dig into preferences to even see or know anything about the fee. When you send your first txn and fee is still 0, it should just explain and give you a chance to set it yourself.
126 2013-03-07 04:09:21 <dkog> So you don't have to figure out the perfect fee, just help let people know about the option.
127 2013-03-07 04:09:29 <etotheipi_> why is it so hard to compute a *reasonable* fee
128 2013-03-07 04:09:31 <mogri> andytoshi, the only thing i can think of is maybe allowing a transaction to be aborted *before* the next block is mined, but past that, you can't go backwards
129 2013-03-07 04:09:40 <etotheipi_> my code for doing it in Armory is like 20 lines
130 2013-03-07 04:10:28 <gmaxwell> etotheipi_: what do you mean by reasonable?
131 2013-03-07 04:11:11 <etotheipi_> gmaxwell: basically applying allowFree logic, and doing 0.0005 BTC/kB above certain sizes
132 2013-03-07 04:11:37 <gmaxwell> etotheipi_: sure sure thats easy.
133 2013-03-07 04:11:58 <weex> it's really a market so if you want something robust it needs market info
134 2013-03-07 04:12:02 <andytoshi> mogri: you'd only be able to cancel unconfirmed transactions, of course
135 2013-03-07 04:12:15 <etotheipi_> gmaxwell: that's my point, why should bitcoinj use a an absolute fixed fee when that logic is so simple?
136 2013-03-07 04:12:20 <andytoshi> this feature would be very confusing and should be hidden unless you do a magic dance upon a "stuck" transaction
137 2013-03-07 04:12:36 <gmaxwell> etotheipi_: I dunno. :(
138 2013-03-07 04:20:25 <mogri> this seems like it would break satoshidice
139 2013-03-07 04:20:37 <mogri> otoh who cares about that :P
140 2013-03-07 04:21:40 <freewil> if anyone could update this for 0.8.0, it would be appreciated
141 2013-03-07 04:21:43 <freewil> https://en.bitcoin.it/wiki/Data_directory
142 2013-03-07 05:06:15 <muhoo> hmm just thinking, if tx fees are a "market" they fail pretty badly at being a market. how can you find out what the actual price is? how can you buy something if you don't know FOR SURE how much it'll cost before you buy?
143 2013-03-07 05:07:20 <muhoo> and, how can you buy something, if all you can do is try to buy, and have to keep re-trying it if it fails to make a sale, and there's no automated way to re-try buying it at a different price until you can buy one.
144 2013-03-07 05:08:12 <muhoo> it's more like a blind auction, really, than a market
145 2013-03-07 05:08:30 <muhoo> </rant>
146 2013-03-07 05:12:20 <freewil> i think the fees "market" is understood to be underdeveloped at this point
147 2013-03-07 05:12:22 <petertodd> muhoo: Do you know what gas will cost next weekend?
148 2013-03-07 05:12:46 <muhoo> i know what it will cost NOW
149 2013-03-07 05:12:56 <muhoo> and if i pull up to the pump, i know before i buy
150 2013-03-07 05:13:09 <muhoo> if i send a tx now, i have no real idea what is the "right" fee to get into a block
151 2013-03-07 05:13:41 <freewil> there arent any good tools i know of
152 2013-03-07 05:13:41 <petertodd> Sure, but you can get a very good estimate by looking at past blocks; unless you want exactly at the minimum margin you can have very good certainty.
153 2013-03-07 05:13:45 <muhoo> also, the price is posted on the pump.
154 2013-03-07 05:13:51 <petertodd> Besides, blocks themselves happen randomly.
155 2013-03-07 05:14:03 <petertodd> Who knows how long it'll take?
156 2013-03-07 05:14:16 <freewil> but you in theory should be able to figure out the right fee by analyzing the current pool of txs that havent made it into a block
157 2013-03-07 05:14:32 <petertodd> Sure, I wrote a tool that basically does that in just a few minutes today.
158 2013-03-07 05:14:39 <petertodd> (er, ok, 30 minutes)
159 2013-03-07 05:14:45 <muhoo> that'd be an improvement, towards being more like a market
160 2013-03-07 05:14:54 <muhoo> where you can at least check the bid/ask
161 2013-03-07 05:15:24 <muhoo> then if that could be worked into the client code, it could pick the fee based on that.
162 2013-03-07 05:15:48 <petertodd> Well, if miners behave rationally, it's really easy: sort all the transactions by fee per kb, and figure out what fee per kb is at the cut-off, and whatever margin you want.
163 2013-03-07 05:16:27 <muhoo> i think i'm safe in saying that humans are not rational :-) . but i get your point, it would be a useful way to approach it.
164 2013-03-07 05:16:45 <petertodd> Yup, I ran it a bunch of times and the threshold was pretty consistant.
165 2013-03-07 05:17:09 <petertodd> You know how to write python code to interface with the Bitcoin RPC?
166 2013-03-07 05:17:18 <muhoo> json-rpc? sure.
167 2013-03-07 05:17:30 <petertodd> Cool, now go write your own. :P
168 2013-03-07 05:17:32 <muhoo> python has to be the easiest jsonrpc (or xmlrpc) interface around.
169 2013-03-07 05:18:01 <petertodd> FWIW my one takes maybe a minute or two to analyze the whole mempool, but if you do some caching I'm sure you can do better.
170 2013-03-07 05:18:18 <petertodd> Bitcoin can add a "add/remove mempool tx" callback or something.
171 2013-03-07 05:18:20 <muhoo> heh, no open source for you!
172 2013-03-07 05:18:42 <petertodd> Heh, you can have a copy of mine if you really want.
173 2013-03-07 05:19:02 <muhoo> sure, just gist it somewhere
174 2013-03-07 05:19:47 <muhoo> i'd probably write something in clojure and integrate it with my app, but it'd be better to have it in java and integrated into bitcoinj for everyone, or in C++ and in bitcoind, etc.
175 2013-03-07 05:20:18 <muhoo> oh, wait. with an spv client, not so easy.
176 2013-03-07 05:20:58 <muhoo> i'll look at what bitcoinj has by way of mempool, if any.
177 2013-03-07 05:23:07 <petertodd> https://gist.github.com/petertodd/5105934
178 2013-03-07 05:23:37 <petertodd> You'll have to change it slightly for jgarzik's bitcoin rpc; I have it written to import my opentimestamps crap.
179 2013-03-07 05:23:54 <petertodd> And hexlify and unhexlify are python3 versions that accecpt strings.
180 2013-03-07 05:23:59 <petertodd> Minor things really.
181 2013-03-07 05:24:10 <jgarzik> petertodd: patches to python-bitcoinrpc welcome
182 2013-03-07 05:24:15 <petertodd> (actually, the code doesn't even use (un)hexlify so...)
183 2013-03-07 05:24:19 <jgarzik> petertodd: in particular, if you know Proper Python Packaging
184 2013-03-07 05:24:32 <jgarzik> setup.py distutils etc.
185 2013-03-07 05:24:34 <petertodd> jgarzik: Oh, I haven't actually changed your code, I was just being super lazy.
186 2013-03-07 05:24:45 <mogri> jgarzik, repository location ?
187 2013-03-07 05:24:45 <petertodd> jgarzik: But yes, that is on my todo list... ever growing todo list...
188 2013-03-07 05:24:51 <mogri> i'll package it for you
189 2013-03-07 05:25:15 <jgarzik> mogri: https://github.com/jgarzik/python-bitcoinrpc
190 2013-03-07 05:25:32 <jgarzik> mogri: and https://github.com/jgarzik/pynode/ too, if you are motivated
191 2013-03-07 05:25:40 <jgarzik> pynode's bitcoin/ sub-dir is really a library
192 2013-03-07 05:25:41 <petertodd> mogri: Cool! If you do that for ubuntu/debian I'll tip a bitcoin. (at reasonably close to current prices :P)
193 2013-03-07 05:26:10 <mogri> ok, give me a moment.
194 2013-03-07 05:26:24 <petertodd> mogri: Yeah, I really wanna see pynode's bitcoin separated out as it's own library.
195 2013-03-07 05:26:26 <gmaxwell> muhoo: thats how a real market works too. you put out your offer (a txn) and then people take the offers most attractive first. :P
196 2013-03-07 05:26:39 <muhoo> information though.
197 2013-03-07 05:26:49 <muhoo> that's why i said, like a blind, silent auction.
198 2013-03-07 05:27:24 <muhoo> if there were a way to retransmit the tx'es with increasing fees until one is accepted, then, yeah, i'd buy "market".
199 2013-03-07 05:27:32 <petertodd> muhoo: Commodities mostly get sold that way anyway - intermediaries repackage it up and take the price risk.
200 2013-03-07 05:30:10 <petertodd> mogri: Oh, just to be clear, that's a 1BTC for both python-bitcoinrpc and pynode
201 2013-03-07 05:30:42 <petertodd> mogri: Well, lets say 0.5BTC for the former, 1BTC for the latter with the separated out library.
202 2013-03-07 05:42:27 <jgarzik> mogri: merged
203 2013-03-07 05:42:58 <mogri> do you want to split out the bitcoin library in pynode to it's own repository?
204 2013-03-07 05:43:03 <Luke-Jr> ???
205 2013-03-07 05:43:11 <Luke-Jr> ACTION NACKs mogri?
206 2013-03-07 05:43:13 <mogri> (could use git submodule to bring it in that way)
207 2013-03-07 05:43:48 <petertodd> mogri: Personally, I would prefer that.
208 2013-03-07 05:43:53 <mogri> or do you just want setup.py support for it
209 2013-03-07 05:44:25 <mogri> for distribution packagers, it doesn't matter, as they can split it on the distro side obviously
210 2013-03-07 05:44:36 <Luke-Jr> jgarzik: could you revert that please? :/
211 2013-03-07 05:44:39 <petertodd> mogri: I think at this stage, it's in flux enough that using submodules or merged trees makes more sense for projects - pynode doesn't have versions.
212 2013-03-07 05:44:50 <petertodd> Luke-Jr: What's the NACK due to?
213 2013-03-07 05:45:16 <Luke-Jr> the entire point of the jsonrpc/ directory is to be a drop-in *replacement* for python-jsonrpc
214 2013-03-07 05:45:26 <Luke-Jr> without any software changes
215 2013-03-07 05:45:32 <mogri> that is a nono in python
216 2013-03-07 05:45:46 <petertodd> Luke-Jr: Yeah, I've seen that cause problems a few times already.
217 2013-03-07 05:45:55 <petertodd> Luke-Jr: It's not drop-in if it uses Decimal()...
218 2013-03-07 05:46:02 <Luke-Jr> petertodd: why not?
219 2013-03-07 05:46:11 <mogri> there was a shitstorm about that with simplejson for example
220 2013-03-07 05:46:25 <Luke-Jr> mogri: quite frankly I don't care about stupid "Python rules"
221 2013-03-07 05:46:35 <Luke-Jr> if you don't want a drop-in replacement, don't use the jsonrpc/ directory
222 2013-03-07 05:46:37 <petertodd> Luke-Jr: Different behavior; Gavin's coin control script doesn't work without Decimal() for instance.
223 2013-03-07 05:46:40 <Luke-Jr> the ONLY thing it does is provide compatibility
224 2013-03-07 05:46:49 <gmaxwell> whoa whoa, luke not arguing for pedantic correctness for once?
225 2013-03-07 05:47:04 <Luke-Jr> gmaxwell: Python's pedantics are all wrong
226 2013-03-07 05:47:34 <jgarzik> well
227 2013-03-07 05:47:50 <jgarzik> it is fair to say it breaks existing apps, that currently use python-bitcoinrpc
228 2013-03-07 05:48:04 <jgarzik> and have "from jsonrpc import"
229 2013-03-07 05:48:25 <Luke-Jr> jgarzik: the files in jsonrpc/ *only* create a compatibility interface - they do nothing else at all..
230 2013-03-07 05:48:36 <petertodd> jgarzik: Packaging becomes harder if we call it jsonrpc...
231 2013-03-07 05:48:40 <jgarzik> but I had hoped there was a stupid python namespace aliasing trick
232 2013-03-07 05:48:51 <mogri> there is :)
233 2013-03-07 05:48:51 <petertodd> jgarzik: ...and there isn't
234 2013-03-07 05:48:55 <Luke-Jr> petertodd: it's called bitcoinrpc though ;)
235 2013-03-07 05:48:58 <mogri> flask has one
236 2013-03-07 05:49:04 <mogri> i can write a stub
237 2013-03-07 05:49:12 <jgarzik> petertodd: <shrug> bitcoin.git/contrib/spendfrom/* shipped looking for 'jsonrpc'
238 2013-03-07 05:49:30 <petertodd> jgarzik: Yes, and it doesn't work on my system because it does that...
239 2013-03-07 05:49:33 <Luke-Jr> hmm, everything is in the directory? /me reviews
240 2013-03-07 05:49:37 <petertodd> jgarzik: It expects Decimals
241 2013-03-07 05:50:17 <jgarzik> petertodd: you have the regular, crappy jsonrpc module on your system, you are saying?
242 2013-03-07 05:50:36 <petertodd> jgarzik: Yes, which gives floats, which is compatible with *other* software.
243 2013-03-07 05:52:54 <Luke-Jr> afaik you can use floats and Decimal interchangable in Python, for many/most use cases
244 2013-03-07 05:53:34 <petertodd> Luke-Jr: Emphasis most...
245 2013-03-07 05:53:48 <mogri> i'll have another pull adding a stub in a second.
246 2013-03-07 05:53:55 <jgarzik> I propose a cage-match between all present
247 2013-03-07 05:54:08 <jgarzik> because I'm not very pythonic.
248 2013-03-07 05:54:11 <Luke-Jr> mogri: it *was* a stub
249 2013-03-07 05:54:21 <petertodd> jgarzik: Finally some sanity in the room...
250 2013-03-07 05:54:27 <Luke-Jr> authproxy.py is the only *real* bitcoinrpc file, and doesn't exist in jsonrpc
251 2013-03-07 05:54:33 <Luke-Jr> the other .py files were stubs for compatibility
252 2013-03-07 05:56:31 <petertodd> Luke-Jr: Alright, compromise: make bitcoinrpc bitcoinrpc specific and do smart things like convert hex/bytes etc.
253 2013-03-07 05:56:44 <petertodd> Luke-Jr: (or maybe by that I mean, bikeshed further)
254 2013-03-07 05:56:56 <Luke-Jr> petertodd: ???
255 2013-03-07 05:57:40 <Luke-Jr> the only things bitcoinrpc does differently are use Decimal by default and use the native json module for JSON parsing.. nothing fancy/incompatible
256 2013-03-07 05:58:04 <petertodd> Luke-Jr: grr, using Decimal is very incompatible...
257 2013-03-07 05:58:13 <Luke-Jr> not for most applications
258 2013-03-07 05:58:19 <petertodd> *most* is not good enough
259 2013-03-07 05:58:24 <Luke-Jr> what can floats do that decimal cannot?
260 2013-03-07 05:58:28 <petertodd> Packaging it named jsonrpc will break stuff, end of story.
261 2013-03-07 05:58:31 <Luke-Jr> yes it is..
262 2013-03-07 05:58:45 <Luke-Jr> so package it named bitcoinrpc; package != module
263 2013-03-07 05:58:51 <petertodd> Luke-Jr: For one thing, floats aren't IsInstance(float)...
264 2013-03-07 05:58:53 <doublec> I got a std::bad_alloc thrown running 0.8 while downloading the blockchain
265 2013-03-07 05:59:03 <petertodd> Luke-Jr: Like it or not, there is code that does that...
266 2013-03-07 05:59:16 <doublec> oh probably ran out of ram
267 2013-03-07 05:59:44 <Luke-Jr> petertodd: then that software can depend on the jsonrpc package instead of the bitcoinrpc-jsonrpc-compat package
268 2013-03-07 06:00:19 <petertodd> Luke-Jr: Right, and that's not the way python namespaces work. When I type "import jsonrpc" in python, I expect the system jsonrpc without any fuss.
269 2013-03-07 06:00:28 <petertodd> Luke-Jr: Work with python
270 2013-03-07 06:00:51 <Luke-Jr> petertodd: system jsonrpc could be either; if you need a specific one, depend on it in your package
271 2013-03-07 06:01:25 <petertodd> Luke-Jr: As I say, that's not the sane way to do things. If I run a script I grabbed from someone, I expect system jsonrpc to be standard jsonrpc, end of story.
272 2013-03-07 06:01:29 <Luke-Jr> yes it is
273 2013-03-07 06:02:02 <petertodd> Luke-Jr: So if you now make me add a bunch of Python path crap, just so I can use your Bitcoin but nearly, but not quite compatible jsonrpc, that's a fail.
274 2013-03-07 06:02:17 <jgarzik> pkg A provides "foo" and pkg B provides "foo" is a common concept in RPM land
275 2013-03-07 06:02:23 <jgarzik> where A conflicts with B
276 2013-03-07 06:02:31 <jgarzik> probably not helpful if you need both
277 2013-03-07 06:02:39 <Luke-Jr> jgarzik: also in Debian and Gentoo
278 2013-03-07 06:02:39 <petertodd> jgarzik: So what? That's not how Python is done.
279 2013-03-07 06:03:08 <Luke-Jr> petertodd: Python is just a programming language. It doesn't get to redefine what is reasonable and sane.
280 2013-03-07 06:03:29 <jgarzik> The main questions are, what do bitcoin users need now and in the future? Is there a huge value in appearing as 'jsonrpc'?
281 2013-03-07 06:03:29 <petertodd> Luke-Jr: python-bitcoinrpc is just some library, it doesn't get to redefine what the whole Python ecosystem does.
282 2013-03-07 06:03:37 <petertodd> jgarzik: Fuck no...
283 2013-03-07 06:03:39 <Luke-Jr> jgarzik: yes
284 2013-03-07 06:03:52 <Luke-Jr> petertodd: I don't recognize a "Python ecosystem"
285 2013-03-07 06:03:58 <jgarzik> packaging as 'bitcoinrpc' may get us in distros, and thus be the most widely accepted version
286 2013-03-07 06:04:02 <petertodd> jgarzik: Note how I import python-bitcoinrpc in my script
287 2013-03-07 06:04:07 <mogri> hmm...
288 2013-03-07 06:04:10 <petertodd> jgarzik: Yes!
289 2013-03-07 06:04:14 <mogri> this jsonrpc stub isn't gonna work
290 2013-03-07 06:04:24 <mogri> cause it doesn't seem to work with 'from jsonrpc import ...'
291 2013-03-07 06:04:36 <petertodd> jmogri: ...and I'm paying a bounty for a distro-possible thing. :P
292 2013-03-07 06:04:43 <Luke-Jr> mogri: you're reinventing the wheel. everything except authproxy.py was ALREADY a stub
293 2013-03-07 06:04:57 <jgarzik> that is a fair point, though
294 2013-03-07 06:05:09 <Luke-Jr> there are 3 use cases:
295 2013-03-07 06:05:16 <Luke-Jr> 1. application doesn't care
296 2013-03-07 06:05:19 <petertodd> jgarzik: Then don't use bitcoinrpc at all and make some really minor thing, or whatever.
297 2013-03-07 06:05:24 <Luke-Jr> 2. application only works with original jsonrpc
298 2013-03-07 06:05:30 <Luke-Jr> 3. application only works with bitcoinrpc
299 2013-03-07 06:05:32 <petertodd> jgarzik: IMO stubs are fine if they add a bit of value.
300 2013-03-07 06:05:57 <petertodd> jgarzik: Again, I'd kinda like to see a bitcoinrpc that was a bit more sophisticated and did some useful conversions, but that leads down bikeshedding...
301 2013-03-07 06:06:00 <jgarzik> the fair point being the stubs are largely useless as named 'bitcoinrpc'
302 2013-03-07 06:06:01 <freewil> what datafiles in 0.8.x should be distributed with a testnet box... here is from 0.7.2... https://github.com/freewil/bitcoin-testnet-box/tree/master/1/testnet3
303 2013-03-07 06:06:08 <jgarzik> possible solution being deletion ;p
304 2013-03-07 06:07:27 <mogri> Luke-Jr, then the changes should be reverted, and authproxy.py should be separated from jsonrpc module
305 2013-03-07 06:07:58 <Luke-Jr> mogri: I'm okay with that, but I don't see the point in moving anything
306 2013-03-07 06:08:01 <Luke-Jr> authproxy.py has no conflicts
307 2013-03-07 06:09:08 <mogri> Luke-Jr, what i am saying is that authproxy.py should not be in jsonrpc module, it should be separate, e.g. bitcoinrpc.authproxy
308 2013-03-07 06:09:28 <Luke-Jr> mogri: right, I'm saying: why bother?
309 2013-03-07 06:10:02 <mogri> because stomping ontop of jsonrpc namespace makes python-bitcoinrpc unpackageable (doubly so in terms of inclusion in distributions)
310 2013-03-07 06:10:19 <Luke-Jr> original jsonrpc doesn't have an authproxy
311 2013-03-07 06:10:27 <mogri> that's not the point
312 2013-03-07 06:10:36 <mogri> the point is, it may in the future
313 2013-03-07 06:11:09 <mogri> you're shoving it in a namespace that is not yours
314 2013-03-07 06:11:24 <mogri> thusly, you're at the mercy of upstream jsonrpc author
315 2013-03-07 06:12:06 <Luke-Jr> meh, my code all uses the stubs, so I don't care to argue it beyond that
316 2013-03-07 06:13:12 <freewil> can anyone tell me what datadir/blocks/rev*.dat is for?
317 2013-03-07 06:13:43 <freewil> im guessing it might have something to do with a new best chain
318 2013-03-07 06:13:52 <mogri> if the goal is to get bitcoinrpc module packaged into distributions, at least authproxy.py should be divorced. a stub can be added to provide backwards compatibility for those using the bundled stubs module (this wouldn't be installed by setup.py obviously :))
319 2013-03-07 06:14:57 <mogri> would you be ok with that refactoring?
320 2013-03-07 06:15:02 <Luke-Jr> mogri: fine
321 2013-03-07 06:15:30 <Luke-Jr> please be sure not to break Python 3 compat either..
322 2013-03-07 06:15:37 <mogri> alright, i will do it. give me a moment.
323 2013-03-07 06:15:50 <mogri> yes, of course.
324 2013-03-07 06:15:57 <petertodd> Luke-Jr: re: Python 3, finally something luke and I can agree on. :P
325 2013-03-07 06:16:07 <gmaxwell> freewil: its the data requred in addition to the blocks needed to roll back applying a block to the coins database.
326 2013-03-07 06:16:14 <gmaxwell> freewil: 'undo files'
327 2013-03-07 06:16:39 <freewil> gmaxwell, ok im trying to figure out how to update the testnet box
328 2013-03-07 06:16:47 <freewil> looks like i need to add blocks/blk*.dat
329 2013-03-07 06:16:53 <freewil> anything else?
330 2013-03-07 06:16:56 <freewil> chainstate/?
331 2013-03-07 06:17:11 <Luke-Jr> petertodd: I only work with Python 3 anymore :P
332 2013-03-07 06:17:18 <Luke-Jr> (as far as Python goes)
333 2013-03-07 06:17:24 <gmaxwell> freewil: everything.
334 2013-03-07 06:17:36 <petertodd> Luke-Jr: OpenTimestamps is all Py3... I just want to see a Py3 protobuf
335 2013-03-07 06:17:50 <freewil> gmaxwell, well i dont want junk like peers.dat, here it is from 0.7.2... https://github.com/freewil/bitcoin-testnet-box/tree/master/1/testnet3
336 2013-03-07 06:18:54 <Luke-Jr> ACTION hides in shame of not following along well enough to have the foggiest idea what OT actually is :P
337 2013-03-07 06:19:19 <petertodd> ACTION hides in shame because no-one knows what his pet project is.
338 2013-03-07 06:20:56 <warren> petertodd: ooh, sounds interesting, is code up?
339 2013-03-07 06:21:05 <warren> petertodd: I've been meaning on working on timestamping this summer
340 2013-03-07 06:21:24 <petertodd> https://github.com/opentimestamps/opentimestamps-client
341 2013-03-07 06:21:30 <petertodd> My server should be working too
342 2013-03-07 06:21:57 <petertodd> (someone donated 5BTC for me to turn it back on - they said they were using unspendable TX outs for timestamping...)
343 2013-03-07 06:22:02 <warren> Does this work anything like chronobit?
344 2013-03-07 06:22:12 <warren> oh
345 2013-03-07 06:22:49 <petertodd> 7ec2ef87856a2fb1fe0ff075f678d7fcbfa2d182adc888a41e1f65ca48fbedba <- example transaction
346 2013-03-07 06:22:50 <warren> petertodd: I was thinking about blockchain inclusion solutions for timestamping, but gmaxwell whacked me hard
347 2013-03-07 06:23:05 <petertodd> It's a super general "proof by hash chain" thing
348 2013-03-07 06:23:17 <petertodd> gmaxwell didn't whack me hard enough apparently
349 2013-03-07 06:23:34 <petertodd> Being server based it's an O(small ish hopefully) solution
350 2013-03-07 06:23:52 <petertodd> It can do coinbase timestamping without changing the client code
351 2013-03-07 06:24:01 <petertodd> (well, almost, I need to write SHA256 midstate support)
352 2013-03-07 06:24:18 <Luke-Jr> petertodd: merge-mine compatible?
353 2013-03-07 06:24:45 <petertodd> Luke-Jr: Yup, from the client's point of view, proofs are just a set of instructions that somehow turn some data into a digest that it knows how to verify.
354 2013-03-07 06:24:52 <petertodd> Luke-Jr: Fundementally it's not even Bitcoin specific.
355 2013-03-07 06:24:54 <mogri> secondary pull-request submitted
356 2013-03-07 06:25:23 <petertodd> Luke-Jr: https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/opentimestamps-client-v0.1.ots is an example timestamp
357 2013-03-07 06:25:28 <mogri> it puts jsonrpc stubs back where they are and adds another for jsonrpc.authproxy (so importing that still works if you're using the old way of just ganking the code)
358 2013-03-07 06:26:38 <warren> petertodd: does this solution require a miner to merge your input?
359 2013-03-07 06:26:54 <warren> (like chronobit)
360 2013-03-07 06:27:01 <petertodd> warren: Require, no, but if you want to use it that way you can.
361 2013-03-07 06:27:01 <warren> or are timestamps in unspendable tx's
362 2013-03-07 06:27:16 <petertodd> warren: Well, what I've implemented right now is they're done with bare multisig tx's
363 2013-03-07 06:27:21 <petertodd> warren: Did you see my example tx?
364 2013-03-07 06:27:56 <warren> http://blockchain.info/tx-index/58864627/7ec2ef87856a2fb1fe0ff075f678d7fcbfa2d182adc888a41e1f65ca48fbedba blockchain considers this an escrow ...
365 2013-03-07 06:28:30 <Luke-Jr> warren: trying to learn bitcoin from blockchain.info is a bad idea
366 2013-03-07 06:28:43 <petertodd> Yup, 1 of 2 multisig, the first key is real, the second is the digest that's the head of the merkle tree of digests being timestamped.
367 2013-03-07 06:28:52 <mogri> Luke-Jr, is the pull-request i just submitted ok with you?
368 2013-03-07 06:29:11 <Luke-Jr> mogri: looks okay, but I'm not really setup to test it until it's merged
369 2013-03-07 06:29:12 <jgarzik> petertodd: interesting (re second)
370 2013-03-07 06:30:06 <Luke-Jr> mogri: then I have to update the package ;)
371 2013-03-07 06:30:08 <petertodd> jgarzik: Yeah, because it's prepending with a zero byte, it's totally invalid, but Bitcoin currently accepts it. I also wrote code that forces it to be a valid pubkey, but for now ensuring it's invalid is safer I think.
372 2013-03-07 06:30:23 <warren> Luke-Jr: yeah, I need to learn how to read it from RPC
373 2013-03-07 06:31:07 <warren> petertodd: looked at chronobit?
374 2013-03-07 06:31:08 <jgarzik> petertodd: er, eh? multisig requires a prepend due to bug I thought
375 2013-03-07 06:31:37 <jgarzik> CScript result;
376 2013-03-07 06:31:37 <jgarzik> result << OP_0; // CHECKMULTISIG bug workaround
377 2013-03-07 06:31:37 <Luke-Jr> jgarzik: to spend
378 2013-03-07 06:31:50 <petertodd> jgarzik: No, I mean the pubkey itself. IE, I have a 32 byte digest, and I pre-pend it with 0x00 to ensure OpenSSL considers it invalid under any circumstance.
379 2013-03-07 06:32:06 <jgarzik> ah, understood
380 2013-03-07 06:32:08 <petertodd> warren: YES I HAVE FUCKING LOOKED AT CHRONOBIT
381 2013-03-07 06:32:15 <petertodd> warren: Sorry, the millionth time I've been asked this. :P
382 2013-03-07 06:32:20 <warren> ah, sorry.
383 2013-03-07 06:32:33 <Luke-Jr> LOL
384 2013-03-07 06:32:50 <petertodd> I need to start claiming I actually wrote chronobit...
385 2013-03-07 06:32:54 <warren> petertodd: I've been thinking about making a server frontend for the public to timestamp anything, and I push it through p2pool for them.
386 2013-03-07 06:33:20 <petertodd> warren: Get forrestv to make the p2pool blockchain non-linear so the proofs are small and you can do that with OpenTimestamps
387 2013-03-07 06:33:20 <warren> Doesn't spam the blockchain at all.
388 2013-03-07 06:33:34 <Luke-Jr> warren: would be nice if someone made a pool-independent version
389 2013-03-07 06:34:19 <petertodd> warren: Do that and I'll totally merge your changes.
390 2013-03-07 06:34:21 <warren> Luke-Jr: technically the input can be included in any pool, but I'd need to convince pool operators to use it, and I've been told "good luck" in convincing pool operators.
391 2013-03-07 06:34:30 <Luke-Jr> warren: O.o
392 2013-03-07 06:34:31 <petertodd> warren: Dunno if you looked, but there is also an opentimestamps-server package...
393 2013-03-07 06:34:51 <Luke-Jr> warren: you can basically consider it a given I can get Eligius to do anything useful :p
394 2013-03-07 06:35:59 <mogri> jgarzik, anyway i sent you mroe patches which probably will make Luke-Jr happy ;p
395 2013-03-07 06:36:03 <petertodd> warren: Luke offered ages ago to do coinbase timestamping, but I realized the idea would never catch on if it took a day to get a timestamp
396 2013-03-07 06:36:10 <warren> petertodd: I'll look into this in the next few months
397 2013-03-07 06:36:21 <warren> petertodd: yeah, that's my concern as well
398 2013-03-07 06:36:26 <jgarzik> mogri: just merged, maybe luke-jr is happy
399 2013-03-07 06:36:41 <Luke-Jr> why not? timestamping taking a day, I don't see a huge barrier to adoption???
400 2013-03-07 06:36:47 <jgarzik> but is petertodd sad? and has he looked into chronobit? the world wants to know.
401 2013-03-07 06:37:07 <petertodd> warren: Hence my approach of "make it stupidly general" so timestamping servers can work together to get timestamps into the blockchain the fastest and cheapest way possible.
402 2013-03-07 06:37:43 <warren> Luke-Jr: from a usability POV, people want to timestamp NOW and not think about it. chronobit requires you to wait for the fragment to complete, which can take hours, before you save it as a proof.
403 2013-03-07 06:37:57 <warren> petertodd: ahh
404 2013-03-07 06:38:00 <petertodd> Yes! It's already awful UI that you even have to do anything twice.
405 2013-03-07 06:38:29 <warren> petertodd: I was considering an intermediate token that they save instantly, that can be redeemed later for the permanent fragment.
406 2013-03-07 06:38:34 <petertodd> Fuck, I'm considering running server's that'll do a top-level archived calendar thing that happens every 1 second or something and publish the whole archive, + bitcoin timestamps, publicly.
407 2013-03-07 06:39:04 <Luke-Jr> bleh, bitcoinrpc still making trouble
408 2013-03-07 06:39:13 <petertodd> Basically collect every timestamp that happens in a one second interval, turn it into a digest, and archive those digests.
409 2013-03-07 06:39:14 <Luke-Jr> ImportError: No module named bitcoinrpc.authproxy
410 2013-03-07 06:39:27 <jgarzik> mogri: ^
411 2013-03-07 06:39:38 <Luke-Jr> need to add a new symlink <.<
412 2013-03-07 06:39:38 <petertodd> 32bytes/second * 1year = 1GB
413 2013-03-07 06:39:52 <mogri> hmm ?
414 2013-03-07 06:40:06 <warren> petertodd: I thought about that too, ideally we want a solution that requires the timestamp service operators to not store anything, it's up to the user to store their own proof.
415 2013-03-07 06:40:08 <mogri> what are you doing exactly
416 2013-03-07 06:40:13 <warren> petertodd: but the wait time really sucks
417 2013-03-07 06:40:22 <Luke-Jr> mogri: current installs of Eloipool often do: git clone python-bitcoinrpc; ln -s python-bitcoinrpc/jsonrpc .
418 2013-03-07 06:40:28 <petertodd> warren: Yeah, compromise between usability and centralization.
419 2013-03-07 06:40:43 <petertodd> warren: But timestamping doesn't have the nasty incentives money does, so a bit of centralization is probably acceptable.
420 2013-03-07 06:40:46 <mogri> oh, well
421 2013-03-07 06:40:51 <mogri> i can't work magic for that :(
422 2013-03-07 06:41:00 <Luke-Jr> >_<
423 2013-03-07 06:41:44 <warren> petertodd: what % of pool mining power can we convince to participate?
424 2013-03-07 06:41:52 <warren> petertodd: the turnaround time matters a lot to our design
425 2013-03-07 06:42:18 <warren> petertodd: there's stupidly simple ways of getting the input to miners, it doens't have to be secure at all
426 2013-03-07 06:42:21 <warren> petertodd: like DNS
427 2013-03-07 06:42:40 <warren> petertodd: would benefit from caching
428 2013-03-07 06:43:06 <petertodd> warren: Yup, merkle timestamping is stupidly scalable - that's why I wrote it in Python.
429 2013-03-07 06:43:40 <petertodd> warren: re: turnaround time, the ugly bit is a trust-free way of having P2P merkle chain building, but the second you add any trsut to the system it becomes really easy.
430 2013-03-07 06:44:05 <warren> If we make it simple and robust, I'd even suggest it for inclusion in the standard bitcoind. Non-blocking DNS lookup, OK if it fails.
431 2013-03-07 06:44:55 <Luke-Jr> warren: er, how would that even work?
432 2013-03-07 06:45:22 <Luke-Jr> I mean, it doesn't make sense involving bitcoind
433 2013-03-07 06:45:26 <petertodd> Luke-Jr: DNS with really short expiry time may actually work.
434 2013-03-07 06:45:33 <petertodd> and yeah, it's not a bitcoind thing
435 2013-03-07 06:45:39 <warren> I haven't figured that out yet, and it's possible I misunderstood chronobit. I'll study this in May.
436 2013-03-07 06:45:44 <warren> oh right
437 2013-03-07 06:45:46 <warren> sorry
438 2013-03-07 06:46:00 <mogri> Luke-Jr, i will think on a solution. perhaps 'jsonrpc.bitcoinrpc.*' could be workable as a namespace.
439 2013-03-07 06:46:12 <warren> petertodd: my point is it wouldn't hurt to make it easy for all miners to do it
440 2013-03-07 06:46:13 <mogri> ACTION zzz
441 2013-03-07 06:46:25 <petertodd> warren: Absolutely
442 2013-03-07 06:46:54 <petertodd> warren: Needs to be something they can setup trivially, and that a timestamp server can figure out what digests actually got into blocks basically.
443 2013-03-07 06:47:01 <warren> petertodd: you're thinking a p2p chain for the digests?
444 2013-03-07 06:47:04 <petertodd> Just keep a temp database of digests sent to the pool ops and you'll be good.
445 2013-03-07 06:47:05 <mogri> i don't really like that though, i think it would be better just to bite the bullet and install a secondary symlink
446 2013-03-07 06:47:26 <petertodd> warren: Nah, I figure that's heavier weight than you actually need - get a simple centralized system working first.
447 2013-03-07 06:47:29 <mogri> (or just fix the code to not use the jsonrpc stubs, that works too.)
448 2013-03-07 06:47:44 <petertodd> warren: As I say, there isn't much incentive to attack timestamping like there is money.
449 2013-03-07 06:47:45 <mogri> plus, it's needed if they want to get it packaged in a distro anyway
450 2013-03-07 06:47:49 <Luke-Jr> mogri: I don't really like breaking compatibility with existing deployments :p
451 2013-03-07 06:48:13 <mogri> needing a symlink is a minor break
452 2013-03-07 06:48:15 <warren> petertodd: I think this as a service can't pay for itself, it seems like an ideal "public service" from the Foundation.
453 2013-03-07 06:48:21 <mogri> it still allows having broken code :P
454 2013-03-07 06:48:28 <Luke-Jr> mogri: as jgarzik pointed out, distros already handle shared APIs just fine
455 2013-03-07 06:48:42 <petertodd> warren: Oh for sure
456 2013-03-07 06:48:51 <mogri> APIs yes
457 2013-03-07 06:48:55 <warren> petertodd: some industries will have use for timestamping of hundreds or thousands of things an hour, eventually we'll want a daemon anyone can run.
458 2013-03-07 06:48:58 <mogri> but, this is not shared API
459 2013-03-07 06:49:02 <Luke-Jr> yes it is
460 2013-03-07 06:49:08 <mogri> this is like
461 2013-03-07 06:49:11 <mogri> two packages installing /bin/ls
462 2013-03-07 06:49:14 <mogri> :p
463 2013-03-07 06:49:23 <Luke-Jr> that's a shared API
464 2013-03-07 06:49:32 <petertodd> warren: And the thing is, that's actually already true, timestamping services make boatloads of money, but what you have to understand, is they aren't selling technology, they're selling lawyers.
465 2013-03-07 06:49:33 <mogri> night
466 2013-03-07 06:49:44 <petertodd> mogri: pete@petertodd.org <- email me your btc addr
467 2013-03-07 06:49:50 <mogri> jsonrpc.bitcoinrpc is a possible solution
468 2013-03-07 06:49:58 <mogri> that gives us isolating our stuff
469 2013-03-07 06:50:00 <mogri> from jsonrpc.*
470 2013-03-07 06:50:05 <mogri> which we want that
471 2013-03-07 06:50:20 <warren> petertodd: the part that makes money is integration in tools and services used by particular industries
472 2013-03-07 06:51:14 <petertodd> warren: Well, long story short, UI design is the hard part. I quite seriously was looking into doing OpenTimestamps as a masters thesis project at an art and design school.
473 2013-03-07 06:51:27 <warren> petertodd: so ... end-users get an instant token that they can later compare to the centrally stored permanent digests?
474 2013-03-07 06:51:48 <petertodd> warren: Not a token, a merkle path to the centrally stored digests.
475 2013-03-07 06:52:05 <warren> well, something they save locally
476 2013-03-07 06:52:08 <warren> instantly
477 2013-03-07 06:52:12 <petertodd> yeah
478 2013-03-07 06:52:13 <warren> doesn't matter what i tis
479 2013-03-07 06:52:40 <warren> how quickly will the digests grow?
480 2013-03-07 06:52:58 <petertodd> You mean the proofs?
481 2013-03-07 06:53:07 <warren> yes
482 2013-03-07 06:53:24 <petertodd> Work it out - educational.
483 2013-03-07 06:53:53 <warren> so you really want to solve the turnaround problem with this...
484 2013-03-07 06:53:56 <warren> I had given up on that.
485 2013-03-07 06:54:04 <mogri> petertodd, 1B9J3NsRmajwXcLLXWJA9tH4suqhkJLHo4
486 2013-03-07 06:54:16 <petertodd> mogri: email me so I don't forget...
487 2013-03-07 06:54:20 <mogri> oh, ok.
488 2013-03-07 06:54:29 <petertodd> mogri: I wanan try it first
489 2013-03-07 06:55:17 <warren> petertodd: I was planning on saving only enough data to allow someone to later use their instant-saved token to retrieve their own fragment. I wouldn't store their proofs.
490 2013-03-07 06:55:19 <mogri> petertodd, yeah, sure :)
491 2013-03-07 06:55:30 <mogri> petertodd, i need to do pynode too still
492 2013-03-07 06:55:39 <petertodd> mogri: yeah
493 2013-03-07 06:55:41 <mogri> petertodd, and add debian/rules files to them
494 2013-03-07 06:55:49 <petertodd> mogri: yup, rules too
495 2013-03-07 06:55:51 <mogri> i'll work at it tomorrow
496 2013-03-07 06:55:57 <petertodd> mogri: thanks a lot!
497 2013-03-07 06:56:30 <petertodd> warren: Your homework: figure out why that won't work. (or will)
498 2013-03-07 06:57:20 <warren> I'll be back on this topic.
499 2013-03-07 06:57:53 <mogri> either way, clean integration of bitcoin and python is a direct goal of mine (and where i work)
500 2013-03-07 06:58:22 <mogri> so any way to enhance that is interesting to me :)
501 2013-03-07 06:58:28 <mogri> night for real now :)
502 2013-03-07 06:58:31 <petertodd> warren: Here, you see the example OpenTimestamps proof I posted, and have in the repo? Verify it by hand and get back to me.
503 2013-03-07 07:39:42 <jgarzik> petertodd: the use of invalid pubkeys was one reason why I suggested OP_DROP
504 2013-03-07 07:46:46 <petertodd> jgarzik: I know, I suggested the idea in that conversation actually...
505 2013-03-07 07:47:07 <jgarzik> it's been known for ages
506 2013-03-07 07:47:09 <petertodd> jgarzik: You can force them to be valid, but at least for hashes it's still pretty trivial to force them to be valid keys.
507 2013-03-07 07:47:21 <jgarzik> it is a Hope Somebody Doesn't Do This On A Large Scale thing
508 2013-03-07 07:47:38 <jgarzik> ;p
509 2013-03-07 07:47:46 <petertodd> Well, I alway see tx fees as the solution to the pollution problem.
510 2013-03-07 07:48:09 <petertodd> You fundementally can't stop people from putting data in the chain in some fashion, only make it expensive and inconvenient.
511 2013-03-07 07:53:42 <jgarzik> petertodd: yep
512 2013-03-07 07:53:50 <jgarzik> *zonk*
513 2013-03-07 08:31:40 <jaromil> g'moin. my connection went down yesterday a short while after posing my question, will appreciate if someone can past me any other reply in private, thanks
514 2013-03-07 08:31:59 <jaromil> are there irc channel archives?
515 2013-03-07 08:51:03 <Graet> Channel logs: bit.ly/iPFi3X from topic jaromil
516 2013-03-07 08:53:08 <grazs> do you know where I can get historical data for a btcexchange like mtgox? I figured I'd ask here, it's for training a trading bot.
517 2013-03-07 08:57:08 <freewil> am i reading this right... the 'help' rpc command requires an unlocked wallet? https://github.com/bitcoin/bitcoin/blob/master/src/bitcoinrpc.cpp#L199
518 2013-03-07 08:58:27 <Luke-Jr> freewil: no
519 2013-03-07 08:58:43 <Luke-Jr> freewil: unlocked refers to whether it's threadsafe or not
520 2013-03-07 08:58:46 <freewil> oh
521 2013-03-07 08:58:51 <Luke-Jr> or whether it needs to lock the mutexes
522 2013-03-07 08:59:08 <freewil> ok thanks
523 2013-03-07 08:59:41 <freewil> btw theres a typo there on line 197 - i think it should be 'safecmd'
524 2013-03-07 09:01:52 <grazs> I found the historic converstion prices at http://bitcoin.stackexchange.com/questions/4799/need-authoritative-source-for-historic-bitcoin-conversion-prices-from-all-exchan
525 2013-03-07 09:02:09 <freewil> im going to submit a PR for that
526 2013-03-07 10:04:31 <ItsDom> approximately how many entries to a typical satoshi clients list of known nodes have in it? (So known nodes not necessarily connected)
527 2013-03-07 10:05:43 <ciphermonk> They there. Is there a relationship between transaction outputs in your wallet and accounts? I can't seem to find a mapping between outputs => addresses => accounts when I start moving coins around using RPC "move" command
528 2013-03-07 10:07:20 <Luke-Jr> ciphermonk: no
529 2013-03-07 10:07:26 <Luke-Jr> ciphermonk: accounts are just numbers
530 2013-03-07 10:08:51 <ciphermonk> oh ok, so outputs to not "belong" to accounts. I see :) thanks
531 2013-03-07 10:09:58 <ciphermonk> I was trying to get account outputs using "getaddressesbyaccount" and feeding the account list to "listunspent"
532 2013-03-07 10:10:47 <Luke-Jr> right
533 2013-03-07 10:11:04 <Luke-Jr> addresses are associated with accounts only so it knows which one to increment when receiving
534 2013-03-07 10:11:27 <ciphermonk> oh fair enough, ok
535 2013-03-07 10:13:16 <sipa> ItsDom: up to 16000 or so
536 2013-03-07 10:14:33 <ItsDom> sipa: cheers. is there actually a limit imposed? or do they just try and store everyone they learn about?
537 2013-03-07 10:19:01 <sipa> ItsDom: there are almost half a million ip addresses circulating
538 2013-03-07 10:19:09 <sipa> ItsDom: so yes, there is a limit
539 2013-03-07 10:21:37 <ItsDom> So what is the point of storing 16k? Do they all get used when sending a transaction, or does it just send to connected peers (of which, I've heard, there are normally about 5 - 15)
540 2013-03-07 10:22:02 <ItsDom> sipa: thanks for the help btw, muchly appreciated:)
541 2013-03-07 10:23:10 <Luke-Jr> petertodd: your email presumes censorship is a bad thing
542 2013-03-07 10:23:38 <petertodd> Luke-Jr: I'm happy with people chosing what transactions they want to mine, I'm not happy with a wholesale ban.
543 2013-03-07 10:23:50 <petertodd> I know you're thinking of satoshidice, but such censorship could go way farther than that.
544 2013-03-07 10:24:41 <Luke-Jr> petertodd: wholesale ban would require miners to be of one mind, so I think in such a case censorship is most likely correct?
545 2013-03-07 10:24:58 <sipa> ItsDom: tead the commemts in addrman.cpp or addrman.h
546 2013-03-07 10:25:33 <petertodd> Remember, that's in reference to large blocks, where you could easily wind up with just a dozen mining pools, and barriers to entry high enough that adding an additional mining pool will cost you thousands, and isn't possible anonymously anyway,
547 2013-03-07 10:25:45 <ItsDom> sipa: will do, cheers.
548 2013-03-07 10:25:45 <sipa> ItsDom: andnof coursenyounjust send to connected peers- hard to send to non-connected ones :)
549 2013-03-07 10:25:57 <sipa> ItsDom: theybforward it to tjeir peers and so on
550 2013-03-07 10:26:27 <ItsDom> sipa: lol, i was more suggesting when a transaction is sent, does it open more connections to known peers to broadcast better. But I'll take a browse at the comments:)
551 2013-03-07 10:26:44 <sipa> no, never more than 8 outgoing connections
552 2013-03-07 10:26:57 <sipa> connectable peers are a scarce resource
553 2013-03-07 10:27:13 <sipa> there is no need to try to connect to as many as possible
554 2013-03-07 10:27:48 <Luke-Jr> petertodd: well, hopefully those are GBT-enabled mining pools that allow miners to select transactions ;)
555 2013-03-07 10:28:16 <petertodd> Luke-Jr: Doesn't matter. You can't force the pool to accept your shares if you do that, thus you're mining solo.
556 2013-03-07 10:28:50 <ItsDom> sipa: okay, thanks:)
557 2013-03-07 10:29:17 <petertodd> Luke-Jr: Besides, if such centralization happens, what makes you think pools are going to continue using GBT anyway?
558 2013-03-07 10:29:36 <Luke-Jr> petertodd: true :/
559 2013-03-07 10:29:59 <Luke-Jr> we already see the big pools refusing to use GBT even without a monopoly
560 2013-03-07 10:30:21 <petertodd> Luke-Jr: It's the same thing with UTXO proofs, unless a solid, can't change it, hard fork enforcing UTXO proofs is achieved, centralized pools can always choose to turn off the soft-fork to UTXO proofs.
561 2013-03-07 10:30:29 <petertodd> Luke-Jr: Yup, why should they care?
562 2013-03-07 10:31:02 <petertodd> Frankly, pools are centralized right now, but because any censorship creates an opportunity for others, it's mainly a confirmation reversal risk.
563 2013-03-07 10:31:03 <Luke-Jr> petertodd: I guess the biggest flaw right now is that miners have too little incentive to care
564 2013-03-07 10:31:27 <petertodd> Unfortunately true - the "hashers" model of mining is a problem, but I can't see a way to fix that.
565 2013-03-07 10:31:36 <petertodd> Or I should say, "dumb hashers"
566 2013-03-07 10:32:28 <Luke-Jr> attempting to fix that is why I intentionally omitted a way for GBT miners to be blinded
567 2013-03-07 10:32:47 <petertodd> Oh, and I should have said in my email too: centralization of pools also can kill merge-mining, again out of censorship of competitors.
568 2013-03-07 10:33:00 <petertodd> Luke-Jr: Good move
569 2013-03-07 10:33:11 <sipa> petertodd: switch to a PoW function that requires fast access to the UTXO set
570 2013-03-07 10:33:32 <petertodd> sipa: Well, I mean a way we can fix that in Bitcoin...
571 2013-03-07 10:35:27 <Luke-Jr> petertodd: we *could* do that for Bitcoin, but it'd need a hardfork
572 2013-03-07 10:35:49 <petertodd> Yeah, with BFL shipping something like $30 million worth of SHA256 hardware, good luck...
573 2013-03-07 10:35:51 <Luke-Jr> basically just require the UTXO POW per header
574 2013-03-07 10:35:59 <Luke-Jr> that'd be compatible with the ASICs
575 2013-03-07 10:36:15 <Luke-Jr> so you make extranonce rolling require access to UTXO
576 2013-03-07 10:36:45 <petertodd> Doesn't matter how you want to do it, there's an enormous amount of economic force behind the current PoW function.
577 2013-03-07 10:36:54 <sipa> changing the PoW function in practice requires starting an altcoin i think
578 2013-03-07 10:37:08 <petertodd> As always, anything *can* be changed, but look luck convincing the economic super majority.
579 2013-03-07 10:37:08 <sipa> there is no way to push such a thing in the bitcoin economy
580 2013-03-07 10:37:20 <Luke-Jr> sipa: bundle it with some other hardfork features
581 2013-03-07 10:37:36 <sipa> sure, and even other things
582 2013-03-07 10:37:40 <petertodd> Luke-Jr: and make acceptance of the hard fork even less likely?
583 2013-03-07 10:37:42 <sturles> Bah! Sometimes I'm very annoyed about how bitcoind chooses inputs. I just sent a 3 BTC tx. It selected a rather young 3 BTC input (out of many older possibilities at 5 or more). Due to the low number of confirmations, it needed a fee, so it added another small input. Now needing two inputs and making two outputs. If it had selected another possible input (one at 5 BTC, one with 7 BTC), it would have been a smaller transaction requiring no
584 2013-03-07 10:37:48 <Luke-Jr> give non-miner features 2 years before they take effect
585 2013-03-07 10:37:59 <Luke-Jr> petertodd: more likely, because more people will want at least one of the changes
586 2013-03-07 10:38:14 <Luke-Jr> sturles: patches welcome
587 2013-03-07 10:38:19 <sipa> some things are not doable in a hardfork even in practice, like stuff that prevents old-system ourputs to be spent
588 2013-03-07 10:38:22 <petertodd> Luke-Jr: Or... 500 page forum threads will pop up until nothign happens.
589 2013-03-07 10:38:46 <petertodd> sipa: Yes, UTXO bloat is I think one of the biggest hidden technical dangers of large blocks.
590 2013-03-07 10:39:03 <sturles> Luke-Jr: I know, but I haven't been able to understand the current selection code fully.
591 2013-03-07 10:39:09 <Luke-Jr> petertodd: it can be done in a way that automatically upgrades only after N% of the network has upgraded
592 2013-03-07 10:39:15 <Luke-Jr> petertodd: signalled by transaction versions, for example
593 2013-03-07 10:39:17 <petertodd> sipa: Just buy up some mining power, and produce 1GiB blocks until your competitors run out of money to buy SSD's.
594 2013-03-07 10:39:48 <petertodd> Luke-Jr: Look, I know it can be done technically, socially, good luck. Any hardfork for bitcoin is going to be tough.
595 2013-03-07 10:39:59 <sturles> Luke-Jr: I would also like bitcoind to consolidate my coins. E.g. when this tx required a fee anyway, it should have added more small inputs to avoid making the dust it added even smaller.
596 2013-03-07 10:40:01 <petertodd> Luke-Jr: However harmless it is.
597 2013-03-07 10:40:11 <Luke-Jr> petertodd: there's enough software centralization right now it wouldn't be difficult really
598 2013-03-07 10:40:28 <Luke-Jr> petertodd: you realize we did one about a year ago?
599 2013-03-07 10:40:51 <petertodd> Luke-Jr: There's plenty of people who can create forks of the software.
600 2013-03-07 10:41:14 <Luke-Jr> petertodd: and a ton more people who will just do whatever Gavin tells them
601 2013-03-07 10:41:19 <petertodd> Luke-Jr: Who cares what we did a year ago? It wasn't anywhere near as political as a PoW change would be.
602 2013-03-07 10:41:30 <Luke-Jr> a PoW change wouldn't be political AFAIK
603 2013-03-07 10:41:32 <petertodd> Luke-Jr: Besides, P2SH wasn't a hard fork.
604 2013-03-07 10:41:40 <Luke-Jr> petertodd: I wasn't talking about P2SH
605 2013-03-07 10:41:47 <Luke-Jr> I was talking about the checksummed version message
606 2013-03-07 10:41:51 <petertodd> Luke-Jr: So being ordered to buy new hardware to keep up by the powers that be won't be political?
607 2013-03-07 10:42:06 <Luke-Jr> petertodd: what I proposed is compatible with all existing hardware
608 2013-03-07 10:42:07 <petertodd> Luke-Jr: Ok, so that's even more my point: it was such a minor hard fork, I had forgotten about it.
609 2013-03-07 10:42:43 <petertodd> Luke-Jr: It's only compatible with existing hardware if miners don't have to change any of their hardware to remain competitive. UTXO PoW does not meet that criteria.
610 2013-03-07 10:43:01 <petertodd> Luke-Jr: You'd have a crazy dash to buy the most IOPs/$
611 2013-03-07 10:43:23 <petertodd> Luke-Jr: Just like the crazy dash to buy ASICs
612 2013-03-07 10:43:32 <Luke-Jr> petertodd: I'm assuming UTXO is stored in memory.
613 2013-03-07 10:44:12 <petertodd> Who cares? Then people start building crazy systems with tonnes of ram so multiple copies of the UTXO are stored in memory.
614 2013-03-07 10:44:46 <petertodd> The only way you can hope to achieve any of this, is if the maximum *hardness* of this PoW is strictly limited, and preferably doesn't grow, and even that's going to be tricky.
615 2013-03-07 10:45:06 <petertodd> Like, if you need a UTXO PoW meeting foo IOP/s per block, but no more.
616 2013-03-07 10:45:21 <petertodd> But then it's really just a proof you had access to the UTXO set, not a PoW per-se.
617 2013-03-07 10:46:04 <Luke-Jr> well, proof of UTXO access is what's important
618 2013-03-07 10:46:37 <petertodd> Luke-Jr: Yes, but we've talked about that one before, and pure proving access isn't anywhere near as controversial.
619 2013-03-07 10:46:50 <Luke-Jr> using the UTXO to create block headers + ASICs forcing rapid creation of block headers = win
620 2013-03-07 10:46:54 <petertodd> But it doesn't provide the real "make miners care" incentive you want.
621 2013-03-07 10:47:03 <Luke-Jr> I suppose
622 2013-03-07 10:47:17 <petertodd> Forcing the hashing power to care is political, that's the issue.
623 2013-03-07 10:47:49 <petertodd> All the safe version does is keep "mystry miners" away, and juicy high-tx fees give correct behavior there anyway,.
624 2013-03-07 10:49:52 <Luke-Jr> petertodd: what if we delay spendability of generation longer?
625 2013-03-07 10:50:07 <Luke-Jr> eg, cannot spend for 5000 blocks
626 2013-03-07 10:50:16 <Luke-Jr> that means miners need to hold onto them for a month
627 2013-03-07 10:50:29 <petertodd> Promotes weird financial structures to get around that.
628 2013-03-07 10:50:36 <Luke-Jr> and therefore have an interest in the value remaining the same or improving in that time
629 2013-03-07 10:50:48 <petertodd> Besides, a month is tiny.
630 2013-03-07 10:51:02 <Luke-Jr> any longer could create barrier-to-entry problems
631 2013-03-07 10:51:34 <petertodd> Yeah, it's a cute idea, but again, making it effective is political.
632 2013-03-07 10:51:55 <petertodd> I don't want us to waste on hard-fork capital on things like that, when we might really need them for a serious security break.
633 2013-03-07 10:52:39 <petertodd> Stuff like a SHA256 partial break, and we know hashing power needs to be upgraded to SHA3 or whatever, hopefully in the next few years.
634 2013-03-07 10:52:58 <Luke-Jr> that would be a harder fork
635 2013-03-07 10:53:10 <petertodd> Politically I think it'd be easier.
636 2013-03-07 10:53:37 <petertodd> It's not changing the economic condition of hashers, just telling them "as you upgrade your equipment, it needs to be this"
637 2013-03-07 10:53:51 <petertodd> In practice it's changing the economics, but at least for (hopefully) clear reasons.
638 2013-03-07 10:54:16 <petertodd> Not to say a UTXO thing couldn't be done, but the reasons to do it aren't due to an existential threat like a broken hash fucntion.
639 2013-03-07 10:54:24 <Luke-Jr> why would they be upgrading their equipment?
640 2013-03-07 10:54:47 <petertodd> Because the PoW would be changing to progressivly deprioritize SHA256 vs SHA3
641 2013-03-07 10:54:50 <petertodd> (or whatever)
642 2013-03-07 10:55:15 <petertodd> (I assume a straight cut-off wouldn't fly due to accusations of unfairness)
643 2013-03-07 10:56:12 <petertodd> anyway, I gotta go
644 2013-03-07 10:56:13 <petertodd> later
645 2013-03-07 10:56:16 <Luke-Jr> ttyl
646 2013-03-07 11:01:12 <sturles> Luke-Jr: Would roughly approxmating a minimum nConfTheirs needed for a free transaction of nTargetValue in SelectCoinsMinConf work? Look for an old output large enough fist, and if not found try younger outputs.
647 2013-03-07 13:07:35 <jaromil> gmaxwell: thanks for your remark, I will watch out before calling it "signing" again. I did read the pdf and did meant relaying. I should really take care of these details in my writings and speeches, I will.
648 2013-03-07 13:07:57 <HM> "// returns false if point is compressed and not valid (doesn't check if uncompressed)"
649 2013-03-07 13:08:00 <HM> .... badness
650 2013-03-07 13:13:33 <HM> necessary for performance i guess
651 2013-03-07 13:14:13 <jaromil> jgarzik: re "so you want to wait for a certain # of confirmations?" sorry my connection went down yesterday. answer is yes, but I don't need to have explained how to do that in detail :^) I just need your advice on what is the best way to register a callback in brd and find out when a transaction gets relayed.
652 2013-03-07 13:31:58 <Diablo-D3> hey guys
653 2013-03-07 13:32:03 <Diablo-D3> is <> used anywhere in C?
654 2013-03-07 13:32:16 <Diablo-D3> I mean as in an encapsulating pair, like () [] and {}
655 2013-03-07 13:32:23 <sipa> no
656 2013-03-07 13:32:26 <mogri> no
657 2013-03-07 13:32:31 <Diablo-D3> _huh_
658 2013-03-07 13:32:32 <MagicalTux> only for #include
659 2013-03-07 13:32:38 <Diablo-D3> ACTION stares angrily at objc
660 2013-03-07 13:32:40 <MagicalTux> but that's not what you're looking for
661 2013-03-07 13:32:40 <mogri> that's not C
662 2013-03-07 13:32:43 <mogri> it's C preprocessor
663 2013-03-07 13:33:27 <mogri> Diablo-D3, i accept bitcoins now it is great
664 2013-03-07 13:33:39 <Diablo-D3> mogri: Ive only been asking you to do that for several years now
665 2013-03-07 13:33:44 <Diablo-D3> great you finally did what I asked
666 2013-03-07 13:34:05 <mogri> well, at sip it was bureaucracy (i.e. mike didn't want to do it)
667 2013-03-07 13:34:25 <Diablo-D3> yeah, and now mike can go fuck himself and we can roll in $40 bitcoins
668 2013-03-07 13:35:43 <Diablo-D3> sips, gmaxwell: btw, you might wanna look into using uncrustify to format bitcoin's src
669 2013-03-07 13:35:47 <Diablo-D3> sipa
670 2013-03-07 13:35:54 <Diablo-D3> osx just autocorrected someone's nick.
671 2013-03-07 13:36:04 <Diablo-D3> ACTION just turns it off
672 2013-03-07 13:36:19 <Diablo-D3> up yours apple
673 2013-03-07 13:38:53 <MC1984_> so angry diablo
674 2013-03-07 14:36:05 <mogri> .check buyvm.com
675 2013-03-07 14:36:25 <mogri> oh right
676 2013-03-07 14:36:27 <mogri> it's .net
677 2013-03-07 14:36:37 <mogri> .check my.frantech.ca
678 2013-03-07 14:38:57 <mogri> .geo 198.27.77.7
679 2013-03-07 14:39:01 <mogri> oops
680 2013-03-07 14:43:41 <grau> !ticker
681 2013-03-07 14:43:42 <gribble> BTCUSD ticker | Best bid: 45.18900, Best ask: 45.19000, Bid-ask spread: 0.00100, Last trade: 45.19000, 24 hour volume: 176261.63876036, 24 hour low: 33.30000, 24 hour high: 49.09900, 24 hour vwap: 42.04372
682 2013-03-07 14:43:54 <grau> ;;goxlag
683 2013-03-07 14:43:55 <gribble> 10.7028 seconds
684 2013-03-07 14:44:30 <grau> !ticker
685 2013-03-07 14:44:31 <gribble> BTCUSD ticker | Best bid: 45.07000, Best ask: 45.18900, Bid-ask spread: 0.11900, Last trade: 45.07000, 24 hour volume: 176042.29777262, 24 hour low: 33.30000, 24 hour high: 49.09900, 24 hour vwap: 42.03492
686 2013-03-07 14:44:34 <helo> are blocks larger than 250kb orphaned too much to be worth it?
687 2013-03-07 14:45:09 <helo> i was pretty sure blocks were sticking around 250kb because of the soft limit, but someone claimed otherwise
688 2013-03-07 14:45:35 <grau> I guess you mean transactions not blocks
689 2013-03-07 14:48:30 <helo> no, block size is hovering around 250kb. it's either because miners are lazy and haven't increased the soft limit, or because they think they'll make less if they increase it
690 2013-03-07 14:49:26 <grau> if I were to guess the second.
691 2013-03-07 14:50:15 <grau> their interest is to have competition in fees
692 2013-03-07 14:50:26 <grau> no limit no competition
693 2013-03-07 14:53:19 <helo> could users retaliate by refusing to relay blocks smaller than 250kb when poolsz is big?
694 2013-03-07 15:00:01 <grau> helo: I guess big mining pools have direct links to each other so they do not depend on propagation by the user
695 2013-03-07 15:01:14 <grau> they however have the incentive of keeping the network useful for user otherwise what they mine is worthless
696 2013-03-07 15:05:35 <helo> is it straightforward that 250kb is the optimal supply to maximize mining profit?
697 2013-03-07 15:08:41 <BlueMatt> helo: no, in fact there is no evidence that any value is optimal to maximize profit
698 2013-03-07 15:08:50 <BlueMatt> (and higher is probably significantly better for many miners)
699 2013-03-07 15:13:14 <petertodd> helo: Optimal is if you can reliably get your blocks to 51% of the hashing power: https://bitcointalk.org/index.php?topic=144895.0
700 2013-03-07 15:13:38 <petertodd> helo: In reality, that's hard to measure, so pool ops chasing fees with up block sizes until orphans scare them.
701 2013-03-07 15:13:53 <BlueMatt> petertodd: well, get it there before there has its own block
702 2013-03-07 15:15:03 <petertodd> Yes, and if 51% of the overall hashing power sees your block, you'll get ahead. The subtley is you have to do that reliably, but with lag based on bandwidth, that's doable, just not to exactly 51%
703 2013-03-07 15:15:45 <BlueMatt> yea, no 1MB with 10 minute intervals for blocks means orphans due to block size really shouldnt ever be an issue in my guesstimates
704 2013-03-07 15:15:59 <BlueMatt> still, I wouldnt mine behind tor
705 2013-03-07 15:17:30 <OneMiner> Buying XRP. Selling signed sports jerseys. WTT for computer parts.
706 2013-03-07 15:17:40 <OneMiner> Shizzz sry, wrong chan.
707 2013-03-07 15:18:23 <petertodd> With 1MB blocks mining behind tor is doable, just a bit less profitable, but not seriously so. The point is, with 100MB blocks, that just won't be true.
708 2013-03-07 15:18:52 <BlueMatt> yes, absolutely, that is what I was referring to
709 2013-03-07 15:19:45 <BlueMatt> mining behind tor will always be profitable if you discount electricity, but if you count electricity and assume mining is only profitable on infinitely small margins, then mining is never profitable unless propagation to 51% is instant
710 2013-03-07 15:20:16 <BlueMatt> actually more than 51% in the extreme case
711 2013-03-07 15:20:26 <petertodd> Huh?
712 2013-03-07 15:20:57 <petertodd> You mean, how you can always mine empty blocks?
713 2013-03-07 15:22:06 <BlueMatt> well assuming the margins are infinitely small, you have to ensure 100% of your blocks are accepted or you end up losing
714 2013-03-07 15:22:21 <BlueMatt> which is ofc impossible, but...anyway you see my point
715 2013-03-07 15:24:46 <petertodd> Ah, yeah, you're technically correct, the best kind of correct. :P
716 2013-03-07 15:25:37 <BlueMatt> heh
717 2013-03-07 15:26:06 <petertodd> I think in my bitcoin-dev email this morning I remembered to mention how in theory miners behind tor could mine censored tx's with really high fees...
718 2013-03-07 15:26:54 <petertodd> Lots of risk though due to other miners griefing them by mining the ones the tor nodes think aren't going to get mined anyway, thus invalidating their blocks.
719 2013-03-07 15:27:00 <BlueMatt> ACTION doesnt really have time to keep up with even the ml anymore :(
720 2013-03-07 15:28:48 <petertodd> Eek, you must be a father or something. :P
721 2013-03-07 15:29:04 <BlueMatt> heh, no Im still a student
722 2013-03-07 15:29:15 <BlueMatt> and yet I still cant find time to do all I want to....
723 2013-03-07 15:29:24 <BlueMatt> TD: off-by-one in my block size code...thats not good :(
724 2013-03-07 15:29:48 <BlueMatt> or maybe the sig is too big...
725 2013-03-07 15:30:06 <petertodd> BlueMatt: Ha, close enough. I sleep so much better now that I'm not taking math classes...
726 2013-03-07 15:31:20 <BlueMatt> ehh, most of my time is in various personal projects, clubs, etc...even my credit hour overload doesnt keep my all that busy (though they are mostly cs courses, so...meh)
727 2013-03-07 15:31:55 <petertodd> BlueMatt: Hey, so long as it's not just work.
728 2013-03-07 15:32:00 <BlueMatt> yep
729 2013-03-07 16:15:05 <midnightmagic> BlueMatt: If your CS courses are "meh" you should be applying for course waivers and skipping up the prereq chain.
730 2013-03-07 16:15:34 <midnightmagic> BlueMatt: Why waste your time there, I say, doing shit you already know. Skip up, and load up on upper level credit.
731 2013-03-07 16:16:03 <midnightmagic> it's more interesting anyway
732 2013-03-07 16:16:22 <BlueMatt> midnightmagic: the meh was more because its not much work, easy courses != not learning anything
733 2013-03-07 16:16:27 <BlueMatt> (and I have skipped up a lot...)
734 2013-03-07 16:17:35 <midnightmagic> Does your institute do the really annoying thing and require attendance? double up on the courses then and finish sooner.
735 2013-03-07 16:24:41 <BlueMatt> na, I could (I already overload)...but why give up free time to get out early?
736 2013-03-07 16:24:46 <BlueMatt> work is...well work
737 2013-03-07 16:25:26 <splnkr> then again, the less you have to go away from the computer, the more you should make a point of it
738 2013-03-07 16:25:36 <splnkr> every 20 mins, focus the eyes on an object 20 feet (6 meters) away for 20 seconds.
739 2013-03-07 16:26:29 <BlueMatt> huh? we are talking about college, not just working on computers all day
740 2013-03-07 16:27:03 <Luke-Jr> BlueMatt: work is far more useful than uni :P
741 2013-03-07 16:27:21 <splnkr> CS courses are both, no?
742 2013-03-07 16:27:28 <Happzz> i've a technical question. SD, right? so you send them X, and they almost instantly send you back Y, like, much before your tx was confirmed even once. how do they know it's not a fake tx or so?
743 2013-03-07 16:27:42 <Happzz> i assume they check it somehow, or else people would scam the shit out of them already
744 2013-03-07 16:28:10 <Luke-Jr> Happzz: they don't
745 2013-03-07 16:28:18 <Luke-Jr> Happzz: people *do* scam them already
746 2013-03-07 16:28:37 <BlueMatt> Luke-Jr: provides money, but...as long as you dont need it
747 2013-03-07 16:28:59 <Luke-Jr> BlueMatt: I wasn't talking about money :P
748 2013-03-07 16:29:11 <BlueMatt> well, ok, but thats what internships are for
749 2013-03-07 16:29:20 <sipa> Happzz: they use the tx you send them as input for the transaction returning to you
750 2013-03-07 16:29:35 <sipa> Happzz: so if you send them something invalid for any reason, the returning tx will be invalid too
751 2013-03-07 16:29:39 <BlueMatt> Luke-Jr: also working on floss
752 2013-03-07 16:30:24 <TD> heya
753 2013-03-07 16:30:29 <TD> BlueMatt: did you see the bug i CCd you on?
754 2013-03-07 16:35:42 <andytoshi> BlueMatt: what year are you in?
755 2013-03-07 16:50:14 <gmaxwell> Density of dice related txn in each block: (dice related means that an input had an output that paid to dice, or it has an output that pays to dice)
756 2013-03-07 16:50:18 <gmaxwell> 224715 0.81457
757 2013-03-07 16:50:20 <gmaxwell> 224714 0.875507
758 2013-03-07 16:50:23 <gmaxwell> 224713 0.328125
759 2013-03-07 16:50:25 <gmaxwell> 224712 0.797654
760 2013-03-07 16:50:28 <gmaxwell> 224711 0.0623819
761 2013-03-07 16:50:30 <gmaxwell> 224710 0.686567
762 2013-03-07 16:50:32 <gmaxwell> It's interesting to note that 224711 was also 400k??? it was produced by someone blocking dice.
763 2013-03-07 16:50:35 <gmaxwell> 224709 0.581081
764 2013-03-07 16:50:37 <gmaxwell> 224708 0.769886
765 2013-03-07 16:50:40 <gmaxwell> 224707 0.749386
766 2013-03-07 16:52:14 <andytoshi> very good numbers to know
767 2013-03-07 16:52:19 <andytoshi> i thought more people were dice-blocking :(
768 2013-03-07 16:52:31 <Happzz> dice blocking?
769 2013-03-07 16:53:20 <andytoshi> Happzz: refusing to mine transactions that come from satoshi dice
770 2013-03-07 16:53:20 <helo> Happzz: refusing to mine transactions to/from satoshidice
771 2013-03-07 16:53:24 <andytoshi> lolo
772 2013-03-07 16:53:31 <helo> hh
773 2013-03-07 16:53:38 <gmaxwell> andytoshi: 224713 was dice blocking too, but dice blockers still mine dice returns... because they block only based on outputs.
774 2013-03-07 16:54:19 <andytoshi> gmaxwell: OK, 2 of eight is not too bad
775 2013-03-07 16:54:19 <gmaxwell> well, some dice blockers??? 224711 was more effective.
776 2013-03-07 16:55:59 <Happzz> someone will mine tx to/from sd i guess.
777 2013-03-07 16:55:59 <TD> gmaxwell: shouldn't it be zero, if dice was blocked?
778 2013-03-07 16:56:09 <TD> ah
779 2013-03-07 16:56:11 <Happzz> you can't really "block" that kinda stuff with the btc infrastructure
780 2013-03-07 16:56:12 <TD> just caught up
781 2013-03-07 16:56:33 <Happzz> i still don't understand what's the big deal with SD and why everyone hates them
782 2013-03-07 16:57:04 <andytoshi> Happzz: because they are spamming the chain, look at that garbage, over half the transactions come from one entity
783 2013-03-07 16:57:12 <andytoshi> why can't they just use multiple outputs?
784 2013-03-07 16:57:50 <Happzz> andytoshi they pay the fees, sounds harsh to not accept their txs
785 2013-03-07 16:57:58 <gmaxwell> TD: my 'related' definition is also a little more expansive than any reasonable blocking would be.. in that if you spend an unrelated output from a txn that also payed dice, I count that spend as dice related.
786 2013-03-07 16:58:20 <andytoshi> Happzz: they don't pay me any fees, or any other node, to store their crap
787 2013-03-07 16:58:28 <TD> ok