path: root/3a/4cacf2727d682be8b6992cff55b0ca74863462

Return-Path: <vincent.truong@procabiak.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A2935EB6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Sep 2015 22:21:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
	[209.85.213.169])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8EE32147
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Sep 2015 22:21:34 +0000 (UTC)
Received: by igbkq10 with SMTP id kq10so52112445igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 11 Sep 2015 15:21:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=procabiak.com; s=procabiakindustries;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=dH3DcEq1aPb2DfCSD02D9gThuhMaVKBeAHsVOw3K0Dw=;
	b=UTat1nh6q0FqfNSMR5PCYeEYQfFrOQQ7Vrk8n9p9BOZsybJIjGUFtw/8WkIOhujJPM
	uVMUyRF7g9e5800voss80IrIx8QCrjVZrca/Nj/u1NPoh+acKR7Iw7fpz0bcvFe+MCBo
	JRV2w19yWTFJr/bns18Q74l0J64QMT3NDdsMY=
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=dH3DcEq1aPb2DfCSD02D9gThuhMaVKBeAHsVOw3K0Dw=;
	b=bFfLLq7ZnQybMHcuOLTt3W5IgiXLCtAKTnVvqWQjjTl/FBD4Js76A2NXAx/a/evWTF
	K9b4IVQxE0gAgn8/sEA6KL5pPGJ8AnLOS/OjTfq1c0cqqO4Uo8Ox64oPLIWFgONOa/Jx
	N0IgG3w1ZbzH6A2bf0FXXgGMQiEiYqxQrN8JdycDq1BMEfH/LDGmw6eMkildrT5OFSfQ
	Ky85nQ6szFxHSs13EYwvVPFPs22gyZQ5st/+ABpUtp7Eq5ImzM1fU+h3dhjAsPv50gJK
	UAvNb88Z7Evk5t9FNcxS/kt865grG9x9jWt1We6ehhjGStOOalY14mUBetElBA4o5fG1
	JQtg==
X-Gm-Message-State: ALoCoQnyI9ZsMAnlRE72UjOcHeIQBN5aFlrfCogZdozYbwyQ0iZCY7ckAZPAS1zUmPoXvQtQUsDF
MIME-Version: 1.0
X-Received: by 10.50.142.1 with SMTP id rs1mr738783igb.17.1442010093776; Fri,
	11 Sep 2015 15:21:33 -0700 (PDT)
Received: by 10.36.68.213 with HTTP; Fri, 11 Sep 2015 15:21:33 -0700 (PDT)
X-Originating-IP: [14.202.127.219]
Received: by 10.36.68.213 with HTTP; Fri, 11 Sep 2015 15:21:33 -0700 (PDT)
In-Reply-To: <CAGLBAhdjTYEXZWRU6gouLgUjerWF3i_L4Sj5QrAcfwmFfEgDAw@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>
	<CAGLBAhdjTYEXZWRU6gouLgUjerWF3i_L4Sj5QrAcfwmFfEgDAw@mail.gmail.com>
Date: Sat, 12 Sep 2015 08:21:33 +1000
Message-ID: <CACrzPe=kDVJHDMgyuFvVcPf1FbfzLbDYFKxzaxtdWnvkJ=HpLQ@mail.gmail.com>
From: Vincent Truong <vincent.truong@procabiak.com>
To: Dave Scotese <dscotese@litmocracy.com>
Content-Type: multipart/alternative; boundary=001a1130c3566711ff051f802329
X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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@lists.linuxfoundation.org
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2015 22:21:35 -0000

--001a1130c3566711ff051f802329
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Would this alter the way txns will be prioritised in order to try to win?
You would always pick txns with the best BTCDD to maximize your chances of
being the block to build on.

I see this as potentially being a bad outcome for bitcoin's fungibility.
On Sep 12, 2015 5:26 AM, "Dave Scotese via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Yes, this proposal is a policy that everyone would be free to ignore.  I
> should have introduced the situation in which this *unenforceable* policy
> makes sense to me.  Here it is:
>
> Every miner is listening for valid block solutions but might receive two
> valid blocks and then they have to decide which one to use.  Choosing the
> one you saw first is the default behavior.  In that situation, we'd all
> like everyone to choose the same block.  I propose that a better heuristi=
c
> than "first seen" is to compare the BTCDD, *but only of transactions you
> already have in your mempool*, and
>
> *weight the BTCDD so that txns you got earlier are more important.*
> The heuristic is most useful when the two blocks are received within a
> small window of time, opting for the first-seen rule otherwise.  I assume
> many miners have an idea of how long it takes for anyone's new block to g=
et
> across the network, and more specifically, the range of times it takes fo=
r
> new solutions to get to themselves.  During this little time window, the
> chances are 50/50 that they'll choose the right block.  If the default
> behavior were to use BTCDD during that time window (one second? I have no
> idea!), then the chances would be significantly better.
>
> I think Jorge is right that it doesn't benefit miners.  It doesn't hurt
> them either, unless they are trying to do selfish mining.  Well, it
> benefits them in terms of increased bitcoin stability by A) making it
> easier for clients to decide which block is valid when they see two
> competing with each other, B) motivating miners to add transactions inste=
ad
> of mining empty blocks, C) severely decreasing the utility of any global
> private network of nodes intended to spread selfishly-mined blocks, and D=
)
> motivating miners to stay well-connected so that they get transactions
> quickly.
>
> I sent this to the list because it is only useful if it is set as default
> behavior since most miners leave the defaults alone, and the benefits don=
't
> materialize unless a majority follows the policy.
>
> On Fri, Sep 11, 2015 at 11:37 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>
>>
>> On Sep 11, 2015 1:18 PM, "Christophe Biocca" <christophe.biocca@gmail.co=
m>
>> 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 th=
e
>> "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 wit=
h
>> 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 val=
id
>> > > blocks) on top of it.
>> > >
>> > >
>> > > _______________________________________________
>> > > bitcoin-dev mailing list
>> > > bitcoin-dev@lists.linuxfoundation.org
>> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> > >
>>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
> which now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a1130c3566711ff051f802329
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Would this alter the way txns will be prioritised in order t=
o try to win? You would always pick txns with the best BTCDD to maximize yo=
ur chances of being the block to build on.</p>
<p dir=3D"ltr">I see this as potentially being a bad outcome for bitcoin&#3=
9;s fungibility.</p>
<div class=3D"gmail_quote">On Sep 12, 2015 5:26 AM, &quot;Dave Scotese via =
bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.o=
rg">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br type=3D"attribu=
tion"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div>Y=
es, this proposal is a policy that everyone would be free to ignore.=C2=A0 =
I should have introduced the situation in which this <i>unenforceable</i> p=
olicy makes sense to me.=C2=A0 Here it is:<br><br></div>Every miner is list=
ening for valid block solutions but might receive two valid blocks and then=
 they have to decide which one to use.=C2=A0 Choosing the one you saw first=
 is the default behavior.=C2=A0 In that situation, we&#39;d all like everyo=
ne to choose the same block.=C2=A0 I propose that a better heuristic than &=
quot;first seen&quot; is to compare the BTCDD, <i>but only of transactions =
you already have in your mempool</i>, and <i>weight the BTCDD so that txns =
you got earlier are more important.<br><br></i></div>The heuristic is most =
useful when the two blocks are received within a small window of time, opti=
ng for the first-seen rule otherwise.=C2=A0 I assume many miners have an id=
ea of how long it takes for anyone&#39;s new block to get across the networ=
k, and more specifically, the range of times it takes for new solutions to =
get to themselves.=C2=A0 During this little time window, the chances are 50=
/50 that they&#39;ll choose the right block.=C2=A0 If the default behavior =
were to use BTCDD during that time window (one second? I have no idea!), th=
en the chances would be significantly better.<br><br></div>I think Jorge is=
 right that it doesn&#39;t benefit miners.=C2=A0 It doesn&#39;t hurt them e=
ither, unless they are trying to do selfish mining.=C2=A0 Well, it benefits=
 them in terms of increased bitcoin stability by A) making it easier for cl=
ients to decide which block is valid when they see two competing with each =
other, B) motivating miners to add transactions instead of mining empty blo=
cks, C) severely decreasing the utility of any global private network of no=
des intended to spread selfishly-mined blocks, and D) motivating miners to =
stay well-connected so that they get transactions quickly.<br></div><div><b=
r></div><div>I sent this to the list because it is only useful if it is set=
 as default behavior since most miners leave the defaults alone, and the be=
nefits don&#39;t materialize unless a majority follows the policy.<br></div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Se=
p 11, 2015 at 11:37 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span><p dir=3D"ltr"><br>
On Sep 11, 2015 1:18 PM, &quot;Christophe Biocca&quot; &lt;<a href=3D"mailt=
o:christophe.biocca@gmail.com" target=3D"_blank">christophe.biocca@gmail.co=
m</a>&gt; wrote:<br>
&gt;<br>
&gt; It&#39;s pretty obvious that Dave is suggesting an alternate tie-break=
er:</p>
</span><p dir=3D"ltr">I thought he was proposing a new consesnsus rule. I s=
ee, this would be just a policy validation that everybody would be free to =
ignore (like the &quot;first seen&quot; spend conflict tx replacement polic=
y).</p>
<p dir=3D"ltr">I don&#39;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 &quot;=
first seen&quot; spend conflict tx replacement policy).<br>
If miners don&#39;t use it, I don&#39;t see how users can benefit from runn=
ing that policy themselves.<br>
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).</p><span>
<p dir=3D"ltr">&gt; Mind you, that risk doesn&#39;t apply if we prefer non-=
empty blocks to<br>
&gt; empty blocks and leave it at that, or only switch if the new block<br>
&gt; doesn&#39;t double spend transactions in the old one, so it&#39;s a fi=
xable<br>
&gt; issue.</p>
</span><p dir=3D"ltr">How do you know which of 2 blocks with the same heigh=
t is &quot;newer&quot;?</p><div><div>
<p dir=3D"ltr">&gt; On 11 September 2015 at 12:32, Jorge Tim=C3=B3n<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; On Sep 11, 2015 12:27 PM, &quot;Dave Scotese via bitcoin-dev&quot=
;<br>
&gt; &gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Rather than (promising to, and when they don&#39;t actually, =
at least<br>
&gt; &gt;&gt; pretending to) use the first-seen block, I propose that a mor=
e sophisticated<br>
&gt; &gt;&gt; method of choosing which of two block solutions to accept.<br=
>
&gt; &gt;<br>
&gt; &gt; There&#39;s already a criterion to chose: the one with more work =
(in valid<br>
&gt; &gt; blocks) on top of it.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" target=3D"_blank">https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev</a><br>
&gt; &gt;<br>
</p>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div d=
ir=3D"ltr">I like to provide some work at no charge to prove my value. Do y=
ou need a techie?=C2=A0 <br>I own <a href=3D"http://www.litmocracy.com" tar=
get=3D"_blank">Litmocracy</a> and <a href=3D"http://www.memeracing.net" tar=
get=3D"_blank">Meme Racing</a> (in alpha). <br>I&#39;m the webmaster for <a=
 href=3D"http://www.voluntaryist.com" target=3D"_blank">The Voluntaryist</a=
> which now accepts Bitcoin.<br>I also code for <a href=3D"http://dollarvig=
ilante.com/" target=3D"_blank">The Dollar Vigilante</a>.<br>&quot;He ought =
to find it more profitable to play by the rules&quot; - Satoshi Nakamoto</d=
iv></div>
</div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div>

--001a1130c3566711ff051f802329--