1 2013-02-01 00:07:04 <num1> Say I were a developer who wanted to start contributing to bitcoin and learn more about the network, where would be a good place to start?
  2 2013-02-01 00:08:22 <CodeShark> here
  3 2013-02-01 00:08:58 <CodeShark> first master this document: https://en.bitcoin.it/wiki/Protocol_specification
  4 2013-02-01 00:10:02 <copumpkin> in the avalon review, he says that the network will become far more secure
  5 2013-02-01 00:10:05 <copumpkin> I'm not sure I buy that
  6 2013-02-01 00:11:32 <Scrat> copumpkin: if ASICs are the last stage of the evolution then the network will be more secure if everyone has access to them
  7 2013-02-01 00:12:06 <Scrat> whereas previously only a well funded attacker could have done that
  8 2013-02-01 00:12:13 <Scrat> thats the way I see it
  9 2013-02-01 00:12:19 <copumpkin> well, my point is that a well funded attacker can just buy a fuckton of avalon ascis now
 10 2013-02-01 00:12:19 <sipa> i agree
 11 2013-02-01 00:12:23 <num1> As far as code goes there's not a big body to learn about right? You have the official client which talks on the network to gossip about blocks and transactions, mines, and verifies blocks.
 12 2013-02-01 00:12:35 <copumpkin> so the determining factor is the distribution of the commonly available units
 13 2013-02-01 00:12:40 <copumpkin> and not their power
 14 2013-02-01 00:12:45 <copumpkin> or is that wrong?
 15 2013-02-01 00:13:05 <num1> Are there any other big things I'm missing or popular alternative implementations?
 16 2013-02-01 00:13:07 <sipa> num1: the code of the reference client is not that much, but it's not easy to understand all details (and it's not written very elegantly)
 17 2013-02-01 00:13:56 <Scrat> their supply is limited
 18 2013-02-01 00:14:08 <sipa> copumpkin: agree, it's the distribution that is relevant
 19 2013-02-01 00:14:32 <copumpkin> Scrat: but they're going to turn it up if they get a huge order. It might be lagged, but that's how markets work
 20 2013-02-01 00:14:43 <sipa> copumpkin: but consider this: 1) the evolution to specialized chips was inevitable  2) the alternative was a cartel of miners investing in chips that would only be available to them
 21 2013-02-01 00:14:57 <copumpkin> yeah
 22 2013-02-01 00:15:03 <copumpkin> so it is improving things
 23 2013-02-01 00:15:20 <sipa> you may argue whether it's an improvement versus the current situation
 24 2013-02-01 00:15:22 <copumpkin> because we're getting closer to state of the art and are likely unable to squeeze major increments out past this point
 25 2013-02-01 00:15:32 <Scrat> it will be just like gpus/fpgs. the difference is that there wont be a huge performance jump after that, only incremental increases
 26 2013-02-01 00:15:33 <sipa> but it's certainly the lesser evil of two possible futures
 27 2013-02-01 00:16:57 <Scrat> although one might argue that going from 110 nm to 3x nm is more than a generational increase
 28 2013-02-01 00:17:10 <sipa> BFL's chips are (allegedly) 65nm, iirc
 29 2013-02-01 00:23:53 <tradefortress> is there any way to find out which pool relayed a block? it seems like Deepbit & slush are relaying from the same IP
 30 2013-02-01 00:24:06 <sipa> you know what 'relay' means?
 31 2013-02-01 00:24:25 <sipa> it's very unlikely that they do not both relay it at some point
 32 2013-02-01 00:25:43 <sipa> if you want to know who produced it: no way of being certain
 33 2013-02-01 00:26:10 <sipa> blockchain.info uses the IP they first saw a block being relayed from as a way for determining the source
 34 2013-02-01 00:26:26 <sipa> this is however known to be frequently wrong
 35 2013-02-01 00:27:04 <tradefortress> I don't think it determines it with relayed by
 36 2013-02-01 00:27:15 <tradefortress> because a "Deepbit" block and a "Slush" block had the same IP
 37 2013-02-01 00:27:20 <tradefortress> yet it says they're from different pools.
 38 2013-02-01 00:27:39 <sipa> ah, maybe it now retrieves information about blocks from the pools themself
 39 2013-02-01 00:27:56 <doublec> or from information in the coinbase
 40 2013-02-01 00:28:04 <slush> tradefortress: that IP is just an IP of node who firstly relayed it
 41 2013-02-01 00:28:26 <CodeShark> no, it's the IP address of the first computer that blockchain.info got it from :)
 42 2013-02-01 00:28:32 <CodeShark> doesn't mean it was the first to relay it
 43 2013-02-01 00:29:06 <gmaxwell> it does multiple things ... which just makes its failure modes more confusing.
 44 2013-02-01 00:30:42 <slush> CodeShark: you're right, I mean "..who firstly relayed it to blockchain.info"
 45 2013-02-01 00:31:34 <sipa> someone should build a faster relayer that is connected to everyone, and relay everything to blockchain.info first
 46 2013-02-01 00:31:43 <sipa> just to screw up the statistics :p
 47 2013-02-01 00:32:01 <tradefortress> kay, so I guess I can't find out which pool mined a block :/
 48 2013-02-01 00:32:23 <sipa> tradefortress: just go to the websites of the largest pools and see whether they mention the block?
 49 2013-02-01 00:32:36 <doublec> tradefortress: try http://blockorigin.pfoe.be/blocklist.php
 50 2013-02-01 00:32:44 <doublec> tradefortress: which does what sipa suggests
 51 2013-02-01 00:32:49 <doublec> tradefortress: and aggregates it
 52 2013-02-01 00:32:51 <gmaxwell> tradefortress: depends on what you need to know it for...
 53 2013-02-01 00:33:06 <tradefortress> ah cool, what about deepbit delaying it by 1 hour?
 54 2013-02-01 00:33:17 <gmaxwell> if e.g. you need to know it in a way which is robust against pools _lying_ then there is no way to know for sure.
 55 2013-02-01 00:33:54 <doublec> tradefortress: the pools that fdelay show as unknown on that site until the pool publishes the data
 56 2013-02-01 00:34:11 <moore> sipa if you could build a faster relayer you could just "cheat" at satoshidice.com
 57 2013-02-01 00:34:21 <moore> that would be even more fun
 58 2013-02-01 00:37:59 <HM> <copumpkin> well, my point is that a well funded attacker can just buy a fuckton of avalon ascis now
 59 2013-02-01 00:39:02 <HM> copumpkin: the difficulty will rise if that happens making it unviable except for anyone intent on destroying bitcoin regardless of cost
 60 2013-02-01 00:39:20 <HM> copumpkin: and there are easier ways to destroy bitcoin if someone powerful enough wanted to
 61 2013-02-01 00:39:40 <HM> or at least set it bacl
 62 2013-02-01 00:39:42 <HM> back
 63 2013-02-01 00:40:14 <HM> besides Avalon have no incentive to flood the market and risk an upset if they want their business to flourish in the medium to long term
 64 2013-02-01 00:41:23 <num1> moore, really? I guess I don't know enough about how satoshi dice work, but why would that let you cheat?
 65 2013-02-01 00:41:54 <moore> well it might not work but
 66 2013-02-01 00:42:08 <moore> they way they do stuff is you send them a trasaction
 67 2013-02-01 00:42:26 <moore> then they send you one back using your output as a input
 68 2013-02-01 00:42:47 <moore> then if you don't like the way the dice came out
 69 2013-02-01 00:43:20 <moore> and you can flood the a new trasaction to the network that spends the same output used in the inital trasaction you sent them
 70 2013-02-01 00:43:33 <moore> your bet with them will get "rolled back"
 71 2013-02-01 00:43:34 <CodeShark> the only problem is that the first transaction you sent has already been propagated
 72 2013-02-01 00:43:47 <CodeShark> the only way that could work is by chaining a bunch of transactions
 73 2013-02-01 00:43:49 <moore> how do they verify that?
 74 2013-02-01 00:44:15 <CodeShark> by the time satoshi dice sends their transaction to the network, your transaction to them has already propagated
 75 2013-02-01 00:44:16 <moore> if all the nodes they relay too are slow you could still win
 76 2013-02-01 00:44:32 <sipa> well ideally you send the first transaction directly to them, and you get the reply back from them directly as well
 77 2013-02-01 00:44:49 <CodeShark> but presumably they will have already relayed your transaction to them to a bunch of other peers, sipa
 78 2013-02-01 00:44:54 <sipa> during that time, they can make sure they have informed a large number of peers
 79 2013-02-01 00:45:00 <moore> there seems to be people doing/trying this now
 80 2013-02-01 00:45:11 <moore> http://blockchain.info/double-spends
 81 2013-02-01 00:45:21 <sipa> actually, they could intentionally delay the response, in order to give it more chance to propagate
 82 2013-02-01 00:45:27 <sipa> moore: there are several ways to help
 83 2013-02-01 00:45:37 <moore> ya I agree
 84 2013-02-01 00:45:42 <moore> but are they now?
 85 2013-02-01 00:45:56 <HM> satoshi can fix that easier than you can exploit it though
 86 2013-02-01 00:45:58 <sipa> no idea, but a few seconds would do a lot already
 87 2013-02-01 00:46:04 <HM> err satoshidice that is
 88 2013-02-01 00:46:28 <moore> if you look at that list of double spends they are overwhelmingly SatoshiDICE
 89 2013-02-01 00:46:50 <HM> all transactions are overwhelmingly SatoshiDICE :/
 90 2013-02-01 00:47:13 <CodeShark> so maybe they haven't patched up this hole
 91 2013-02-01 00:47:16 <moore> also one of the big pools could game them too
 92 2013-02-01 00:47:34 <gmaxwell> Kinda telling(?) that when people complain to SD about SD burdening the network they get a "so? you better fix it" but when someone attacks sd and sd doesn't even care people are looking out for ways for them to fix themselves.
 93 2013-02-01 00:47:49 <moore> just refuse loosing transactions
 94 2013-02-01 00:48:02 <tradefortress> http://blockorigin.pfoe.be/blocklist.php is outdated?
 95 2013-02-01 00:48:08 <sipa> moore: or block them altogether :)
 96 2013-02-01 00:48:11 <gmaxwell> moore: lots of miners already refuse to mine SD transactions??? wouldn't be an enormous patch to only mine when SD loses.... 0_o
 97 2013-02-01 00:48:20 <doublec> tradefortress: delayed I think
 98 2013-02-01 00:48:43 <CodeShark> that would be hillarious, gmaxwell :)
 99 2013-02-01 00:48:51 <moore> gmaxwell that would be a good way to make them go away
100 2013-02-01 00:49:24 <gmaxwell> moore: or to stop announcing their losses as transactions, which is half of what some people irritated with them want. Those very tiny outputs are .. ugh.
101 2013-02-01 00:49:26 <doublec> is there a patch for refusing SD transactions?
102 2013-02-01 00:50:22 <HM> SD could increase the fees to compensate miners, or do a deal with one of the mining groups
103 2013-02-01 00:50:26 <gmaxwell> doublec: yes. I'm on slow internet now so I can't go find one of the public ones, but IIRC luke has a branch for example.
104 2013-02-01 00:50:28 <HM> make them bid for it
105 2013-02-01 00:50:58 <jaakkos> moore: interesting attack on satoshidice. perhaps if the attacker aggressively connects to a huge number of nodes, they could poison the network with the second transaction easily because it starts propagating faster than the original one?
106 2013-02-01 00:51:02 <gmaxwell> HM: no the point is that if you don't mine their txn??? even if other miners do??? those delays make double spends easier.
107 2013-02-01 00:51:41 <HM> you mean if you want to be malicious?
108 2013-02-01 00:51:47 <gmaxwell> every block mined by a miner which blocks X is a block which might instead contain a later doublespend against X.
109 2013-02-01 00:51:59 <gmaxwell> I don't even mean malicious??? it's just the natural effect of blocking something
110 2013-02-01 00:52:04 <doublec> gmaxwell: thanks, found Luke-Jr's branch
111 2013-02-01 00:52:20 <gmaxwell> If you blcok something that improves the odds of a not-something doublespend marginally.
112 2013-02-01 00:52:50 <HM> right, you mean if a spend isn't seen by the full network hash power then there is an increased time window for a double spend
113 2013-02-01 00:53:12 <gmaxwell> HM: and take care with malice, SD's responses to complaints have been 'well, if its a burden you should go fix that'???  if their spammy txn getting denied is a problem then perhaps an inkind respond is due.
114 2013-02-01 00:53:25 <moore> the issue hear is that the SatoshiDICE trick to be fast is actually not really safe
115 2013-02-01 00:53:26 <gmaxwell> s/respond/response/
116 2013-02-01 00:53:43 <HM> i don't think malice is an issue, i think the free market should handle it
117 2013-02-01 00:53:48 <HM> somehow
118 2013-02-01 00:53:51 <gmaxwell> moore: yea, and also has a lot of costs on the network.
119 2013-02-01 00:54:00 <moore> you can't be sure of the ordering of transactions until they are in a block
120 2013-02-01 00:54:20 <moore> well if the network wants them to stop it is clear how to do it
121 2013-02-01 00:54:39 <gmaxwell> so you get unsafe and very greatly increased txn volume...  it also has misled a bunch of people about the safty of unconfirmed txn, but I guess it might ultimately have the reverse effect.
122 2013-02-01 00:54:44 <moore> well I guess they could just be more tricky but it would hurt there UX
123 2013-02-01 00:54:57 <gmaxwell> moore: network wide collusion opens up other hard questions.
124 2013-02-01 00:55:13 <gmaxwell> Though special cases that make themselves flaming identifyable .. well thats kinda special.
125 2013-02-01 00:55:17 <moore> gmaxwell, yes
126 2013-02-01 00:55:27 <HM> interesting question
127 2013-02-01 00:55:38 <HM> what's the biggest spender on the network?
128 2013-02-01 00:55:43 <gmaxwell> moore: did you see that they wouldn't even change to compressed public keys because they were (apparently?) so determined not to change addresses. Weird.
129 2013-02-01 00:55:43 <HM> 2nd biggest*
130 2013-02-01 00:56:08 <moore> hu
131 2013-02-01 00:56:09 <moore> no
132 2013-02-01 00:56:16 <moore> I gotta take off
133 2013-02-01 00:56:18 <gmaxwell> HM: obviously you can't identify single users on the network (usually)... so what do you really mean by spender?
134 2013-02-01 00:56:20 <moore> nice chatting
135 2013-02-01 00:56:25 <gmaxwell> Indeed.
136 2013-02-01 00:56:57 <HM> well SatoshiDICE is well tracked
137 2013-02-01 00:57:21 <HM> are there any other large known groups pushing out anything comparable?
138 2013-02-01 00:57:22 <gmaxwell> maybe. Again what do you mean by spender?
139 2013-02-01 00:57:34 <HM> number of transactions
140 2013-02-01 00:57:46 <jaakkos> do miners always accept the transaction that they see first, if multiple alternatives are available?
141 2013-02-01 00:57:48 <gmaxwell> If I just send to myself a million times am I the biggest "spender"?
142 2013-02-01 00:57:54 <sipa> why do you classify by? IP? computer? wallet?
143 2013-02-01 00:58:07 <gmaxwell> jaakkos: they reject doublespends against txn they've already accepted.
144 2013-02-01 00:58:16 <Scrat> HM: probably mtgox
145 2013-02-01 00:58:22 <HM> gmaxwell: if you put a million transactions on to the network, then yes?
146 2013-02-01 00:58:26 <jaakkos> gmaxwell: so yes
147 2013-02-01 00:58:48 <gmaxwell> HM: in any case if you're asking about txn count by address, I imagine that deepbit is still #2.
148 2013-02-01 00:59:04 <Scrat> and the other 2 letter website which shall remain unnamed
149 2013-02-01 00:59:09 <gmaxwell> But mtgox may in fact be much more??? but they don't usually generate totally obvious non-private txn.
150 2013-02-01 00:59:53 <CodeShark> mtgox keeps much of their internal txs off the block chain
151 2013-02-01 01:00:11 <HM> exchanges don't seem like a huge candidate to me. i think a lot of people use them to trade/speculate
152 2013-02-01 01:00:18 <HM> scalp etc
153 2013-02-01 01:00:55 <gmaxwell> HM: they also do fairly large volumes of I/O.
154 2013-02-01 01:01:14 <gmaxwell> ys, most of their own volume is internal??? but that volume is a significant multiple of the whole blockchain at times.
155 2013-02-01 01:04:42 <HM> the block hashing algorithm is surprisingly simple
156 2013-02-01 01:07:46 <petertodd> HM: Too simple... should have been merge mining from the start; currently because the coinbase is a normal tx, you always have relatively lengthy proof chains to the merkle root for any merge mined chains.
157 2013-02-01 01:09:11 <HM> i don;t yet understand the merkle root
158 2013-02-01 01:09:44 <Luke-Jr> gmaxwell: lol
159 2013-02-01 01:09:51 <HM> i follow the concept of a merkle tree but haven't put together how the merkle root hash works in the block header
160 2013-02-01 01:10:05 <HM> i haven't looked at any of the databade/blockchain stuff
161 2013-02-01 01:11:02 <CodeShark> HM, the idea is twofold: 1) you only need to hash the block header regardless of the number of transactions. 2) you can get a subset of transactions and verify they haven't been tampered with without needing all the transactions
162 2013-02-01 01:11:50 <petertodd> HM: 3) You can prove the existence of a transaction with a short merkle path to the block header.
163 2013-02-01 01:12:07 <CodeShark> oh, yes - also (3) :)
164 2013-02-01 01:13:05 <CodeShark> (1) means mining power required does not depend on the size of the block
165 2013-02-01 01:13:29 <HM> i don't get it. isn't the merkle root hash a hash of all the tx hashes?
166 2013-02-01 01:13:40 <HM> how can you verify a subset and trust the entire block header?
167 2013-02-01 01:14:00 <CodeShark> it's a binary tree - each node is a hash of concatenating the hashes of the two children
168 2013-02-01 01:14:30 <sipa> HM: for each node, you either specify the two children, or its hash
169 2013-02-01 01:14:37 <sipa> for the children you do the same thing
170 2013-02-01 01:15:20 <sipa> so if you have a 10-level deep tree (1024 transactions), you can prove a transaction belongs to the block, by providing the transaction + 10 hashes along the part to the root
171 2013-02-01 01:15:39 <petertodd> http://en.wikipedia.org/wiki/File:Hash_Tree.svg is a nice drawing
172 2013-02-01 01:15:46 <HM> doesn't that mean a block has to contain a power of 2 tx's?
173 2013-02-01 01:16:06 <sipa> HM: there are special rules when a level has an odd number of entries
174 2013-02-01 01:16:20 <sipa> (an unfortunately chosen rule, by the way...)
175 2013-02-01 01:16:31 <HM> well of course
176 2013-02-01 01:16:48 <sipa> in practice that changes little
177 2013-02-01 01:17:54 <HM> right so the subset you verify has to be one of the branches
178 2013-02-01 01:18:15 <sipa> you can do it for arbitrary subsets, but it becomes a bit more complex
179 2013-02-01 01:18:22 <HM> and because you have the root, you can traverse to the leaf of that branch and verify the leaves have the correct hashes
180 2013-02-01 01:19:32 <fiesh> on my freebsd machine here, bitcoind has been running for several months now and consumes 416M RES memory (not that I'm super happy with that, but ok), on a debian box I started it last night and it is already at 776M... both 0.7.2.  Seems quite unreasonable to me, any recommendations?
181 2013-02-01 01:20:35 <doublec> fiesh: number of connections?
182 2013-02-01 01:21:11 <HM> i have a similar situation fiesh
183 2013-02-01 01:22:27 <doublec> or 64bit vs 32bit binaries?
184 2013-02-01 01:22:27 <Scrat> maybe it has a different interpretation of res in ps?
185 2013-02-01 01:22:34 <Scrat> certainly is the case for free
186 2013-02-01 01:22:52 <fiesh> 8 vs 22
187 2013-02-01 01:23:12 <fiesh> 64bit, statically linked (which shouldn't account for much)
188 2013-02-01 01:23:45 <HM> http://pastebin.com/WUnuhMVH
189 2013-02-01 01:23:47 <HM> here's mine
190 2013-02-01 01:24:03 <HM> doing nothing but keeping the blockchain up to date
191 2013-02-01 01:24:27 <fiesh> yyes
192 2013-02-01 01:24:37 <HM> virtual memory is closer to 1.3 GiB for me
193 2013-02-01 01:24:55 <HM> not sure how you account for swap but that's up to 600 MiB so that must be the difference
194 2013-02-01 01:25:00 <HM> (box is doing nothing else)
195 2013-02-01 01:29:32 <fiesh> I suppose bitcoind has been compiled against valgrind or something similar and verified that it doesn't leak?!
196 2013-02-01 01:30:07 <HM> i was thing boehm
197 2013-02-01 01:30:11 <HM> thinking*
198 2013-02-01 01:30:14 <CodeShark> valgrind actually gives me a lot of memory errors for bitcoind
199 2013-02-01 01:30:59 <sipa> CodeShark: really?
200 2013-02-01 01:31:05 <CodeShark> yer
201 2013-02-01 01:31:13 <CodeShark> doesn't give you any errors?
202 2013-02-01 01:31:18 <sipa> there are a few standard harmless ones caused by BDB
203 2013-02-01 01:31:23 <CodeShark> ok
204 2013-02-01 01:31:27 <sipa> and one about moneyformat at shutdown
205 2013-02-01 01:31:28 <CodeShark> perhaps it's only that
206 2013-02-01 01:32:00 <fiesh> so what is the "standard memory footprint" that people normally have?
207 2013-02-01 01:32:12 <fiesh> can't find any information on the net
208 2013-02-01 01:32:44 <sipa> having lots of connections increases memory usage a lot
209 2013-02-01 01:33:01 <fiesh> why is that by the way?
210 2013-02-01 01:33:18 <fiesh> but anyway, I only have very few connections
211 2013-02-01 01:33:18 <sipa> big buffers (too big...)
212 2013-02-01 01:33:32 <fiesh> hmm they must be way too big then I guess ;)
213 2013-02-01 01:33:33 <HM> hmmm
214 2013-02-01 01:33:43 <HM> boehm can be loaded as a LD_PRELOAD library
215 2013-02-01 01:34:09 <HM> overrides malloc etc. does bitcoind do any fancy/obscure memory allocation?
216 2013-02-01 01:34:35 <sipa> HM: i expect boehm to work, would be an interesting experiment
217 2013-02-01 01:35:52 <gmaxwell> CodeShark: you need to recompile your openssl with a non-braindamaged one.
218 2013-02-01 01:35:58 <fiesh> hmm bitcoind must be using the most ginormous buffers in the history of mankind...
219 2013-02-01 01:36:16 <CodeShark> gmaxwell: ?
220 2013-02-01 01:36:20 <sipa> fiesh: a few MiB per connection
221 2013-02-01 01:36:24 <gmaxwell> Stock openssl copies uninitilized memory into its randomness pool and then makes valgrind complain about *.
222 2013-02-01 01:36:49 <HM> sipa is hat a malloc()'s recv() buffer or a TCP/socket buffer?
223 2013-02-01 01:36:52 <fiesh> sipa: then I don't understand I guess, what's being buffered that is so huge?
224 2013-02-01 01:37:10 <CodeShark> how do I disable that when compiling openssl, gmaxwell?
225 2013-02-01 01:37:15 <gmaxwell> It's a throughly dumb feature that seldom has any gain, and the harm of busting one of the most valuable pro-security debugging instrumentations avilable couldn't possible be worth it.
226 2013-02-01 01:37:17 <sipa> fiesh: blocks
227 2013-02-01 01:37:22 <gmaxwell> CodeShark: -DPURIFY IIRC.
228 2013-02-01 01:37:47 <andytoshi> thx gmaxwell, i didn't know that either
229 2013-02-01 01:37:57 <sipa> fiesh: to get some reasonable throughput, you want to be able to be sending/receiving them while processing
230 2013-02-01 01:38:18 <gmaxwell> andytoshi: if you're using RPMs based on my specs.. I compile with -DPURIFY (or whatever the knob is)
231 2013-02-01 01:38:22 <fiesh> sipa: but for sending you surely don't need to buffer each connection individually?!
232 2013-02-01 01:38:33 <sipa> fiesh: yeah, there are a lot of improvements possible
233 2013-02-01 01:38:43 <fiesh> sipa: and for receiving, once the blockchain is up to date, you'd only want to receive one at a time anyway, right?
234 2013-02-01 01:38:47 <andytoshi> gmaxwell: nope, i compile my own
235 2013-02-01 01:39:08 <sipa> fiesh: the send buffer is only 1 MiB these days, it seems
236 2013-02-01 01:39:16 <sipa> it used to be 10 MiB, that was really overkill :)
237 2013-02-01 01:39:24 <fiesh> sipa: if that's per connection, then I'd say it's still brutally huge ;)
238 2013-02-01 01:39:34 <sipa> fiesh: meh
239 2013-02-01 01:39:50 <HM> fortunately ram is cheap
240 2013-02-01 01:40:12 <sipa> jeff wrote a nice improvement for the receiver part, but it occassionally caused segfaults, and i'm not sure anyone ever found them
241 2013-02-01 01:40:49 <HM> you could share buffers across sockets, surely
242 2013-02-01 01:41:47 <sipa> patches welcome :)
243 2013-02-01 01:41:58 <sipa> (but not right now)
244 2013-02-01 01:42:20 <HM> frozen for 0.8-rc1?
245 2013-02-01 01:42:35 <sipa> we don't have an RC yet, but it won't be long
246 2013-02-01 01:43:14 <fiesh> hmm, after a restart it's now at a res of 246M
247 2013-02-01 01:43:53 <fiesh> so I think there was something seriously fishy going on, maybe not a memory leak but just keeping memory that is unnecessary
248 2013-02-01 01:46:54 <HM> bitcointalk still down
249 2013-02-01 01:46:56 <HM> sheesh
250 2013-02-01 01:49:23 <petertodd> Too many people trying to talk about $20.50/BTC? It was running slow earlier...
251 2013-02-01 01:50:22 <randy-waterhouse> asic threads just went nutz alos
252 2013-02-01 01:51:52 <HM> i notice the bitcoin foundations box has 4 ASICs to Jeffs 3
253 2013-02-01 01:52:10 <HM> pushing 89 GH/s
254 2013-02-01 01:53:24 <jgarzik> woo!
255 2013-02-01 01:53:30 <jgarzik> slush's UI claims my ASIC found a block
256 2013-02-01 01:53:48 <petertodd> Awesome!
257 2013-02-01 01:53:56 <randy-waterhouse> cool first ASIC block .... well officially
258 2013-02-01 01:54:33 <randy-waterhouse> jgarzik: what stratum  difficulty you using for the asic?
259 2013-02-01 01:55:30 <andytoshi> congrats jgarzik, very cool!
260 2013-02-01 02:01:17 <jgarzik> The first ASIC-found block: http://blockchain.info/block/00000000000001291f56c477342d39f0c9b31803e55c7b52ce2eab7c91eb2c0c?site=slush
261 2013-02-01 02:02:13 <abracadabra> pffft
262 2013-02-01 02:02:19 <abracadabra> only 0.3262 BTC in fees!
263 2013-02-01 02:02:20 <abracadabra> :)
264 2013-02-01 02:04:25 <petertodd> Reminds me, any idea what's going on with 1JmQN8NvX3XXWWrJW3rEEcKQMQd5DUgkH3? 9f2fd3fb459cfdb60f1b1d261d44cbb536e0c58a2ee3ec137e029bf962490910 has a 3BTC fee, and 7faff9ccc2962aa9ca3c291c7737410f432c596bf12a503dc19ae9fdbb9a8f7c 4.5BTC, maybe a bug in someone's custom code?
265 2013-02-01 02:05:21 <petertodd> (and others at 3BTC, 1.2BTC etc.)
266 2013-02-01 02:06:01 <gavinandresen> sendrawtransaction should probably have an idiot switch turned on by default...
267 2013-02-01 02:06:56 <gavinandresen> ???although part of me thinks that losing a few BTC might teach people to be more careful when playing around dangerous equipment
268 2013-02-01 02:07:16 <andytoshi> i think so, it'll be good to get some urban myths going about sendrawtransaction
269 2013-02-01 02:07:25 <petertodd> The idiot switch for sendrawtransaction is to disable it... but yeah, we need better tools to review tx's.
270 2013-02-01 02:08:08 <petertodd> You need to be able to present a list of pubkeys and do an independent check that the tx really can be spent by them for instance.
271 2013-02-01 02:08:10 <gavinandresen> simple idiot switch would be a setting "don't sendrawtransaction if fee > 1% of input value"
272 2013-02-01 02:08:55 <petertodd> That'd be a good start. Someone in gmaxwell's "taint" thread did that by accident - 1BTC fee.
273 2013-02-01 02:09:01 <randy-waterhouse> a big red switch is the standard for idiot-proofing
274 2013-02-01 02:09:06 <gavinandresen> well, if the pub keys don't pass the IsStandard() check then sendrawtransaction won't send them
275 2013-02-01 02:09:39 <petertodd> Sure, but you need to be able to validate separately, perhaps even on a different machine for multisig.
276 2013-02-01 02:10:08 <petertodd> Might not be worth it in RPC proper, but someone should write it somewhere.
277 2013-02-01 02:10:29 <HM> the idiot switch would be to explicitly specify the fee in the API
278 2013-02-01 02:10:44 <HM> then bark at them if the numbers don't add up
279 2013-02-01 02:13:29 <gavinandresen> BlueMatt: by the way??? I failed to build a mingw-w64 openssl:  a_strex.c:574:1: internal compiler error: in inline_call, at ipa-inline-transform.c:269
280 2013-02-01 02:14:28 <BlueMatt> gavinandresen: wonderful...
281 2013-02-01 02:15:17 <BlueMatt> gavinandresen: Im probably gonna have to make a second chroot on jenkins for precise and use the current deps builds from the old mingw
282 2013-02-01 02:15:36 <gavinandresen> BlueMatt: ok.  Feel free to clone the whole VM if you need to.
283 2013-02-01 02:16:05 <BlueMatt> gavinandresen: yea, Ill see what I can do, it may be until the weekend though, as I cant just install w64 in the current vm (would require a libc upgrade.....)
284 2013-02-01 02:16:17 <gavinandresen> wonderful....
285 2013-02-01 02:18:05 <BlueMatt> luckily its easily reproduceable, though bisect is giving me different commit causes depending on the order of the bisect...
286 2013-02-01 02:33:15 <jgarzik> hrm
287 2013-02-01 02:33:30 <jgarzik> can anyone verify that bitcointalk.org did not change IP addresses in the last N hours?
288 2013-02-01 02:36:45 <petertodd> www.webboar.com says in mar 2012 it had 209.44.108.236, not useful I know
289 2013-02-01 02:42:17 <petertodd> there you go: http://toolbar.netcraft.com/site_report?url=http://bitcointalk.org unchanged
290 2013-02-01 02:42:35 <jgarzik> cool, that backs up what #bitcoin is saying
291 2013-02-01 02:42:47 <petertodd> was someone suspicious?
292 2013-02-01 02:42:57 <petertodd> ssl cert looks ok too
293 2013-02-01 02:43:20 <jgarzik> I was suspicious
294 2013-02-01 02:43:30 <jgarzik> it suddenly asked for a password again, when it came back up
295 2013-02-01 02:44:30 <petertodd> ah, I got that too
296 2013-02-01 02:44:51 <petertodd> still seeing template parse errors
297 2013-02-01 02:54:14 <doublec> yeah I'm seeing it as well
298 2013-02-01 02:58:43 <Luke-Jr> looking for more eyes on http://codepad.org/5rhxeTAh - this is to test master block acceptance vs 0.6.0
299 2013-02-01 03:17:41 <ShaTwo> Hello??? I wanted to show you a weir think that just happened to me...
300 2013-02-01 03:17:44 <ShaTwo> Check http://blockchain.info/address/1Q8nFaxzPUmgKzD2wGLTy8i3ogBNUgfHoo
301 2013-02-01 03:18:48 <ShaTwo> If you check the 0.01710561 transaction??? that was added by the client.
302 2013-02-01 05:21:10 <andytoshi> [5~