📅 Original date posted:2017-02-08
📝 Original message:
Tadge had an idea so we do not need any nTimeLock:
TX1
Input:
1 BTC From Alice
1 BTC From Bob
Output:
1 BTC Alice+Bob OR Bob+AliceSecret1
1 BTC Bob+Timeout OR Alice+AliceSecret1 OR Bob+AliceSecret2 (aka the
bounty)
TX2
Input:
TX1:0 using Alice+Bob
Output:
1 BTC Alice+Bob+100 CSV OR Bob+AliceSecret1
So basically, if Alice try to broadcast TX2 and claim TX1:1 with
Alice+AliceSecret1, Bob can claim TX2:0 with Bob+AliceSecret1.
The condition Bob+AliceSecret2 in TX1:1 is useful such that Bob can claim
the bounty without having to wait the Timeout.
Channel establishment will basically take twice more time than a normal
channel with expiration.
On Wed, Feb 8, 2017 at 1:16 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170208/16bdb873/attachment.html>;
Nicolas Dorier [ARCHIVE] /
npub1hu…9q4u3
2023-06-09 14:47:02
in reply to nevent1q…2an3
Author Public Key
npub1huz53hq26gu7nc0qhw3uj6tr9hk5q2ngpywduxep5zy4ay9unftsm9q4u3Published at
2023-06-09 14:47:02Event JSON
{
"id": "7f446b3bac1f70e4003fdeb8a1baf157af1f62449dcfb7b9509459ceec68eb68",
"pubkey": "bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57",
"created_at": 1686314822,
"kind": 1,
"tags": [
[
"e",
"9ea054313bf60f8de6d3bffeb1c78d06c11e96e42cc896b7e3b1ee263032c084",
"",
"root"
],
[
"e",
"689cd3c8e11ead13c2e02d4e5a0ee5848f7389a5904db5fb765df4acc953a3b5",
"",
"reply"
],
[
"p",
"bf0548dc0ad239e9e1e0bba3c969632ded402a68091cde1b21a0895e90bc9a57"
]
],
"content": "📅 Original date posted:2017-02-08\n📝 Original message:\nTadge had an idea so we do not need any nTimeLock:\n\nTX1\n\nInput:\n1 BTC From Alice\n1 BTC From Bob\nOutput:\n1 BTC Alice+Bob OR Bob+AliceSecret1\n1 BTC Bob+Timeout OR Alice+AliceSecret1 OR Bob+AliceSecret2 (aka the\nbounty)\n\nTX2\n\nInput:\nTX1:0 using Alice+Bob\nOutput:\n1 BTC Alice+Bob+100 CSV OR Bob+AliceSecret1\n\nSo basically, if Alice try to broadcast TX2 and claim TX1:1 with\nAlice+AliceSecret1, Bob can claim TX2:0 with Bob+AliceSecret1.\nThe condition Bob+AliceSecret2 in TX1:1 is useful such that Bob can claim\nthe bounty without having to wait the Timeout.\n\nChannel establishment will basically take twice more time than a normal\nchannel with expiration.\n\n\n\n\nOn Wed, Feb 8, 2017 at 1:16 PM, Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e\nwrote:\n\n\u003e With this solution, is there any problem left without Segwit outside no\n\u003e third party channel monitoring and channel establishment which need to wait\n\u003e Bob bounty expiration ?\n\u003e\n\u003e On Tue, Feb 7, 2017 at 9:02 PM, Tier Nolan \u003ctier.nolan at gmail.com\u003e wrote:\n\u003e\n\u003e\u003e On Tue, Feb 7, 2017 at 2:39 AM, Nicolas Dorier \u003cnicolas.dorier at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Good point, actually, a simpler way to do it, is for TX2 to be\n\u003e\u003e\u003e nTimelocked after bounty's expiration.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e That works too and keeps the transaction smaller.\n\u003e\u003e\n\u003e\u003e I think a symmetrically funded channel needs 4 1BTC outputs, so it is\n\u003e\u003e pretty much two single funded channels. It would be slightly smaller than\n\u003e\u003e 2 transactions to open the channel.\n\u003e\u003e\n\u003e\u003e TX1\n\u003e\u003e\n\u003e\u003e Input\n\u003e\u003e 2 from Alice\n\u003e\u003e 2 from Bob\n\u003e\u003e\n\u003e\u003e Output\n\u003e\u003e 1: (Alice + Bob) OR (Bob + AliceSecret)\n\u003e\u003e 1: (Alice + Bob) OR (Alice + BobSecret)\n\u003e\u003e 1: (Bob + timeout(now + T)) OR (Alice + AliceSecret)\n\u003e\u003e 1: (Alice + timeout(now + T)) OR (Bob + BobSecret)\n\u003e\u003e\n\u003e\u003e TX2\n\u003e\u003e locktime: now + 2T\n\u003e\u003e\n\u003e\u003e Input\n\u003e\u003e TX1/0: signed by (Alice + Bob)\n\u003e\u003e TX1/1: signed by (Alice + Bob)\n\u003e\u003e Output\n\u003e\u003e Initial channel paying Alice \u0026 Bob 1BTC each\n\u003e\u003e\n\u003e\u003e ---------------------------------------\n\u003e\u003e\n\u003e\u003e Alice and Bob create TX1, sign it and share the result.\n\u003e\u003e\n\u003e\u003e Alice and Bob create TX2, sign it and share the result.\n\u003e\u003e\n\u003e\u003e Abort for those 2 steps:\n\u003e\u003e * If one signs and the other doesn't then the signer should spend their\n\u003e\u003e inputs to be safe.\n\u003e\u003e * If TX1 is broadcast, then they can both spend their timeouts to\n\u003e\u003e recover their funds, so it is safe.\n\u003e\u003e\n\u003e\u003e Once they both have signed versions of TX1 and TX2, they should broadcast\n\u003e\u003e TX1. This initializes the channel.\n\u003e\u003e\n\u003e\u003e If TX1 is mutated, then they should both abort and spend their timeouts\n\u003e\u003e and recover their funds.\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170208/16bdb873/attachment.html\u003e",
"sig": "5e0f05fb27e08e118c13681f656e8c7578710d326b861e3340a73a55d58a5bb6b2fbb585be8cd2245caccbfb0daf6d58dabef51f74f50aa7bcccdb276e845a48"
}