1 2014-10-05 02:04:07 <gmaxwell> 18:55 < brisque> bitnodes.io is worse than blockchain.info in terms of client spam though. they are very rapid in their connections and flood constantly.
  2 2014-10-05 02:04:10 <gmaxwell> 18:56 < brisque> they now do this fucking stupid thing where they connect, dump your mempool, then dc, wait a few seconds, and do it again
  3 2014-10-05 02:14:47 <jgarzik> gmaxwell, brisque, ya, I've pondering writing a rate limiting patch specifically for that site
  4 2014-10-05 02:15:07 <jgarzik> "I don't want to see any node more than once per 60 secs"
  5 2014-10-05 02:15:31 <jgarzik> constant reconnection is annoying
  6 2014-10-05 02:16:00 <jgarzik> sucks for sockets, poor network behavior for a variety of reasons, potentially uses connection slots someone needs in a crunch, ...
  7 2014-10-05 02:16:22 <gmaxwell> yea, I think we should say "a non-whitelisted node that reconnects within X seconds since being disconnected is banned" with x at some reasonable value like 30 or 60 seconds.
  8 2014-10-05 02:16:59 <gmaxwell> coupled with some random disconnections here and there some of the huge socket wasters will have to chose less abusive strategies.
  9 2014-10-05 02:17:35 <gmaxwell> We also need something to deal with the "transfers oodles of data, never does anything useful for us at all" but I haven't come up with a crisp and safe policy for that.
 10 2014-10-05 02:24:03 <kanzure> what about rating connected peers, culling low performers periodically where reconnects would require them to rebuild their peer score?
 11 2014-10-05 02:25:02 <kanzure> giving worse service to low scoring peers would be bad for newly-connecting nodes (various sybil issues too), so that wont work. hrm.
 12 2014-10-05 02:25:40 <glassem> What does a miner do if they receive a transaction referencing a transaction hash they don't know about yet?
 13 2014-10-05 02:26:16 <kanzure> isn't that the same as referencing any other non-existing input?
 14 2014-10-05 02:26:42 <glassem> Uh, I'm a noob
 15 2014-10-05 02:26:47 <glassem> what happens in that case? :P
 16 2014-10-05 02:30:00 <Luke-Jr> glassem: it gets stored in a cache and ignored
 17 2014-10-05 02:30:12 <Luke-Jr> until/unless a transaction is received satisfying it
 18 2014-10-05 02:31:15 <glassem> what if they are mutually dependent?
 19 2014-10-05 02:32:23 <Ireneista> the relevant code which would have the responsibilty for detecting a cycle in the transaction graph is the function starting at https://github.com/bitcoin/bitcoin/blob/3fd192f8b4d6db386354dfe635a8a6a105b55de8/src/miner.cpp#L78
 20 2014-10-05 02:32:27 <Ireneista> but it’s not clear to me whether it does so :)
 21 2014-10-05 02:32:33 <Ireneista> it would be “cute” ><
 22 2014-10-05 02:32:40 <Luke-Jr> glassem: let me know when you have a test case for that..
 23 2014-10-05 02:33:16 <glassem> oooh
 24 2014-10-05 02:33:18 <glassem> right
 25 2014-10-05 02:33:19 <Luke-Jr> :p
 26 2014-10-05 02:33:28 <glassem> hey, it's totally computable
 27 2014-10-05 02:33:34 <Luke-Jr> …
 28 2014-10-05 02:33:36 <Luke-Jr> no, it isn't.
 29 2014-10-05 02:33:37 <glassem> tractability is a triviality
 30 2014-10-05 02:33:54 <Luke-Jr> the transactions would need to have the hash of the other in them
 31 2014-10-05 02:34:00 <glassem> yeah
 32 2014-10-05 02:34:01 <Luke-Jr> you'd need to break SHA256d pretty bad to do it
 33 2014-10-05 02:34:08 <glassem> that's still computable
 34 2014-10-05 02:34:12 <glassem> just not tractable
 35 2014-10-05 02:34:21 <Luke-Jr> I mean, you couldn't even do it if we were using MD5
 36 2014-10-05 02:34:23 <Ireneista> lol ><
 37 2014-10-05 02:34:36 <Ireneista> well, that’s a strong statement, MD5 is pretty broken :)
 38 2014-10-05 02:34:42 <Ireneista> you’re right, they’d have to reference each other by hash
 39 2014-10-05 02:34:42 <Luke-Jr> not THAT broken
 40 2014-10-05 02:34:46 <Ireneista> it would take a lot of compute time
 41 2014-10-05 02:34:54 <Ireneista> 
ACTION shrugs

 42 2014-10-05 02:35:08 <Ireneista> yeah, we were discussing this amusing possibility elsewhere and thought we’d bring it here
 43 2014-10-05 02:35:20 <Luke-Jr> "a lot" being more time than the universe has existed..
 44 2014-10-05 02:35:43 <Ireneista> under present assumptions, yeah
 45 2014-10-05 02:35:52 <Ireneista> I agree that it can’t be done right now :)
 46 2014-10-05 02:36:01 <Ireneista> sorry, I don’t really want to troll
 47 2014-10-05 02:38:54 <Ireneista> thank you for educating us :)
 48 2014-10-05 03:04:37 <coinheavy> Is it just a rumor that there was an initial bug for ~2 years that allowed anyone to spend anyone else's coins?  (I can't find the source but I recall it being found and patched without ever being exploited)
 49 2014-10-05 03:08:48 <justanotheruser> coinheavy: not sure about 2 years, but yeah
 50 2014-10-05 03:08:59 <justanotheruser> it would have to be softforked immediately if someone did double-spend
 51 2014-10-05 03:09:38 <coinheavy> justanotheruser: thanks for confirming.  I can't seem to find the post on bitcointalk and I haven't had much luck looking through commits/releases on github.  Any idea where I might find more info?
 52 2014-10-05 03:09:53 <glassem> why isn't there an organized system for bribing miners to boycott a transaction?
 53 2014-10-05 03:10:10 <justanotheruser> I tried to find info on it. I remember reading on the dev list someone mentioning
 54 2014-10-05 03:10:13 <justanotheruser> I'll try to find it
 55 2014-10-05 03:10:26 <coinheavy> justanotheruser: much appreciated
 56 2014-10-05 03:11:20 <justanotheruser> coinheavy: https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5141
 57 2014-10-05 03:12:17 <coinheavy> justanotheruser: cheers -- that's the one!
 58 2014-10-05 04:31:21 <prettymuchbryce> Anyone know where I can find an up-to-date list of the opcode's still accepted by the majority of nodes ?
 59 2014-10-05 04:31:59 <Luke-Jr> prettymuchbryce: opcodes are not a matter of majority.
 60 2014-10-05 04:32:35 <justanotheruser> Luke-Jr: they're a matter of miner majorty
 61 2014-10-05 04:32:41 <Luke-Jr> nope
 62 2014-10-05 04:32:51 <prettymuchbryce> Can you explain your thinking Luke-Jr ?
 63 2014-10-05 04:33:05 <justanotheruser> Luke-Jr: miners can softfork out opcodes or softfork in opcodes within OP_EVA?L
 64 2014-10-05 04:33:11 <Luke-Jr> prettymuchbryce: opcodes are dictated by consensus, so 100% of nodes must agree on them or it doesn't work
 65 2014-10-05 04:35:50 <sipa> in blocks
 66 2014-10-05 04:36:01 <prettymuchbryce> Luke-Jr Nodes send transactions to each other via the inv message, but if they receive a tx which they determine has an invalid opcode via !::IsStandard. Then the transaction won't be relayed to peers.
 67 2014-10-05 04:36:05 <sipa> for lone transaction individuao nodes may have different rules
 68 2014-10-05 04:36:28 <Luke-Jr> prettymuchbryce: IsStandard has no relationship with validity or invalidity of opcodes
 69 2014-10-05 04:38:32 <justanotheruser> well isstandard should always be a subset of isvalid
 70 2014-10-05 04:40:00 <sipa> actually, not at all
 71 2014-10-05 04:40:23 <sipa> isstandard is just a quick bailout before validation of a transaction is even attempted
 72 2014-10-05 04:40:40 <sipa> but there are many more rules that affect whether a transaction is relayed
 73 2014-10-05 04:40:46 <sipa> beyond isstandard and validity
 74 2014-10-05 04:40:57 <sipa> like throttling low-fee transactions
 75 2014-10-05 04:41:11 <sipa> or double spends (which are technically valid) are ignored
 76 2014-10-05 04:41:18 <Luke-Jr> and noteworthy: developers should not base decisions on whether the transaction they create passes IsStandard or not
 77 2014-10-05 04:41:59 <sipa> prettymuchbryce: to answer your actual question: in p2sh nearly everything is allowed these days
 78 2014-10-05 04:42:26 <sipa> though i don't think the majority of nodes are new enough
 79 2014-10-05 04:43:02 <prettymuchbryce> Sorry. I'm struggling to remember the actual reject error at the moment. Maybe it is check() (non-canonical).
 80 2014-10-05 04:43:07 <Luke-Jr> sipa: 0.9.3 didn't change that, did it?
 81 2014-10-05 04:43:15 <prettymuchbryce> And yes I am potentially talking about non-p2sh.
 82 2014-10-05 04:43:21 <Luke-Jr> prettymuchbryce: be sure then ;)
 83 2014-10-05 04:43:26 <Luke-Jr> non-canonical is a bigger deal
 84 2014-10-05 04:46:13 <sipa> prettymuchbryce: outside of p2sh, just multisig up to 3 keus
 85 2014-10-05 08:30:36 <visiteur_1> test
 86 2014-10-05 09:29:00 <dabura667> Luke-Jr: What does "TBC" mean? tera-bitcoin? or tera-satoshi? or something else?
 87 2014-10-05 09:29:30 <Apocalyptic> probably Tonal Bitcoin
 88 2014-10-05 09:31:20 <dabura667> oh ok
 89 2014-10-05 09:31:23 <dabura667> I see the wiki now.
 90 2014-10-05 09:31:27 <dabura667> Thanks
 91 2014-10-05 10:07:56 <visiteur_1> if you are well off and healthy please consider to make a donation and please spread it :) https://secure.changa.co.ke/myweb/share/3050
 92 2014-10-05 11:44:50 <xiando> Hi, I "upgraded" bitcoind on gentoo and a new use flag called ljr was enabled by default described as "Enable Luke Dashjr's patches". Now I get errors in the log saying AcceptToMemoryPool : ignoring transaction 289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice)
 93 2014-10-05 11:45:02 <hearn> er
 94 2014-10-05 11:45:11 <hearn> xiando: gentoo is patching bitcoin core with luke's patches *by default*?
 95 2014-10-05 11:45:13 <xiando> recompiling without the -stupidnazi useflag now, but just to be clear, this is the patches not the official client right?
 96 2014-10-05 11:45:21 <xiando> hearn: yes
 97 2014-10-05 11:45:26 <hearn> xiando: please please please do not use bitcoin packages from linux distros
 98 2014-10-05 11:45:38 <hearn> xiando: it's always better to obtain it from upstream.
 99 2014-10-05 11:46:28 <hearn> that's no good at all. they're forking it without renaming it.
100 2014-10-05 11:46:31 <xiando> I see your point but if you apply that logic to your whole system then you're in for a full-time job maintaining it. Some of us actually use our computers for things
101 2014-10-05 11:47:07 <xiando> anyway, just to confirm, this will be fixed when recompiling without the fascistidiotspatches use flag right?
102 2014-10-05 11:48:34 <hearn> we all use our computers for things ;) people who don't use linux still manage to be productive. anyway, i have no idea what that ebuild will do, but the fact that it's making such changes by default suggests it'd be better to stay away from it entirely. if they want to distribute a bitcoind with patches like luke's (which change behaviour in quite some fundamental ways) then they should do a proper upstream fork with a new name, so
103 2014-10-05 11:48:34 <hearn>  you are always sure what you're getting.
104 2014-10-05 11:50:26 <xiando> Oh now I see. I have the "bitcoin" overlay enabled and guess who owns that https://gitorious.org/bitcoin/gentoo/community
105 2014-10-05 11:51:06 <xiando> I guess it is better to just use the 0.9.2 in the official portage tree, then. Someone willing to censor payments is probably willing to do all sorts of other evil :-/
106 2014-10-05 11:56:14 <xiando> https://bugs.gentoo.org/show_bug.cgi?id=524512
107 2014-10-05 11:56:38 <xiando> It apperas that the default gentoo portage tree now has 0.9.3 and yes it enables the breakbitcoin useflag
108 2014-10-05 11:57:24 <xiando> perhaps gentoo developers don't know or they are short and therefore want bitcoin to be worthless (which it is the moment you for example say that you can pay for a bible but not the korean because we "don't like it")
109 2014-10-05 13:19:57 <vual> Hi there, sillly question maybe but i was going soo well..... how can i convert a "bitcoin address" to a "CTxDestination" in the bitcoin code?
110 2014-10-05 13:20:54 <vual> ok no that dosnt make sense
111 2014-10-05 13:22:37 <vual> well i was taking a "address string" and wanting to get the balance of it in the QT cpp code, so i made a map<CTxDestination, int64> and i passed it the output from wallet->GetAddressBalances() now i want to access it with the "address string" ie varible[CTxDestination]....
112 2014-10-05 13:22:55 <vual> does this make any sense? ..... sorry in advance if not
113 2014-10-05 13:25:04 <vual> anyone ?
114 2014-10-05 13:27:52 <vual> well yell out if anyone can take 5min to teach me where i missundertand what im doing here ill tip some btc for your time thank you
115 2014-10-05 13:43:42 <wumpus> vual: CTxDestination CBitcoinAddres.Get() maybe?
116 2014-10-05 13:44:41 <wumpus> defined in base58.h
117 2014-10-05 13:45:31 <vual> ok so CBitcoinAddress
118 2014-10-05 13:45:39 <vual> how can i convert address string to CBitcoinAddress
119 2014-10-05 13:46:58 <wumpus> CBitcoinAddress(string)
120 2014-10-05 13:47:41 <wumpus> you could have found that easily by looking at the class declaration
121 2014-10-05 13:49:00 <vual> thank you
122 2014-10-05 13:49:09 <vual> easily?
123 2014-10-05 13:49:30 <vual> tech me how please, how to do this, easily.
124 2014-10-05 13:50:05 <wumpus> well you search for CBitcoinAddress, which as I said is defined in base58.h ,then you see it has a constructor CBitcoinAddress(const std::string& strAddress) { SetString(strAddress); }
125 2014-10-05 13:50:52 <vual> ok
126 2014-10-05 13:50:55 <vual> but tahts not commited
127 2014-10-05 13:51:06 <vual> but yes ty i see what you mean
128 2014-10-05 13:51:12 <vual> *commented
129 2014-10-05 13:51:33 <vual> i appreciate the help thanks for that
130 2014-10-05 14:08:22 <Eliel> function and variable names themselves are a light form of documentation.
131 2014-10-05 14:28:55 <vual> thanks
132 2014-10-05 14:29:20 <vual> any idea about /usr/include/boost/thread/pthread/recursive_mutex.hpp:110: void boost::recursive_mutex::lock(): Assertion `!pthread_mutex_lock(&m)' failed. ? my code is :
133 2014-10-05 14:29:29 <vual> https://www.irccloud.com/pastebin/GzCmO8oP
134 2014-10-05 14:47:41 <vual> its balanceMap = wallet->GetAddressBalances(); thats giving the error
135 2014-10-05 14:47:52 <vual> when that line is commented out all works fine
136 2014-10-05 14:51:52 <wumpus> does using the listaddressgroupings RPC call also result in the same error?
137 2014-10-05 14:52:19 <wumpus> (its the primary user of GetAddressBalances)
138 2014-10-05 15:47:26 <Luke-Jr> xiando: so you're just trolling, or something is actually broken?
139 2014-10-05 15:49:29 <xiando> error message does say txes are rejected because you consider addresses bad, right
140 2014-10-05 15:51:59 <xiando> I am curious, what other kinds of addresses do you feel like blacklisting in the near future? those belonging to gay groups? religions you don't like? porn actors? political parties you disagree with?
141 2014-10-05 15:52:42 <Luke-Jr> ok, so you're just trolling
142 2014-10-05 15:52:55 <Luke-Jr> wrong channel for that, try ##trolls or something
143 2014-10-05 15:58:02 <xiando> ERROR: AcceptToMemoryPool : ignoring transaction                289673d37df1a709829b3f3ea7b8549703f4251f26f5721863aacbccc47b95a9 with blacklisted output (SatoshiDice)  <- explain this
144 2014-10-05 15:58:06 <xiando> What is a "blacklisted output"
145 2014-10-05 15:58:40 <Luke-Jr> xiando: one identified by a particular script
146 2014-10-05 16:00:19 <xiando> is that your patches or the official client?
147 2014-10-05 16:00:36 <Luke-Jr> xiando: there is no such thing as official
148 2014-10-05 16:00:49 <Luke-Jr> xiando: your questions seem more along the lines of #bitcoin material than development
149 2014-10-05 16:01:30 <xiando> Alright, then, the bitcoin-qt as in https://github.com/bitcoin/bitcoin
150 2014-10-05 16:02:45 <Luke-Jr> that feature is part of my patchset, which you can see on https://github.com/luke-jr/bitcoin/tree/0.9.x-ljr
151 2014-10-05 16:03:21 <xiando> If you can get your patches into that one then do it, if you can not and want to make it optional for people to get them then fine. If you can't get it in there then the right thing to do is not to force them upon gentoo users because you happen to have a position of power there and pretend it's the same client as everyone else gets
152 2014-10-05 16:03:39 <Luke-Jr> nobody is being forced to do anything
153 2014-10-05 16:03:52 <Luke-Jr> if you're going back to trolling, again see ##trolls
154 2014-10-05 16:06:00 <xiando> I see. Do you claim you are not forcing your patchset upon people because you believe the line IUSE="$IUSE 1stclassmsg dbus kde +ljr +qrcode test upnp" doe snot enable ljr by default due to there being a + there? Or are you just lying?
155 2014-10-05 16:07:19 <Luke-Jr> I'm not going to respond to further trolling. If you have more honest user questions, you can ask those in #bitcoin.
156 2014-10-05 16:08:51 <jaakkos> that is such horseshit. it's useless trying to negotiate with him.
157 2014-10-05 16:09:17 <xiando> jaakkos: elaborate
158 2014-10-05 16:09:29 <jaakkos> xiando: not with you.
159 2014-10-05 19:12:23 <chichov> how to get the balance of the whole wallet (all accounts) including tx's with 0 confirmations?
160 2014-10-05 19:13:17 <justanotheruser> chichov: getunconfirmedbalance
161 2014-10-05 19:13:41 <chichov> huh, didn't know such a thing exists
162 2014-10-05 19:13:53 <chichov> at least it's not listed in https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
163 2014-10-05 19:14:14 <chichov> justanotheruser: but you're right, it works like a charm :)
164 2014-10-05 19:14:16 <justanotheruser> chichov:  ¯\_(ツ)_/¯  0.9.3
165 2014-10-05 19:14:30 <justanotheruser> no idea when it was added
166 2014-10-05 19:15:40 <chichov> alrightie, I'll add it to my wrapper
167 2014-10-05 19:33:46 <espringe> Could anyone recommend a good default configuration setting for bitcoin core that will prevent me having trasactions left in unconfirm purgatory
168 2014-10-05 19:34:08 <espringe> I'm using the latest bitcoind to send transactions, and been getting recently a lot of complaints about transactions like: https://blockchain.info/tx/58d3b18c87e452299757da02dc00c47ecdd31fee552d98dbbbf568f460007812
169 2014-10-05 19:35:11 <sipa> espringe: set the fee to nonzero
170 2014-10-05 19:35:48 <espringe> sipa: As in 'paytxfee' ?
171 2014-10-05 19:36:01 <sipa> yes
172 2014-10-05 19:36:26 <espringe> sipa: Does that act as a fee floor? Or does it always use that exact amount?
173 2014-10-05 19:36:26 <sipa> 1000 satoshi or higher (per kilobyte, but paytxfee is per kilobyte already)
174 2014-10-05 19:37:17 <sipa> ^
175 2014-10-05 19:40:03 <gmaxwell> espringe: it's per-kilobyte of data. (there is a worst case maximum implied by the fact that it will never make a tx larger than 100kb; though it normally makes much smaller transactions; if at all possible)
176 2014-10-05 19:42:55 <espringe> I guess what I mean to say, is I'm happy paying 1000 satoshis / kb -- but I'd also be happier to pay more if deemed appropriate
177 2014-10-05 19:43:32 <espringe> i guess what i'm looking for is:  payatleasttxfee  or something
178 2014-10-05 19:43:45 <sipa> espringe: there's no good solution for that right now, except by looking at what fees are being paid right now
179 2014-10-05 19:44:06 <sipa> soon bitcoin core will automatically do such an estimation, and you can query it
180 2014-10-05 19:45:55 <espringe> Yeah nice. It's a bit problematic, like I just ordered something and they use CoinPayments.net to process the order. For what ever retarded reason, they reuse addresses and require the payment to have 2 confirmations within 3 hours, or it won't count against your order
181 2014-10-05 19:46:24 <sipa> that's crazy...
182 2014-10-05 19:46:38 <sipa> where does the money go if it confirms later?
183 2014-10-05 19:46:44 <sipa> do they refund it?
184 2014-10-05 19:46:47 <espringe> To other peoples orders, presumedly
185 2014-10-05 19:47:00 <sipa> ...
186 2014-10-05 19:47:02 <espringe> I just checked the address they gave me, and it received money 21 times
187 2014-10-05 19:47:15 <espringe> no wait, 31 times
188 2014-10-05 19:47:26 <espringe> Here's the address they told me to pay: https://blockchain.info/address/1CgwGc5VX6QbHFGC3AU7z5V5HXoYtGHmNE
189 2014-10-05 19:48:11 <espringe> Anyway, that's more of a case of someone else creating a stupid system
190 2014-10-05 19:48:25 <espringe> Why they'd want to reuse addresses for multiple peoples orders, i will never know
191 2014-10-05 19:49:17 <sipa> reusing addresses for receiving different payments from the same person is already bad for privacy, and should be discouraged, but doesn't hurt otherwise
192 2014-10-05 19:49:34 <sipa> reusing addresses to the point that you can't identify distinct payments anymore is just retarded
193 2014-10-05 19:51:58 <espringe> I really like reusing addresses on my site, as it makes it trivial for both me and the consumer to see all their deposits. But sharing the same address for multiple people, and giving them a windows time period to have the transaction confirm seems ill thought out
194 2014-10-05 19:52:36 <espringe> The only thing I can think of, is they don't know how to deterministically generate addresses, and want to have a big pool for backup purposes
195 2014-10-05 19:52:48 <sipa> You think making it trivial to see all deposits, by making the whole world see them, is a good idea?
196 2014-10-05 19:53:01 <sipa> Convenience trumps security every day, i guess :(
197 2014-10-05 19:53:21 <espringe> There's no public link between that address and their account
198 2014-10-05 19:53:27 <sipa> So?
199 2014-10-05 19:53:30 <espringe> I've yet to receive a complaint
200 2014-10-05 19:53:45 <sipa> ^thatś what worries me, that nobody cares about privacy
201 2014-10-05 19:54:31 <espringe> The convience is extreme though, they can go to blockchain.info  type in their address -- see *all* their deposits and make sure they were all credited
202 2014-10-05 19:54:46 <sipa> it's just gratuiously letting the whole world link different transactions together
203 2014-10-05 19:55:29 <espringe> I've been tempted to use bip44, to allow people to generate a new address after each previous deposit
204 2014-10-05 19:55:39 <espringe> but its a feature no one has requested, so i don't want to make it for no purpose
205 2014-10-05 19:57:05 <espringe> And until bitcoin core supports bip44, it's just a shit load more addresses i need to import in it
206 2014-10-05 20:20:40 <midnightmagic> I am amused that you appear to think that wasn't a complaint.
207 2014-10-05 21:24:27 <brisque> sipa: headers-first is sick :)
208 2014-10-05 22:12:53 <sipa> brisque: ?
209 2014-10-05 22:13:57 <brisque> sipa: delivering praise for headers-first, just got around to messing with it :)
210 2014-10-05 23:13:08 <phantomcircuit> sipa, reusing addresses like that actually appears to be a common solution
211 2014-10-05 23:13:13 <phantomcircuit> iirc bitpay does that also
212 2014-10-05 23:13:23 <phantomcircuit> but with a much larger interval between reuse
213 2014-10-05 23:15:58 <brisque> phantomcircuit: it's interesting, really, that they're doing that.
214 2014-10-05 23:16:26 <brisque> I've noticed that before and couldn't explain it at all
215 2014-10-05 23:16:52 <phantomcircuit> brisque, i would assume that they distribute a fixed set of addesses
216 2014-10-05 23:17:05 <phantomcircuit> but synchronization issues would seem to be an issue there
217 2014-10-05 23:17:16 <phantomcircuit> possibly it's just a database table with address, last_used
218 2014-10-05 23:17:37 <brisque> one of the exchanges does that too but I can't remember which
219 2014-10-05 23:27:11 <sipa> brisque: well, please keep trying to break it :)
220 2014-10-05 23:28:22 <phantomcircuit> brisque, really? which one?
221 2014-10-05 23:28:26 <phantomcircuit> that is mind bogglingly stupid
222 2014-10-05 23:30:33 <brisque> phantomcircuit: I honestly don't remember, just someone mentioned making a deposit to an exchange and finding the address was stale (had a transaction months ago)
223 2014-10-05 23:30:50 <phantomcircuit> jeez
224 2014-10-05 23:31:29 <brisque> nothing would surprise me. what about the dude who sent hundreds of bitcoin to mt gox after it closed?
225 2014-10-05 23:32:24 <phantomcircuit> sigh...
226 2014-10-05 23:33:19 <brisque> that's right, he sent 800 BTC
227 2014-10-05 23:33:57 <brisque> and got it back, too.