From: Matt Corallo <lf-lists@mattcorallo.com>
To: Bram Cohen <bram@bittorrent.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>,
Bram Cohen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>,
Luke Dashjr <luke@dashjr.org>
Subject: Re: [bitcoin-dev] Fraud proofs for block size/weight
Date: Wed, 22 Mar 2017 21:51:08 +0000 [thread overview]
Message-ID: <30FB8B13-135D-4905-B1B4-76D79341CA02@mattcorallo.com> (raw)
In-Reply-To: <CA+KqGkqD0z1O6+pCNaB-vCu_YW2-eO9nmrwcnQ--574t95hghg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
It works today and can be used to prove exact size: the key observation is that all you need to show the length and hash of a transaction is the final SHA256 midstate and chunk (max 64 bytes). It also uses the observation that a valid transaction must be at least 60 bytes long for compression (though much of that compression possibility goes away if you're proving something other than "too large").
On March 22, 2017 1:49:08 PM PDT, Bram Cohen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>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@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
[-- Attachment #2: Type: text/html, Size: 3705 bytes --]
next prev parent reply other threads:[~2017-03-22 21:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 8:47 [bitcoin-dev] Fraud proofs for block size/weight Luke Dashjr
2017-03-22 20:49 ` Bram Cohen
2017-03-22 21:51 ` Matt Corallo [this message]
2017-03-23 18:27 ` Jorge Timón
2017-03-25 5:16 ` Luke Dashjr
2017-03-26 14:16 ` Chris Pacia
2017-03-28 22:35 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30FB8B13-135D-4905-B1B4-76D79341CA02@mattcorallo.com \
--to=lf-lists@mattcorallo.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=bram@bittorrent.com \
--cc=luke@dashjr.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox