Quote from: d5000 on August 25, 2020, 09:38:20 PM

The use case I originally had in mind, as I wrote above, is an exchange or web wallet which would allow its users to "withdraw coins to a Lightning channel" with an onchain payment. Of course, if the exchange itself is connected to LN, and the channel of the user who wants this kind of payment is bidirectional, a direct LN payment is a better alternative. But there are cases where an on-chain payment could be preferrable:

- if the user wants to increase his LN capacity
- if he has only an unidirectional channel
- if the service provider (exchange, wallet etc.) isn't connected to LN, for example for regulatory reasons (I read this argument somewhen, but I dunno if it really realistic)

In a future with a more complex LN protocol wrt fees (currently the opener pays everything, which is a bad incentive for such entities to directly open a channel), the exchange could just open the channel and pay the opener through the first commitment transaction pair ?

Quote from: d5000 on August 25, 2020, 09:38:20 PM

In these cases, for the service provider it doesn't matter to which address he pays, as long as the transaction is under control of the customer. The service provider simply "hands out control" of the used UTXOs to the customer and deducts the amount of them from the user's balance.

Yet another fundamental thought

. In a future where a high number of people use Bitcoin LN won't be enough and we definitely need a way to:
- Allow a shared management of utxos
- Allow to hand utxos as you describe (without an onchain tx, so maybe hand the control of a LN channel ?)

To the best of my knowledge the closest proposal to that are channel factories.

Quote from: d5000 on August 25, 2020, 09:38:20 PM

So in this case, if I interpret the SIGHASH variants right (according to the above linked article), I could imagine a combination of SIGHASH_ANYONECANPAY with SIGHASH_NONE (if a whole UTXO under control of the service provider is used, the service provider simply "hands it out" to the customer and deducts the amount from his balance once the tx is confirmed - no matter to what address) or SIGHASH_SINGLE (if a part of the coins has to be transferred to a change address of the service provider) could be used for this kind of withdrawals.

By signing a transactiono using ACP|NONE you are giving the control not only to your customer but to anyone who claims it, so basically the first miner to include the tx

.

The only way to securely hand an utxo (still, that i know of) is currently to unlock it and re-lock it to the receiver through an on-chain transaction. There might exist some more complex design to hand the *control* or *part* of the utxo (re channel factories).