Notice: If you want a payment to go through in less than several hours, increase your Bitcoin client's optional/voluntary fee to something higher than 0.0001/kB for all transactions. Priority is given to higher fee transactions. Some transactions sending large amounts of Bitcoin may qualify to be free, but you should add this additional fee in your Bitcoin's options, so that no transactions are sent without fee. The default additional fee is 0, which still allows some non-fee transactions to be created. The Bitcoin network is very busy right now. There are several transactions a second being sent, and currently 6000 and 5MB of transactions are waiting for inclusion in the blockchain. Inclusion is what makes payments confirmed and trustable. If there were NO more transactions sent, clearing this backlog would take over an hour of maximum-size blocks. Just the web page attempting to list unconfirmed transactions is about 2MB, and will make your browser crawl: https://blockchain.info/unconfirmed-transactionsAlso note: If you have already sent a payment with Bitcoin-Qt, the best thing to do is wait. Other wallets may make "bad" transactions, with less than the mandated minimum fee that will never confirm, but Bitcoin-Qt transactions will always confirm given time. The first-post instructions for removing a transaction and re-sending a new one with fees apply only if the original transaction was created with a "bad" client, or if it was sent while attempting to bypass Bitcoin fee rules. Removing a transaction record from your client and re-sending another transaction will likely do you little good. The network won't soon "forget" your original transaction if it is properly constructed, will recognize a new transaction as attempting to double-spend the same money, and will discard the new transaction anyway.
|
|
|
|
Not hacked. This transaction is not showing in the blockchain at all The blockchain is where confirmed Bitcoin transactions are permanently stored. blockchain.info is a site that tries to display information about both the blockchain and transactions that have been transmitted and are waiting for inclusion. The first transaction didn't have an optional fee included. Due to the limited number of free transactions that miners will include in a block, it may have to wait quite a while. A second transaction sending all of your money may need to wait for the first transaction to confirm. It likely is funded by "change" back to your wallet that is in the first transaction. There are currently 5MB of unconfirmed transactions waiting to be included in 0.5MB blocks, which happen every 10 minutes, and most of these include fees and are given priority over non-paying ones. |
|
|
|
Hi all,
Yesterday at 1:49pm GMT, I sent 1BTC to localbitcoins. Sadly, I accidentally sent without a transaction fee. As such, it kept getting pushed further and further back in the queue.
Anyway, I read about pywallet, so I followed the guide to clear the transaction from my wallet, and then performed a rescan. Of course, I got the BTC back in my wallet and sent again with the tx fee.
This time, however, blockchain says :
Warning! this transaction is a double spend of XXXXXXXX. You should be extremely careful when trusting any transactions to/from this sender.
Estimated Confirmation Time Possibly Never (queue position 86)
(and the other one is queue position 4860)
Does anyone know how long this situation will take to resolve itself? It's a weird one.
Thanks
The blockchain.info client captures transaction info even when other Bitcoin clients might ignore it. If you create a junk transaction that nobody will relay, they'll still show it if it gets to them and put a 'double spend' alert even on the one that is valid. However, your issue is that your 1 BTC transaction qualified to be free if you sent it with Bitcoin-Qt and you were not prompted for a fee (1 BTC can be free after less than a day sitting in your wallet). As such, the first is a legitimate transaction, and other Bitcoin clients and miners won't store another new transaction with a double-spend of its funds. You'll have to wait for the first to go through. The optional fee in Bitcoin-Qt should be set to 0.0001 per/KB instead of 0, so all transactions have the minimum fee, if you don't want miners pushing back free ones for more profitable transactions. |
|
|
|
If You Use A Blockchain.info Wallet Wait.
It will stop being broadcasted in 30 hours. I learned that the hard way.
If You Use A Blockchain.info Wallet Don't.
It uses a non-standard Bitcoin that doesn't calculate correct minimum fees or minimum transactions amounts required by Bitcoin.
Many learned that the hard way. As a TL;DR to my long post above: after removing a never-confirming transaction from your wallet to restore your balance, simply spend your whole wallet balance back to a new wallet address to be sure the old transaction is invalidated on the network. |
|
|
|
let me check again and look at my bat file edit sierrachartfeed.exe --volume-precision 4 -l 1000 -s * also the base files are the files ziped that you offer for download The scid files I shared are default precision 2, they are incompatible with a different precision setting if you are charting volume. Do you know why you are changing that option? |
|
|
|
Block Date Shares Payout Share Val.
269695 11/15/13 06:09 AM 237472651 19.31342465 0.000000081
269648 11/14/13 11:02 PM 1494880017 45.70631176 0.000000031
269333 11/13/13 03:49 AM 2147483647 65.60088711 0.000000031
268847 11/10/13 02:38 PM 457268162 24.33921501 0.000000053
268756 11/10/13 01:46 AM 1479433909 47.78782646 0.000000032
268486 11/08/13 03:32 AM 964254129 24.7370004 0.000000026
268293 11/06/13 07:33 PM 2147483647 53.39340188 0.000000025 Average number of shares per block has been 1275M, […] The number of shares per block above cannot be accurate because it's clear now that currently the pool's web interface cannot account for more than 2147483647 shares per block: Maybe it's time to use an unsigned int (or a long) to count submitted shares per block…  I see what you are saying, there seems to be a maximum of exactly 2147483647 (2^31) shares hit for several long rounds with obviously more shares than that. Hopefully this is not also happening in the accounting backend. |
|
|
|
I whipped up this console python code to watch the fun on exchanges, it gets data from bitcoincharts market API JSON, and then bitcoincharts socket stream, to keep up to date on exchange prices for all exchanges. No fancy display, just a dump to console of select currencies across exchanges every time a price changes, displaying only exchanges with trades in the last two hours (currency list and how old is too old are command line options). http://we.lovebitco.in/btcmon.py (python 2.7 source)
btceUSD price change: -0.37200000 =======
anxhkUSD : 824.99200000
bitkonanUSD : 800.00000000
bitstampUSD : 647.00000000
btceUSD : 654.63000000
crytrUSD : 600.00000000
justUSD : 750.00000000
localbtcUSD : 732.43000000
mtgoxUSD : 763.01000000
btcnCNY : 5665.00000000
mtgoxCNY : 4838.30029000
btceUSD price change: +0.37300000 =======
anxhkUSD : 824.99200000
bitkonanUSD : 800.00000000
bitstampUSD : 647.00000000
btceUSD : 655.00300000
crytrUSD : 600.00000000
justUSD : 750.00000000
localbtcUSD : 732.43000000
mtgoxUSD : 763.01000000
btcnCNY : 5665.00000000
mtgoxCNY : 4838.30029000
..
Command line options -c, --currency, default=USD,CNY Currencies to watch, comma separated, no spaces. -a --age, default=7200 Hide tickers with no trades for xx seconds. Don't restart it more than once every 15 minutes per http://bitcoincharts.com/about/markets-api/ policy. (I'll make an exe after I make display less "dumpy") bitcoincharts socket interface code is (from)/(as documented only in) sierrachartfeed. Maybe this will turn into a gui charting app, but not likely. Maybe I'll make it more useful as a library, but not likely. |
|
|
|
Consider the "silk road takedown". DPR can do anything he wants so long as he is increasing his bitcoin hoard on USA ground, he even allegedly hires a hitman, the government doesn't stop it even though they are on the Silk Road server and can see everything happening.
When do they step in? When he orders forged travel documents that might jeopardize their ability to seize the 170K bitcoins by being outside their jurisdiction. Someone more cynical might have some questions about that.
When do they step in? When they can grab his laptop while he is logged in using a public wifi. After they have created some evidence of him "hiring a hitman" so they can say "look, a criminal" instead of "look, ebay without draconian rules". |
|
|
|
download in Windows from github, put on separate USB, then boot via Ubuntu USB, leave Internet unconnected, verify the file hash on the ubuntu machine, then run the bitaddress file from separate USB
So I did a bit of googling/youtubing and know how I can check the md5 hash and sha1 hash of a file. Only problem is, I don't see any hash in the readme file or anywhere else. Where is the hash found? And what file should I be hashing? The bitaddress.org.html file? The zip file? Obviously incomplete advice, you also need to verify the signature of the file containing hashes. The URL is redirected when loading off bitaddress.org to include a release and SHA1: https://www.bitaddress.org/bitaddress.org-v2.6.2-SHA1-4d98755d7e78caa4361228a2b11b0faa0f65e6de.html"release notes" is signed by "ninja" using PGP, and contains a SHA-1 hash of each "release": https://www.bitaddress.org/pgpsignedmsg.txtHowever, the private key for ninja is also only found on the web page, I don't see an MIT link, etc: https://www.bitaddress.org/ninja_bitaddress.org.txtThis means that all content on the website could be diligently replaced by a hacker with no means of detection. When you download from github to your drive and then load the file in your browser: https://raw.github.com/pointbiz/bitaddress.org/master/bitaddress.org.htmland then verify the signature and hash provided on bitaddress.org, at least then both sites have to agree on the same SHA1 hash. You can also see when the bitaddress.org.html was last modified, and review the commits to see what changed, such as the last one five days ago: https://github.com/pointbiz/bitaddress.org/commit/ef1d9614f1c9f11598a603e965f0cbaa7d2f3314Another question: in bitaddress, under paper wallet, I should be able to bash my keyboard to generate a sufficiently random key pair, right? I.e., I don't have to roll a die a hundred times or whatever.
You didn't see the instructions "move your mouse around to generate some extra randomness" when you loaded the page? |
|
|
|
|
What a waste of time. Talking heads reading storybook time testimony for congressmen, because senators are apparently illiterate(?). Just submit your pre-composed "speech".
(PS: Mozilla, why is pre-composed a misspelling, but "pee-composed" is your suggestion??)
(PS: Secret service: obsolete when currency can't be counterfeited.)
(Sen. Tom Carper now telling a story about seeing the movie "Dillinger" as informing him about financial crime. "We figured out how to deal with that" - he thinks the US government is a movie character?)
|
|
|
|
The difficulty of mining has quadrupled in less than two months, you're going to make far less:  Along with the earnings reduction expected from high difficulty, pool mining during the current difficulty has also been affected by bad luck. As the pool has a smaller percentage of mining vs the big ASIC farms, variability is increased. This is the nature of any pool that doesn't have PPS (with the pool owner taking all the risk), there's going to be periods with either more or less block finds than expected. Block Date Shares Payout Share Val.
269695 11/15/13 06:09 AM 237472651 19.31342465 0.000000081
269648 11/14/13 11:02 PM 1494880017 45.70631176 0.000000031
269333 11/13/13 03:49 AM 2147483647 65.60088711 0.000000031
268847 11/10/13 02:38 PM 457268162 24.33921501 0.000000053
268756 11/10/13 01:46 AM 1479433909 47.78782646 0.000000032
268486 11/08/13 03:32 AM 964254129 24.7370004 0.000000026
268293 11/06/13 07:33 PM 2147483647 53.39340188 0.000000025 Average number of shares per block has been 1275M, whereas expected is ~difficulty of 511M. However, the DGM payment system has actually mitigated variance and luck risks, spreading miner earnings across multiple rounds, for an average per-block payout of 40.1BTC instead of 25. You must keep separate your evaluations of miner earnings, which fluctuate due to the "lottery" nature of mining and accumulate far after you've submitted shares due to DGM delay, with issues withdrawing funds, which should happen automatically shortly after your earning threshold has been reached. |
|
|
|
So that means addresses in a wallet is very easy to be associated. Then not-reusing address is not enough, and we have to generate a new wallet for each transaction?
Even if people all generate new address for each transaction, since the addresses in one wallet is easy to be found associated, their addresses are still can be classified into one big 'address family'. So there may be no 'well known address', but 'well know address family'. Did I make any mistake here? If this is true, why the trouble?
No, if you use each Address only once, it will be completely empty after you send BTC from that address the first time and will never be used for any transaction again. There would be no difference in creating a new Wallet. The client takes care that Change addresses are only used once, the only thing you have to do is to use addresses for reviving transactions only once. If you only revive at B one time, there never will be a B-2 Change. Unless what you send exactly equals to what you received before, otherwise there's a change and the change needs to be sent to a change address in the same transaction. So if you see a transaction S -> A and S -> S2, you know it's highly likely S and S2 belongs to the same wallet. As a result, your address S is associated with the change address S2, but not so closely because you can still claim (arguably weakly) that you are sending to two different people simultaneously and happens to used up all the unspent amount of S. Then let's say you have change address A, and change Address B, they all have 0.5 BTC and you want to send to user U 1 BTC, then this time you will see A -> U 0.5 and B -> U 0.5. This makes a strong association between A and B and every one knows A and B belongs to the same wallet. Therefore, it is easy to associate the addresses in the same wallet by analysing the block chain. If you don't reuse the address S. It will never have an unspent output after this transaction again. If you use every address only once. S will receive exactly 1 Transaction and never again a second one. Therefore there will never be more than one change address for ever address. And it's impossible to tell which address is the change address and which one is the reviving address. Changing Wallets here makes absolutely 0 difference. That was the point. What you are missing here is that a wallet may contain many unspent txouts from receiving many payments from different sources before there is any need to purchase something with the wallet. Lets say I sell alpaca socks out of a truck down by the river. I would be receiving many 0.10 BTC payments from different individuals to different addresses, suppose for a total of 20 .1 BTC payments in my wallet. Now, I donate 0.95 BTC to a known-address donation site and say to everybody "hey, I just donated!". There will be a 0.05 change back to my wallet, that is now considered "tainted" - based on my declaration of donation, or the site owner saying "thanks for donating, deepceleron", it has become simple to figure out my donation AND determine which is the change back to me that is still in my wallet. So I've got 1.00 BTC of sock-selling money that 10 sock buyers know the address of, and 0.05 that anybody interested can know about. I then send the entire contents of my wallet to a man-boy snowden tibet love honey pot that is supposed to be anonymous, but is monitored or busted by a government. Even with this site using one-time addresses, the previous use of a reused address has compromised my identity and made my payment have little plausible deniability, due to my control of the change. The "change" could have been a multi-send to a third party, and the third party may have made the illicit payment, but LE will not care to investigate so much when they need doors to kick in. |
|
|
|
How can they know that transaction belongs to B? Whatever made {B} interesting to them in the first place. Perhaps he was involved in an unusually high value transaction. Perhaps {B} paid to a "Free tibet" honeypot or well known (reused) donation address and the attacker is the chinese government and now they want to identify B to send him to a reeducation camp. and never worry about their identity is disclosed People never worry about a lot of things, including some things they really should and some things they'll later greatly regret not worrying about. But B never reuses address, so whatever interests others is not the same address used to transact with A. B use address 1 to donate to 'Free Tibet' or whatever, and B use address 2 to send to 'well known' A. Why do you know address 1 and address 2 both belong to B? Address 1 may have separate fund sources in the same wallet as Address 2. If payments from B are to known reused addresses, the change is easily identifiable as still under the control of the wallet owner. When B-1-Change is combined with B-2-Change in a third transaction, those payments are associated and the transaction also identifiable as made by the wallet owner. |
|
|
|
Discussion of off-line secure computing, paper wallets, backups etc are beyond the scope of this post. I am aware of what steps to take. I also give these steps a lot of attention.
-----
I would like to create a bitcoin address using dice. I don't want to trust software and/or hardware RNG. I don't want to memorize anything. Therefore, I don't think Diceware is appropriate. I also want to prove to myself that my manual RNG is good. I also want to minimize potential issues with the human factor (me). I want to keep things simple.
Should I roll the equivalent of 256 bits of entropy with a standard dice (# of rolls?), and sha256 hash it for the secret exponent? What is a secure method for generating the bitcoin address from there?
I would then import the private key into Bitcoin-QT for spending (out of scope).
1. Is this a good approach?
2. If I append "1", "2", "3" etc to the original series of rolls (seed).. does this constitute a "secure" method for generating a series of addresses?
Where were you yesterday? https://bitcointalk.org/index.php?topic=297077
I coded some python to turn any-sided dice into a full-strength private key, no hashes. The answer is it takes a LOT of dice rolling, less than 100 d6's is not a full-strength key....
|
|
|
|
Could you provide a concrete example to explain why reusing addresses by A will affect B if B always carefully choosing address. and how both A and B never reusing addresses prevent it? I'm still not so clear about it.
Since the drawbacks are very apparent, IMHO you need a very clear explanation about the benefit and why the benefit is far more important than the drawbacks.
http://blockexplorer.com/address/1Lukejrwhew7sj4TvWCKksaVo7aLpedHDtFollow the coins back ~12 hops to where they were generated, then follow forward where they were sent to "A". Easy to identify the recipient and owner. Backwards, not so much. Now if B's next payment with the change from that transaction is to "free Tibet", buy "recreational substances", or pay a hitman to whack a business partner, association with the transaction A may reveal identity. When A is shared and reused, as in "this is the donation address for Eligius", any separate-channel information about someone making a donation to Eligius can be used with this known address to reveal a path to their money. |
|
|
|
Man i think many ppl here dont like win 8 , but they dindt ever test this OS. I am telling you: Instal win 8, test it for a little and then tell what you think
I did, I attempted to tolerate it for two months. Infuriating in every way possible. |
|
|
|
 Track UserThese pages are only available to those in membergroups granted the permission to Moderate forum members. Activity - Here, you can view the Most recent IP address used by the member, along with the IPs used in messages, IPs used in error messages, and members possibly in the same range. Below that are any error messages caused by that member. IP Address - Here, you can track the member's current IP address (or type in a different one) and do things such as view Whois records and view other members from the same IP/range. Also you can view messages posted at the IP/range entered and view errors caused by members from that IP/range as well. |
|
|
|
edit: I just found that the QR code of the private keys works. strange It would be good to know what the problem is. Did the QR code decode to a different private key than was printed? If so, we would want to provide feedback to the maintainer of the bitcaddress code so it doesn't happen again. |
|
|
|
|
Probably one of the berkeley db files is messed up, a likely culprit is ~/.bitcoin/peers.dat. Delete it and the .lock file, and restart.
If that doesn't do it, you should make a backup of your wallet.dat, and start with the -salvagewallet option.
You may also need to rename (instead of delete) the "database" subdirectory which also contains berkeleydb logs.
That's of course if you've checked disk space with df, done an fsck, etc.
Also, you should be using the latest client, v0.8.5, if you got that "uses qt version" from the about qt, its probably an old version.
|
|
|
|
|
Show Posts
