Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5D3D69B for ; Wed, 14 Oct 2015 18:57:13 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9219490 for ; Wed, 14 Oct 2015 18:57:12 +0000 (UTC) Received: from [IPv6:2607:fb90:211c:96f5:60f0:e645:d51e:beb7] (unknown [172.56.31.102]) by mail.bluematt.me (Postfix) with ESMTPSA id A1B6859028; Wed, 14 Oct 2015 18:57:10 +0000 (UTC) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YMPFIUJBG0EG12QR5WNRD59SW98WRT" Content-Transfer-Encoding: 8bit From: Matt Corallo Date: Wed, 14 Oct 2015 18:57:08 +0000 To: Ittay , Ittay via bitcoin-dev , Bryan Bishop Message-ID: <28CC699B-4DA8-4472-A795-9505418C688A@mattcorallo.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev , Ittay Eyal 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: Wed, 14 Oct 2015 18:57:13 -0000 ------YMPFIUJBG0EG12QR5WNRD59SW98WRT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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 :(. 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). On October 14, 2015 11:28:51 AM PDT, Ittay via bitcoin-dev wrote: >On Wed, Oct 14, 2015 at 2:12 PM, Bryan Bishop >wrote: > >> On Wed, Oct 14, 2015 at 1:02 PM, Emin Gün 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 ------YMPFIUJBG0EG12QR5WNRD59SW98WRT Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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 :(.

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).

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
------YMPFIUJBG0EG12QR5WNRD59SW98WRT--