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
Compressed Bitcoin Transactions #29134
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
d03ebbb
to
ed0e798
Compare
ed0e798
to
7a0018c
Compare
9165635
to
77828b8
Compare
Concept ACK 25-50% savings look good and compressed raw transactions can help in some cases as mentioned in the PR description. Related Q&A: https://bitcoin.stackexchange.com/questions/98886/compress-transaction-hex-string (still wont fit in one text message but will need less text messages) |
c1cceb3
to
0430476
Compare
Is this intended to be used for storage, p2p relay, or something else? If for our storage, I would be interested in seeing benchmarks as this would have an effect on how quickly things can be pulled from disk to be relayed. If for relay, then I think there should first be a BIP that describes the protocol for using compression and how that is negotiated. And if neither of those, then I don't think it's within the scope of Bitcoin Core. It seems to be a pretty significant maintenance burden for something that, as implemented, is only used by specific new RPCs. |
0430476
to
1ecfbd7
Compare
f202aab
to
ba03fc9
Compare
edfe03b
to
b35fd06
Compare
5d1c78a
to
baeba39
Compare
baeba39
to
7e8511c
Compare
My understanding is that it requires the chainstate, so this is written inside of Bitcoin Core. However, I am also wondering if existing RPCs can be used to query the chainstate, or if the RPC interface could be extended, if needed. Putting this piece of code directly in the satellite broadcast software seems easier and preferable. |
7e8511c
to
7ca85bf
Compare
e9d3ac7
to
8c8c47d
Compare
8c8c47d
to
9fafa2b
Compare
…nsaction, For valid assets_tests run compression tests, Added unit tests for new primitives
9fafa2b
to
a850ab0
Compare
Closing for now due to lack of replies to questions. Please reply below, and leave a comment if this should be reopened. |
This is a draft PR and reference implementation for a Compressed Bitcoin Transaction, As stated in the doc the main application for this is steganography, satellite/radio broadcast, and other low bandwidth channels with a high CPU availability on decompression.
doc: Added Compressed Transaction Schema Documentation
util: Added a variable length bitstream encoder
script: Added the rest of the IsPayTo Script functions, And Split ExtractDestination into two functions for ease of use
node: Added a vector based coin lookup
primitives: Added Compressed Transaction
validation: Added OutPoint Compression methods to the chainstate class
rpc: Added RPC endpoints for compression and decompression of Transactions
test: Added Tests for the RPC and new Primitive
fuzz: Added a fuzz test for Compressed Transactions
Link to first post on the bitcoin mailing list:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021924.html