Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 215E7412 for ; Thu, 15 Oct 2015 15:10:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8A72C1E1 for ; Thu, 15 Oct 2015 15:10:12 +0000 (UTC) Received: by obbda8 with SMTP id da8so67644131obb.1 for ; Thu, 15 Oct 2015 08:10:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=WpFItliP7Is2sj4jrrg+fi8A7DYeCI694UdNXaMWJpE=; b=X5ece6wuf+hDm77hp1GYoKRXZSWII0zdPfisVhyUgfEnIsr5avDLOUDM5y+tQTYv4y sDB9vk7ZCyjyiPhewmxA4nKGIeJOv/ynGWH9japphx+3M66oZNAP4U7DR9qPwHo+z5oW UeEt7k/gHNEH5jrKAbvWyQUtv/MGaIRg6KnzXWJ53P7osMvUJfZFtjBn8rN4+GC9sWRH wz+JHJNCTcnJx8yILibIwKZ24TeW+toAq/fMUx0nv751rtjCr9ddEbKleB3VvFw7fpLa UMhoyuj36/YCJoyH60ZXu16sc2lx/RvyST1sgJ9qiYwZYdgvD9sXecuTLRqFbfvy1HAD BenA== X-Received: by 10.60.124.226 with SMTP id ml2mr5290209oeb.27.1444921811953; Thu, 15 Oct 2015 08:10:11 -0700 (PDT) MIME-Version: 1.0 Sender: stanga@gmail.com Received: by 10.182.104.164 with HTTP; Thu, 15 Oct 2015 08:09:52 -0700 (PDT) In-Reply-To: <28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com> References: <28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com> From: Ittay Date: Thu, 15 Oct 2015 11:09:52 -0400 X-Google-Sender-Auth: fNQbPuisxGKXkVVrq2u1P2jKAy0 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary=047d7b414eee546dcc0522261347 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Ittay , Ittay via bitcoin-dev Subject: Re: [bitcoin-dev] Bitcoin-NG whitepaper. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 15:10:14 -0000 --047d7b414eee546dcc0522261347 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Matt. Response inline. On Wed, Oct 14, 2015 at 2:57 PM, Matt Corallo 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 th= e > 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 en= d > 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 whic= h > 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 co= st > - 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 wrote: >> >>> On Wed, Oct 14, 2015 at 1:02 PM, Emin G=C3=BCn Sirer >>> 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 >> >> --047d7b414eee546dcc0522261347 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Matt. Response inline.=C2=A0

On Wed, Oct 14, 2015 at 2:57 PM, Ma= tt Corallo <lf-lists@mattcorallo.com> wrote:
That conversation missed a second issue. Nam= ely that there is no way to punish people if there is a double spend in a m= icro block that happens in key block which reorg'd away the first trans= action. eg one miner mines a transaction in a micro block, another miner (e= ither by not having seen the first yet, or being malicious - potentially th= e 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 con= firmation times :(.

If NG is to b= e used efficiently, microblocks are going to be very frequent, and so such = forks should occur at almost every key-block publication. Short reorgs as y= ou described are the norm. A user should wait before accepting a transactio= n to make sure there was no key-block she missed. The wait time is chosen a= ccording 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 mis= sed.=C2=A0

As for the malicious case: the attacker= has to win the key-block, have the to-be-inverted transaction in the previ= ous 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 indistingu= ishable from benign behavior.=C2=A0
=C2=A0
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 wi= th separate rewards and pubkeys, but now the user can commit fraud at a muc= h 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.=C2=A0
Do you perceive th= is as a significant practical issue?=C2=A0
=C2=A0

On Octob= er 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.org> wrote:

= On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop <kanzure@gmail.com> wrote:
On Wed, Oct 14, 2015 a= t 1:02 PM, Emin G=C3=BCn Sirer
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> while the whitepaper has all the nitty gritty details:
>=C2=A0 =C2=A0 =C2=A0 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 discus= sion.=C2=A0

Best,=C2=A0
Ittay=C2=A0

bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfou= ndation.org/mailman/listinfo/bitcoin-dev

<= /div>

--047d7b414eee546dcc0522261347--