* [bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1
@ 2022-09-04 22:31 Ali Sherief
2022-09-05 3:17 ` ZmnSCPxj
0 siblings, 1 reply; 2+ messages in thread
From: Ali Sherief @ 2022-09-04 22:31 UTC (permalink / raw)
To: bitcoin-dev
Over the past few days I've figured out a novel way to batch transactions together into blocks, thereby compacting the transaction size and increasing the transactions-per-second. This is all on layer 1, without any hardforks - only a single softfork is required to add MuSig1 support for individual invoice addresses.
The nucleus of the idea was born after a discussion with Greg Maxwell about a different BIP (Implementing multisig using Taproot, to be specific)[1]. He suggested to me that I should add MuSig1 signatures into the Taproot script paths.
After some thinking, I realized a use case for MuSig1 signatures as a kind of on-chain Lightning Network. Allow me to explain:
LN is very attractive to users because it keeps intermediate transaction states off-chain, and only broadcasts the final state. But without mitigations in the protocol, it suffers from two disadvantages:
- You have to trust the other channel partner not to broadcast a previous state
- You also have to trust all the middlemen in intermediate channels not to do the above.
Most of us probably know that many mitigations have been created for this problem, e.g. penalty transactions. But what if it were possible to create a scheme where so-called technical fraud is not possible? That is what I'm going to demonstrate here.
My scheme makes use of MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock type, and negligible OP_RETURN data. It revolves around constructs I call "multipayment channels", called so because they allow multiple people to pay in one transaction - something that is already possible BTW, but with much larger tx size (for large number of cosigners) than when using MuSig1. These have the advantage over LN channels that the intermediate state is also on the blockchain, but it's very compact.
A channel consists of a fixed amount of people N. These people open a channel by creating a (optionally Taproot) address with the following script:
<blockheightofoutput+desiredwaitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG**
Simultaneously, each of the N participants receives the N signatures and constructs the N-of-N MuSig. Each participant will use this MuSig to generate his own independent "commitment transaction" with the following properties:
- It has a single input, the MuSig output. It has an nSequence of desiredwaitingblocks. <This prevents the output from being spent immediately.>
- It has outputs corresponding to the addresses and balances of each of the participants in the agreed-upon distribution.
Disadvantage: Because the N-of-N signature is given to all participants, it might be leaked into the public and consequentially anybody can spend this transaction after the timelock, to commit the balance.*** On the other hand, removing the timelocks means that if one of the participants goes missing, all funds are locked forever.****
A second output with a script OP_RETURN <32-byte connection ID> can be added to the transaction to enable L1 channel discovery.
Full nodes parsing the blockchain can maintain a list of connection IDs to connect to (but without a non-malleable refund transaction, nobody is going to use this). SPVs can simply export a list of them from Full Nodes.
A connection only lasts for one transaction. Spending the output to another MuSig of the above format will create a new connection if it spends to a similarly-constructed MuSig output with different signature. In all cases, the current connection is destroyed.
*This introduces a variable grace period, in blocks, after which anybody can broadcast this transaction to commit the channel funds distribution to each of the participants' addresses. blockheightofoutput is the block height of the musig output, and desiredwaitingblocks is the maximum number of blocks the connection can stay alive for.
**This implies that a hypothetical OP_CHECKMUSIG would take a single aggregated signature, a single aggregated public key, and an integer N that denotes how many public keys were combined together. I elected not to overload OP_CHECKSIG since MuSig and regular signatures are both valid for the same address types. This part is a rought draft and requires lots of work on making an OP_CHECKMUSIG opcode that satisfies the requirements of multipayment channels.
***This is quite a bad flaw of this scheme because it means that all the participants must be trustworthy - you can't use this in trustless environments. I appreciate any ways on how to implement non-malleable refund transactions with single (non-aggregated) signatures!
****Perhaps the best solution is to offer both alternatives: <N-of-N MuSig1> OP_CHECKMUSIG in a public scenario where none of the participants want to face the prospect of losing their money, and <blockheightofoutput+desiredwaitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG with signature sharing in private scenarios.
This draft is very crude and parts have not been fully developed. Tips for fleshing it out is much appreciated. Not that there's anything wrong with LN for that matter, I'm just concerned about the security reprocussions of not broadcasting intermediate transactions, and its enabling of crime.
- Ali
[1]: https://bitcointalk.org/index.php?topic=5410553.0
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1
2022-09-04 22:31 [bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1 Ali Sherief
@ 2022-09-05 3:17 ` ZmnSCPxj
0 siblings, 0 replies; 2+ messages in thread
From: ZmnSCPxj @ 2022-09-05 3:17 UTC (permalink / raw)
To: Ali Sherief, Bitcoin Protocol Discussion
Good morning Ali,
> Over the past few days I've figured out a novel way to batch transactions together into blocks, thereby compacting the transaction size and increasing the transactions-per-second. This is all on layer 1, without any hardforks - only a single softfork is required to add MuSig1 support for individual invoice addresses.
>
> The nucleus of the idea was born after a discussion with Greg Maxwell about a different BIP (Implementing multisig using Taproot, to be specific)[1]. He suggested to me that I should add MuSig1 signatures into the Taproot script paths.
>
> After some thinking, I realized a use case for MuSig1 signatures as a kind of on-chain Lightning Network. Allow me to explain:
>
> LN is very attractive to users because it keeps intermediate transaction states off-chain, and only broadcasts the final state. But without mitigations in the protocol, it suffers from two disadvantages:
>
> - You have to trust the other channel partner not to broadcast a previous state
> - You also have to trust all the middlemen in intermediate channels not to do the above.
>
> Most of us probably know that many mitigations have been created for this problem, e.g. penalty transactions. But what if it were possible to create a scheme where so-called technical fraud is not possible? That is what I'm going to demonstrate here.
The fact that you need to invoke trust later on ("Because the N-of-N signature is given to all participants, it might be leaked into the public") kinda breaks the point of "technical fraud is not possible".
At least with the penalty transactions of Poon-Dryja and the update transactions of Decker-Russell-Osuntokun you never have to worry about other parties leaking information and possibly changing the balance of the channel.
You only need to worry about ensuring you have an up-to-date view of the blockchain, which can be mitigated further by e.g. running a "spare" fullnode on a Torv3 address that secretly connects to your main fullnode (making eclipse attacks that target your known IP harder), connecting to Blockstream Satellite, etc.
You can always get more data yourself, you cannot stop data being acquired by others.
> My scheme makes use of MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock type, and negligible OP_RETURN data. It revolves around constructs I call "multipayment channels", called so because they allow multiple people to pay in one transaction - something that is already possible BTW, but with much larger tx size (for large number of cosigners) than when using MuSig1. These have the advantage over LN channels that the intermediate state is also on the blockchain, but it's very compact.
How is this more advantageous than e.g. CoinPools / multiparticipant channels / Statechains ?
> A channel consists of a fixed amount of people N. These people open a channel by creating a (optionally Taproot) address with the following script:
> <blockheightofoutput+desiredwaitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG**
If it is Taproot, then `OP_CHECKSIG` is already `OP_CHECKMUSIG`, since MuSig1 (and MuSig2, for that matter....) is just an ordinary Schnorr signature.
In a Tapscript, `OP_CHECKSIG` validates Schnorr signatures (as specified in the relevant BIP), not the ECDSA signatures.
> Simultaneously, each of the N participants receives the N signatures and constructs the N-of-N MuSig. Each participant will use this MuSig to generate his own independent "commitment transaction" with the following properties:
>
> - It has a single input, the MuSig output. It has an nSequence of desiredwaitingblocks. <This prevents the output from being spent immediately.>
>
> - It has outputs corresponding to the addresses and balances of each of the participants in the agreed-upon distribution.
> Disadvantage: Because the N-of-N signature is given to all participants, it might be leaked into the public and consequentially anybody can spend this transaction after the timelock, to commit the balance.*** On the other hand, removing the timelocks means that if one of the participants goes missing, all funds are locked forever.****
As I understand it, in your mechanism:
* Onchain, there is an output with the above SCRIPT: `<blockheightofoutput+desiredwaitingblocks>* OP_CTLV OP_DROP <N-of-N MuSig1> OP_CHECKMUSIG`
* Let me call this the "channel UTXO".
* Offchain, you have a "default transaction" which spends the above output, and redistributes it back to the original owners of the funds, with a timelock requirement (as needed by `OP_CLTV`).
Is that correct?
Then I can improve it in the following ways:
* Since everyone has to sign off the "default transaction" anyway, everyone can ensure that the `nLockTime` field is correct, without having `OP_CLTV` in the channel UTXO SCRIPT.
* So, the channel UTXO does not need a SCRIPT --- it can just use a Taproot-address Schnorr MuSig point directly.
* This has the massive advantage that the "default transaction" does not have any special SCRIPTs, improving privacy (modulo the fact that you are cooperating with others who could leak their data).
* If the participants can agree on a new distribution of the funds, then they can sign off with the current blockheight without waiting for the later blockheight.
* This improves security, since the new distribution can appear on the mempool first and be confirmed first before the "default transaction" can.
Now I want you to look at the literature on channel constructions, particularly "Spilman channels".
For example, see this:
* https://old.reddit.com/r/Bitcoin/comments/cc9psl/technical_a_brief_history_of_payment_channels/
My modifications to your scheme are just a modernization of the Spilman channels.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-09-05 3:17 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-04 22:31 [bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1 Ali Sherief
2022-09-05 3:17 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox