1 2012-11-11 00:25:09 <ne0futur> de la balle
  2 2012-11-11 00:25:39 <ne0futur> oups sorry
  3 2012-11-11 00:25:41 <ne0futur> bad chan
  4 2012-11-11 00:28:55 <W00t_> Probably not the first to ask this, but is tehre any public-source php scripts for online btc address generation and use?
  5 2012-11-11 00:30:16 <D34TH> W00t_, are you asking for a php based bitcoin client?
  6 2012-11-11 00:30:26 <W00t_> I suppose, yes
  7 2012-11-11 00:30:35 <D34TH> i dont think so
  8 2012-11-11 00:47:37 <W00t_> dicks
  9 2012-11-11 01:05:54 <jgarzik> mmmkay
 10 2012-11-11 02:12:29 <BlueMatt> sipa: heh...thanks, knew it was a stupid mistake on my side
 11 2012-11-11 02:12:55 <BlueMatt> D34TH: whats up with win32 builds?
 12 2012-11-11 02:13:13 <D34TH> its linker was spitting stuff out about -z
 13 2012-11-11 02:20:47 <BlueMatt> D34TH: link?
 14 2012-11-11 02:20:52 <BlueMatt> D34TH: I see nothing on current builds
 15 2012-11-11 02:21:08 <D34TH> http://jenkins.bluematt.me/job/Bitcoin/139/console
 16 2012-11-11 02:23:08 <BlueMatt> D34TH: hmm...odd, have you tried the build
 17 2012-11-11 02:23:15 <D34TH> i have not
 18 2012-11-11 02:25:12 <D34TH> i was gonig to wait till 140 was done
 19 2012-11-11 02:50:23 <BlueMatt> D34TH: alright, ping me when youve tested, thanks
 20 2012-11-11 03:59:49 <Luke-Jr> (that'd give me warnings when/if git master creates a block template that 0.6.0.x doesn't like
 21 2012-11-11 04:19:56 <astor> I have a locking-related question. anyone awake?
 22 2012-11-11 04:22:00 <astor> never mind
 23 2012-11-11 05:32:45 <Diablo-D3> heh so
 24 2012-11-11 05:32:50 <Diablo-D3> I finally went ahead and got my devcoins
 25 2012-11-11 05:33:03 <Diablo-D3> "balance" : 81873877.00000000,
 26 2012-11-11 05:33:45 <Diablo-D3> or approximately 173 btc at current exchange rates
 27 2012-11-11 05:34:52 <ThomasV> another scamcoin?
 28 2012-11-11 05:38:24 <Diablo-D3> ThomasV: no
 29 2012-11-11 05:38:32 <Diablo-D3> its a coin that pays foss developers
 30 2012-11-11 05:39:16 <Diablo-D3> ThomasV: 90% of the generation goes to developers
 31 2012-11-11 10:13:53 <abrkn> foss?
 32 2012-11-11 10:15:04 <sipa> free and open source software
 33 2012-11-11 10:23:29 <Diapolo> sipa: Wow thanks for merging that many pulls recently.
 34 2012-11-11 10:23:56 <sipa> i guess most couldn't hurt :)
 35 2012-11-11 10:24:01 <Diapolo> :-D
 36 2012-11-11 10:26:27 <Diapolo> sipa: Will new LevelDB versions cause the same problems as switching BDB versions?
 37 2012-11-11 10:27:33 <sipa> Diapolo: no, leveldb is far more consistent in its on-disk structure
 38 2012-11-11 10:28:37 <sipa> and since the source is included in our tree, we can guarantee which version users will use
 39 2012-11-11 10:28:51 <Diapolo> I'm asking because I remember you suggested switching to a later version in on of the pulls, can't remember which it was though. Does Google maintain a changelog for LevelDB?
 40 2012-11-11 10:28:59 <sipa> sure
 41 2012-11-11 10:29:19 <sipa> yes, we could switch to 1.6, but there don't seem to be many improvements
 42 2012-11-11 10:30:23 <Diapolo> Another thing, is the peers.dat still BDB or did I missread the code in db.cpp?
 43 2012-11-11 10:30:30 <sipa> it's not
 44 2012-11-11 10:30:36 <sipa> it's just a serialized CAddrMan
 45 2012-11-11 10:32:10 <sipa> class CAddrDB does not inherit from CDB, you see
 46 2012-11-11 10:32:42 <Diapolo> you are right, was just wondering as it resides in db.cpp, which I thought would contain only BDB stuff (didn't take a deep look yet)
 47 2012-11-11 10:33:15 <sipa> the idea is that addrman.* is just the data structure, and has no knowledge about how/where it gets stored on disk
 48 2012-11-11 10:34:05 <Diapolo> which is a good thing, as changes below are not related then
 49 2012-11-11 10:34:39 <sipa> having it in db.* is a bit strange maybe, but i wouldn't know of a better place
 50 2012-11-11 10:35:57 <Diapolo> no need to invent someting new
 51 2012-11-11 11:26:57 <Diapolo> Is the pull tester currently working?
 52 2012-11-11 13:08:44 <liori> hello, is there any chance to get bitcoind follow XDG base directory specification? (http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html)
 53 2012-11-11 13:10:16 <sipa> liori: what would that imply, in practice?
 54 2012-11-11 13:11:00 <liori> i just found out that my ~/.bitcoin takes 50GB of my backup space. if it kept blockchain in ~/.cache, it would take much less (as i keep just one copy of ~/.cache)
 55 2012-11-11 13:12:55 <liori> well, it would be moving files from ~/.bitcoin to ~/.cache/bitcoin, ~/.local/bitcoin and ~/.config/bitcoin.
 56 2012-11-11 13:13:55 <liori> (technically these paths can be configured by environment variables)
 57 2012-11-11 13:14:32 <sipa> before 0.8, the wallet and blockchain shared a database environment, so it was impossible to separate them
 58 2012-11-11 13:14:47 <sipa> as of 0.8, it's technically possible, and changing the directories wouldn't be that much work
 59 2012-11-11 13:15:25 <sipa> but we would have to think about equivalent paths for other platforms
 60 2012-11-11 13:15:38 <sipa> and backward compatibility
 61 2012-11-11 13:16:05 <sipa> (e.g. if someone's bitcoin.conf specifies a datadir, which datadir does it refer to?)
 62 2012-11-11 13:18:36 <liori> i see. so, it will be technically possible only in 0.8, and even then there are some compatibility implications& so, for now i'll try to make some exception in my backup software (won't be easy, it operates on a per-directory basis)
 63 2012-11-11 13:19:39 <sipa> for 0.8 there is already a scheduled change to the datadir layout (wallet in $DATADIR, blocks in $DATADIR/blocks, block database in $DATADIR/blktree, unspent transaction output database in $DATADIR/coins)
 64 2012-11-11 13:20:40 <sipa> so that would mean you can set different backup policies for those subdirs already
 65 2012-11-11 13:29:39 <Luke-Jr> sipa: Bitcoin-Qt already uses ~/.config/Bitcoin/Bitcoin-Qt.conf fwiw
 66 2012-11-11 13:30:07 <sipa> indeed
 67 2012-11-11 13:30:10 <Luke-Jr> liori: you don't want to make exceptions for now :/
 68 2012-11-11 13:30:43 <Luke-Jr> lianj: technically you could leave out blk000*.dat, but I don't think there's any way to get those out of the same dir with blkindex.dat and database/ which you need for integrity
 69 2012-11-11 13:31:05 <Luke-Jr> liori*
 70 2012-11-11 13:33:00 <liori> i see. thanks for warning then.
 71 2012-11-11 13:37:08 <sipa> Luke-Jr: for what it's worth, i've already mined with ultraprune for quite some time (even found a real block!), so i'm more worried about things like accepting invalid blocks or mempool behaviour, rather than creating invalid blocks
 72 2012-11-11 13:49:43 <Luke-Jr> sipa: still, more testing can't hurt
 73 2012-11-11 13:49:48 <sipa> of course
 74 2012-11-11 14:52:39 <abrkn> bitfloor api acting up again?
 75 2012-11-11 15:48:21 <Joric> how to work with a pull request correctly should i revert changes and rebase to a single commit every time
 76 2012-11-11 16:22:44 <kload1> Help please i am trying to fetch listtransaction api but it gives me an empty array does anyone know why?
 77 2012-11-11 16:24:02 <sipa> did you receive/send any transactions yet?
 78 2012-11-11 16:32:25 <kload1> @sipa: no
 79 2012-11-11 16:37:40 <sipa> kload1: then it's very normal that it returns an empty list, as that RPC call returns the transactions in your wallet
 80 2012-11-11 16:39:22 <kload1> @sipa: Thanks :)
 81 2012-11-11 17:16:15 <D34TH> abe is taking so long on the import
 82 2012-11-11 17:16:31 <D34TH> its only @ ~185k after 24 hr
 83 2012-11-11 17:16:43 <sipa> what do you need abe for?
 84 2012-11-11 17:18:40 <D34TH> looking up transactions
 85 2012-11-11 17:18:55 <D34TH> and i dont want to overload blockchain.info
 86 2012-11-11 17:51:04 <cjd> Good afternoon guys, I'm trying to figure out the "version" message and the satoshi client doesn't seem to be sending nTime in the ip address blocks
 87 2012-11-11 17:53:30 <sipa> correct
 88 2012-11-11 17:53:59 <cjd> ok, is it removed from new versions?
 89 2012-11-11 17:54:19 <sipa> the nTime field is only present in later protocol versions, and the version message is exchanged before a protocol version is agreed upon
 90 2012-11-11 17:54:31 <cjd> ahh I see
 91 2012-11-11 17:55:22 <cjd> I would have thought it would be set as of the time when the version field was read and since it's first in the packet it would change
 92 2012-11-11 17:55:27 <cjd> but that makes some sense
 93 2012-11-11 17:56:19 <sipa> the version/verack messages are special in many ways, in order to guarantee conpatibility
 94 2012-11-11 17:57:02 <cjd> I suppose it also establishes a minimum bar of entry for writing a client ;)
 95 2012-11-11 18:03:11 <wizkid057> there a limit on how many outputs can be in a sendmany? lol
 96 2012-11-11 18:38:24 <wizkid057> i still want to know if thats any kind of record.... lol
 97 2012-11-11 18:43:17 <ThomasV> wizkid057: the only limit is your imagination. lol
 98 2012-11-11 18:43:28 <sipa> the only limit is size
 99 2012-11-11 18:43:38 <ThomasV> too
100 2012-11-11 18:43:39 <wizkid057> i have a vivid imagination
101 2012-11-11 18:43:50 <wizkid057> well, Eligius's mass payout paid 2031 addresses
102 2012-11-11 18:43:54 <ThomasV> do you have a vivid size
103 2012-11-11 18:44:05 <sipa> in theory, 1000000 bytes
104 2012-11-11 18:44:09 <sipa> in practice, somewhat less
105 2012-11-11 18:44:29 <wizkid057> well, 70KB < 1000KB, so, guess that works :)
106 2012-11-11 21:32:21 <DrHaribo> anyone know why getblocktemplate's target and getdifficulty would not be in sync on testnet?
107 2012-11-11 21:32:29 <DrHaribo> getblocktemplate shows "target" : "000000000170f900000000000000000000000000000000000000000000000000",
108 2012-11-11 21:32:38 <DrHaribo> bitcoind getdifficulty gives 1.00000000
109 2012-11-11 21:33:11 <sipa> the previous block probably had the special testnet rule applied
110 2012-11-11 21:34:17 <Luke-Jr> oh right, forgot getdifficulty was based on the previous block XD
111 2012-11-11 21:34:59 <DrHaribo> hmm, it should be called getwhatdifficultyusedtobe :P
112 2012-11-11 21:35:15 <DrHaribo> but thanks, sipa, that explains it
113 2012-11-11 21:36:25 <sipa> this split of the RPC into separate sourcefiles is great... but where the hell is getinfo?
114 2012-11-11 21:36:38 <sipa> rpcwallet.cpp it seems...
115 2012-11-11 21:36:57 <sipa> as appropriate as all other, i guess :)
116 2012-11-11 22:02:45 <jgarzik> sipa: unfortunately 'getinfo' fits all categories :)
117 2012-11-11 22:02:49 <jgarzik> sipa: it is a locking mess, too
118 2012-11-11 22:07:03 <sipa> jgarzik: yeah
119 2012-11-11 22:07:32 <Luke-Jr> perhaps getinfo should be deprecated, since JSON-RPC batching should perform the same job
120 2012-11-11 22:08:08 <Luke-Jr> although, it might be important to refactor batching support first, so that the locks are held for all the calls
121 2012-11-11 22:08:15 <Luke-Jr> (so the info is atomic)
122 2012-11-11 22:11:01 <sipa> ewww, please no
123 2012-11-11 22:11:08 <sipa> not at that level
124 2012-11-11 22:11:13 <sipa> v
125 2012-11-11 22:13:18 <Luke-Jr> sipa: shouldn't be any worse than it is now?
126 2012-11-11 22:13:55 <sipa> no but it would prevent any sane locking in the future
127 2012-11-11 22:14:32 <sipa> the rpc system shiuldn't need to know, or even be allowed to touch the locks its callees use
128 2012-11-11 22:15:09 <sipa> make a getwalletinfo, a getblockchaininfo, ... all you like
129 2012-11-11 22:15:39 <sipa> they will access independent information, so don't need atomicity across calls
130 2012-11-11 22:16:01 <sipa> and be protected internally by independent locks
131 2012-11-11 22:16:16 <Luke-Jr> sipa: I disagree. I do in fact need atomic info between wallet and blockchain
132 2012-11-11 22:16:42 <sipa> such as?
133 2012-11-11 22:17:22 <Luke-Jr> sipa: interactions between orphaned blocks, for example
134 2012-11-11 22:18:07 <sipa> and how is the wallet involved there?
135 2012-11-11 22:18:17 <Luke-Jr> it contains information on the state of transactions
136 2012-11-11 22:18:43 <sipa> well i guess your case as a mining pool is somewhat special
137 2012-11-11 22:19:47 <sipa> but an rpc call sure may call something that internally locks both wallet and blockchain, that's not the problem
138 2012-11-11 22:19:58 <Luke-Jr> hmm, I suppose I could call getblockhash before and after to verify the block remained part of the chain
139 2012-11-11 22:20:12 <jgarzik> the straightforward way is to mark 'getinfo' unlocked
140 2012-11-11 22:20:21 <jgarzik> then manually lock/unlock
141 2012-11-11 22:20:28 <Luke-Jr> jgarzik: that has the opposite effect ;)
142 2012-11-11 22:20:42 <sipa> jgarzik: AAAAAARG
143 2012-11-11 22:20:58 <Luke-Jr> jgarzik: right now getinfo provides atomic information; otherwise we can just batch get*
144 2012-11-11 22:21:12 <jgarzik> sipa: messy, but a summary is quite useful.  anything else is more work for a system view
145 2012-11-11 22:21:37 <sipa> the inner datastructurrs should simply neither expose their internal state nor their locks
146 2012-11-11 22:21:49 <jgarzik> sure
147 2012-11-11 22:21:53 <jgarzik> hiding the locks is fine too
148 2012-11-11 22:22:04 <jgarzik> getinfo can run unlocked, and call helpers
149 2012-11-11 22:22:07 <sipa> rpc calls should simlly request information from the core
150 2012-11-11 22:22:12 <jgarzik> nod
151 2012-11-11 22:22:33 <sipa> and those core functions will access whatever data/locks they need
152 2012-11-11 22:26:05 <sipa> maybe, for batch rpcs, an inner function could get GetBlockData(vector<uint256> blockids), and a batch rpc that calls getblock frequently would batch it to a single call of this functiom, instead of calling a single block info function fkr each
153 2012-11-11 22:26:35 <sipa> but please, don't let the rpc system decide which locks it needs for its callees
154 2012-11-11 22:26:46 <gmaxwell> Obviously we need to add an SQL interperter and transactions to the RPC.
155 2012-11-11 22:35:27 <Luke-Jr> gmaxwell: hmm, I wonder how SQL would work as a protocol O.o
156 2012-11-11 22:35:35 <Luke-Jr> :P
157 2012-11-11 22:36:43 <Luke-Jr> actually, I wonder if there'd be a way to teach sqlite to access our internal data like that. I bet some people would like it for real
158 2012-11-11 22:38:21 <sipa> levepdb has support for read-only snapshots
159 2012-11-11 22:39:12 <sipa> if someone wants expensive blockchain queries, such snapshots may be useful to get consistent data wuthout needing core datastructure locks
160 2012-11-11 22:39:57 <jgarzik> if someone wants expensive/extensive blockchain queries, it's easy enough to use znort597(sp?)'s blockchain indexer, or pynode, or...
161 2012-11-11 23:19:31 <jgarzik> BlueMatt: did the binary bloom serialization just change?
162 2012-11-11 23:25:53 <BlueMatt> yes
163 2012-11-11 23:26:14 <BlueMatt> only very slightly though
164 2012-11-11 23:26:18 <BlueMatt> the filter itself just got another int at the end
165 2012-11-11 23:28:03 <Luke-Jr> slush: ping
166 2012-11-11 23:28:37 <Luke-Jr> slush: IIRC I read somewhere that Stratum requires notifies every 30 seconds; is that correct? if not, is there any rule on how often, and is that documented anywhere?
167 2012-11-11 23:34:33 <sipa> BlueMatt: what is the max bloom filter size now? 36k or 1M?
168 2012-11-11 23:34:54 <BlueMatt> that didnt change
169 2012-11-11 23:35:14 <sipa> that's no answer to my question :(
170 2012-11-11 23:35:16 <BlueMatt> static const unsigned int MAX_BLOOM_FILTER_SIZE = 36000; // bytes
171 2012-11-11 23:35:22 <BlueMatt> (I didnt remember)
172 2012-11-11 23:35:26 <sipa> ok
173 2012-11-11 23:35:56 <sipa> why does the pullreq mention 1M somewhere? was that just a proposal?
174 2012-11-11 23:42:54 <BlueMatt> thats filteradd ie max for any given element to be added to the filter over the network
175 2012-11-11 23:45:54 <sipa> hmm
176 2012-11-11 23:46:31 <sipa> wait, how can the filter grow because of a filteradd?
177 2012-11-11 23:47:00 <BlueMatt> it cant, but now the elements themselves are limited
178 2012-11-11 23:47:20 <sipa> i'm not following
179 2012-11-11 23:47:57 <BlueMatt> you can call filteradd with an element (eg pubkey) which is then added to that connection's filter
180 2012-11-11 23:48:04 <BlueMatt> those elements are now limited in size to 1MB
181 2012-11-11 23:48:41 <sipa> ooh
182 2012-11-11 23:49:09 <sipa> isn't that already extremely much?
183 2012-11-11 23:49:31 <BlueMatt> meh, its hardly a dos even unlimited, so why limit it low
184 2012-11-11 23:51:17 <sipa> what is matched for? extracted addresses, txids... and?
185 2012-11-11 23:52:01 <BlueMatt> any script object
186 2012-11-11 23:52:45 <sipa> oh yes, data pushes
187 2012-11-11 23:52:55 <sipa> aren't those limited?
188 2012-11-11 23:53:43 <BlueMatt> hmm...yea good point
189 2012-11-11 23:54:36 <sipa> 520 bytes, apparently
190 2012-11-11 23:58:01 <sipa> i don't like filteradd randomly assuming some parameters
191 2012-11-11 23:58:13 <BlueMatt> what else should it do?
192 2012-11-11 23:58:19 <sipa> fail
193 2012-11-11 23:58:30 <BlueMatt> meh...
194 2012-11-11 23:59:18 <sipa> either the spec should say what the parameters are, and reason why those are good defaults, or nothing atball