Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-22 📝 Original message:Despite the generalised ...
📅 Original date posted:2017-03-22
📝 Original message:Despite the generalised case of fraud proofs being likely impossible, there
have recently been regular active proposals of miners attacking with simply
oversized blocks in an attempt to force a hardfork. This specific attack can
be proven, and reliably so, since the proof cannot be broken without also
breaking their attempted hardfork at the same time.
While ideally all users ought to use their own full node for validation (even
when using a light client for their wallet), many bitcoin holders still do
not. As such, they are likely to need protection from these attacks, to ensure
they remain on the Bitcoin blockchain.
I've written up a draft BIP for fraud proofs and how light clients can detect
blockchains that are simply invalid due to excess size and/or weight:
https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki
I believe this draft is probably ready for implementation already, but if
anyone has any idea on how it might first be improved, please feel free to
make suggestions.
Luke
📝 Original message:Despite the generalised case of fraud proofs being likely impossible, there
have recently been regular active proposals of miners attacking with simply
oversized blocks in an attempt to force a hardfork. This specific attack can
be proven, and reliably so, since the proof cannot be broken without also
breaking their attempted hardfork at the same time.
While ideally all users ought to use their own full node for validation (even
when using a light client for their wallet), many bitcoin holders still do
not. As such, they are likely to need protection from these attacks, to ensure
they remain on the Bitcoin blockchain.
I've written up a draft BIP for fraud proofs and how light clients can detect
blockchains that are simply invalid due to excess size and/or weight:
https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki
I believe this draft is probably ready for implementation already, but if
anyone has any idea on how it might first be improved, please feel free to
make suggestions.
Luke