Author

Topic: Can double-spending be prevented by design? (Read 624 times)

newbie
Activity: 5
Merit: 0
March 13, 2014, 03:10:40 PM
#7
Thank you everybody for your responses. Your explanations were very helpful.

I am not a developer, so please forgive my ignorance.

hero member
Activity: 728
Merit: 500
Can double-spending be prevented by imposing rules for initiating new transactions:

RULE1: Account can only initiate 1 transaction every 60 sec
RULE2: Account cannot initiate new transaction before previous transaction is validated.


First of all, Bitcoin doesn't have 'accounts'. There are private keys and their associated public keys and addresses. But lets assume you meant those.

What is stopping someone from simultaneously broadcasting transaction A to nodes 1, 2 and 3 and transaction B, which tries to spend the same coins as A, to nodes 4, 5 and 6? Both transactions are perfectly valid when seen by the nodes that they were broadcast to and only when the transactions propagate through the network will some nodes receive both A and B, in which case they simply drop one of the two. Nothing in the rules you propose prevents this.

Adding such rules to the users client-software is pointless (and current clients already try and prevent doublespending), since a malicious user may as well develop his own version of the software that doesn't include these rules.

As DannyHamilton has pointed out, doublespending is already prevented by design. In fact, this is one of the more important innovations of Bitcoin: a decentralized system with doublespend prevention. However, the caveat is that some time is required before a recipient can be confident that a transaction will make it into the permanent ledger.
hero member
Activity: 714
Merit: 500
NEED CRYPTO CODER? COIN DEVELOPER? PM US FOR HELP!
Can double-spending be prevented by imposing rules for initiating new transactions:

RULE1: Account can only initiate 1 transaction every 60 sec
RULE2: Account cannot initiate new transaction before previous transaction is validated.


I really didn't get your whole point or question but definitely i can say that the 2 scenario you are talking about are not so cool and any wallet who develops that people will avoid using that service.

Edit: the multiple account exploit can be patched due to some extent by getting an one account / ip limitation  on. thanks Smiley
legendary
Activity: 3528
Merit: 4945
double spending is prevented.  That is the problem that Satoshi's bitcoin solves in a decentralized way.

I think what you are asking is can a user be prevented from simultaneously attempting to broadcast to 2 or more different peers 2 or more different transactions that share at least one input.

I think the answer to this is no.  But, the consensus system built around proof-of-work makes sure that only one of those transactions are valid.  The others will eventually be tossed away as invalid transactions.

As a recipient, as long as you have a trust relationship with the sender or you are willing to accept the fraud risk, it doesn't matter.  If you don't have a trust relationship with the sender and you aren't willing to accept the fraud risk, then confirmations exists to establish a consensus on which transaction exists and which doesn't.
legendary
Activity: 2058
Merit: 1462
Can double-spending be prevented by imposing rules for initiating new transactions:

RULE1: Account can only initiate 1 transaction every 60 sec
RULE2: Account cannot initiate new transaction before previous transaction is validated.

exploit: make multiple accounts
kjj
legendary
Activity: 1302
Merit: 1026
Account?  Methinks you have some more books to be hitting.

Also, this won't work.  For either rule to work, you need some way to decide which of two events was first, which is exactly what the bitcoin network is doing.
newbie
Activity: 5
Merit: 0
Can double-spending be prevented by imposing rules for initiating new transactions:

RULE1: Account can only initiate 1 transaction every 60 sec
RULE2: Account cannot initiate new transaction before previous transaction is validated.
Jump to: