Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-27 📝 Original message: Hi ZmnSCPxj, It is stated ...
📅 Original date posted:2020-01-27
📝 Original message:
Hi ZmnSCPxj,
It is stated in the paper "Atomic multi-channel updates with constant
collateral in bitcoin-compatible payment-channel networks" and I am quoting
verbatim (page 11) (last email still waiting moderator approval) "Phase I:
Setup. The first phase requires to freeze the coins available at each
channel involved in the protocol. Doing this naively (i.e., locking the
complete balance in the channel at once) would lock more coins than
required, unnecessarily increasing the collateral in the protocol. Instead,
during the setup phase, the balance at each payment channel is split in
two, effectively creating thereby two sub-channels: one sub-channel is set
with the coins required for the present protocol session, while the other
one is set with the
remaining coins, which can then be freely spent. In the illustrative
example shown in Figure 4.2, the setup phase starts with the user A
collaborating with user B to create the transaction Tx A
setup , where they split the 10 coins they have in the channel in two
sub-channels: one sub-channel with 8 coins to be used in the rest of the
protocol session and one sub-channel with the rest (i.e., 2 coins). This
transaction is signed by both users so that it can be eventually enforced
on-chain if required. The rest of the users behave analogously. Note that
operations at each channel in this phase of the protocol can be carried out
in parallel." Does this sound good ?
On Mon, Jan 27, 2020 at 9:41 AM Subhra Mazumdar <
subhra.mazumdar1993 at gmail.com> wrote:
> Hi ZmnSCPxj,
> It is stated in the paper "Atomic multi-channel updates with
> constant collateral in bitcoin-compatible payment-channel networks". I am
> attaching the screenshot of the paragraph which mentions about locking the
> amount which is required for payment transfer and not the entire channel
> fund.
>
> On Mon, Jan 27, 2020 at 6:15 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Subhra,
>>
>> This does not seem to make sense?
>> For a payment that is less than the channel funds on your side, only that
>> amount is locked behind an HTLC, and the rest remains useable for other
>> HTLCs.
>>
>> What exactly are you referring to?
>>
>> Regards,
>> ZmnSCPxj
>>
>> > Hi,
>> > I was wondering when parties apply condition on fraction of
>> channel fund for ensuring successful payment, entire channel fund is held.
>> Is it possible to lock just partial amount of fund of a payment channel and
>> leave the rest to be used by some another payment request ? Concept of
>> subchannels of a single channel has been suggested in "Atomic multi-channel
>> updates with constant collateral in bitcoin-compatible payment-channel
>> networks"
>> https://scholar.google.com/scholar?cluster=40566801298747858&hl=en&as_sdt=2005&sciodt=0,5
>> but I am still in doubt what happens during closing of subchannel ?
>> > --
>> > Yours sincerely,
>> > Subhra Mazumdar.
>>
>>
>>
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/b8248846/attachment.html>;
📝 Original message:
Hi ZmnSCPxj,
It is stated in the paper "Atomic multi-channel updates with constant
collateral in bitcoin-compatible payment-channel networks" and I am quoting
verbatim (page 11) (last email still waiting moderator approval) "Phase I:
Setup. The first phase requires to freeze the coins available at each
channel involved in the protocol. Doing this naively (i.e., locking the
complete balance in the channel at once) would lock more coins than
required, unnecessarily increasing the collateral in the protocol. Instead,
during the setup phase, the balance at each payment channel is split in
two, effectively creating thereby two sub-channels: one sub-channel is set
with the coins required for the present protocol session, while the other
one is set with the
remaining coins, which can then be freely spent. In the illustrative
example shown in Figure 4.2, the setup phase starts with the user A
collaborating with user B to create the transaction Tx A
setup , where they split the 10 coins they have in the channel in two
sub-channels: one sub-channel with 8 coins to be used in the rest of the
protocol session and one sub-channel with the rest (i.e., 2 coins). This
transaction is signed by both users so that it can be eventually enforced
on-chain if required. The rest of the users behave analogously. Note that
operations at each channel in this phase of the protocol can be carried out
in parallel." Does this sound good ?
On Mon, Jan 27, 2020 at 9:41 AM Subhra Mazumdar <
subhra.mazumdar1993 at gmail.com> wrote:
> Hi ZmnSCPxj,
> It is stated in the paper "Atomic multi-channel updates with
> constant collateral in bitcoin-compatible payment-channel networks". I am
> attaching the screenshot of the paragraph which mentions about locking the
> amount which is required for payment transfer and not the entire channel
> fund.
>
> On Mon, Jan 27, 2020 at 6:15 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Subhra,
>>
>> This does not seem to make sense?
>> For a payment that is less than the channel funds on your side, only that
>> amount is locked behind an HTLC, and the rest remains useable for other
>> HTLCs.
>>
>> What exactly are you referring to?
>>
>> Regards,
>> ZmnSCPxj
>>
>> > Hi,
>> > I was wondering when parties apply condition on fraction of
>> channel fund for ensuring successful payment, entire channel fund is held.
>> Is it possible to lock just partial amount of fund of a payment channel and
>> leave the rest to be used by some another payment request ? Concept of
>> subchannels of a single channel has been suggested in "Atomic multi-channel
>> updates with constant collateral in bitcoin-compatible payment-channel
>> networks"
>> https://scholar.google.com/scholar?cluster=40566801298747858&hl=en&as_sdt=2005&sciodt=0,5
>> but I am still in doubt what happens during closing of subchannel ?
>> > --
>> > Yours sincerely,
>> > Subhra Mazumdar.
>>
>>
>>
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/b8248846/attachment.html>;