📅 Original date posted:2018-05-17
📝 Original message: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.
Gregory Maxwell [ARCHIVE] /
npub1f2…crwet
2023-06-07 18:12:08
in reply to nevent1q…jg9p
Author Public Key
npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetSeen on
wss://relay.noswhere.comPublished at
2023-06-07 18:12:08Event JSON
{
"id": "1712744b571917ac7f44dadd8969472329d6bd766b93dab9a8e2efb89a2a8655",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686161528,
"kind": 1,
"tags": [
[
"e",
"eabff6113b025739bbbbba2fed799c5fd10f099dbd401b210313123b44276f13",
"",
"root"
],
[
"e",
"c0416322f5c96b972711baa4efa53aa879974960a14cae979595f3f3bdadd2e4",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2018-05-17\n📝 Original message:On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Tl;dr: Rather than storing all unspent outputs, store their hashes.\n\nMy initial thoughts are it's not _completely_ obvious to me that a 5%\nongoing bandwidth increase is actually a win to get something like a\n40% reduction in the size of a pruned node (and less than a 1%\nreduction in an archive node) primarily because I've not seen size of\na pruned node cited as a usage limiting factor basically anywhere. I\nwould assume it is a win but wouldn't be shocked to see a careful\nanalysis that concluded it wasn't.\n\nBut perhaps more interestingly, I think the overhead is not really 5%,\nbut it's 5% measured in the context of the phenomenally inefficient tx\nmechanisms ( https://bitcointalk.org/index.php?topic=1377345.0 ).\nNapkin math on the size of a txn alone tells me it's more like a 25%\nincrease if you just consider size of tx vs size of\ntx+scriptpubkeys,amounts. If I'm not missing something there, I think\nthat would get in into a very clear not-win range.\n\nOn the positive side is that it doesn't change the blockchain\ndatastructure, so it's something implementations could do without\nmarrying the network to it forever.",
"sig": "3fc778925dee0b1cb5fb5280745370fe448112e5b73a8c55df9cc764df1f4fad544af6507a249ac851a623b9c225a19f1ce72c232acf5b227b972afed212dd50"
}