From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org, "Jorge Timón" <jtimon@jtimon•cc>
Subject: Re: [bitcoin-dev] Fraud proofs for block size/weight
Date: Sat, 25 Mar 2017 05:16:25 +0000 [thread overview]
Message-ID: <201703250516.26362.luke@dashjr.org> (raw)
In-Reply-To: <CABm2gDpgTtiftByQhD_TtzgD5Tv==io2+TGiTCnMt9onquVBmw@mail.gmail.com>
On Thursday, March 23, 2017 6:27:39 PM Jorge Timón via bitcoin-dev wrote:
> I think it would be clearer to put the "Creation of proofs" section
> before "Proof verification", maybe even before "Proof format" if a
> high level defintion of "full tx size proof" is provided before.
Creation of proofs isn't part of the spec itself.
I've moved it out of the Specification section (but it's still below it).
> Also, in "For the full-size proof, each transaction should be assumed
> to be at a minimum the stripped-size rather than the fixed 60 bytes."
> it seems you are referring to a "full-size block proof" as opposed to
> a "full size tx proof", perhaps a better term could be "full-weight
> block proof" if what you are referring to is the proof of the weight
> instead of only the pre-segwit size.
>
> Perhaps some short definitions for "stripped-size proof", "full tx
> size proof", "full-size proof" and maybe also "size component" at the
> beginning would be enough.
Added a definitions section above.
> In "Network protocol", "It should not recheck blocks known to be
> valid, " does "known to be valid" include the blocks that the peer
> told us where valid (with their hash and 0 in the enumerated varint)?
> Those could be invalid too if the peer was lying, no?
> Do you mean "It should not recheck blocks known to be invalid,"?
Right, fixed.
> Why do you need to have at least one full tx size?
>
> In Rationale you have:
> "
> Why must a full tx size proof be included?
>
> This is necessary to establish that the claimed block transaction
> count is correct.
> "
>
> Why do you need to establish that? If you can establish that the
> number of transactions is at least N and that N * 60 bytes is greater
> than the size/weight limit, isn't it that enough?
The only way to establish the number of transactions at all, is to show that a
leaf is a parsable transaction. Which this doesn't actually show, so it's
broken. :( Need to think on this. Any ideas? :/
Luke
next prev parent reply other threads:[~2017-03-25 5:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 8:47 Luke Dashjr
2017-03-22 20:49 ` Bram Cohen
2017-03-22 21:51 ` Matt Corallo
2017-03-23 18:27 ` Jorge Timón
2017-03-25 5:16 ` Luke Dashjr [this message]
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=201703250516.26362.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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