My thougths: https://bitcointalk.org/index.php?topic=129970.0

Depends. What if you launched a big ad campaign and suddenly you get a mass of requests? You would not want your webhost to shut your site down because he thinks something is wrong.
Granted, that many requests from a single host would be suspicious, but if the attacker has resources (i.e. botnet) he can spread those requests over many hosts.
If you run your own server, you could lay traps. Like, letting file2ban monitor logs for requests for e.g. the infamous info.php and block that IP.
If you absolutely have to store sensitive information on your webserver (data exchange, backup, etc) at least put it into a Truecrypt container and upload that one instead.

Like Linode?

A simple HEAD request would be enough for a scan. Speed mostly depends on your server: a good hardware and configuration can serve hundreds/thousands of requests per second.
Of course if the scan gets out of control you'll notice because your site will start lagging and your logs will blow up.
Even if you think you locked things down (like setting "Options -Indexes") you can run into problems eith e.g. a buggy script. If you pay attention you'll notice that security issues pop up all the time with the most common CMS, like Wordpress, Typo3, Joomla, Drupal etc. If an attacker finds a bug which makes a script return a directory listing you have lost.

Simple fix? Never store files you want to keep private in a location that is accessible by the webserver. Period.

You will need "nearly infinite bandwidth" anyway since you have to download the entire chain to verify it. 0.5GB consisting of 10MB data blocks means you store 50 blocks; with the right algorithm behind it (for example, look at the way Bittorrent distributes data) it shouldn't be that much of a drama. The choices are to let everybody store everything (recycling my previous example this would mean a replication count of 60,000) or distributed storage (replication count 5000) or a few (how many? 10? 100?) history nodes. Less replication means easier attacks: a combined government operation spanning over a few countries could take down the history nodes. Or just dDoS them.

As for your exploit: that's already common in many p2p networks and they still survive.
Possible solution: a client requesting a data block sends a random string together with the request and the sender has to deliver the block along with a checksum of block+string. The client verifies the checksum after it receives the block and then requests only the checksum from one or two other random nodes. If all checksums match, the seeding client is good. If the seeding client turns out to serve bad data, the requester stops communicating with it completely (or for x days to get around dynamic IPs). Obviously, it'd be better to have smaller data blocks, like 1MB instead of 10MB. Together with timeouts and a minimum bandwith requirement this could sort out the bad apples.

Instead of relying on a few nodes which act as history nodes (what increases the risk of data loss) Bitcoin could move to a distributed and replicated storage method: each node provides some storage and the protocol balances data-blocks across all online nodes to guarantee that each of those blocks is replicated at least n times across the entire network. So when a fresh client joins, it will download the chain, store those ~200MB it needs plus e.g. a flat file of 0.5GB in which those blocks with the lowest replication count get stored. Btw, I mean blocks as in chucks of data, e.g. 10MB blocks, not Bitcoin blocks because by using a fixed size it's easy to swap out blocks.

Let's say there are 60,000 active clients on the network with 0.5GB provided by each client. This would create 30TB of storage. With a blockchain size of 6GB the network could offer a replication count of 5000. If the minimum replication count would be 100, the blockchain could grow to 300GB; assuming the number of clients won't change. The currently required space of ~5GB would offer 300TB in this model (yes, I did round here and there a bit). Of course there still can be the option to work as a full history node which stores all blocks to act as a seeder simply by overriding the 0.5Gb with x GB.

I thought it's a very popular feature used by a lot of people.
Is there a reason why Coderrr or you (I think you released a test version with the coincontrol patch) dropped this?

After a first look there seem to be no major issues.
Will the coin control feature be added to the official client?
I really got used to this very useful option.

Sure. Add a page like "My Account" for those who have entered a Bitcoin address which contains eg:
- paid/unpaid balance
- an option to set the minimum automatic payout (eg 0.001btc)
- "sweep" button (if clicked, the entire balance will be paid)
Since you cannot change the recipient address a password isn't that important. A troll could play around, but never steal any coins. It shouldn't be too complex to add a password field though.
The reason? I wouldn't mind leaving coins in your wallet until a certain amount is reached instead of cluttering up my wallet with lots of incoming mBTC transactions.

Maybe you could add an option to define a minimum payout, or a "pay all with the next batch" button.

I really shouldn't be online when I'm tired

Luckily you quoted his addresses so that it'll be useless if he edits his own posts.

Sure


So we have a bunch of requests (probably more via PM)


All the requests have been denied by stating that Pirate has to pay him only.


An interesting quote I ran across while looking through the thread. Interesting because this breaks the traceability of coins.
Even with his depost address being known, nobody knows how many coins investors sent to BitcoinMax.

Also, from the swift code he's using Banco Espirito Santo S.A. in Portugal:
http://www.swiftbic.com/bic-code.html?swift_search=BESCPTPL

Since the branch code is 0000 it should be the one in Lisbon.

Since payb.tc/E&G has decided to abandon his BitcoinMax thread and doesn't reply to a PM anymore I finally decided to open a thread.

I think most would agree that Pirate won't return any coin to the investors and I'm aware that payb.tc/E&G said that in case of a Pirate default there won't be any more withdrawals.

However, a few (like myself) had requested Bitcoins before the default; requests which have been ignored so far.

In the past, payb.tc/E&G had been quite vocal about the issue, boldly stating that it's only his business to take care of the Pirate issue by denying investors the option to attempt to settle with Pirate.
When it turned out that Pirate has quite an experience as a scammer and that he won't give in to threats on the Internet things got pretty quiet; just like those who threatened/promised to do everything to get the coins back.

If, they will show up at Trendon's door; and this would not be pretty.
I see no reason why a neighbor should be afraid; they have nothing to do with what happened.

To reduce the load on your SSD (or any mechanical drive) you could use a ramdisk for the initial download since there will be tons of I/O.

With the exception of OP's coins and a 15btc tx all others are multiples of 50btc though.
I also looks like each of those 50btc transactions goes through 1CLVnMWEwzuGVcQ6L2WBoUJQFj3B9XeVmx or 1HeyN2fuKPurGPQsSSpt3S2Ruy7zc5rye9 if you just go back long enough.
Maybe it's a mixing pool?

It's a bit strange that someone who successfully stole your wallet would use an already existing address to send the money to, instead of using a brand new one.

From the information on the blockchain, I would create a list of addresses which have sent to that one address in question, or recevied from it.

Then offer a bounty for anybody who owns one of these addresses; they should be able to tell you who they sent their coins to, or from who they received them.

I'm not playing a lot of Poker, but as far as I know a stake can mean a total loss if the player fails (depending on the agreement with the backer); so I'll pick the safe route and offer 5 for 6 as a loan.
However, if you promise a full repayment of the 7.5btc in case of a stake, I'll offer this one too of course.
Since you halfed the requested loan/return, I'll also half the security deposit.
Send 10btc to 1P6C6JEZPCBqbExxeXmCeHQPoLemfuyyWP and let me know where I should send the 5btc to.