Bitcoin Forum

Say I'm running a client, and I have 1,000BTC, and backup my wallet.  Then, I use the BTC to buy something.  Then, I re-copy my wallet, and my client assumes I have the 1,000BTC again.  Of course, if I use these coins again, the network will reject my payment.  On what metric does it make the decision that I no longer own the coins?

The network will see that there is a previous recorded transaction where you transferred those coins to someone else and so it will know you don't really have them.  Therefore it will reject your second transfer as invalid.  This is also how the network protects against someone just editing their wallet.dat file to give themselves a bunch of coins.

By the way, I don't suggest trying this as someone posted in another thread that they tried a similar thing as a test and ended up losing a bunch of coins in the process.  The network will not punish you for this (i.e. he did not lose his coins as a punishment) it was just some weird interaction between the client and the wallet file (the exact details elude me at the moment).

-Buck

you can try this without any fear.
afaik that person lost it's coins by overwriting the wallet-file at some point (simply do a backup first!), not by trying to double-spend coins.

I'm not trying to re-spend coins.  However, I do have another question.  What, precisely, constitutes a "coin?"  It was said...

What form is this record, wherein the network denotes that I have transferred these coins?  Is this what a "coin" is?

Have a browse around the wiki: http://www.bitcoin.org/wiki/doku.php?id=bitcoins (http://www.bitcoin.org/wiki/doku.php?id=bitcoins)

From the wiki, "a coin is a number associated with an address."  Fine, but this doesn't answer my question.  What form does the record by which you verify that an individual who has spent a coin no longer owns it take?  Is it simply the latest associated address?

If that coin is one of the inputs to a later valid transaction, then it is spent and cannot be spent again.

That later transaction is the record that somebody spent the coin; it is signed with the private key, and that key (which Bitcoin keeps for you in your wallet) should be known only to the owner.

"That later transaction is on the recor that somebody spent the coin; it is signed with the private key..."

So, the chain contains a full history of transactions, and a coin's current owner is determined by all nodes as being the last signature in the chain associated with a coin.  Am I reading this right?

Yes.  Whoever has the private key that can create that last signature can spend the coin-- he or she (or them-- eventually maybe as bitcoin clients add features) are the owner.

The transaction history isn't exactly a "chain" -- multiple coins can get combined as input to a transaction (they're all "spent"), and multiple coins can get produced from a transaction (they're all "unspent" until they're used as the input to another transaction), so it's a more complicated network (I think of a chain as one link followed by another in a straight line).  But it will all trace back to one or more 50 Bitcoin GENERATE transactions.

If the chain has a full history of transactions, including the most recent owner, then why can coins not be recovered from the chain?  Say my wallet gets wiped - the chain still knows the ownership of my coins is with me.  I suppose my key would have gotten wiped as well, and then I couldn't verify that I am in fact....me?

For that matter, if the ownership of all coins can be derived from the chain, what is wallet.db besides a person's key?  Why not just store the keys, and derive coin ownership while online?

This on-the-chain identification of ownership could provide a solution to the deflation problem - if its a problem at all.  If a given coin's final client had not been seen in....five years, say...then the individual is obviously not using bitcoin for monetary purposes, and the coins associated with that key could be liquidated and put up for generation once more.  Of course, that deflation is a problem at all is very suspect, especially given what I've recently been told about how precision can change.  However, I'm just thinking though technical options here.

Additionally, could people use keys not generated by Bitcoin?  For instance, I have a PGP key with which I sign crucial files, and this key is backed up to the n-teenth time on any number of media.  If I could use bitcoin by simply inputting this key into the software, and then the software could derive which coins are mine from the content of the chain, it would make losing access to coins far more unlikely.  Obviously, switching keys would be akin to switching wallets.

The block chain can verify that the "coins" belong to a certain private key. If you've lost the private key you've lost the ability to transfer the coins and hence the ability to spend them hence they're not "yours" anymore. The whole idea of "coins" is a fiction to make the system more easily understandable. The system simulates the expected behaviour of coins. A coin is more accurately the expectation of the success of a mutually agreed value transferring transaction. If we mutually agree to invalidate certain transactions or similarly validate certain non-standard transactions then we can manipulate people's "balances" arbitrarily.


Nothing unrecoverable apart from the secret key.

This is what happens.

You misunderstand how coins work. The fact that the number of coins is limited is something that is mutually agreed by the software. The fact that block generation "creates" bitcoins is something mutually agreed by the software. There's no mathematical basis for any of it. If you change the software to interpret the block chain in a different way and to validate transactions or calculate balances in a different way, as long as everyone (or nearly everyone) agrees then hey presto! that's the way it is.
This could be done if we change the software and convince everyone to use the new version.

ByteCoin

Not necessarily.  The key is used to sign the coins, and right now it's generated by the program.  The REST of the program, however, doesn't care where that key comes from.  I could write a custom client which accepted keys from the user, even if noone else did this, as it would just look like the program happened to generate that key for me.  It would count as a new user, with a balance of 0 (aka, you couldn't "reprogram" your wallet to accept a different key, you'd have to make a new wallet, and send the coins from the old wallet to the new, so that they were signed by your "external" key.

Ooops! Yes! You're quite right if the PGP key is compatible with the key type used in BitCoin. I still associate PGP with RSA and I believe BitCoin uses ECC so I was thinking you'd have to update the software to understand RSA keys.

A production version of BitCoin will probably have to accept a number of different Public Key algorithms.

ByteCoin

Right, I thought we were talking about a private key that was the same type as the client (and assuming the client uses some known standard).  Obviously it wouldn't work if you were to provide an unrecognized type. =P

However, changing the client to recognize multiple types of PKA's WOULD most likely be a breaking change, unless satoshi is including some kind of version information about what keys were used in the block chain.

Actually, you can lose coins this way. Consider - you have 2 BC (as a single coin) and spend 1. Now you have 1 BC as a single coin with a new private key. If you restore the old wallet.dat, your new private key is gone. Once the client realizes the 2BC coin was spent, that coin is deleted, and you're left with 0BC.


It would probably be easier to add a extension field to GPG to list bitcoin addresses. Note, however, that the destination address (actually, the signature acceptance script) is visible to everyone, so it would be a very public transfer.

That said, however, there is support for partial signatures. That is, you can create a transaction from yourself, with a signature that excludes the destination fields. Now you just encrypt that, email it to the recipient, they add on said destination fields, and there you go. This, however, has the issue that other nodes can _also_ modify said destination fields, and the first one to get in the block wins. I'm not sure if there's some clever fix satoshi had in mind for that...

bdonlan:  Actually, I was trying to figure out how to do that very thing, put a coin in "first come first serve" mode, for transfer onto a flash drive or something.  Can you post more detailed information on how You'd go about doing that?

I'm quite aware that "coins" are not coins, but validations for a magnitude of transaction.

So wallet==keyfile, and nothing else?  Good, that's appropriate.

Take a look at the SIGHASH_ANYONECANPAY value for the SIGHASH enum. As far as I can tell, nothing generates hashes using anything other than SIGHASH_ALL yet. That said, I'd want satoshi to weigh in on the intended use of this; the only secure way of using this AFAICS is to integrate such a transaction into a block of your own creation.