tbtc
tbtc copied to clipboard
keep-network
Redemption via Lightning
Background
tBTC is a Bitcoin peg protocol. One tBTC is always backed by a real BTC, and the collateralisation is designed such that there is no loss to a user if the cross-chain redemption fails.
Looking at deposit and liquidate flows, it's clear they do the same thing - verify that the peg exists. Redemption in contrast, is proving something different - verifying that Bitcoin was sent from an address, after the redemption request.
Concept
The redemption flow currently requires the signer group to post proof of a Bitcoin transaction. It is likely we can change the redemption proof, such that alternative proofs of payment, such as artifacts from the Lightning network/protocol are supported. This has the potential to vastly improve UX.
Resources
a very simple change to support this is a ackRedemption contract call, that is gated to the redeemer. It would shortcut the redemption process.
a more complex version would be to add a redemptionAckHash system, where the redeemer could (optionally) supply a sha2 digest. if the preimage is revealed, it's treated as ackRedemption
Redemption via Lightning is also a sweet improvement to Lightning- folks would be able to get network capacity.
How would signers accomplish this, though?
How would signers accomplish this, though?
Academic question until larger channels exist
Can't the redeemer post an invoice on-chain at redeeming time, and the signers would provide proof of payment via preimage? This would be similar to an Atomic Multipath Payment, where you have N senders instead of 1.
a very simple change to support this is a ackRedemption contract call, that is gated to the redeemer. It would shortcut the redemption process.
This requires invoiceless-payments (ie Sphinx) https://github.com/lightningnetwork/lnd/pull/2455. We can add it in the docs as a possible improvement, but I find it much more complex since you'd need to verify the logic on Ethereum.
a very simple change to support this is a ackRedemption contract call, that is gated to the redeemer. It would shortcut the redemption process.
This requires invoiceless-payments (ie Sphinx) lightningnetwork/lnd#2455. We can add it in the docs as a possible improvement, but I find it much more complex since you'd need to verify the logic on Ethereum.
Oh I mean in general, in addition to lightning. If the redeemer is willing to attest that they got paid, the Deposit should respect that.
If the redeemer is willing to attest that they got paid, the Deposit should respect that.
Right but the redeemer can be unwilling to attest that they got paid, which can be dangerous for the signers' collateral. With on-chain txs that cannot happen, because the Signers can publish the SPV proof that they paid the user, but with off-chain txs you need some similar proof, in this case the invoice preimage (or sphinx payment proof)
I mean use redeemer attestation as a shortcut that falls back to any other provable delivery method
I think the term here is data availability attack @gakonst and it's a good point.
Did some deeper research today (some more links above) - the preimage/submarine approach should work with LN invoices. Data availability aside - the preimage will always be made available otherwise the LN payment won't go through, no?