BIP 337: Compressed Transactions

[TomBriar]

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.

[apoelstra]

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.

[murchandamus]

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?

[TomBriar]

Thank you @murchandamus, all changes were accepted!

[murchandamus]

Thanks, I aim to give this a proper review soon

[murchandamus]

Hi @TomBriar, I went over the complete document, the Bitcoin Core pull request, and the mailing list. Your document almost fulfills the formatting requirements, I left one nit and one open question that you may want to consider. The description is clear, concise, and appears to be comprehensive. Since the Bitcoin Core pull request was closed, I was wondering whether this proposal is actively deployed by other software (although that is not necessary for this to be merged).

[murchandamus]

Hey @TomBriar, I’m not sure what happened here, it looks like you started working on this, but maybe you did not push the changes yet?

If the answer to my two open questions would be that alternative designs are not relevant, and the proposal is currently not implemented in any software that would be satisfactory answers to me—I just thought if those answers were different it would be nice to mention it.

As soon as you push your changes, I can take it from there. The only things missing would be to assign a number and merge it, which I can take care of.

[TomBriar]

@murchandamus Hi, Yes there is actually a relevant implementation I am finishing the finial touches on it today and I'll link it all together and have this ready to go by EOD. Thank you for your patience!

Thanks-
Tom.

[murchandamus]

I see, thanks for the update!

[TomBriar]

Hi,

Just pushed changes that address all of the above reviews, As stated, there is a project that I am aware of that will enable people to use steganography to encode data into images although it is not complete and I was not given an ETA. That said I have built a tool that implements the scheme described here. The hope is that with this BIP, future projects will all use this scheme for compressed Bitcoin transactions, and potentially bitcoin core itself can use parts of it in P2P or Block Storage.

https://github.com/TomBriar/compressed_transactions

Thanks-
Tom.

[murchandamus]

Hey, you wrote that you pushed, but I don’t see a change. Could you check whether the push went through?

[murchandamus]

Spotted a missing word here, but otherwise LGTM.

[murchandamus]

I assign this BIP 337

[TomBriar]

Hi, Thanks!

I made that change and fixed the BIP number field.

-Tom

[murchandamus]

I fixed the Comments-URI header, added an entry in the README.mediawiki table, and moved your BIP to the numbered file

[TomBriar]

Awesome thank you!

[murchandamus]

Thank you, and congrats! :)