[WIP] [TZE] [ZIP 309] Add zkChannels (or BOLT) support #216
Conversation
|
Is this intended to be a candidate for NU3? It seems insufficiently specified and/or dependent on other features that we don't have yet, but I'm willing to include it for consideration if that's your intention @jakinyele . |
|
Does BOLT compete with StarkPay? |
|
@jakinyele can you add detail here for me and @daira to review? |
|
@acityinohio, @daira. We updated the pull request with more details but would like some feedback on what we are thinking for shielded transactions. We are doing a final review of the submitted version today and will update the pull request accordingly. Thanks for your patience! |
|
Geffen is working with BOLT on UX help/review for this |
zip-bolt-support.rst
Outdated
| (7) Ability to verify the transaction output such that: | ||
|
|
||
| - if customer initiated closing, first output pays out to customer with a time lock (to allow merchant to dispute customer balance) and second output pays out to merchant immediately | ||
| - if merchant initiated closing, a single output that pays the merchant the full balance of the channel with a time lock that allows for customer dispute |
There was a problem hiding this comment.
Indent these two items by four spaces so that the sublist renders correctly.
zip-bolt-support.rst
Outdated
|
|
||
| * Mode 2 (for merchant-initiated close). The opcode expects a channel token and a merchant closure token, which is signed using the customer's channel-specific public key. The opcode validates the customer signature on the provided closure token and verifies that the closing transaction contains a timelocked output paying the total channel balance to the merchant. The output must be timelocked to allow for the customer to post her own closing transaction with a different split of channel funds. | ||
|
|
||
| * Mode 3 (for merchant dispute of customer closure token). This mode is used in a merchant closing transaction to dispute a customer's closure token. The opcode expects a merchant revocation token. It validates the revocation token with respect to the wallet pub key posted by the customer in the customer's closing transaction. If valid, the customer's closure token will be invalidated and the merchant's closing transaction will be deemed valid. |
There was a problem hiding this comment.
Indent these three items (and their sub-items) by four spaces so that the sublist renders correctly.
There was a problem hiding this comment.
The modes above describe the various tokens, but do not specify them. Please add specifications for the tokens, so that it is clear how the opcode is supposed to parse and distinguish them.
| 2. Transparent/Shielded Tx: Using T/Z-addresses and Scripting Opcodes | ||
| ------------- | ||
|
|
||
| We assume the following specific features are present: |
There was a problem hiding this comment.
The six items in this list don't line up with the seven items in the "General Requirements" section. It would be useful to reorganise one or the other lists so that readers can see which requirements are being satisfied by which assumed specific features.
zip-bolt-support.rst
Outdated
|
|
||
| (1) ``OP_CLTV`` - absolute lock time | ||
| (2) ``OP_CSV`` - relative lock time | ||
| (3) shielded address support |
There was a problem hiding this comment.
Add precision here about what "shielded address support" is being assumed. In later sections the corresponding assumption is more precise, e.g. "2-of-2 multisig shielded address support".
zip-bolt-support.rst
Outdated
|
|
||
| 3.3 Initial Wallet Commitment | ||
| ------------- | ||
| The initial wallet commitment will spend from the shielded address to two outputs: a P2SH output (for customer) and P2PKH (for merchant). The first output pays the customer with a timelock (or the merchant with a revocation token) and the second output allows the merchant to spend immediately. It is not clear to us whether it will be possible to encumber the outputs of shielded outputs directly. |
There was a problem hiding this comment.
Earlier it was assumed (for this section's proposal) that it was possible to encumber shielded outputs. Refactor this paragraph to remove the references to P2SH and P2PKH, and describe what the specification would be assuming encumberance was possible.
zip-bolt-support.rst
Outdated
| ------------- | ||
| The channel closing consists of the customer broadcasting the most recent commitment transaction and requires that they present the closure token necessary to claim the funds. Similarly, the merchant would be able to claim the funds with the appropriate revocation token as well. | ||
|
|
||
| 4. Bitcoin Compatible: Using T-address and Scripting Opcodes |
There was a problem hiding this comment.
Remove this section from the ZIP. Zcash does not have P2WSH addresses (and it is unlikely that they would ever be added), and IMHO a transparent-only BOLT integration is not worth the non-trivial engineering effort, when that time could instead be spent working on one of the other proposals with better privacy properties.
There was a problem hiding this comment.
Note: don't actually remove this section until another reviewer agrees with me that it should be removed!
zip-bolt-support.rst
Outdated
| ------------- | ||
| The initial wallet commitment will spend from the shielded address to two outputs: a P2SH output (for customer) and P2PKH (for merchant). The first output pays the customer with a timelock (or the merchant with a revocation token) and the second output allows the merchant to spend immediately. It is not clear to us whether it will be possible to encumber the outputs of shielded outputs directly. | ||
|
|
||
| We would appreciate feedback on the possibilities with creating commitment transactions via shielded transactions only. |
There was a problem hiding this comment.
I think the simplest strategy would be to create a specific Bolt circuit that enforces the necessary encumberance, and then require that the spender provide a proof that takes in public inputs satisfying the encumberance. This could be implemented as a special case of P2VK (zcash/zcash#2425), or a dedicated circuit that could be migrated in a future NU to a more general programmability solution (general P2VK, or something else).
Broadly, I would imagine something along these lines:
- The encumbered output would contain a commitment to the various Bolt parameters (the timelock, the revocation token, etc).
- Without changing the Sapling circuit, the commitment would be added to a global Merkle tree in parallel to the current Sapling Merkle tree (meaning that they don't have a shared privacy set).
- If the Sapling circuit was altered, the privacy sets could potentially be shared, at the cost of requiring all Sapling users to be aware of Bolt semantics. IMHO this probably isn't worth the cost of doing such a change, but we could consider it during a later general programmability solution.
- The parameters themselves would probably also be included directly in the transaction in an encrypted field (as we do for shielded notes).
- The spend using that output would contain a proof using the Bolt circuit, and the necessary public inputs such as the "time" at which the proof was created (perhaps stored in the
locktimefield).- The circuit would enforce the equivalent of the
OP_BOLTlogic, allowing a valid proof to be created if the prover had knowledge of the revocation key and merchant key, OR the prover had knowledge of the customer key AND the public time input was past the committed timelock. It would also enforce all the necessary peripherial checks (the parameters match the original commitment, there exists a Merkle path from the original commitment to a specified public anchor, etc.). - Network nodes would validate the Bolt-specific proof, and also validate the public inputs (if necessary, e.g. the
locktimefield is already enforced by the network).
- The circuit would enforce the equivalent of the
The above MIGHT be feasible for NU3, but it would likely be at the exclusion of almost all other proposals. In particular, this ZIP would need major revisions in the near future, or NU3 deadlines would need to be extended, in order to be able to fully-specify the necessary changes.
zip-bolt-support.rst
Outdated
| We assume the following specific features are present: | ||
|
|
||
| (1) ``OP_CLTV`` - absolute lock time | ||
| (2) ``OP_CSV`` - relative lock time |
There was a problem hiding this comment.
Zcash does not have this opcode at present, so it would need to be deployed alongside this ZIP.
zip-bolt-support.rst
Outdated
| (2) ``OP_CSV`` - relative lock time | ||
| (3) shielded address support | ||
| (4) 2-of-2 multi-sig transparent address support (via P2SH) | ||
| (5) Transaction non-malleability |
There was a problem hiding this comment.
Zcash does not have this for transactions that involve transparent components (due to scriptSig malleability), and deploying SegWit is not feasible for NU3 (and unlikely to happen at all). An alternative approach would need to be proposed, specified, and deployed alongside this ZIP.
|
@zmanian Would you be willing to review and provide comments on this ZIP next week? |
A few more updates to go
|
@warner Would you be willing to review and provide comments on this ZIP sometime this week? |
|
[UX Review]: Bolt channels will require heavy UX/UI effort for both education and use. While this falls into the purview of the wallet or app creator, we should do a design story on how privacy would work within the bolt funding/spending/closing flows. This is a good candidate for a mock-up or rapid prototype for further user research. |
More revisions to come...
|
For the record, I've read this ZIP and all of the comments up to here. |
Added more details to token descriptions
Describes three potential approaches for integrating Bolt with Zcash