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

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: Thu, 15 Oct 2015 11:09:52 -0400	[thread overview]
Message-ID: <CABT1wWm0QXjGAXgrBMT7w+25kcsEJnP8JZ5RSpuk3aefX45+wQ@mail.gmail.com> (raw)
In-Reply-To: <28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com>

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

Thanks, Matt. Response inline.

On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo <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.

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.

> Also, Greg Slepak brought up a good point on twitter at
> https://twitter.com/taoeffect/status/654358023138209792. Noting that this
> model means users could no longer pick transactions in a mining pool which
> was set up in such a way (it could be tweaked to do so with separate
> rewards and pubkeys, but now the user can commit fraud at a much lower cost
> - their own pool reward, not the block's total reward).
>

Agreed x3: This is a good point, it is correct, and the tweak is dangerous.
Do you perceive this as a significant practical issue?

>
> On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>>
>> On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail•com> wrote:
>>
>>> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün Sirer
>>> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> > while the whitepaper has all the nitty gritty details:
>>> >      http://arxiv.org/abs/1510.02037
>>>
>>> Taking reward compensation back by fraud proofs is not enough to fix
>>> the problems associated with double spending (such as, everyone has to
>>> wait for the "real" confirmations instead of the "possibly
>>> double-spend" confirmations). Some of this was discussed in -wizards
>>> recently:
>>> http://gnusha.org/bitcoin-wizards/2015-09-19.log
>>
>>
>> Fraud proof removes all the attacker's revenue. It's like the attacker
>> sacrifices an entire block for double spending in the current system. I
>> think Luke-Jr got it right at that discussion.
>>
>> Best,
>> Ittay
>>
>> ------------------------------
>>
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>

[-- Attachment #2: Type: text/html, Size: 5315 bytes --]