📅 Original date posted:2018-05-17
📝 Original message:Matt: That's a good point. I'll do up a chart comparing utxo size at each
block, as well as comparing over-the-wire size for each block. I think the
period of coalescing earlier this year should be a good example of what
you're describing.
Greg: heh, I was wondering how long it would take for someone to point out
that I'm cheating. I avoided using the word "compression", mostly to
side-step having the discussion turning into reworking the wire
serialization. But you're absolutely right, the de-duping benefits are
independent of the UHS use-case.
Cory
On Thu, May 17, 2018, 12:56 PM Gregory Maxwell <greg at xiph.org> wrote:
> On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Tl;dr: Rather than storing all unspent outputs, store their hashes.
>
> My initial thoughts are it's not _completely_ obvious to me that a 5%
> ongoing bandwidth increase is actually a win to get something like a
> 40% reduction in the size of a pruned node (and less than a 1%
> reduction in an archive node) primarily because I've not seen size of
> a pruned node cited as a usage limiting factor basically anywhere. I
> would assume it is a win but wouldn't be shocked to see a careful
> analysis that concluded it wasn't.
>
> But perhaps more interestingly, I think the overhead is not really 5%,
> but it's 5% measured in the context of the phenomenally inefficient tx
> mechanisms ( https://bitcointalk.org/index.php?topic=1377345.0 ).
> Napkin math on the size of a txn alone tells me it's more like a 25%
> increase if you just consider size of tx vs size of
> tx+scriptpubkeys,amounts. If I'm not missing something there, I think
> that would get in into a very clear not-win range.
>
> On the positive side is that it doesn't change the blockchain
> datastructure, so it's something implementations could do without
> marrying the network to it forever.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180517/84d84610/attachment.html>;
Cory Fields [ARCHIVE] /
npub19r…yj32s
2023-06-07 18:12:08
in reply to nevent1q…2wq7
Author Public Key
npub19r53ufymeycp9wzk3yzru55y5u46e4vva2lj7nak4zrn6yhrna7qsyj32sSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:12:08Event JSON
{
"id": "3bef7678e9b6354056e78858f859b8907daeaea3ea1e301b59c39e94ca5808b9",
"pubkey": "28e91e249bc93012b85689043e5284a72bacd58ceabf2f4fb6a8873d12e39f7c",
"created_at": 1686161528,
"kind": 1,
"tags": [
[
"e",
"eabff6113b025739bbbbba2fed799c5fd10f099dbd401b210313123b44276f13",
"",
"root"
],
[
"e",
"1712744b571917ac7f44dadd8969472329d6bd766b93dab9a8e2efb89a2a8655",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2018-05-17\n📝 Original message:Matt: That's a good point. I'll do up a chart comparing utxo size at each\nblock, as well as comparing over-the-wire size for each block. I think the\nperiod of coalescing earlier this year should be a good example of what\nyou're describing.\n\nGreg: heh, I was wondering how long it would take for someone to point out\nthat I'm cheating. I avoided using the word \"compression\", mostly to\nside-step having the discussion turning into reworking the wire\nserialization. But you're absolutely right, the de-duping benefits are\nindependent of the UHS use-case.\n\nCory\n\nOn Thu, May 17, 2018, 12:56 PM Gregory Maxwell \u003cgreg at xiph.org\u003e wrote:\n\n\u003e On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Tl;dr: Rather than storing all unspent outputs, store their hashes.\n\u003e\n\u003e My initial thoughts are it's not _completely_ obvious to me that a 5%\n\u003e ongoing bandwidth increase is actually a win to get something like a\n\u003e 40% reduction in the size of a pruned node (and less than a 1%\n\u003e reduction in an archive node) primarily because I've not seen size of\n\u003e a pruned node cited as a usage limiting factor basically anywhere. I\n\u003e would assume it is a win but wouldn't be shocked to see a careful\n\u003e analysis that concluded it wasn't.\n\u003e\n\u003e But perhaps more interestingly, I think the overhead is not really 5%,\n\u003e but it's 5% measured in the context of the phenomenally inefficient tx\n\u003e mechanisms ( https://bitcointalk.org/index.php?topic=1377345.0 ).\n\u003e Napkin math on the size of a txn alone tells me it's more like a 25%\n\u003e increase if you just consider size of tx vs size of\n\u003e tx+scriptpubkeys,amounts. If I'm not missing something there, I think\n\u003e that would get in into a very clear not-win range.\n\u003e\n\u003e On the positive side is that it doesn't change the blockchain\n\u003e datastructure, so it's something implementations could do without\n\u003e marrying the network to it forever.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180517/84d84610/attachment.html\u003e",
"sig": "018f5705e43ad2425941ad06b0d165c1b213849fc024b981d0c7e403a7f8a46d9188ab16e515d1e225ec4bfcb0bcd566ea7b6eb008d9fff21261d28b9f2cb5fc"
}