Delayed Replace By Fee (RBF)

[phelix]

The latest attempt to add RBF to Bitcoin Core might cause unexpected delays in user experience by vendors waiting for (sender controlled opt-in) RBF. Would it be possible to modify RBF so that the transaction replacement is delayed? E.g. disregard replacement tx if the original tx has been in the mempool for less than six blocks. This way zero conf tx should not be affected, still stuck transactions could be fixed after some waiting time.

background: https://www.reddit.com/r/Bitcoin/comments/3ul1kb/peter_todds_rbf_replacebyfee_goes_against_one_of/

[watashi-kokoto]

zero-conf acceptance is doomed.

For commerce between people who trust each other, they don't need Bitcoin.

They can simply send each other email "I owe you 5 bucks" and be done with it


Bitcoin main purpose is to enable commerce between hostile competing parties that hate each other such as but not limited to:
- commerce between greedy evil people and honest people
- blackmailer and victim. blackmailing is moral if the value is going to be used for greater good or prevent a very bad thing from happening that outweights the blackmailing itself (and perhaps fully >100% repaid to victim afterwards). Standard system solved this by making all blackmailing illegal and borrowing very affordable ubiquitous and cheap

- trade between competing / nations at war
- between corporations that compete / are at concurrency

so. in this point of view anybody would be foolish to not to try to cheat the opposing party

so most (if not all) BTC transactions should be considered doublespent by default

Therefore:

* There is a black market for zero-conf doublespending. It's simple: miner+payer scam the merchant  by sending coins back to myself (and xx% fee to miner) transaction is secretly delivered to miners. A honest looking payment is send to merchant. now payer+miner scam zeroconf merchant who already delivered goods. result: the payment will never go into blockchain and the send cash back to self is gonna stay in blockchain forever.
 
Replace by fee simply means the black market is now white market. But THE market is still THE same one.

* There is also a market for 1-block reversal. It's much smaller and much more expensive to do this (YY% of scam transactions).

* There is a market for 6-block reversal. It's much much more expensive (>99% of the fee) but anybody can be scammed this way. Since scammers get only 1% they don't care if evil miner or merchant get the rest. scammer still lost funds (scam failed) so this gonna never happen.

* There is a market for whole blockchain reversal . This means all bitcoin transactions ever happened are cancelled.
easiest way to do this is delete all blockchains. but somebody somewhere has hidden disk with a blockchain. so nuking the planet is perhaps necessary to archieve this goal.

[watashi-kokoto]

Uses of replace by fee

1. Urgent payments . Block space is forever limited. No matter the limit is 1MB, 1GB, 1TB. Mammoth blocks simply cannot be delivered to slow internet and memory limited users. But the demand is unbounded: A retard wanting to send 1 satothi to million addresses. This is technically valid (it's his coins he can do whatever).

So when you grow blocks to 1GB retards begin to put MP3 songs an cat images to blockchain for fun.

Replace by fee + small blocks is simple solution. The fee replacement is a simple mechanism to get ahead in the queue for confirmation.
Simply look at others 's fees. Pay a highest fee. Bingo you're the first one in queue now  

Small blocks + replace by fee = win win situation. crap flood minimal. all important payments processed quickly. zero fee dust stuck forever at the end of the queue.


2. Putting quickly changing data to blockchain. Let's say you have a fast pos chain  with 10 second blocks. You want to confirm the highest block on bitcoin chain and trust it when it gets 6 confirms. So each time pos chain new block is mined. You send another doublespend containing the new highest block ID on pos chain to bitcoin. with higher fee by 1 satoshi. This means your new transaction is now ahead in queue before your old transaction but they are doublespend so both cannot get into the block
So oldschool miner is gonna include the "oldest" (first seen). but RBF miner will include the latest one to earn the extra satoshi

This mechanism is very useful to trust shitty, centralized, low-hashrate shitcoins. Cross confirmation proves that shitcoin block got mined at time T and NOT earlier and NOT later.

[gmaxwell]

Satoshi would be disgusted.

If so why would the system's creator have put opt-in unconfirmed transaction replacement into the very first release of Bitcoin?

[pawel7777]

What major problem does this implementation solves? It will potentially harm BTC adoption and could be a pain for many (all?) merchants, so what's the gain?

[gmaxwell]

Don't miss the FAQ: https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/

[tl121]

Don't miss the FAQ: https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/

Look out for specious reasoning.  Like how to "optimize" functions that shouldn't be necessary in the first place, except on rare occasions.

[pawel7777]

Nice summary by Chris Pacia in this blog post:

https://chrispacia.wordpress.com/2015/11/29/on-zero-confirmation-transactions/

+ comment from a retailer (Adam Brown):

Excellent writeup. I’m a retailer that has accepted about 500k USD worth of 0-confirmation transactions and had no incidents of fraud due to just waiting a minute or two before processing. Sometimes it can be an hour between blocks and I didn’t want my customers to have to wait more than a minute or two for their gift cards.

I’ll write in the RBF detection code but I’m very frustrated at the direction this is going.

I’m also in the midst of writing a Bitcoin payment processor and this puts a hamper on a lot of the features I was planning on implementing

.

[phelix]

Nice summary by Chris Pacia in this blog post:

https://chrispacia.wordpress.com/2015/11/29/on-zero-confirmation-transactions/

This article sounds a bit biased. E.g. it says:

retailers will be able to detect unconfirmed RBF transactions and reject them

But there is no need to "reject", you just don't process these transactions until you have some confirmations. Users that "opt-in" on RBF might have to wait longer in some situations.

I still wonder how this is supposed to be handled on the sender user interface - it seems very difficult to explain the implications to a normal user ("click here so your transaction is less likely to get stuck in the network but more likely to be delayed on the recipient side"?)

FSS-RBF certainly is a better solution from a user perspective even if it is less elegant protocol wise. Maybe it will also be added at some point. Or the awesome "Delayed-RBF" solution in the OP  


edit: btw is it only me that considers the use case for RBF of "Paying multiple recipients in succession" pretty irrelevant? Currently this is simply done by batching transactions so the practical cost savings will be minimal.

[medUSA]

I support the concept of introducing a mechanism to speed up confirmation, may it be RBF or CPFP (or some other). I actually would like this mechanism to offer ways for both the sender and the recipient to speed up confirmations. Replace By Fee (RBF) can be achieved by simply decreasing amount sent to change address (more to fees). If the sender can sign with the source addresses and one of the change address. I don't see merchants exposed to increased risk of double spending/scamming.