text:
Confirmations on sent/receive transactions, still have 0 balance
I've tried to transfer Bitcoins from one address to another address, both of which I own. I bought a new computer, so I downloaded the Bitcoin client for OS X, and transfered from the old computer to the new computer. This was before I realized I could simply copy over my wallet.dat file.
This was also before I had a good idea of how Bitcoin actually worked. Just a few minutes after I hit send on the transfer, I shut down the old computer and put it away.
I sort of forgot about the whole thing until yesterday evening. I tried to check in on my balance and found it at 0.
However, after about an hour, I see that there are transactions in my Bitcoin client for the Bitcoins sent, and the Bitcoins received.
The received address is mine, there is a credit for the amount of Bitcoins I sent, and there are 20k+ confirmations for that transaction. The weird part is that transaction is dated 6/15/2011. The sent from transaction address is also mine, there is a debit of the correct amount, there are 68 confirmations, and the transaction is dated 8/6/2011.
The problem is that the balance is still 0.00.
Is there something I can do to make sure I still have these Bitcoins? Is it a matter of waiting until there are more confirmations? Have a made a horrible mistake?

Forgot to mention, I'm on OS X Lion, and I'm using the 0.4.0-beta version of the Bitcoin client.

Those confirmations you see are in the old computer or in the new computer?

I'm seeing them on the new computer. The field 'Your Bitcoin Address:' and the single transaction I have in the 'Received' section have matching addresses. The address in the 'Received' section is labeled: 'Received with:'.

And what is the destination address of the sent transaction? Have you ever sent any bitcoins from that computer? It looks like you received bitcoins in your wallet in June and someone transferred them to another address in August. Looking up the addresses in blockexplorer might help.

Can you clarify whether you see the transactions in blockexplorer or not.

It is possible if the client crashed it didn't finish processing the block containing your transaction (due to bad timing) and now that it is past that block doesn't go back to "double check".
https://en.bitcoin.it/wiki/Running_Bitcoin
There is a command line argument -rescan which forces the client to recheck every block for transactions related to the current wallet. In windows it would be done from Command prompt "bitcoin -rescan".  I assume OS X has some sort of commandline option.
Alternatively you can stop the client.  Make a backup of your wallet.dat.  Delete all the files from bitcoin configuration folder other than wallet.dat file.  Restart the client.  It should show 0 blocks and not have the "bad transaction".  The client will download the blockchain. This could take an hour or more.  Once block chain is fully downloaded the transaction should appear and balance updated.

I gave both of those suggestions a try, but unfortunately neither of them seemed to work.
I'm now at 122 confirmations for the send on 8/6, and 20292 confirmations for the receive on 6/15.

@Brian, Did you manage to get your coins?


text:
How to perform a double spend attack in websites that accept transactions with 0 confirmations?
To perform a Finney attack or a 51% attack I need to have lots of computational power, but in this case (a website that accepts transactions with 0 confirmations) it seems to me that I only need to issue two transactions almost simultaneously. Depending on what the miner chooses to include in the next block, I might get lucky.
Is it that easy or am I forgetting something?

If you are attempting a 0-confirm double spend then which transactions (if any) are included in the next block is irrelevant.  Your goal is to simply complete both transaction prior to either merchant getting notification of the other one.
The "problem" is that the network is fairly quick at passing transactions from one node to the next.  Unless you have located an inefficiency in the network, a bottleneck, or actively degrading network performnce is unlikely you will complete both transactions before the merchant sees both halves of the double spend.
An effective countermeasure would be for the merchant to introduce a short delay between the time they detect your 0-confirm transaction and when they give you access to the purchased item or service.   Say you execute a perfectly timed double spend.  The merchant sees their transaction and waits 60 seconds.  60 seconds is a long time for transactions to not propagate the network.  If at any point in that 60 seconds the merchant sees the "other" transaction you have failed.   Unlike other forms of fraud you will lose the funds as your double spend is irrevocable.  It will just be luck on which merchant gets paid.
Also many transactions are not irreversible.  Software which has a license key can have the license key revoked.  Many giftcards can be reported as stolen to freeze the funds.  Any subscription based site would grant you at most a few seconds of service before cutting you off.  Product which require physical deliver are never going to be shipped fast enough to execute a double spend.
The risk of a 0-confirm double sped is low but security can be improved by designing ultra fast low latency "super nodes".  A service provider could setup a network of Bitcoin nodes around the world with low latency links between them.  Each of these nodes would be running modified version of bitcoind to maximize the number of connections, establishing thousands or even tens of thousands of connections to peers.  No matter where the two halves of the double spend originate it would be only a few hops to a super node.
If a merchant only accepts transactions from the super node network then you would be unable to complete the double spend.  Either the network has seen both transactions and the double spend is detected or they haven't in which case one of the merchants won't give access to the item purchased.

It wouldn't really take much work just demand.  Map out the existing Bitcoin network and find locations for servers in diverse parts of the net (say server in Hong Kong, UK, US East Coast, US West Coast, Germany, Brazil).  Setup those nodes to create a huge number of connections to peers in the network and then relay those transaction to each other quickly.  There isn't sufficient demand today to warrant the cost but someday these nodes could be the equivelent of internet backbone for the Bitcon network.

Well, I guess one could basically set everything up on Amazon EC2 with minimal effort. Costly, but quick to set up.

What you're forgetting is that merchants who accept transactions with zero confirmations would already defend against this attack using well-known methods. The primary defense is monitoring the Bitcoin network at multiple points, as close to the largest mining pools as possible. The merchant only considers a transaction valid if they see it at the vast majority of their probe points. And, of course, if they see a conflicting transaction at any probe point, they reject the transaction (until/unless it gets confirmations).
This is why the Finney attack was such a shock. It was generally believed that this was sufficient defense. In my opinion, it is still sufficient for low-value transactions, say less than $250 or equivalent. At least, that's my opinion until we actually see a successful double-spend attack against a merchant using reasonable defenses.

How do you get to the $250 number? I was going to post a question about how to calculate this and found your answer.

It can be higher now. The number is based on the risk an attacker takes -- the risk of losing the mined block. Just be warned, the primary defense is not sufficient, you need others as well. For example, the transaction fee must be adequate.

Bear with me. How does a double spend attacker, not a 51% attacker, risk losing a block? He's not necessarily a miner. I can send the same coins to 10 addresses and I own 9 of them, only 1 is a merchant I'm trying to fraud. Isn't there 90% chance I will end up still owning the coins? If the merchant sells an irreversible good with 0 confirmations, he's in trouble. Or is he? Enlighten me :)

@AntonAnsgar That won't work because as soon as the merchant sees a conflicting transaction, he won't issue the goods. You can't get 90% of the miners to see the transaction and still hide it from the merchant. So the attacker will have to mine his own block with the conflicting transaction, hold it until the merchant releases the goods, and then release the block with the conflicting transaction. (We're assuming the merchant uses all reasonable defenses against double spends except waiting for a confirmation.)

All reasonable defenses include connecting to enough nodes and having enough delay before accepting the payment that the probability of not seeing the conflicting transfers become negligible. As suggested in the first answer. I need to learn more about how to hold a mined block to understand the block mining part of your answer but I think I get the 0 confirmation double spend part. Thank you very much.

@AntonAnsgar Punch "Finney attack" into your favorite search engine.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
How can one find how much "room for arbitrage" is there in the Bitcoin market?
I don't know what's the mathematical/economical definition, but I would define "room for arbitrage" as the amount of money that can be extracted from the market by doing arbitrage (between the different exchanges). I am sure there is a precise definition of such a concept.
So, given this definition - how much room for arbitrage do the current Bitcoin markets exhibit?
Edit - see also on Quora - How do you measure arbitrage?

See also http://bitcoin.stackexchange.com/questions/121/is-there-an-efficient-way-to-exploit-arbitrages-between-the-different-exchanges

This seems like a very time dependent question, doesn't it?

@D.H. - True, but check out the answers, they contain important timeless information and links.

Could we at least change the title then? If the answer contains timeless information I'm sure we can make the question more timeless. Perhaps something like: "How can I exploit possible arbitrage opportunities in Bitcoin markets?"

@D.H. Edited, but not to the title you suggested.

Good, that's much better.

http://bitcoin-analytics.com/#arbitrage provides realtime arbitrage panel which supports history of arbitrage opportunites between all major markets.

After studying Bitcoin Arbitrage for the past few months, I've developed an information service to answer this question.
CoinThink.com gives a complete picture of arbitrage. All asks that have a bid at a higher price (on another exchange) are tallied into a total opportunity amount, including the fees for each exchange. It also makes an estimate on the fee for moving money between exchanges. The result is a total dollar amount available for arbitrage.
The exchanges are limited to those that have an automated transfer capability - basically a connection to bitinstant. I am interested in extending the site's functionality to bigger and better information in the future.

Any chance to get CampBX on there?

@ColinDean thanks for the suggestion. While I dont think CampBX has enough volume to be interesting to a general audience, next on the todo list is a way for exchanges to be included or not based on user preference.

I am not an expert on this, but I will answer from my personal experience from the past couple of months. Here are some things I noticed:

MtGox rules the market. The price there leads and the other exchanges follow. Sometimes TradeHill moves a few decimal points on its own above or below MtGox, but it usually goes back to where it was after a few hours.
The price difference between exchanges with APIs rarely goes above $0.3 (the most common opportunities are around $0.1/BTC). So with the current fees you will earn very little from each trade - note that on smaller exchanges, it is very easy to move prices up and down so you are doing arbitrage with very small trades.
You must be fast. There are already people doing this and the opportunities don't stay up for long. If you are not careful your orders will end up pending.
Exchanges without APIs have much more arbitrage opportunities. Bitmarket for example is some times $1 or more off the current MtGox price. Of couse it is also much more time consuming to arbitrage manually.
There are days when nothing happens and others when a lot happens. You have to be ready and keep a lot of money on each exchange if you want to catch it all. There are huge volume differences so you should split your money accordingly.

I am still testing things out, but I don't think that you can make a lot of money out of this. It may be interesting to use it as a complement to other automated trading strategies though.

Just another note:

Moving money/bitcoins around to grab opportunities in exchanges with APIs won't work because of fees (even if small) plus waiting time. You usually have a few minutes to grab opportunities. If you are lucky you can sometimes find an opportunity that lasts a couple of hours, but that happens like once a week.

All of this is from personal observations during July/August 2011. Things will of course change and the market will probably become more and more efficient.

See this pdf for more information.
If you were asking about a two currency arbitrage between different markets.  For example, the BTC/USD exchange rate at MtGox and one at Intersango then the following formulas apply considering brokerage fees at both exchanges.
For simplicity I am using BTC as the base currency and USD as the quote currency, but you can exchange these easily.
Assume:

A is the exchange rate of BTC/USD on exchange MtGox
B is the exchange rate of XXX/YYY on exchange Intersango
Fa is the fee of MtGox
Fb is the fee of Intersango

There is a no arbitrage opportunity if A = B + ( Fa + Fb )
But if A - B > Fa + Fb then the the base currency, BTC, is cheaper on exchange B than in A.  So the person would buy BTC on Intersango (B) and sell BTC on MtGox (A).
profit = A - B - ( Fa + Fb )
If B - A > ( Fa + Fb ) then the base currency, BTC, is cheaper on exchange A than in B.  So the person would buy the BTC on MtGox (A) and sell it on Intersango (B).
profit = B - A - ( Fa + Fb )
Other arbitrage opportunities will exist such as triangular arbitrage.  But those won't develop until the exchanges not only have BTC/fiat currency pairs but other currency pairs as well.

There are on occasion decent opportunities for arbitrage if you are willing to go through the hassle for a few bucks.
Here are two data services that are useful:
- http://nyse-group.de/bitcoin-arbitrage
- http://fnoose.com/bitcoin/arbitrage
The opportunities are the largest after a sudden move in the price on the leading exchange, Mt. Gox which leaves scraps that can be picked up by performing arbitrage against open orders left on other exchanges.
Of course, to do so means you needed to have funds sitting out there on the other exchanges in order to be among the first with access to do those trades.
The delays in adding bitcoins (waiting for the transfer to confirm) or in adding funds through other channels (e.g., Dwolla transfer) mean arbitrage opportunities might evaporate as those with the open orders become aware that the market has moved and will cancel their orders.  Eventually, in the range of tens of minutes or hours at most decent arbitrage opportunities that yield a few dollars or more will get attention from a trader performing arbitrage.
Because Bitcoin has so many different currency markets, one service that enables the ability to transfer cash out of the exchanges might be useful: http://en.bitcoin.it/wiki/CurrencyFair CurrencyFair was reviewed recently here: http://www.bitcoinmoney.com/post/7259588518
and Nyse-Group's arbitrage viewer was reviewed here: http://www.bitcoinmoney.com/post/7000316379
The ability to move funds to and from exchanges, nonetheless movement between exchanges, was a topic addressed by Rick Falkvinge: http://falkvinge.net/2011/06/10/bitcoins-four-hurdles-part-four-exchanges

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Do no-fee transaction represent a greater risk if the product is delivered instantly?
Let's say I want to accept payments instantly on a site for digital downloads.
So I publish an address and wait for the unconfirmed transaction, I see the transaction and release the digital download.
However the user may have sent the transaction with no fee. Therefore the miners may not pick it up or the user could issue a new transaction with a fee that gets processed into the block chain.
Is my thinking correct ? and is there away to stop this king of attack ?

See also http://bitcoin.stackexchange.com/questions/1869/how-to-perform-a-double-spend-attack-in-websites-that-accept-transactions-with-0

To stop the attack you could wait for the confirms and then send an email "your download is ready" if that works for your type of business.

You can check if a transaction includes a fee just by looking at its inputs and outputs (you can also access this information at blockexplorer.com).
But you are correct: accepting transactions with 0 confirmations is risky and there are other attacks besides the one you mentioned (the 51% attack and the Finney attack, for example).
Here are a few options to defend against this:

Wait for more confirmations - this may not be desirable but it works
Accept payments from an e-wallet/exchange like parker_vmg3 mentioned - some websites such as TradeHill or CampBX allow you to send bitcoins instantaneously between members
Use green addresses - currently these are only available at MtGox and InstaWallet, but they might become more popular in the future

While 0 confirmations have risk the risk for small value purchases is likely less than accepting credit cards especially when you consider the added cost of chargeback fees.  All risk is relative.  While there is risk of loss with 0 confirms the risk of loss is never 0 even with 6 confirmations.  One has to weigh the cost of requiring multiple confirms (less user friendly = less sales) to the very low risk of getting double spend.

It should get picked up eventually, but yes, the user could double-spend before that.
That is exactly what confirmations are for. But it is probably unlikely that you would see massive amounts of "piracy" due to this. I'd just write that off as a cost of doing business. If it does get out of hand, you can go back to waiting for confirmations or accepting "green addresses".
Also keep in mind that if the users are not anonymous towards you (i.e. they maintain some kind of relationship with you, even just a user registration), you have recourse (you can refuse to continue offering them access until the scores are settled).
It is a trade-off between relying on trust (that the user pays) versus waiting for the amount of time it takes for the confirmations.

The risk of a transaction never getting picked up is essentially zero.  Currently blocks are on average only 5% "full" so miners and mining pools tend to include all transactions.  For a transaction to never be included it would require that no miner on the planet ever include this transaction.
If it did become a risk you could always require a fee is user wants to download at 0-confirms.  You can enforce this by checking the transaction.  The fee amount if the difference between inputs and outputs.  If they are the same then there is no fee.  For users which ignore your instructions and submit a no-fee transaction you could then just wait for 1 confirmation.
The greater risk comes from a "double spend" or "51% attack" however these risks are often overestimated. Allowing digital downloads paid by credit card has risk too so achieving 0% risk isn't a viable business strategy.  Even if your software never has credit card fraud is likely has losses due to piracy so the best solution is one that maximizes net revenue not one that attempts to eliminate all fraud.
Each business needs to look at the risk of their specific product.  The higher the value the more likely you should consider using confirmaiton. There is little value in executing a double spend attack to get a 1 BTC ($3 USD as of writing) copy of say "Super Angry Birds".  Allowing instant downloads likely improves sales enought offset any neglible increase in fraud.   On the other hand if you are allowing downloads & license keys for SQL Server Enterprise at 2500 BTC a copy you probably should require confirmations.
Confirmation can only reduce not eliminate risk. The less risk you have at 0 conifrms the less benefit there is in delaying your customers. The real question then becomes does the delay end up costing you more revenue than it saves you in near non-existant fraud.

+1 for "the best solution is one that maximizes net revenue not one that attempts to eliminate all fraud"

If I understand you question correctly, you could get them to give you an instawallet or maybe strongcoin address as a link where you could transfer funds directly into your wallet.


text:
How can I generate a large number of Bitcoin addresses?
I would like to generate a large number of public Bitcoin addresses (several hundred thousand) quickly and efficiently into a simple text file. What would be the easiest way to get this done? I'm just wondering if there are any particular scripts or services that handle this already without having to roll my own.

If you want to generate a lot of keys in the wallet.dat, use command line parameter:
-keypool=<n>       Set key pool size to <n> (default: 100)

Then you can extract the results with Pywallet.
If you want to make them separate, you will have to use a cryptography library that supports secp256k1 ECDSA, like the Bouncy Castle. Simply generate private keys, use the library to generate public keys from them, and then convert them to classic Bitcoin address using this algorithm (requires libraries that support SHA256 and RIPEMD-160).

Hmmm. So roll my own then? Not a standard feature of bitcoind to produce them outside of the wallet.dat?

Wouldn't know, what do you want to do with those addresses anyway?

One possible use case would be to pre-load an online service with a bucket of transaction addresses. No private keys stored on the server.

I guess you could also use Pywallet for this, edited my answer.

Vanitygen is a command-line tool that can be used to generate random bitcoin addresses. It also has OpenCL-compatible GPU version called oclvanitygen. Both can be built from source, GitHub, and both are included in the Windows binary package. PGP signature here.

Good suggestion, but I need to favour performance over looks. Generating vanity addresses will throw away perfectly acceptable addresses leading to wasted time.

@Gary Rowe But couldn't you just provide and empty regular expression (something like 1*) and generate a ton of addresses?

@nmat Good point - hadn't considered that

i would think that vanitygen is the best performing address generator, but i don't have numbers to compare. see also http://bitcoin.stackexchange.com/a/2088/1098 for vanitygen speed

You can use bitaddress.org. It is a single HTML file so you can save it and generate lots of addresses offline using their Bulk Wallet tab. The biggest problem here is Javascript performance. With current hardware you can generate around 1000 addresses per minute. If you are willing to wait several hours (maybe leave the computer working overnight), this can solve your problem.

Interesting approach, however I'd be looking to create them in blocks of several hundred thousand in a short space of time (a few minutes) so I'd need a compiled execution environment.


text:
Why does Bitcoin send the "change" to a different address?
For example I have an address (A) with 20 BTC and send 9 BTC to address (B).  Bitcoin will create a "change" portion of the transaction where the remaining 11 BTC goes to address (C).
Why not send the change back to A?
Instead of:

Initial balance:
A: 20 BTC
B: 0 BTC
C: 0 BTC

Transaction Pair:
A -> B 9 BTC
A -> C 11 BTC

End result
A: 0 BTC
B: 9 BTC
C: 11 BTC

Why not?

Initial balance:
A: 20 BTC
B: 0 BTC

Transaction Pair:
A -> B 9 BTC
A -> A 11 BTC

End result
A: 11 BTC
B: 9 BTC

and is there an option in the client to turn this off (i.e. send back to the original address)?

Related: http://bitcoin.stackexchange.com/questions/736/how-does-change-work-in-a-bitcoin-transaction

I've got a 'noprivacy' branch at https://github.com/gavinandresen/bitcoin-git that sends change back to the funding address, but it confuses the heck out of the 'accounts' code and makes for confusing-looking transaction lists.

Is there any solution than? I would also prefer when the change come back to the original address.

Two reasons:

So whoever sent to your "A" address can't claim to have sent you 31 bitcoins ("See!  Look on block explorer, there are two transactions sending to "A", one for 20 bitcoins and one for 11-- send me back the extra 11!")
Using a new change address makes it more difficult for other people to track of how many bitcoins you have or where you're spending them.

It also conceals which output is the "spend" and which is the "change".

The preventing a false claims would be of dubious value.  Transactions are irreversable anyways and the transaction will clearly indicate the coins went from A to A.  The second part of your answer plus David clarification seems most likely rational.

Sending the change somewhere else makes it look like you spend your whole balance, which is not the case. It can be very confusing for beginning users.
I think this should be an opt-in option for the default client.

I also think separate change addresses are a very bad "feature". Sending back to the same address would prevent paper wallets becoming obsolete when a part of them is spent. Obfuscating payment flow should also not be part of the "official" bitcoin client. Keeping the ledger straightforward would lend Bitcoin more legitimacy.

@DeathAndTaxes, so basically Gavin's first point is wrong/invalid?

I agree with @Steven Roose. Look this address: https://blockchain.info/address/175fTMj3sNZANncHTGEGw4SAims14ZDxNX I sent 5 mBTC from 175fTMj3sNZANncHTGEGw4SAims14ZDxNX to 1JGZbBj5iuxzskxAxRmoQgKZXoDehGEA6r and then my client creates an address 15taCtq1Mj76wuweVjnvrmKxSt3gKMVXqJ to receive the left 0.8 mBTC. But my client shows only two addresses: 1GzeYtD8KGVw7LmWCtsQ7wMX3Me7KUBwna and 175fTMj3sNZANncHTGEGw4SAims14ZDxNX. Both with zero balance. But my bitcoin-qt shows I have 0.8 mBTC balance. It is very weird and confusing.

Look this too: http://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/ It's hard to final user. I prefer like before.

@DeathAndTaxes, Do you mean that if we are inventing a new coin that doesn't need a "concealing advantage", it would be more beneficial to have only one target?

@Pacerier, I do hope so! :) That security-through-obscurity argument looks incredibly silly. But it still seems somewhat nontrivial to prove being the sender of a tx. (esp. with multiple inputs); see e.g. https://bitcoin.stackexchange.com/questions/18502/is-there-a-way-to-prove-ownership-of-a-transaction

While the other answers are slightly true, there's another reason. Addresses which have been spent are inherently less secure than unspent addresses. This is because, when spending on an address, you reveal the public key to the address. This means that in order to steal those funds, you only need to find the private key, whereas normally you'd need to break the hash and find the private key.
Both of these tasks are extremely difficult, so for now it's not much of a concern if you send to spent addresses. The problem arises with the theoretical quantum computer. ECDSA, the technology which secures your private key, is extremely easy for quantum computers to reverse. The hash isn't. Therefore, when quantum computers become popular used addresses will become exponentially less secure.
More info at https://bitcoin.stackexchange.com/a/7134/11666
Also: https://bitcointalk.org/index.php?topic=153302.0
In the BitcoinTalk post, the concern brought up about hackers cracking transactions between broadcast and inclusion in blocks is reasonable. Fortunately, honest miners include the first transaction first regardless of fee, so that attack is foiled. It is also prevented by the fact that it would still take quite some time to crack the public key.

Why do you believe breaking a key pair is easier than breaking a crypto hash?

http://en.wikipedia.org/wiki/Elliptic_curve_cryptography#Quantum_computing_attacks

@Basic, because the Public key is generated from the Private key via SHA256 algorithm, which is vulnerable to quantum computer attack. While the Bitcoin address is generated from the Publik key by using both SHA256 and RIPEMD160 algorithms and potantial hackers will need to attack 2 different encryptions.

@Sulevus If you encrypt/hash something multiple times, it doesn't necessarily make it more secure... It depends entirely on how the two systems preserve entropy across multiple operations.

The idea of the change addresses is an attempt to make transactions anonymous. Unfortunately, bitcoin transactions are not anonymous, even with the use of change addresses:

http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html
http://motherboard.vice.com/blog/if-youre-not-careful-bitcoins-arent-as-anonymous-as-you-think

When you have a wallet filled with change addresses, transactions will be forced to use some of those change addresses to fill transactions you want to make. The fact that the receiver is the same, and that the time of transaction is the same means that an outside observer will have a high confidence that those addresses belong to the same person. If all of those addresses only received bitcoins from a single address, it will be very clear they are change addresses for that address.
What the above means is that your addresses become deanonymized when they are used. This makes your privacy basically worthless because anyone can look back a couple years and see everyone you paid or received money from.
This is not necessarily a bad thing, as the tracability of transactions will make it harder for governments to justify fighting the adoption of bitcoins.
While you might gain a tiny bit of privacy for a short period of time using change addresses, there is a HUGE downside: it makes backing up your money intractable. If you want to back up an address, you can do that easily. Just encrypt your wallet and copy it to various devices (your phone, external HD, USB drive, paper wallet, etc). If change addresses are used tho, you must copy to all your backups (as painful as printing out a new paper wallet) every time you make a transactions. That is intractable.
That intractability I think is a HUGE problem for bitcoins. People need a secure way of being "their own bank" and change addresses make bitcoins broken for most people.
UPDATE: Deterministic wallets somewhat solve this problem by allowing you to determine all of the wallet's potential addresses from a single seed value. This allows you to backup once, and restore at any later time by using the seed to generate and check addresses until you're sure you haven't used any beyond the ones you checked. Armory, Electrum, and CarbonWallet all use deterministic wallets.

I really like this answer, but it seems like it would be better provided under another question. Gavin's answer is 100% true, and this answer would be better for a question about the anonymity of change addresses.

@BT , so how does Dark Wallet work then?

@Pacerier I don't know much about Dark Wallet, but there can certainly be much more complicated schemes that keep addresses more anonymous. This would involve things like staggered transactions and sophisticated transaction mixing. These aren't your average transactions. They're complex techniques and they're just as useful without the use of change addresses.

@ColinDean, Is the "quandary" typo in your profile intentional?

@BT, However, adding the use of change addresses does increase the cost of unanonymizing right?

@Pacerier Yes, but while I'm not entirely sure how much the cost is raised, I'm thinking the theoretical limit is doubling the cost. Tho in normal scenarios where that address is eventually used in conjunction with another change address, the cost in determining that is basically negligible.

AIUI the original idea was that every address would be used exactly once, with change addresses being no different in that regard than any other address.
Unfortunately many people use a single address loads of times and even publish it publically. That gives places for tracers to lock on to.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How does BitPay manage to confirm transactions so fast (less than a minute)?
I believe it takes about an hour for 6 confirmations. (Edited from David Schwartz's comment)
However, when I purchased some stuff from merchants who used BitPay, the payment/orders were confirmed in like 20 seconds or so?
Since BitPay is confirming the order before 6 confirmations, how does it protect itself from double spending attacks?

How long do you think it takes BitPay to confirm a transaction? Are you assuming that just because the buyer isn't waiting at a screen, that means the transaction has already been confirmed? (Also, on average it's 10 minutes per confirmation, or 60 minutes for 6 confirmations.)

@DavidSchwartz I was able to place orders with merchants using BitPay in less than 30 seconds from sending payment to confirmation of payment on BitPay screen and confirmation of order from merchants? BitPay has retail store solutions where the customer pays with bitcoin and leaves with his stuff which looks like is getting processed in less than a minute.

BitPay takes all the risks of a double-spend and they don't wait for any confirmation to make the user feel good with the purchase. The merchant doesn't care because they'll receive fiat and most of them are not direct access purchases.

how does this scale when it is used in retail stores and I shopped for expensive stuff, say jewellery or a macbook etc...?

@Medicine Same as my previous answer. They take the risks for the instant payment. There's no other way around, unless you use a Green Address.

They probably charge extra for the exchanging of currencies because of that. And you did say it takes several seconds, which often is enough to detect a double-spend attempt (but often not).

@DanielH, couldn't just several huge fradulent transactions render them bankrupt like MtGox?

@Pacerier I read they've not receive a double spend attempt yet, they'd love to though, so they can appear in the media telling the story...

As I understand. In a bricks and mortar retail environment listening software can be employed which in just a few seconds reduces the risk of a double spend to a mathematical possibility rather than a practical concern.
Mail order, as soon as the transaction is detected, well there is no risk.

Do you have any information or source regarding "in just a few seconds reduces the risk of a double spend to near negligible".

"For security and fraud prevention reasons, we require one confirmation on the bitcoin blockchain before we can credit funds can be added to the BitPay Card.
Note that confirmation times are determined by the Bitcoin network, not by BitPay. One confirmation may take as few as several seconds to as much as a few days, but most transactions are confirmed within an hour." - from their site. So they wait just for one conf.


text:
Ogrr market size
I've heard that [Ogrr] (http://ogrr.com/) has provided Bitcoin as its internal unit of trading. Could someone who knows the forum well provide us with information about:

How large is the transaction volume every day?
How do members deposit/withdraw BTC to their accounts in the forum?
How much is the fee?
Do you think this forum will help raising the price of Bitcoin?

I've always been interested in implementing a virtual currency in a forum. I am curious about what forum software does Ogrr use so that they can quickly convert mBTC to USD.

I don't know a lot about Ogrr. But what makes you think it can (or should) convert mBTC to USD? One of the points of using Bitcoin for this is that it's a real global currency, it's not internal to the forum and thus needn't be converted to anything as far as the forum is concerned.

I've taken another look and, in case you meant conversion of displayed prices (as described in https://ogrr.com/viewtopic.php?f=37&t=479), I don't know about the implementation details but in principle it just involves polling an exchange for ticker data and doing some arithmetic.

Yes, that's what I meant.

You should drop the 4th question as that is just a matter of personal opinion and not suitable for an SE site.

There was a bitcoin-powered service like Digg / Reddit that allowed posts and replies so it was kind of like forum software -- it was called Witcoin.  It was really a neat idea.  It didn't gain much traction though -- for various reasons.  http://CoinSmack.com is along the same lines as Witcoin, but no comments / replies.

Thanks for all the comments, but for the 4th questions, I think we need more opinions. And I don't see why it's not suitable for an SE site.

@StephenGornick, I went to Witcoin and found it went down sadly. I also vist CoinSmack.com but it's not really seems like a forum but a advertising site.

Well, I don't know what the transaction volume is - only the site owner would be able to give you that information. As far as your other questions:

How do members deposit/withdraw BTC to their accounts in the forum?

Same as you generally deposit/withdraw btc from any site. You go to your account, click the 'deposit' or 'withdraw' button, and it either gives you the address to send btc to to fill up your account, or it tells you to input the address to which you would like to withdraw.

How much is the fee?

I understand there's currently no fee being charged by the site.

Do you think this forum will help raising the price of Bitcoin?

Any venture that results in more people using bitcoin will, ceteris paribus, raise the price of bitcoin.
Hope that was helpful. :)

See, like right there is the reason every forum software, including right here -- Stack Exchange, should have a system for giving credit of some sort.   Thanks to nanotube I now know what ceteris paribus means ("all other things being equal").  I'ld like to give him a few cents as a tip to express my appreciation for expanding my vocabulary.  Hitting upvote/+1 on his answer really doesn't let me express my appreciation like maybe a monetary tip would.


text:
Which cryptocurrencies deviate significantly from Bitcoin?
There's been dozens of alternate cryptocurrencies but I don't believe many of them did much other than find/replace some strings.
We see Bitcoin as made up of the blockchain and proof-of-work via hashing of the next block. Have there been any altcoins that drastically strayed from this recipe?

The original question was primarily opinion-based and thus not suited for StackExchange (a better fit would have been a forum such as bitcointalk.org). I edited the title to be more suitable.

Ripple is in my opinion very interesting that uses a very different system which isn't based on the block chain nor the proof-of-work algorithm. Rather, it uses a quite different consensus algorithm outlined here: https://ripple.com/wiki/Consensus
The only problem is that there's very little research about this concept and I can't figure out how it works more in detail without an official publication of some sort. All I can say is that it's different from any altcoin because it's based on trusting nodes that behave honestly and distrusting the ones that don't:

If someone should be dishonest, the honest actors will notice them
  lying and can disregard their future attestations.  That is, if you lie once, you have no gain as the network doesn't care and they won't care what you say in the future.

The "trust" in Ripple's UNL (unique node list) setup for servers isn't that you need to trust the validator to be honest, it's a much lower bar in that you just need to trust them to not collude with another validator on your UNL (i.e. to not be dishonest in the exact same way as someone else, and if you don't/can't trust them not to collude then you don't put them in your UNL).

The example I sometimes use is the NSA, Al Qaeda, the government of North Korea, the Mossad, and Disney corporation. You probably don't particularly trust any of these groups. But they're very unlikely to collude against you. (I just use this to show that trusting not to collude is a lower level of trust than, say, trusting to provide accurate information.)

Counterparty is not even an altcoin, it is entirely compatible with Bitcoin. In fact, BTC is a first class currency inside Counterparty, which provides a financial toolkit for a global market, betting, derivatives, contracts for difference, and more.
Counterparty actually runs on the Bitcoin blockchain, and can therefore be considered part of Bitcoin itself. It's like a symbiote that uses the unused data space in Bitcoin transactions to create a true free market for securities, derivatives, "coins", crowdfunding, and anything people can come up with..


text:
Got the Bitcoin Wallet. How do I transfer money into it?
I've got active connections & there are blocks downloaded but I don't know what to do next. Presumably I need to transfer some money in there so I can buy bitcoins. But how?
Any suggestions gratefully relieved.
Thanks.

There are currently development efforts in place to integrate the exchanges with the various wallets to make this process much easier in future. You may also want to look over http://lovebitcoins.org which offers practical advice about how to reach an exchange local to you.

It is not possible to buy bitcoins from inside the client. What you need to do is this:

Find someone that you can buy bitcoins from. One way is to use an exchange, such as Mt.Gox, that let's you deposit USD (or some other currency) and then buy bitcoins.
In the Bitcoin client (assuming you use the original client from bitcoin.org), get a Bitcoin address from the "Receive coins" tab ("New address..."). Using a new address for each transfer will increase your anonymity.
Transfer the bitcoins you bought to your new Bitcoin address. If you use Mt.Gox you would use the "withdraw" option. The bitcoins will then show up in your client.

Thanks so much for that. I did get the wallet from bitcoin.org and have got an address from the. I’ve been trying to get the bitcoins on Mt.Gox. I will try the ‘withdraw’ option on MtGox now. Thanks!

Mtgox.com seems to be now in Bankrupt. Any other proposals?

Do you have any proposals how to do the case in euros?


text:
Is it possible for someone to verify that a wallet is theirs wallet, without providing their private key?
I need to know with 100% certainty that someone can tell me "this is my wallet" and prove it to me.  I could of course simply get their private key/brainwallet phrase, is there any other way to do it?

To be exact, you're not getting proof of "this is my wallet" in the sense analogous to "this is my account" - you're getting proof of "at this point of time, I [along with possibly others] have control of this wallet".  Usually it will mean the same, but not always - e.g., it doesn't neccessarily mean that yesterday this was your wallet, and it doesn't also imply that any future transactions are authorised by you and not someone else who also has the keys.

Yes, you can use "Message Signing", available in most Bitcoin clients, including Bitcoin core. If I sign with my address the message "I am Meni Rosenfeld and I am proving to user127317 that this is my address", you can be sure it's mine.

Good idea!  Any issues with multi-sigged addresses?

@user127317: Good question, not sure how those would be handled. In theory you should at least be able to sign the message separately with each key associated with the address.


text:
What is the story behind Tradehill?
Tradehill used to be an important Bitcoin exchange, but it was closed earlier this year due to losing a lot of money to their payment processor. What is the full story behind Tradehill?

Basically, Dwolla promised that they would never honor chargebacks. They in fact did and stole dollars back from their bank account after TH gave Bitcoins to the scammers. They lost a lot of money by this. I believe Dwolla is being sued for 2 million dollars as a result of this.

That isn't really "the full story behind Tradehill".

If you believe something is incorrect you may downvote or even vote for deletion. Please do not flag things for moderator attention based on correctness.


text:
What's the story behind the Mitt Romney's tax return information blackmail
On the 6th of September, 2012 CNN reported that a hacker group got a hold of Mitt Romney's tax return information and demanded a ransom of 1 million dollars equivalent in bitcoins to be paid for not revealing the information, or for revealing it instantly. What is the full story behind the hack and blackmail? Was the ransom paid, or was the data revealed?

IMHO this question is not a good fit for the site. It's not really about Bitcoin but about some blackmailing where they happened to use Bitcoin. I'll see what others have to say.

@D.H.: I think it fits. At this point in Bitcoin's life, this story is about as much about Bitcoin as it is about Romney. In 10 years time, hopefully this would not be the case for a similar story.

There were 3 BTC paid on the "release" side, and 0.72 BTC paid on the "don't release" side.
So it brought in under $50 USD worth.
And the deadline passed with no tax returns.

http://www.dailydot.com/news/blackmailers-50-dollars-bitcoin-romney-taxes/


text:
Does blockchain.info backup wallet include also the next addresses
The standard client's wallet includes a key pool of 100 extra pre-generated addresses, which are the next ones to be "generated" when you ask an extra address.
Does the blockchain.info's backup wallet do such a thing, too?

Related: http://bitcoin.stackexchange.com/q/10557/153

No, it doesn't. At least not from what can be seen in the "Export Unencrypted" option and I doubt that it would be any different using the encrypted option.

Lol I noticed and added the same answer right now

Ah, I beat you by 20 seconds or so. :)


text:
Does Ripple give an advantage to early adopters?
I really believed in the idea behind Bitcoins from the start, and because I was an early adopter, I made some nice profit.
Now I forecast a big future for Ripple too, but I don't see many ways to turn this into profit. I can start hoarding loads of XRP, but it doesn't seem likely they will become valuable in the future, because as soon as they do, transaction fees will be lowered. Another option is to start a new gateway, and because they're pretty scarce now, it may become one of the popular ones in the future.
Is there any other way I can profit as an early adopter?

OpenCoin is the earliest adopter, and they start with all the ripples, so, in a sense, yes.

I don't see how "transaction fees will be lowered" is an argument against XRP appreciating. If people start using the XRP currency it will go up in value just like Bitcoin. However, I am suspicious of a currency where a single entity gets it all from the start. (And it doesn't matter how they choose to distribute it, what matters is that they have a say in it.)

XRP isn't supposed to be the currency, it's intended for keeping the network possible. The actual point of Ripple is to trade in other IOUs of other currencies. Of course, as with any scarce resource (e.g. WoW legendary equipment) you can trade or invest in it whether it's intended or not. But there are 100 billion XRP's available, waiting to be distributed at the whim of OpenCoin, so expect major inflation in excange value. Again, this is because they are not intended as currency, but as cheap network plumbing items.

Advantages to being an early Ripple adopter:

Being able to get a lot of free ripples during their first distribution
Being able to establish oneself as a reliable and reputable Gateway that will be a go-to place for everyone
Establishing oneself as the first business to do something with Ripple - be it selling something or offering some services. Other early adopters would be then inclined to spend their ripples on your service just for the sake of using the system

Generally, there is not that vast of an advantage for being an early Ripple adopter as compared to using Bitcoin. That doesn't mean, however, that the advantages are not there.

I'm a Ripple early adopter. Where do I get my free Ripples? (I mean besides the few you sent me)

You can get your free XRP's from various giveaways: https://giveaway.ripple.com/ Currently there is a giveaway from GitHub users. Remember that XRP's are not in any way the "point" of the Ripple system, they're just for making transactions scarce. You should not invest in them, they are not intended as currency (though they can be used as such).


text:
Is there a Bitcoin service that works like Western Union?
I am very new to using Bitcoin.  I have never actually used it yet.  My goal is to send a payment of $100 to a trustworthy individual in China.  I was given some sort of address by this individual when I asked how/where to send payment.
Is it possible for me to simply go to a physical agent location near my address to make this payment, then have the agent send my payment to the recipient (similar to how western union and money gram work)?
I am very intimidated by how this all works.  I would love to simply do this on my own computer, but even creating a credible "wallet" has been confusing for me.
Any comments or help are greatly appreciated!!
Thanks

Welcome to Stack Exchange. When posting questions, please choose a title that hints at what the question actually is, rather than a generic description like "Beginner question".

I don't think you'll easily find a service of the kind you describe.
But using Bitcoin directly shouldn't be too difficult. You can install a wallet on your computer such as https://electrum.org/. Then you can buy some bitcoins (the best way will depend on your location), and send them to the recipient.


text:
Why doesn't Bitcoin use a DHT for choosing peers?
Why does Bitcoin use a gossip protocol rather than a DHT for peer discovery? I believe that kademlia XOR distance helps shape the network topology so that peers are more evenly disturbed.

What does 'peer lookup' mean? Bitcoin does not have any local data specific to a node, and every node needs to learn everything anyway. We have peer selection logic, but it optimizes for DoS protection robustness and propagation speed. What exactly would it use a DHT for?

i think he's talking about the BitTorrent DHT implementation, which is used to find peers - Bittorrent's DHT stores IP addresses of peers downloading the torrent as values - although generally DHT's aren't used for that.

@NickODell i mean peer discover. Is that clear?

@PieterWuille With XOR-Topology you have more evenly connected network. With Gossip peers that stay online for a long time tend to have more connection. Since almost every peer will know about it. But I'm not 100% sure about this so I'm asking here.

DHTs are built so that nodes keep only a small portion of other nodes addresses in their routing table (the closest ones). This means that when you send a message to a DHT to put("foo", "bar"), only specific peers are going to see it (in fact as little as possible) and even fewer are going to store it. So if you want to do "peer lookup" using DHTs, it wouldn't work because nodes aren't programmed to send messages through a path to all nodes.
Also I think you may be confused with BitTorrent's DHT. They store IP addressed of peers downloading torrents as values of keys in the DHT. So in that sense, they do use the DHT to "lookup peers" downloading a specific torrent. BitTorrent is a different system than Bitcoin, which is not a file-transfer protocol, and therefore I don't see how a DHT can be useful to Bitcoin's design.

I edited the question to make it more clear. You can most certainly use a DHT like structure to select Peers. Its not quite a full DHT because we wouldn't be storing any hashes.

your question is still not very clear. what are you trying to do?

trying to find peers to connect to. you can do this with an greed algo (ie. ask a bootstraping peer to give you all the peers it knows about and so forth) or storing peers in k-buckets (DHT) and connecting to them on the basis of their XOR distance. Which should give you a "better" network topology.  Is there any reason that bitcoin uses a greedy algo and not something?

Actually DHTs don't say anything regarding "how to find peers". DHTs have a logic of understanding which peers to keep and which to reject, and the result is that you end up connecting to peers that are XOR closest to you. In terms of "how to find peers", the logic is similar to Bitcoin - just ask other peers about their routing table. Also, the XOR distance is useful for performing key lookups - it reduces to a minimum the number of hops to find peers storing a specific key - how would it be used in Bitcoin?

Other blockchain projects, like Twister, use BitTorrent/DHT, so why doesn't Bitcoin?

I have seen this conversation before in antivirus forums - why doesn't AV XYZ use X method for distributing updates, it would be better/faster/foo/bar.

Event Bittorrent DHT has a bootstrap server that talks to Bittorrent server. Still, DNS is centralized so DHT would be a more decentralized way to find peers. I think it fits the spirit of Bitcoin better than DNS.


text:
debug.log file size
According to this comment, the debug.log file in the Bitcoin application data directory should be truncated on startup if it is bigger than 10MB. I'm running Bitcoin 0.5.2 on Windows 7 and it does no such thing - the file keeps increasing in size even after restarts, and it is already over 1GB.
Why is it not truncated? Is it safe to stop Bitcoin and truncate the file manually, or delete it completely?

bitcoind 0.5.99-beta was running and my debug.log was 26MB.  After
bitcoind stop
(wait 30 sec. or so for stop)
bitcoind -daemon

debug.log was 201KB.
Mac OS 10.6.7

my debug.log became 4GB. There should be awareness to truncate debug.log even as the software is running not upon restart

I went ahead and deleted the file. There don't seem to be any side effects.


text:
How many Bitcoin addresses are/have been carrying a balance?
Bitcoin addresses can be generated at will, and the theoretical limit to their number is high.  Addresses are constantly being generated to receive funds or balance transactions, but they are also being emptied.
How many addresses are carrying a balance at the moment, and how has this number developed historically? Would this number be a good proxy for the Bitcoin adoption rate?
I'd also be interested in the number of addresses that have been part of transactions during the last x days (i.e. active addresses).
The blockchain contains all necessary data to derive the numbers, so maybe there's even a site that lists/graphs them?

I calculated the answer by starting with Gavin's "bitcointools" and modifying it to track account balances.
Here's what I found.  Each line shows the number of addresses after the specified block was found, at the end of each month.  So the 1st line is saying that after block 2543 was found at the end of Jan 2009, there were 2,439 funded addresses, and all 2,569 were 'active' in January 2009.  The 'active' number is the number of addresses involved in a transaction in the preceding month, and can be bigger than the number of addresses which remain funded at the end of that month.
-block  --date--  --total--   ---used--%total-   -active---%total---%used-
  2543  Jan 2009      2,569     2,439 (94.94%)     2,569  100.00%  105.33%
  5923  Feb 2009      5,975     5,646 (94.49%)     3,447   57.69%   61.05%
  9389  Mar 2009      9,444     8,868 (93.90%)     3,486   36.91%   39.31%
 12831  Apr 2009     12,893    12,125 (94.04%)     3,495   27.11%   28.82%
 16214  May 2009     16,288    15,388 (94.47%)     3,424   21.02%   22.25%
 18450  Jun 2009     18,528    17,543 (94.68%)     2,267   12.24%   12.92%
 20375  Jul 2009     20,456    19,347 (94.58%)     1,973    9.65%   10.20%
 21939  Aug 2009     22,021    20,749 (94.22%)     1,639    7.44%    7.90%
 24098  Sep 2009     24,180    22,647 (93.66%)     2,212    9.15%    9.77%
 26224  Oct 2009     26,311    24,374 (92.64%)     2,231    8.48%    9.15%
 28441  Nov 2009     28,533    26,411 (92.56%)     2,262    7.93%    8.56%
 32489  Dec 2009     32,611    29,827 (91.46%)     4,420   13.55%   14.82%

-block  --date--  --total--   ---used--%total-   -active---%total---%used-
 37493  Jan 2010     37,647    34,342 (91.22%)     5,304   14.09%   15.44%
 43096  Feb 2010     43,329    37,274 (86.03%)     7,009   16.18%   18.80%
 48297  Mar 2010     48,615    40,329 (82.96%)     6,308   12.98%   15.64%
 53875  Apr 2010     57,806    42,688 (73.85%)    10,839   18.75%   25.39%
 58815  May 2010     63,368    44,620 (70.41%)     6,762   10.67%   15.15%
 63561  Jun 2010     69,540    47,011 (67.60%)     7,056   10.15%   15.01%
 71436  Jul 2010     94,992    53,227 (56.03%)    27,957   29.43%   52.52%
 77452  Aug 2010    107,172    55,995 (52.25%)    14,162   13.21%   25.29%
 82997  Sep 2010    120,562    56,490 (46.86%)    16,883   14.00%   29.89%
 88892  Oct 2010    135,952    58,428 (42.98%)    18,921   13.92%   32.38%
 94801  Nov 2010    155,639    60,615 (38.95%)    22,307   14.33%   36.80%
100409  Dec 2010    176,326    65,622 (37.22%)    23,377   13.26%   35.62%

-block  --date--  --total--   ---used--%total-   -active---%total---%used-
105570  Jan 2011    210,243    69,030 (32.83%)    37,989   18.07%   55.03%
111136  Feb 2011    267,542    78,813 (29.46%)    62,381   23.32%   79.15%
116038  Mar 2011    353,093    90,304 (25.58%)    92,321   26.15%  102.23%
121126  Apr 2011    443,112    99,090 (22.36%)    99,144   22.37%  100.05%
127865  May 2011    631,480   132,152 (20.93%)   203,052   32.15%  153.65%
134121  Jun 2011  1,061,590   196,975 (18.55%)   462,886   43.60%  235.00%
139035  Jul 2011  1,548,806   380,056 (24.54%)   531,002   34.28%  139.72%
143408  Aug 2011  1,930,979   487,833 (25.26%)   428,095   22.17%   87.75%
147565  Sep 2011  2,205,926   533,670 (24.19%)   318,294   14.43%   59.64%
151314  Oct 2011  2,411,298   546,269 (22.65%)   241,105   10.00%   44.14%
155451  Nov 2011  2,601,999   553,251 (21.26%)   225,012    8.65%   40.67%
160036  Dec 2011  2,768,500   568,177 (20.52%)   199,879    7.22%   35.18%

-block  --date--  --total--   ---used--%total-   -active---%total---%used-
164780  Jan 2012  2,956,869   580,453 (19.63%)   236,927    8.01%   40.82%
165643  6 Feb 12  2,994,694   583,126 (19.47%)    62,300    2.08%   10.68%

So the number of non-empty addresses has been around 600,000 since September 2011.
As of block 165643, the ten most common values for addresses to store were:
 0.00000000 (in 2411568 addresses)
50.00000000 (in   40631 addresses)
 0.00000001 (in   35921 addresses)
 0.05000000 (in   22806 addresses)
 0.00100000 (in   22439 addresses)
 0.02000000 (in   18160 addresses)
 0.01000000 (in   13178 addresses)
 1.00000000 (in   11636 addresses)
 0.00500000 (in    9502 addresses)
 0.00000002 (in    7628 addresses)

The next 43 most common values after that were the 43 values from 3 satoshis to 45 satoshis, with between 5472 and 5799 addresses having each value.
I don't know what's special about 0.00000045 and not 0.00000046, but only one other value with a non-zero 8th decimal digit occurred in more than 25 addresses.  That was 0.00000703, which occurred in 101 different addresses.
I also found a bunch of weird looking addresses, which nobody will ever be able to spend from.  http://blockchain.info/address/871a40e5e61b96b6171f1b435788082edadda7a8 shows a lot of transactions sending tiny amounts to human-readable addresses, spelling out paragraphs of text.
As of block 165643, from Mon Feb 6 2012:
        2 addresses have 6 or more figures (100,000 <= x):
            105,258.88 12WmWuSQCgpEkPQTZ4ABijQaz6TCV69ZpE and
            105,555.00 1933phfhK3ZgFQNLGSDXvqCn32k2buXY8a
       70 addresses have 5 figures (10,000 <= x < 100,000)
      740 addresses have 4 figures (1,000 <= x < 10,000)
    6,552 addresses have 3 figures (100 <= x < 1,000)
   66,118 addresses have 2 figures (10 <= x < 100)
   50,638 addresses have 1 figure (1 <= x < 10)
  459,006 addresses have a fraction (0 < x < 1)
2,411,568 addresses have 0 BTC

Excellent researchin. I would like to know how many addresses have more than 10, 100, 1000, 10000, 100000 and 1000000. This would be so interesting to know.

I just updated my answer to include those details.

Brilliant answer! Any chance you'd post your modified BitcoinTools script(s)? With a full GitHub repo we could suggest a push into the main codebase, but I'd settle for a Gist :)

For sure.  It's in a real mess at the moment, but once it's tidier I'll put it on github.

Is your code for generating this data available anywhere?

Reping on your code or updated stats

at the 28c3 conference, "bitcoin - an analysis" shows some data related to this.
http://events.ccc.de/congress/2011/Fahrplan/events/4746.en.html
http://media.ccc.de/browse/congress/2011/28c3-4746-en-bitcoin_an_analysis.html

Hi Harald, if you put the numbers in the answer instead, I'll give you an upvote. Just links are usually not good answers (since they might change, or break) but especially not when it is an hour long video that you have to watch in order to find the answer.

Just finished watching the video - the answer doesn't appear to be present anywhere in the video, although it does contain a large number of excellent statistics.


text:
Listtransactions in v. 0.4.0 - different behavior?
I upgraded to Bitcoin v. 0.4.0, and I think the way "listtransactions" works is different now.
Let's assume I have 10 transactions on my account.
Old behavior:
When I call
listtransactions account='', 1, 10

I get an empty list, and then when I call
listtransactions account='', 1, 11

it would wrap around and give me the first transaction
listtransactions account='', 1, 12

would give me the 2nd one, etc.
New behavior:
When I request a non-existent transaction (i.e. the "from" parameter is more than 10), I always get the first transaction.
Does anybody know if this is by design?

Yes, it was by design.  The old behaviour was accidental and was causing a crash in some situations.
Here are the full details:
In version 0.3.24, the 'from' parameter was simply passed into std::advance() to skip the required number of transactions.  If the value given was bigger than the number of available transactions, it would wrap around, due to how std::advance() works.  I'm not clear on whether advance() is defined to work like that, or if it's dependent on the particular implementation in the library your version was linked against.
Anyway, in version 0.4, the advance() function call was made conditional:
if (txByTime.size() > nFrom) std::advance(it, nFrom);

meaning to only skip some transactions if the number of transactions available is greater than the number you're trying to skip.
The change was made by Gavin Andresen on August 12, 2011 in response to a bug report


text:
boost::thread_resource_error
I am getting this error in the debug.log of bitcoind:
EXCEPTION: N5boost16exception_detail10clone_implINS0_19error_info_injectorINS_21thread_resource_errorEEEEE
boost::thread_resource_error
It happens every 2 to 4 hours, and I need to restart bitcoind.
What I do is I request recent transactions every 2 seconds, via json-rpc.
Does anybody else got this error? Is there a way of avoiding this error?
UPDATE:
I actually managed to figure out it is related to calling walletlock. Whenever walletlock is called (via json-rpc or command line, doesn't matter), a new thread is spawned and it doesn't die. Looks like a bug.

What is the exact RPC call you issue? listtransactions?

I actually managed to figure out it related to calling walletlock. Whenever walletlock is called (via json-rpc or command line, doesn't matter), a new thread is spawned and it doesn't die. Looks like a bug.

It seems to be an error from the Boost library that is thrown "thread-related resources cannot be acquired". You probably should contact the dev team about this error, from your description it appears to be a memory leak.

It seems like the problem is the walletlock method of the API.
Whenever it is called, a new thread is created and it doesn't die. Do you know where I can report this bug?

I`d submit it either here https://bitcointalk.org/index.php?board=4.0 or here https://github.com/bitcoin/bitcoin/issues or email the devs. Probably the second option is the best.


text:
Why the signature is always 65 (1+32+32) bytes long?
A signature created by the Bitcoin-Qt client can always be decoded (base64) to a 65-byte array. This array seems (according to https://github.com/bitcoin/bitcoin/blob/master/src/key.cpp#L217) to contain a header byte, a 32-byte R part, and a 32-byte S part.
I've extracted some (R,S) pairs from some ECDSA Signatures encoded in the DER format. I found that R and S are not necessarily of 32 bytes in size. They sometimes can be 33 bytes long. Could anyone tell me why the signature created by the Qt client is always 65 bytes, or whether it is OK to always convert both R and S into a 32-byte array? Thanks.

There are two different encodings used.
Everything in the Bitcoin protocol, including transaction signatures and alert signatures, uses DER encoding. This results in 71 bytes signatures (on average), as there are several header bytes, and the R and S valued are variable length.
For message signatures, a custom encoding is used which is more compact (and more recent) and supports public key recovery (given a message and a signature, find which public key would have created it). The code you're referring to in the question is for creating such signatures.
A correct DER-encoded signature has the following form:

0x30: a header byte indicating a compound structure.
A 1-byte length descriptor for all what follows.
0x02: a header byte indicating an integer.
A 1-byte length descriptor for the R value
The R coordinate, as a big-endian integer.
0x02: a header byte indicating an integer.
A 1-byte length descriptor for the S value.
The S coordinate, as a big-endian integer.

Where initial 0x00 bytes for R and S are not allowed, except when their first byte would otherwise be above 0x7F (in which case a single 0x00 in front is required). Also note that inside transaction signatures, an extra hashtype byte follows the actual signature data.

Thank you, Pieter! Now I understand why we can safely ignore the first byte in the 33 bytes cases.

Why are values above 0x7F in the first byte of R or S not allowed? Maybe something to do with DER? The signatures that are printing for me seem to have the 0x00 out in front of the R, S about 50% of the time, disjointly.

@StephenM347 If the first byte has its highest bit set (>0x7F), BER (of which DER is a specialization of) says that it is to be interpreted as a negative number. OpenSSL, knowing that signatures only contain positive numbers, ignores this, but this violates the specification. As of v0.8.0, Bitcoin Core requires strict adherence to DER for signatures, although anything that OpenSSL accepts is valid in the blockchain for now (although BIP62 proposes making it a network rule to require strict DER).

Great, thanks. Sort of wish Satoshi had just used data pushes for R and S on the stack rather than this whole DER thing, but what can you do! :)

Can you expand more on the custom format? I am trying to recreate the QT signing process. However, C++ is far beyond my understanding.

How about in Schnorr Signature, is both (R,s) values are included in the signature field

@CiscoMmu Yes, in BIP340 signatures the first 32 bytes are the X coordinate of R (and the Y coordinate is implicitly even), and the last 32 bytes are s.

thank you Pieter, I have been looking around for few days (i wonder why the Public nonce value did not mention anywhere), until I found it out that ECDSA signature actually consists of signature and Public Nonce. I assume it is the same with SCHNorr. that why I asked.

For reference, DER encoding is defined in ITU-T X.690 (part of ASN.1)


text:
Has anyone tried transfering 0.00000001 BTC (the currently minimum amount) successfully?
I did an experiment of withdrawing 0.00000001 BTC from MtGox. And this transaction still cannot be seen on http://blockexplorer.com/ after about an hour.

Concern solved, thank you everybody!
http://blockexplorer.com/address/1Mm1YSodmgoDEHEQtQaZLjBW8Nemje3kFw

Yes, I have successfully transferred 0.00000001 BTC (commonly referred to as a Satoshi) before.
What is possible within the scope of a MtGox withdrawal is another question entirely. MtGox uses a custom client and has a fee structure and other assorted math to contend with that may not allow for such a transfer at present. If your withdrawal has not appeared in Block Explorer you should contact MtGox support as it may reflect more on their modified system than the default behavior of Bitcoin.

Maybe you can link to that transaction as a reference?

The 0.00000001 BTC is received after five hours.

@ThePiachu Here you go, http://blockexplorer.com/address/1Mm1YSodmgoDEHEQtQaZLjBW8Nemje3kFw


text:
The change to the size of blockchain data files
The blkXXXXX.dat files in the new Bitcoin-Qt client (v0.8.1) are about 130MB each in size, while the old ones are about 1.9GB in size each. Does anyone know the motivation behind this change?

The blk*.dat files should be around 10GB of total size. Are you sure your client is fully synced?

@StevenRoose My client is catching up. I see many blk*.dat files being created now. Each of them is 134.2MB in size.

The reason is future pruning functionality.
Pruning will be implemented by simply deleting files (and related metadata in index databases) with only old blocks in them. Having smaller files means higher granularity in choosing what to keep or not.


text:
Is it safe to email an encrypted wallet to myself?
I'd like to setup an automated process to email my encrypted wallet to myself, so that if, for instance, my house burns down, I've got easy access to a recent copy of my wallet stored off-site.
I've seen this mentioned in a couple places as a method for backing up a wallet, but none of the more thorough security guides I've read mention this as either a good or bad thing to do.
So, is this a stupidly insecure thing to do, or a reasonable means of keeping a regular automated off-site backup of a wallet?

The wallet.dat contains not just encryption keys but addresses as well.  If you are using the encrypt feature from the Bitcoin client to encrypted the keys then mailed to yourself those keys in the wallet would be secure assuming you used a strong passphrase and that passphrase is not used elsewhere.
But the transactions in that wallet can be viewed by anyone with access to the backup file.

Thanks.  So, adding an additional layer of encryption, such as like this [ http://snippets.dzone.com/posts/show/341 ], would be beneficial before emailing the (now extra encrypted) file.  Except, to make it automated, the script would need to contain the plain text salt that was used for the extra encryption, so if someone got a hold of THAT.  I guess there is no perfect solution. All options have their pro's and cons, both in terms of security and convenience.

Create a public/private RSA key pair. Encrypt with the RSA public key before emailing. (You can use gpg to do this.)

@DavidSchwartz But then where would I securely store the private key to address the original scenario - "so that if, for instance, my house burns down?"  Email it to myself? ;-)

@JonGarvin You would memorize the pass phrase it was generated from, using a deterministic process so that you could regenerate the key given the passphrase. Alternatively, you would write it on a piece of paper (or print it in barcode) and lock it in a bank vault.

@DavidSchwartz I was unaware that it is possible to generate keypairs deterministically.

The SHA256 hash of any passphrase can be used as a private key with a corresponding public key and Bitcoin address. Note that security requires that an attacker need at least 2^104 guesses to get it and, ideally, 2^128.

You can trust encryption
If you encrypt anything using a strong key and a strong algorithm (e.g. GPG) then you can be sure that it will be beyond economical reach for anyone for a long time.
So, the general procedure would be

Encrypt wallet.dat with your long and complex passphrase (which you keep safe)
Attach the ciphertext output to your email
Enjoy the free offline backup service

Do not just attach wallet.dat to the email since it will reveal your transaction history and bind your public addresses directly to you thereby removing your anonymity.

Isn't the wallet.dat the ciphertext output?

Only if you use an ecrypted wallet. Not everyone has upgraded. See @Stephen Gornick's answer for more details.

You can also use hushmail.com for emailing an encrypted wallet file to yourself for backup. It is an added layer of protection and when utilized in this way, it acts as an online wallet accessible anywhere.

Instead of e-mailing it to yourself, why not send it through a cloud service such as Dropbox or Google Drive which connects through SSL by default?


text:
Underclock GPU Memory below "Recommended" Limits on Linux
I'd like to try underclocking my GPU Memory. Based on what I've read, this is frequently done to reduce heat without sacrificing hashrate, and can sometimes even boost the hashrate if done carefully.
I seems that those running on Windows have a tool called "Afterburner" that allows them to over/underclock beyond the manufacturer's recommended limits, without flashing their BIOS.
However, under Linux, aticonfig --odsc=XXX,YYY won't allow setting the memory clock any lower than the range displayed by aticonfig --odgc.  Other tools I've investigated, such as AMDOverdriveCtrl, appear to just be front-ends for aticonfig, and therefore limited to what it can do.
I've seen some mentions that flashing on a new third party BIOS rectifies this, but that makes me more than a little nervous, so I would prefer to avoid that.
Would someone please explain, either...
A) How to underclock the memory on ATI GPUs (6850 and 6950, specifically) on Linux beyond the manufacturer's recommended limits, without flashing the BIOS.
... or ...
B) How it's possible for tools running on Windows to have more control over the hardware than those running on linux. (This feels like a slap in the face to me.)

I don't see how this question would be Bitcoin-specific. You should try asking it on other StackExchanges.

aticonfig respects the settings set in your video card's firmware by your card's manufacturer (frequently, although incorrectly, called a BIOS). However, AMDOverdriveCtrl can clock memory down much farther, depending on the card.
Radeon 5xxx, 67xx, and 68xx series cards should be clocked down to 1/3rd of the core speed (ie, 750mhz should have a memory speed of 250), 69xx cannot clock down far enough to be worth it, and GCN (79xx, 78xx, 77xx) seem to have a limit of 150 mhz less than core (however, although it is not worth underclocking on 69xx, it is worth underclocking on GCN due to automatic memory voltage control done by the hardware/driver; on my 7950 @ 1125mhz, going from 1375 down to 975 dropped my GPU temps 3-4 degrees celsius).
5xxx and 6xxx series cards also have a problem where they will instantly lock up if memory speed is set between around 400mhz to around 600mhz (depending on core speed), so your mileage may vary as always.


text:
What will happen if I try to broadcast a transaction before the established locktime block height passed?
If someone send me BTC with locktime and I accidentally try to broadcast transaction before the established block height passed, what will happen?
Am I still be able to broadcast it after the established block height passes or it will be stuck in network?

The transaction will not be relayed across the network and it will simply be as if the transaction never happened in the first place.

Okay Andrew so the btc will just remain on sender wallet, right? (because they are blocked until specified block height mine but as I tried to broadcast that transaction before it happen transaction is invalid?) Thank you very much for help

Yes, the Bitcoin will not move.

This is of course assuming that your peers do actually discard the transaction (as Bitcoin Core does) and none of them hold onto it to rebroadcast it later when it becomes valid. It's unlikely, but you shouldn't assume it can't happen.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
12 word seed invalid
I tried to create wallet by mnemonic seed, this link explains how to do it.
I've created this sample:

use yellow direct rib grass uncle cinnamon country furnace endless book denial

Rules I followed:

The words are separated by a single space.
The words are all in lowercase.
The words are included in this word list

But https://iancoleman.io/bip39/ tells me it is an invalid mnemonic.

To create a 128 bits BIP39 mnemonic phrase, you need to:

generate the entropy
Let's take for example ae0d36b7fcfb6cfe599366ecd9411b62 which is the hexadecimal representation of 128 bits of entropy.

calculate the checksum by hashing the entropy and keeping the first 4bits (1 bit for 32 bits of entropy (128/32 = 4))
hash(entropy) = 9214b8501502213b6e1d67f4bed6dd216596c553f0a0618bbd63c1cc3d7db51e

Now let's keep the first 4bits which is '9' (1001 in binary)

append the checksum to the entropy:
ae0d36b7fcfb6cfe599366ecd9411b629
which gives us in binary:

10101110000 01101001101 10101101111 11111001111 10110110110 01111111001
01100110010 01101100110 11101100110 11001010000 01000110110 11000101001
(The binary string is split into groups of 11 bits (2^11 = 2048 and there are 2048 words in the BIP39 Wordlist))

convert each group of 11 bits to its corresponding word in the BIP39 Wordlist

For example, the first group: 10101110000 is the 1392th word on the list.
(starting from 0) => The word is 'puppy'
(10101110000 being the binary representation of 1392)

The last word is a checksum, i.e. it is computed based on the 11 previous words.
So you can't just pick any random 12 words. You can pick 11 random words and compute the last one -- although I don't know if there is an easy resource that would help you do that.
In any case, you really shouldn't do this with real money ever.


text:
Is golang's implementation of Bitcoin core sufficiently relevant to the original?
Is anyone familiar with btcd, the Golang implementation of a Bitcoin node.
Is it relevant enough? I read somewhere that they boast that it is an almost 1 to 1 mirror of the original C++ implementation, but does anyone have experience with this? Is it worth going through this implementation, since I'm not that familiar with C++.

Is it relevant enough?

It depends what your goal is. As an educational tool for someone more familiar with Go, sure. For running in production say with a Lightning node managing hundreds of millions of dollars, perhaps not. Or at least not without running Bitcoin Core additionally as a backstop. There have been examples in the past of consensus bugs in btcd and it doesn't have as much review and eye balls as Bitcoin Core say but it is one of the few alternative implementations that is maintained and continually improved.

My goal is to learn how Bitcoin "breathes" through it. That is, to know exactly what is happening at what moment and in what way (how validation is performed, forwarding of transactions, finding other nodes, even original bugs from the bitcoin core etc.), literally every detail. I would say that these are educational purposes, so would it be good for me to learn how to "breathe" and then go through the C++ implementation because it will be much easier for me? However, after you said that there are certain bugs, I would say that I will not make it through this implementation. What do you think?

@joke: The bugs are rare. For educational purposes btcd would be fine, it is well written code.

Thanks, so if I understand you correctly golang's implementation, we can say, full follows the original one. For example the ways in which other nodes are found are the same (there is no additional in core that does not exist in the golang version), the way of validating, for example, the segwit script is the same and so on?

@joke: The consensus rules (e.g. script validation) should be exactly replicated and if they aren't you should submit a bug report. Other rules e.g. P2P/mempool policy don't have to be replicated. I'd guess they are similar to Core's but you'd need to speak to a contributor on the project to confirm.


text:
What is the difference between reliance on miners on Drivechains and Lightning?
It's commonly said that the Drivechains proposal gives much power to miners and that they can steal money from these drivechains, but I keep thinking that if what they can do is to vote on which transaction will be able to spend from the hashrate-controlled escrow, then if a majority of miners collude they vote on a steal transaction, fine.
Now, a majority of miners can also steal the funds from Lightning channels they're participating in if they are able to spend an old channel state and don't allow the new state or the penalty transaction to be published in time.
Some differences between the two steal attempts are:

To steal on Drivechain the colluding miners don't ever have to orphan blocks.
They can steal all the Drivechain funds at once.

Are these the crucial differences? Do they make Lightning inherently safer than Drivechains? What am I missing?

A majority of miners cannot arbitrarily steal funds from a lightning network channel. Lightning's current incentives depend on the publishing and confirmation of penalty transactions-- miners are involved in this mechanism, but they do not have the capability to alter those transactions to pay out to themselves instead of the channel participants. Someone could still answer to compare the two, but it is worth pointing out that they are not similar in this way (risk of miners stealing funds).

I was considering the miner collusion as a channel participant in my hypothesis. Should make that clearer.

I would consider these two crucial differences, so I guess you answered your own question. I guess the more important distinctions, though, are about the systemic impact of both:
Firstly, Lightning can simply be done with bitcoin as it is (OK, we needed segwit, but we needed that anyway). So it would be hard to keep people from using Lightning.
Secondly, the risk of miners stealing bitcoins in LN channels is probably not a problem: LN deals with small amounts, miners would have to collude with one side of every channel they want to steal, and breaking Bitcoin's censorship resistance in order to steal some LN funds would be such a nuclear attack that it would probably tank price AND lead to a PoW change.
On the other hand, IIRC drivechains explicitly expect miner consortiums to steal funds in unpopular sidechains. Very different risk profiles IMHO.


text:
Would mining future bitcoins break Bitcoin?
Assuming an Bitcoin miner with very much hashrate (like Bitmain) would decide to mine "future" Bitcoin blocks and provide them within very short time to the network, would this break Bitcoin?
As I understand a block hash is generated from the version, previous block hash, the merkle root hash, current time, difficulty / target bits and the nonce. The Bitcoin network only accepts blocks for timestamp with max 2 hours in the future.
But what if a miner with that much power started mining for a future timestamp at which he assumes it would be possible for him to mine up to 2016 blocks (every block with a little increased timestamp) before the timestamp is reached. If this would be possible, the miner would only need to mine one more block when the timestamp is finally reached to bind the chain (the missing block for the previous block header hash) and could provide all his mined blocks a nearly one timestamp to the network. The target / difficulty the miner mines at would be a little be greater than estimated by him.
Wouldn’t the network increase the difficulty after this action by such an huge factor, that mining the next 2016 blocks would be nearly impossible?

As I understand the bitcoin hash is generated from the ... previous block hash, ...

So, the new block cannot be mined until the block it is building on exists. If a miner can mine so fast it does not have to wait to release blocks, it can just do so. The difficulty will then adjust.

sure, but couldnt the miner mine his future blocks each on his own blocks because no one else is mining in this future timestamp currently? only the block which must bind his mined blocks and the blockchain must be mined very fast..?

oh i got it, he could not even start mining - thank you :-)


text:
What would be the easiest way to test the submitblock method?
I'm constructing a customized miner, and I'd like to check if the submitblock method would work properly when connected to mainnet. What would be the easiest way of doing that using RPC calls and bitcoind?
Which alternate network (testnet, regtest, signet) would suit better for this kind of test? (I'd like to use something with a very low difficulty)
Should I try to remine the genesis block, or should I try to create my own blocktemplate to be mined? And how could I do this?

regtest is the test network best suited for this kind of testing. While it does still have a PoW requirement, the work required is basically negligible. It also does not do retargeting so the difficulty does not change. This allows you to create blocks at will. So you can use the regtest network option in order to test that your code is creating blocks correctly.

Should I try to remine the genesis block, or should I try to create my own blocktemplate to be mined? And how could I do this?

As all of the alternate networks available have genesis blocks, there is no need (nor way) to remine the genesis block. You should be creating new blocks that build on top of the existing chain. Since regtest is a local private network, all it has is the genesis block and you can add blocks on top.
You can either create your own blocks from scratch, or use the getblocktemplate RPC to get block templates that you can use. This will still work on regtest. The only caveat is that you need to generate at least 1 block after you start the regtest node in order for getblocktemplate to work. There is a generatetoaddress RPC built into bitcoind so that you can do that. This RPC will mine a new regtest block with the coins from the coinbase going to an address of your choice.


text:
How to protect against wallet theft?
Let's say I run a Bitcoin client on a computer (Windows, but the question can apply to other O.S.es too), and I want to make sure nobody steals it. I'm especially concerned about situations where someone gets full access to the computer:

The computer is in a company network where domain admins can do anything they want to it.
The computer is a laptop and gets stolen.
The computer has a problem and I need to bring it to a computer shop (or call in a technician) to fix it.
A trojan gets on the computer and instead of popping up random ads starts doing something much more useful and stealthy like looking for Bitcoin wallets to steal (somebody is going to create one of these sooner or later).

I'm assuming here that whoever gets access to the computer has full access to everything, even as my own user account, in the case of a technician or a trojan; no built-in O.S. security is to be trusted.
How can I be absolutely sure that nobody simply copies my wallet files, loads them somewhere else and steals all my Bitcoins?

Physical access:
Minimise your risk by using a deterministic wallet with Armory, and enabling extreme encryption and key stretching. The program will let you configure your wallets settings, and you can make it sting to the point of being completely ridiculous, seconds to open is enough to stop any attack on the password.
Malware
There is no protection against malware on a computer with a wallet. These exist already as pre-made tools, so it's hardly a stretch to think you might be infected.
Use a hardware wallet like the Bitcoin Trezor or a split-wallet with an offline portion with Armory.
In a split-wallet a computer is kept air-gapped and stores the private keys, and a separate one is used to manage the wallet. Transactions are ferried by USB drive between the machines, so the offline wallet is never at risk of compromise. This is the best option for storing large amounts of funds safely.


text:
Can Bitcoin scripting be used for double spending attacks?
A standard Bitcoin transaction deposits coins into an address and then, using Bitcoin's scripting language, states that whoever wants to spend this output must be in possess of the private key corresponding to that address.
However, it's possible to deviate from this base template to create more complex transactions, where other conditions must be met in order to spend the transaction output.
Is it possible to create a transaction where a sum is deposited into an address, but only the owner of another private key is allowed to spend it? I'm not a Bitcoin scripting expert, but this looks at least possible.
In this case, can such a crafted transaction be used to mount a double-spending attack, where address A sends sum X to address B, but after the transaction is completed address A retains ownership of the sum and can send it elsewhere, while address B can actually do nothing about it even if the sum is credited to its balance?
How would a standard wallet treat such a transaction? Would it even recognize there's something strange going on, or would it blindly display that X BTC entered address B, regardless of the transaction script?

Edit:
Sorry, I was misled by how sites such as blockchain.info display transactions: a transaction doesn't actually contain any "output address", it only contains outputs which state the conditions necessary to spend them; the "output address" is computed by checking which address's signature is requested by the output script; thus it's impossible to "send money to address B" without actually placing address B in the output script.
However, the question somewhat remains: could a transaction be crafted to fool a wallet into telling its user "I received X BTC" while someone else can actually claim the sum using another private key?

Please note that the transaction as I described it is crafted so that B has no right at all to spend the sum; a more complex transaction could instead allow both B and A to spend it.

Ok, that wouldn't work (see edit). But maybe something else would...

What you're describing is a contradiction of terms. If a sum of money is deposited into an address, that means that only that address's private key can spend the money.
Maybe you could craft a non-standard transaction and tell people it's giving address B's owner permission to spend it, but if people look closely enough at the transaction, they'll be able to tell that it's really address C (and not B)'s owner that can spend it. There's no way around this: the transaction output is public, as is the implementation of how it works.
So if the question is: can you fool software X with a non-standard transaction? Perhaps, it would depend on finding a bug (or other less-than-ideal situation) in the software in question. (for example, if you craft a transaction that can be spent by address B or C, maybe the wallet owning B will say it has the balance, and if he doesn't transfer it again before you do, then you can "steal back" the money that way) However, I'd treat any non-standard transactions as highly suspect.

Agreed (see edit). However, the question stands: how do clients react to non-standard transactions? How does f.e. the reference client go from "a transaction's output script" to "hey, you just received 42 BTC"? Could it be tricked by something like this?

No, you won't fool the standard client with this. If it does not understand the script completely (i.e. it is a nonstandard script), it does not try to parse it partially or whatnot. The procedure is simple: if the client can't understand the script completely, it is simply ignored. Period.

Any reference for this? What types of transactions are considered "standard"? Who decides if a transaction is a standard one? How can you even get a nonstandard transaction mined into the blockchain if the reference software simply ignores it?

There's a protocol and then there's the reference implementation and other implementations as well. While the protocol is stable, implementations are not and some features are adopted more quickly in some clients. The same goes with the policy of relying trx - different implementations have slightly different rules when it comes to decisions about relying trx. What is a "standard" script depends on the client, but generally it is a script that requires valid public key and a signature. More info here.

see https://github.com/bitcoin/bitcoin/blob/6513a9f7033737458735305a08606280d6d0d33c/src/script.cpp#L1203 (function solver) - even if you don't know programming, those four lines should be clear enough, and they contain the four standard transactions. The future bitcoind versions will allow for any other txs to be standard ( https://bitcoin.stackexchange.com/questions/28181/what-new-transactions-are-possible-with-15-operations ), but still - the clients/wallets look at the whole tx to compute the bitcoin address.


text:
How the hell was I able to receive BTCs via an address I do not own?
A few minutes ago I received 0.00000001 BTC. I don't know who sent them or why.
But what makes it crazy is, this sum was sent to an address I do not own and which the client I'm running (the standard Bitcoin-QT, versione 0.8.5) had never heard of before. I know this for sure because I only created 2 (two) addresses using this client, and the receiving address of this transaction is not one of them.
How is this possible at all?
Is it a hash collision, or what else?
The address is 1Cz2AmLe8U52KR549d13JQkqsqkV64RchB and the transaction ID is b9591410ff030e40deb3eda9d2fe30a29642ede443f354bb5f4ed5bb55f0d36d.
According to this page, the address seems to have received money a little time before from 1HTawQNCS4axPXft6L6fkzrv5ya7TguqwD, which actually is one of my addresses; the last two transactions are me sending all my BTCs to a new address, just to be sure. This worked, so it looks like I'm actually the owner of that address, even if my client doesn't list it as one of mine.
What's exactly going on here?

Are you involved in a mining pool? You may have received a proportion for your work

I actually am, but the pool doesn't make such small payouts. And still the main question remains... I don't own that address!

Satoshi was clever. Change addresses add an extra layer of anonymity. The bitcoin-qt wallet GUI doesn't have any indication that they exist, however. This might be for simplicity's sake.

Yes, Satoshi was clever, but you mean "anonymity" with quotes.  It's possible to trace money in Bitcoin with a reasonable confidence level.

As Murch says one possibility is that this address is in your keypool. Another is that this is a change address the client created. If you're willing to share the relevant transaction we may have more to say.
Owning an address means "being in unique possession of a corresponding private key". It's difficult to know if you're the only owner, but verifying you have a key is easy - ask bitcoin-qt to sign a message with this address.

Question updated. And yes, it looks like that address actually belongs to me...

Ok, I've looked up change addresses (https://en.bitcoin.it/wiki/Change), and it looks like it's one of them, and it's normal to not see it in the client GUI. But why did I suddenly receive 0.00000001 BTC on it? Who sent them and why?

@Massimo: This is indeed a mystery, but once this address received change it is publicly visible and anyone can choose to send a satoshi to it, for whatever reason. Bulk sending of satoshis to random addresses has been observed before.

@Massimo: Looking at the transaction, it seems to have come from an address associated with "LetsDice.com". Have you used that service? Perhaps you sent them funds from the change address, and they returned coins to it to carry some information (they could also send payment for winnings to that address, but 1 satoshi doesn't seem to be it).

Never heard of that service before... and the change address was created only a couple of hours before receiving that satoshi. Also, I received ANOTHER satoshi from the same address on the new address I started using soon after. Maybe someone is sending satoshis to any new address it sees on the blockchain?!? I'm puzzled.

@Massimo: Some people do weird things.

@Massimo: Actually, this tx is probably an advertisement. Note that there's also a public note on blockchain.info advertising their site.

Check if that address appeared on the blockchain before that mystery payment.  If it does, they could have gotten it from there.  Also if you used it as a change address for a payment to someone, maybe you overpaid and they are refunding your overpayment (possibly in an automated process)

Bitcoin-qt has always at least 100 unused addresses in store. You probably received the payment to one of those.
If it were a hash collision that would very disconcerting, it might indicate that there is also trouble with the randomness in the standard libraries used by bitcoin-qt.

But even if this is the case, I don't know them and never told them to anyone...