This is basically a movie plot, but not one good enough to get made into an actual movie.  Also, it comes up every few weeks here on the forums.  You people gotta learn to search.  If we stickied every topic that was popularly assumed to be a new thought by each person, the real threads would start on page 23.

You will notice that no one is seriously worried that someone is going to buy all of the world's gold and drop it into a subduction zone in the ocean, removing it from circulation forever.  The first problem with this movie is that the concept of "buy all of the world's X" doesn't work, for pretty much all values of X.

And no, collecting transaction fees is not different from buying, in this context.  No one is ever going to pay more than a small percentage as a transaction fee for anything but a trivial transaction, so the most you can get in one iteration is a tiny fraction of a small percentage of all bitcoins, so you need to keep iterating over and over again if you want to collect a lot.  But, each batch that you remove from meaningful circulation makes the rest more valuable, so the average transaction size will go down over time, as will the fees people are willing to pay.

The same happens when trying to buy.  Buying 1% of all bitcoins today would not be too hard.  But you'd exhaust the willing sellers in a hurry after only collecting a small fraction.  This will drive prices up, which will entice more bitcoins onto the market.  But you are still shaving tiny portions off, and each slice costs you more and more.

Now assume an attacker with no budget, like congress or the fed, entities that can literally create money out of thin air.  They could afford higher and higher prices, or smaller and smaller fees for a long time.  But each batch they do makes their own money worth less and less, while it makes ours worth more and more.  At some point, the trillions of dollars created would finally tip the scales of credibility, and the fake money's value would crash, with consequences apocalyptic for those that survive solely by trying to boil the frog too slowly for it to notice.

p2pool.info isn't measuring your hash rate, it is estimating it from a random process.  Variations in that process lead to variations in the estimated hashrate.  p2pool.info has to rely on actual shares, so the variance there will be much higher than your local estimates, which are estimated from pseudoshares.

Using a single key means that every single transaction you ever do it absolutely linked.  With random change addresses, there is sometimes a little linkage, but it isn't as easy or as automatic to track you.

This sort of question keeps coming up though.  I may create a key disposal service to meet the need.

Keys aren't very big.  There isn't much cost to keeping them around forever.

On the other hand, if you delete one, and then the person pays, the coins for that payment are lost, not just to you, but to the entire world until the end of time.

This message usually means that you are running on a VM.

Unhiding change would not in any way reduce confusion.  It would just trade the current questions for new different ones.  Plus, it would make the default to spray information around the network.  Not a good trade.

BTCGuild did merged mining on the old getwork servers.  His implementation of stratum does not do merged mining, and I think he is busy enough with other things that he isn't going to bother adding in something that apparently very few of his users care about.

In both cases, every party produced $10 worth of value, and consumed $10 worth of value.

In the first case, there is only one person, and that person created a $10 lunch, and then consumed it.

In the second case, you have to keep in mind that the chain is infinite in both directions.  You got the $10 from someone by trading a similar value for it, and they got it from someone else by the same system, and ditto for the lunchmaker, and the person the lunchmaker trades with forever into the future.

The chain is also virtual, since commerce is really a web, not a chain.  A few threads may break, but the overall web goes on forever.

Money is just a way to virtualize barter.  Rather than trading wealth for wealth, you can trade wealth for a claim to wealth, and later redeem that claim.  Now virtualized, trade no longer needs to be atomic.  The giving and the receiving can now be done at different times, and between different parties.

Of course, this is just a metaphor.  Trade is still atomic, you still give and receive at the same time, and with a single party.  But the widespread acceptance of money allows you to act as if the metaphor was real.

The confusion comes in when two distinct concepts have the same name.

"private key" can mean either the raw 256 bits used to calculate the signature, or it can mean the encoded format that bitcoin stores.

Public key can also mean either the (x,y) point used to verify signatures, or it can mean the encoded version that bitcoin uses.

In the raw sense, both private keys are the same, and both public keys refer to the same (x,y) point.  In the encoded sense, the compressed private key encoding implies the compressed public key encoding, and ditto for the uncompressed encodings.  The addresses are hashed from the encoded forms, so there are two different addresses that technically refer to the exact same keypair.

Since bitcoin deals exclusively with encoded versions, the two formats are totally distinct different things.  If you generate your own raw private key, you can create both encodings and calculate both addresses.  Import the two encodings into different wallets, and neither one will have any idea about transactions sent to the other.  Even though they could calculate signatures for both, they don't know to look for them.

The files have a loose format.  The files contain blocks (magic number, size, data), essentially the same format as the block network message.  The files should not contain other data, but all parsers should be careful to discard anything that isn't a valid block.

The data part of a block includes the header, a transaction count, and then transaction data.

All of this is on the wiki.  Start here.  Don't miss the link near the bottom.

Less powerful, actually.  Not to mention needing to upgrade the entire network every time someone needs a new transaction type.


Argh.  It is absolutely NOT the address that the coins came from, because there is no such thing.  If you want to argue about an imaginary system that we could have some day in the future, then in that system it could be a return address.  In the actual real bitcoin of today, there isn't one, and people should stop pretending that there is.

In bitcoin, you know if a payment happened.  You don't know where it came from, or who it came from.

So...  How do you handle coin creation?  How do you keep miners from ignoring all chains other than the one with the most available fees?

I'm handwaving the problems of figuring out which chain you need to look at to see if a transaction is valid, but that doesn't seem to be solvable either.

There are serious issues with such a model.


True, but he gave you that address, so it is up to him to keep the key safe.  If you decide on your own to send coins to a random address, that would be different.  A judge would be able to see the difference immediately.  Would you pay a bill by mailing cash to an address that "you think" the biller owns?  Why would you send bitcoins to a pubkey that "you think" someone might own?


You may have missed it, but I've already agreed in this thread that if you want to assume a bunch of stuff that isn't necessarily really true, you can get away with a lot of stuff.  If you don't assume, and confine yourself to what really is, then you have to accept certain limitations.

You should really go back and read page 1.

Scripts are there for a reason.  We rely on a small number of standard types right now, because they are hard to handle safely.  We need to take some time to learn how to work with them, and we will.  What we have now fills a lot of needs, but not all of them.


For case #1, the signature could be computed with a key that is now lost.  A new transaction would not have the same signature.  There are good reasons to never destroy keys, but as a recipient, you have no guarantee that the key to a previous transaction output still exists.

For case #2, the script could be a hashing puzzle, or some other device intended for a single use only.  The solution may become public when used, and thus anyone could collect repeats.

Case #3 is the usual case, using ECDSA where the key is retained forever.

Makes sense.  Their whole reason for existing is to regulate derivatives.

But this is my favorite (quote from the article, not from Chilton):


Plenty of people on these forums would argue that the infrastructure mentioned, which is indeed quite real, does not exist to prevent "volatility, fraud and other malfeasance", but to concentrate that malfeasance into the hands of those blessed by the state.

Fortunately, bitcoin is "based on" math which will confer no such blessing on anyone.

I'm glad you brought this up.  The bitcoin system itself has no addresses.  There is no "address" field in a transaction.  The address is a metaphor that we use to make it easier for humans to interact with the network clients.  If I give you an address, and you then "send coins to that address", what really happened is that your node is using a standard template to create a script based on the hash value encoded in the address.


Well, sorta.  Depending on the script you are looking at, there are three ways it could go.  Case #1, no one is capable of redeeming the new transaction that you make.  Case #2, anyone is capable of redeeming it.  Case #3, one person (or group or whatever) is capable of redeeming it.  The system does not provide enough information in-band to distinguish the three cases.

The only concept that is universally meaningful when receiving a transaction is whether or not you received it.  If you need to make refunds or returns, you need to collect that information outside of the bitcoin system.

In doing so, you have redefined "from" to mean "the last address that it was sent to".  If muddling the two concepts works for you, then enjoy, I guess.

However, when people come here asking this question, they are trying to do something.  The something that they are doing is dangerous, and never the correct way to solve the (real) problem they have.  Typically, what they really want is a return address.  Bitcoin has no such concepts.  There is no return address, just like there is no sending address.  People working with bitcoin need to accept the system as it really is, not the way they want it to be.  They can choose not to, as you have, but they do so at their own peril, and I won't encourage them down that road.

Bitcoin transactions connect other transactions to scripts.  They do not connect addresses to addresses.  Just because you can sometimes (or even usually) find an address that controlled a now-redeemed transaction does not mean that the new transaction came from that address.  There is no general solution, because the concepts simply do not exist in the system.

Do you understand that?  You are finding things that exist in some transactions that have properties similar to the thing you are looking for, and you claim that they are the thing you are looking for.

What address did this little guy come from?

-rescan reads the block chain and adds any missing transactions to your wallet's collection.  It does not remove anything.  Actually, there is no mechanism in the standard client to remove transactions from the wallet database.