Richard Myers [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-09 📝 Original message: I believe using the eltoo ...
📅 Original date posted:2019-09-09
📝 Original message:
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], the ability to have multiple party channels and the
most used types of scripts makes eltoo compelling compared to LN-Penalty
for this kind of application.
The multiple party aspect in particular introduces an interesting way to
unify concepts from different second layer protocols like federated
sidechains and statechains (ht. aakselrod [2]).
Though the Statechains proposal relies on eltoo [3], I think what Christian
suggested does not try to solve the dynamic membership problem. That's why
I think of this as more an evolution of the channel factory paper towards
something like a federated sidechain.
I think this reconciliation between the off-chain model and the on-chain
> model, with many concepts cleanly mapping from one context to another
> (state outputs = UTXO, off-chain update = on-chain transactions,
> cut-through = confirmation, operation batching = block creation) is
> rather nice :-)
One additional concept that could be new to this off-chain blockchain model
would be something like batched multi-party loop-in/out. In a
Schnorr/Taproot world you could add signers/inputs and remove
signers/outputs with a single multi-signature negotiated off-chain. You'd
still like to limit these onchain txs, even if they are small, but updating
channels periodically seems like a straight forward way to address the
dynamic membership problem.
I guess this all gets back to how to design an off-chain protocol for
managing these negotiations. Ultimately I can imagine a sort of multi-party
eltoo based 'signet' with the same RPC interface, but different transaction
validation and block creation logic. Perhaps there would be a new message
where the channel parties would add their signature before forwarding a
valid block, and the block wouldn't be built on until all parties had
signed.
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html
[2] https://twitter.com/stile65/status/1171030423394078720
[3]
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190909/bb60fee0/attachment.html>;
📝 Original message:
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], the ability to have multiple party channels and the
most used types of scripts makes eltoo compelling compared to LN-Penalty
for this kind of application.
The multiple party aspect in particular introduces an interesting way to
unify concepts from different second layer protocols like federated
sidechains and statechains (ht. aakselrod [2]).
Though the Statechains proposal relies on eltoo [3], I think what Christian
suggested does not try to solve the dynamic membership problem. That's why
I think of this as more an evolution of the channel factory paper towards
something like a federated sidechain.
I think this reconciliation between the off-chain model and the on-chain
> model, with many concepts cleanly mapping from one context to another
> (state outputs = UTXO, off-chain update = on-chain transactions,
> cut-through = confirmation, operation batching = block creation) is
> rather nice :-)
One additional concept that could be new to this off-chain blockchain model
would be something like batched multi-party loop-in/out. In a
Schnorr/Taproot world you could add signers/inputs and remove
signers/outputs with a single multi-signature negotiated off-chain. You'd
still like to limit these onchain txs, even if they are small, but updating
channels periodically seems like a straight forward way to address the
dynamic membership problem.
I guess this all gets back to how to design an off-chain protocol for
managing these negotiations. Ultimately I can imagine a sort of multi-party
eltoo based 'signet' with the same RPC interface, but different transaction
validation and block creation logic. Perhaps there would be a new message
where the channel parties would add their signature before forwarding a
valid block, and the block wouldn't be built on until all parties had
signed.
[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html
[2] https://twitter.com/stile65/status/1171030423394078720
[3]
https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190909/bb60fee0/attachment.html>;