Bram Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-22 📝 Original message:Some questions: Does this ...
📅 Original date posted:2017-03-22
📝 Original message:Some questions:
Does this require information to be added to blocks, or can it work today
on the existing format?
Does this count number of transactions or their total length? The block
limit is in bytes rather than number of transactions, but transaction
number can be a reasonable proxy if you allow for some false negatives but
want a basic sanity check.
Does this allow for proofs of length in the positive direction,
demonstrating that a block is good, or does it only serve to show that
blocks are bad? Ideally we'd like an extension to SPV protocol so light
clients require proofs of blocks not being too big, given the credible
threat of there being an extremely large-scale attack on the network of
that form.
On Wed, Mar 22, 2017 at 1:47 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170322/d02f0db1/attachment.html>;
📝 Original message:Some questions:
Does this require information to be added to blocks, or can it work today
on the existing format?
Does this count number of transactions or their total length? The block
limit is in bytes rather than number of transactions, but transaction
number can be a reasonable proxy if you allow for some false negatives but
want a basic sanity check.
Does this allow for proofs of length in the positive direction,
demonstrating that a block is good, or does it only serve to show that
blocks are bad? Ideally we'd like an extension to SPV protocol so light
clients require proofs of blocks not being too big, given the credible
threat of there being an extremely large-scale attack on the network of
that form.
On Wed, Mar 22, 2017 at 1:47 AM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170322/d02f0db1/attachment.html>;