Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-08 📝 Original message: The locktime is basically ...

📅 Original date posted:2017-02-08
📝 Original message:
The locktime is basically useless.
The reason for the locktime was to give bob time to reclaim the bounty
before Alice can broadcast TX2.
But with AliceSecret1 in TX2, if alice ever broadcast and take the bounty,
Bob can confiscate TX2:0.

AliceSecret2 is courtesy of Alice, so bob can get the bouncy back. It is
unsafe to Bob to start using the channel before he could reclaim the bounty
with some confirmation.

On Wed, Feb 8, 2017 at 7:25 PM, Tier Nolan <tier.nolan at gmail.com> wrote:

> On Wed, Feb 8, 2017 at 9:32 AM, Nicolas Dorier <nicolas.dorier at gmail.com>
> wrote:
>
>> Tadge had an idea so we do not need any nTimeLock:
>>
>
> I think the nLocktime for TX2 is basically costless. It just prevents
> channel fast initial channel close.
>
> Once an unchanged version of TX1 is in the blockchain, all further updates
> of the channel can exclude the nLocktime..
>
> > 1 BTC Bob+Timeout OR Alice+AliceSecret1 OR Bob+AliceSecret2 (aka the
> bounty)
>
> This is so that Alice can unlock the bounty once the channel is setup, as
> a courtesy?
>
> _______________________________________________
> 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/20170208/e7ea62f6/attachment.html>;