Quote from: btchris on August 06, 2014, 11:34:20 PM

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

Quote from: CJYP on August 06, 2014, 09:30:48 PM

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:

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.

That's what I was referring to, yes.

Quote from: btchris on August 06, 2014, 11:34:20 PM

Quote from: CJYP on August 06, 2014, 09:30:48 PM

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

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.

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.

Quote from: btchris on August 06, 2014, 11:34:20 PM

Quote from: CJYP on August 06, 2014, 09:30:48 PM

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.

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.

Yes.

Quote from: btchris on August 06, 2014, 11:34:20 PM

Quote from: CJYP on August 06, 2014, 09:30:48 PM

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

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