Topic: Reverse a 0-conf transaction (Read 975 times)
lol, I pay .0005 tx fees all the time, then I sit there and fret for hours about that first confirm
When I run the double-spend test, it will be from an account which has only the coins being sent, and to two empty addresses (I might not even generate them... just pick a random string, as I'll be working with such small numbers as to be useless after two transaction fees). I feel reasonably secure.
My only question now is, does having a higher tx fee increase relay speed or only confirmation speed? I suspect the latter, as there's no incentive to a node to relay a high-paying transaction.
My only question now is, does having a higher tx fee increase relay speed or only confirmation speed? I suspect the latter, as there's no incentive to a node to relay a high-paying transaction.
You won't be able to pay a random string. Making up a well-formed bitcoin address by pulling numbers out of your bum is practically impossible due to the built-in checksum. You'll actually have to pay an address generated by software.
For all intents and purposes, having a transaction fee of a couple bitcents will give you the highest priority processing, assuming there is any serious backlog for transaction processing. Any extra fee will not speed anything up as you'll be pretty close to 1st place (see http://bitcoincharts.com/bitcoin/txlist/ for the list of unconfirmed transactions, notice nearly none of them pay even 0.01 BTC fee).
Quote
This though is markedly different from your original post, where you had asked if you could change your mind about a transaction, which presumably would be several minutes, or seconds at best, after already releasing the original transaction to the network. Since your efforts to reverse the original transaction would be way too late, the answer for all intents and purposes is no.
Thank you.Quote
Please DO MAKE BACKUPS first of your wallet.dat. Additionally, DO PLAN ON RESTORING from backups after your testing is completed (i.e., don't use new keys from the key pool that aren't in the backup).
Double spends like that don't happen unless you are doing something that causes it to happen (as you have described in your plans) and as a result, the client doesn't accommodate the invalid double spend and will leave it at 0/unconfirmed with no way to clear the problem.
When I run the double-spend test, it will be from an account which has only the coins being sent, and to two empty addresses (I might not even generate them... just pick a random string, as I'll be working with such small numbers as to be useless after two transaction fees). I feel reasonably secure.Double spends like that don't happen unless you are doing something that causes it to happen (as you have described in your plans) and as a result, the client doesn't accommodate the invalid double spend and will leave it at 0/unconfirmed with no way to clear the problem.
My only question now is, does having a higher tx fee increase relay speed or only confirmation speed? I suspect the latter, as there's no incentive to a node to relay a high-paying transaction.
OK, thanks for the answer. I'm gonna try this crapshoot now... two simultaneous spends from two different locations to two different addresse
Please DO MAKE BACKUPS first of your wallet.dat. Additionally, DO PLAN ON RESTORING from backups after your testing is completed (i.e., don't use new keys from the key pool that aren't in the backup).
Double spends like that don't happen unless you are doing something that causes it to happen (as you have described in your plans) and as a result, the client doesn't accommodate the invalid double spend and will leave it at 0/unconfirmed with no way to clear the problem.
So it's only feasible if I alert my uncle Joe ahead of time, "If I text you anything from X cell number, immediately send all of my coins to Y address", and my Uncle Joe operates DeepBit?
More like, get Uncle Joe on the phone, you each prepare the conflicting transaction, and then "Ok, Uncle Joe, on the count of three let's both click submit... one two three click". It would have to be that synchronized to have any reasonable chance of success. Joe doesn't necessarily have to run Deepbit, but if he has a direct p2p connection to Deepbit's servers and you don't, his transaction stands a somewhat better chance of being declared the winner. And if you manage to have a direct connection to the merchant you're trying to defraud, making sure he hears your transaction first, you stand a better chance of succeeding.
This though is markedly different from your original post, where you had asked if you could change your mind about a transaction, which presumably would be several minutes, or seconds at best, after already releasing the original transaction to the network. Since your efforts to reverse the original transaction would be way too late, the answer for all intents and purposes is no.
So it's only feasible if I alert my uncle Joe ahead of time, "If I text you anything from X cell number, immediately send all of my coins to Y address", and my Uncle Joe operates DeepBit?
OK, thanks for the answer. I'm gonna try this crapshoot now... two simultaneous spends from two different locations to two different addresses, both of which I own, with the same coins... it might even turn out to be a nice way to generate almost-truly-random bits very slowly
OK, thanks for the answer. I'm gonna try this crapshoot now... two simultaneous spends from two different locations to two different addresses, both of which I own, with the same coins... it might even turn out to be a nice way to generate almost-truly-random bits very slowly
It's essentially random as to who wins if a lot of nodes are spending the same coins, which is why a prudent user of Bitcoin waits for at least one confirmation before considering a coin fully transferred.
This is only true if the competing transactions are released at the same time, to completely different nodes, so that there can exist an equal proportion of nodes that heard each competing transaction "first". Once a node has heard one transaction, it won't even relay a conflicting transaction, so a latecomer (even if just by seconds) has a huge disadvantage in terms of even getting heard on the network.
Practically speaking, no. Once all the nodes hear about your first transaction, they won't relay your second one.
How long would it take for every node to "hear" about it? What if I called my uncle Joe in Uzbekistan and he did the double-spend? Surely he's connected to different nodes, so given a higher transaction fee and a very short period between the first tx and the second, his spend might outweigh mine?There must be some substantial time between my tx and half of the nodes in the world hearing about it, given the relay time of packets and limited network connectivity, right?
Yes, but it's still seconds. After about 15 seconds, the odds are greatly stacked against you. Besides, what matters more is what percentage of the miners and mining pools have heard about it. You could turn it into an unpredictable crap shoot if you and Uncle Joe release two competing transactions at the same time (which would get resolved the same way as two miners solving a block at the same time), but after one gets a head start of only seconds, the practical odds of reversal without any serious collusion from miners become overwhelmingly low.
Practically speaking, no. Once all the nodes hear about your first transaction, they won't relay your second one.
How long would it take for every node to "hear" about it? What if I called my uncle Joe in Uzbekistan and he did the double-spend? Surely he's connected to different nodes, so given a higher transaction fee and a very short period between the first tx and the second, his spend might outweigh mine?There must be some substantial time between my tx and half of the nodes in the world hearing about it, given the relay time of packets and limited network connectivity, right?
It's essentially random as to who wins if a lot of nodes are spending the same coins, which is why a prudent user of Bitcoin waits for at least one confirmation before considering a coin fully transferred.
Practically speaking, no. Once all the nodes hear about your first transaction, they won't relay your second one.
How long would it take for every node to "hear" about it? What if I called my uncle Joe in Uzbekistan and he did the double-spend? Surely he's connected to different nodes, so given a higher transaction fee and a very short period between the first tx and the second, his spend might outweigh mine?There must be some substantial time between my tx and half of the nodes in the world hearing about it, given the relay time of packets and limited network connectivity, right?
Practically speaking, no. Once all the nodes hear about your first transaction, they won't relay your second one.
To pull this off, you'd have to be mining and be lucky enough to be the one to solve the very next block, incorporating your replacement transaction into your block instead of the first one. Unless you control a substantial percentage of the total hash power on the network, the odds of your succeeding at this are quite remote. Once your first transaction makes it into a block, you're pretty much screwed.
To pull this off, you'd have to be mining and be lucky enough to be the one to solve the very next block, incorporating your replacement transaction into your block instead of the first one. Unless you control a substantial percentage of the total hash power on the network, the odds of your succeeding at this are quite remote. Once your first transaction makes it into a block, you're pretty much screwed.
Hypothetically, if I were to send a transaction with a typo or whatever, and it had a low priority, would I be able to reverse it? For example, could I double-spend the coins involved, but with a higher T.X. fee, to an address I own?
Just wondering.
Just wondering.
Jump to: