📅 Original date posted:2020-09-01
📝 Original message:
Hi Nadav,
thanks for writing up this proposal. I think I can add a bit of details,
which might simplify the proposal.
## Ordering of updates
The way we ensure that an update tx (as the commitment txs are called in
the paper) can be attached only to prior updates is done by comparing
the state-number committed to in the prevout script with the current
timelock through CLTV. This functionality exists today already, and does
not have to be implemented by the Escrow at all: it can just sign off on
any update transaction and the monotonicity of the sequence of updates
is guaranteed through the script.
This should simplify the escrow considerably and allow us to disclose
less to it.
## Emulating `sighash_anyprevout`
We can emulate `sighash_anyprevout` and variants today already, if we
know all the transactions we'd eventually want to bind to at the time we
create the transaction that'd use `anyprevout`: simply iterate through
all the transactions it might bind to, update the transaction we're
signing with the prevout details of that potential binding, and sign
it. There are two downsides to this, namely processing overhead to
generate `n` signatures for `n` potential bindings, and communication
overhead, since we're now exchanging `n` signatures, instead of a single
`anyprevout` signature, but it can work.
I think with the escrow we can defer the creation of the signature to
the time we need it, and externalize the anyprevout logic: at each
update all parties sign a statement that they are ok with state
`k`. Should one party become unresponsive, or broadcast an intermediate
TX k'<k, the other party can take the statement to the escrow, which
verifies the signature of the misbehaving party and co-signs the state
`k`, basically taking on the role of the misbehaving party.
Notice that the "statement" above could just be the update TX bound to
the funding outpoint, meaning that in the happy case we'd just be able
to use that to collaboratively close the contract, otherwise we use the
escrow to rebind the update to whatever happened inbetween.
## Escrow collusion
While not particularly familiar with SCU, I think the escrow might need
to be ultimately trusted, since giving it the ability to act as
co-signer in lieu of a subset of participants, or even sole signature
authority could lead to collusion between the escrow and the remainder
of the contract participants, but I'm happy to be corrected here.
We had similar considerations while working on the original channel
factories paper, where we tried to come up with a scheme that'd allow a
subset of participants to split out an inactive participant in order to
recover from what would otherwise be a deadlock. We decided to drop that
possibility due to the complexity involved and the potential for serious
damage if participants collude.
## Fees
The way we handle fees in eltoo is simply sign the update txs with
sighash_single, allowing us to attach fees at a later point in
time. This is also what we're trying to do with the LN spec at the
moment by externalizing the fees with the anchor outputs proposal.
Overall I really like the idea of using an escrow to optimize the my
"just sign all variants" workaround, let's see where it takes us :-)
Cheers,
Christian
Nadav Kohen <nadav at suredbits.com> writes:
> Hi all,
>
> # Simulating Eltoo / ANYPREVOUT Factories Using SCU Escrows
>
> In this write-up I hope to convince you that it is possible to create some
> weak version of Eltoo channels and channel factories today without
> SIGHASH_ANYPREVOUT (although the version using this sighash is clearly
> superior) using ZmnSCPxj's proposal Smart Contracts Unchained (SCU) which
> Ben Carman has cleverly given the name SCUE'd Eltoo.
>
> ## Introduction
>
> ### Eltoo / ANYPREVOUT
>
> Eltoo is a proposal for a new (and generally improved) way of doing
> Lightning channels which also allows for multi-party channels (and channel
> factories). I am by no means fluent in the going's on of eltoo and
> anyprevout so I will link https://blockstream.com/eltoo.pdf and
> https://bitcoinops.org/en/topics/sighash_noinput/. My understanding is that
> at a high level, rather than using a penalty mechanism to update channel
> states, sighash_anyprevout is used to make any old commitment transaction
> spendable by any newer commitment transaction so that old revoked states
> can be updated on-chain instead of relying on a punishment mechanism.
> Benefits of this scheme include but are not limited to easier watchtower
> implementations, static partial backups, and multi-party channels.
>
> ### Smart Contracts Unchained (SCU)
>
> I strongly recommend the reader read this write up by ZmnSCPxj before
> continuing https://zmnscpxj.github.io/bitcoin/unchained.html
>
> At a high level the idea is to use a participant-chosen "federation" of
> "escrows" which can be thought of as virtual machines which understand
> contracts written in some language and which enforce said contracts by
> giving users signatures of transactions that are produced by these
> contracts. A general goal of SCU is to be trust-minimizing and as private
> as possible. For example, escrows should not be able to see that they are
> being used if there are no disputes, among other considerations that can be
> made to make SCU Escrows as oblivious as possible (discussed further below).
>
> ## Proposal (Un-Optimized)
>
> At a high level, this proposal is to replace the use of ANYPREVOUT with a
> federation of SCU Escrows which will enforce state updates by only
> generating signatures to spend older states with newer ones.
>
> I will work in the general context of multi-party channels but all of this
> works just as well in two-party (Lightning) channels.
>
> Say that we have N parties who wish to enter into a multi-party channel
> (aka channel factory). Each participant has a public key P_i and together
> they do a distributed key generation (DKG) of some kind to reach some
> shared secret x (for example, each party contributes a commitment to a
> random number and then that random number, MuSig style, and the sum of
> these random numbers constitutes the shared secret). This x will be used to
> derive a sequence of (shared) key pairs (x_k, X_k) (for example this can be
> done by having x_k = PRNG(x, k)).
>
> Let State(k) be some agreed upon commitment of the channel state at update
> k (for example, HMAC(k, kth State Tx outputs)). State(0) is a commitment to
> 0 and the initial channel balances.
>
> Let Delta be some CSV timelock.
>
> For the sake of simplicity, let us consider the case where only a single
> SCU escrow is used which has public key E, but note that all of the
> following can be extended to a threshold scheme of escrows. E_k will be
> used to denote some tweak of E by State(k) similar to the tweak described
> in SCU.
>
> ### Transactions
>
> #### Funding Transaction
>
> Like all such schemes, the funding transaction is some transaction
> containing an N-of-N multi-signature output with keys P_1, ..., P_N called
> the funding output.
>
> #### Commitment Transaction
>
> The commitment transaction spends the funding output and has a single
> output which has two spending conditions: Either E_k and X_k sign OR all N
> parties sign cooperatively after Delta.
>
> #### State Transaction
>
> The state transaction spends the commitment transaction via the cooperative
> branch and has (potentially many) outputs representing the current channel
> state. For example there will be an output for each solvent participant in
> this channel, as well as an output for ever contract living on this channel
> (for instance, other smaller channels).
>
> #### Commitment Update Transaction
>
> Let k2 be some state where k2 > k.
>
> The commitment update transaction spends either a commitment transaction's
> non-cooperative branch (E_k and X_k) or another commitment update
> transaction's non-time-locked branch, and has a single output which has two
> spending conditions: Either E_k2 and X_k2 sign OR E_k2' and X_k2' sign
> after Delta where those are tweaked keys in some way (to avoid signatures
> generated for one case being used in the other).
>
> #### State Update Transaction
>
> The state update transaction spends the commitment update transaction via
> the time-locked branch and has outputs equal to those on the (k2)th state
> transaction.
>
> ### Update Mechanism
>
> The update mechanism here is the same as would be expected for a
> multi-party payment channel but with the added step that all parties must
> sign the commitment State(k) before they sign State Transaction k.
>
> ### Settlement
>
> #### Cooperative (Normal Close)
>
> As you might expect, cooperative closure is where a transaction is
> cooperatively constructed which directly spends the on-chain funding UTXO
> and outputs the current State Transaction's outputs.
>
> #### Non-Cooperative (Force Close)
>
> In any case where not all parties are able or willing to sign a cooperative
> closing transaction, any party can broadcast the most recent commitment
> transaction, which can then be spent by anyone broadcasting the most recent
> state transaction after Delta.
>
> If, at any time, any party broadcasts an old commitment transaction k < c,
> any other party has until Delta to correct this mistake/attack. They do so
> by going to the SCU Escrow and presenting all signatures of State(k) and of
> State(c) which the Escrow verifies as well as verifying that k < c. Should
> all of these things check out, the Escrow can construct a Commitment Update
> Transaction (for (k, k2) = (k, c)) and the corresponding State Update
> Transaction and sign both of these transactions using E. These signatures
> (along with signatures from the shared keys X_k and X_c) can be used to
> broadcast the commitment update transaction, and after Delta, the state
> update transaction.
>
> If a commitment update transaction is broadcast for an old state c < c',
> then any party has until Delta to correct this mistake/attack. They do so
> by following the same exact steps as in the previous paragraph but with k
> <- c and c <- c' and where the Commitment Update Transaction spends the
> previous Commitment Update Transaction instead of a Commitment Transaction.
>
> In this way any channel participant can unilaterally update the on-chain
> commitment transaction until the most recent state is reached after which
> Delta will pass and a State Update Transaction with the current state will
> be valid to broadcast.
>
> ## Optimizations and Open Details
>
> ### Multiple Escrows
>
> The above can be done with some user-chosen federation with some threshold
> by replacing E above with a threshold condition using many escrow public
> keys. Doing so with as large and diverse a federation as possible is
> strongly encouraged as it reduces the likelihood that the federation will
> be bribed to spend the non-time-locked branch of the commitment transaction
> along with some channel participant directly. I believe it should
> (hopefully) be possible to make such an attack traceable (i.e. provide
> proof that this happened in an illegal way) so that attacked parties can
> prove that Escrows have been malicious.
>
> ### Taproot
>
> As is mentioned in SCU, the escrow scheme is made much better (especially
> in the multi-escrow case) by Taproot and the above scheme using SCU is
> improved even further as all outputs are bi-conditional and these two
> conditions can be separated into different merkle branches to increase
> privacy and fungibility.
>
> ### What is given to the Escrow? (aka Blinding / ZKP)
>
> In the above proposal, virtually all information about the channel, as well
> as how to find it on chain, is given to the escrow(s). This is really bad,
> and luckily it is avoidable! In principal we want Escrows to do nothing but
> (potentially many) random looking simple computations on random looking
> inputs to generate random looking outputs. The algorithm given the the
> Escrow is currently:
>
> Inputs =
>
> * output to spend (either a commitment output or a commitment update output)
> * State(k) corresponding to that output
> * signatures of State(k)
> * State(c) with c > k
> * signatures of State(c)
> * N public keys
> * Relevant shared public keys
> * Delta
>
> Output = If any signature is invalid or c <= k, FAIL. Otherwise, generate a
> digital signature using E with some tweak (as a function of inputs) and of
> some hash (as a function of inputs).
>
> As such, I will first note that the verification part of this algorithm's
> execution is linear time and so there must be a way to do it in Zero
> Knowledge. Specifically I believe this should be "as simple as" blinding
> all state inputs with random tweaks and blinding signatures of these states
> in the corresponding way (this may require that the signatures given by all
> parties during updates actually be altered in some way to make this work).
> Furthermore I think it should be possible (at least in theory it seems
> plausible to me) that all inputs can be hidden/blinded/tweaked and the
> Escrow performs some computations on these random looking inputs resulting
> in either a FAIL, or in further random looking computation using E (likely
> requiring some ZKP inputs proving that the calling party has followed some
> set of rules) to generate a blinded signature which can then be unblinded
> by the caller to receive a valid digital signature usable to enforce the
> above proposal.
>
> Please note that I do not have these details worked out in any meaningful
> way (and probably won't be able to do so, would love if someone more apt in
> this area would give this some thought!), but also that while this vastly
> improves the privacy and security of this scheme, it isn't strictly
> speaking a necessary optimization if you are willing to place more trust
> and be less private with Escrows.
>
> ### Fees
>
> I have given no thought to transaction fees in the above and I'm sure there
> are a bunch of ways to do them wrong but I'm hoping that it is possible to
> add anchor outputs or whatever other alterations need to occur to allow fee
> considerations to work out.
>
> I hope people find this proposal interesting! In theory it could be
> implemented on today's Bitcoin (though I will not have time to work on this
> in the foreseeable future, but would be happy to help anyone who would want
> to try to do this)!
>
> Best,
> Nadav
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 13:00:49
in reply to nevent1q…vxtz
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 13:00:49Event JSON
{
"id": "87d5a6efdaaf452982d4eb4f30305877ad051acd2c081413823eba3e3df1da68",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686315649,
"kind": 1,
"tags": [
[
"e",
"b3af66d55971c588d902389d22b2d0c69acbfc53d0ac9c123d3b274e14337e34",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2020-09-01\n📝 Original message:\nHi Nadav,\n\nthanks for writing up this proposal. I think I can add a bit of details,\nwhich might simplify the proposal.\n\n## Ordering of updates\n\nThe way we ensure that an update tx (as the commitment txs are called in\nthe paper) can be attached only to prior updates is done by comparing\nthe state-number committed to in the prevout script with the current\ntimelock through CLTV. This functionality exists today already, and does\nnot have to be implemented by the Escrow at all: it can just sign off on\nany update transaction and the monotonicity of the sequence of updates\nis guaranteed through the script.\n\nThis should simplify the escrow considerably and allow us to disclose\nless to it.\n\n## Emulating `sighash_anyprevout`\n\nWe can emulate `sighash_anyprevout` and variants today already, if we\nknow all the transactions we'd eventually want to bind to at the time we\ncreate the transaction that'd use `anyprevout`: simply iterate through\nall the transactions it might bind to, update the transaction we're\nsigning with the prevout details of that potential binding, and sign\nit. There are two downsides to this, namely processing overhead to\ngenerate `n` signatures for `n` potential bindings, and communication\noverhead, since we're now exchanging `n` signatures, instead of a single\n`anyprevout` signature, but it can work.\n\nI think with the escrow we can defer the creation of the signature to\nthe time we need it, and externalize the anyprevout logic: at each\nupdate all parties sign a statement that they are ok with state\n`k`. Should one party become unresponsive, or broadcast an intermediate\nTX k'\u003ck, the other party can take the statement to the escrow, which\nverifies the signature of the misbehaving party and co-signs the state\n`k`, basically taking on the role of the misbehaving party.\n\nNotice that the \"statement\" above could just be the update TX bound to\nthe funding outpoint, meaning that in the happy case we'd just be able\nto use that to collaboratively close the contract, otherwise we use the\nescrow to rebind the update to whatever happened inbetween.\n\n## Escrow collusion\n\nWhile not particularly familiar with SCU, I think the escrow might need\nto be ultimately trusted, since giving it the ability to act as\nco-signer in lieu of a subset of participants, or even sole signature\nauthority could lead to collusion between the escrow and the remainder\nof the contract participants, but I'm happy to be corrected here.\n\nWe had similar considerations while working on the original channel\nfactories paper, where we tried to come up with a scheme that'd allow a\nsubset of participants to split out an inactive participant in order to\nrecover from what would otherwise be a deadlock. We decided to drop that\npossibility due to the complexity involved and the potential for serious\ndamage if participants collude.\n\n## Fees\n\nThe way we handle fees in eltoo is simply sign the update txs with\nsighash_single, allowing us to attach fees at a later point in\ntime. This is also what we're trying to do with the LN spec at the\nmoment by externalizing the fees with the anchor outputs proposal.\n\n\nOverall I really like the idea of using an escrow to optimize the my\n\"just sign all variants\" workaround, let's see where it takes us :-)\n\nCheers,\nChristian\n\nNadav Kohen \u003cnadav at suredbits.com\u003e writes:\n\u003e Hi all,\n\u003e\n\u003e # Simulating Eltoo / ANYPREVOUT Factories Using SCU Escrows\n\u003e\n\u003e In this write-up I hope to convince you that it is possible to create some\n\u003e weak version of Eltoo channels and channel factories today without\n\u003e SIGHASH_ANYPREVOUT (although the version using this sighash is clearly\n\u003e superior) using ZmnSCPxj's proposal Smart Contracts Unchained (SCU) which\n\u003e Ben Carman has cleverly given the name SCUE'd Eltoo.\n\u003e\n\u003e ## Introduction\n\u003e\n\u003e ### Eltoo / ANYPREVOUT\n\u003e\n\u003e Eltoo is a proposal for a new (and generally improved) way of doing\n\u003e Lightning channels which also allows for multi-party channels (and channel\n\u003e factories). I am by no means fluent in the going's on of eltoo and\n\u003e anyprevout so I will link https://blockstream.com/eltoo.pdf and\n\u003e https://bitcoinops.org/en/topics/sighash_noinput/. My understanding is that\n\u003e at a high level, rather than using a penalty mechanism to update channel\n\u003e states, sighash_anyprevout is used to make any old commitment transaction\n\u003e spendable by any newer commitment transaction so that old revoked states\n\u003e can be updated on-chain instead of relying on a punishment mechanism.\n\u003e Benefits of this scheme include but are not limited to easier watchtower\n\u003e implementations, static partial backups, and multi-party channels.\n\u003e\n\u003e ### Smart Contracts Unchained (SCU)\n\u003e\n\u003e I strongly recommend the reader read this write up by ZmnSCPxj before\n\u003e continuing https://zmnscpxj.github.io/bitcoin/unchained.html\n\u003e\n\u003e At a high level the idea is to use a participant-chosen \"federation\" of\n\u003e \"escrows\" which can be thought of as virtual machines which understand\n\u003e contracts written in some language and which enforce said contracts by\n\u003e giving users signatures of transactions that are produced by these\n\u003e contracts. A general goal of SCU is to be trust-minimizing and as private\n\u003e as possible. For example, escrows should not be able to see that they are\n\u003e being used if there are no disputes, among other considerations that can be\n\u003e made to make SCU Escrows as oblivious as possible (discussed further below).\n\u003e\n\u003e ## Proposal (Un-Optimized)\n\u003e\n\u003e At a high level, this proposal is to replace the use of ANYPREVOUT with a\n\u003e federation of SCU Escrows which will enforce state updates by only\n\u003e generating signatures to spend older states with newer ones.\n\u003e\n\u003e I will work in the general context of multi-party channels but all of this\n\u003e works just as well in two-party (Lightning) channels.\n\u003e\n\u003e Say that we have N parties who wish to enter into a multi-party channel\n\u003e (aka channel factory). Each participant has a public key P_i and together\n\u003e they do a distributed key generation (DKG) of some kind to reach some\n\u003e shared secret x (for example, each party contributes a commitment to a\n\u003e random number and then that random number, MuSig style, and the sum of\n\u003e these random numbers constitutes the shared secret). This x will be used to\n\u003e derive a sequence of (shared) key pairs (x_k, X_k) (for example this can be\n\u003e done by having x_k = PRNG(x, k)).\n\u003e\n\u003e Let State(k) be some agreed upon commitment of the channel state at update\n\u003e k (for example, HMAC(k, kth State Tx outputs)). State(0) is a commitment to\n\u003e 0 and the initial channel balances.\n\u003e\n\u003e Let Delta be some CSV timelock.\n\u003e\n\u003e For the sake of simplicity, let us consider the case where only a single\n\u003e SCU escrow is used which has public key E, but note that all of the\n\u003e following can be extended to a threshold scheme of escrows. E_k will be\n\u003e used to denote some tweak of E by State(k) similar to the tweak described\n\u003e in SCU.\n\u003e\n\u003e ### Transactions\n\u003e\n\u003e #### Funding Transaction\n\u003e\n\u003e Like all such schemes, the funding transaction is some transaction\n\u003e containing an N-of-N multi-signature output with keys P_1, ..., P_N called\n\u003e the funding output.\n\u003e\n\u003e #### Commitment Transaction\n\u003e\n\u003e The commitment transaction spends the funding output and has a single\n\u003e output which has two spending conditions: Either E_k and X_k sign OR all N\n\u003e parties sign cooperatively after Delta.\n\u003e\n\u003e #### State Transaction\n\u003e\n\u003e The state transaction spends the commitment transaction via the cooperative\n\u003e branch and has (potentially many) outputs representing the current channel\n\u003e state. For example there will be an output for each solvent participant in\n\u003e this channel, as well as an output for ever contract living on this channel\n\u003e (for instance, other smaller channels).\n\u003e\n\u003e #### Commitment Update Transaction\n\u003e\n\u003e Let k2 be some state where k2 \u003e k.\n\u003e\n\u003e The commitment update transaction spends either a commitment transaction's\n\u003e non-cooperative branch (E_k and X_k) or another commitment update\n\u003e transaction's non-time-locked branch, and has a single output which has two\n\u003e spending conditions: Either E_k2 and X_k2 sign OR E_k2' and X_k2' sign\n\u003e after Delta where those are tweaked keys in some way (to avoid signatures\n\u003e generated for one case being used in the other).\n\u003e\n\u003e #### State Update Transaction\n\u003e\n\u003e The state update transaction spends the commitment update transaction via\n\u003e the time-locked branch and has outputs equal to those on the (k2)th state\n\u003e transaction.\n\u003e\n\u003e ### Update Mechanism\n\u003e\n\u003e The update mechanism here is the same as would be expected for a\n\u003e multi-party payment channel but with the added step that all parties must\n\u003e sign the commitment State(k) before they sign State Transaction k.\n\u003e\n\u003e ### Settlement\n\u003e\n\u003e #### Cooperative (Normal Close)\n\u003e\n\u003e As you might expect, cooperative closure is where a transaction is\n\u003e cooperatively constructed which directly spends the on-chain funding UTXO\n\u003e and outputs the current State Transaction's outputs.\n\u003e\n\u003e #### Non-Cooperative (Force Close)\n\u003e\n\u003e In any case where not all parties are able or willing to sign a cooperative\n\u003e closing transaction, any party can broadcast the most recent commitment\n\u003e transaction, which can then be spent by anyone broadcasting the most recent\n\u003e state transaction after Delta.\n\u003e\n\u003e If, at any time, any party broadcasts an old commitment transaction k \u003c c,\n\u003e any other party has until Delta to correct this mistake/attack. They do so\n\u003e by going to the SCU Escrow and presenting all signatures of State(k) and of\n\u003e State(c) which the Escrow verifies as well as verifying that k \u003c c. Should\n\u003e all of these things check out, the Escrow can construct a Commitment Update\n\u003e Transaction (for (k, k2) = (k, c)) and the corresponding State Update\n\u003e Transaction and sign both of these transactions using E. These signatures\n\u003e (along with signatures from the shared keys X_k and X_c) can be used to\n\u003e broadcast the commitment update transaction, and after Delta, the state\n\u003e update transaction.\n\u003e\n\u003e If a commitment update transaction is broadcast for an old state c \u003c c',\n\u003e then any party has until Delta to correct this mistake/attack. They do so\n\u003e by following the same exact steps as in the previous paragraph but with k\n\u003e \u003c- c and c \u003c- c' and where the Commitment Update Transaction spends the\n\u003e previous Commitment Update Transaction instead of a Commitment Transaction.\n\u003e\n\u003e In this way any channel participant can unilaterally update the on-chain\n\u003e commitment transaction until the most recent state is reached after which\n\u003e Delta will pass and a State Update Transaction with the current state will\n\u003e be valid to broadcast.\n\u003e\n\u003e ## Optimizations and Open Details\n\u003e\n\u003e ### Multiple Escrows\n\u003e\n\u003e The above can be done with some user-chosen federation with some threshold\n\u003e by replacing E above with a threshold condition using many escrow public\n\u003e keys. Doing so with as large and diverse a federation as possible is\n\u003e strongly encouraged as it reduces the likelihood that the federation will\n\u003e be bribed to spend the non-time-locked branch of the commitment transaction\n\u003e along with some channel participant directly. I believe it should\n\u003e (hopefully) be possible to make such an attack traceable (i.e. provide\n\u003e proof that this happened in an illegal way) so that attacked parties can\n\u003e prove that Escrows have been malicious.\n\u003e\n\u003e ### Taproot\n\u003e\n\u003e As is mentioned in SCU, the escrow scheme is made much better (especially\n\u003e in the multi-escrow case) by Taproot and the above scheme using SCU is\n\u003e improved even further as all outputs are bi-conditional and these two\n\u003e conditions can be separated into different merkle branches to increase\n\u003e privacy and fungibility.\n\u003e\n\u003e ### What is given to the Escrow? (aka Blinding / ZKP)\n\u003e\n\u003e In the above proposal, virtually all information about the channel, as well\n\u003e as how to find it on chain, is given to the escrow(s). This is really bad,\n\u003e and luckily it is avoidable! In principal we want Escrows to do nothing but\n\u003e (potentially many) random looking simple computations on random looking\n\u003e inputs to generate random looking outputs. The algorithm given the the\n\u003e Escrow is currently:\n\u003e\n\u003e Inputs =\n\u003e\n\u003e * output to spend (either a commitment output or a commitment update output)\n\u003e * State(k) corresponding to that output\n\u003e * signatures of State(k)\n\u003e * State(c) with c \u003e k\n\u003e * signatures of State(c)\n\u003e * N public keys\n\u003e * Relevant shared public keys\n\u003e * Delta\n\u003e\n\u003e Output = If any signature is invalid or c \u003c= k, FAIL. Otherwise, generate a\n\u003e digital signature using E with some tweak (as a function of inputs) and of\n\u003e some hash (as a function of inputs).\n\u003e\n\u003e As such, I will first note that the verification part of this algorithm's\n\u003e execution is linear time and so there must be a way to do it in Zero\n\u003e Knowledge. Specifically I believe this should be \"as simple as\" blinding\n\u003e all state inputs with random tweaks and blinding signatures of these states\n\u003e in the corresponding way (this may require that the signatures given by all\n\u003e parties during updates actually be altered in some way to make this work).\n\u003e Furthermore I think it should be possible (at least in theory it seems\n\u003e plausible to me) that all inputs can be hidden/blinded/tweaked and the\n\u003e Escrow performs some computations on these random looking inputs resulting\n\u003e in either a FAIL, or in further random looking computation using E (likely\n\u003e requiring some ZKP inputs proving that the calling party has followed some\n\u003e set of rules) to generate a blinded signature which can then be unblinded\n\u003e by the caller to receive a valid digital signature usable to enforce the\n\u003e above proposal.\n\u003e\n\u003e Please note that I do not have these details worked out in any meaningful\n\u003e way (and probably won't be able to do so, would love if someone more apt in\n\u003e this area would give this some thought!), but also that while this vastly\n\u003e improves the privacy and security of this scheme, it isn't strictly\n\u003e speaking a necessary optimization if you are willing to place more trust\n\u003e and be less private with Escrows.\n\u003e\n\u003e ### Fees\n\u003e\n\u003e I have given no thought to transaction fees in the above and I'm sure there\n\u003e are a bunch of ways to do them wrong but I'm hoping that it is possible to\n\u003e add anchor outputs or whatever other alterations need to occur to allow fee\n\u003e considerations to work out.\n\u003e\n\u003e I hope people find this proposal interesting! In theory it could be\n\u003e implemented on today's Bitcoin (though I will not have time to work on this\n\u003e in the foreseeable future, but would be happy to help anyone who would want\n\u003e to try to do this)!\n\u003e\n\u003e Best,\n\u003e Nadav\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "ff5b15ee1df5de054828012090c1e0316edefa06d8673d40cb61a4188c6ff25aa568a49355506c80f19577daaae837d34d23d54fd2d410c90aca4362b8460843"
}