ZmnSCPxj writes:
>> cooperative close:
>> * when all parties mutually agree to close the channel
>> * close the channel with a layer one transaction which finalizes the outputs
>> from the most recent channel output state
>> * should be optimized for privacy and low on-chain fees
>
> Of note is
Good morning Richards, and list,
> Thanks for the feedback ZmnSCPxj.
>
> > I imagine a future where most people do not typically have single-signer
> > ownership of coins onchain, but are instead share-owners of coins, with
> > single-signer ownership occurring onchain only in the case of
Thanks for the feedback ZmnSCPxj.
I imagine a future where most people do not typically have single-signer
> ownership of coins onchain, but are instead share-owners of coins, with
> single-signer ownership occurring onchain only in the case of dispute or
> for long-term cold storage.
>
The
Good morning Richard,
> I believe using the eltoo update scheme as a way to consolidate blocks of
> off-chain transactions is an interesting idea worth exploring.
>
> ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo.
> Although using CSV is more complicated and
I believe using the eltoo update scheme as a way to consolidate blocks of
off-chain transactions is an interesting idea worth exploring.
ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo.
Although using CSV is more complicated and outputs must also use
SIGHASH_NOINPUT [1],
Good morning Christian,
This is effectively transaction cut-through.
I mention this in passing here:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html
> I observe that one may consider any offchain system a specialization of an
> offchain transaction cut-through
