Hi Tom,
without having gone into the details yet, thanks for the great effort you have
put into this research and implementation already!
> The bulk of our size savings come from replacing the prevout of each input by
> a block height and index.
Have you also considered using just an index fro
Hi Tom,
I realized I simplified my message a bit too much. Of course an index of the
UTXO set would also need a height, so I rather meant some kind of composite
reference I guess. An index alone might be enough if a height has been
pre-agreed which could still be compatible with the use-cases y
Hi Fabian,
We did consider indexing all txos -- even, amusingly, by using ordinals --
but decided that the extra index requirements for the decompressor (which
otherwise just requires a bit of extra CPU cycles but nothing beyond a
normal Core node).
A while ago we looked into putting the whole UT
Hi Fabian,
Yes as Andrew said, creating a prefix tree is going to take up more space then
simply the block height and then an index for the UTXO in the block. We removed
the vout from the encoding by doing almost exactly what you said per block
where it’s a flattened index over all the transact
Hi Tom
> I've been working on a way to compress bitcoin transactions for transmission
> through steganography, satellite broadcasting,
Interesting. Some size numbers (vs plain, vs gzip) would be nice.
Maybe add a definition to your BIP that makes clear when NOT to use
height/index due to risk
Hi Jonas,
I’m working to get numbers based on both historical data and from fuzz tests
but I’m in the middle of updating the code to match the doc, I should have it
finished before the end of the week.
We estimate that 100 blocks is safe from reorg, that is the same policyfor
spending coin bas
