bitcoin is failing in replacing fiat in physical shops

[AnonyMint]

His calculation is wrong. To double-spend when the seller requires only 0-confirmations, then one doesn't need any mining hashrate, they just send out two spend transactions. As I explained upthread, the system will probably reject both as duplicates, but the seller has already given your the product and you are long gone. Randomly the system might get one of the spends in a found block and reject the other as a double-spend.

How can you get this wrong after being here so long.

Haven't you learned already that you've lost every technical debate with me in the past and you put your foot in your mouth again here.

1) The network will never reject BOTH transactions.  If the transactions are valid one will be confirmed.

It depends on the programming of the mining client. They might accept the first one received or reject both, given they can collect transactions for the next block while calculating the hash solution for the current block.

You can not dictate how all mining clients will be programmed. You might be referring to the default choice in the official reference client?

2) To be included in the next block the attacker's tx will need to win the "race" of course if the merchant sees the attack tx it becomes very obvious that a double spend is being attempted and the sale can be halted.

I wrote that when the seller releases the product after Tx send. You are writing about a seller waiting a while and trying to sniff the network activity, which is not a guaranteed method due to propagation of transactions not being guaranteed by the protocol.

Especially due to the fact that Bitcoin depends on transaction fees, and I have explained this creates an incentive to withhold transaction propagation. This problem will get worse as coin rewards continue to decrease by design in the flawed Bitcoin protocol.

His calculation is wrong. To double-spend when the seller requires only 0-confirmations, then one doesn't need any mining hashrate, they just send out two spend transactions. As I explained upthread, the system will probably reject both as duplicates, but the seller has already given your the product and you are long gone. Randomly the system might get one of the spends in a found block and reject the other as a double-spend.

How can you get this wrong after being here so long.

I put him on "Ignore" long ago so I wouldn't be tempted to respond to his silly, mis-informed, useless drivel.

Good to see that I made the right decision on the matter.

Ignorant.

You see folks, these so called long-time "experts" are really just gate keepers trying to prevent you from having a better system.

[1715297423]

1715297423

[DeathAndTaxes]

It depends on the programming of the mining client. They might accept the first one received or reject both, given they can collect transactions for the next block while calculating the hash solution for the current block.

Wait isn't the same thing as reject.  If miner waits until the next block then one of the tx will be confirmed.  Still there is no reason for a miner to wait on a paying tx.  Once again theoretical nonsense, based on a presumption that miners are idiots and will do dumb things you need them to.

You can not dictate how all mining clients will be programmed. You might be referring to the default choice in the official reference client?

Economics dictate miners won't be stupid.  If they are they will go bankrupt and be replaced by ones less stupid.

I wrote that when the seller releases the product after Tx send. You are writing about a seller waiting a while and trying to sniff the network activity, which is not a guaranteed method due to propagation of transactions not being guaranteed by the protocol.

You say "send" and "propagation" as if they are different events.  How do you think the merchant LEARNS of the payment.  That is right it is propogated through the network.

So the merchants tx propagates rapidly within seconds, but magically the attackers tx only propagates to nodes that aren't linked to the merchant although the attacker has no way of knowing which ones those are.

Gotcha.

[DeathAndTaxes]

I put him on "Ignore" long ago so I wouldn't be tempted to respond to his silly, mis-informed, useless drivel.

Good to see that I made the right decision on the matter.

I must have taken it off some time ago for one reason or another.  Always good to reverify ones assumptions by experimentation.  In this case the experiment validated the hypothesis.  Also knowing Angry Mint this will likely span countless posts of baseless assumptions and blatantly incorrect technical details so I think it is back to ignore.  Life is too short, and you can't fix stupid.

[DannyHamilton]

Life is too short, and you can't fix stupid.

I'm not convinced that he's stupid.  I suspect that he knows how things work but likes to mislead others for his own personal entertainment.  He either succeeds in drawing someone into a prolonged debate with him on semantics and false assumptions, or he confuses a newbie into spreading additional false information on his behalf.  Either way, it entertains him.

[AnonyMint]

It depends on the programming of the mining client. They might accept the first one received or reject both, given they can collect transactions for the next block while calculating the hash solution for the current block.

Wait isn't the same thing as reject.  If miner waits until the next block then one of the tx will be confirmed.  Still there is no reason for a miner to wait on a paying tx.  Once again theoretical nonsense, based on a presumption that miners are idiots and will do dumb things you need them to.

I have no idea what you are babbling about. If I send a tx to a mining node, that node collects the txs that will be in the next block solution, because it can't modify the hash of the current block solution it is working on. While it is collecting these txs, if it notices two are double-spends, then it could either not include either in the next block solution or it could include one of them. Most logically it would not include either since it can't be sure which was first due to propagation delays.

You can not dictate how all mining clients will be programmed. You might be referring to the default choice in the official reference client?

Economics dictate miners won't be stupid.  If they are they will go bankrupt and be replaced by ones less stupid.

Huh?

I wrote that when the seller releases the product after Tx send. You are writing about a seller waiting a while and trying to sniff the network activity, which is not a guaranteed method due to propagation of transactions not being guaranteed by the protocol.

You say "send" and "propagation" as if they are different events.  How do you think the merchant LEARNS of the payment.  That is right it is propogated through the network.

So the merchants tx propagates rapidly within seconds, but magically the attackers tx only propagates to nodes that aren't linked to the merchant although the attacker has no way of knowing which ones those are.

Gotcha.

The post I was responding to said "confirmation of tx send". If the attacker knows which mining node the merchant is receiving confirmation from, he can send directly to that node, then send his double-spend within the propagation delay to other nodes.

Due to propagation delays, if mining nodes are accepting the first one received, then it is not sure which transaction will be confirmed in the next block solution, i.e. nodes will not all be keeping the same of the two transactions.

If the merchant waits long enough and his mining node is reporting the receipt of a double-spend to him, then he can abort the transaction. But this was not the statement of the post I was responding to which said the product was released upon "confirmation of tx send".

Worse however, if the attacker can identify mining nodes which are withholding high valued transactions (or have significant propagation delay, i.e. there is no requirement that miners must propagate quickly) and have significant hashrate, he can put a high tx fee on his payment to self (not necessary if just a propagation delay attack). Then even if the merchant waits significant time, the double-spend might still succeed. The attacker himself doesn't need to have that mining hashrate.

You have many assumptions which won't always be true. This is typical for the junior level programmer that you are. Get off my lawn child.

Just like the recent malleability issue. You Bitards make many assumptions about how the mining clients "should" work. You forget it is a free market and chaos rules. You need to design for every potential outcome.

The non-zero tx fee is a flaw in many ways.

I put him on "Ignore" long ago so I wouldn't be tempted to respond to his silly, mis-informed, useless drivel.

Good to see that I made the right decision on the matter.

I must have taken it off some time ago for one reason or another.  Always good to reverify ones assumptions by experimentation.  In this case the experiment validated the hypothesis.  Also knowing Angry Mint this will likely span countless posts of baseless assumptions and blatantly incorrect technical details so I think it is back to ignore.  Life is too short, and you can't fix stupid.

Typical junior level programmer that thinks he is hot shit.

Life is too short, and you can't fix stupid.

I'm not convinced that he's stupid.  I suspect that he knows how things work but...

I know not only how things "should" work, but also think about all the ways they "do" work. You stay in your perfect little lab enclosed world. I will stay out here in the real world, where I don't make assumptions that can't be guaranteed.

You all are making many assumptions which you've forced on yourself to counteract a major design flaw in Bitcoin which is the 10 minute block period. Just keep digging that hole please.

[augustocroppo]

Most logically it would not include either since it can't be sure which was first due to propagation delays.

Wut?

d00d, what are you talking about? "Propagation delays"?

LoL

[AnonyMint]

Most logically it would not include either since it can't be sure which was first due to propagation delays.

Wut?

d00d, what are you talking about? "Propagation delays"?

LoL

Are you serious! Do you not know a tx must propagate out to all mining clients?

Are we in Bitcoin Developer 101 class now.

https://en.bitcoin.it/wiki/Double-spending#Race_attack

[Peter R]

I see that Death & Taxes has already corrected AnonyMint's misunderstanding of the bitcoin network in regards to zero-confirm transactions, but I thought I should provide additional clarification for readers.  

Seller has no way of knowing that you didn't send a double-spend within the past few seconds, because your spends don't instantly go into the block chain. Learn what 0-confirmations means.

Incorrect: the seller in fact does have a way of knowing.  If the buyer attempts to double spend by simultaneously sending the coins both to the vendor and to himself, then blockchain.info [an example of a well-connected node] will show a big red DOUBLE SPEND DETECTED warning next to the transaction.  It would also take a fairly sophisticated and custom mobile wallet to even attempt this, as the two spends would need to be broadcast to different network nodes.  Remember: nodes won't relay known double spends and miners won't add them to their memory pools even for unconfirmed transactions.  

Unless you're in cahoots with a nefarious miner that controls a large amount of global hash power [so that you can have him add your fraudulent double spend to his memory pool over a non-public back-channel], the network will detect your double spend attempt.  

Malleability nuance aside, zero-confirm transactions are highly reliable if they've been accepted by a large number of well-connected network nodes and if no double spends have been detected.

A fraudster could send the $1000s in BTC to himself, some seconds before issuing the second Tx. Most likely both transactions would be rejected once the duplicates propagate over the network. Or one of the transactions might make it into the next block solution before the other propagated.

Incorrect: each node will assume the first valid transaction it saw was the legitimate one, and will reject [not relay] the second.  One of the two transactions will get mined and the other won't, and there's no way to know ahead of time which one it will be.  

The important point is that the fraud attempt will be obvious as soon as the network sees two different transactions that attempt to spend the same coins.  This is how blockchain.info can give the DOUBLE SPEND DETECTED warning.  So in your example, the merchant wouldn't give the fraudster his merchandise and tell him to f off if he's gonna pull shit like that; if he's unlucky the transaction to the merchant will confirm and then the fraudster will need to beg for his coins back.

[AnonyMint]

Peter R, DeathAndTaxes, DannyHamilton, Augusto Croppo, back to Bitcoin 101 class for you:

https://en.bitcoin.it/wiki/Double-spending#Race_attack

[Peter R]

Peter R, DeathAndTaxes, DannyHamilton, back to Bitcoin 101 class for you:

https://en.bitcoin.it/wiki/Double-spending#Race_attack

We all understand this, AnonyMint.  The two competing transactions will both spread across the network but only one will get mined.  The point we are trying to make is that the network (and thus BitPay and the merchant) will see this obvious fraud attempt and the cheating customer will not get his merchandise.  The funny thing is that the merchant still might get paid, and then the fraudster would need to beg for his coins back!

You can try to double-spend right now: use brainwallet.org to create two transactions that use the same coins.  Make one transaction send the coins to you, and make the other transaction send the coins to the BitPay invoice-address for a $100 Amazon gift card using Gyft.com.  Broadcast the honest transaction from brainwallet.org and use the blockchain.info/pushtx to broadcast the fraudulent transaction. 

See what happens. 

[AnonyMint]

You are basing your assumption on the current performance of the propagation of the network. This is not guaranteed. Exactly how long must you wait to be sure all nodes have propagated? Is it guaranteed in the protocol? (NO IT IS NOT YOU FOOL)

I will not write further. I already explained it. You have a right to remain ignorant if you wish to.

[augustocroppo]

Most logically it would not include either since it can't be sure which was first due to propagation delays.

Wut?

d00d, what are you talking about? "Propagation delays"?

LoL

Are you serious! Do you not know a tx must propagate out to all mining clients?

Are we in Bitcoin Developer 101 class now.

https://en.bitcoin.it/wiki/Double-spending#Race_attack

I am ROFL serious.

Tell me, great master of the anonymous mint, what that has anything to do with 0 confirmation double spend duplicated tx?

[Peter R]

You are basing your assumption facts and empirical data on the current performance of the propagation of the network the way bitcoin is and has been since the genesis block.  This is not guaranteed. --  FTFY 

I will not write further. I already explained it. You have a right to remain ignorant if you wish to.

You are correct AnonyMint: if everything changes then everything changes.  You've won the debate by reducing your argument to a truism.  

[AnonyMint]

You fools have forgotten the fundamental game theory of Satoshi's invention.

Only PoW guarantees propagation, because there is a selfish reason to propagate first.

With tx propagation this selfish motivation does not exist.

Additionally the tx fee alters the game theory in many ways.

Now STFU. I don't have time to teach you. I will just destroy your piece of shit coin. Bye.

Edit: And even the block propagation incentive can be gamed by gaming propagation:

https://bitcointalk.org/index.php?topic=88302.msg972813#msg972813
http://hackingdistributed.com/2014/01/15/detecting-selfish-mining/#related

[augustocroppo]

You are basing your assumption on the current performance of the propagation of the network. This is not guaranteed.

I will not write further. I already explained it. You have a right to remain ignorant if you wish to.

I think you made a blunder. You said the Bitcoin network would reject the two transactions from a double spend attempt. This perhaps is possible in theory, however that is not how the transactions are processed by the nodes and then included in the blockchain. The first transaction received by the majority of nodes is always accepted, even if majority means just one node. This is stated in Nakamoto's paper:

https://bitcoin.org/bitcoin.pdf

The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

Let me remind you that 0 confirmation just means the transaction was included in 0 blocks. That do NOT means the transaction was rejected.

https://en.bitcoin.it/wiki/Confirmation

After a transaction is broadcast to the Bitcoin network, it may be included in a block that is published to the network. When that happens it is said that one confirmation has occurred for the transaction.

So your case scenario of a seller accepting a transaction with 0 confirmations, one of the transactions will be accepted while others could be rejected. Otherwise, attempt of double spend would be meaningless. Why would an attacker try to double spend his BTC if both transactions would be rejected anyway?

[AnonyMint]

Why would an attacker try to double spend his BTC if both transactions would be rejected anyway?

Because then he gets the product for free and keeps his money too.  

I think you made a blunder. You said the Bitcoin network would reject the two transactions from a double spend attempt.

Incorrect. I did not make that assumption in any of my posts on this issue.

the system will probably (silently!) reject both as duplicates, but the seller has already given your the product and you are long gone. Randomly (rarely?) the system might get one of the spends in a found block and reject the other as a double-spend.

It depends on the programming of the mining client. They might accept the first one received or reject both, given they can collect transactions for the next block while calculating the hash solution for the current block.

You can not dictate how all mining clients will be programmed. You might be referring to the default choice in the official reference client?

While it is collecting these txs, if it notices two are double-spends, then it could either not include either in the next block solution or it could include one of them. Most logically it would not include either since it can't be sure which was first due to propagation delays.

[augustocroppo]

Now STFU. I don't have time to teach you. I will just destroy your piece of shit coin. Bye.

ROFL.

d00d, relax, it is not even a "coin". It is just some spare digits heavily encrypted bloating computer hard disks. I fail to understand why people like you get nuts because something so ephemeral. It is a revolutionary medium of exchange, but it is not a matter of life and death. Why you got so emotional?

[augustocroppo]

Why would an attacker try to double spend his BTC if both transactions would be rejected anyway?

Because then he gets the product for free and keeps his money too. 

I think you made a blunder. You said the Bitcoin network would reject the two transactions from a double spend attempt.

Incorrect I did not make that assumption any of my posts on this issue.

the system will probably (silently!) reject both as duplicates, but the seller has already given your the product and you are long gone. Randomly (rarely?) the system might get one of the spends in a found block and reject the other as a double-spend.

It depends on the programming of the mining client. They might accept the first one received or reject both, given they can collect transactions for the next block while calculating the hash solution for the current block.

You can not dictate how all mining clients will be programmed. You might be referring to the default choice in the official reference client?

While it is collecting these txs, if it notices two are double-spends, then it could either not include either in the next block solution or it could include one of them. Most logically it would not include either since it can't be sure which was first due to propagation delays.

d00d, there is no "could", "perhaps", "might", etc.

One transaction of two will be accepted if it is valid, whatever are the confirmation number for that transaction.

Relax, listen to some jazz music, it helps to visualize the process.

[MakeBelieve]

What? Bitcoin has been used in many different shops from large names to local shops Bitcoin is not failing one bit.

[leopard2]

1. payment processors are no problem - they are needed anyways as long as shops need to operate on a fiat basis.
2. should the time come when shops do not wish to convert their coins into fiat anymore, the obvious solution is this:

a) BTC being the equivalent of a Gold coin (e.g. Roman gold aureus) - used for large transactions like buying a horse or a car, where waiting as absolutely not a problem

b) some fast confirming altcoin being the equivalent of a Silver coin (e.g. Roman sesterce) - used for small transaction like buying a beer in a tavern

For centuries Gold coins have never been used to buy small stuff and the BTC is no exception.

This does also solve the blockchain size issue.

This does also solve the issue of having to use very small fractions of a BTC for a small purchase, which is absolutely not helping the average Joe.

http://en.wikipedia.org/wiki/Silver_coin

"Because silver is not nearly as valuable as gold, it is much more practical for small everyday transactions."