📅 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>;
Nicolas Dorier [ARCHIVE] /
npub1hu…9q4u3
2023-06-09 12:47:02
in reply to nevent1q…yw9l
Author Public Key
npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3Published at
2023-06-09 12:47:02Event JSON
{
"id": "9371c1c48580eec1818c80a720e5dc342d8823fc10d3ab0b46a848919b963cb9",
"pubkey": "bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57",
"created_at": 1686314822,
"kind": 1,
"tags": [
[
"e",
"9ea054313bf60f8de6d3bffeb1c78d06c11e96e42cc896b7e3b1ee263032c084",
"",
"root"
],
[
"e",
"955324e6aced3f6f212b04bba57d15dc5c1d3dbdbf4f15d1be0febd3c3882269",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2017-02-08\n📝 Original message:\nThe locktime is basically useless.\nThe reason for the locktime was to give bob time to reclaim the bounty\nbefore Alice can broadcast TX2.\nBut with AliceSecret1 in TX2, if alice ever broadcast and take the bounty,\nBob can confiscate TX2:0.\n\nAliceSecret2 is courtesy of Alice, so bob can get the bouncy back. It is\nunsafe to Bob to start using the channel before he could reclaim the bounty\nwith some confirmation.\n\nOn Wed, Feb 8, 2017 at 7:25 PM, Tier Nolan \u003ctier.nolan at gmail.com\u003e wrote:\n\n\u003e On Wed, Feb 8, 2017 at 9:32 AM, Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Tadge had an idea so we do not need any nTimeLock:\n\u003e\u003e\n\u003e\n\u003e I think the nLocktime for TX2 is basically costless. It just prevents\n\u003e channel fast initial channel close.\n\u003e\n\u003e Once an unchanged version of TX1 is in the blockchain, all further updates\n\u003e of the channel can exclude the nLocktime..\n\u003e\n\u003e \u003e 1 BTC Bob+Timeout OR Alice+AliceSecret1 OR Bob+AliceSecret2 (aka the\n\u003e bounty)\n\u003e\n\u003e This is so that Alice can unlock the bounty once the channel is setup, as\n\u003e a courtesy?\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170208/e7ea62f6/attachment.html\u003e",
"sig": "27311a3cd2b772072c39c4fb57214351f846c7d05e81fa583af53fbb1defa1c6b35763cc1c30acc9ed7c5fd5b4f0554df82523add909db3b6b5588ab2fd88dba"
}