Bitcoin Forum
September 21, 2017, 11:26:01 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Double-spending technical question  (Read 981 times)
Disposition
Full Member
***
Offline Offline

Activity: 122


View Profile
August 04, 2011, 06:55:09 PM
 #1

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
August 05, 2011, 03:00:37 AM
 #2

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
August 05, 2011, 03:17:58 AM
 #3

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.

Disposition
Full Member
***
Offline Offline

Activity: 122


View Profile
August 05, 2011, 03:35:12 AM
 #4

@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.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
August 05, 2011, 03:53:51 AM
 #5

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.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Disposition
Full Member
***
Offline Offline

Activity: 122


View Profile
August 05, 2011, 12:39:15 PM
 #6

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!
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1050


View Profile WWW
August 05, 2011, 12:41:10 PM
 #7

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.

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...

aka sipa, core dev team

Tips and donations: 1KwDYMJMS4xq3ZEWYfdBRwYG2fHwhZsipa
JoelKatz
Legendary
*
Online Online

Activity: 1582


Democracy is vulnerable to a 51% attack.


View Profile WWW
August 05, 2011, 01:57:29 PM
 #8

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.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
August 05, 2011, 03:18:23 PM
 #9

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...


Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Disposition
Full Member
***
Offline Offline

Activity: 122


View Profile
August 05, 2011, 07:52:20 PM
 #10

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
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
August 05, 2011, 08:01:56 PM
 #11

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

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!