1

On page 2 of Bitcoin paper, it says:

The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. [emphasis added] The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

Why does only the earliest transaction matter for double spending? I thought that it would be latest as previous owner would have checked till that. But even that is flawed... We need to check all.

Is it because the coin is a list of transactions and only first one is not verified?

3

"Doublespend" refers to an attempt of spending the same funds twice. In Bitcoin specifically this occurs when a user publishes two transactions that are in conflict due to attempting to use the same unspent transaction output as input. Obviously, only one of the two transactions can be valid.

Before Bitcoin was published, the solution to the doublespending problem was to designate a central actor that decided which of the two transactions would take precedence. The central actor would do this by announcing which of the two it had seen first.

The "first-seen" behavior was at first explicitly encoded in node behavior: nodes would not accept a conflicting transaction into their mempool (the temporary storage of unconfirmed transactions). However, this lead to the incorrect assumption that zero confirmation transactions could be reliable whereas actually the doublespending problem is solved by miners collecting transactions into blocks for confirmation. The blocks may only contain one of the two conflicting transactions, as otherwise the block is invalid. Thus, the blockchain specifies the precedence of transactions by converging on a common journal of the transactions without a central actor.

In the past months, we've seen the "first-seen" paradigm get softened significantly as doublespends (of unconfirmed transactions) have become more or less trivial due to the high demand for blockspace. As it is becoming common for users to update transactions with a higher fee (i.e. a doublespend), the "first seen" paradigm is falling out of use and being replaced by the defacto mechanism of "first-included". Assuming rational miner behavior selecting the most profitable transactions first, we will converge on a full replace-by-fee system eventually.

In other words, when the whitepaper describes the requirement for the Bitcoin system to create a convergent history with "first-seen", it describes a simplified situation that didn't account for the network dynamics of competition for blockspace. From today's perspective this should be understood as "first-confirmed".

  • oh.. i was thinking that "earliest transaction" refers to the first transaction in the history of every block-coin. But here earliest transaction means first transaction of 2 or more double-spends ? – Ashish Negi Jun 19 '17 at 11:42
  • @AshishNegi: Correct, I don't see why the earliest transaction in the history of every block-coin would be especially interesting. – Murch Jun 19 '17 at 15:30
  • Note that solutions did exist but were not complete. Here is a paper predating bitcoin which describes a solution that mitigates the problem as much as possible - arxiv.org/abs/0802.0832v1 – Nether Apr 14 '18 at 9:17
-1

Bitcoin is made with distributed computing and mathemetical calculations as the proof of concept.

so, every time you make a transaction, it is broadcasted to the network and processed based on the fees and resources available.

Bitcoin don't trust any one, so it generally approves transaction after at least 6 more blocks/transactions are added to ledger.

so, if you want to do double spending, you will have to forge the other transaction with exactly prior timestamp, and you must process next six blocks prior to the whole bitcoin network in the world. To do so, you must acquire at least 51% of computation power of whole bitcoin network, which is not possible.

so, bitcoin will discard any duplicate transaction based on the longest transaction block-chain length.

  • 1
    even though whatever you have said is right, i don't understand where is the answer to my question about statement in paper. – Ashish Negi Jun 12 '17 at 15:07
  • To forge double transaction, a user must have at least 51% computing power of the Bitcoin network(That is millions of miner and mining pools combined) to outperform the others in calculations and make his block chain longer. That is impossible!!! so we can Surely say the Early transaction(with longer blockchain) is the valid one. – Jitendra Jun 12 '17 at 17:55
  • 1
    In the chapter 2 of bitcoin paper, satoshi is not talking about 51 % computing power. Can you please rephrase your answer with respect to that chapter ? It will be more convincing. I have also updated the question with two paragraphs of that chapter. – Ashish Negi Jun 13 '17 at 5:48
  • extremetech.com/extreme/… This article may help you to understand it. – Jitendra Jun 13 '17 at 17:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.