Bitcoin Forum

Hi there,

I have a feature request for Bitcoin Core. (I'm not a programmer, so I am unable to contribute technical skills to getting this implemented. I can just type up my feature request here. ;))

I recently lost $1 worth of BTC, because one of my transactions got permanently stuck in an "unconfirmed" state. This is because my iOS wallet app (BitWallet) didn't require me to include the required .0001 fee with it. As a result, my transaction never confirmed. To make matters worse, my app doesn't have the ability for me to cancel unconfirmed transactions so I can rebroadcast the transaction with a fee attached. Full details in this thread: https://bitcointalk.org/index.php?topic=722880.0 

So my transaction seems to be lost permanently.

It was pointed out to me on a Reddit thread (located at http://www.reddit.com/r/Bitcoin/comments/2ci5mb/bitcoin_is_not_the_answer_for_micro_transactions/) that the answer could be as simple as the Bitcoin Core app implementing Peter Todd's "Replace By Fee" tools, which he has uploaded onto GitHub here: https://github.com/petertodd/replace-by-fee-tools

I would like to express my support of seeing these "Replace By Fee" tools implemented into the Bitcoin Core app. This would help prevent users like myself from having their transactions lost permanently if they forget to attach a fee!

Thanks! :)

Nothing is permanent in bitcoin, and a transaction that's not accepted or propagated by miners and 'lost in limbo' is, with increasing probability, headed toward the opposite of permanent.

Getting the move of funds to go through should be as simple as backing up the wallet, importing it into another (more proper) wallet app and sending a new transaction with a fee attached. Or maybe deleting the cache of the iOS wallet app could work, but I have no idea how iOS or any of their apps work, so be sure to have a backup anyway.

Thanks so much. I tried importing the private keys into another wallet app (MultiBit), but it wouldn't let me create a new transaction because it saw the "unconfirmed" transaction as a valid transaction. So, my "available to spend" BTC balance had already reflected the lower balance, as if the transaction had already gone through.

I'd guess that if your wallet software were smart enough to implement Replace By Fee (and if it was standard on the network), it would probably also be smart to not have caused this situation in the first place. In other words, I think the better option would be to get your wallet's developers to implement warnings when the transaction fee is too low, and also methods to remove stuck transactions, first (not to knock the devs, all things take time to work the bugs out).

If Replace By Fee were standard, no transaction would ever be instant, even very small ones. Some see this as an improvement in security at the expense of convenience and choice, others see the improvement in security to be so minuscule, especially with small transactions, that the cost in convenience makes it not worthwhile (although I'm probably summarizing all this incorrectly).


Have you tried the advice over on this support page of theirs (https://multibit.org/en/help/v0.5/help_support_sentBitcoinFromMultibitButTheyAreStuck.html)?

If that doesn't help, here's what I'd eventually consider.

• Transfer the remaining balance (via the Bitcoin network) from your old wallet to one of the new MultiBit addresses. This is just to ensure that you don't lose anything on the off-chance MultiBit didn't like the keys you imported (I really don't think that's the case, I'm just being safe).
• Once that transaction has confirmed, uninstall the old wallet so that it stops trying to broadcast the stuck transaction, wait a day or so, and try the advice on the linked page once again.

Eventually that transaction will confirm as its inputs age. You just have to wait.

wait for centuries?
we can not disallow nodes to keep and rebroadcast valid transactions.
and some of them really do it.


What a nonsense! Why do you ask to change one app because of bad behavior of another app?
As you mentioned above the "replace-by-fee" tools already exist as separate package.

Couldn't it be fixed by manually crafting the new tx with a higher fee and then https://btc.blockr.io/tx/push or http://coinb.in/send-raw-transaction.html ?

No, you'd have to try and broadcast it via another node, since BlockChain seems to reject 2nd transactions that use the same inputs. I'm not sure about coinb.in.
Nodes might treat it as a double spend anyway.

There's another one https://btc.blockr.io/tx/push

(Edited my post above)

Just broadcast it with a higher fee. Also if you don't rebroadcast the original transaction, the memory pools will drop the transaction within a week.

Usually, no.
Because both these services reject new transaction with double-spending inputs. You have to check them frequently to find when they remove old stuck transaction from memory-pool to send new one with higher fee.

Better service is http://webbtc.com/relay_tx
But I am not sure that it has enough connected peers to successful rebroadcasting.

And do not forget about http://eligius.st/~wizkid057/newstats/pushtxn.php

Some nodes and clients automatically rebroadcast transactions...
So yeah.

It seems like there is nothing I can do to rebroadcast this transaction with a fee, and that I have lost this $1 forever. :( At least it was only $1, though.

Hmm... Not really. Can't you just remove the private key from bitWallet? Then it can't rebroadcast the transaction at all.

You can. But let us start from the early beginning.
1) Can you show stuck transaction on the blockchain?
2) Do you have another utxo (sorry - this means some other funds on unspent tx output )?

Unfortunately, BitWallet is not the app that is rebroadcasting the transaction. BitWallet only broadcasts the transaction once (according to the BitWallet developers). It is other nodes on the Bitcoin network that are continually rebroadcasting the transaction.

1. The stuck transaction on the blockchain can be seen here: https://blockchain.info/tx/c238d939b330b682abe1c729300636600254c23c67e1eea4e8daa9abc26dd2c5

2. Sorry, I'm new to this. I don't know if I have other funds on the unspent output. How can I tell?

Thanks,
Scott

I'm not sure what you're asking, but the input has additional funds, so the remainder is being delivered as change back to him.
The outputs are unspent, and also unconfirmed.

I have encountered some strange result regarding your Tx. Except blockchain.info none is showing it !!!

https://btc.blockr.io/tx/info/c238d939b330b682abe1c729300636600254c23c67e1eea4e8daa9abc26dd2c5

https://www.biteasy.com/blockchain/transactions/c238d939b330b682abe1c729300636600254c23c67e1eea4e8daa9abc26dd2c5

Weird. Can he just build a raw transaction using Brainwallet.github.io, and then rebroadcast it? (with a fee, of course).

Very interesting!! What does this mean? This is making me hopeful! :)

It means that Blockchain.info is being retarded as it usually does. It proves that other nodes can't see this tx at all.
Please wait for a bit, you should be able to get your bitcoins back. I need someone to answer if what I stated is possible.

That you can just broadcast a new transaction with fees on blockr.io or else.

Okay. Bitcoingirl, try this.

https://brainwallet.github.io/#tx

Then they will eventually drop it, a lot of nodes already have.  You will need to import the keys into a new wallet so you can create a "double spend" which pays the minimum fee.

Blockchain.info has a bad habit of relaying txns which other nodes would simply drop.  It makes it worse when their wallet also creates txns that other clients wouldn't allow it to create.

Most of the network has either never received the original txn or they dropped it because it had insufficient fee/priority.

DeathandTaxes, can he create another transaction and broadcast it elsewhere then?

Yes.  The private keys need to be extracted from the original wallet and imported into a new wallet.

Thanks. I imported the keys into MultiBit, but MultiBit wouldn't let me do the "double spend" because MultiBit ALSO sees the transaction as still pending/unconfirmed. Perhaps MultiBit is pulling its information from the Blockchain.info site?

I tried this with MultiBit and it wouldn't let me spend the coins again there, but maybe I should try it with a different wallet instead.

Thanks! I will try this!!!

I must say I'm surprised this transaction is still being propagated.

Seeing that it has no fee, I see no reason for nodes to relay this transaction for longer than a few hours, if at all. If it hasn't reached a miner that's prepared to mine it by that time, it likely never will.

It isn't. The only NODE i can find that still lists it is BCI... They need to get their shit together!

So it seems like all of my problems have been caused by Blockchain.info never dropping the transaction, and the apps that I have been using have all been pulling their information from blockchain.info?

Yes most likely, or your app has a memory for unconfirmed tx it sent itself.

I tried this, and it didn't work… it sees the $1 transaction as "already spent", so I can't resend the transaction.

The actual error message on the page says: "Some funds are pending confirmation and cannot be spent yet (Value 0.00163899 BTC)".

Seems like Blockchain is the culprit here. Damn Blockchain!! This is no better than dealing with a centralized bank, if Blockchain.info can singlehandedly prevent this transaction from dropping so I can resend it with a fee.

Well on the flip side, banks also wouldn't carry your money from A to B if they didn't get payed for it. So there's that.

And BC.I isn't in theory preventing this transaction from happening; it's actually encouraging it by trying to get it to a miner, which it's failing at for obvious reasons. On the other hand, wallets are preventing you from double spending the transaction because BC.I appears to be persistent on relaying a doomed transaction, so in practice, it is preventing you from moving the funds - even if through another transaction, indirectly.

Rest assured all these 'irrelevant usability issues', as myself and many developers would call them, will be worked out before long.

@bitcoinGirl

I'd bet that your transaction will be included in a block within a week!

Thanks for your thoughts on this matter. Makes perfect sense, all the way around.

And… great news!! My unconfirmed transaction finally "fell off" of Blockchain.info, and I got my coins returned to me! :)

Only took 4 days!  :P

Next time, try writing to blockchain.info support, and see if they can help. They're the retarded ones that still showed the tx, and everyone looks at blockchain.info, all clients do -.-

I actually did write blockchain.info support… no response from them.  :-\

Ugh. Annoying that everyone looks to them as their master source of information.

Now you should spend your uxto. Just send your funds with 0.00001 fee (or 0.0001)
Because everybody is able to resubmit your stuck transaction ;D

Ha! Thanks!! I did go ahead and spend my uxto, so I think I'm okay now. Thanks to you and everyone else for your amazing help through these trying times!! :) All this for $1. But a great learning experience.

i think thats all about new code in running . or double spend ?
i never got problem like that  :-\

Not everyone. There's plenty of options.

This thread is kinda depressing; this sillyness should have been fixed a year ago.

FWIW greenaddress.it was talking about implementing fee bumping to me; tell Lawrence you want to see it. :) I've also suggested it to the rest of the DarkWallet team, again, telling them you want to see this too helps. Also, everyone who runs my replace-by-fee patch helps out the network. Even if you aren't a miner, nodes that run it help get replacements to miners who will accept them for whatever reason.

If you have any change from your transaction, you can send the change to another address that you own with enough fee to cover both transactions and that may get your transaction confirmed.

I do agree that replace by fee should be added when the client is in expert mode. Also, miners really need to implement Child-pays-for-parent.

Can't be done, because the change transaction was also in an unconfirmed state.

It's a good wake-up call to how open source software almost never succeeds in the real world. And when open source does have some modicum of success, it is riddled with bugs and flaws and security holes (e.g. Android). It makes me realize that Bitcoin will probably never reach mainstream success. :(

It takes a for-profit corporation to take open source software and turn it into something proprietary that works for the mainstream (like how Apple took Gecko/KHTML and turned it into Safari).

You mean like linux, Firefox, open office, Wordpress, apache , MySQL, BSD, Magento, Filezilla, audacity, gimp, vlc, truecrypt, ubunto, keypass?

Just because there is a part that needs to be fixed ( I am not even entirely convinced it should be fixed on a protocol level!) , makes you think BTC will never reach mainstream success..

Well, I got bad news for you ;)

child-pays-for-parent is not implemented by miners

No. There is no such restriction in protocol itself. Just use smart client software. Unfortunately, "smart" is not "friendly to novice"

Hmm that's something I thought existed. It would profit miners to implement this; why don't they?


Replace-by-fee, combined with child-pays-for-parent, seems to make 0/unconfirmed transactions much more secure for small transactions. Just read the thread where Peter Todd describes the proposal; he has a very well thought-out argument for why, which I'll summarize:
Current system:
- If a scamer manages to send out a double-spend transaction at the same time as you send the actual transaction, 50% chance yours is confirmed 50% theirs - theirs might even have a higher chance if it has higher fees and a miner (but not most clients) is implementing replace-by-fee.
- Expected value for potential scamer: 0.5*amount_paid
- Expected value for you: amount_paid - P(payee is not a scamer)*amount_paid
Replace-By-Fee system:
- If a scamer sends out a double-spend transaction at the same time as you send the actual transaction, you send another transaction paying the output of your transaction to a transaction fee. Scamer receives nothing, but neither do you.
- Expected value for potential scamer: 0
- Expected value for you: amount_paid
As you can see, there's no longer any motivation to scam. The only reason there would be motivation to scam is if the scamer has a vendetta against you, and if losing the money would cause significant damage you wait for a confirmation - which should be true now anyway.

Potential flaw, you double spend accidential yourself. I managed to do that too...

Most of current clients do not allow to spend unconfirmed transaction output. So, the profit is near to zero.
Right now the transaction fee is too small comparing with block reward.
It is not good reason to change existing code to increase profits to 0.00x btc per block. The error in code costs much more.

That is not true, most advanced clients allow it. Same with coincontrol.

Also you can always dump your private key and reimport it elsewhere to create a new transaction. This is a chicken-egg problem with your argumentation!

I am totally pro-Bitcoin and a huge Bitcoin fan, but it's just not looking so great for mainstream adoption.

Here's a great article on how closed-source always beats open-source:
http://blog.erratasec.com/2014/07/cliche-open-source-is-secure.html#.U-Kj3Ui9KSN

The technologies you named are great for tech-savvy engineers, but not for the general public:

Linux - never made it to mainstream users. The general public uses OS X.
Firefox - surpassed in usability and security by Safari and Chrome. Apple's new web services don't even support Firefox anymore.
Wordpress and MySQL and Apache - arguably the 3 open source technologies that made it to mainstream users... BUT both are maintained & controlled by corporations (Wordpress and Oracle and Apache). Hence their success. Without these corporations funding the development of those products, they would likely not have taken off.
VLC - surpassed handily in functionality & features & ease of use by companies like LogMeIn. VLC stopped evolving years ago.
The other technologies you've named: not being used by any mainstream users, unless they were taken over by a corporation (e.g. how Apple used BSD for OS X).

I would LOVE for Bitcoin to go mainstream. I'm rooting for Bitcoin. But unless a for-profit corporation starts controlling & writing the code, it's looking increasingly unlikely that Bitcoin will go mainstream. The few developers working on the code can't even agree on a direction for its future! It's taken 5 years to get where we are today, which is... almost no progress. :( The Bitcoin Core client hasn't even reached version 1.0.

On the other hand, for example, look where Apple has come in 5 years with the iPhone: 5 major iOS releases, hundreds of millions of phones sold, rock solid stable OS with no security flaws, an entire worldwide ecosystem built around it.

Not true. I reimported my private key to 4 different clients, and none of them let me create a new transaction while my unspent outputs were still unconfirmed. No client that I could find will allow for double spending.

I think you confuse with "used by the huge majority" with mainstream use.

Sorry to say, but what you say is just not true.

Just a few pointers: Linux is the most used server OS, by far
Firefox still has over 20% market share
@others, again you confuse two concepts, mainstream and majority.

Even if "the majority" won't directly use Bitcoins, I am sure they will use it without knowing it.

Blockchain infos custom send, does.

I tried it on blockchain.info and didn't work. Maybe I did it wrong.

I see what you're saying. You're saying that a few tech-savvy engineers will rally around Bitcoin technology as the backend, and create mainstream products for people who don't even know that Bitcoin is the underlying technology. Let's hope so! This technology is too important to fade away!!!

Not tech-savy people but greedy businessmen. Look at circle. They even want to eventually only display USD amounts. You won't even notice that there is BTC being send behind the scenes. Just a frontend like paypal.

Yes, of course, the greedy businessmen!!  :P But... who will maintain the underlying source code?? I hope that Circle plans on spending $$$ to improve and enhance the code!

Everyone that owns BTC has some interest in improving BTC, so things will move forward. BTC attracts very very skilled people, don't underestimate this!

Greed is one of the best sources of innovation! It is a powerful incentive for extremely advanced companies ;)

 I love your optimism!!! I'm going with it!!!!

You should know how many times you use linux or take advantage of Linux each and every day without you even knowing it.

You mean chrome, the browser built on top of the open-source chromium project?

Sure, but take PostgreSQL, open-source database system I'd venture to say is better in many ways than MySQL (and also many proprietary database systems). No major corporation there. Wordpress -> Drupal (no corporation, less popular but still in the loop). Apache -> Apache is a foundation.

VLC is an open-source media player. LogMeIn is remote control software. You were thinking of VNC I guess? VNC (which is just a system describing server-client interaction to share a screen, basically) includes all features software like LogMeIn or TeamViewer has, but it doesn't have a whole lot of applications that 'present it nicely'. I'll give you that.
VLC on the other hand is one of the best media players to roam the earth.


You must understand this directly contradicts everything bitcoin stands for?


My good lord.

1. Core developers, and the bitcoin community as a whole, are very rightly conservative when it comes to making decisions about bitcoin's future. If everyone would agree in a heartbeat I'd say something is quite wrong.
2. 5 years is almost no time at all. And to say there's been almost no progress? Are you kidding?
3. The core client will go to version 1.0 when it's good and ready.


Yes. Yes. Apple has in 5 (more like 30) years managed to become the crappiest company in the world by building a computer and a phone.

Your definition of mainstream is just wrong.

TL;DR: the main point is that Pay by Fee isn't a simple issue, and it’s as much a technical issue as it is one of human nature.


To be fair, I think (but am not sure) it was luke-jr who initially decribed this (https://github.com/bitcoin/bitcoin/pull/1647), and jdillon who expanded on it (https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189).

Also, I don't think you have the description quite right.


I think you mean, "If a scammer tries to double-spend their own Bitcoin by sending out two transactions, one legit and one back to themselves, there is some chance they will succeed and the receiver/vendor will be none-the-wiser until it's too late."

I don't understand where the percentages you go on to quote come from, though. There is some chance that the receiver/vendor will see the legit transaction in their memory pool, and some chance they will see the scamming transaction (and react accordingly), but it's not 50/50. Likewise with the chances that one transaction will end up succeeding over the other.


I think you mean, "If a scammer sends out two transactions, one legit and one back to themselves, the receiver/vendor will eventually (assuming a significant majority of the network/miners is using Replace by Fee) see the scam transaction, which is good for the receiver/vendor, so the receiver/vendor can send another transaction paying 100% of the output of the transaction to a transaction fee (to a miner). Scammer receives nothing, but neither does the vendor.

No arguments from me here.


You're assuming that all receivers/vendors will be smart enough to check for this situation and react to it quickly (which might be the case one day, but the reality is that there will be a transition period while this is not the case). You're also assuming that the scammer is choosing to act rationally.

Even if the scammer only has a low likelihood of success, I don't see why a scammer wouldn't try anyways. Some percentage of the time the scammer would fail and would end up paying for their merchandise (although they'd be paying a miner instead of the vendor). Some other percentage of the time, the scammer would succeed and get their btc back. It seems to me that the scammer, at least during the transition period, has nothing to lose by trying, and is guaranteed to at least deprive the receiver/vendor of their payment.

To be fair, jdillon also had a clever solution to this problem (linked above), but it involves requiring all senders/consumers to overpay for their merchandise/service, and then trust the receiver/vendor to refund them the difference after the tx has been confirmed, which seems unfriendly at best.

The bottom line is that Pay by Fee seems likely to completely eliminate zero-conf transactions, or at least during the transition period. Some would argue that this would be a good thing, but I'd rather let receivers/vendors have the choice to make their own risk/benefit analysis.

(I can't believe I'm letting myself get dragged into this, I should know better...  ::) )


Let's see, how about:

• this server we're all posting to
• Google
• the phone in my pocket (IDC says Android has a 78% market share as of 4Q13)
• the TomTom in my car
• the wireless router under my desk (and possibly your wireless router too)
• 485 out of the top 500 supercomputers (as of June 2014)
• the International Space Station (where it replaced Windows in 2013)

It really is all over the place these days, despite it's low desktop OS adoption rate.


Or maybe Safari, the browser built on top of the open-source (though Apple-backed) WebKit project?

That's what I was referring to, yes.


The percentages did indeed come out of thin air. I was assuming that the scammer can send directly to the sender and at the same time to everyone else. Right now, if I understand the system correctly (and depending on the wallet of course), the victim keeps his version of the transaction in his memory pool while sending it, and rejects the double-spend until it gets included in a block.
And the scammer doesn't need to do this manually - he can have software do it for him.

Yes.


I did forget about jdillon's solution. Assuming it takes 13 seconds for a transaction to propagate through the network, and a block is found once every ten minutes (600 seconds), there's less than a 13/600 chance (oversimplified, but you get the idea) of a double spend getting into a block before the victim sees it, then another less than 13/600 chance of the transaction being included in a block before the scorched earth transaction is seen (if the scammer has a miner friend then all bets are off anyway remember). The merchant doesn't need to do any of this manually; their software will do it for them. So you need to overpay by 13/300, or about 4.33%. If 4.33% is a significant amount when I'm getting it back later, you bet I'm waiting for confirmations anyway if I'm receiving the money. Hopefully, merchants will offer the choice of temporarily pay 4.33% or stay around for a confirmation, then I can make the choice depending on the size of the transaction. And if the merchant steals 4.33% on a small transaction, they'll cost themselves more in trust than they gain in the transaction.

As for the transition period, you can't be afraid to implement improvements because it will temporarily make life difficult. You'll never improve anything that way. The bitcoin community has shown itself to be fast to upgrade when it's important.
EDIT - The very thread you linked shows a case where 0 confirmation transactions were temporarily insecure because of an upgrade.

OK, I'll buy that. So there's a non-zero chance that the scammer will get away with it scot-free (get their btc back), but in every scamming attempt, the scam attempt will result in a 587/600 chance that the receiver doesn't receive any btc (unless they want to try a cat-and-mouse game of some sort with the scammer up until the next block is found).

A rational scammer will only try this scam if their expectancy is > 1, in other words if the refundable fee is < than some smallish %. But a scammer who places value on the thought that the receiver will not get paid can execute the attack at will (albeit in return for the surcharge), with the added bonus that they also might get their btc back.

This means that the vendor needs a higher refundable fee to discourage such practice, and they also need to add a non-refundable surcharge to cover their losses. As long as this surcharge is less than 3-ish percent, it will be comparable to credit cards (which removes an advantage of Bitcoin from a vendor's point of view).

Now that Bitcoin is gaining some public traction, explaining all this from a PR point of view would be just about disastrous, if you ask me. To consumers: you have to pay an extra 10%, but it's refundable. To vendors: any consumer who wants to can rip you off, even though they aren't likely to benefit financially, so it probably won't happen much.

But more importantly, what is it that we'd be left with? A more complicated system (both technically and PR-wise) that that accomplishes the same thing as what we had before: instant payments still aren't guaranteed, and so they cost the receiver. So where's the advantage?

If anything, I'd prefer a Pay by Fee that didn't include scorched earth. At least there I see some small advantage: nobody should trust zero-conf transactions (although I still don't like it).

So absolutely anyone who wants can become a criminal for absolutely no financial gain!
Remember, most physical goods stores have video cameras already to catch people who are shoplifting. Now we have a situation where for the potential scammer:
Risk:
- Guaranteed to lose the (small, but non-zero) extra money they paid (which can be increased slightly to account for this situation)
- Likely to become a criminal, and face a prison sentence
- Likely to be banned from the store for life, or at least have to wait around for one confirmation from then on whenever they go to the store
Reward:
- Small satisfaction that the store won't receive money

The number of people who would be willing to risk this is very small. Again, if the transaction is large enough that this happening occasionally poses an actual threat to the business, the business should be smart enough to make the customer wait for confirmations on either system.

EDIT: (late edit, but better late than never and there are no replies yet so it should be okay)
The advantage is as such:
Currently, accepting a 0 confirmation transaction runs the risk that a scammer will create a transaction (via software remember) paying a utxo to themselves, and another paying it to a merchant's address. They have some direct connection to the merchant - I don't know how they acquired this, but they have it (yes, that is possible if they can find the merchant's IP, which depending on the merchant might not be difficult). But the merchant and the scammer also have other direct connections. So the scammer simultaneously sends the transaction paying a utxo to the merchant, and the transaction paying it to themselves to all their other connections (with their software, not trying to manually click two buttons at once obviously). This gives them an advantage in network propagation, and the merchant sees the valid transaction. The merchant releases the items, and the scammer leaves; later the scammer's transaction is much more likely to end up in a block. This possibility makes it very risky to allow anyone to leave until their transaction has at least one confirmation.
With replace-by-fee and child-pays-for-parent, in the normal case, the merchant would immediately (via software, not manually) send a child transaction paying the temporary fee back to the customer. These would be confirmed in the same block in almost all cases, and the customer would never be without access to the temporary fee. The customer's software would pay this extra fee for them; the customer does not have to know about the fee at all (as long as they have enough bitcoin to cover it; if not they can stay around for a confirmation). The merchant's software would send the fee back for them; the merchant does not have to know about the fee at all. In the case of an attack as described above, the merchant's software would automatically send the scorched-earth transaction, costing the scammer his temporary fee and the entire balance of the transaction. Since almost nobody will be willing to pay just to screw a merchant out of a small amount of money, this is unlikely to happen and the merchant can allow the customer to leave immediately.

Replace by fee and child pays for parent are both must-have features IMHO.

Replace by fee without child pays for parent would make 0 transactions impossible to accept, as it would be trivial to double-spend back to yourself at any time before the transaction is included in a block.
Child pays for parent is useful, and poses no security risk; I really don't know why it isn't implemented.

I read a whole thread and i don't really understand you guys everyone is saying that child pays for parent isn't implemented yet but it is(if it means that you can spend unconfirmed outputs) a perfect example is luckyb.it (http://luckyb.it) you send the money to lets say green(yellow and red also applies) and they instantly spend your coins as a payment back. And if it's not that case what you all meant i am almost sure that eligius did implemented the child pays for parent feature. Correct me if i am wrong.

That's part of it, and it is available to miners, but as I understand it, few have implemented it at this time. Here's an explanation from Stephen Gornick on Stack Exchange:


EDIT: Although some miners must have, because I used it to recover a stuck transaction the other day.

Sorry to disrupt such great discussion, but I just had to point out that BitcoinGirl - with a female avatar of course - named herself... Scott  LOL

/offtopic. please continue.