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-tombriar-compressed-transactions #1556
base: master
Are you sure you want to change the base?
bip-tombriar-compressed-transactions #1556
Conversation
Hi Tom, Thanks for posting this. I'd suggest rewording the abstract and PR description to avoid talking in terms of Core internals (classes, subclasses, etc) and instead simply describe the serialization. It's fine to describe suggested RPC endpoints since these give an idea of how the specification might be used. |
|- | ||
! Name !! Width !! Description | ||
|- | ||
| Compressed Signature || 1 Bit || Signature compression flag. For P2TR: 1 for keyspend, 0 for scriptspend; For P2SH: 0 for p2sh, 1 for p2sh-wpkh. |
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.
Maybe mention that for optut types other than P2TR and P2SH this bit is unused.
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.
It's used for all script types but has special implications for P2TR and P2SH-WPKH. I reworded for clarity.
be1f84e
to
e5af215
Compare
e5af215
to
b6be561
Compare
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.
Light first review. Looks pretty good, could you please add the mandatory "Backwards Compatibility" section (even if it just says that there are no concerns) and take a look at the preamble?
Comments-URI: https://github.com/bitcoin/bitcoin/pull/29134 | ||
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html |
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 think this is mixing up the "Comments-URI" and the "Post-History" headers.
Comments-URI: https://github.com/bitcoin/bitcoin/pull/29134 | |
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html | |
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-tombriar-compressed-transactions |
Status: Draft | ||
Type: Standards Track | ||
Created: 2024-02-01 | ||
License: BSD-3-Clause |
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.
License: BSD-3-Clause | |
License: BSD-3-Clause | |
Post-History: https://github.com/bitcoin/bitcoin/pull/29134 | |
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html |
=== Motivation === | ||
Typical Bitcoin transactions usually contain a large amount of white space and padding due to specific fields that are often one of a minimal number of possibilities. We can use this fact and a few similar methods to create an encoding for 90% of Bitcoin transactions that are roughly 25-50% smaller. | ||
|
||
=== Rational === |
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.
=== Rational === | |
=== Rationale === |
This document proposes a serialization scheme for compressing bitcoin transactions. The compressed bitcoin transactions can reach a serialized size of less than 50% of the original serialized transaction. One of the methods for compressing, involves reducing the transaction outpoints in a potentially lossy way, therefore it is an optional path for compression. Without compressing the outpoints, compressed transactions still reach less then 70% of the original size.
Reference Implementation:
bitcoin/bitcoin#29134
The reference implementation includes two new RPC endpoints to demonstrate how to use compressed transactions. The compressrawtransaction takes in a raw hex-encoded transaction and returns a compressed hex-encoded transaction, while the decompressrawtransaction accepts a compressed hex-encoded transaction and returns the original raw hex-encoded transaction.
Thanks-
Tom.