Hi Dave,
> Is swap-in-potentiam[1] an option here?
While this could work, it does require more on-chain transaction bytes
since you first make a SiP transaction then settlement transactions.
My goal was to design something with the smallest on-chain footprint
possible.
> I think that's the same number (and approximate size) of transactions
that you'll get from the SIGHASH_ANYPREVOUT|SIGHASH_SINGLE solution you
outline
My proposal avoids the settlement transactions entirely, and produces
only one transaction. With your example participants, it would produce
a single splice transaction with 4 inputs and 3 outputs:
- E's funding input
- {A,D}'s current channel input
- {B,E}'s current channel input
- {C,F}'s current channel input
- {A,D}'s new channel output
- {B,E}'s new channel output
- {C,F}'s new channel output
While the number of inputs/outputs stays the same, we're paying for the
common transaction fields only once instead of N times (where N is the
size of the batch). For larger batches, in a high-fee future, I believe
this could be significant?
Thanks,
Bastien
Le mar. 24 oct. 2023 à 06:41, David A. Harding a écrit :
> On 2023-10-17 03:03, Bastien TEINTURIER via bitcoin-dev wrote:
> > Good morning list,
> >
> > I've been trying to design a protocol to let users withdraw funds from
> > exchanges directly into their lightning wallet in an efficient way
> > (with the smallest on-chain footprint possible).
>
> Hi, Bastien.
>
> Is swap-in-potentiam[1] an option here? For example, Exchange E wants
> to pay users A, B, and C, who each have different counterparties. Then:
>
> - E gets from each of A, B, C a public key for their separate
> counterparties (e.g., D, E, F)
> - E gets confirmed a transaction paying three swap-in-potentiam outputs,
> one each for {A,D}, {B,E}, {C,F}
> - Each of the parties then offchain spends the SiP outputs into a
> standard LN-penalty channel construction and starts using it
> - Ideally, before the SiP expires, each party is able to drain the
> channel into their other channels and mutually settle it with just an
> onchain spend of the SiP output
> - Non-ideally, the previously offchain spend of the SiP output that
> established the LN-penalty channel is put onchain
>
> In the best case, this involves four transactions:
>
> - E's one-input, four-output batch withdrawl (the fourth output is E's
> change)
> - Three separate one-input, one-output transactions to settle the SiP
> outputs
>
> I think that's the same number (and approximate size) of transactions
> that you'll get from the SIGHASH_ANYPREVOUT|SIGHASH_SINGLE solution you
> outline, although your solution allows the channels to remain open
> indefinitely, whereas the SiP solution has an expiry.
>
> -Dave
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003810.html
> (I know Eclair already uses SiP; the above reference is for other
> readers)
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
