They are obviously just making things up as they go along
Or maybe they were asked to help form the chokepoint. With a list of everyone who has control of hashing capacity (since mining pools and solo miners are the ones who control what transactions go in the blockchain), the next step is to force them to comply with "later guidance", such as KYC on each party submitting a transaction. Like .. no more P2P, if you want a transaction through one of these "licensed" miners, you connect to them directly. And then Bitcoin is toast. Muahahahahaha!!! I'm probably seeing more to it than exists, but this is one possible direction.
|
|
|
Ok - I did exactly as you told me and this is the message I'm getting now:
Hmm ... I doubt your backup is corrupted too. I'm not sure BDB wouldn't open it. Maybe it is seeing the database/log files and trying to recover anyway? The "start from a clean slate" approach is to remove everything from the Bitcoin data directory and then restore just the wallet.dat from the backup.
|
|
|
You might want to inject an "Unofficial" in the title or somewhere to clarify that ICBIT did not author this. Final settlement value is determined on listed the day of settlement for each instrument (currently 14th Apr, 14th Jun and 16th Sep) and is based on the spot price of BTC/USD on that day. Because that could be misinterpreted, each contract type specifies the method that determines the settlement value . For BTC/USD contracts, the final settlement value is the 24 hour volume weighted average price (VWAP) from the largest exchange at the time of the settlement (i.e., 20:00 UTC).
|
|
|
Yes - I did make a backup - and one that is encrypted too. And damned if I know what to do with it.
First, close the Bitcoin-Qt client. Then rename (rather than delete) your current wallet.dat just in case .. or move it elsewhere, but don't overwrite your backups. Then copy the BTCBackupEncrypted.dat and save it as wallet.dat in your Bitcoin data directory. Launch Bitcoin-Qt. Your funds should be there (presuming you've made less than 100 transactions since March 24th). (I'm not sure with v0.8.1, you may need to run Bitcoin-Qt with -rescan if the balances are not accurate.)
|
|
|
I've done a couple full restarts and it still shows in my Bitcoin-Qt client as Unconfirmed and existing. But does not show anywhere else.
Ok, then someone is probably re-connecting to you and re-sending it [edit: Or you are connecting to a peer that is relaying it to you.] You can prevent this by changing your configuration and removing the ability to accept incoming connections.
|
|
|
Can anyone help me please?
Do you have any backup copies of your wallet.dat? Any copy made within the last 100 transactions would have all the private keys necessary to recover all your funds.
|
|
|
I've been trying to send a Moneygram to Okpay but i don't know which website i should use safely and cheapest because the one i saw was like 50 bucks just for 500 bucks. I need some help asap on the cheapest safest exchange site you guys Moneygram to OKPAY through. Thanks.
The factors that matter for a buying decision include: - Where are you located (country)? - How much are you looking to buy? [You mentioned about $500.] - What payment methods do you have available? - How soon do you need access to the proceeds? - Is privacy important? If you are looking to buy bitcoins, then OKPay is just one method. If you instead are looking to get cash to OKPay, you can do that by first buying bitcoins and then cashing out at an exchange that supports OKPay as a payout method. A fairly comprehensive list of options is compiled here: - http://en.bitcoin.it/wiki/Buying_bitcoins
|
|
|
I live right up the street from the White Lime at the corner of Murrieta Hot Springs Road and Margarita Road, so if anyone ever wants to hang out there, hit this thread and I'll probably show up too.
Do they have Wi-Fi? If not, does Spelly's (the only restaurant/bar in Muriette I know off hand) have Wi-Fi?
|
|
|
What's the process to resolve this issue? They probably aren't looking for new threads reporting a problem. Instead, how about reporting your issue in their thread -- that's probably the quickest to resolution: Official BitInstant Support Thread (Active Customer Support) - http://bitcointalk.org/index.php?topic=128314.0
|
|
|
Is your client directly connected to the sender? That may explain why you see it whereas it doesn't broadcast.
I'm wondering if that is starting happen for person-to-person transactions on -OTC. For example, through IRC without cloaking someone would see your IP address, connect to you and send you a bogus valid transaction (but them make it bogus by broadcasting at the same a double spend to the rest of the network). You see the transaction, send your money (e.g., Dwolla or whatever) and then that transaction never confirms. If it definitely doesn't get included in a block you (and the sender) might want to delete the transaction from your wallet with pywallet
If it is an incoming transaction, then simply shutting down and restarting the app will cause it to disappear from the memory pool.
|
|
|
BTC Vault does not include a local copy of blockchain.info (as this side requires a server) but only a link to it.
Ah, I was remembering some method that their HTML page with javascript allowed offline wallet access. I guess the script to decrypt a wallet might work instead to provide offline access to a blockchain.info AES-encrypted wallet. Perhaps that would make a useful addition to a future release? - https://gist.github.com/fcicq/3368495
|
|
|
I don't think the transaction I am referring to is listed there. I had an incoming and outgoing transaction of the same amount (2.44) in that wallet yesterday, but this is a third and separate one. Here is all the info my wallet tells me about this specific transaction:
Status: 0/unconfirmed Date: 4/1/2013 14:22 From: unknown To: 15s17qYWvj9vTJrjKnywGPiduM7NvbhNx7 (own address) Credit: 2.439 BTC Net amount: +2.439 BTC Transaction ID: 2176854c0ed2e2a8e6c2f4aeb429e4548452ba59088cc63ff36634cdeae062a4
It looks as though blockchain doesn't see that transaction ID at all.... Thanks for your help so far!
OK, so this is an incoming transaction to you? If so, the the party that sent it needs to re-broadcast it as your client knows about it but the rest of the network does not. To clear this, simply close your client and re-launch. The memory pool will not have this transaction in it. (The only exception there is if someone was cheating you, that transaction still existing in your memory pool might be evidence and shutting down your client would cause any trace of it to disappear.)
|
|
|
I still have encrypted backups of the old wallet. Can I import these elsewhere to regain access? Well, if you are sure you know the password you can try a script to decrypt it: - https://gist.github.com/fcicq/3368495Additionally, while Blockchain.info might not be re-broadcasting the transaction, if it is valid anyone else with a copy of it can re-broadcast it. I posted a question inquiring if anyone has a copy of it: - http://bitcoin.stackexchange.com/questions/8946
|
|
|
Is the first transaction picked up and the second dropped? or are both dropped? or are the btc lost for ever? Thanks!
The context is important here. Most mining occurs using the Bitcoin-Qt/bitcoind client which will reject any double spend attempts. So it is the first transaction to reach the miner is the one that gets included in a block. So how a "race attack" double spend works is if the attacker knows your IP address and you take incoming connections, the attacker has one node shoot a spend transaction to you. Then at the very same time the attacker has another node shoot another spend transaction to the rest of the network. The attacker's aim is to have you see the transaction (0/unconfirmed), then you hand over the cash or whatever reason the coins were sent, and then only later when the mined block arrives would you realize that the funds were double spent. There are protections against that (don't allow incoming transactions, for outgoing you have an explicit connection to well-connected nodes. Additionally, even if you do accept incoming, you can check the rest of the network (e.g.,blockchain.info being one source) before handing over any value to see if any double spend transactions were broadcast. That's the typical race attack. There's also the Finney attack, the 51% attack, and others. - http://en.bitcoin.it/wiki/Double-spendingWhat is the context in which you are asking?
|
|
|
Problem now is I have no access to the old account and still have no idea why.
Is it possible you were trying to login with the wrong wallet ID? Did you assign an alias to it? If not, did you have an e-mail or SMS assigned to it which might give you the wallet identifier? - https://blockchain.info/wallet/forgot-identifierI log into my new account and the balance is zero... WTF? I thought transfers could not be reversed? Confirmed transactions cannot be reversed. If the transaction was being ignored (or not being relayed) and never made it into a block, eventually the rest of the network will forget about it and the original client will need to re-broadcast it. Blockchain.info is simply saying it no longer broadcasts it. why would blockchain show a full balance for so many days in the new address then revert it? Blockchain.info/wallet includes in your balance any transactions that have not yet confirmed. Is it possible that the transaction from the "lost" wallet itself too had not confirmed? That might happen if the party that sent those funds to you had double spent against you. If you know the bitcoin address(es) in that "lost wallet", check blockchain.info to see if that address(es) till show the funds. If not, then you have a different problem than not being able to login to the "lost" wallet. [Edit: In the worst case scenario, blockchain.info (or someone else) might have an archive of the transactions. If your transaction is valid and just needed to be rebroadcast, anyone can re-broadcast it. If it instead simply didn't get relayed for whatever reason, and nobody has a copy of it, then you're out of luck.]
|
|
|
Let's say I invest $1,000 into BitCoin. That $1,000 turns into $2,000. I then want to take the $1,000 and buy more Bitcoin. Is there any way of doing this without withdrawing, paying fees, waiting, re-investing, paying fees, and waiting?
You are describing the desire to profit from timing the bitcoin market. I take it you believe you can know when to sell, then using the proceeds of that buy back at a later time at a lower value. [Edit: Oops, I missed the last part of your question, which said "in a rising market". My suggestion is assuming you are thinking there's a declining market.] I tried that and am still waiting for $20 to return so I can buy those coins back. Same for more at $40, then $75, etc. However, if you want to put your money where your mouth is, there are methods to use bitcoins to short bitcoins. What you can do is buy BTC/USD PUT options (or write BTC/USD CALL options) on MPEX. Or sell BTC/USD futures contracts on ICBIT.se for example. With ICBIT how that works is you sell a contract (currently above spot price, e.g., $115) and then buy it back at any time before settlement (e.g., June 14th, 2013 for BUU3 contract). The risk is that you buy it back at a higher price, in which you get back less than you paid. If it drops in value, you get back more than you paid. [Edit: If instead you are thinking the market will be rising, then you can buy CALL options or sell PUT options on MPEX. You could also buy BTC/USD futures contracts on ICBIT. You'll be overpaying there, as the price is in contango (above spot).] There will be more methods to short coming -- as Coinsetter.com, Kraken.com and others launch.
|
|
|
I mean that if I want to send 1BTC tomorrow 12pm for someone, but I will have no opportunity to get to my eWallet, than is it possible to schedule the transaction?
This has been asked of EWallet providers but the feature has not been offered by any yet. You could probably contract with an escrow provider at a low fee to do this. The bitcoin protocol has an nLockTime which would presumably allow this however no clients currently support it.
|
|
|
|