btcd's bugs were not vulnerabilities. The specification and bitcoin core implementation has no sensible resource consumption limits on witness sizes. That's all it was. As a Go programmer, I am also very avid about keeping resources under control. It actually helps a lot with security as well. Resource exhaustion attacks can destroy peer to peer networks functionality.
Whoever is paying for development says what will get done. But the new features you speak of still work even when a minority of nodes support it, because they recognise each other as being able to and can make paths to run these new protocol API components.
Just like there is still a huge number of bitcoin nodes that still don't have segwit enabled.
We don't have to agree. This is a peer to peer system, ultimately. And LN can tolerate even more divergence than the bitcoin protocol because it's purely peer to peer.
You're free to fud and attack whoever you like but building is what gets you respect.
The specification and bitcoin core implementation has no sensible resource consumption limits on witness sizes. That's all it was. As a Go programmer, I am also very avid about keeping resources under control. It actually helps a lot with security as well. Resource exhaustion attacks can destroy peer to peer networks functionality.
Well yeah the Taproot BIP spec explicitly removes the previous sigop and witness stack size limits, only to be bound by the blocksize instead.
Hence I would consider the bugs as vulnerabilities as they left lnd in a semi-glitchy state.
I agree with all your other points though.
reply
all of your points are very logical ....cant disagree
reply