MIME-Version: 1.0
In-Reply-To: <CABm2gDoCecK1jk6i_bZMTRCTQUseXYugi5ntykMimzns_dxFug@mail.gmail.com>
References: <CAGLBAhd11-_LNJ-ba6NXmWBXz=yb+pFTmf9tHAgFW_m6S5jnfw@mail.gmail.com>
	<CABm2gDpsJdSDTyvTGNSZXX1+UyAHxTB=ODuy6bJvMj3A9BqhqQ@mail.gmail.com>
	<CANOOu=8jT++mX_pTHrEnryJqiw3C+J3mWKL27dEkQh=rO0q_Cg@mail.gmail.com>
	<CABm2gDoCecK1jk6i_bZMTRCTQUseXYugi5ntykMimzns_dxFug@mail.gmail.com>
Date: Fri, 11 Sep 2015 15:06:43 -0400
Message-ID: <CANOOu=_fX6buYhLz0hB0Swzu8MpgMx6UudFZfF4sJ_Cd4SVo5A@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin Days Destroyed as block selection
	heuristic
Precedence: list

> 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 <jtimon@jtimon.cc> wrote:
>
> 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-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
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >
>> > On Sep 11, 2015 12:27 PM, "Dave Scotese via bitcoin-dev"
>> > <bitcoin-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 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
>> >