1 2012-06-27 00:00:32 <gmaxwell> BlueMatt: use loadblock
  2 2012-06-27 00:01:04 <BlueMatt> gmaxwell: have been, but I dont have any blk0001.dats around with full chain because I keep corrupting crap...
  3 2012-06-27 00:01:20 <BlueMatt> oh well, have to go sync again
  4 2012-06-27 00:02:32 <BlueMatt> tcatm: did you want someone to actually test it, if not: https://github.com/bitcoin/bitcoin.org/pull/42
  5 2012-06-27 00:03:02 <BlueMatt> (eyeballed the api output, but not sure if the ["contributors"] is still required
  6 2012-06-27 00:05:44 <tcatm> BlueMatt: It would be great if someone could actually test it. I think the way user profiles are transmitted was changed so the script would have to fetch each users profile in a separate GET now.
  7 2012-06-27 00:06:16 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 42 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/42>
  8 2012-06-27 00:07:36 <tcatm> If it works, feel free to merge it. The contributors page is the cause of bitcoin.org not updating. I can have a deeper look tomorrow, though.
  9 2012-06-27 00:13:38 <BlueMatt> tcatm: I beat it up and (after removing the ["..."]s) it worked, nfc if the jekyl stuff is right, but $stderr.puts worked so Im assuming its fine
 10 2012-06-27 00:23:16 <BlueMatt> no one gonna merge that and fix the website?
 11 2012-06-27 00:24:20 <BlueMatt> oh well, Im off to bed, guess it will wait till tomorrow
 12 2012-06-27 01:20:57 <jgarzik> reading up on libtorrent++, http://www.rasterbar.com/products/libtorrent/
 13 2012-06-27 01:21:37 <jgarzik> wondering if we shouldn't pick an arbitrary slice of blocks, say the first 2GB of blockfile, and distribute that via bittorrent.
 14 2012-06-27 01:23:07 <jgarzik> public nodes sure do seem to be serving a lot of old blocks, implying there are a lot of full-chain downloads
 15 2012-06-27 01:31:21 <D34TH> jgarzik i could seed it :D
 16 2012-06-27 01:31:34 <jgarzik> everyone could seed it!
 17 2012-06-27 01:31:38 <D34TH> :D
 18 2012-06-27 01:31:42 <D34TH> i meant on a seedbox
 19 2012-06-27 01:34:06 <nanotube> jgarzik: make sure there's a sig file in the torrent so people can verify authenticity. gavin's release signing key would be a good choice. :)
 20 2012-06-27 01:55:15 <jgarzik> nanotube: just the block file, no BDB indices.  so no need for any sigs... the block chain is self-verifying
 21 2012-06-27 01:55:56 <nanotube> ah
 22 2012-06-27 01:58:58 <jgarzik> hmmmmm
 23 2012-06-27 01:59:29 <jgarzik> might even be able to do it as a separate program, a "block chain downloader" that downloads the chain via torrent, then executes bitcoin with -loadblock
 24 2012-06-27 02:00:24 <jgarzik> would be easier to simply link bitcoind against libtorrent though
 25 2012-06-27 02:14:11 <D34TH> jgarzik i wouldnt be opposed to client seeding if it was opt-out able
 26 2012-06-27 02:19:03 <jgarzik> D34TH: oh that goes without question...
 27 2012-06-27 02:19:10 <D34TH> :D
 28 2012-06-27 02:19:24 <D34TH> D:
 29 2012-06-27 03:51:33 <etotheipi_> philosophical question:  is there any *effective* difference between output anonymity (making it difficult to distinguish recipient from change) and input anonymity (minimizing number of unique input addresses)?
 30 2012-06-27 03:52:37 <etotheipi_> my select-coins algorithm is configurable, and I can't decide whether to offer those as two separate features, or just lump them together with equal weights
 31 2012-06-27 05:28:13 <Tykling> why is my machine suddently so lagged when downloading a few days worth of blockchain :(
 32 2012-06-27 05:28:24 <Tykling> like permanent disk activity
 33 2012-06-27 05:28:56 <Tykling> I haven't really changed anything that I know of
 34 2012-06-27 06:00:48 <gribble> New news from bitcoinrss: fanquake opened pull request 1523 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1523>
 35 2012-06-27 06:49:19 <yellowhat> i have a question about the new tor hidden service support. how is the bitcoin p2p network going to pass messages between the "hidden" and visible nodes?
 36 2012-06-27 06:50:03 <yellowhat> and can a regular ipv4/ipv6 node connect somehow directly to a node that is also running on tor?
 37 2012-06-27 06:56:06 <sipa> yellowhat: it can be on both networks
 38 2012-06-27 07:22:48 <yellowhat> isn't that dangerous? if i connect to both networks my ip address and tor address can easily be linked.
 39 2012-06-27 07:24:21 <yellowhat> for example if i connect to a tor node send him a new transaction and simultanously connect to many ip nodes i can see who is relaying the transaction.
 40 2012-06-27 07:24:52 <yellowhat> or compare the inventory and ordering in the inventory
 41 2012-06-27 07:27:23 <jeremias> like if you want to provide anonymity for others, then you can run a hidden service
 42 2012-06-27 07:27:34 <jeremias> but I guess you can also run only the hidden service?
 43 2012-06-27 07:30:50 <yellowhat> ok, so running ipv4/ipv6 simultanously is not the common case but rather acting as a bridge. your .onion address should be considered wasted and identified
 44 2012-06-27 09:16:44 <cande> I'm awaiting a payment, having a bitcoind running on a server, how can i get notified when the payment is done?
 45 2012-06-27 09:17:07 <cande> can i monitor a specific bitcoinadress?
 46 2012-06-27 09:19:49 <kinlo> payments are done to the bitcoin network, so anyone can see which address got which coins
 47 2012-06-27 09:20:29 <kinlo> so you can see what you need on any block explorer site
 48 2012-06-27 09:21:02 <cdecker> If you want to be notified take a look at http://www.bitcoinmonitor.net/services/
 49 2012-06-27 09:23:26 <sipa> yellowhat: i run a bitcoin node at kjy2eqzk4zwi5zd3.onion, 178.18.90.41 and 2a02:348:5e:5a29::1
 50 2012-06-27 09:23:42 <sipa> *oops* anonimity gone
 51 2012-06-27 09:23:57 <kinlo> :p
 52 2012-06-27 09:30:42 <cande> I want to do the monitoring automatically
 53 2012-06-27 09:31:00 <Eliel> cande: you could also poll your bitcoind for either the balance or listtransactions
 54 2012-06-27 09:31:29 <sipa> cande: there's a patch for that coming up
 55 2012-06-27 09:31:38 <cande> ah.. nice
 56 2012-06-27 09:31:59 <Eliel> sipa: is it planned for inclusion into 0.7?
 57 2012-06-27 09:33:05 <sipa> maybe
 58 2012-06-27 09:33:46 <sipa> it is related to the plan of having lightweight clients ask the full node they connect to for filtering blocks/transactions for them
 59 2012-06-27 09:34:39 <cande> mm, nice
 60 2012-06-27 09:35:03 <cande> damn, good work fellows!
 61 2012-06-27 09:39:15 <setkeh> how would one make a script in bash to varify if a txid is in the current block
 62 2012-06-27 09:39:51 <cande> good question :-)
 63 2012-06-27 09:40:36 <sipa> in 0.7 you can use getblock to get a list of txid's in a given block
 64 2012-06-27 09:41:01 <cande> amazing, when is 0.7 due?
 65 2012-06-27 09:41:11 <sipa> when it's ready...
 66 2012-06-27 09:41:16 <setkeh> D
 67 2012-06-27 09:41:18 <cande> :-)
 68 2012-06-27 09:41:18 <setkeh> XD*
 69 2012-06-27 09:41:34 <cande> who do i pay? ;)
 70 2012-06-27 09:41:41 <setkeh> me
 71 2012-06-27 09:41:45 <cande> haha
 72 2012-06-27 09:41:45 <setkeh> XD
 73 2012-06-27 09:42:37 <cande> are the developers payed? or just donations?
 74 2012-06-27 09:43:19 <sipa> i don't think any of us is payed
 75 2012-06-27 09:43:57 <cande> if there was a feature list, one could donate to each feature to get it done
 76 2012-06-27 09:44:27 <MysteryBanshee> ohps its not anonymous anymore
 77 2012-06-27 09:44:40 <MysteryBanshee> :P
 78 2012-06-27 09:46:01 <cande> i think i hav heard that joke before..
 79 2012-06-27 09:46:10 <MysteryBanshee> it wasnt a joke lol
 80 2012-06-27 09:46:35 <Eliel> well, it became one now :D
 81 2012-06-27 09:47:43 <sipa> cande: sure donations are nice, but unless it's significant (and it's not reasonable to build an income from donations...), i'm not sure people would start putting more time into it than they already do
 82 2012-06-27 09:49:02 <cande> yes!
 83 2012-06-27 09:49:24 <cande> and they might become significant if someone really wants that feature
 84 2012-06-27 09:49:41 <MysteryBanshee> can I make a donation in exchange for a "Donate to MysteryBanshee" button being placed in the client?
 85 2012-06-27 09:50:19 <MysteryBanshee> (it has to be right next to the send button :P)
 86 2012-06-27 09:50:27 <sipa> right, that's the other point: if people start paying for a feature, the results may be not what everyone in the community wants
 87 2012-06-27 09:50:47 <cande> hmm
 88 2012-06-27 09:50:56 <cande> sipa interesting point
 89 2012-06-27 09:50:58 <sipa> cande: there was some call from someone on the forum who wanted to add multi-wallet support in the client
 90 2012-06-27 09:51:12 <sipa> he said he could do it, wanted to do it, but wanted to be payed for it
 91 2012-06-27 09:51:23 <MysteryBanshee> i think the client should support alternative chains like nmc and ltc
 92 2012-06-27 09:51:46 <sipa> just an alternative chain is pointless
 93 2012-06-27 09:51:54 <sipa> they are interesting because they are different
 94 2012-06-27 09:52:11 <sipa> they get to experiment with different rules, different features
 95 2012-06-27 09:52:33 <sipa> but two semi-identical competing chains doesn't help anyway
 96 2012-06-27 09:52:39 <sipa> *anyone
 97 2012-06-27 09:52:43 <cande> sipa, yes and one don't want to many features
 98 2012-06-27 09:53:48 <cande> perhaps there will be branches
 99 2012-06-27 09:54:04 <sipa> there are
100 2012-06-27 09:55:01 <cande> of bitcoind ?
101 2012-06-27 09:56:01 <sipa> yes
102 2012-06-27 09:56:29 <sipa> https://bitcointalk.org/index.php?board=67.0
103 2012-06-27 10:17:14 <cande> ah yes,, i meant different feature sets of bitcoind for the bitcoin network
104 2012-06-27 10:39:12 <BlueMatt> jgarzik: if we fix the block download mechanism to be more efficient and get the same performance as -loadblock, why do we need to distribute a -loadblock file via torrent?
105 2012-06-27 10:43:13 <BlueMatt> also, https://github.com/bitcoin/bitcoin/pull/973 helps block download efficiency a ton...
106 2012-06-27 10:45:16 <gmaxwell> It does?
107 2012-06-27 10:45:27 <BlueMatt> if the peer you are downloading from has it, yes
108 2012-06-27 10:45:39 <BlueMatt> (sends way more blocks in response to getblocks)
109 2012-06-27 10:45:51 <BlueMatt> (always sends the 500 limit instead of limiting based on block size)
110 2012-06-27 10:46:41 <BlueMatt> (like very old nodes used to)
111 2012-06-27 10:50:01 <gmaxwell> Right, but I can't imagine this helping a ton? the additional pipelining should be mostly important when the data sent is small, if you're roundtripping for every 5MBytes that should be no big deal Why is it?
112 2012-06-27 10:50:23 <BlueMatt> (in the current version of https://github.com/bitcoin/bitcoin/pull/1233 if touches cs_main at the end of the given list of blocks, so if you can get more blocks in between, it helps it quite a bit)
113 2012-06-27 10:50:56 <BlueMatt> for master nodes, the download is so inefficient anyway...
114 2012-06-27 10:52:15 <gmaxwell> in any case, if we eventually change to pulling headers first all that download stuff gets easier because we could pull blocks in parallel from multiple peers.
115 2012-06-27 10:53:02 <BlueMatt> yea
116 2012-06-27 10:54:36 <BlueMatt> anyway...back to removing slow locks from download
117 2012-06-27 11:02:28 <BlueMatt> can someone merge https://github.com/bitcoin/bitcoin.org/pull/42 to fix the website?
118 2012-06-27 11:04:45 <EricLombrozo> what's the current status on "nonstandard" transactions that bitcoind will relay?
119 2012-06-27 11:05:01 <BlueMatt> it wont
120 2012-06-27 11:05:16 <EricLombrozo> BIP 16 and 17 notwithstanding?
121 2012-06-27 11:05:37 <BlueMatt> BIP 16 defines new standard txes, which are relayed
122 2012-06-27 11:05:45 <BlueMatt> but bitcoind still wont relay nonstandard txes
123 2012-06-27 11:05:47 <EricLombrozo> ok, so then let me rephrase my question :)
124 2012-06-27 11:05:59 <EricLombrozo> what are the current standard transactions that bitcoind will relay?
125 2012-06-27 11:06:57 <EricLombrozo> is there a comprehensive list available anywhere with examples?
126 2012-06-27 11:06:59 <EricLombrozo> that would be beautiful
127 2012-06-27 11:07:15 <cande> is there a way to get an receiving adress from the bitcoind without also having the access to steal all the money ?
128 2012-06-27 11:07:36 <EricLombrozo> you mean via the RPC, cande?
129 2012-06-27 11:07:41 <BlueMatt> iirc (and I may be entirely wrong) it relays all bip16-output txes (because you cant tell if its standard until its spent) and will not relay non-standard spends once it knows the script in question is actually nonstandard
130 2012-06-27 11:08:05 <BlueMatt> cande: there are plans on being able to in the future, but not currently
131 2012-06-27 11:08:18 <EricLombrozo> cande, the workaround is to write a proxy
132 2012-06-27 11:08:28 <EricLombrozo> which only allows specific RPC calls
133 2012-06-27 11:08:47 <cande> RPC yes
134 2012-06-27 11:08:49 <sipa> cande: don't understand your question
135 2012-06-27 11:09:14 <BlueMatt> EricLombrozo: aside from bip16, the standard, it has to be TX_PUBKEY (spend-to-pubkey) TX_PUBKEYHASH (spend-to-address) or TX_MULTISIG (multisig with max n-of-3)
136 2012-06-27 11:09:14 <cande> sipa, if i want to send you money
137 2012-06-27 11:09:19 <cande> and you have a bitcoind running
138 2012-06-27 11:09:26 <cande> and can ask it directly
139 2012-06-27 11:09:30 <cande> for an receiving adress
140 2012-06-27 11:09:39 <BlueMatt> oh, yea, you have to use a proxy on top of bitcoind rpc for that
141 2012-06-27 11:09:42 <BlueMatt> cant do it directly
142 2012-06-27 11:09:54 <cande> if the wallet is encrypted?
143 2012-06-27 11:10:17 <EricLombrozo> I would still use a proxy :)
144 2012-06-27 11:10:27 <cande> ok :-)
145 2012-06-27 11:10:32 <BlueMatt> you have to unencrypt to get new addresses repeatedly (you can fill keypool and get n before you have to unlock)
146 2012-06-27 11:10:35 <EricLombrozo> the JSON-RPC is not as battlehardened against potential attacks and malformed requests as the p2p protocol, I don't think
147 2012-06-27 11:10:39 <BlueMatt> where n is the -keypoolsize
148 2012-06-27 11:11:17 <cande> so it's not a good idea to leave the JSON-RPC open for the public
149 2012-06-27 11:11:21 <EricLombrozo> no
150 2012-06-27 11:11:24 <BlueMatt> if there is a reasonable limit on how many addresses you want, you can just encrypt the wallet, but...
151 2012-06-27 11:11:28 <BlueMatt> no, dont leave it open
152 2012-06-27 11:11:43 <cande> ok, thx for the advice
153 2012-06-27 11:11:46 <BlueMatt> its also a fairly easy dos target
154 2012-06-27 11:11:51 <cande> is it hard to build a proxy ?
155 2012-06-27 11:12:12 <EricLombrozo> not really, assuming you have some basic coding skills
156 2012-06-27 11:12:40 <cande> basic yes
157 2012-06-27 11:13:29 <cande> doin the ruby way :-)
158 2012-06-27 11:13:50 <EricLombrozo> if you can accept HTTP requests and make HTTP requests it's just a couple more lines of code
159 2012-06-27 11:43:26 <EricLombrozo> according to the bitcoin protocol rules, coinbase is halved every 210,000 blocks. do we use floor(c/2) where c is in satoshis? or round(c/2)?
160 2012-06-27 11:43:43 <sipa> floor
161 2012-06-27 11:43:59 <sipa> it's an integer division of the amount in satoshi
162 2012-06-27 11:44:08 <EricLombrozo> ok, got it
163 2012-06-27 11:45:00 <EricLombrozo> so assuming the genesis block has height 0, block with height 210,000 will have a coinbase of 25e8 satoshis, block with height 420,000 will have coinbase 12.5e8 satoshis, etc...
164 2012-06-27 11:45:13 <sipa> indeed
165 2012-06-27 11:46:07 <EricLombrozo> since the height is not stored as part of the block structure, a receiving node can only verify this once the block is connected to the genesis block, right?
166 2012-06-27 11:46:37 <EricLombrozo> the amount for the first transaction output must total to coinbase + fees, right?
167 2012-06-27 11:47:20 <sipa> must not exceed
168 2012-06-27 11:47:34 <sipa> it can be less (though that would be a waste)
169 2012-06-27 11:47:37 <EricLombrozo> but until the height is known, the node cannot verify that it is valid in the general case
170 2012-06-27 11:47:42 <sipa> indeed
171 2012-06-27 11:48:10 <sipa> only basic validity checks are possible before linking to the block tree
172 2012-06-27 11:48:16 <EricLombrozo> for instance, say that blocks 209,999 and 210,000 are mined simultaneously and 210,000 claims a coinbase of 50
173 2012-06-27 11:48:24 <BlueMatt> you cant even check fees unless you have all the txins of txes in the block
174 2012-06-27 11:48:30 <EricLombrozo> yes, true
175 2012-06-27 11:48:35 <sipa> indeed, there are three stages
176 2012-06-27 11:49:21 <BlueMatt> theres at least one block that has a coinbase output of 1 satoshi + fees less than it could have
177 2012-06-27 11:49:23 <sipa> 1) basic checkblock 2) when storing after linking to the tree 3) when connecting the block to the main chain
178 2012-06-27 11:50:12 <EricLombrozo> why was it decided to not include the amount in inputs and the height in blocks? doesn't seem like it would amount to that much more space and would make verification simpler
179 2012-06-27 11:50:43 <EricLombrozo> nodes could still compress the blocks to save space locally
180 2012-06-27 11:50:55 <sipa> soon it may be the opposite
181 2012-06-27 11:51:33 <sipa> i'm working on a pruned mode that stores "undo information" together with blocks, but not keep historic data in the database
182 2012-06-27 11:51:37 <BlueMatt> height in blocks isnt really required, because all nodes can calculate that, amount in inputs...dunno originally, though with the coming filter stuff it doesnt really matter
183 2012-06-27 11:51:53 <EricLombrozo> nodes can calculate height only if the block is not orphaned
184 2012-06-27 11:52:18 <sipa> if the height was stored in headers you can do much more strict early validity checks
185 2012-06-27 11:52:35 <sipa> though with initial headers only mode, that is less of a problem
186 2012-06-27 11:53:32 <BlueMatt> sipa: ? you mean in CheckBlock() meh, we do the height-required checks right after the block gets connected anyway, and if its orphaned we dont really care about checking anyway
187 2012-06-27 11:53:57 <EricLombrozo> well, if it's malformed wouldn't you want to know ahead of time so you don't have to keep it around?
188 2012-06-27 11:54:01 <BlueMatt> (though, to be fair, orphan blocks do eat memory, would be nice to be able to check them more thoroughly, but it doesnt really make it harder to dos...)
189 2012-06-27 11:54:08 <sipa> right, but sending tons of low-difficulty orphans can lead to a memory dos attack
190 2012-06-27 11:54:50 <sipa> you could decide not to allow blocks before the last checkpoint, given that you already the checkpoint and its parents
191 2012-06-27 11:55:01 <sipa> s/allow/download/
192 2012-06-27 11:56:55 <BlueMatt> right now, to dos a node by filing it with low-diff orphans, you have to claim the blocks are long in the future using block timestamp, to do it if we had block height in blocks, you would have to lie on block height too, so it doesnt really make it harder
193 2012-06-27 12:13:23 <gmaxwell> 06:53 < EricLombrozo> well, if it's malformed wouldn't you want to know ahead of time so you don't have to keep it around?
194 2012-06-27 12:13:41 <gmaxwell> Yes, but you can verify the POW so any such attack will be computationally expensive.
195 2012-06-27 12:15:16 <gmaxwell> In the future we'll probably be forcing the coinbase to contain the height, in order to prevent duplicate coinbases... it would also allow a little stronger pre-connection testing, although nodes can potentially do an alternative fetching algorithim where it feteches, connects, and validates headers first before doing anything else.... which would basically close any attacks related to invalid blocks.
196 2012-06-27 12:20:11 <gavinandresen> That reminds me, I meant to implement the "smooth roll-out of blockchain changes" proposal https://gist.github.com/2355445  ... and then a pull for "version 2" blocks that include the height in the coinbase.
197 2012-06-27 12:31:43 <jgarzik> BlueMatt: because (1) the bitcoin protocol is simply not built for highly optimized, multi-peer file sharing, and (2) moving ancient blocks to torrent saves wear and tear on public nodes, who are constantly serving old blocks
198 2012-06-27 12:32:48 <sipa> i think we'll see a split between archive nodes (optimized for throughput and access to old blocks, but no mempool, recent blocks, full validation, tx serving, relaying, ...) and normal full nodes (which relay and serve recent blocks, but not old ones)
199 2012-06-27 12:33:02 <jgarzik> if you remove "serving old blocks" from public nodes, their disk cache hit rate improves
200 2012-06-27 12:33:20 <jgarzik> assuming you're not serving all that data from RAM/cache already, that is
201 2012-06-27 12:33:30 <sipa> that said, the sync mechanism can definitely be improved on the short term
202 2012-06-27 12:33:44 <sipa> and that remains useful in said scenario, for short-time syncups
203 2012-06-27 12:33:50 <BlueMatt> jgarzik: after sipa's prune stuff, the split between nodes who have old blocks and those who dont is part of the client
204 2012-06-27 12:34:05 <BlueMatt> jgarzik: so public nodes who have old blocks are there to serve them anyway at that point
205 2012-06-27 12:34:37 <BlueMatt> in terms of optimization, yea its not ideal, but the protocol itself really isnt that bad, it just needs a bit of optimization in the actual code (mostly overzealous locking)
206 2012-06-27 12:35:06 <jgarzik> no, peer selection tech continues to lag -far, far- behind the state of BT
207 2012-06-27 12:35:47 <BlueMatt> with sipa's stuff, the only nodes which set NODE_NETWORK will be archival nodes...
208 2012-06-27 12:36:02 <jgarzik> ...which does not address the issue at all
209 2012-06-27 12:36:04 <BlueMatt> and the peer selection already only choses NODE_NETWORK peers
210 2012-06-27 12:36:16 <BlueMatt> dnsseeds would have to be updated but...meh
211 2012-06-27 12:36:20 <BlueMatt> thats easy
212 2012-06-27 12:36:58 <jgarzik> You're aware that BT uses multiple peers, not just one, right?  you're aware that BT utilizes competition to determine the best peers, right?  You don't see any difference between bitcoin peer selection for block download, and BT's?
213 2012-06-27 12:37:36 <jgarzik> libtorrent++ even uses an AS map to better select peers and distribute data
214 2012-06-27 12:37:58 <BlueMatt> oh, you mean peer selection of peers we already have...well those are optimizations we need to do anyway
215 2012-06-27 12:38:00 <jgarzik> there is simply no comparison between BT and bitcoin, when it comes to downloading data
216 2012-06-27 12:38:11 <TD> of course. if the data was pre-indexed and shipped with the client, this problem would go away
217 2012-06-27 12:38:16 <sipa> anyone objects against pulling 457, 973, 1245, 1246, 1347, 1396, 1409, 1494 ?
218 2012-06-27 12:38:23 <TD> because people would get the chain as part of the initial software download, via whatever protocol they preferred
219 2012-06-27 12:38:34 <BlueMatt> and if you do something like https://github.com/bitcoin/bitcoin/pull/1233 you can easily get to the limiting factor of block checking instead of network in all cases where bt would help
220 2012-06-27 12:39:38 <sipa> gavinandresen, jgarzik, gmaxwell: ^
221 2012-06-27 12:39:57 <gmaxwell> 07:35 < jgarzik> no, peer selection tech continues to lag -far, far- behind the state of BT
222 2012-06-27 12:40:09 <BlueMatt> really just downloading  blocks from multiple peers concurrently and ignoring peers that are really slow should be able to get to where the block checking is the limit imho
223 2012-06-27 12:40:12 <gmaxwell> ^ Bleh. Totally different goals. BT is _not_ attack resistant.
224 2012-06-27 12:40:23 <gmaxwell> It's relatively easy to isolate BT nodes.
225 2012-06-27 12:41:26 <gmaxwell> getting the most traffic efficient p2p behavior is somewhat at odds with making sure the network is resistant to attakers who would try to partition it. And thats okay. We should be able to hide the fact that syncing takes a little while from the user.
226 2012-06-27 12:41:44 <gmaxwell> sipa: looking
227 2012-06-27 12:42:09 <gavinandresen> sipa: 457 : no objections
228 2012-06-27 12:42:49 <TD> if somebody could test the leveldb code, that'd help with speeding up chain sync :)
229 2012-06-27 12:42:56 <TD> and block propagation, probably
230 2012-06-27 12:43:24 <jgarzik> gmaxwell: if BT does not work, it is easy to fallback to the primary method of using a network unsuited for large data transit
231 2012-06-27 12:44:26 <jgarzik> There does not appear to be another development on the horizon that will ease the burden of public nodes (WRT serving old blocks constantly)
232 2012-06-27 12:44:34 <gmaxwell> I've not reviwed 457 but no principled objections; 973 I think we should pull and I reviewed a bit in the past, it needs testing but pulling it will cause that, 1245 I believe I tested at one point, 1246 sounds great, I thought we pulled 1347 already
233 2012-06-27 12:45:05 <gmaxwell> jgarzik: I haven't seen any evidence of significant burden except for the fact that the current behavior of pulling all blocks from a single peer creates spiky traffic.
234 2012-06-27 12:45:35 <sipa> TD: i'll gladly test it after pruning works (i'm especially curious in the speedup by combining them)
235 2012-06-27 12:45:40 <BlueMatt> jgarzik: sipa's pruning stuff will, and I believe rebroad was looking into downloading from multiple peers concurrently
236 2012-06-27 12:45:57 <jgarzik> sipa: RE 457 -- do we really want to force non-GUI to use uiinterface.queueshutdown() ??
237 2012-06-27 12:46:16 <gmaxwell> Meh on 1396. I don't know that its needed.
238 2012-06-27 12:46:17 <jgarzik> gmaxwell: my public nodes are constantly serving old blocks, hitting the disk because they are not SSD (yet).
239 2012-06-27 12:46:26 <gavinandresen> 1246 : love the new unit tests, but I need to set aside some time to convince myself that the changes to the Connect/Check logic is correct
240 2012-06-27 12:46:49 <BlueMatt> jgarzik: that said, adding http support for -loadblock would be interesting, way simpler than implementing bt, and then you can just run a bunch of mirrors instead
241 2012-06-27 12:46:52 <jgarzik> gmaxwell: I imagine on more resource-constrained nodes, e.g. DSL or cable modem, you will be uploading blocks and impact your TX/block latency
242 2012-06-27 12:47:00 <sipa> jgarzik: i certainly prefer one single interface over #ifdef UI stuff
243 2012-06-27 12:47:04 <BlueMatt> yea, not as secure, but meh
244 2012-06-27 12:47:04 <TD> jgarzik: a good place to start might be to have a hint flag in addr broadcasts saying you are willing to serve the chain in bulk and then having those be preferred
245 2012-06-27 12:47:14 <sipa> jgarzik: but it's not a requirement for me; the rest of the patch is more important
246 2012-06-27 12:47:37 <TD> as long as the connection was dropped and re-assigned to a different node after download was done
247 2012-06-27 12:47:40 <jgarzik> sipa: just noting what I see in #457...  that is the only questionable bit.  otherwise 457 looks ACK-worthy
248 2012-06-27 12:48:07 <BlueMatt> TD: The way I see it NODE_NETWORK should slowly morph into that
249 2012-06-27 12:48:16 <BlueMatt> TD: allows for backward-compat after pruning
250 2012-06-27 12:48:29 <gmaxwell> jgarzik: I've actually measured that and pulling the chain caused almost no disk IO.
251 2012-06-27 12:48:31 <jgarzik> 973 has my ACK
252 2012-06-27 12:48:46 <gmaxwell> (because it ends up satisfied by cache)
253 2012-06-27 12:49:03 <jgarzik> gmaxwell: that presumes it is a beefy box that can cache it all
254 2012-06-27 12:49:10 <jgarzik> gmaxwell: including BDB data
255 2012-06-27 12:49:37 <jgarzik> gmaxwell: if you do not have 100% data cachable / tmpfs, you face a cliff of I/O
256 2012-06-27 12:50:03 <jgarzik> and there's ONE source of queries that hits old data (old block serving)
257 2012-06-27 12:50:50 <jgarzik> 1245 - presumably gavinandresen and sipa have thought about this one, I'll let their ACKs stand :)
258 2012-06-27 12:51:21 <gmaxwell> jgarzik: even so most users will be network bottlenecked on that, not anywhere near IO bottlenecked. (If you have a 10MByte/s+ network connection you can probably afford a bit more ram or a ssd. :) )
259 2012-06-27 12:51:51 <BlueMatt> jgarzik: I absolutely agree we should work on lowering the load on public nodes who dont really want to serve the full chain, but I think pruning addresses that nicely without having to pull in yet another lib and yet another feature
260 2012-06-27 12:52:12 <gmaxwell> Regardless, I'm now not sure what we're discussing. I certantly think we should pull blocks from more peers to spread the load out... and could preference based on the peer IDs to improve cache locality.
261 2012-06-27 12:52:54 <gmaxwell> sipa: re: 1494 ... I do think we need some infrastructure to better test that stuff. Perhaps some kind of parallel RPC fuzzer.
262 2012-06-27 12:53:23 <gmaxwell> (I don't object to pulling it now, but the rpc locking changes basically mean I think having better testing will block 0.7.0 release)
263 2012-06-27 12:54:21 <jgarzik> sipa: 1409 - don't care.  just worried it is a luke-jr-only change.
264 2012-06-27 12:54:27 <gavinandresen> 1494 : as I said in the pull, I like the other, table-driven approach better.
265 2012-06-27 12:55:11 <jgarzik> Can I get ACK's for 1512, JSON-RPC 2.0 batches?
266 2012-06-27 12:55:13 <gavinandresen> 1409: ok with me
267 2012-06-27 12:55:26 <gavinandresen> jgarzik: I was testing 1512 before this ACK-fest....
268 2012-06-27 12:55:36 <gmaxwell> jgarzik: nah, 1409 isn't luke-jr only. Weirdness with generated coin is a common complaint, a couple other pools (including p2pool) pay users in the coinbase. Miner-only is a valid criticism, but the current behavior is weird.
269 2012-06-27 12:55:46 <sipa> agree with gmaxwell
270 2012-06-27 12:55:54 <jgarzik> fair enough then (re 1409)
271 2012-06-27 12:56:25 <sipa> jgarzik: haven't checked the code for 1512, but i certainly want it merged
272 2012-06-27 12:57:05 <BlueMatt> gavinandresen: re:1494 I would hope mergers are paying attention enough to not merge rpcs that need locks...in the past it may have been a problem, but to me doing the locking in the rpc calls themselves is just much cleaner, instead of having locks in multiple places, just seems like that would make it harder to verify
273 2012-06-27 12:57:09 <BlueMatt> but...meh
274 2012-06-27 12:57:29 <gmaxwell> Can 1393 get some more comments?  Luke wrote that as a response to a long bitcointalk thread and it's fixing a common point of confusion.  The mechanism seemed a bit awkward to me, but I didn't see an obviously better way to do it.
275 2012-06-27 12:58:38 <gmaxwell> BlueMatt: that kind of fear is why I think async rpc means we need better tests. Right now I think that it's highly likely that we could ship a repeatable deadlock w/ concurrent use of just about any random pair of rpcs.
276 2012-06-27 12:58:40 <gavinandresen> BlueMatt: The JSON-2.0 Batch pull influences my thinking a little bit-- we might find ourselves wanting the call-a-bunch-of-routines to get locks once, instead of getting them over and over
277 2012-06-27 12:58:41 <sipa> about 1393: i'm not using that feature myself enough to comment
278 2012-06-27 12:59:10 <gavinandresen> BlueMatt: .... but that might just be premature optimization on my part.
279 2012-06-27 12:59:27 <BlueMatt> gmaxwell: DEBUG_LOCKORDER helps a /ton/, but I agree, more automated tests would be nice (jenkins is available if anyone wants to write such tests in a ways they can be bash-scripted)
280 2012-06-27 12:59:27 <sipa> gavinandresen: or even schedule the order of dealing with a batch request so that non-conflicting ones are executed simultaneously
281 2012-06-27 12:59:30 <gmaxwell> gavinandresen: sounds impossible to debug.
282 2012-06-27 13:00:13 <sipa> but eventually we need to a move to something more 1494-like, imho
283 2012-06-27 13:00:43 <sipa> (and even further, move locking to the blockdb/wallet/net subsystem code instead of RPC)
284 2012-06-27 13:00:47 <BlueMatt> gavinandresen: hmm...I actually kinda prefer repeated locks instead of locking before and running once, as it lets other threads run in between instead of blocking for a huge amount of time...also, I was thinking of shared locks which further complicates the list of rpcs that need locks
285 2012-06-27 13:01:34 <BlueMatt> yea its less efficient, but it can make things seem more responsive
286 2012-06-27 13:01:51 <gavinandresen> BlueMatt: I'm thinking of things like "I want to get information about these 50 transactions" -- locking for lightweight operations might become a bottleneck
287 2012-06-27 13:02:19 <gavinandresen> (and it'd be special code like "If the batch is all gettransaction requests then...."
288 2012-06-27 13:02:28 <gmaxwell> I would _expect_ the actual lookup cost to dwarf taking the lock.. but I'm speculating there.
289 2012-06-27 13:02:30 <BlueMatt> meh, pthread locks are pretty damn fast
290 2012-06-27 13:02:37 <sipa> BlueMatt: if uncontended
291 2012-06-27 13:03:03 <gmaxwell> yea, two concurrent batch-get-txn might be a bit thrashy.
292 2012-06-27 13:03:05 <gavinandresen> All premature optimization, but that type of thing is why I like the idea of a data-driven table that says what locks a RPC call will need.
293 2012-06-27 13:03:07 <sipa> a bit more generally: group rpc calls per call type, and change the RPC functions to accept a list of arguments, and let them deal with it if they can
294 2012-06-27 13:03:10 <BlueMatt> sipa: and if they are contended, then I would prefer to have the additional locks
295 2012-06-27 13:03:48 <gmaxwell> Another option is to just have special cases for the json batch requests: e.g. if-all-these-are-gettxn-then-call-batch-gettxn-instead
296 2012-06-27 13:04:01 <gavinandresen> (running batch RPC calls in parallel as sipa suggests, is more likely)
297 2012-06-27 13:04:22 <BlueMatt> it will mean both batches return at the same time instead of one before the other, but they will run in the same total time...
298 2012-06-27 13:04:23 <gmaxwell> sipa: yea, thats basically what I was thinking.
299 2012-06-27 13:04:46 <sipa> well, once we have shared locks, you can have two threads have a readonly wallet lock, and have them both do gettransaction processing without contention
300 2012-06-27 13:04:53 <gmaxwell> Less trouble with special cases where something should or shouldn't drop the lock based on external conditionals... and weird bugs like closing your rpc connection prematurely leaves locks held.
301 2012-06-27 13:05:56 <BlueMatt> sipa: yep, shared locks is really why I prefer the in-function locking instead of table locking...though I agree grouping rpc functions would be better, at least by far for code readability anyway
302 2012-06-27 13:08:23 <gavinandresen> mmm.  I'll ACK 1494, we can always switch Yet Again, and 1494 is definitely better than what we have now.  Assuming the locking actually is correct and doesn't introduce nasty hard-to-debug "shoulda held that lock" bugs.
303 2012-06-27 13:09:10 <sipa> only stop and help don't get locks, afaik
304 2012-06-27 13:09:26 <sipa> so it should be conservative
305 2012-06-27 13:11:21 <gmaxwell> sipa: on 1393, does the method of stuffing in the extra ordering/timestamp data into the wallet give you hives?
306 2012-06-27 13:11:56 <gmaxwell> sipa: see https://github.com/luke-jr/bitcoin/commit/bf8084dc584daca39ccf2d9b10e91855aad7615b
307 2012-06-27 13:13:00 <sipa> gmaxwell: it feels dirty
308 2012-06-27 13:13:50 <sipa> but storing ordering information separate would be a waste of resources (and wallet load time)
309 2012-06-27 13:14:04 <gmaxwell> this was my only concern with that pull, other than just it generally needs a lot of beating on.
310 2012-06-27 13:14:32 <luke-jr> jgarzik: I don't make pull requests for luke-jr-only changes.
311 2012-06-27 13:15:06 <gmaxwell> luke-jr: you have a different opinion of what constitutes a luke-jr only change from some other people!
312 2012-06-27 13:15:38 <gmaxwell> (fortunately, it doesn't take much to prove something is not a luke-jr-only-change
313 2012-06-27 13:15:41 <gmaxwell> )
314 2012-06-27 13:16:35 <luke-jr> gmaxwell: the problem is usually that jgarzik likes to throw that around as an excuse to NACK lots of generally useful things
315 2012-06-27 13:17:19 <jgarzik> The problem is that is takes time to separate luke-jr noise from luke-jr signal
316 2012-06-27 13:17:53 <BlueMattBot> Project Bitcoin build #370: FAILURE in 25 min: http://jenkins.bluematt.me/job/Bitcoin/370/
317 2012-06-27 13:18:04 <gmaxwell> luke-jr: You shouldn't need to worry about it other people should be looking out for those things to prevent that from happening.
318 2012-06-27 13:18:26 <gmaxwell> bitcoinrpc.cpp: In function void RPCAcceptHandler(boost::shared_ptr<boost::asio::basic_socket_acceptor<Protocol, SocketAcceptorService> >, boost::asio::ssl::context&, bool, AcceptedConnection*, const boost::system::error_code&):
319 2012-06-27 13:18:30 <gmaxwell> bitcoinrpc.cpp:2771: error: reference to error is ambiguous
320 2012-06-27 13:18:32 <gmaxwell> util.h:135: error: candidates are: bool error(const char*, ...)
321 2012-06-27 13:18:35 <gmaxwell> /mnt/mingw/boost_1_47_0/boost/asio/error.hpp:57: error:                 namespace boost::asio::error { }
322 2012-06-27 13:19:01 <sipa> hmm :'(
323 2012-06-27 13:19:37 <genjix> i see nothing called error there to cause the conflict?
324 2012-06-27 13:20:22 <genjix> oh, yeah you should change that
325 2012-06-27 13:20:30 <genjix> error is now also part of the new c++11 standard
326 2012-06-27 13:20:46 <genjix> http://stackoverflow.com/questions/9760851/stderror-code-my-errorcheck-block-my-errorvalidate-my-erroraccept
327 2012-06-27 13:43:24 <BlueMattBot> Project Bitcoin build #371: STILL FAILING in 25 min: http://jenkins.bluematt.me/job/Bitcoin/371/
328 2012-06-27 13:48:51 <jgarzik> ACK troll - quieten 'getdata' a bit - https://github.com/bitcoin/bitcoin/pull/1511
329 2012-06-27 13:49:21 <jgarzik> collapses 500-inv getdata into one line, yet iff inv.size() == 1, leaves the verbose line as-is
330 2012-06-27 13:49:50 <jgarzik> makes logs much more watchable on a busy public node
331 2012-06-27 14:01:31 <jgarzik> someone should dig out the luke-jr bugfix from https://github.com/bitcoin/bitcoin/pull/1240
332 2012-06-27 14:01:33 <jgarzik> the first commit
333 2012-06-27 14:07:52 <jgarzik> gavinandresen: RE your batch comment: I agree it does not match spec... but it does match prior bitcoin json-rpc behavior in the face of an invalid request.
334 2012-06-27 14:08:13 <jgarzik> gavinandresen: so it required an Executive Decision :)
335 2012-06-27 14:08:51 <gavinandresen> Ideally, you'd see if "jsonrpc":"2.0" was in the request and then Do The Right Thing
336 2012-06-27 14:09:10 <gavinandresen> (match the JSON 2.0 spec, or do the old backwards-compatible thing)
337 2012-06-27 14:09:12 <jgarzik> OK, will separate the behaviors
338 2012-06-27 14:09:30 <jgarzik> (after lunch)
339 2012-06-27 14:09:38 <gavinandresen> lunch, good idea
340 2012-06-27 14:10:00 <sipa> dinner, good idea
341 2012-06-27 14:17:29 <genjix> http://i.imgur.com/FhuC7.png <- can i push this change to bitcoin.org?
342 2012-06-27 14:17:44 <genjix> (see bottom right)
343 2012-06-27 14:23:49 <BlueMatt> genjix: you could just pull request it first...
344 2012-06-27 14:25:40 <gavinandresen> genjix:  ok with me
345 2012-06-27 14:26:52 <genjix> BlueMatt: sure but it's small.
346 2012-06-27 14:27:02 <genjix> gavinandresen: thanks
347 2012-06-27 14:27:12 <luke-jr> genjix: but it also makes it easy to see what changed :p
348 2012-06-27 14:27:39 <genjix> ok i can do that, but just curious: what's the difference to a commit log?
349 2012-06-27 14:28:03 <Diapolo> luke-jr: Can you please close some of your solve GUI issues on Github :). It starts to get hard keeping an overview.
350 2012-06-27 14:28:29 <BlueMatt> genjix: oh, I dont really care, but it makes it easy for anyone who may disagree to voice there opinion, instead of asking on irc
351 2012-06-27 14:28:47 <genjix> btw i the contributors.rb plugin is broken
352 2012-06-27 14:28:52 <genjix> the url inside it doesn't work.
353 2012-06-27 14:29:32 <BlueMatt> s/is/was/
354 2012-06-27 14:31:15 <lordcirth> Anyone capable of helping me with Armory?
355 2012-06-27 14:31:18 <genjix> BlueMatt: if you want to do the honour https://github.com/bitcoin/bitcoin.org/pull/43
356 2012-06-27 14:31:26 <genjix> lordcirth: maybe etotheipi_ is around :)
357 2012-06-27 14:31:47 <genjix> if not you can email him using his nickname @ gmail.com
358 2012-06-27 14:32:06 <BlueMatt> genjix: I dont have push on that repo
359 2012-06-27 14:32:06 <gribble> New news from bitcoinrss: genjix opened pull request 43 on bitcoin/bitcoin.org <https://github.com/bitcoin/bitcoin.org/pull/43>
360 2012-06-27 14:32:12 <genjix> ok
361 2012-06-27 14:32:18 <lordcirth> genjix: Not on Freenode. Hasn't replied to his email, I'll try that email address
362 2012-06-27 14:32:44 <BlueMattBot> Project Bitcoin build #372: STILL FAILING in 25 min: http://jenkins.bluematt.me/job/Bitcoin/372/
363 2012-06-27 14:32:52 <genjix> ok whateveer, i pulled it
364 2012-06-27 14:33:30 <genjix> also pulled this https://github.com/bitcoin/bitcoin.org/pull/39
365 2012-06-27 14:41:56 <genjix> Tuxavant: bitcoin informant sounds like the magazine for the stasi department of #bitcoin-police
366 2012-06-27 14:41:59 <genjix> not sure if intentional
367 2012-06-27 14:42:10 <gribble> New news from bitcoinrss: TheBlueMatt reopened pull request 1453 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1453>
368 2012-06-27 14:50:11 <Tuxavant> genjix, lol... it's a bit of a play on words... informants keep you informed
369 2012-06-27 14:50:30 <genjix> Tuxavant: for your own good :)
370 2012-06-27 14:50:58 <Tuxavant> exactly!
371 2012-06-27 14:51:31 <Tuxavant> I gotta say, I'm very surprised with the stats I'm getting from google analytics... Vietnam is kicking everyone's ass as far as downloads of this weekly newsletter
372 2012-06-27 14:51:45 <Karmaon> lol google analytics
373 2012-06-27 14:51:53 <Tuxavant> second week in a row they've dominated per country download stats
374 2012-06-27 14:52:27 <Tuxavant> http://i.imgur.com/tZhyb.png
375 2012-06-27 14:55:13 <quintopia> Tuxavant: link to the newsletter. FOR THE USA
376 2012-06-27 14:55:32 <Tuxavant> BitcoinInformant.com/download (for everything)
377 2012-06-27 14:55:38 <Tuxavant> 8 languages so far
378 2012-06-27 14:57:18 <Tuxavant> derp. 7 - waiting for deutch to jump in. perhaps next week
379 2012-06-27 14:57:41 <Tuxavant> quintopia, .
380 2012-06-27 14:57:57 <Diapolo> luke-jr: thanks for cleaning up :)
381 2012-06-27 14:58:15 <luke-jr> Diapolo: sorry for procrastinating as long as I did :p
382 2012-06-27 14:59:54 <genjix> Tuxavant: could it be bad stats?
383 2012-06-27 14:59:57 <genjix> i.e people using tor .etc
384 2012-06-27 15:00:11 <Diapolo> luke-jr: np, Did you take a look at the QR Code pull? Perhaps an ack for the sign/verify UI ;)?
385 2012-06-27 15:06:04 <luke-jr> Diapolo: I didn't notice a QR Code pull
386 2012-06-27 15:07:58 <Tuxavant> genjix, i dont think so... one of my vietnamese friends has been actively promoting his translations in some bitcoin related forums
387 2012-06-27 15:08:47 <genjix> Tuxavant: ahh it has i18n
388 2012-06-27 15:09:01 <Tuxavant> genjix, ?
389 2012-06-27 15:09:06 <Tuxavant> il8n?
390 2012-06-27 15:10:12 <Diapolo> luke-jr: https://github.com/bitcoin/bitcoin/pull/1518
391 2012-06-27 15:11:28 <genjix> Tuxavant: programmer speak for internationalisation
392 2012-06-27 15:13:44 <Tuxavant> genjix, ah.. it's all volunteerism... i send out the source files in SVG on friday and get them back on sunday, make some final changes and publish monday morning PST
393 2012-06-27 15:15:13 <genjix> nice
394 2012-06-27 15:32:59 <MysteryBanshee> Team Challenge starting in #btc-mystery soon - Win 3BTC
395 2012-06-27 15:42:33 <PK> MysteryBanshee: did you try making special looking QRs now?
396 2012-06-27 15:42:55 <genjix> PK: http://bitcoin-hackathon.com/
397 2012-06-27 15:43:57 <PK> ah, updates :)
398 2012-06-27 15:44:41 <PK> did you count me in already or are there going to be other swiss too?
399 2012-06-27 15:45:32 <MysteryBanshee> PK: not yet
400 2012-06-27 15:45:44 <MysteryBanshee> were splitting a private key into 7 parts for a specail mega team challenge
401 2012-06-27 15:45:52 <MysteryBanshee> 6 parts sorry
402 2012-06-27 15:47:38 <genjix> PK: oh wow you're coming sweeet
403 2012-06-27 15:47:47 <genjix> PK: yeah mike hearn and stefan thomas are coming
404 2012-06-27 15:47:58 <genjix> let me know if you wanna crash with me
405 2012-06-27 15:48:36 <PK> where do you crash?
406 2012-06-27 15:49:05 <genjix> i live in berlin
407 2012-06-27 15:50:51 <PK> cool, I always thought you'd live in the UK.
408 2012-06-27 15:51:32 <genjix> also we have 10 crates of rum :)
409 2012-06-27 15:51:43 <jgarzik> hrm
410 2012-06-27 15:51:54 <jgarzik> did I kill the RPC server, or someone else?  Let's see...
411 2012-06-27 15:52:12 <jgarzik> shutdown is rather abrupt, in git HEAD + json-batch
412 2012-06-27 15:52:44 <jgarzik> my gut says the IPv6 RPC stuff is problematic
413 2012-06-27 15:53:41 <PK> genjix: like true pirates :)
414 2012-06-27 15:54:31 <jgarzik> yep
415 2012-06-27 15:54:36 <jgarzik> git HEAD crashes on shutdown now
416 2012-06-27 15:54:58 <jgarzik> eliminated json-batch as cause
417 2012-06-27 15:56:46 <genjix> PK: the song of my people http://www.youtube.com/watch?v=SLMJpHihykI
418 2012-06-27 15:58:07 <PK> genjix: in germany probably more like http://www.youtube.com/watch?v=KLTv-hCSvKc
419 2012-06-27 16:00:09 <genjix> pirate partei
420 2012-06-27 16:01:47 <gavinandresen> jgarzik: possibly related: I got bitcoind(21280,0xb0185000) malloc: *** error for object 0x2100350: pointer being freed was not allocated   ... at shutdown (but cannot reproduce right now)
421 2012-06-27 16:02:02 <gavinandresen> jgarzik: could be a destructor race condition
422 2012-06-27 16:03:13 <jgarzik> alas, I cannot do much more than file an issue right now :/
423 2012-06-27 16:03:43 <gribble> New news from bitcoinrss: jgarzik opened issue 1524 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1524>
424 2012-06-27 16:18:51 <gribble> New news from bitcoinrss: gavinandresen opened pull request 1525 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1525>
425 2012-06-27 18:30:12 <Karmaon> luke-jr: does bitcoin next have rpc commands for coin control?
426 2012-06-27 18:31:13 <luke-jr> Karmaon: I think so?
427 2012-06-27 18:31:19 <luke-jr> well, next-test at least
428 2012-06-27 18:31:22 <luke-jr> next only has ACK'd stuff
429 2012-06-27 18:36:29 <Karmaon> luke-jr: i don't see any particular new commands with next-test
430 2012-06-27 18:36:51 <Karmaon> are they listed in 'help'?
431 2012-06-27 18:38:55 <luke-jr> Karmaon: not sure
432 2012-06-27 19:10:13 <maaku> robocat
433 2012-06-27 19:10:43 <maaku> n/m wrong channel :\n3866577
434 2012-06-27 21:24:55 <midnightmagic> does my node send out an addressbook of *all* nodes it knows about when someone asks for it?
435 2012-06-27 21:25:04 <midnightmagic> that haven't been banned, etc etc
436 2012-06-27 21:25:53 <midnightmagic> or is it just a subset based on that new addressbook stuff sipa was doing? (apologies to the real coder if it wasn't sipa)
437 2012-06-27 21:51:02 <gribble> New news from bitcoinrss: gavinandresen opened pull request 1526 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1526>
438 2012-06-27 21:58:22 <genjix> midnightmagic: just a random subset
439 2012-06-27 22:40:42 <graingert> is anyone free to lay down some justice in #bitcoin
440 2012-06-27 22:41:18 <guruvan> oh ugh....deathbylollipop in da house
441 2012-06-27 23:17:43 <gribble> New news from bitcoinrss: ThePiachu opened issue 1527 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1527>
442 2012-06-27 23:35:55 <sipa> gmaxwell: mind testing my 'unstuck4' branch?
443 2012-06-27 23:36:24 <sipa> i did a full block chain download with it, and without any duplicate getblocks requests, but it may be luck
444 2012-06-27 23:37:21 <gmaxwell> Sure.
445 2012-06-27 23:50:57 <antkingtube> haha gmaxwell just got arrested
446 2012-06-27 23:51:00 <antkingtube> fucking nig
447 2012-06-27 23:55:07 <galambo__> did i just fall in a time machine? back to high school?
448 2012-06-27 23:55:32 <gmaxwell> dunno why this random idiot has a newfound fixation on me ::shrugs::
449 2012-06-27 23:55:50 <luke-jr> gmaxwell: the random IRC flooding idiots usually seem to
450 2012-06-27 23:56:02 <luke-jr> gmaxwell: PMs btw
451 2012-06-27 23:56:04 <gmaxwell> It must be my manly beard.
452 2012-06-27 23:57:52 <gmaxwell> sipa: hm, is the && !mapAlreadyAskedFor.count(inv) going to result in baddness when a peer goes away and we don't request that block from other peers?
453 2012-06-27 23:58:46 <sipa> gmaxwell: that third if-then-else case is only for the situation where a too long chain is being reconnected