Richard Myers [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-16 📝 Original message: Thanks for the feedback ...
📅 Original date posted:2019-09-16
📝 Original message:
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 change-in-membership ritual you describe seems like a good start for
elaborating on this idea.
Some aspects of multi-party Decker-Russell-Osuntokun channels have analogs
to a signet blockchain that use a n-of-n federation of signers. But other
places, like change-in-membership, do not have direct analogs.
For example, some signet concepts with multi-party channel analogs:
block script:
* the first 'update' and 'settle' transactions, aka 'setup' and 'refund'
transactions, define the set of signers that must sign subsequent channel
updates
genesis block:
* the initial 'funding' transaction, aka outpoint of the commitment
transaction, which establishes the funded channel
utxo set:
* the specific set of on-chain outputs from the 'settlement' transaction
that spends the balance of the latest 'update' transaction signed by the
complete set of channel parties.
mempool:
* the set of proposals for specific changes to the set of outputs from the
latest 'settlement' transaction (similar to update_add_htlc,
update_fail_htlc, etc)
Concepts where layer two channels do not have an obvious analog to a layer
one signet blockchain:
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
membership change (ZmnSCPxj ritual):
* when channel parties want to leave or add new members to the channel
* close and reopen a new channel via something like a channel splicing
transaction to the layer one blockchain
* should be optimized for privacy and low on-chain fees paid for by parties
entering and leaving the channel
balance change (similar to membership change):
* when channel parties want to add or remove some of the finalized value in
the channel
* close and reopen a new channel via something like a channel splicing
transaction to the layer one blockchain
* should be optimized for privacy and low on-chain fees paid for by parties
adding and removing value from the channel
uncooperative close:
* when one or more nodes fails to sign the next channel state update
* use a layer one transaction to commit both finalized and un-finalized
outputs from the most recent channel output state
* script timeouts determine when channel parties should uncooperatively
close the channel if not all parties have signed the next 'update' and
'settlement' transaction
uncooperative membership change:
* a subset of channel parties might want to cooperatively sign a channel
splicing transaction to 'splice out' uncooperative parties
mining, mining reward and difficulty adjustment
* no equivalent concept for multi-party channels
transaction fees:
* updates to layer two channels do not incur transactions fees
* invalid updates dropped to layer one should be paid by cheating node
* splice in/out transactions should be paid by requesting signers only
* do transaction fees prevent 'griefing' attacks?
privacy:
* disassociate a particular update from signer(s)
* disassociate IP address of signers from signature
* using SIGHASH_ALL for cooperative closes
liveness:
* if signers know they will be offline, can they pre-sign updates that just
commit their own outputs, rather then splice out?
* contingent tap-leafs to splice out non-responsive signers
The "block" that would need to be signed by the participants would actually
> be a Decker-Russell-Osuntokun update+state transaction, and would commit to
> the UTXO set rather than the transaction set.
> Unless I misunderstand your meaning here.
>
Oops, ya, I did mean a "block" to be a particular Decker-Russell-Osuntokun
update+state transaction.
I think it will be useful to have these ideas in the back of my mind as I
work on making eltoo scripts that support multi-party channels.
--
Richard Myers
Decentralized Applications Engineer, goTenna
gotenna.com
@gotenna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190916/afc6b87e/attachment.html>;
📝 Original message:
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 change-in-membership ritual you describe seems like a good start for
elaborating on this idea.
Some aspects of multi-party Decker-Russell-Osuntokun channels have analogs
to a signet blockchain that use a n-of-n federation of signers. But other
places, like change-in-membership, do not have direct analogs.
For example, some signet concepts with multi-party channel analogs:
block script:
* the first 'update' and 'settle' transactions, aka 'setup' and 'refund'
transactions, define the set of signers that must sign subsequent channel
updates
genesis block:
* the initial 'funding' transaction, aka outpoint of the commitment
transaction, which establishes the funded channel
utxo set:
* the specific set of on-chain outputs from the 'settlement' transaction
that spends the balance of the latest 'update' transaction signed by the
complete set of channel parties.
mempool:
* the set of proposals for specific changes to the set of outputs from the
latest 'settlement' transaction (similar to update_add_htlc,
update_fail_htlc, etc)
Concepts where layer two channels do not have an obvious analog to a layer
one signet blockchain:
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
membership change (ZmnSCPxj ritual):
* when channel parties want to leave or add new members to the channel
* close and reopen a new channel via something like a channel splicing
transaction to the layer one blockchain
* should be optimized for privacy and low on-chain fees paid for by parties
entering and leaving the channel
balance change (similar to membership change):
* when channel parties want to add or remove some of the finalized value in
the channel
* close and reopen a new channel via something like a channel splicing
transaction to the layer one blockchain
* should be optimized for privacy and low on-chain fees paid for by parties
adding and removing value from the channel
uncooperative close:
* when one or more nodes fails to sign the next channel state update
* use a layer one transaction to commit both finalized and un-finalized
outputs from the most recent channel output state
* script timeouts determine when channel parties should uncooperatively
close the channel if not all parties have signed the next 'update' and
'settlement' transaction
uncooperative membership change:
* a subset of channel parties might want to cooperatively sign a channel
splicing transaction to 'splice out' uncooperative parties
mining, mining reward and difficulty adjustment
* no equivalent concept for multi-party channels
transaction fees:
* updates to layer two channels do not incur transactions fees
* invalid updates dropped to layer one should be paid by cheating node
* splice in/out transactions should be paid by requesting signers only
* do transaction fees prevent 'griefing' attacks?
privacy:
* disassociate a particular update from signer(s)
* disassociate IP address of signers from signature
* using SIGHASH_ALL for cooperative closes
liveness:
* if signers know they will be offline, can they pre-sign updates that just
commit their own outputs, rather then splice out?
* contingent tap-leafs to splice out non-responsive signers
The "block" that would need to be signed by the participants would actually
> be a Decker-Russell-Osuntokun update+state transaction, and would commit to
> the UTXO set rather than the transaction set.
> Unless I misunderstand your meaning here.
>
Oops, ya, I did mean a "block" to be a particular Decker-Russell-Osuntokun
update+state transaction.
I think it will be useful to have these ideas in the back of my mind as I
work on making eltoo scripts that support multi-party channels.
--
Richard Myers
Decentralized Applications Engineer, goTenna
gotenna.com
@gotenna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190916/afc6b87e/attachment.html>;