<p>I would not recommend the notion of a one way offline channel. Historically one way channels could have been build for a long time by offering new signatures for spending an output of a 2-2 wallet to the 2nd party in which more and more btc of the consumed input are given to the 2nd party. The second party naturally has an incentive to publish the latest of such tx. </p>

<p>Loop is more like a submarine swap. With <code>loop in</code> you request to get some balance on a payment channel to your side. </p>

<p>Let us assume you have a payment channel with 0.1 btc capacity but all the money is on your partners side. However you would like to add some funds to your side without rebalancing your channels or opening a new channel. </p>

<p>In order to achieve that you could create an invoice with a payment hash. A person might be willing to pay that invoice on lightning if you reimburse that person on chain. The question that loop solves is to make this process trustless.</p>

<p>You make an onchain btc tx to that person but encumber a second output which goes back to you with a timelock. The output that can be claimed by that person can only be claimed if the preimage of your payment hash is presented. This works directly before the timelock expires. </p>

<p>Now there are two cases. Either the person pays your invoice and receives a preimage and can be sure to get reimbursed. Or if the person does not pay the invoice you can reclaim your btc after the timelock. Noone needs to trust the other side. </p>

<p>What I don't know is if trezor allows to sign such a timelocked / special transaction and how the trezor api works. However I don't see any reason why it would not support signing such a transaction. </p>

CC BY-SA 4.0
2019-05-07T14:16:07.237Z
2019-05-07T14:16:07.237Z
Rene Pickhardt
<p>Am I oversimplifying? I feel like I must be missing some details.</p>

<p>Can I use my Trezor to sign loop in transactions in theory?</p>

<lightning-network><ln-loop>
I've been reading about "loop in" and it seems to be like a one-way offline channel, is that correct?
Clayton Rabenda
# I've been reading about "loop in" and it seems to be like a one-way offline channel, is that correct?

(Asked by: username_0 on 2019-05-07)

Am I oversimplifying? I feel like I must be missing some details.

Can I use my Trezor to sign loop in transactions in theory?

**Tags:** lightning-network, ln-loop


---

## 1 answers

### Answer by username_1 on 2019-05-07. Score: 1

I would not recommend the notion of a one way offline channel. Historically one way channels could have been build for a long time by offering new signatures for spending an output of a 2-2 wallet to the 2nd party in which more and more btc of the consumed input are given to the 2nd party. The second party naturally has an incentive to publish the latest of such tx.

Loop is more like a submarine swap. With `loop in` you request to get some balance on a payment channel to your side.

Let us assume you have a payment channel with 0.1 btc capacity but all the money is on your partners side. However you would like to add some funds to your side without rebalancing your channels or opening a new channel.

In order to achieve that you could create an invoice with a payment hash. A person might be willing to pay that invoice on lightning if you reimburse that person on chain. The question that loop solves is to make this process trustless.

You make an onchain btc tx to that person but encumber a second output which goes back to you with a timelock. The output that can be claimed by that person can only be claimed if the preimage of your payment hash is presented. This works directly before the timelock expires.

Now there are two cases. Either the person pays your invoice and receives a preimage and can be sure to get reimbursed. Or if the person does not pay the invoice you can reclaim your btc after the timelock. Noone needs to trust the other side.

What I don't know is if trezor allows to sign such a timelocked / special transaction and how the trezor api works. However I don't see any reason why it would not support signing such a transaction.


---

