public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Alex Mizrahi <alex.mizrahi@gmail•com>
Cc: Bitcoin-Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)
Date: Mon, 3 Nov 2014 09:54:59 -0800	[thread overview]
Message-ID: <20141103175459.GT6400@shavo.vs.shawcable.net> (raw)
In-Reply-To: <CAE28kURz3smtwDvVuPQDFxosqB2tRNWiM3bf=BeLcjhJ2eiR5A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1310 bytes --]

On Mon, Nov 03, 2014 at 06:01:46PM +0200, Alex Mizrahi wrote:
> 
> Yes, but "harder" isn't same as "unlikely".
>

We are aware of the distintion between hardness (expected work) and
likelihood of successful attack -- much of Appendix B talks about this,
in the context of producing compact SPV proofs which are (a) hard to
forge, and (b) very unlikely to be forgeries.

We did spend some time formalizing this but due to space constraints
(and it being somewhat beside the point of the whitepaper beyond "we
believe it is possible to do"), we did not explore this in as great
depth as we'd have liked.
 
> Another problem with this section is that it only mentions reorganizations.
> But a fraudulent transfer can happen without a reorganization, as an
> attacker can produce an SPV proof which is totally fake. So this is not
> similar to double-spending, attacker doesn't need to own coins to perform
> an attack.
> 

Well, even in the absense of a reorganization, the attacker's false proof
will just be invalidated by a proof of longer work on the real chain.
And there is still a real cost to producing the false proof.


-- 
Andrew Poelstra
Mathematics Department, University of Texas at Austin
Email: apoelstra at wpsoftware.net
Web:   http://www.wpsoftware.net/andrew


[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

  parent reply	other threads:[~2014-11-03 18:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 21:54 Adam Back
2014-10-22 22:01 ` Daniel Murrell
2014-10-22 22:35   ` Bryan Bishop
2014-10-22 22:52     ` Daniel Murrell
2014-10-23  0:00       ` Jeff Garzik
2014-10-31 18:58 ` Melvin Carvalho
2014-11-03 12:12 ` Alex Mizrahi
2014-11-03 14:14   ` Jorge Timón
2014-11-03 16:01     ` Alex Mizrahi
2014-11-03 17:32       ` Jorge Timón
2014-11-03 17:54       ` Andrew Poelstra [this message]
2014-11-03 19:38         ` odinn

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=20141103175459.GT6400@shavo.vs.shawcable.net \
    --to=apoelstra@wpsoftware$(echo .)net \
    --cc=alex.mizrahi@gmail$(echo .)com \
    --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