pull down to refresh
This is helpful. Especially your reminder that we don't operate in a vacuum.
Prior to working on this post, I assumed that assumevalid later validated transactions from genesis (similar to assumeutreexo's behavior). It surprised me that this was not the case.
What I'm curious about is if there are lots of node runners like me, And if this group grows to be a large portion of the nodes on the network, all is us not validating below a certain block height, what changes about the network's security properties?
It surprised me that this was not the case.
It's because, unlike assumeutxo and assumeutreexo, you do validation on everything but you only skip the script interpreter (incl signature) validation step. So you will still have validated that the total utxoset isn't inflated with paper bitcoin. And there is a massive PoW gate on the validity of it. Barring sha256d preimages being feasible, If someone were to rewrite history, it would be very hard to not notice.
If there are lots of node runners like me
I think that bottom line, it matters what choices we make, for ongoing network hygiene and in the face of adversity. It's of course better if there's no shitshow going on but we may get a chance to run through the test once more this year... let's hope Bitcoin is still not a reflection of overall society.
If you're curious / so sovereign you wanna validate it all... do it! It is good for the network if you do - one more independent validation. I trust you'd write about it if you find something - also I don't think you will find something.
what changes about the network's security properties?
There's still PoW on it. Block work accumulates into chainwork because it's a block chain, where each block confirms the entire chain before it. It's hard to mess with. I think running a vulnerable or slow node is worse for the network's security properties than running a default configured node. Also, if you don't mine and you have no idea how you're going to defend your economic value (remember Voskuil's thing on this) then I don't think you really can influence the security. If your node gets hijacked and it does really nasty shit on a p2p connection to me that isn't punished by the algo, I will just manually ban it... easy.
I feel that I may have misunderstood something (or at least not done a good job of writing about it).
I didn't mean to imply that people would retroactively change things in already confirmed blocks.
I meant that an assumevalid node is not capable of catching an invalid transaction such as a coin being spent by someone who doesn't have the private keys for it.
So, the assumevalid node has to trust that the other nodes on the network and the miners are doing such checks.
Which is why I was comparing it to an SPV trust model. But I think where I am confused is this:
Since assumevalid nodes are validating all new transactions they learn about, they have stronger security than an SPV node as long as they are confident that there was no time before the assumed valid block when people weren't validating all new transactions. Whereas, an SPV node doesn't bother validating anything.
But still, i'm struggling with this, because it seems to me that valodating things higher uo in a chain, without validating the chain from genesis will alwaya carry the assumption that the majority of the network is honest...and isn't that the same assumption as SPV?
I didn't mean to imply that people would retroactively change things in already confirmed blocks.
But what other way is that possible if:
- you do not live in a vaccum, and
- many people have validated the chain fully
To give you an example based on something real: in 2013 opti got some coins.
Now let's add the hypothetical that opti didn't spend these coins (opti is somewhat of a retard, haha) and in 2026 opti's coins are magically gone. Would opti be calmly typing a comment to you now? Or would opti be screaming from the roofs: "dey took mah coins"?
I can guarantee you that the latter would be the case.
Note that:
txidis the cryptographic hash of the transaction- the
txidsof a block are built into amerkle tree, which is a method to create cryptographic proof of a "set of things" - the
merkle treeis put into theblock header - each block designates the
hash of the previous blockheaderit builds upon - this is why it ischain.
These are cryptographic proofs. Not some yolo thing where anyone can just say things like I do in this reply. Or some document. It's all SHA256, which, luckily for us, is still secure today. Combined with the difficulty of changing the entire chain of PoW, this gives integrity and makes blocks a few confirmations off the tip highly unlikely to be fake.
If you were to say that the coins opti got in 2013 were dishonest, what are you going to do about it? To undo this injustice, you will have to roll back the entire chain to 2013, which is... costly. Think about it: every transaction you even made on LN is invalid because every block built upon the 2013 block would be invalid. Every zap on SN ever made? Invalid. You'd have to replay the entire transaction history and hope that opti's coins weren't in any ancestry path of any LN channel you used, or they used, and so on. Highly unlikely!
So it does not matter if opti tricked the entire network in 2013 to give opti coins. The truth is in the chain, and the chain wasn't challenged. Full validation of the current blocks is way more important, because if you see an invalid spend in the current block, then you could act on it.
But what is very important: you can do all the validation yourself.
Here's how I would use assumevalid for new bitcoiners:
- Just use it.
- if you cannot sync to the same tip as all your buddies, hardware issues are suspect #1, software bugs are the second most likely cause, eclipse attacks with block withholding and alt chain fabrication, however unlikely, are currently still more likely than an integrity issue in the highest value timestamp network in the world. Unless you own over 50% of all coins, the rest of the network has a greater incentive to not have chain integrity issues than you, and this is what is leveraged.
If however you're a prepper and you want to have a fully archived chain copy that you have verified by yourself without trusting anyone, and need a backup of, for when WW3 turns out to not be WWE, then set up 2 nodes with ECC memory, RAID-10 disks, do the IBD without assumevalid. Then when both nodes are sync, compare the chaintip (hash should be enough.) Then on both run the linearize script and take shasums of the bootstrap files. Sign the file with a single use pgp key. Burn these to a bunch of those high-quality bluray disks, multiple copies. Put these in your bunker, in your sibling's bunker and in your friend's bunker. And send one to Darth for safekeeping in the citadel along with some CCs as thanks.
Now you have a copy of the chain that, when the whole world is nuked, is likely to be absolutely useless, but you have it. And you've fully verified it yourself. Which has value to you, but less to me - I have my own bootstrap file.
assumevalid does all checks except script validation. Among other things, it verifies that the transaction bytes hash to the txid, and the Merkle root commits to all txid in the correct order. It checks that every block header commits to the previous block header, and that the assumevalid block is in the header chain. It also rebuilds the UTXO set from scratch. With that you are guaranteed to have the same blockchain byte-by-byte up to the assumevalid block as the rest of the network had when the assumevalid block was defined. Otherwise, the assumevalid header would not be in your header chain. To arrive at a different UTXO set, you’d have to interpret a byte-by-byte matching transaction differently than the rest of the network.
If your software were to do that, it’s broken, but (maliciously) broken software could also mislead you in any other number of ways. That’s why you should always check the signatures on the binary or build from the source code yourself, but even then you trust the people that created the binary that someone would cry foul if there were a conspiracy going on.
Given which other types of trust are extended when assuming that non-assumevalid sync is trustworthy, I am confused when people posit that assumevalid is a significant step up in trust.
It checks that every block header commits to the previous block header, and that the assumevalid block is in the header chain.
Isn't this the same level of security as SPV?
It also rebuilds the utxo set from scratch
But if they don't check for validity, the node is trusting that the rest of the network did such checks. What is the difference between this and an SPV node trusting that the longest the majority of hash power isn't tricking them?
Remember that not everyone syncs at the same time[1] and that you don't live in a vacuum. If you do live in a vacuum and you know or trust no one, then you should probably turn off the assumptions. It's not like it takes forever if you have decent node hardware. Just takes a while.
I think it is more important that your node isn't vulnerable and that you make well informed choices, for you, not anyone else, in how you configure your node and which software client you run.
It's just a default setting, it's a choice to leave it on. Use @lopp's configurator if you want to learn more about the configuration choices you can make. I think it gives nice explanations and I'm sure stackers would help out if you have questions after that.
A block that you may not check script on now, my node, that I've been upgrading since 0.16, has in fact fully validated. It agrees with
mempool.spaceabout the chaintip, in case you were wondering. ↩