Nobody announces they WILL be buying $1M (future tense). Case in point we have multiple clients who have bought over $1M to date. No advance notice, off-exchange, no slippage, secured over the course of weeks. Patient and silent, locking in a solid entry point and the market is no more the wiser.
|
|
|
In the prior x period of time (MtGox weighted average on homepage is 24 hour) take the sum of the USD traded and the sum of the BTC trade.
(total USD traded in prior 24 hours) ---------------------------------- = 24 hour volume weighted average price (VWAP) (total BTC traded in prior 24 hours)
|
|
|
Not anymore now its better to be the seller and not sell anything. All the seller had to do was say "Yes I have given him the items" no wallet ID no nothing. Basically I am hoping to help any other idiot such as myself that believes what is said in these forums to be the concrete truth, because I can tell you it's not. Doesn't work if the buyer claims he never made the purchase, or it is a genuinely hacked/stolen PayPal account, or it was funded by a stolen credit card, etc. Plenty of ways for a dishonest buyer to pull a scam. You didn't know what you were doing and like talking to the cops without a lawyer just backed yourself into a corner.
|
|
|
You should change your title to "PayPal not reversible for honest people".
A scammer would simply dispute the tx as "unauthorized" claim they never made it and have no idea how it showed up on his/her account. The scammer would have the funds back by now. Being honest you just screwed yourself.
This shows why you shouldn't use PayPal (as either buyer or seller) unless you trust the counterparty. A scammer is going to know every trick and trap and the honest joe is just going to get robbed.
|
|
|
Couldn't you just look at the last four digits of the address?* If the address is valid (and all websites should check and prevent entering invalid addresses) and the checksum is the same then the odds of a typo producing a valid address with the same checksum is about one in four billion.
*Technically you can just look at any four digits for the same effect but it seems that is a more confusing concept to users.
|
|
|
I'm not saying we should have NO TX FEE at all. But at the very fucking a least a tx fee proportionate to the input value of the transaction!
The cost in storage, bandwith, and CPU is relative to the number of inputs and outputs not the value of the tx. A fee based as a % of value would provide no DOS protection.
|
|
|
Transactions exist outside blocks. When you submit a tx to the network it means you submit it to your peers who submit it to their peers who .... every peer on the network is aware of the tx. All peers have a pool of unconfirmed tx which is called the memory pool. Miners choose which tx (if any) to take from the memory pool and put in the next block. When a block is solved it is relayed peer to peer and each peer removes from the memory pool all the tx which are in the block.
So at all times all peers have a) the blockchain = permanent record of all confirmed transactions b) the memory pool = collection of unconfirmed tx the peer is aware of
|
|
|
LOL! It was an ACH.
Ok that makes more sense, I do not think you can fraud a wire transfer because its a push not a pull, but ACH you can. HOWEVER there is a simple procedure: They should run the ACH, and keep the money in suspense for a week. The signatory of a personal (but not business) bank account can dispute an ACH transaction as fraudulent up to 60 days from the statement in which the fraudulent transaction was reported. Keeping funds a week would do little good against "friendly fraud".
|
|
|
To 51% the litecoin network would cost about $1,000 per hour, or $4,000 to meet the requirements of your bounty. One would have to be bad at math to accept that "deal". Make it $20,000 and you might find some takers.
|
|
|
You are only prompted to enter passphrase when trying to do something considered sensitive like send coins or sign a message.
The wallet file contains a public portion (addresses & prior tx history) and a private portion of the wallet file contains the private keys and it is encrypted using AES with a 256 bit key created by hashing the passphrase roughly 10,000 or more times using SHA-256.
|
|
|
0.5 * min? Wouldn't that force the fee lower and lower until it reached zero.
i.e. avg min fee is 0.001. 0.001 * 0.5 = 0.0005. So only fees below 0.0005 are valid?
|
|
|
I hope there is some way to recoup what I have lost; in any way. No. Future actions don't change the past. The money you lost is gone. Even if you were able to mine (or work, or trade) and generate a profit you would have been able to do that even if you didn't lose the money you lost. It is called gambling for a reason. I have no choice since I lost nearly all of my money I had saved up. Of course you have a choice, you have a choice to not beg.
|
|
|
Pools/miners are free to include the tx they wish to include. IIRC some pools consider a fee below min threshold to be no different than a free tx. Probably not worth savings that half penny worth of fee. I would go with 0.0005 or nothing.
As for the time between blocks even when hashrate is constant the time between blocks will vary. The average is 10 minutes but an hour long interval between blocks isn't that uncommon. Even a two hour interval between blocks is common enough to be seen about once a year or so. Now longer than a two hour interval is pretty rate. Unless difficulty is off significantly it shouldn't happen very often.
|
|
|
If bitcoind is taking that long to respond it likely doesn't have sufficient resources however making adhoc requests against bitcoind directly isn't going to scale.
Instead have a background process on your webserver make a list transactions call against bitcoind say once every 15 seconds. Now store the results in a db on the webserver locally. On each update you will need to perform some logic to compare the tx set in the database against the tx returned by bitcoind, find the new tx and update the database.
To respond to user queries the webserver would only poll the local database not bitcoind.
|
|
|
wait? version 0.4 wasn't that released in like 2011? Have you considered upgrading?
Make a backup of your wallet.dat file, leave a copy in the data dir. Download and install v0.80 Launch client. v0.80 uses a new version of the database for storing blockchain but it should be able to build it from the older version (without needing to redownload) it may take up to an hour to build a new copy though.
Once new blockchain is built and synced to current block you should have full access to your funds.
|
|
|
Same here. My first transaction completed. I bought some more BTC today and was informed that my coins would hit the account on 03/20/13. Good to know the delay is not entirely Coinbase's fault. But how is it that PayPal doesn't put a waiting period on my purchases?
If you commit fraud PayPal will simply reverse the funds from the sucker you paid. PayPal doesn't lose a penny from your fraud, the sellers using the service do. With Bitcoin that isn't possible. PayPal couldn't offer "instant purchases" unless sellers would subsidizing that cost.
|
|
|
Questions to DeathAndTaxes: If you broadcast a double spend, and 2 txs are added into memory pool, how could system tell there is a double spend and deny one of them? And what is the strategy used here? Randomly select one of them to deny? I think this must be done before the next block generated The memory pool is not consistent across nodes. If A & B are a pair of tx which both use the same unspent outputs as inputs, in a 0-confirm double spend some nodes see tx A first and will drop tx B as a double spend. Some nodes see tx B first and drop tx A. The network will be out of consensus. Some nodes believe tx A is valid and some believe tx B is valid. Eventually a miner will solve a block which contains either A OR B (but never both as that would be an invalid block). At that point both A & B are both removed from the memory pool. To think of it on a higher/meta level the purpose of mining is to force the network to agree upon a consensus view of the current ownership of coins (unspent outputs).
|
|
|
Even if the miner doesn't cheat S isn't evenly distributed. Far easier to just just the least significant 8 digits of the block hash.
|
|
|
|