Topic: Feature Request for Bitcoin Core: Replace by Fee (Read 5522 times)

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.

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.

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 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.

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.

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

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.

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).

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.

(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?

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, and jdillon who expanded on it.

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.

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.

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

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

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

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.

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!!!

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

Blockchain infos custom send, does.

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.

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.