From: Ittay <ittay.eyal@cornell•edu>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Ittay <ittay.eyal@cornell•edu>,
Ittay via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin-NG whitepaper.
Date: Fri, 6 Nov 2015 15:48:08 -0500 [thread overview]
Message-ID: <CABT1wWndkSNK5FDbaiYoFZhhBu9FxXhy9qkb_pA7KW6Xqq1nfg@mail.gmail.com> (raw)
In-Reply-To: <56302E34.7070906@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 3671 bytes --]
On Tue, Oct 27, 2015 at 10:08 PM, Matt Corallo <lf-lists@mattcorallo•com>
wrote:
> Oops, just realized I never responded to this...
>
> On 10/15/15 15:09, Ittay wrote:
> > Thanks, Matt. Response inline.
> >
> > On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <lf-lists@mattcorallo•com
> > <mailto:lf-lists@mattcorallo•com>> wrote:
> >
> > That conversation missed a second issue. Namely that there is no way
> > to punish people if there is a double spend in a micro block that
> > happens in key block which reorg'd away the first transaction. eg
> > one miner mines a transaction in a micro block, another miner
> > (either by not having seen the first yet, or being malicious -
> > potentially the same miner) mines a key block which reorgs away the
> > first micro block and then, in their first micro block, mines a
> > double spend. This can happen at any time, so you end up having to
> > fall back to regular full blocks for confirmation times :(.
> >
> >
> > If NG is to be used efficiently, microblocks are going to be very
> > frequent, and so such forks should occur at almost every key-block
> > publication. Short reorgs as you described are the norm. A user should
> > wait before accepting a transaction to make sure there was no key-block
> > she missed. The wait time is chosen according to the network propagation
> > delay (+as much slack as the user feels necessary). This is similar to
> > the situation in Bitcoin when you receive a block. To be confident that
> > you have one confirmation you should wait for the propagation time of
> > the network to make sure there is no branch you missed.
>
> I think you're overstating how short the wait times can be. They need to
> be much longer than the network propagation delay.
>
> > As for the malicious case: the attacker has to win the key-block, have
> > the to-be-inverted transaction in the previous epoch, and withhold his
> > key-block for a while. That being said, indeed our fraud proof scheme
> > doesn't catch such an event, as it is indistinguishable from benign
> > behavior.
>
> The attacker does not need to withold their keyblock at all. All the
> attacker does is, for every transaction they ever send, after it is
> included in a microblock, set their hashpower to start mining a keyblock
> immediately prior to this microblock. When they find a keyblock, they
> immediately announce it and start creating microblocks, the first of
> which double-spends the previous transaction. If they dont win the key
> block, oh well, their payment went through normally and they couldn't
> double-spend.
>
> In chatting with Glenn about this, we roughly agreed that the
> confirmation time for microblocks possibly doesn't need to be a full
> key-block, but it needs to be a reasonable period after which such an
> attacker would lose more in fees than the value of their double-spend
> (ie because the key-block afterwards gets 20% more in fees than the
> key-block before hand). In any case, the game theory here starts to get
> rather complicated and it doesn't make me want to suggest accepting
> microblocks as confirmations is safe.
>
Yes, an attacker can continuously try to do this, losing all (and only)
fees.
They will succeed every time they mine a block after the to-be-double-spent
transaction is placed by the current leader. So a microblock + delay is
stronger
than a zero-confirmation transaction, but not as strong as a first-block
confirmation.
A game theory analysis is indeed difficult here, mainly since the
assumptions
are not entirely clear. We are working towards this, starting with
formalizing
the attacker's incentive structure.
[-- Attachment #2: Type: text/html, Size: 5121 bytes --]
next prev parent reply other threads:[~2015-11-06 20:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 18:02 Emin Gün Sirer
2015-10-14 18:12 ` Bryan Bishop
2015-10-14 18:28 ` Ittay
2015-10-14 18:57 ` Matt Corallo
2015-10-15 15:09 ` Ittay
2015-10-28 2:08 ` Matt Corallo
2015-11-06 20:48 ` Ittay [this message]
2015-10-14 18:14 ` Sergio Demian Lerner
[not found] ` <20151014182055.GC23875@mcelrath.org>
2015-10-14 18:38 ` Ittay
2015-10-14 18:39 ` Emin Gün Sirer
2015-10-14 22:21 ` odinn
2015-10-15 1:59 ` Matt Corallo
2015-10-15 8:48 ` odinn
2015-10-15 15:12 ` Ittay
2015-10-15 18:43 ` odinn
2015-10-14 20:52 ` Bob McElrath
2015-11-09 18:33 ` Emin Gün Sirer
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=CABT1wWndkSNK5FDbaiYoFZhhBu9FxXhy9qkb_pA7KW6Xqq1nfg@mail.gmail.com \
--to=ittay.eyal@cornell$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/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