Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-08 📝 Original message: With this solution, is ...
📅 Original date posted:2017-02-08
📝 Original message:
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/7de2d4d4/attachment.html>;
📝 Original message:
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/7de2d4d4/attachment.html>;