-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BIP 347: OP_CAT in Tapscript #1525
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor nits. Idea seems sensible. Mailing list post seems mostly positive sentiment as well.
@luke-jr ?
Co-authored-by: kallewoof <[email protected]>
"If an if only has a single-statement then-clause, it can appear on the same line as the if, without braces. In every other case, braces are required, and the then and else clauses must appear correctly indented on a new line." Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
Definitely looking forward to test drive this BIP. |
Can we get a BIP number assigned? Any blockers to doing this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, some more μ-nits. Fine with it as is though.
Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
Co-authored-by: kallewoof <[email protected]>
TIL that it is "a one" rather than "an one" Co-authored-by: kallewoof <[email protected]>
bip-???-cat.mediawiki
Outdated
|
||
* Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. <ref>R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf</ref> | ||
* Tree Signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with a thousand public keys. This also enables generalized logical spend conditions. <ref> P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/</ref> | ||
* Post-Quantum Lamport Signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. <ref>J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html</ref> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lamport signatures in tapscript aren't actually quantum secure because the taptweak still relies on EC operations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know it is an open question if the taptweak based commitment is quantum secure or not. This BIP could not take a position on this question. I will reword this to fix any confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, I spoke too soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad you brought this up. I wouldn't want the BIP to be seen as making an authoritative statement on this question. Let me know if you think my change addresses the issue or not.
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
Co-authored-by: Vojtěch Strnad <[email protected]>
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
I put the BIP number in the title, I hope you don’t mind. It seems to me that there are still a couple open review comments, will swing by again later to check whether it’s ready for the next round of review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have left a couple more nits that you may address or ignore freely, I don’t consider any to be blocking.
The BIP described in this PR fulfills the criteria set out in BIP2, it:
- Is properly formatted
- Has a complete preamble
- Concisely specifies a new feature in sufficient detail for implementation
- Covers Motivation, Rationale, Backwards Compatibility
- Has an acceptable license
and therefore appears to be ready to be merged.¹
ACK 696cc17
¹ This should be obvious, but to make it explicit: This is a clerical assessment of the completeness of this PR. I am neither endorsing this BIP nor expressing any opinion on whether OP_CAT should be activated.
@luke-jr had previously requested changes:
which I consider to have been addressed. I will abstain from merging this PR for some time, to give other editors a chance to make their own assessment. |
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
This improves readability, thanks! Co-authored-by: Mark "Murch" Erhardt <[email protected]>
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK, mod non-working url and squash commits
bip-0347.mediawiki
Outdated
* Bitstream, a protocol for the atomic swap (fair exchange) of bitcoins for decryption keys, that enables decentralized file hosting systems paid in Bitcoin. While such swaps are currently possible on Bitcoin without OP_CAT, they require the use of complex and computationally expensive Verifiable Computation cryptographic techniques. OP_CAT would remove this requirement on Verifiable Computation, making such protocols far more practical to build in Bitcoin. <ref>R. Linus, "BitStream: Decentralized File Hosting Incentivised via Bitcoin Payments", 2023, https://robinlinus.com/bitstream.pdf</ref> | ||
* Tree signatures provide a multisignature script whose size can be logarithmic in the number of public keys and can encode spend conditions beyond n-of-m. For instance a transaction less than 1KB in size could support tree signatures with up to 4,294,967,296 public keys. This also enables generalized logical spend conditions. <ref> P. Wuille, "Multisig on steroids using tree signatures", 2015, https://blog.blockstream.com/en-treesignatures/</ref> | ||
* Post-Quantum Lamport signatures in Bitcoin transactions. Lamport signatures merely require the ability to hash and concatenate values on the stack. <ref>J. Rubin, "[bitcoin-dev] OP_CAT Makes Bitcoin Quantum Secure [was CheckSigFromStack for Arithmetic Values]", 2021, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019233.html</ref> It has been proposed that if ECDSA is broken or a powerful computer was on the horizon, there might be an effort to protect ownership of bitcoins by allowing people to mark their taproot outputs as "script-path only" and then move their coins into such outputs with a leaf in the script tree requiring a Lamport signature. It is an open question if a tapscript commitment would preserve the quantum resistance of Lamport signatures. Beyond this question, the use of Lamport Signatures in taproot outputs is unlikely to be quantum resistant even if the script spend-path is made quantum resistant. This is because taproot outputs can also be spent with a key. An attacker with a sufficiently powerful quantum computer could bypass the taproot script spend-path by finding the discrete log of the taproot output and thus spending the output using the key spend-path. The use of "Nothing Up My Sleeve" (NUMS) points as described in [[bip-0341.mediawiki|BIP341]] to disable the key spend-path does not disable the key spend-path against a quantum attacker as NUMS relies on the hardness of finding discrete logs. We are not aware of any mechanism which could disable the key spend-path in a taproot output without a softfork change to taproot. | ||
* Non-equivocation contracts <ref>T. Ruffing, A. Kate, D. Schröder, "Liar, Liar, Coins on Fire: Penalizing Equivocation by Loss of Bitcoins", 2015, https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf</ref> in tapscript provide a mechanism to punish equivocation/double spending in Bitcoin payment channels. OP_CAT enables this by enforcing rules on the spending transaction's nonce. The capability is a useful building block for payment channels and other Bitcoin protocols. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.727.6262&rep=rep1&type=pdf
doesn't seem to be the correct link for me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe that link is dead now. Let me fix it, thanks for finding.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
It seems useful to use the ACM DOI URI for that paper mentioned above with the nonfunctional link: https://dl.acm.org/doi/10.1145/2810103.2813686 It is very likely to still work for ten more years. Although it is paywalled, people can find free versions online. |
The requested "Backwards Compatibility" section has been added.
The build check was failing, because the BIP had not been added to the table in the README yet, so I added a commit to add it to the table. |
Yep, sorry, we weren't allowed to upload it to eprint.iacr.org or arXiv due to copyright reasons. (The ACM is evil...) But it's lawfully available under https://publications.cispa.saarland/565/1/penalizing.pdf (Web Archive: https://web.archive.org/web/20221023121048/https://publications.cispa.saarland/565/1/penalizing.pdf), and I've also just made it available under https://raw.githubusercontent.com/real-or-random/accas/master/paper.pdf (Web Archive: https://web.archive.org/web/20240506104315/https://raw.githubusercontent.com/real-or-random/accas/master/paper.pdf). |
@real-or-random Just added a stable URL for Liar, Liar, Coins on Fire! citation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 7ad0f82
Seems to me that all open review comments have been addressed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 7ad0f82
This BIP defines OP_CAT a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126.
See our implementation PR in bitcoin-inquisition: bitcoin-inquisition/bitcoin#39