Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-10 📝 Original message: Well two transactions to ...
📅 Original date posted:2017-02-10
📝 Original message:
Well two transactions to be confirmed is not too bad. Approximately 30
minutes. Compare that to the time it takes to apply for a prepaid debit
card.
So we have two possibilities so far without segwit: one transaction to be
confirmed but definite channel lifetime.
Or two transactions to be confirmed but indefinite channel lifetime.
Not sure yet what is the best from user perspective as channel renewal can
be done in the background.
On Fri, Feb 10, 2017 at 2:51 AM, "Christopher Jämthagen" <cjamthagen at gmx.com
> wrote:
> Two-layer HTLCs still need a malleability fix or some other workaround to
> avoid excessive timeouts.
>
> /Christopher
>
> *Sent:* Wednesday, February 08, 2017 at 5:16 AM
> *From:* "Nicolas Dorier" <nicolas.dorier at gmail.com>
> *To:* "Tier Nolan" <tier.nolan at gmail.com>
> *Cc:* lightning-dev at lists.linuxfoundation.org
> *Subject:* Re: [Lightning-dev] Anchor transaction for no expiration
> channels without segwit
> With this solution, is there any problem left without Segwit outside no
> third party channel monitoring and channel establishment which need to wait
> Bob bounty expiration ?
>
> On Tue, Feb 7, 2017 at 9:02 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>>
>> On Tue, Feb 7, 2017 at 2:39 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
>> wrote:
>>
>>> Good point, actually, a simpler way to do it, is for TX2 to be
>>> nTimelocked after bounty's expiration.
>>>
>>
>> That works too and keeps the transaction smaller.
>>
>> I think a symmetrically funded channel needs 4 1BTC outputs, so it is
>> pretty much two single funded channels. It would be slightly smaller than
>> 2 transactions to open the channel.
>>
>> TX1
>>
>> Input
>> 2 from Alice
>> 2 from Bob
>>
>> Output
>> 1: (Alice + Bob) OR (Bob + AliceSecret)
>> 1: (Alice + Bob) OR (Alice + BobSecret)
>> 1: (Bob + timeout(now + T)) OR (Alice + AliceSecret)
>> 1: (Alice + timeout(now + T)) OR (Bob + BobSecret)
>>
>> TX2
>> locktime: now + 2T
>>
>> Input
>> TX1/0: signed by (Alice + Bob)
>> TX1/1: signed by (Alice + Bob)
>> Output
>> Initial channel paying Alice & Bob 1BTC each
>>
>> ---------------------------------------
>>
>> Alice and Bob create TX1, sign it and share the result.
>>
>> Alice and Bob create TX2, sign it and share the result.
>>
>> Abort for those 2 steps:
>> * If one signs and the other doesn't then the signer should spend their
>> inputs to be safe.
>> * If TX1 is broadcast, then they can both spend their timeouts to
>> recover their funds, so it is safe.
>>
>> Once they both have signed versions of TX1 and TX2, they should broadcast
>> TX1. This initializes the channel.
>>
>> If TX1 is mutated, then they should both abort and spend their timeouts
>> and recover their funds.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
> _______________________________________________ Lightning-dev mailing
> list Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170210/a5c4bb17/attachment.html>;
📝 Original message:
Well two transactions to be confirmed is not too bad. Approximately 30
minutes. Compare that to the time it takes to apply for a prepaid debit
card.
So we have two possibilities so far without segwit: one transaction to be
confirmed but definite channel lifetime.
Or two transactions to be confirmed but indefinite channel lifetime.
Not sure yet what is the best from user perspective as channel renewal can
be done in the background.
On Fri, Feb 10, 2017 at 2:51 AM, "Christopher Jämthagen" <cjamthagen at gmx.com
> wrote:
> Two-layer HTLCs still need a malleability fix or some other workaround to
> avoid excessive timeouts.
>
> /Christopher
>
> *Sent:* Wednesday, February 08, 2017 at 5:16 AM
> *From:* "Nicolas Dorier" <nicolas.dorier at gmail.com>
> *To:* "Tier Nolan" <tier.nolan at gmail.com>
> *Cc:* lightning-dev at lists.linuxfoundation.org
> *Subject:* Re: [Lightning-dev] Anchor transaction for no expiration
> channels without segwit
> With this solution, is there any problem left without Segwit outside no
> third party channel monitoring and channel establishment which need to wait
> Bob bounty expiration ?
>
> On Tue, Feb 7, 2017 at 9:02 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
>>
>> On Tue, Feb 7, 2017 at 2:39 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
>> wrote:
>>
>>> Good point, actually, a simpler way to do it, is for TX2 to be
>>> nTimelocked after bounty's expiration.
>>>
>>
>> That works too and keeps the transaction smaller.
>>
>> I think a symmetrically funded channel needs 4 1BTC outputs, so it is
>> pretty much two single funded channels. It would be slightly smaller than
>> 2 transactions to open the channel.
>>
>> TX1
>>
>> Input
>> 2 from Alice
>> 2 from Bob
>>
>> Output
>> 1: (Alice + Bob) OR (Bob + AliceSecret)
>> 1: (Alice + Bob) OR (Alice + BobSecret)
>> 1: (Bob + timeout(now + T)) OR (Alice + AliceSecret)
>> 1: (Alice + timeout(now + T)) OR (Bob + BobSecret)
>>
>> TX2
>> locktime: now + 2T
>>
>> Input
>> TX1/0: signed by (Alice + Bob)
>> TX1/1: signed by (Alice + Bob)
>> Output
>> Initial channel paying Alice & Bob 1BTC each
>>
>> ---------------------------------------
>>
>> Alice and Bob create TX1, sign it and share the result.
>>
>> Alice and Bob create TX2, sign it and share the result.
>>
>> Abort for those 2 steps:
>> * If one signs and the other doesn't then the signer should spend their
>> inputs to be safe.
>> * If TX1 is broadcast, then they can both spend their timeouts to
>> recover their funds, so it is safe.
>>
>> Once they both have signed versions of TX1 and TX2, they should broadcast
>> TX1. This initializes the channel.
>>
>> If TX1 is mutated, then they should both abort and spend their timeouts
>> and recover their funds.
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
> _______________________________________________ Lightning-dev mailing
> list Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170210/a5c4bb17/attachment.html>;