From: Mark Friedenbach <mark@monetize•io>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
Date: Sun, 27 Apr 2014 10:05:45 -0700 [thread overview]
Message-ID: <535D38E9.60209@monetize.io> (raw)
In-Reply-To: <535CF9BB.5010209@certimix.com>
On 04/27/2014 05:36 AM, Sergio Lerner wrote:
>> Without invoking moon math or assumptions of honest peers and
>> jamming-free networks, the only way to know a chain is valid is to
>> witness the each and every block. SPV nodes on the other hand,
>> simply trust that the most-work chain is a valid chain, based on
>> economic arguments about the opportunity cost of mining invalid
>> blocks.
> I argue that you cannot talk about "the most-work chain" without
> actually making an assumption about honest peers.
I should have said "without invoking moon math or interactive protocols
requiring honest peers over jamming-free networks." The interactive
protocol was more the point than the honest peers and jamming-free
network. Yes, without an honest peer and an un-jammed network, you might
never learn about the most-work chain in the first place. But having the
security of the proof not depend on query access to an honest full node
is absolutely necessary for some applications and certainly desirable in
others.
Although strictly speaking what I said may not be 100% true. The single
alternative solution I've seen involves some sort of Fiat–Shamir
transform that could give you a probabilistic proof by including random
additional paths through the block chain chosen based on the combined
hash of the headers. However this is disadvantageous as it massively
increases the proof size and verification time, and you have to include
a lot of data to achieve assurance that more work was required to
generate the fraud than an honest chain.
> If you do not make the assumption, you compute the "economic
> arguments" wrong.
Not necessarily. By requiring connectivity you know that what you are
receiving is built off of the main chain, for example, and you can still
make assumptions about resulting opportunity costs.
> First this is a method that uses NPPs, not SPV proofs. Since the
> method chooses all peers that are synchronized (have the latest
> current block) then going back means only skipping a potential short
> fork (which I suppose has never been more than 3 blocks during normal
> network conditions). You're looking for a common ancestor, not the
> checkpoint. So the linear scan is actually O(1). The exact value can
> be approximated by the sum of the convergent infinite geometrical
> sequence of forking probabilities, which it's about 1.03 without
> considering selfish-mining, and probably less than 2.03 considering
> it.
Unless you're connected to attacker nodes which are wildly divergent
from each other. It's relatively easy to create a massive fake history
of difficulty-1 blocks.
If you assume honest peers things get very easy. But that's not a safe
assumption to be making. With back-link block-history commitments, on
the other hand, an interactive protocol allows you to do a binary search
to find common ancestors, and have trust that the intermediate links
actually exist.
next prev parent reply other threads:[~2014-04-27 17:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-27 1:08 Sergio Lerner
2014-04-27 1:43 ` Mark Friedenbach
2014-04-27 2:39 ` Sergio Lerner
2014-04-27 6:43 ` Mark Friedenbach
2014-04-27 12:36 ` Sergio Lerner
2014-04-27 17:05 ` Mark Friedenbach [this message]
2014-04-28 14:32 ` Sergio Lerner
2014-04-28 17:29 ` Mark Friedenbach
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=535D38E9.60209@monetize.io \
--to=mark@monetize$(echo .)io \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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