waxwing on Nostr: So apparently utxo set size has now already hit 160M. This is a huge blowup, ...
So apparently utxo set size has now already hit 160M. This is a huge blowup, presumably due to "stamps" and similar projects. I wonder if there is a way in which we can finesse by having a flavor of bitcoin node which is "optimistic", stores (in fast access let's say) only utxos above a certain value (somewhere above dust), and has a kind of slower recovery mode to deal with spends of utxos below that filter. I don't know if that makes any sense, especially outside of "blocksonly", and after all we can't have all nodes be blocks only! (or can we? err I just remembered that someone around here may disagree :) ).
Published at
2024-02-04 15:43:22 UTCEvent JSON
{
"id": "fd7f0865e8758904d4e50fa001c2320f11a066f08b44f1cc461680726504bedc",
"pubkey": "675b84fe75e216ab947c7438ee519ca7775376ddf05dadfba6278bd012e1d728",
"created_at": 1707061402,
"kind": 1,
"tags": [],
"content": "So apparently utxo set size has now already hit 160M. This is a huge blowup, presumably due to \"stamps\" and similar projects. I wonder if there is a way in which we can finesse by having a flavor of bitcoin node which is \"optimistic\", stores (in fast access let's say) only utxos above a certain value (somewhere above dust), and has a kind of slower recovery mode to deal with spends of utxos below that filter. I don't know if that makes any sense, especially outside of \"blocksonly\", and after all we can't have all nodes be blocks only! (or can we? err I just remembered that someone around here may disagree :) ).",
"sig": "b0e47bfcb57466f1bc47690e65244497d29969756989333c8b8a618980ad7f00e1fb39f0c153422a28335a3e3eae79f5be4e4e300bfa34dff19ae8a91a893557"
}