1 2012-02-24 01:43:41 <copumpkin> is it normal for the client to be "catching up" even when it's been open for a while?
  2 2012-02-24 01:43:48 <copumpkin> it says the last block received was 54 minutes ago
  3 2012-02-24 01:43:53 <copumpkin> but it's catching up
  4 2012-02-24 01:44:16 <copumpkin> I'm supposedly connected to 8 peers
  5 2012-02-24 01:44:47 <copumpkin> oh, I guess that's when the last block was made
  6 2012-02-24 01:45:11 <tcatm> Yep. The message is a bit misleading, though.
  7 2012-02-24 01:45:25 <copumpkin> yeah, I assumed I was somehow detached from the network
  8 2012-02-24 01:45:36 <copumpkin> and that somehow it knew there was a block on its way but hadn't seen it yet
  9 2012-02-24 01:47:59 <copumpkin> damn, finally got a block and it didn't include my transaction :P
 10 2012-02-24 01:57:51 <Joric> guys
 11 2012-02-24 01:58:13 <Joric> maybe the tx fee could be based on current difficulty?
 12 2012-02-24 01:59:00 <Joric> rather than 'sub-cents' btc/usd rates and such
 13 2012-02-24 02:24:45 <nanotube> Joric: that has been proposed (i proposed it in fact, iirc, some time ago :) ). it has been responded that difficulty may rise due to improvement in technology, rather than any associated increase in value.
 14 2012-02-24 02:25:02 <nanotube> (e.g., if everyone gets a bunch of fpgas, with lower variable costs...
 15 2012-02-24 02:25:04 <nanotube> )
 16 2012-02-24 02:25:23 <Joric> still better than now
 17 2012-02-24 02:26:44 <nanotube> well, in the shorter term, yes, i think so. but it's not a "permanent long-term solution".
 18 2012-02-24 02:27:14 <nanotube> (the discovery of which is left as an exercise to the reader ... :P )
 19 2012-02-24 02:31:08 <Joric> well determining the 'spam' itself is an AI task, so either difficulty or bayes and shit )
 20 2012-02-24 03:01:37 <pingdrive> damn cooling is a pain
 21 2012-02-24 05:42:43 <swulf--> a bit off topic, but wondering if anyone's interested: i'm trying to devise a strategy for proof of work that maintain that each solution takes roughly the same amount of time regardless of computing power (i.e., solution is easier for end users, harder for servers), and that the difficulty of your computation isn't necessarily related to the difficulty of mine... just that both of our problems were solved in the (expected) same am
 22 2012-02-24 05:42:45 <swulf--> any ideas?
 23 2012-02-24 05:48:11 <swulf--> better yet: is there any way (mathematically) that i can have a remote node *prove* how fast his mhashing capabilities are?
 24 2012-02-24 05:53:13 <gmaxwell> swulf--: its trivial to prove access to a lower bound to any desired confidence.
 25 2012-02-24 06:19:08 <Diablo-D3> has anyone seen slush lately?
 26 2012-02-24 06:38:23 <wumpus> swulf--: it's impossible to make that resistant against sybil attacks, ie virtualizing a server into lots of "end users"
 27 2012-02-24 07:25:35 <Diablo-D3> well apparently his pool is breaking on DM.
 28 2012-02-24 07:25:35 <Graet> saqw him on about 36hours ago or so Diablo-D3
 29 2012-02-24 09:20:09 <genjix> ;;later tell jgarzik your email address is broken/down
 30 2012-02-24 09:20:10 <gribble> The operation succeeded.
 31 2012-02-24 09:51:37 <libcoin> from the protocol specification:
 32 2012-02-24 09:51:38 <libcoin> Before 20 February 2012, the version and verack messages do not have a checksum; the payload starts 4 bytes earlier. On and after 20 February 2012, all messages have checksums.
 33 2012-02-24 09:51:49 <libcoin> Does it still apply ?
 34 2012-02-24 09:52:23 <Diablo-D3> yes, that has passed.
 35 2012-02-24 09:52:26 <Diablo-D3> all clients now require it
 36 2012-02-24 09:53:09 <libcoin> OK - explains why I got a lot of errors like : PROCESSMESSAGE MESSAGESTART NOT FOUND, got: 37
 37 2012-02-24 09:53:29 <libcoin> but I cannot find the spot in the code that changes it...
 38 2012-02-24 09:53:30 <Diablo-D3> yeah, I expect a lot of third party shit broke because they didnt read the spec
 39 2012-02-24 09:53:40 <Diablo-D3> this has been in the works since 0.2.9
 40 2012-02-24 09:54:24 <libcoin> Yup, and I recall that I found it somewhere in the code but I cannot recall where
 41 2012-02-24 09:54:41 <Diablo-D3> sipa or gavin or gmaxwell should know
 42 2012-02-24 09:54:51 <MagicalTux> [19:53:29] <libcoin> but I cannot find the spot in the code that changes it... <- it's dirty
 43 2012-02-24 09:55:00 <MagicalTux> the spot in the code just changes the default version from 0 to 209
 44 2012-02-24 09:55:16 <libcoin> ahh then it might be in CDataStream
 45 2012-02-24 09:55:21 <MagicalTux> no
 46 2012-02-24 09:55:35 <libcoin> but it should involve some date
 47 2012-02-24 09:55:48 <MagicalTux> net.h
 48 2012-02-24 09:55:57 <libcoin> I recall that it is the version of the vRecv that does the trick
 49 2012-02-24 09:56:00 <MagicalTux> // Version 0.2 obsoletes 20 Feb 2012\nif (GetTime() > 1329696000)
 50 2012-02-24 09:56:01 <libcoin> ahh thanks
 51 2012-02-24 09:56:12 <MagicalTux> just grep for 1329696000
 52 2012-02-24 09:57:12 <libcoin> Yup - thanks! it was the internal version of the CDataStreams that does the magic - hacking at its best :-/
 53 2012-02-24 09:57:39 <MagicalTux> yea
 54 2012-02-24 09:57:58 <MagicalTux> anyway you can drop this piece of code now
 55 2012-02-24 09:58:03 <MagicalTux> and just apply hash to everything
 56 2012-02-24 09:58:19 <MagicalTux> including version and verack
 57 2012-02-24 09:59:41 <libcoin> I already did drop it - that was the reason :) - it took me quite some effort to figure our how the protocol was implemented - and I have a check for version and verack, was lazy about the date..
 58 2012-02-24 10:02:18 <sturles> MagicalTux: When Mt.Gox get an international bank transfer from private persons, does it include the address of the sender?
 59 2012-02-24 10:05:44 <MagicalTux> [20:02:19] <sturles> MagicalTux: When Mt.Gox get an international bank transfer from private persons, does it include the address of the sender? <- include? where ?
 60 2012-02-24 10:06:15 <Diablo-D3> on the secret government forms you're using to report terrorists with
 61 2012-02-24 10:06:17 <Diablo-D3> duh
 62 2012-02-24 10:06:19 <sturles> Among the information you get from your bank when receiving it.  I'm asking because banks are required to keep my address in sync with the central resident registry, so it should be valid as proof of residency.  A good one as well.  I don't get any utility bills on paper.  My other alternative is to send a tax receipt.
 63 2012-02-24 10:06:54 <sturles> To get a verified account.
 64 2012-02-24 10:06:59 <MagicalTux> sturles: depending on the bank, we get various info
 65 2012-02-24 10:07:03 <Diablo-D3> sturles: he'd have to know where you live first
 66 2012-02-24 10:07:09 <MagicalTux> our hong kong bank do not keep the address sent by the sending bank, but our japanese bank does
 67 2012-02-24 10:07:23 <MagicalTux> we often get unreliable crap, however, so that doesn't exactly count as a proof of address for us
 68 2012-02-24 10:08:10 <libcoin> Just update MessageParser.cpp to:         case command:
 69 2012-02-24 10:08:11 <libcoin> // Version 0.2 obsoletes 20 Feb 2012
 70 2012-02-24 10:08:12 <libcoin> _checksum = true;
 71 2012-02-24 10:08:13 <libcoin> _checksum = (msg.command() != "version" && msg.command() != "verack");
 72 2012-02-24 10:08:14 <libcoin> _counter = 0;
 73 2012-02-24 10:08:15 <libcoin> Now it runs smoothly again - thanks for the help!
 74 2012-02-24 10:08:19 <Diablo-D3> damnit libcoin
 75 2012-02-24 10:08:29 <sturles> I have mostly sent to your japanese bank.
 76 2012-02-24 10:08:38 <MagicalTux> libcoin: just drop the if (GetTime() > ...)
 77 2012-02-24 10:08:44 <MagicalTux> there's no chance it'll be < to that value anymore
 78 2012-02-24 10:08:53 <Diablo-D3> MagicalTux: yes there is
 79 2012-02-24 10:09:02 <sturles> You can also get the information directly from the central registry if you have a legal reson for it.
 80 2012-02-24 10:09:15 <libcoin> Agree... I will keep it as a rimnder for myself for a couple of days :-D
 81 2012-02-24 10:09:36 <sturles> Some information in English here: http://www.skatteetaten.no/en/International-pages/Employee/working/Norwegian-employer/77885/Remember-to-report-any-change-of-address/
 82 2012-02-24 10:10:08 <MagicalTux> sturles: don't they provide you with a receipt, or stuff ?
 83 2012-02-24 10:10:18 <sturles> Not on paper, no.
 84 2012-02-24 10:10:28 <sturles> You can look it up electronically.
 85 2012-02-24 10:10:46 <sturles> I get a tax receipt on paper.  That's about everything.
 86 2012-02-24 10:11:28 <sturles> The tax receipt includes my officially registered address directly from the source.
 87 2012-02-24 10:12:13 <sturles> I think Japan has a similar system?  We also have personal identification numbers.
 88 2012-02-24 10:14:07 <sturles> I can download my utility bills as PDFs from my bank, but I don't expect them to be accepted since a PDF is trivial to change.
 89 2012-02-24 10:29:26 <sturles> Nevermind.  Wrong channel anyway.  Sent a support request.
 90 2012-02-24 10:38:04 <vegard> why is the wallet flushed whenever a block is received?
 91 2012-02-24 12:45:03 <TD> is there an issue with the network at the moment?
 92 2012-02-24 12:45:15 <TD> for some reason none of the nodes my client is trying are accepting connections/still present
 93 2012-02-24 12:46:57 <TD> huh
 94 2012-02-24 12:46:58 <TD> there we go
 95 2012-02-24 12:47:06 <TD> there must be a lot of stale addresses in my addr.dat
 96 2012-02-24 13:38:40 <finway> i guess 17 is too long?
 97 2012-02-24 13:38:41 <finway> What's the max length of rpcpassword ?
 98 2012-02-24 13:40:16 <gmaxwell> No. 17 is not too long.
 99 2012-02-24 13:40:31 <gmaxwell> Some tools have a hard time if you include some special characters however.
100 2012-02-24 13:42:04 <finway> gmaxwell: oh, i see
101 2012-02-24 13:46:37 <Joric> gmaxwell, what if make fee dependent of the difficulty? seems pretty fair
102 2012-02-24 13:49:12 <Joric> this way bitcoin could really be divisible to 8 decimal places
103 2012-02-24 13:51:09 <sipa> fee should depend (in an economic sense) on the exchange rate of bitcoins, on how valuable the transactions done using it are
104 2012-02-24 13:51:22 <jrmithdobbs> gmaxwell: so how long you think grabbing the last two months of blocks should take on a core2 1.7 and ssd with -connect to a semi-local host?
105 2012-02-24 13:51:33 <jrmithdobbs> if i grab .6
106 2012-02-24 13:51:58 <sipa> jrmithdobbs: I have a patch for importing a blk0001.dat file into bitcoin
107 2012-02-24 13:52:02 <wumpus> sipa: I don't think I agree -- the fee is for storage costs, so is based on the size of the transaction in bytes, not in coins
108 2012-02-24 13:52:19 <jrmithdobbs> sipa: i'm specifically interested in how performance of large downloads has gotten since .4 ;p
109 2012-02-24 13:52:42 <sipa> wumpus: You don't pay for storage costs.
110 2012-02-24 13:52:54 <sturles> The fee depends on the miners now.  There is a default value, but it is entirely up to miners what transactions go into a block.  Is there any plans to change that?
111 2012-02-24 13:53:12 <sipa> wumpus: Miners are the judges for what to store, but they are not those who do most of the storage.
112 2012-02-24 13:53:15 <wumpus> sipa: but the storage and network traffic is what is the cost factor
113 2012-02-24 13:53:16 <helo> there's no decentralized way to determine the exchange rate... don't miners just need to be able to their fee requirements easily?
114 2012-02-24 13:53:20 <sturles> Some miners take inn all transactions there is space for in the block.  One miner only take transactions with a fee.
115 2012-02-24 13:53:26 <wumpus> sipa: not the number of coins sent
116 2012-02-24 13:53:37 <helo> "to set"
117 2012-02-24 13:53:53 <wumpus> sipa: it doesn't matter for a miner for processing whether 0.01 is being sent of 1000
118 2012-02-24 13:53:59 <wumpus> or*
119 2012-02-24 13:54:09 <sturles> Miners can choose to vary their demanded fee on exchange rate.  It's up to them.
120 2012-02-24 13:54:11 <sipa> wumpus: no, but it does change the incentive for the attacker
121 2012-02-24 13:54:27 <sipa> wumpus: and defence against that attacker is what you pay for
122 2012-02-24 13:54:58 <wumpus> how? if you pay less fees for a small transaction than a big one, it's easier to flood with smaller transactions
123 2012-02-24 13:55:32 <wumpus> the attack is clogging the block chain right?
124 2012-02-24 13:55:56 <sipa> sure, prevention against DOS attacks is another reason why we have fees now
125 2012-02-24 13:55:56 <sturles> Later, when miners depend more on fees, the mining power will adjust dynamically to the possible fees.  If there is a lot of fees waiting, more hashpower will get phased in to solve the block.  No fees -> miners are automatically halting mining to conserve power.
126 2012-02-24 13:56:55 <sipa> wumpus: i'm more talking about a hypothetical future were mining income is mostly based on fees, and people pay for getting their transactions included
127 2012-02-24 13:57:59 <wumpus> okay
128 2012-02-24 13:58:30 <sipa> if i trust a received payment to not be double-spent, i don't care whether it is in the block chain or not quickly
129 2012-02-24 13:58:44 <sipa> -"or not"
130 2012-02-24 14:03:21 <Joric> any thoughts how big the blockchain would be to 2013? the tentency is pretty scary http://goo.gl/kAYPK
131 2012-02-24 14:15:46 <forrestv> Joric, be more concerned about bandwidth requirements to maintain a node; the entire blockchain can be theoretically reduced to a single merkle hash (if you trust the source of it)
132 2012-02-24 14:17:49 <sipa> The hash of the block at the top of the chain in itself is a cryptographic proof of the entire history
133 2012-02-24 14:17:55 <sipa> That doesn't mean it's usable ;)
134 2012-02-24 14:17:58 <btc_novice> forrestv: but until that's implemented, we should still be concerned about block chain size.
135 2012-02-24 14:19:17 <forrestv> btc_novice, nobody has thought of a way to greatly reduce bitcoin's bandwidth without compromising its characteristics (at least that i've heard of)
136 2012-02-24 14:19:30 <forrestv> block chain size at least has a theoretical solution :P
137 2012-02-24 14:50:08 <LittleDuke> fyi, got namecoind to compile on FreeBSD 7.1 (32-bit) last night, working on 8.2 (64-bit) now...
138 2012-02-24 15:04:13 <jgarzik> hum
139 2012-02-24 15:04:24 <gavinandresen> I was just thinking the same thing
140 2012-02-24 15:04:25 <jgarzik> wonder which email genjix is talking about
141 2012-02-24 15:04:46 <jgarzik> ---> <genjix> your email address is broken/down
142 2012-02-24 15:04:57 <jgarzik> that's a bit vague :)
143 2012-02-24 15:05:11 <gavinandresen> Oh, I was going "hum" over qtipcserver.cpp .....
144 2012-02-24 15:06:20 <gavinandresen> sipa:  do you know why ipcInit() does a little dance with message_queue::timed_receive ?
145 2012-02-24 15:07:01 <copumpkin> ;;seen roconnor
146 2012-02-24 15:07:01 <gribble> roconnor was last seen in #bitcoin-dev 1 week, 0 days, 0 hours, 25 minutes, and 46 seconds ago: <roconnor> Dear user n27pHgA6KioCvXUCdijzdFjeaa9kHA7kzi, Due to your violation of bitcoin TOS your asset has been frozen and your private key is being disclosed as 9afaa65b092e4c82ea752080bee6ce53398207dca480f64c82f32bdb7f85b7e5. Have a nice day, and thank you for using bitcoin.
147 2012-02-24 15:09:30 <etotheipi_> hahah
148 2012-02-24 15:10:21 <sipa> gavinandresen: No idea at all.
149 2012-02-24 15:10:34 <etotheipi_> I don't see any transactions behind either of those addresses though...  I wonder how roconner got it....
150 2012-02-24 15:10:46 <sipa> gavinandresen: But the problem is that timed_receive?
151 2012-02-24 15:10:47 <gavinandresen> sipa: ok, thanks, I'll ask Matt
152 2012-02-24 15:10:52 <etotheipi_> (*either = trying both endiannesses of that private key)
153 2012-02-24 15:11:26 <sipa> gavinandresen: Do you know whather timed_receive itself is using 100% CPU, or whether it is immediately returning false?
154 2012-02-24 15:11:27 <gavinandresen> sipa:  yes, looks like a boost bug on Mac.  I'm thinking of replacing it with a plain-old receive
155 2012-02-24 15:11:59 <sipa> Which of both?
156 2012-02-24 15:13:09 <sipa> http://mrajcok.wordpress.com/2010/10/06/boost-message_queue-timed_receive-eating-100-cpu/
157 2012-02-24 15:13:21 <etotheipi_> sipa, I meant, I imported that private key by roconnor, in both endiannesses... neither one has any transactions
158 2012-02-24 15:13:39 <riush> etotheipi_: it's a testnet address
159 2012-02-24 15:14:04 <riush> http://test.bitcoin.interesthings.de/address/n27pHgA6KioCvXUCdijzdFjeaa9kHA7kzi
160 2012-02-24 15:14:37 <etotheipi_> riush, oh right... I didn't notice that part
161 2012-02-24 15:14:57 <sipa> etotheipi_: I'm kinda glad roconnor didn't do his attack on mainnet :)
162 2012-02-24 15:15:06 <etotheipi_> what was the attack?
163 2012-02-24 15:32:09 <jgarzik> ok, figured out the problem
164 2012-02-24 15:32:14 <jgarzik> DNS service needed renewing
165 2012-02-24 15:33:17 <copumpkin> what's the current status on the duplicate transaction id issue?
166 2012-02-24 15:33:39 <copumpkin> roconnor seems to think it's pretty serious
167 2012-02-24 15:34:56 <copumpkin> and should warnings be sent out to people doing API-like things about it?
168 2012-02-24 15:35:51 <gavinandresen> copumpkin: patch is being tested.  What do you mean by 'people doing API-like things?'
169 2012-02-24 15:37:05 <copumpkin> just warning people using the RPC interface for whatever that they should do their best to avoid relying on the uniqueness of transaction ids
170 2012-02-24 15:37:14 <copumpkin> not sure how much people rely on that
171 2012-02-24 15:37:30 <copumpkin> (or the fact that transactions can be overwritten, I should say)
172 2012-02-24 15:39:08 <gavinandresen> The plan is to make duplicate transactions illegal, first with a patch that fixes the immediate problem and then with changes to make them impossible to generate.
173 2012-02-24 15:40:31 <gavinandresen> Asking people to handle different transactions with the same transaction id just isn't workable, in my humble opinion
174 2012-02-24 15:41:41 <copumpkin> oh, I don't mean that
175 2012-02-24 15:42:31 <copumpkin> I just mean warning them that there is currently an issue and that they should do their best to avoid relying on anything that could be broken
176 2012-02-24 15:45:37 <etotheipi_> so what is the plan for making them "illegal"?
177 2012-02-24 15:46:07 <etotheipi_> *how will it be enforced
178 2012-02-24 15:46:20 <libcoin> Regarding the timed_receive 100% CPU usage on Mac - it also applies to receive. The "hack" is to do a try_receive every second or so, however, it will make only little sense as the way you have implemented protocol handling only applies to windows (and perhaps linux?)  anyway. On Mac you need to listen to an event.
179 2012-02-24 15:46:24 <gavinandresen> etotheipi_: https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks
180 2012-02-24 15:46:42 <gavinandresen> etotheipi_: ... and sipa has a patch that fixes the immediate problem
181 2012-02-24 15:47:16 <luke-jr> IMO something should probably be merged for 0.6
182 2012-02-24 15:47:20 <libcoin> And btw - it is not a boost bug - if you look at the code it is just a fall back solution for some platforms
183 2012-02-24 15:47:41 <luke-jr> it's too easy to exploit
184 2012-02-24 15:47:55 <sipa> luke-jr: if you have cooperation from a large pool, yes
185 2012-02-24 15:47:56 <gavinandresen> sipa's patch will be merged as soon as he tells me it is ready for merging.
186 2012-02-24 15:48:05 <etotheipi_> gavinandresen, I'm not fluent enough in bitcoinC++ to figure out what "discourage" means... is that simply "don't accept and don't forward?"
187 2012-02-24 15:48:10 <sipa> gavinandresen: that implies we decide on a date
188 2012-02-24 15:48:24 <sipa> etotheipi_: accept but don't forward
189 2012-02-24 15:48:34 <luke-jr> sipa: you just need to generate 2 blocks over an unlimited time period; doesn't need a pool
190 2012-02-24 15:48:38 <sipa> and don't mine on top of it
191 2012-02-24 15:48:51 <etotheipi_> sipa, that doesn't make sense... it sounds like it wouldn't be accepted
192 2012-02-24 15:48:55 <gavinandresen> luke-jr: no, to exploit it you need to force a re-org, which is not easy
193 2012-02-24 15:49:02 <etotheipi_> if it's "accepted", it seems you would automatically be mining off of it
194 2012-02-24 15:49:13 <luke-jr> gavinandresen: it's not hard eithert
195 2012-02-24 15:49:24 <gavinandresen> ... if you have a big pool with lots of hashing power
196 2012-02-24 15:49:34 <luke-jr> gavinandresen: you just need to connect to a large number of peers, and as soon as you see someone else announce a block, you announce yours
197 2012-02-24 15:50:04 <gavinandresen> luke-jr: "as soon as you see" is probably too late to force a re-org
198 2012-02-24 15:50:06 <luke-jr> if you're careful to announce the other person's block to the big pools, you can almost guarantee yours is orphaned
199 2012-02-24 15:50:28 <luke-jr> gavinandresen: if you connect to almost all the nodes, you will see it before it gets flooded much
200 2012-02-24 15:51:00 <luke-jr> I suspect the attacker could get 90% nodes with a reorg
201 2012-02-24 15:51:10 <gavinandresen> well, in any case, we need to fix it "with all due haste"
202 2012-02-24 15:51:37 <sipa> also, the attack can only be used on transactions that depend entirely on a duplicated coinbases, which you can see 120 blocks in advance
203 2012-02-24 15:51:47 <sipa> and there is no financial gain to the attacker
204 2012-02-24 15:51:51 <gavinandresen> ... but I don't want people to think there is any reason to panic.  This is not like the overflow bug
205 2012-02-24 15:52:03 <luke-jr> sipa: I'm just talking without a txn
206 2012-02-24 15:52:19 <luke-jr> gavinandresen: no reason to panic; it's fixed with a redownload
207 2012-02-24 15:52:59 <luke-jr> unless someone does the more complicated txn-based attack anyhow
208 2012-02-24 15:53:19 <sipa> "talking without a txn" ?
209 2012-02-24 15:53:35 <luke-jr> sipa: ie, just 2 blocks
210 2012-02-24 15:53:46 <sipa> ?
211 2012-02-24 15:53:50 <libcoin> do you have a description of the attack somewhere - I can't figure out the (cheap) generation of tx with same hash ?
212 2012-02-24 15:54:08 <sipa> http://r6.ca/blog/20120206T005236Z.html
213 2012-02-24 15:54:15 <etotheipi_> offtopic:  if I shutoff networking entirely, then turn it on (such as a smartphone going to sleep), how quickly do you think I can acquire connections to 3-5 peers
214 2012-02-24 15:54:26 <luke-jr> sipa: mine 1 block, <any length of time>, mine 2nd block and ensure it's orphaned (as explained above), then spend the coinbase
215 2012-02-24 15:54:38 <jrmithdobbs> etotheipi_: seconds assuming latency/packet loss isn't too bad
216 2012-02-24 15:54:42 <libcoin> sipa: thanks
217 2012-02-24 15:55:02 <etotheipi_> jrmithdobbs, perfect... that's what I was hoping for, but I don't have any experience yet, to know for sure
218 2012-02-24 15:55:19 <sipa> luke-jr: yup, block chain split
219 2012-02-24 15:55:31 <jrmithdobbs> etotheipi_: worse case you'll cycle through some dead/stale peers in addr.dat before finding some still listening
220 2012-02-24 15:56:00 <etotheipi_> jrmithdobbs, what about if I don't have any existing peers?  perhaps I want to make sure I get a different crowd every time?
221 2012-02-24 15:56:24 <jrmithdobbs> etotheipi_: dns seeds should give you known good peers so not an issue
222 2012-02-24 15:56:25 <luke-jr> correction to my statement above: I meant 90% of *online* nodes
223 2012-02-24 15:56:46 <etotheipi_> jrmithdobbs, is it still the same order-of-magnitude? (in terms of time to collect peers)
224 2012-02-24 15:56:57 <sipa> luke-jr: but that is not fixed with an update to the client, as those would risk to be orphaned even more easily
225 2012-02-24 15:57:16 <jrmithdobbs> etotheipi_: ya, you'll still find good peers in seconds
226 2012-02-24 15:57:44 <jrmithdobbs> etotheipi_: sometimes faster since if you're using cached peers you'll cycle through more dead ones where the dns seeds filter those out fairly effectively
227 2012-02-24 16:11:13 <jrmithdobbs> curl -L -o - http://bitcoin.sipa.be/seeds.txt 2>/dev/null </dev/null | egrep -n "$(echo -n '^('; ifconfig -a | egrep -o '(addr:|inet )[0-9]+[.][0-9]+[.][0-9]+[.][0-9]+' | cut -d: -f2 | cut -d  -f2 | sed 's,[.],[.],g' | tr '\n' '|'; echo -n '# )')"
228 2012-02-24 16:12:00 <jrmithdobbs> easy way to check for a node in sipa's seeds/uptime list so long as the public address is actually assigned on the box
229 2012-02-24 16:12:20 <gribble> New news from bitcoinrss: xHire opened pull request 891 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/891>
230 2012-02-24 16:50:09 <jine> jrmithdobbs: What does that seed/uptime list show actually? Cause it's not correct imo.
231 2012-02-24 16:50:24 <jine> This is our bitcoind (at pool.bitlc.net):
232 2012-02-24 16:50:25 <jine> 46.253.195.51:833311.26%30.93%29.07%6.86%1.71%60000 "/bitcoin-qt:0.5.99/"
233 2012-02-24 16:50:44 <jine> 46.253.195.51:8333    11.26%     30.93%     29.07%     6.86%      1.71%      60000 "/bitcoin-qt:0.5.99/"
234 2012-02-24 16:51:00 <jine> 11-30% uptime in the past days? :P
235 2012-02-24 16:51:02 <jrmithdobbs> jine: the "uptime" is based on connectability, not running
236 2012-02-24 16:51:26 <jrmithdobbs> jine: so if sipa's monitor could successfully connect and get a version it's up, if it couldn't connect, it's not
237 2012-02-24 16:51:39 <jrmithdobbs> jine: and default connection limit is 128
238 2012-02-24 16:52:01 <jine> Ah, i see. It has to be the connection limit in that case.
239 2012-02-24 16:52:36 <jrmithdobbs> it also doesn't actually have a full 30 days of stats yet sipa was saying
240 2012-02-24 20:50:15 <dump_> Where all the drunk bitches?
241 2012-02-24 20:50:46 <helo> they passed out hours ago :(
242 2012-02-24 21:09:01 <phantomcircuit> jrmithdobbs, ahah oh wow
243 2012-02-24 21:09:27 <phantomcircuit> he's from norway
244 2012-02-24 21:09:39 <jrmithdobbs> phantomcircuit: huh?
245 2012-02-24 21:09:45 <phantomcircuit> internet tough guy
246 2012-02-24 21:09:55 <phantomcircuit> hard to take a tough guy norweign seriously
247 2012-02-24 21:10:04 <jrmithdobbs> that's like a tough guy ukranian
248 2012-02-24 21:10:11 <jrmithdobbs> what they gonna do? bleed on you?
249 2012-02-24 21:12:49 <Zarutian> what is it about internet tough guys? What do most of think they could do?
250 2012-02-24 21:13:27 <BlueMatt> they just have really small realpeen, so they have to pretend they have big epeen
251 2012-02-24 21:14:06 <coingenuity> my reelpeen is tiny :( like a tic-tac
252 2012-02-24 21:14:14 <BlueMatt> ...
253 2012-02-24 21:14:14 <coingenuity> that is why i threaten j00 on irc.
254 2012-02-24 21:14:21 <coingenuity> ill kick ur azz BlueMatt:D
255 2012-02-24 21:14:30 <coingenuity> and you too phantom!
256 2012-02-24 21:14:32 <coingenuity> :P
257 2012-02-24 21:14:37 <BlueMatt> I will pwn ur a$$
258 2012-02-24 21:14:53 <coingenuity> nah i am 8 feet tall and 900 pounds of muscle
259 2012-02-24 21:15:03 <BlueMatt> Im sure
260 2012-02-24 21:15:10 <coingenuity> i also have fusts made of sledgehammers
261 2012-02-24 21:15:15 <coingenuity> fists*
262 2012-02-24 21:15:20 <coingenuity> and lazer-eyes
263 2012-02-24 21:15:28 <BlueMatt> (my realpeen is 9 foot long and 500 pounds of muscle...)
264 2012-02-24 21:15:32 <coingenuity> XFD
265 2012-02-24 21:15:34 <Zarutian> BlueMatt: yeah, is it that similar to the guys who soup up honda civic hummers with kits, lights and kello kitty stickers?
266 2012-02-24 21:15:39 <coingenuity> hahahasha
267 2012-02-24 21:15:44 <coingenuity> BlueMatt++
268 2012-02-24 21:15:45 <BlueMatt> Zarutian: yea, something like that
269 2012-02-24 21:16:33 <phantomcircuit> lol so im reading dmesg trying to identify the source of timing info
270 2012-02-24 21:16:42 <phantomcircuit> and i realize i actually understand most of this now
271 2012-02-24 21:16:43 <phantomcircuit> lol
272 2012-02-24 21:17:54 <egecko> hrm... this is taking a long time to catch up to 300 blocks
273 2012-02-24 21:18:35 <phantomcircuit> gmaxwell, i have 2 processes one calls gettimeofday() and sends the result to the other one which calls gettimeofday itself and prints the difference
274 2012-02-24 21:18:41 <phantomcircuit> messages are coming from the future
275 2012-02-24 21:18:43 <phantomcircuit> what the fuck
276 2012-02-24 21:19:16 <jrmithdobbs> phantomcircuit: does it call gettimeofday() before or after read()?
277 2012-02-24 21:19:21 <jrmithdobbs> (receiving end)
278 2012-02-24 21:19:26 <phantomcircuit> before
279 2012-02-24 21:19:28 <phantomcircuit> no
280 2012-02-24 21:19:39 <phantomcircuit> it receives the published time
281 2012-02-24 21:19:44 <phantomcircuit> calls gettimeofday
282 2012-02-24 21:19:45 <jrmithdobbs> if it's before i think you answered your own question
283 2012-02-24 21:19:48 <phantomcircuit> calculates the difference
284 2012-02-24 21:19:51 <phantomcircuit> prints the result
285 2012-02-24 21:20:01 <phantomcircuit> read your question wrong
286 2012-02-24 21:20:10 <jrmithdobbs> well that's interesting then
287 2012-02-24 21:34:41 <gribble> New news from bitcoinrss: dooglus opened pull request 892 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/892>
288 2012-02-24 21:42:23 <DrHaribo> Hm, Satoshi seems to have a sick fetish for mixing up endianness.
289 2012-02-24 21:42:49 <BlueMatt> or just doesnt care about rare architectures...
290 2012-02-24 21:42:54 <BlueMatt> (or semirare)
291 2012-02-24 21:48:04 <dikidera> the first sounds reasonable
292 2012-02-24 21:50:16 <phantomcircuit> lol
293 2012-02-24 21:50:23 <phantomcircuit> jrmithdobbs, it's just a fucking floating point bug
294 2012-02-24 21:50:28 <phantomcircuit> time.time() in python is a float
295 2012-02-24 21:50:34 <jrmithdobbs> wtf, why?
296 2012-02-24 21:50:44 <jrmithdobbs> there's no reason for that to be a float
297 2012-02-24 21:50:45 <BlueMatt> wait, what???
298 2012-02-24 21:51:01 <BlueMatt> thats like sending floats for balances in financial software
299 2012-02-24 21:51:04 <BlueMatt> ...oh, wait...
300 2012-02-24 21:51:06 <phantomcircuit> :)
301 2012-02-24 21:54:13 <jrmithdobbs> BlueMatt: nicely played, sir
302 2012-02-24 21:54:25 <etotheipi_> I use long(time.time()) all the time!
303 2012-02-24 21:54:45 <etotheipi_> the float thing has thrown me off a bit... but supposendly it has microsecond precision
304 2012-02-24 21:54:56 <etotheipi_> where as long(time.time()) gives you only integer seconds
305 2012-02-24 21:55:21 <jrmithdobbs> still shouldn't be a float
306 2012-02-24 21:55:43 <etotheipi_> jrmithdobbs, then what should it be, for people who need more resolution than 1s?
307 2012-02-24 21:56:03 <jrmithdobbs> etotheipi_: two ints in a struct is hard now?
308 2012-02-24 21:56:45 <etotheipi_> seems unnecessarily complex when you can just repr the exact values as a single double with human-understandable meaning
309 2012-02-24 21:57:55 <etotheipi_> (not that either form is particularly complex)
310 2012-02-24 22:01:42 <jrmithdobbs> etotheipi_: it seems unnecessarily complex right up to the moment you need to manipulate everything < or > 1s
311 2012-02-24 22:01:53 <jrmithdobbs> which is a pretty damned common use case
312 2012-02-24 22:04:42 <phantomcircuit> lol
313 2012-02-24 22:04:47 <phantomcircuit> so tcp connection
314 2012-02-24 22:06:37 <phantomcircuit> s.send(str(datetime.datetime.now()))
315 2012-02-24 22:12:10 <phantomcircuit> lol it takes like 200 usec to parse the date string
316 2012-02-24 22:14:12 <sipa> lolwut?
317 2012-02-24 22:15:41 <phantomcircuit> sipa, lolol yeah