Topic: Double-spending technical question (Read 1138 times)

Well, now there's a use for my first post:  the invalidated transaction will happen as soon as the first block is produced that has one of them included.  If 90% of the world sees TxA first, and 10% see TxB first, there's probably about 90% chance that TxA will end up being the valid one.  But regardless of the ratio, that will happen on the next block... so 1-20 minutes (dependent on global luck), for the network to "agree" which one is valid.

I suppose it's possible to end up with both blocks being solved at the same time, then you end up with another race to see which block is valid, in the exact same way there was a race to see which Tx was valid.  But that's a boundary case, and it really only extends the validity "agreement" for another one more block. 

To be more direct... once you get that first confirmation, the invalid Tx is purged from the network pretty quickly.  I don't see why there's a problem getting the client to figure that out, too

Yes, I'm greatly interested in this as well. while we all would want to generally avoid spending the same coins, it is still possible that we do and during design phase I foresee this as an problem so I bought it up hoping for some type of solution.

I suppose the real question is if two people spend the same coin, assuming there's no other network and node type of attack involved, how long does it take for the bitcoin network to valid one transaction, therefore invalidating the other one? how SHORT can this be? 1 confirmation on a transaction? or is it something else completely. I also feel like I'm missing something.

@etotheipi

I see your reverse problem, I think that could be solved using a ping back from the blockexplorer to update the true value of bitcoins associated with the address, which is something the client currently doesn't have but shouldn't be too hard to add.

Cheers

I get it.  Using wallets on multiple computers are not handled well with the current client.  But I don't see why this has to be a problem.  The client can easily check each of its "0/Unconfirmed" transactions to see that they are permanently invalid.  Why isn't it a simple patch to resolve this issue?  Is there something I'm missing?

On the other hand, I have the opposite problem, now.  0/Unconfirmed transaction for months that is sitting there solely because because I didn't include a transaction fee (to see what happens, now I know).  My client claims I don't have the money, but it was also never officially spent.  I need a method to "pre-spend" this money by using the same TxOuts in a new transaction that will get handled.  It won't fix the client (in fact, what will the client do??), but at least I'll get access to the money again.  I'm very tempted to apply my python tools to find the relevant TxOuts, and manually construct a new Tx broadcast...

As a general rule, you want to avoid the case where two parties have the ability to spend the same coins unless one is just acting as an emergency backup to prevent loss of the coins. There are just too many possible race conditions.

The problem is that the network doesn't think of coins as belonging to an account. So even if you and I both have access to the same account's 100 coins, if you and I both go to spend 5 bitcoins each at around the same time, we will likely conflict.

It is possible - i implemented a proof of concept for this some months ago (seemy rejectedtx branch on github, pull 195). It marks wallet transactions which depend on inputs spent by other transactions that are in the blockchain as inactive.

It takes more time to get it in a mergable condition though...

wait so you mean it days a "day" technically to verify the validness of a TxOut? I thought whoever spends it first gets confirmed by a block first, which is in around 10 minutes?

now is it possible to write a custom client of sort to check against something like this? so the service will continue to function without it's biggest draw back which is double spending.

e.g.
A loads address pair to said SERVICE, how can and when can the service know the coins are valid? soon as 1 confirmation comes? or can it wait a certain time until it knows there has been a double spending that had happened and make this transaction invalid?

while I just realized this doesn't affect this services at all since in theory person B just won't get paid, but users would still able to send coins via this service online with little information as the key pair and only expose very little information to a third party, which was the whole goal.

but it'll be an interesting answer to get for the concept, how does/how fast can clients detect double spending attacks, or become aware it self has become a victim of a double spending attack.

cheers!

So, why can't the client see that the transaction is invalid and remove it from the list (or tell the user it's invalid)?   After all, the fact that TxOuts have been used is easily verifiable. 

Say, once a day, the client will scan the block chain for invalidating information about all "0/Unconfirmed" transactions in the wallet.  If there are Tx's that use the outputs, that Tx can never be valid again and the user should be given some indication as such.  Even if the Tx is technically still valid, it might be worth giving the user some feedback that it's still valid, just not handled yet.

@etotheipi,

Thanks I understand how conceptually it works, I'm just wondering if the client and/or network will throw some sort of notification/error for B.

@Maged

damn I was afraid of that.

I guess I should elaborate a bit. I was thinking of writing a front-end service to a node where you input both the address and the private key to spend just those coins linked to that address, much like a wallet except the server will never have access to the coins until you give them access. another idea is to maybe send the remaining coins to another adress(which is secure) so at most the "evil" server can only steal w/e address/key pair you share to them.

Thanks for answer! also if anyone have idea and thoughts for said above I'd love to hear.

The client will currently just show it to be forever unconfirmed. That is one reason why we highly discourage using the same wallet on more than one computer at once.

I just realized I answered a question that you didn't ask.  Whoops!  Well hopefully you at least learned something from it!

I'm not sure what the official client would tell the users, but I can tell you what would happen in the network:

(1) A and B both broadcast transactions at the same time, using the same previous transaction "outputs" (you have to reference previous transactions to create new ones)
(2) Some nodes get word of TxA first, other nodes get word of TxB first.  Whichever one they get first they will add to their queue and start trying to include them in a block
(3) When nodes get word of the second Tx, they will reject it because it conflicts with the first.
(4) The next block that is generated will include TxA or TxB, but not both.   Let's assume it's TxA.
(5) The miners working with TxB will receive word of this next block, and switch to mining for the new one.
(6) They reconstruct the block, but realize that TxB is no longer valid because TxA (in the prev block) already used up the transaction outputs.
(6) TxB will be removed from the miner's Tx pool and never considered again.

So to answer your question more directly:  one of the transactions will go through, and the other will be rejected.  No one knows which one until the next block is generated.  The probability that one wins over the other depends on what proportion of all miners receive TxA first vs those that receive TxB first.

Let's say in a scenario where A and B both spends the same coins. and A is faster(earlier time stamp, assuming no block based attack were also executed.)

What would B see? say in his client for example, what indication would the bitcoind give to B that the transaction failed, would it not confirm? or will it say something else.

Thanks!

p.s.
feel free to talk about other double-spending related things in this thread.