📅 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>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:57:39
in reply to nevent1q…zgrw
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:57:39Event JSON
{
"id": "79d7def6fd2d7a219f95d9ba11d1f5e05c790d14c3197da71bc89bae81b132f8",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160659,
"kind": 1,
"tags": [
[
"e",
"fd141301718697000f942ebd7100178f690819e8eb751b48f40a986556f0512e",
"",
"root"
],
[
"e",
"8b94abfe3cb695c741b966c5eb39a8dbde2c4ce392e75c7aceff8262d60bdd52",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-03-22\n📝 Original message:Some questions:\n\nDoes this require information to be added to blocks, or can it work today\non the existing format?\n\nDoes this count number of transactions or their total length? The block\nlimit is in bytes rather than number of transactions, but transaction\nnumber can be a reasonable proxy if you allow for some false negatives but\nwant a basic sanity check.\n\nDoes this allow for proofs of length in the positive direction,\ndemonstrating that a block is good, or does it only serve to show that\nblocks are bad? Ideally we'd like an extension to SPV protocol so light\nclients require proofs of blocks not being too big, given the credible\nthreat of there being an extremely large-scale attack on the network of\nthat form.\n\n\nOn Wed, Mar 22, 2017 at 1:47 AM, Luke Dashjr via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Despite the generalised case of fraud proofs being likely impossible, there\n\u003e have recently been regular active proposals of miners attacking with simply\n\u003e oversized blocks in an attempt to force a hardfork. This specific attack\n\u003e can\n\u003e be proven, and reliably so, since the proof cannot be broken without also\n\u003e breaking their attempted hardfork at the same time.\n\u003e\n\u003e While ideally all users ought to use their own full node for validation\n\u003e (even\n\u003e when using a light client for their wallet), many bitcoin holders still do\n\u003e not. As such, they are likely to need protection from these attacks, to\n\u003e ensure\n\u003e they remain on the Bitcoin blockchain.\n\u003e\n\u003e I've written up a draft BIP for fraud proofs and how light clients can\n\u003e detect\n\u003e blockchains that are simply invalid due to excess size and/or weight:\n\u003e\n\u003e https://github.com/luke-jr/bips/blob/bip-sizefp/bip-sizefp.mediawiki\n\u003e\n\u003e I believe this draft is probably ready for implementation already, but if\n\u003e anyone has any idea on how it might first be improved, please feel free to\n\u003e make suggestions.\n\u003e\n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170322/d02f0db1/attachment.html\u003e",
"sig": "7c20238443b90672daa6881ce7af8e832580aca370f217e6f657aceb72efabd7e4eea3e806b54f57a55f7cf0deaffdc870f15a94f3f6a4625a032779c45f8523"
}