Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-08 📝 Original message: Tadge had an idea so we ...
📅 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>;
📝 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>;