Onchain deposit with PSBTs

[Jacksper13]

While lightning has many objective advantages over using bitcoin onchain, managing a node is burdensome, and most people give up and rely on third parties to host and manage their liquidity, giving up on some of the privacy benefits lightning offers. The option to receive funds onchain is already a reality in robosats, but a fully onchain bitcoiner would not be able to complete a transaction because the current security deposit method only supports lightning.

Here's a proposal for a PSBT based deposit method:

The taker signs a PSBT for an amount of X, with a fee rate of Y, TO THEMSELVES. Essentially just a signed promise to send funds to themselves, and submit that as the deposit method. When the transaction is successfully closed, Robosats would delete the PSBT, and the transaction would close purely onchain, with no onchain traces or fees for the taker. Let me break it down:

• The amount X is irrelevant, could be as little as dust (500-ish sats?), or as much as 10btc is the taker wants to. This part is irrelevant to the proposed methodology, the interesting part comes in the Y amount.

• The fee rate Y should be selected so that the total fees it generates are equivalent to AT LEAST the deposit amount. So if the taker is trying to close a trade and they need to deposit 100,000 sats, the fee rate Y should be such that the total fees amount to at least 100,000 sats. That means, if the taker submits a PSBT with 200,000 sats in fees, that should also be considered a valid deposit.

What happens if the taker tries to spend the UTXO from the PSBT?

Let's say the taker wants to cheat after they submit the PSBT as deposit method:

If the taker tries to spend the underlying UTXO, the moment it hits the mempool, the coordinator sees that a UTXO from a PSBT it holds is trying to be spent. Cheat detected. Coordinator releases deposit PSBT to mempool. For the cheating taker to be able to circumvent the released PSBT, they would need to use a higher feerate than that of the PSBT they signed previously. Meaning that in order to avoid paying the fees incurred by feerate Y, they would have to pay the fees incurred by feerate Y+1. They would essentially pay more than the cheating fee in miner fees when trying to avoid it. This removes the incentive to cheat on the taker side.

The cheating taker could in theory create another PSBT and shadow mine it submitting directly to a miner so the coordinator never sees it in the mempool, but they would also not be incentivized to do this because:

1. If they did it after submitting the PSBT and before making the payment, the moment the transaction is mined Robosats would detect the UTXO as spent in the blockchain and automatically cancel the transaction (and penalize the taker with not being able to take another offer in Z amount of time). No loss of funds would happen for the maker, nor the taker.
2. If they did it after submitting the PSBT and after making the fiat payment, Robosats would detect the UTXO was spent onchain and would close the trade, so the taker would be hit with a double punishment, paid fiat funds and deposit fee burnt. Definitely not interested in doing this.
3. If they did it after submitting the PSBT, making the payment, and the maker closing the transaction, that would even make less sense, because the PSBT was going to be deleted by robosats and the UTXO was gonna be unlocked anyway.

Therefore, no real incentive for the taker to cheat after submitting the PSBT. And if they spend it before submitting the PSBT, well, the PSBT will be invalid.

Stuff Robosats would have to keep an eye on

• Monitor the mempool to see if any of the UTXOs form the PBSTs held hostage show up. If so, release the corresponding PSBT.
• Monitor the blockchain to see if any of the UTXOs form the PBSTs held hostage show up. If so, cancel the corresponding transaction.
• Every time a PSBT is uploaded, check against all the other PSBTs held hostage, and make sure no other PSBT uses the same UTXO. If so, ask for a new PSBT as the uploaded one is already being used in another transaction (no penalties to taker, just try again with another PSBT)
• Check that the UTXOs form the PSBT are valid and have not been spent

Could the taker cheat or collude with robosats to benefit from this?

There's no real incentive, since funds are going to be sent back to the taker, it doesn't matter if they put 500sats or 10 btc in the transaction. Any corruption/collusion would only burn the senders deposit, the same way that the existing architecture would "not unlock" their deposit. Not a risk, since no one benefits from it.

This also streamlines the UX, since users can create their own PSBTs offline and not have to receive any address from robosats to commit the PSBT to.

Is it important that the PSBT is sent to the taker?

It is essentially up to the taker to decide this since it's them the ones creating the PSBT. While there is no way of knowing if the receive address defined belongs to the sender or not, takers would be encouraged to create PSBTs that send to themselves. Mostly because this removes any incentive to cheat for any other party, and if things go south takers would probably want to keep whatever funds they committed to that transaction and only lose the fees.

Why the deposit fee or higher?

One of the cool things of this is that the user could create one PSBT and use it over and over again to take multiple offers over time. So if a user creates a PSBT burning 500,000 sats in fees, they could take any offer that requests for 500,000 sats or less in deposit.

Why is it so cool?

A taker could use their Passport for example, create a PSBT with some cold storage funds, save it on an sd card and take it on a trip with them, be able to buy bitcoin on the go using cold storage funds as collateral without needing to actually have access to them while transacting, and without needing any internet connected lightning hot wallet.

Besides, this would be even more private than lightning since no onchain transaction would actually take place for the deposits, which also makes for a very elegant solution. Plus, saves fees onchain and routing fees to the taker.

Ideally the PSBT would also be able to be submitted via QR code, so air gapped deposits are possible.

Are there any risks?

The only problem is that we would need to make sure to that Robosats deletes the PSBT after the transaction has been finished. A buggy or rogue client keeping these could burn the fees for the takers. Again, the risk is minimized because the worst that can happen is that the deposit fee is burnt, but no one would be able to steal any funds.

[Reckless-Satoshi]

Hey @Jacksper13 This is a very cool idea! Thanks for bringing it and writing it down in such a detailed way.

This is an alternative to the bondless taker method we discussed long time ago and discarded as too risky for makers. I see this as, makers/sellers can optionally allow PSBT takers . Maker/sellers know that in case their peer cheats, they will not be compensated (in contrast to LN bonds) but they also know that allowing PSBT takers creates a bigger market for them and their takers will be equally committed to complete the trade fairly.

In addition to add this new bond method via API. For the UI wise, we could show a new toggle when the taker invoice is show to Submit PSBT bond. This creates a tiny bit more extra complexity. However, once submitted, in the next step, users will not be shown the option to submit a LN invoice for payout, they will only be able to submit an Onchain Address (the only reasonable option after choosing PSBT as bond method).

[KoalaSat]

Hi @Jacksper13 , Very cool approach!

I read it when you created it and lastly I realized one small sugestion. Did you consider to assign to this feature its own derivation path?

The fact that these transactions doesn't have expiration dates makes me a little bit uncomfortable and to think some bad actor might be collecting these burn transactions for my main wallet is a little bit disturbing.

I understand the scenrario is unlikely to happen and will only work for those actors that just want to watch the world burn. But if all these transactions points to a derivation path specifically assigned for potentiall burns, would make me feel way better to know that I'm not exposing my main wallet with my funds.

[Jacksper13]

Hey @KoalaSat thanks for the reply!

I'm not positive I see the advantage of using a custom derivation path. What you are doing here is providing a valid spendable transaction to an existing UTXO. It doesn't matter if that UTXO is part of your main wallet, or a custom derivation path. Anyone that steals that signed PSBT will be able to broadcast that transaction (to the destination you predefined, at the feerate you predefined - remember they can't change the destination address or anything like that). The point is, anyone stealing this will only have the ability to broadcast it, nothing else. The rest of your wallet is safe, since this PSBT defines the spending conditions of that one UTXO. They wouldn't gain access to any of the other UTXOs in your wallet.

To you point, ideally you would only have one or two PSBTs that you use for this, instead of rotating through all the available UTXOs in your wallet. A successful trade means the UTXO is never spent, so you can use the same PSBT for another trade. This way you would be limiting the amount of UTXOs "exposed". In any case, remember that the destination of the PSBT is your own wallet, so "exposing" would really just mean someone making you burn some sats in fees, equivalent to the penalty of a regular trade, say 3%.

Besides, one of the cool things about PSBTs is that you can use your funds as a collateral without any onchain movement. Moving funds to a custom derivation path already means at least one onchain movement, at which point we might just want to send the funds to a custom script that allows Robosats to spend the funds in the first 25 hours since the trade began and the original owner after that. It's just not as elegant.

After thinking more about this though, I realized I made one mistake in my statement above. Even if the taker defines a high feerate for the PSBT, they really could reach out to a miner and pay them under the table to broadcast the transaction at <current_feerate> instead of <feerate defined in PSBT+1>. So there is that one edge case where this could be exploited - IF prices drop noticeably (more than feerate delta + fee charged by miner for shadow mining), IF the taker has not started the payment, and IF they know how to reach out to a miner to shadow mine the transaction for a regular mining fee, it is possible that they could take an offer, wait 23 hours, then execute this and let the trade expire to just buy at a cheaper price. No one would lose funds here, but the taker could not be punished for leaving the trade. They would be forced to pay an onchain fee, but this would be far from the actual punishment fee. In all honesty though, the price drop has to be considerable and in a very short timespan - in these scenarios the feerate typically spikes, and miners tend to charge more when fees are high to include a custom transaction, making the price difference probably not worth the effort, so I am unsure about the real life feasibility of this "attack".

[KoalaSat]

@Jacksper13 thanks for the long reply! Under that circumstances I would just say that coin selection is a very necessary step for a secure PSBT

[Jacksper13]

@KoalaSat absolutely it is, yes! That would be outside of what Robosats needs to worry about though, and more in the hands of companies like Foundation where we would have to make an intuitive and comprehensive flow to create the PSBTs required to buy with Robosats. Robosats would only need to check that the PSBT format is valid and the funds are within the limits required for each trade.