From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5A036F93 for ; Fri, 11 Sep 2015 19:06:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B69C1F1 for ; Fri, 11 Sep 2015 19:06:44 +0000 (UTC) Received: by iofb144 with SMTP id b144so109339874iof.1 for ; Fri, 11 Sep 2015 12:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Y5c6E1UEirsXckY8nDIkLJqN46gqfLQ+3bDYAQL3lGI=; b=Na2g//vBZFdyssAqUjGlRjbg8hf8KOfa7wz4Wdf0UZ8f7LMlNRZE7pTQi4hjkMOgsR lb9WnAuVs/fn0W8AUstcC3EENq4AJyasfEOrh1BVZiTKTIsfS6ByJ7EoLODRu3lTcqYt RsjQXXpBjhPPTxO4Vmt9SohOvKSZEL6fF+Gg0X9xccb5R4jil0XNTiTSHF7YHOV+HpSR widdQXLRdwAg4zd0w9wdutBR3/eelI6ZZaYVephb66U+PwnXEn07YwBEgo3Y4uV/1a2u jE9ZZMnRVyxOh8gb7XJTZ6pxwAp11DhkIHFPY/YT/UPLbBpyfdiUAZqAwopbdPwLzmRf lfow== MIME-Version: 1.0 X-Received: by 10.107.156.14 with SMTP id f14mr6461641ioe.32.1441998403670; Fri, 11 Sep 2015 12:06:43 -0700 (PDT) Received: by 10.36.110.19 with HTTP; Fri, 11 Sep 2015 12:06:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Sep 2015 15:06:43 -0400 Message-ID: From: Christophe Biocca To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no 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 19:06:45 -0000 > How do you know which of 2 blocks with the same height is "newer"? >From the particular node's perspective. I'm aware there is no possibility of consistent global ordering. Dave's code is about switching blocks (instead of continuing on the existing one), and, in that context, "old" means the first sibling the node saw, and "new" is any subsequent block. I will disambiguate this in the future, because I'm clearly confusing at least 1 person. > 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 conf= lict tx replacement policy). There's always a default, and if miners don't have any overriding reason to change, they'll likely stick to it. Which is why Dave started his statement with: > Rather than (promising to, and when they don't actually, at least pretend= ing to) use the first-seen block Clearly recognizing that any changed logic is non-binding. On 11 September 2015 at 14:37, Jorge Tim=C3=B3n wrote: > > 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 ju= st > a policy validation that everybody would be free to ignore (like the "fir= st > 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 confli= ct > tx replacement policy). > If miners don't use it, I don't see how users can benefit from running th= at > 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 >> >