Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E5797110F for ; Fri, 11 Sep 2015 18:37:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 272B019F for ; Fri, 11 Sep 2015 18:37:36 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so67806210wic.0 for ; Fri, 11 Sep 2015 11:37:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eB7pji2mb/0IjYmLV8cwcYLyjOScqrXKG1prjLBoLH0=; b=KlmFqhyHW6Y80KcDbtlLKKyyS4SdaDM/YDUKWl6xD2ZviIwz/p8oiS/LVQpLLnqHjR cLveZk+6NUiWCIh2bILcSNMOiYS44w5o6rzEgIOiyiYm3jNg4xtw8XGEV+Rh5A9oV66a JyyFiYRFTH/oz4J6tPg+OI9gsWpyjLvZfSuzyW4pKb6dZJY0BSc7Q7hduRZStzlHslnf 8C7t4IB6O9FOIc8eeo7GfeEGSksaxkMQOgKcGQjm8uYaVmZIC4rCn6h6T5/1Uyy+slfQ Xc23Mqu3T/Q5wuV5SNduI+LGJYuoscHNkt0fR8kR+BwUe201Tbgz9G9iSR4Rl6SvZgs1 hexw== X-Gm-Message-State: ALoCoQl5QH5e4Npzt5XBjG7XmjEkxcLW2mTXXw6NQkrIomMM1yqxF4wsLaQhO+lSKaYQazq7BFhK MIME-Version: 1.0 X-Received: by 10.180.103.72 with SMTP id fu8mr8989630wib.7.1441996654475; Fri, 11 Sep 2015 11:37:34 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Fri, 11 Sep 2015 11:37:34 -0700 (PDT) Received: by 10.194.37.5 with HTTP; Fri, 11 Sep 2015 11:37:34 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Sep 2015 20:37:34 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Christophe Biocca Content-Type: multipart/alternative; boundary=f46d0444e9e95b90eb051f7d026f X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Bitcoin Dev Subject: Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection heuristic 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: Fri, 11 Sep 2015 18:37:37 -0000 --f46d0444e9e95b90eb051f7d026f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sep 11, 2015 1:18 PM, "Christophe Biocca" wrote: > > It's pretty obvious that Dave is suggesting an alternate tie-breaker: I thought he was proposing a new consesnsus rule. I see, this would be just a policy validation that everybody would be free to ignore (like the "first seen" spend conflict tx replacement policy). I don't see how miners would benefit from running this policy so I would not expect them to run it in the long run (like the "first seen" spend conflict tx replacement policy). If miners don't use it, I don't see how users can benefit from running that policy themselves. They will still have to keep waiting some block confirmation to exponentially reduce the chances of a successful double-spend attack with each new confirmation (as explained in the bitcoin white paper). > Mind you, that risk doesn't apply if we prefer non-empty blocks to > empty blocks and leave it at that, or only switch if the new block > doesn't double spend transactions in the old one, so it's a fixable > issue. How do you know which of 2 blocks with the same height is "newer"? > On 11 September 2015 at 12:32, Jorge Tim=C3=B3n > wrote: > > > > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev" > > wrote: > >> > >> Rather than (promising to, and when they don't actually, at least > >> pretending to) use the first-seen block, I propose that a more sophisticated > >> method of choosing which of two block solutions to accept. > > > > There's already a criterion to chose: the one with more work (in valid > > blocks) on top of it. > > > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --f46d0444e9e95b90eb051f7d026f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.com> wrote: >
> It's pretty obvious that Dave is suggesting an alternate tie-break= er:

I thought he was proposing a new consesnsus rule. I see, thi= s would be just a policy validation that everybody would be free to ignore = (like the "first seen" spend conflict tx replacement policy).

I don't see how miners would benefit from running this p= olicy so I would not expect them to run it in the long run (like the "= first seen" spend conflict tx replacement policy).
If miners don't use it, I don't see how users can benefit from runn= ing that policy themselves.
They will still have to keep waiting some block confirmation to exponential= ly reduce the chances of a successful double-spend attack with each new con= firmation (as explained in the bitcoin white paper).

> Mind you, that risk doesn't apply if we prefer non-= empty blocks to
> empty blocks and leave it at that, or only switch if the new block
> doesn't double spend transactions in the old one, so it's a fi= xable
> issue.

How do you know which of 2 blocks with the same height is &q= uot;newer"?

> On 11 September 2015 at 12:32, Jorge Tim=C3=B3n
> <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
> >
> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"= ;
> > <bitc= oin-dev@lists.linuxfoundation.org> wrote:
> >>
> >> Rather than (promising to, and when they don't actually, = at least
> >> pretending to) use the first-seen block, I propose that a mor= e sophisticated
> >> method of choosing which of two block solutions to accept. > >
> > There's already a criterion to chose: the one with more work = (in valid
> > blocks) on top of it.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-= dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >

--f46d0444e9e95b90eb051f7d026f--