Bitcoin Forum
December 08, 2016, 06:19:24 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Are transactions bound to a specific block or can they be applied to any block?  (Read 679 times)
gst
Jr. Member
*
Offline Offline

Activity: 38


View Profile
June 21, 2011, 08:13:39 PM
 #1

Let's say I have a fork of the blockchain into chains A and B. My client currently only sees A and I submit a transaction.

Would it now be possible that someone else also applies the same transaction to B? Or is the transaction somehow bound to the chain (e.g. by specifying the hash of a chain block that must exist before the transaction is considered valid), so that a transaction submitted for fork A is invalid for fork B.

The reason why I'm asking is that some "Bitcoin banks" seem to only credit received coins after a given number of blocks have passed. If it would be possible to bind a transaction to a specific block chain (e.g., by specifying a required "previous" block) one could avoid this problem, by instantly crediting received coins, but by binding newly sent coins to the same fork of the chain where the previous coins have been received.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
June 21, 2011, 11:45:14 PM
 #2

The correct chain is the longest one (the one with the greatest embedded difficulty, but it is usually the same thing).  In the case of a tie, the provisionally correct chain is the fork you saw first.

Eventually, one or the other will win.  Even if exactly half of the network considers each branch to be provisionally correct, it is very unlikely for both halves to find a valid continuation at the same time, so one fork will be longer.  A single block fork is unusual, but happens every few hundred blocks.  A two block fork is rare.  I don't think we've seen a three block fork yet.

When that happens, all transactions from the blocks that became invalid are reversed, and added to the pending transaction pool.  If a transaction is no longer valid because it attempts to re-spend previous transactions that were already redeemed in the winning chain, that transaction will not be accepted.

That is why people wait for several blocks to pass before they consider a transaction to be really confirmed.  The deeper it is into the block, the harder it will be to reverse.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
JoelKatz
Legendary
*
Offline Offline

Activity: 1386


Democracy is vulnerable to a 51% attack.


View Profile WWW
June 22, 2011, 12:35:26 AM
 #3

The reason why I'm asking is that some "Bitcoin banks" seem to only credit received coins after a given number of blocks have passed. If it would be possible to bind a transaction to a specific block chain (e.g., by specifying a required "previous" block) one could avoid this problem, by instantly crediting received coins, but by binding newly sent coins to the same fork of the chain where the previous coins have been received.
That wouldn't solve the problem. Even if you specify a required previous block, there is still no way to know whether the subsequent block that contains this transaction will "win" until sufficient blocks have passed.

In fact, this would make things worse. In the present system, if the block containing the transaction doesn't win, at least you can still perform the transaction if the sender hasn't maliciously attempted a double spend. With your scheme, if the block containing the transaction doesn't win, there is no chance to still perform the transaction.

I am an employee of Ripple.
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
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!