Re: [bitcoin-dev] Bitcoin-NG whitepaper.

[Ittay <ittay.eyal@cornell.edu>]

[-- 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 --]