Hi All,
Here are some final results of testing with the reference implementation
for compressing blocks and transactions. This implementation also
concatenates blocks and transactions when possible so you'll see data
sizes in the 1-2MB ranges.
Results below show the time it takes to sync the
Hi All,
Here are some final results of testing with the reference implementation
for compressing blocks and transactions. This implementation also
concatenates blocks and transactions when possible so you'll see data
sizes in the 1-2MB ranges.
Results below show the time it takes to sync the
(I haven't been following this development recently so apologies in advance
if I've made assumptions about RBF)
If you made CPFP consensus critical for all Full-RBF transactions, RBF
should be safer to use. I see RBF as a necessity for users to fix mistakes
(and not for transaction
It appears you're using the term "compression ratio" to mean "size reduction".
A compression ratio is the ratio (compressed / uncompressed). A 1 kB file
compressed with a 10% compression ratio would be 0.1 kB. It seems you're using
(1 - compressed/uncompressed), meaning that the compressed file
yes, you're right, it's just the percentage compressed (size reduction)
On 28/11/2015 4:30 PM, Jonathan Toomim wrote:
> It appears you're using the term "compression ratio" to mean "size
> reduction". A compression ratio is the ratio (compressed /
> uncompressed). A 1 kB file compressed with a
