I've never used them, but a quick search didn't deliver any scam-related results:

https://cse.google.com/cse?cx=016660200577587308545%3Aesf40ml9aag&ie=UTF-8&q=tradesatoshi.com&sa=Google+search#gsc.tab=0&gsc.q=tradesatoshi.com&gsc.sort=date

Offcourse, it wouldn't be the first exchange that turned scam, ran away or had to default... So there is no guarantee tradesatoshi will ever come back.

How long have they been down?

It had been a long time since i last mined altcoins, but i had 2 spare dedicated boxes laying around and tested ZEC mining. Since we're talking about CPU mining, my servers had these CPU's:
1 x Xeon(R) CPU E3-1245 V2
1 x Xeon(R) CPU Dual L5420

The combined hashrate of 16 cores is around 30 S/s. the E3-1245 gets about 23 S/s, the L5410 around 7 S/s

The only experience i have was a small test i did depositing 0.05BTC to btcjam little over a year ago.

I made (very) small investments into 12 projects.
I allways made sure the borrower had a good rating, i liked the project and the loan wasn't suspicious (suspicious, for example, are people that have repayed 5 BTC in the past, and suddenly try to take a 50 BTC loan).

After a year, i stopped my exeriment with the following statistics:
Net return: -21%
5/12 borrowers defaulted, 1/12 is more than a month late (so in the end, i suppose 50% of the borrowers will have defaulted on their loans).

I've depostited 0.05BTC, and i've withdrawn 0.032792 (using 3 transactions, each transaction requires a fee). Substracting the fee of 0.0003681 I payed when funding my account, i can say:

I have sent 0.05 BTC to btcjam, after a year and after both deposit and withdrawal fees, i have a total return of 0.0324239. So in the end, i've lost both a year of my time and 0.0175761BTC by investing on a p2p lending platform.

That is correct. As long as a transaction is unconfirmed, it only exists in the memory of the nodes. An attacker can actually generate a transaction spending input A with a very low fee, and directly afterwards create a second transaction spending input A but with a much larger fee.
Most miners will include the transaction with the larger fee into a block, voiding the first transaction. Only waiting for at least one confirmation will protect a service against this problem.

Once a transaction is added to a block, it's allmost impossible to doublespend the inputs, but as long as the transaction is unconfirmed, it's pretty easy to do so.

My best guess is that the person who wrote the wiki meanth that once your transaction is confirmed, it's protected against double-spending.

The way i always understood the concept, double spending means only one of many transactions spending the same inputs is included in a block, the other one is cancelled. This is what makes it dangerous. You think you have received funds from somebody, but a completely different transaction spending the same input is included in a block, and your transaction is cancelled, hence, you are no longer payed.

5 BTC is enough to make some effort... I participated in the quoted topic and gave some proof of concept examples in perl on how to tackle this problem (altough, an other member wrote a much better sollution in python), in case you need some extra assistance, you're always free to PM me

0.1 Gh/s will make you about 3 dollarcent a year, while ruining your computer.

Like it has been asked before, it would be a good thing to give us the complete picture to work with

- is your electricity really free
- how much electricity can you use (it's not because it's free that you can use as much as you want... Your landlord might knock down your door, or your house might catch fire if your breakers aren't ok)
- what kind of PC do you have (let's find out if you can mine some CPU minable coins, don't expect to much tough)
- what kind of GPU is inside your PC
- do you have a budget you can spend
- which commandline were you executing when starting the OP?
- what is your technical knowledge?

Can you show us this address? Where did you see it???
Maybe it was just a note on blockchain.info or something, but with the information you gave, i have no way of knowing what happened.

quoted that for you... I'll verify the sig with electrum and edit this post when successfull.

EDIT: can't seem to verify this one, not by using electrum, not by using https://tools.bitcoin.com/verify-message/ not by http://www.coinig.com/?adr=15LxBZ12C8VW5EsDVnRG8cnzJFAEDK9EQD&msg=This+is+Crwth+from+Bitcointalk.org+today+is+November+7%2C+2016%0D%0A%0D%0AThis+is+my+address.+%0D%0A%0D%0A15LxBZ12C8VW5EsDVnRG8cnzJFAEDK9EQD%0D%0A%0D%0APlease+be+advised.+Thank+you.&sig=H8dekP3Hc6SsvT8P3dnEmCt%2Fiu2rYoTgKlWq2F5k%2BVIBKUBU5NAt%2BIFp%2FLoS59JP6%2FGbLzf2ED3i9aIMOf%2BJVrE%3D

Maybe it's because of the many linebreaks... Maybe you can try a simpler message?

It's not hard to write your own faucet from scratch, using json-rpc and running your own node.
I made a proof of concept which you can use to study how to do this, you can use the code as a basis if you wish:
https://github.com/mocacinno/simple_testnet_faucet

yes, i have the exact same problem here (Western europe)... So my guess it's a server side problem (altough it's only an educated guess)

Since i had a couple of hours today, i quickly made a proof of concept testnet faucet:
https://github.com/mocacinno/simple_testnet_faucet

It's a PROOF OF CONCEPT TESTNET FAUCET, DO NOT RUN IT ON THE MAIN NET!!!!! It will work, but your funds will be drained in mere days
I did nothing, repeat nothing, to avoid abuse of this system, nor did i check for security vulnerabiltys...

If you want to use this faucet as a mainnet faucet, you'll have to extend/fix/patch this code and at least:
- check for possible vulnerabilitys
- add ref system (add a table, insert each address as a user, keep track of the referring user, when running cronjob.php insert record in the faucet table to pay out refferer)
- kick bots
- kick proxy's
- kick VPN's
- kick tor
- create blacklist
- create admin page
- add extra checks: 1 claim per ip, 1 claim per address,...
- add captcha
- make a nice gui
- add an installation script
- add bitcoin.conf sample
- implement session
- implement ad management
- test the hell out of it
- ...

I'd probably just install bitcoin core, and run a daemon in testnet mode... Then i would create a php/mysql script to use json-rpc in order to generate transactions when a claim was made. Especially when talking about testnet, it's all pretty basic stuff. Just a form an a captcha. When info is posted, enter the ip and timestamp into the db and check if a claim can be made. If true, either make a json-rpc call, or store the info into a db and run a cronjob to query the db and make the transaction on an hourly/daily basis)

You could probably use an open source script like this one to do the same thing:
https://github.com/tuaris/FaucetRPC

(disclaimer: just found this script by searching github, i have no idear if this one is secure).

EDIT: if it's 100% sure testnet only, i'd be willing to invest a couple of hours in order to write something up whenever i have some time (might take a couple of weeks tough)

Please, read this tagged post, written by a trusted member and adjust your OP accordingly:

https://bitcointalk.org/index.php?topic=577765.0

Next to this, 0.01 is allmost 7 bucks nowadays (this is not a little number, considering there are a couple dozen accounts created each and every week with the sole purpose of asking for no-collateral loans), and taking loans for the sole purpose of building trust is heavily frowned upon by the community.

If you're 100% sure your strategy works, go to a bank, take a mortgage of $100.000 on your house.
1,5% compounded daily will make 22.575.604 in one year. Banks in my country have a yearly intrest rate of about 3% at the moment, so you'll need to pay back ~103k-105k, and keep more than 22 million.

I can honestly say i don't really trust people that say they have a money making idear, but instead of using it themselfs, they publish it in an ebook... Always smells fishy to me.

This one was easy
Thanks for the AIR

Can't answer you this either. There is no predefined timeframe for a node to forget about a transaction (altough i think there might be a default of 3 days. EDIT: https://github.com/gavinandresen/bitcoin-git/blob/master/src/main.h#L68), when the node restarts, the unconfirmed transactions will be gone from its memory. The node's owner can also set the maximum memory for the mempool, so i guess a transaction will also be forgotten when the node's memory is full.

Can't answer the question about the rebroadcasting either, not because there is no answer, but because i'm not familiar with multibit classic 0.5.19. For example, bitcoin core keeps rebroadcasting the transaction unless you keep your client off, abandon the transactor or zap your wallet. On the other hand, electrum for example, only broadcasts a transaction once (iirc)

If nobody can help you here (in this topic), you can ask this specific question (wether or not multibit classic 0.5.19 keeps rebroadcasting) in this subforum: https://bitcointalk.org/index.php?board=99.0

Not really, those numbers are averages... With a 20 satoshi per byte fee, you'll need to wait 30 to 1080 minutes on average (at this moment)... The miners are completely free to include transactions in their block, they do not have to include the oldest transactions first or something.

It's possible to add 20 satoshi's per byte and get added to the very next block 5 minutes later (on average roughly 10 minutes between blocks)... It's also possible you'll have to wait forever, and see your transaction dropped.

That is correct, and the second transaction uses the output of this transaction as an input... So it cannot be confirmed if the first one isn't...

The second one is 225 bytes and has a fee of 10.000 satoshi's, that's 44 satoshi's per byte... Even this fee is rather "problematic", but it's better than the first one.

This one:
https://blockchain.info/tx-index/94fc3abe8d3f1df56925d19dc006540f424e45e2188c99fddba78397c0772566

uses an unconfirmed input... So it cannot be confirmed before the input is confirmed i'm afraid...

Actually, after further investigation:
the output of 82f2af56de26a74b171d0af12ea3f84345f23214163df2818fc2b26beee7de2e is used as input for 94fc3abe8d3f1df56925d19dc006540f424e45e2188c99fddba78397c0772566

So, there's a problem with 82f2af56de26a74b171d0af12ea3f84345f23214163df2818fc2b26beee7de2e
This tx is 518 bytes and has a fee of 0.0001 BTC = 10.000 satoshi's... This is less than 20 satoshi's per byte, and is not enough

https://bitcoinfees.21.co/ recommands a fee of 80 satoshi's per byte at this moment... A 20 satoshi per byte fee currently has an AVERAGE waiting time of 30-1080 minutes.

About your second question: there are options to "fix" this problem:
1) wait untill the transaction is "forgotten" by the nodes, make sure multibit doesn't re-broadcast the transaction (don't know if classic does this or not, you might have to inquire in the correct subforum)
2) double-spend the inputs of the first transaction, completely re-create the second one (i don't think multibit can do this by default, so it might be rather challenging to export the private keys needed to create a transaction doublespending the inputs)
3) CPFP or RBF might also work