1 2012-11-14 00:11:43 <etotheipi_> so this doesn't look like the cause, but it is suspicious -- it looks like somehow Armory is requesting each tx like 5-20 times
  2 2012-11-14 00:12:22 <etotheipi_> I see a bunch of "received getdata: tx ...." calls, and Armory is definitely making a bunch of those calls, though I can't tell why
  3 2012-11-14 00:12:43 <etotheipi_> Bitcoin-Qt receives a tx and sends out an inv to all peers, correct?
  4 2012-11-14 00:13:21 <etotheipi_> if Armory hasn't seen the tx, it issues getdata to Bitcoin-Qt
  5 2012-11-14 00:13:31 <etotheipi_> Bitcoin-Qt doesn't send out another inv for the same tx, does it?
  6 2012-11-14 00:20:11 <cjd> how is target expressed in decimal? is it just a float?
  7 2012-11-14 00:20:50 <cjd> err difficulty
  8 2012-11-14 00:21:40 <cjd> ahh foundit
  9 2012-11-14 00:39:23 <Zarutian> cjd: isnt it expressed as an integer equal in size of the blockhash? The difficulty increases as its gets lower iirc (someone more knowledgeable than me should correct me if I am wrong)
 10 2012-11-14 00:42:58 <cjd> it's a float which is calculates by dividing 2 parts of the integer
 11 2012-11-14 00:43:35 <Luke-Jr> cjd: it's a real number. doesn't need to be a float :P
 12 2012-11-14 00:44:41 <pjorrit> how could it be an imaginary number?
 13 2012-11-14 00:45:45 <cjd> I really don't get the significance of the division and the decimal point number but I can deal with the bytes as SetCompact() does
 14 2012-11-14 00:51:01 <Luke-Jr> the difficulty number is merely for human consumption
 15 2012-11-14 00:51:03 <Luke-Jr> not much else
 16 2012-11-14 00:59:26 <jgarzik> indeed
 17 2012-11-14 00:59:33 <jgarzik> target is the 256-bit integer
 18 2012-11-14 01:39:36 <Diablo-D3> http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
 19 2012-11-14 01:39:38 <Diablo-D3> kerpow!
 20 2012-11-14 01:40:37 <D34TH> hmm, i recognize some of those symbols
 21 2012-11-14 01:43:15 <cjd> hmm
 22 2012-11-14 01:43:20 <cjd> I'm confused about something
 23 2012-11-14 01:43:28 <D34TH> cjd whats up
 24 2012-11-14 01:43:32 <cjd> What is the target hash currently?
 25 2012-11-14 01:44:03 <D34TH> run getwork and find out
 26 2012-11-14 01:46:32 <cjd> hmm ok
 27 2012-11-14 01:46:57 <cjd> getwork, my implementation, and my hack of the bitcoin source agree
 28 2012-11-14 01:47:07 <cjd> blockexplorer is full of shit
 29 2012-11-14 01:47:19 <cjd> http://blockexplorer.com/q/hextarget
 30 2012-11-14 01:49:33 <pjorrit> dat regexp
 31 2012-11-14 01:51:12 <cjd> https://ezcrypt.it/VA5n#drb5YD9c4nEwBshJqAVsRnk3
 32 2012-11-14 01:51:16 <cjd> there's my version
 33 2012-11-14 01:52:44 <cjd> https://ezcrypt.it/WA5n#V55K4Q5plF6tuu5RETVvvVdW
 34 2012-11-14 01:52:48 <cjd> there's what I used to test it
 35 2012-11-14 02:47:21 <forrestv> cjd, probably because blockexplorer isn't up-to-date. it lags behind on blocks... (this is assuming that there has been a difficulty change recently)
 36 2012-11-14 02:48:25 <weex> theymos runs that right?
 37 2012-11-14 03:02:18 <cjd> heh I just found a couple bugs in my implementation and tested it against the original, now they come out the samw given random numbers
 38 2012-11-14 03:02:39 <cjd> real2m16.168s <-- original
 39 2012-11-14 03:02:56 <cjd> real0m3.096s <-- mine
 40 2012-11-14 03:03:03 <cjd> doing 100 million cycles
 41 2012-11-14 03:16:35 <phantomcircuit> interesting
 42 2012-11-14 03:16:54 <phantomcircuit> attempting to enumerate all of the bitcoin peers has crashed my router
 43 2012-11-14 03:16:55 <phantomcircuit> :(
 44 2012-11-14 03:17:39 <cjd> yeah, that happens
 45 2012-11-14 03:17:52 <cjd> vpn to a linux box or 10
 46 2012-11-14 03:18:05 <cjd> well.. 1 will do, you're not attacking
 47 2012-11-14 03:18:06 <phantomcircuit> i do have 125k peer ips though
 48 2012-11-14 03:19:27 <cjd> https://ezcrypt.it/ZA5n#9rmm28qE3hFPkNAW20I4XArc <-- there's my source code
 49 2012-11-14 03:21:40 <phantomcircuit> cjd, gonna try again on a vps
 50 2012-11-14 03:21:55 <phantomcircuit> if that doesn't work i'll buy a kimsufi box for a month
 51 2012-11-14 03:22:00 <cjd> heh
 52 2012-11-14 03:23:15 <Joric> fellow PhDs how do you distinguish thesis from feces? they sound the same to my ears
 53 2012-11-14 03:23:39 <phantomcircuit> Joric, context...
 54 2012-11-14 03:23:40 <phantomcircuit> hopefully
 55 2012-11-14 03:26:54 <jgarzik> Joric: that's about what most of them are worth
 56 2012-11-14 03:27:17 <jgarzik> Joric: compare number of theses produced per year, versus number of impactful theses that contribute advances to science
 57 2012-11-14 03:40:58 <xenland> How much data can bitcoin labels hold?
 58 2012-11-14 06:34:18 <sipa> cjd: 2m vs 3s for what kind of operation?
 59 2012-11-14 06:35:30 <cjd> validating headers :)
 60 2012-11-14 06:35:39 <cjd> something that never happens but ohwell
 61 2012-11-14 06:36:42 <sipa> well the time is iterating them from disk, not hashing
 62 2012-11-14 06:37:07 <cjd> idk maybe it's called more often than I thought, it's CheckProofOfWork
 63 2012-11-14 06:37:29 <sipa> as part of checkblock, yes
 64 2012-11-14 06:37:40 <cjd> it's not the hashing, it's moving numbers in and out of openssl
 65 2012-11-14 06:37:47 <sipa> ha
 66 2012-11-14 06:37:54 <sipa> nice
 67 2012-11-14 06:38:08 <sipa> feel free to submit a patch :)
 68 2012-11-14 06:39:09 <cjd> https://ezcrypt.it/aB5n#LVQ7Qhww1mYnJw8yp7O7ix5n <-- that's the code
 69 2012-11-14 06:39:26 <cjd> it might be worthwhile just because it's a more conscise definition of "what is valid"
 70 2012-11-14 06:41:25 <sipa> don't see anything (on my phone)
 71 2012-11-14 06:41:43 <cjd> ahh, that pastebin uses javascript to decrypt the paste
 72 2012-11-14 06:42:16 <cjd> http://pastebin.com/raw.php?i=Qtg5PAKA
 73 2012-11-14 06:44:02 <sipa> nice
 74 2012-11-14 06:44:34 <cjd> it's an ugly switch statement but all the ugly is in one place and you can show that to anyone and say "that's the definition"
 75 2012-11-14 06:44:48 <sipa> there is a pullreq for improving get/setcompact though
 76 2012-11-14 06:45:04 <cjd> although I kind of hacked it together bt trial and error using that test loop
 77 2012-11-14 06:45:22 <cjd> but 100,000,000 test cycles I think I got it
 78 2012-11-14 06:46:27 <sipa> what if the exponent is negative?
 79 2012-11-14 06:47:19 <cjd> hmm, not sure what you mean
 80 2012-11-14 06:47:30 <cjd> I think it's stripped in the conversion to uint256
 81 2012-11-14 06:47:56 <cjd> it didn't work without the & 0x7f in case 1: targetHashOut[32 - byteOne] = (bits >> 16) & 0x7f;
 82 2012-11-14 06:48:24 <cjd> and I think that was the sign bit
 83 2012-11-14 06:50:05 <cjd> oh yeah, that will give you a big endian representation which doesn't work with the uint256 but I'm partial to it because I'm looking at using memcmp()
 84 2012-11-14 06:50:43 <cjd> I'm sure you could reverse the numbers and get it to produce bass ackwards bitcoin numbers
 85 2012-11-14 07:16:23 <ThomasV> what are the "Unable to decode output address 0 BTC" txouts at blockchain.info ?
 86 2012-11-14 07:17:34 <ThomasV> for example here, last output of coinbase: http://blockchain.info/block-index/277012/000000000000027ab70c62a9c41408ad2f2b70bbd9b175c597ad9394a117f306
 87 2012-11-14 07:25:48 <sipa> ThomasV: output scripts that do not have a corresponding address?
 88 2012-11-14 07:26:53 <ThomasV> sipa: what are they? I thought non stansard tx were rejected by the network
 89 2012-11-14 07:28:31 <sipa> yes
 90 2012-11-14 07:28:38 <sipa> but a coinbase is produced by the miner himself
 91 2012-11-14 07:29:37 <sipa> in this case, looks like p2pool data
 92 2012-11-14 07:30:42 <ThomasV> so they just use this to store data? (the value is 0 btc)
 93 2012-11-14 07:30:48 <sipa> yes
 94 2012-11-14 07:31:17 <ThomasV> is there a length limit on what they can write? (other than block length limit)
 95 2012-11-14 07:31:25 <sipa> don't think so
 96 2012-11-14 07:31:31 <ThomasV> :-/
 97 2012-11-14 07:32:06 <sipa> but if miners blow up the size of the chain, they are hurting everyone
 98 2012-11-14 07:35:33 <ThomasV> so we just hope they are rational?
 99 2012-11-14 07:36:22 <sipa> well miners' function is deciding what transactions end up in the chain
100 2012-11-14 07:36:32 <weex> the protocol guides miners to follow the longest/most difficult chain...what if block size were a term in that guidance?
101 2012-11-14 07:37:13 <sipa> weex: then every miner would produce empty blocks
102 2012-11-14 07:37:27 <sipa> to maximize their the chance for their blocks' survival
103 2012-11-14 07:40:16 <ThomasV> sipa: still, I find it strange that a rule to reject nonstandard tx has been accepted, and that that rule does not apply to coinbase transactions. nothing prevents the rule to apply there too
104 2012-11-14 07:40:55 <sipa> ThomasV: "reject nonstandard tx" is not a protocol rule, and there is no difference between coinbases and other transactions
105 2012-11-14 07:41:20 <sipa> "reject nonstandard tx" is a policy for the memory pool implementation in the reference client
106 2012-11-14 07:41:30 <ThomasV> oh, it is just a bitcoind thing
107 2012-11-14 07:41:35 <sipa> yes
108 2012-11-14 07:41:45 <sipa> some miners have different policies altogether
109 2012-11-14 07:41:53 <ThomasV> ok
110 2012-11-14 07:42:30 <ThomasV> (I once tried to propagate a nonstandard tx, but it did not make it in a block)
111 2012-11-14 07:42:51 <sipa> if you include enough fee and send it to eligius it may get accepted
112 2012-11-14 07:43:06 <ThomasV> yeah :)
113 2012-11-14 07:44:40 <ThomasV> and if it contains a prayer, I can get a rebate on the fee
114 2012-11-14 07:51:48 <ThomasV> sipa: btw, concerning electrum, I built a pruned index of address -> (txout, height), that still keeps empty entries for addresses that have no unspent coins. this latter point allows me to know that the address has been used, which is sufficient for electrum to do wallet recovery from seed
115 2012-11-14 07:52:22 <sipa> where did you implement this?
116 2012-11-14 07:52:31 <ThomasV> it is way more efficient than abe :)
117 2012-11-14 07:52:45 <ThomasV> in python, with python-levelDB
118 2012-11-14 07:53:03 <ThomasV> not in bitcoind
119 2012-11-14 07:53:09 <sipa> oh, ok
120 2012-11-14 07:54:42 <cjd> heh
121 2012-11-14 07:55:11 <cjd> err nvm
122 2012-11-14 07:56:03 <cjd> 2 retargets in the same second drives the difficulty to infinity, I thought for a second it was 2 blocks in the same second
123 2012-11-14 07:57:09 <sipa> cjd: no, difficulty changes are limited to *[0.25..4]
124 2012-11-14 07:57:32 <ThomasV> 2 retargets in the same second? you 'd need to mine 2016 blocks in the same second
125 2012-11-14 09:31:45 <jgarzik> +    SCRIPT_VERIFY_P2SH      = (1 << 0),
126 2012-11-14 09:31:58 <jgarzik> sipa: s/1/1U/
127 2012-11-14 09:32:34 <jgarzik> 1U << 0
128 2012-11-14 09:32:36 <jgarzik> 1U << 1
129 2012-11-14 09:32:38 <jgarzik> etc
130 2012-11-14 09:41:13 <sipa> jgarzik: meh - ok, will change this evening
131 2012-11-14 09:46:51 <sipa> no idea what you call this time of day though - late night or early morning?
132 2012-11-14 09:48:10 <jgarzik> sipa: both!
133 2012-11-14 11:43:25 <SomeoneWeird> * jgarzik just had a kid explode at 5am local time < wat
134 2012-11-14 11:43:48 <Diablo-D3> cleanup on aisle 5
135 2012-11-14 12:20:28 <Graet> SomeoneWeird, when u are a parent u will understand
136 2012-11-14 14:25:25 <kjj_> does anyone maintain a patch to accept raw transactions into the memory pool, but not forward them?
137 2012-11-14 14:37:28 <helo> maybe someone in #bitcoin-doublespenders does ;)
138 2012-11-14 14:42:01 <kjj_> you really can't think of ANY other uses for that?
139 2012-11-14 14:43:09 <helo> that's just the most amusing
140 2012-11-14 14:44:37 <gmaxwell> kjj_: whats the application?
141 2012-11-14 14:44:52 <gmaxwell> The only one I'm aware of is pool opps mining their own payments.
142 2012-11-14 14:45:05 <kjj_> that's exactly it, but not a pool, just my own stuff
143 2012-11-14 14:45:09 <gmaxwell> But Luke is ~the only pool op that releases code, and he use coinbase payments.
144 2012-11-14 14:45:27 <gmaxwell> If you're mining, use coinbase payments.
145 2012-11-14 14:46:00 <kjj_> I'm thinking of creative ways to do wallet cleanup
146 2012-11-14 14:47:15 <gmaxwell> uh. ... why not just make coin selection more intellegent so that your normal transactions clean up as you go.
147 2012-11-14 14:48:21 <kjj_> well, I want to reshuffle some of my offline stuff.
148 2012-11-14 14:49:43 <kjj_> Ideally, I'd like to get down to a collection of privkeys on paper, each of which has a single transaction going to it
149 2012-11-14 14:50:43 <kjj_> but going from hundreds of 0.01 to 0.5 inputs into a single 5 BTC (for example) is slow, and I feel it is annoying to the network
150 2012-11-14 14:51:54 <kjj_> but I'd be totally fine with letting my own miners fill up their blocks with that garbage, and then waiting a few weeks or months to find a block
151 2012-11-14 14:52:44 <gmaxwell> what you probably also want is a way to forget them too so you can replace them.
152 2012-11-14 14:53:37 <gmaxwell> Would sort of be interesting to have a 'fragile' transaction in the memory pool any double spend knocks it out of the pool to be replace by the double spend.
153 2012-11-14 14:53:51 <kjj_> yeah, but it doesn't need to be quick.  restarting once a week would be fine by me
154 2012-11-14 14:54:36 <kjj_> it doesn't look at first glance like the changes would be hard to do
155 2012-11-14 14:55:36 <kjj_> basically, add a new RPC call like sendlocalrawtransaction or whatever, that sets a flag.  change the relay code to not relay when it sees that flag.  adding a fragile flag would be easy too
156 2012-11-14 14:56:35 <kjj_> but I haven't had time to even finish up the named pipe stuff I started last week, so this is a couple of weeks out for me, minimum.
157 2012-11-14 14:56:38 <gmaxwell> I'd think that non-relayed ones should always be fragile. Simply because they are defacto fragile in any case since someone else will likely mine the conflict.
158 2012-11-14 14:57:08 <kjj_> that makes sense, sure
159 2012-11-14 14:57:34 <gmaxwell> You'd also need to figure out how to prevent the 'recieving' wallet from rebroadcasting those in cases where you are the recieving wallet.
160 2012-11-14 14:58:06 <kjj_> er, hang on, I think that fragile and local are equal sets, not merely highly overlapping
161 2012-11-14 14:58:43 <gmaxwell> I think local is a proper subset of fragile.
162 2012-11-14 14:58:44 <kjj_> unless you want to change the protocol so that nodes can pass flags along with their transactions over the p2p protocol
163 2012-11-14 14:59:08 <gmaxwell> kjj_: we have replacement, which is in theory a way of having network transitive fragility.
164 2012-11-14 14:59:28 <gmaxwell> But we don't actually implement the actual replacement.
165 2012-11-14 14:59:47 <kjj_> and I don't think replacement works on input only
166 2012-11-14 15:00:03 <kjj_> as in, I don't think you can replace A->B with A->C
167 2012-11-14 15:00:15 <gmaxwell> It could, but it doesn't work with
168 2012-11-14 15:00:19 <gmaxwell> _anything_ right now
169 2012-11-14 15:00:39 <gmaxwell> I'm just pointing out that the concept of fragility isn't a purely local thing, in that we do have facilities for it in transactions already.
170 2012-11-14 15:01:22 <kjj_> ok.  I haven't followed the replacement system discussions in that much detail, so I'll take your word for it
171 2012-11-14 15:02:05 <kjj_> I have a sort of rough understanding of it, but every discussion so far that I've seen ends with "well shit, that won't work"
172 2012-11-14 15:05:45 <gmaxwell> right. It's somewhat hard to have it and not magnify DOS or theft risks.
173 2012-11-14 15:06:29 <gmaxwell> Locally only is another matter...
174 2012-11-14 15:07:40 <kjj_> for what we are talking about, the node should get the local flag as part of the transaction creation (sendrawtransaction or whatever) and then just dump it if it sees any of the same inputs in use
175 2012-11-14 15:08:48 <gmaxwell> Though, I do generally think improved coin selection will go a long way. E.g. make your selection, then for each of the input addresses you're using, add more inputs smallest first until you would need to pay (more) fee.
176 2012-11-14 15:09:31 <gmaxwell> (iff the txn already has change, of course)
177 2012-11-14 15:09:59 <kjj_> ideally, I want each of my secure offline paper wallets to have the key to a single transaction though
178 2012-11-14 15:10:18 <kjj_> as in, I want them safe against an ECDSA break
179 2012-11-14 15:10:40 <someone42> would i be correct to say that the standard scripts are: pay to public key hash, pay to script hash and (up to 3) multisig?
180 2012-11-14 15:11:05 <gmaxwell> someone42: no, there are more standard transactions than that.
181 2012-11-14 15:11:13 <kjj_> is straight pay to pubkey still allowed too?
182 2012-11-14 15:11:16 <gmaxwell> E.g. pay to pubkey.
183 2012-11-14 15:11:26 <someone42> whoops, forgot that one
184 2012-11-14 15:11:34 <someone42> any more?
185 2012-11-14 15:11:55 <gmaxwell> and not all of those are standard. For example, txn that have zero value outputs are not standard.
186 2012-11-14 15:14:47 <someone42> so if i accept: pay to {public key | public key hash | script} and multisig, am i guaranteed to accept any current standard transaction?
187 2012-11-14 15:15:12 <someone42> if it's a superset of standard transactions, it doesn't matter
188 2012-11-14 15:15:22 <sipa> someone42: you decide for yourself what you accept
189 2012-11-14 15:15:40 <sipa> someone42: if you don't give out a multisig address, no one will ever pay to a multisig of yours
190 2012-11-14 15:16:53 <sipa> someone42: and if you don't give out your pubkey, you will never need to scan for a pay-to-pubkey
191 2012-11-14 15:18:14 <someone42> i understand
192 2012-11-14 15:18:25 <someone42> i was just checking if there were any standard transactions i wasn't aware of
193 2012-11-14 15:18:45 <gmaxwell> someone42: what exactly are you doing?
194 2012-11-14 15:19:02 <sipa> what i'm trying to say is that it's ridiculous that a wallet implementor would need to worry about what types of exotic "standard" transactions all or part of the network might accept
195 2012-11-14 15:19:22 <someone42> gmaxwell: writing firmware for a hardware wallet
196 2012-11-14 15:19:23 <sipa> as those are in no way part of the protocol definition
197 2012-11-14 15:20:40 <gmaxwell> yea. I think you're doing something horribly wrong if you're worring about that.
198 2012-11-14 15:21:40 <someone42> okay, i won't worry then :)
199 2012-11-14 15:22:02 <sipa> in particular, i think it's wrong to expect to gracefully deal with payments to any address (or generalized, scriptPubKey) you didn't explicitly give out
200 2012-11-14 15:22:23 <gmaxwell> someone42: the _recipent_ of a transaction specifies the kind of transaction they recieve, e.g. if you give someone a pay to address then thats the only kind of transaction you should expect to recieve. You can not, should not, and must not worry about the geometry of the input transactions for transactions paying you. We can, have, and will change the standard transactions in the future. :P
201 2012-11-14 15:23:00 <gmaxwell> Even if, in theory, you might be able to do some crazy parsing and find your address in some other kind of transaction. Trying to fuddle yourself out in other scripts is dangerous.
202 2012-11-14 15:23:03 <sipa> "How do you mean, you didn't get my payment? I knew your pubkey P, so I sent a payment to the pubkey (P + G*SHA256("ILoveBritney!"))..."
203 2012-11-14 15:26:28 <someone42> with that in mind, i am working on a way to give out p2sh/multisig addresses
204 2012-11-14 15:26:46 <someone42> does anyone have any script hash test vectors?
205 2012-11-14 15:27:02 <someone42> (as in, here are a bunch of public keys, and here's the resulting P2SH address)
206 2012-11-14 15:41:56 <kjj_> easy enough to make those using bitcoind
207 2012-11-14 15:42:31 <kjj_> and if you want to give me free money, I posted at least a couple when I was testing the raw transaction API
208 2012-11-14 15:50:17 <someone42> kjj: thanks, i see there's even a handy json-rpc command for it
209 2012-11-14 17:26:30 <jgarzik> burrito habla
210 2012-11-14 17:35:16 <sipa> jgarzik: you speak burrito?
211 2012-11-14 17:37:00 <rdponticelli> Hola burrito
212 2012-11-14 17:37:15 <rdponticelli> :D
213 2012-11-14 18:05:19 <Luke-Jr> woo 25% rebased/updated
214 2012-11-14 18:18:34 <jgarzik> sipa: the little donkey speaks
215 2012-11-14 20:20:46 <Luke-Jr> gavinandresen: I have a 0.7.x branch ready to go whenever that fix gets merged into master
216 2012-11-14 20:25:43 <cjd> is the effect of the sign bit on retargets well understood?
217 2012-11-14 20:26:28 <sipa> cjd: more or less - but it's not particularly useful, as all decoded CBigInts get converted to uint256 anyway, which ignores the sign
218 2012-11-14 20:27:02 <cjd> I'm reimplementing the retarget function and it doesn't do what I originally expected
219 2012-11-14 20:27:03 <sipa> *ducks*
220 2012-11-14 20:27:12 <cjd> hehe :D
221 2012-11-14 21:21:51 <denisx_> I have now HEAD running for 18h and it seems to eat memory
222 2012-11-14 21:22:24 <gmaxwell> how much memory is it using?
223 2012-11-14 21:22:39 <gmaxwell> and are you talking about VM or actually used memory?
224 2012-11-14 21:22:46 <gmaxwell> also what is that node doing other than running?
225 2012-11-14 21:23:13 <sturles> Same here.  1.2 GiB when I stopped it.  The VM was running out of swap.
226 2012-11-14 21:23:31 <sturles> Downloading blocks.
227 2012-11-14 21:23:37 <denisx_> hmm, right now it dropped from 260MB to 180MB
228 2012-11-14 21:24:06 <denisx> yeah, after downloading the whole blockchain I had it at 900MB
229 2012-11-14 21:24:36 <gmaxwell> denisx: 260MB isn't unusual for a node with many connections... not on 0.7.1 heads usage was less.
230 2012-11-14 21:24:52 <gmaxwell> sturles: again, are you talking about virtual memory or actual usage?
231 2012-11-14 21:25:19 <cjd> 2930 user      20   0  801m 165m  41m S   1.7  3.0  42:22.99 bitcoin-qt
232 2012-11-14 21:25:29 <cjd> that was built 2 days ago from the master
233 2012-11-14 21:25:34 <sturles> Actul nough that the VM was running out of swap.  When I stopped it, I had mor than 400 of 512 MiB free RAM.
234 2012-11-14 21:26:07 <gmaxwell> cjd: looks perfectly normal
235 2012-11-14 21:26:18 <cjd> yeap, just pasting it for comparison
236 2012-11-14 21:26:22 <gmaxwell> sturles: if you had 400 of 512 mib free ram you weren't running out of swap.
237 2012-11-14 21:26:24 <sturles> It is at 555 MiB virt, 266 MiB res now after 30 min CPU time.  Still downloading blocks.
238 2012-11-14 21:26:36 <sturles> gmaxwell: I had _after_ I stopped it.
239 2012-11-14 21:27:01 <sturles> gmaxwell: Before I stopped it, I had almost 0 free ram, and a few KiB free swap.
240 2012-11-14 21:27:06 <cjd> 150MB of allocation and 650MB of libboost :|
241 2012-11-14 21:27:18 <gmaxwell> Just ignore virtual it's meaningless.
242 2012-11-14 21:28:15 <gmaxwell> all that means is that there is address space used. It's not actually a tighty limited resource, excepting that on 32 bit systems a process can only have about 2GiB of it.
243 2012-11-14 21:28:21 <sturles> Mine use 278 MiB res now.  Counting 1-2 every update in top (i.e. every 5 seconds).
244 2012-11-14 21:28:43 <gmaxwell> sturles: interesting. How many connections do you have?
245 2012-11-14 21:29:10 <sturles> "connections" : 17,
246 2012-11-14 21:29:23 <sturles> "blocks" : 207095,
247 2012-11-14 21:29:29 <sturles> (Still downloading.)
248 2012-11-14 21:29:39 <sipa> sturles: which version?
249 2012-11-14 21:30:08 <gmaxwell> sturles: you probably should stop listening on a node that is that memory constrained.  Though I'm not sure if your usage is high or not given that you have a fair number of connections.
250 2012-11-14 21:30:08 <sturles> pulld and compiled about 14 hours ago.
251 2012-11-14 21:30:48 <gmaxwell> Did we have some patches someplace that got rid of the crazy socket buffering?
252 2012-11-14 21:31:05 <sturles> OK
253 2012-11-14 21:32:52 <sturles> Cheap VM for testing.
254 2012-11-14 21:34:12 <sturles> Looks like it actually ran out of swap and invoked OOM killer:
255 2012-11-14 21:34:13 <sturles> Killed process 7251 (bitcoin-rpclist)
256 2012-11-14 21:35:52 <jgarzik> gmaxwell: not AFAIK
257 2012-11-14 21:36:24 <jgarzik> (RE crazy socket buffering)
258 2012-11-14 21:41:07 <sipa> i thought the send buffer size was reduced, along with matt's overflow prevention
259 2012-11-14 21:42:33 <sturles> Blockchain download done, and res fell back a bit to 222 MiB.  Will let it run and see tomorrow.  Bed tim in my part of the world.
260 2012-11-14 21:42:58 <sturles> *time
261 2012-11-14 21:43:04 <gmaxwell> sturles: how many connections?
262 2012-11-14 21:43:44 <sturles> 18 now.  Didn't restart after lowering in bitcoin.conf.
263 2012-11-14 21:44:33 <gmaxwell> Well on my pre-ultraprune node here I have a RSS of 224mb with two connections.
264 2012-11-14 21:44:56 <sipa> default is 1MiB send buffer and 5MiB receive buffer... weird
265 2012-11-14 21:45:31 <sipa> 5 MiB recv may make sense during ibd
266 2012-11-14 21:45:42 <sipa> but not in general
267 2012-11-14 21:45:59 <gmaxwell> all seems silly to me, but all that connection handling needs to be revamped.
268 2012-11-14 21:51:33 <sipa> my node has 1200 recv, 1600 send, 123 connections, 415 MiB rss
269 2012-11-14 22:05:16 <jgarzik> For socket RX, you only need to buffer a single header, plus the size of the incoming message
270 2012-11-14 22:06:22 <jgarzik> For socket TX, you need to buffer whatever you queue in response
271 2012-11-14 22:06:23 <jgarzik> attempt to write(2) immediately
272 2012-11-14 22:06:53 <jgarzik> the common case is zero write buffer, as write(2) will succeed immediately for most messages
273 2012-11-14 22:07:40 <jgarzik> as it stands now, we are pointlessly double-buffering, if you consider the kernel buffer