|
You don't even need to rescan if you're using a client after 0.3.21.
|
|
|
|
still no answer to my support tickets and no answer in IRC... so what is my recourse besides calling mtgox a bunch of scammers to anyone that will listen?
Try Reddit: http://www.reddit.com/r/mtgox |
|
|
|
The "time to be trusted" is dependent on several factors, namely your internet connectivity, the current global hashrate, and the hash rates of nodes closely connected to you.
The "time to be trusted (as not being spam)" is dependent on the number of confirmations the coins have, and their amounts. |
|
|
|
|
There really isn't much more info. That thread at least covered the basics. Are you looking for something in particular?
|
|
|
|
sent, but they're all still on 0/unconfirmed... hopefully soon some of the first ones will get in a block so people can vouch for me. Don't worry, I saw them on bitcoincharts. |
|
|
|
@"scam" guy: I've checked the site's source, it's one of the cleanest sites I've ever visited.
We're watching this post like a hawk. |
|
|
|
|
Be careful, guys. I suggest requiring ClearCoin.
|
|
|
|
I just wanted to let you know that I went to my twitter and found out how to fix the crap that bitcoinboom.org guy scammed me on.
Go to twitter settings and go to the Applications tab - revoke access from EtsaGo.
Thanks for catching this one.
-Shfinkel
|
|
|
|
Status: Paid
ty
*sigh* Next one I see of these, I'll delete. Op, you've been warned. And yes, everyone in this thread just got scammed. |
|
|
|
|
Unless someone is highly trusted, I suggest an immediate deletion of any thread giving away money in exchange for referrals, etc unless they set up an escrow with a highly trusted user to pay out. These recent Bitcoin7 referral scam threads are getting ridiculous and is highly damaging to the site that's being referred.
Another option is to ban referrals altogether.
|
|
|
|
|
We already have a sticky for this information gathering.
|
|
|
|
|
Dear God, not this again...
@OP: If this is legitimate, PM me with proof that people have been paid.
|
|
|
|
has anyone actually been contacted here after making a request?
Yes, they have. On average, we're whitelisting about 20 people per day, many of which I've contacted personally. |
|
|
|
Are any of the white-list requests being honored?
Yes, they are. In fact, I'm going through the new ones right now. 11 users before your post will be whitelisted. Now, I got to get back to processing these requests... |
|
|
|
|
Please keep discussion of the newbie restrictions to the Newbie restrictions sticky. Yes, we read it.
|
|
|
|
|
Please keep discussion about the newbie restrictions to the Newbie Restrictions sticky, thanks!
|
|
|
|
Dunno how you test it, but the solution is to have a third party merchant who allows a small line of credit to the customer and runs their own (fast) verification network not based on bitcoins. Each transaction will be approved in serial until the wallet hits its limit.
This. As for what that network would do, they would listen for a few seconds for a conflicting transaction. If no conflict is heard, approve the transaction. If a conflict is detected, decline the transaction, at which point the user of the snack machine would have to call the payment processor to get their money back if the original transaction went through. After a few seconds, it is all but impossible to get a conflicting transaction into a block. The only real threat to accepting unconfirmed transactions, at that point, is the Finney Attack - and that can only have one victim per coin. Of course, a Finney Attack can be staged with hundreds of double-spends. Imagine this: you generate a transaction to yourself and submit it to a company that does Finney Attacks. Then, when the block is ready, they text you: "spend NOW!", giving you about 30 seconds or so to do a double-spend before they publish the block. However, it's impossible to do a Finney Attack on your time-table. (good luck using a Finney Attack at the grocery checkout, for example) |
|
|
|
|
Show Posts
