Broadcast Double Spend Transactions

[ShoukaT]

Hello,

I have been using bitcoins for quite a while now ,

after reading this topic https://bitcointalk.org/index.php?topic=130764.0

i was interested in trying out some related methods ,

i want to know how you can broadcast double spend transactions ,

most of the time the network will reject your double spend transaction and it wont be broadcasted properly , i have tried using it with the default bitcoinqt client ,

kindly guide me some method with which i can successfully BROADCAST a bitcoin transaction on the network....

even though it is a double i just want it to be broadcasted across the network , not confirmed or anything , just broadcasted before the original is confirmed , if any pro can help me , that would be really appreciated.



p.s. i know double spending is impossible but i just want to know about broadcasting transactions , broadcast a transaction before the first one is added in a block (confirmed)

[Raoul Duke]

Clients who know it's a double spend, i.e. that already have the other transaction on their memory pool, won't broadcast it, if I'm not mistaken, so I would say you have a challenge there.

You will need both clients to be connected to different ends of the network to be able to have 2 transaction(double-spends) floating around on anything that even gets close to 50/50.
But no, you will not get one transaction broadcasted from a client which already has the other.

I bet someone will come that will explain it to you with technical details included. And maybe some assurances. This is my understanding on how it works, but I may be wrong here or there.

[ShoukaT]

^
Yes you are right ,

But say , i have two different machines , both have fully updated blockchain and online..

now when i create a first transaction , it propagates through the network to all the nodes in a matter of seconds , like say max 5 or 10 secs...

so the other machine will also know of this transaction and update it in the wallet...

however what i can do is disconnect the 2nd machine from the network when i make first transaction and make it back online after 10 secs so it doesnt get the announce of first TX

now i try and spend same funds on the 2nd machine but that's where the problem occurs...

the nodes i m connected to some times reject to announce the second transaction and the second tx doesnt get broadcast properly over the network...

now i want a way by which the second tx although a double spend can also be broadcast in the network... not confirmed , but just broadcast ,

 the confirmation part is just my luck that which tx the miner who mines the next block will pick as valid.

[ufmace]

I'm pretty sure that you'd have to write a custom client to do anything like that. That's stuff that is technically possible to do in the protocol, but no mainstream client will let you do it - deliberately ignore the first spending transaction, and/or deliberately connect to two separate sets of nodes in the network. And if you're doing any messing around like that, it would probably be best to do it on the test network instead of the production one.

[Raoul Duke]

To successfully broadcast a double-spend from your Client, Node A, you'll need to be connected to at least 1 node, that doesn't know about the "real" transaction, let's call it Node B. No other way around it.
And for Node B to successfully broadcast that transaction he would need to be connected to at least 1 node, Node C, that doesn't know about the "real" transaction and which isn't Node A.

And so on and so on.
It's not a matter of your client not broadcasting the transaction, which it will (try to) do if you use the method you described, it's a matter of the network accepting it and broadcasting it.

[ShoukaT]

the method i described above works 1/10 times,

both the TX get accepted by the network and show up on blockchain.info..

but mostly it is rejected by the network...

e.g. http://satoshidice.com/full.php?tx=92305b36e12c0abc37e9ea18406a6a388e0d626e2c394c21ea488ea7e6fb43d5

i was able to reverse this loss on SD via my method too


which also pops an interesting question in my mind..

If the network is made this way it that it doesnt accept any kind of double spends then how come it does accepts the double spend tx sometimes and broadcasts it to all nodes... and all nodes recognize the double spend TX too...

does it mean that i only need to be connected to 1 well connected node which doesnt know about the TX A in order to broadcast TX B through it?

[milly6]

Because once it sends it to all nodes its labeled as a doublespend once it connects to the nodes and realizes that someone is trying to dupe the system. Its designed that way. If it didnt send it to the nodes, it wouldnt know that its a double spend or even that it exists. The point of having multiple nodes is that the nodes must match for a transaction to be valid.

[Raoul Duke]

Because once it sends it to all nodes its labeled as a doublespend once it connects to the nodes and realizes that someone is trying to dupe the system. Its designed that way. If it didnt send it to the nodes, it wouldnt know that its a double spend or even that it exists. The point of having multiple nodes is that the nodes must match for a transaction to be valid.

Important detail here. My statement above may need a fix after reading this.

[milly6]

yeah well basically if you doublespend and control your nodes, your transaction will never make it to the reciever unless that reciever is one of the other nodes which is NOT connected to other nodes which have the correct info. When the all converge, the double spend will be invalid.

[Stephen Gornick]

both the TX get accepted by the network and show up on blockchain.info..

Blockchain.info couldn't report about double spends unless it accepts them.  So it is easy to get Blockchain.info to know about your double spend attempts, just connect to one of their listening nodes or wait until they connect to your node.

However, most every mining node is simply taking the first spend transaction it sees.  So even if Blockchain.info shows that there is a second transaction (which is a double spend), the mining nodes and everyone else will reject it because it is a double spend.

Now there may be some mining nodes who will modify the rules, and maybe even take the second transaction over the first (especially if the fees on the second are higher than on the first).

And there is the other possibility where a mining node wasn't operating at the time of the trx broadcast and later when the mining node was started up it learned of the double spend transaction first and then rejects the original transaction.  So this would explain how an honest miner using the stock Bitcoin-Qt/bitcoind click could still end up including the double spend in a block even though most nodes learned of the original transaction first.

SatoshiDICE now waits for a confirmation on certain wagers before giving a WIN/LOSE status if it either sees a double spend attempt or figures the transaction won't confirm right away and thus is more at risk of there being a double spend later on.

[union]

I don't think this is a bug, this is a feature.

Fees make transactions have different speeds, thats is the whole point of fees (at this point).
The bigger the fee, the faster the transaction (theoretically).

A second transaction with hier fees can go faster and possibly reach 51% of the network faster than the first transaction with no, or lower, fees.

As a merchant you should look at the fee paid for any given transaction, and allow more confirmations for lower fees,
I dont think there is any other way around it, since mining operators will always prioritize higher fees.

I think, that ideally, a 0 fee transaction should wait for 51% confirmations before being acted upon.

Does any of this make sense to you?

[Stephen Gornick]

I think, that ideally, a 0 fee transaction should wait for 51% confirmations before being acted upon.

Some transactions will confirm right away without a fee.  Others will take longer even with a fee due to other properties (e.g., having INPUTs who themselves have not yet confirmed).

This is going to become an increasingly important area to manage for those who accept on 0/unconfirmed (e.g., retail merchants).

Imagine paying at the counter and then being told your payment had no fee and thus you need to wait (hours maybe) to receive the merchandise you paid for.  There's no way to cancel the payment, which makes it even worse.

I keep flip flopping on whether or not bitcoin can work for merchant payments.

If the retailer can make it economically unprofitable to try to double spend then there won't be a problem.  i.e., if the attacker/thief has to buy 19 hamburgers before the 20th is "free" from a successful double spend, then an attacker probably isn't going to try.  But the merchant isn't looking to figure out a way bitcoin will work, the merchant is looking only to sell hamburgers, and if a payment network gives hassle and risk it is not likely to be embraced.

Now that FinCEN has stated that merchants can accept bitcoins for goods and services without having to register as MSBs, there will probably be some new approaches coming (including intermediaries, likely).

[Abdussamad]

If the retailer can make it economically unprofitable to try to double spend then there won't be a problem.  i.e., if the attacker/thief has to buy 19 hamburgers before the 20th is "free" from a successful double spend, then an attacker probably isn't going to try.  But the merchant isn't looking to figure out a way bitcoin will work, the merchant is looking only to sell hamburgers, and if a payment network gives hassle and risk it is not likely to be embraced.

Sorry to bump up this thread but I think it is relevant given that namecheap has become the first merchant to accept bitcoin payments without waiting for confirmations. So looks like Stephen was at least half right above.

Stephen, if you are still subscribed to this thread I'd like to know what you think of the recent namecheap move? Do you think other merchants will follow suit?

[Stephen Gornick]

namecheap has become the first merchant to accept bitcoin payments without waiting for confirmations.

How about EVR bar?  Cups & Cakes Bakery?   Room 77 and the rest at Bitcoin Kiez?     The Pao Cafe?    Green Ave Market?   

All these are bricks & mortar businesses that don't wait for confirmation.

None have reported any double spending having occurred.

I'd like to know what you think of the recent namecheap move? Do you think other merchants will follow suit?

A merchant category that would have the highest risk of loss from accepting payment on 0/unconfirmed would be the quarter machine at an unattended laundromat.    In that instance, there is little (or no) profit from each sale, and thus any losses due to double spend translate directly into losses to the merchant.   If the attacker has to try twenty-five times before finally succeeding at a double spend attempt with try #26, the attack is profitable to the attacker -- the attacker has both the loot and the bitcoins that were double spent.  Since the merchant won't know about the double spend until after the attacker has left (at the soonest), it can be presumed the chance of the attacker getting caught is nil.

Namecheap is a merchant that is on the other end of the spectrum.  Namecheap registers domain names, provides web hosting, etc.   If an attacker is successful at a double spend, as soon as Namecheap learns of the double spend  they have at their disposal their full control of the domain and any hosting services they provide.  So at most an attacker would get hours (or maybe a day) of domain registration or hosting and then lose access to the domain.  Thus there's absolutely no benefit from attempting to double spend against a merchant like Namecheap.

As long as there's no significant economic benefit from performing the attack, then the merchant will probably be able to absorb any resulting losses when a double spend occurs. 

But this is a developing situation.   

Currently the stock client doesn't relay double spends and miners and pools aren't for the most part using customized clients that could make double spending easier, such as the "replace by fee" patch:
 - http://bitcointalk.org/index.php?topic=179612.0

So if there is a decent amount of hashing capacity using this software, the risk of loss due to double spending against merchants increases.    Even if 100% of hashing capacity were to adopt this patch though, for instance, a sit-down restaurant would still have little risk as maybe only 5% of purchases would be by the dishonest, cheating types yet restaurant margins are 30%, let's say.

But what does a grocery store with razor-thin margins do?   Well, I see that the merchant processor BIPS also has an E-Wallet.  So if the grocery used BIPS as its payment processor it would know right away that the payment is using confirmed funds.  For others, the grocery could require identification, for instance.  Or restrict to wallets that are supported with green addresses.   Or Ripple payments. 

Gyft, right now, is the first Bitcoin-accepting merchant that I consider to be the canary in the coal mine.   An attacker (thief) can pay for a Gyft card via bitcoin (anonymously, using Tor) , get a QR code for the gift card, send the  QR code image as Instagram to a partner (shopper) who uses the QR code to pay for the purchase and leave the premises with the goods.

If Gyft isn't having trouble with 0/unconfirmed double spends, I doubt many other merchants will either.

But that's today.  Down the road it may change.   In the meantime, merchants accepting Bitcoin payment are gaining new revenue and not suffering payment network losses (due to double spending resulting from 0/unconfirmed transactions) so for now Bitcoin is relatively safe for these transactions for most merchants.   

[Abdussamad]

namecheap has become the first merchant to accept bitcoin payments without waiting for confirmations.

How about EVR bar?  Cups & Cakes Bakery?   Room 77 and the rest at Bitcoin Kiez?     The Pao Cafe?    Green Ave Market?   

All these are bricks & mortar businesses that don't wait for confirmation.

None have reported any double spending having occurred.

As you can see from my sig I live in Asia so I've never heard of these businesses before. I thought namecheap was the first in this regard.

I'd like to know what you think of the recent namecheap move? Do you think other merchants will follow suit?

A merchant category that would have the highest risk of loss from accepting payment on 0/unconfirmed would be the quarter machine at an unattended laundromat.    In that instance, there is little (or no) profit from each sale, and thus any losses due to double spend translate directly into losses to the merchant.   If the attacker has to try twenty-five times before finally succeeding at a double spend attempt with try #26, the attack is profitable to the attacker -- the attacker has both the loot and the bitcoins that were double spent.  Since the merchant won't know about the double spend until after the attacker has left (at the soonest), it can be presumed the chance of the attacker getting caught is nil.

We don't have these machines where I live but I assume by the name that only small sums are involved? Would a thief go through all that trouble for a few dollars?

Namecheap is a merchant that is on the other end of the spectrum.  Namecheap registers domain names, provides web hosting, etc.   If an attacker is successful at a double spend, as soon as Namecheap learns of the double spend  they have at their disposal their full control of the domain and any hosting services they provide.  So at most an attacker would get hours (or maybe a day) of domain registration or hosting and then lose access to the domain.  Thus there's absolutely no benefit from attempting to double spend against a merchant like Namecheap.

Actually one of the problems that hosts face is that people sign up, start spamming  or otherwise abusing their services and then chargeback. With bitcoin it would be a double spend instead of a chargeback. You can spam quite a bit even within a few hours and the host is left to clean up the mess. So there is always a risk.