RBF question

[Picard78]

Hello Bitcoin Expert,

What happens currently if I create Transaction X, without RBF enabled, with UTXO A and then 1 minute later I create another Transaction Y with UTXO A.  Will the nodes receiving Transaction Y flag it as a double spend and reject it?

Thanks

[BrewMaster]

yes.

[Picard78]

Thank you for your responses.

Suppose I send Transaction X with RBF enabled.  Must the subsequent Transaction Y have the same Inputs and Outputs as Transaction X?  The only difference between Transaction X and Y allowed is a reduced Change value resulting in a higher transaction fee?

[o_e_l_e_o]

Suppose I send Transaction X with RBF enabled.  Must the subsequent Transaction Y have the same Inputs and Outputs as Transaction X?

No. Transaction Y can have any combination of inputs and outputs. All that is required for Transaction Y to replace Transaction X is that it spends at least one of the same inputs as Transaction X does, and it pays a higher fee. When Transaction Y is confirmed, Transaction X will become invalid because it now depends on at least one input which no longer exists.

As an addendum to this, there are a minority of nodes which will only support a form of RBF known as first-seen-safe RBF, or FSS RBF. In FSS RBF, Transaction Y is only accepted if it pays the same outputs as Transaction X.

[Picard78]

Thank you

[Picard78]

Is this a correct use case of RBF and transaction Locktime?

Delaying BTC payment until customer is satisfied with new Product

Suppose I have an agreement with a merchant to pay them 1 BTC upon the arrival of a new product.  The merchant tells me the product will arrive tomorrow.

I tell the merchant I want to inspect the product upon arrival and will release the 1 BTC to them once I am satisfied with the product.

I setup a RBF transaction with a Locktime that is 3 days from today and tell the merchant that if I am not satisfied with the product I will return the product and I will execute another RBF transaction that outputs the 1 BTC back to me.

Is this one application of RBF?

Thank you.

[nc50lc]

I setup a RBF transaction with a Locktime that is 3 days from today and tell the merchant that if I am not satisfied with the product I will return the product and I will execute another RBF transaction that returns the 1 BTC to me.

No, you wont be able to broadcast that transaction before the set locktime, using RBF isn't necessary in that case.
You can give him the signed RAW TX so he can broadcast it himself after the locktime;
if you're not satisfied, create a new TX spending the input of that RAW transaction before the locktime to invalidate it.

Plus, delaying the payment and "promising" not to make a replacement transaction involves a lot of risk for the merchant and trust to the buyer (you).

[Picard78]

Plus, delaying the payment and "promising" not to make a replacement transaction involves a lot of risk for the merchant and trust to the buyer (you).

Yes I was thinking exactly that.  This would give all the power to the buyer requiring tremendous trust in the buyer.

You can give him the signed RAW TX so he can broadcast it himself after the locktime; if you're not satisfied, create a new TX spending the input of that RAW transaction before the locktime to invalidate it.

Thank you.  This achieves the Use Case I was trying to create.  Again this would require tremendous Trust in the Buyer.  This is actually like writing a post dated cheque and giving it to the merchant.

 

[o_e_l_e_o]

This is actually like writing a post dated cheque and giving it to the merchant.

Not quite. Your proposed set up is much riskier from the merchant's point of view.

A post-dated cheque is not necessarily legally binding depending on your jurisdiction, and can often be cashed prior to the date of the cheque. There is disincentive for the payer not to write a bad cheque, in that they will be hit with fees and fines, their credit rating could suffer, and they could suffer criminal charges. The merchant can take legal action against them to cover the lost funds.

If you give a merchant a signed time locked transaction, there is absolutely no disincentive for you to invalidate that transaction prior to it being broadcast. Since you can hand out such a transaction without revealing any personal information, the merchant's options for legal recourse may be very limited.

Your set up is essentially no different to saying "Give me the goods, and if I like them, I'll pay for them later".

[Picard78]

Your set up is essentially no different to saying "Give me the goods, and if I like them, I'll pay for them later".

I agree.

The use case I see for signed time locked transactions is if I employ 20 people and I pay them in bitcoin at the start of each month.  I prepare my signed transactions ahead of time but add the security of locktime.  On the first of the month I simply run a utility that broadcasts my 20 prepared signed time locked transactions.

Is that the use case of locktime?

[o_e_l_e_o]

Is that the use case of locktime?

That's certainly a possible use, yes.

Bear in mind that in your scenario, since you are creating the transactions in advance, you would have to craft them from inputs which already exist. So if you are paying 20 people, then you would need at least 20 separate inputs to use at least one for each transaction. You couldn't have a single input of 2 BTC and 20 transactions which all pay out 0.1 BTC from that input, for example. As soon as the first transaction confirmed, all the others would be invalid since that input no longer exists.

Alternatively you would simply create a single transaction with 1 input and 20 outputs, but that raises privacy implications if your employees can all see how much each other are being paid.

[Picard78]

Bear in mind that in your scenario, since you are creating the transactions in advance, you would have to craft them from inputs which already exist. So if you are paying 20 people, then you would need at least 20 separate inputs to use at least one for each transaction. You couldn't have a single input of 2 BTC and 20 transactions which all pay out 0.1 BTC from that input, for example. As soon as the first transaction confirmed, all the others would be invalid since that input no longer exists.

Good point.  This is the way I envisioned it initially in my mind but I can see from your explanation how only 1 prepared transaction would go through.  So is the best way to implement this via Child Pays For Parent chain of 20 transactions?

Alternatively you would simply create a single transaction with 1 input and 20 outputs, but that raises privacy implications if your employees can all see how much each other are being paid.

Good point.

[HCP]

Delaying BTC payment until customer is satisfied with new Product

This is what escrow was designed for... customer gives BTC to escrow, merchant sends product to customer, escrow waits until customer is "satisfied" before sending funds to merchant.

If customer attempts to keep without paying, escrow can release the funds to merchant
If merchant doesn't send the item, or customer is not satisfied, escrow can return the funds to customer (after item is returned etc)
Escrow is essentially the mediator in any disputes and their decision will determine who ends up with the funds.

Can be achieved using a 2-of-3 multisig with customer, escrow and merchant... and using this method both the customer and merchant have "equal" risk (assuming the escrow is legit and not colluding with either party)

The problem is finding a "trusted and independent" escrow.

So is the best way to implement this via Child Pays For Parent chain of 20 transactions?

No, if, for whatever reason, you need to invalidate one of the transactions (ie. one person doesn't do their job as promised)... any transactions in the chain after it will also be invalidated as their inputs won't exist any more.

[Picard78]

So is the best way to implement this via Child Pays For Parent chain of 20 transactions?

No, if, for whatever reason, you need to invalidate one of the transactions (ie. one person doesn't do their job as promised)... any transactions in the chain after it will also be invalidated as their inputs won't exist any more.

True.  Thank you.