Topic: bitcoin is failing in replacing fiat in physical shops - page 3. (Read 8586 times)

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://bitcointalksearch.org/topic/m.972813
http://hackingdistributed.com/2014/01/15/detecting-selfish-mining/#related

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

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?

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.

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. 

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

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

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.  


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.



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.

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

Wut?

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

LoL

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.


Huh?


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.


Typical junior level programmer that thinks he is hot shit.


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.

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.

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.

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.


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


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.

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.


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?


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.



Ignorant.

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

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.

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

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

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.

Merchants (or their processors) can improve the odds by using listening nodes which communicate out of band width the merchants (or processor's wallet).  If a merchant had 8 geo located listening nodes with an average of 2,000 peers each that would be 16,000 peers.  Now if any one of those 16,000 peers are relayed the double spend the merchant will be aware of this.  The merchant can nearly instantly detect attempts to double spend.  The merchant can delay the sale by a few seconds to ensure good propagation and see if there are any double spends.

If the attacker waits until after the sale is complete, the entire network will already be aware of the merchant's tx and reject the attacker's as a double spend.
If the attacker sends both tx simultaneously within seconds some node connected to the merchants listening network will see it and a "DOUBLE SPEND. ASK FOR ALTERNATE PAYMENT" can be displayed to the cashier.

This type of detection would not be able to see Finney attacks however 0-confirm isn't suitable for all transactions and there are significant costs and complicates with pulling off a Finney attack in all situations.

His calculation is wrong. To double-spend when the seller requires only 0-confirmations, i.e. only confirmation of Tx send, then my understanding is that one doesn't need any mining hashrate, they just send out two spend transactions with one sent to self. As I explained upthread, 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.

His math is apparently for trying to double-spend to a seller who accepts 1-confirmation.

LoL

How naive and fool you are...

Who said the entity willing to double spend needs to buy any equipment? They already have it all they want.

...and no, their equipment will be not seized. Bitcoin double spend is not a crime anywhere.

I will be revealing a proposal of how to keep pools small.

---

Cool idea to virally spread Bitcoin adoption by sending via email. Realize that when sending BTC via coinbase via email, anyone who can access the email can access the BTC, thus a wallet could just send the private key in the email too, even hide it in HTML with

to https website which accomplishes the same thing but stores the private key locally on the computer with the option to back up keys by printing and memory card. There might need to be a browser plugin to be installed for the wallet to allow to write to the local hard disk.

I don't see anything on the coinbase user interface in that video that couldn't be accomplished just as easily and seamlessly with the keys stored locally and all activities being recorded in the block chain. The only extra hassle for local storage is doing your own backups, but you gain anonymity and you can prevent all your balance from being stolen by malware by keeping most of your balance on paper.

He claims in the video that Coinbase holds the private keys. He claims Blockchain.info does not hold the private keys in an online database but I haven't verified it.

Coinbase keeps 95% of the private keys off line. They bring more online as needed during heavy demand for liquidity. Yet that 5% pool is apparently shared between all users. Malware could still record your coinbase login and spend your entire balance.

A user could do similarly, they wouldn't want to keep all their BTC private keys on their computer which is connected to the internet due to fear of malware stealing it.

One might argue that the safest would be to never use memory card either, and instead only print and re-type private keys from paper. Because malware can spread via USB drives too. However that is not true in this case, since the purpose is not to use the memory card in the interim time rather only to store it and reinsert when ready to spend the balance. Nevertheless I would also print, since memory cards can fail and malware could potentially delete it as soon as you reinserted it. So you would normally not have to retype, but keep these for the worst case scenario. At some point, I would like to look into if there is a way to create a memory card interface that can't transfer executable malware.

This in my opinion is one of the most important points that the community misses.

if people start accepting bitpay (or any other service) balances as bitcoin, then effectively we are now using BitPayCoin because nothing stops them from changing the amount of coins people have in their database.
this will effectively break bitcoin's 21 million coin limitation and enable the same inflation we have today with fiat.

if we are to win the war for sound money the only bitcoin that must be accepted by people are bitcoins that reside on the blockchain, where the bitcoin protocol rules are actually enforced.
otherwise we have gained nothing and simply created new bitcoin banks.