path: root/d5/573caeb3e4ad708d40cf352c0bcfb0ad23efa5

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <dave@hashingit.com>) id 1YsCwJ-0002Yo-4w
	for bitcoin-development@lists.sourceforge.net;
	Tue, 12 May 2015 16:21:51 +0000
Received-SPF: softfail (sog-mx-3.v43.ch3.sourceforge.com: transitioning domain
	of hashingit.com does not designate 89.145.69.228 as permitted
	sender) client-ip=89.145.69.228;
	envelope-from=dave@hashingit.com; helo=heron.directrouter.co.uk;
Received: from heron.directrouter.co.uk ([89.145.69.228])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.76) id 1YsCwG-0002u0-WA
	for bitcoin-development@lists.sourceforge.net;
	Tue, 12 May 2015 16:21:51 +0000
Received: from host81-151-120-191.range81-151.btcentralplus.com
	([81.151.120.191]:54556 helo=[192.168.1.82])
	by heron.directrouter.co.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256)
	(Exim 4.85) (envelope-from <dave@hashingit.com>)
	id 1YsCw9-001UVv-IK; Tue, 12 May 2015 16:21:41 +0000
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_8BC3E943-08E7-4C35-9E50-5C3F5143F7E8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Dave Hudson <dave@hashingit.com>
In-Reply-To: <CABsx9T3AxM3et7hgXx3+Rn3BvhQkF-Cn797sHcyztkMpD1UQmA@mail.gmail.com>
Date: Tue, 12 May 2015 17:21:40 +0100
Message-Id: <6D03480C-C9B9-4CCC-938B-151AC0DD57F0@hashingit.com>
References: <5550D8BE.6070207@electrum.org>
	<ce3d34c92efd1cf57326e4679550944e@national.shitposting.agency>
	<CABsx9T1VgxEJWxrYTs+2hXGnGrSLGJ6mVcAexjXLvK7Vu+e3EA@mail.gmail.com>
	<5551F376.4050008@electrum.org>
	<CABsx9T1h7p3hDr7ty43uxsYs-oNRpndzg=dowST2tXtogxRm2g@mail.gmail.com>
	<555210AF.3090705@electrum.org>
	<CABsx9T3AxM3et7hgXx3+Rn3BvhQkF-Cn797sHcyztkMpD1UQmA@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
X-Mailer: Apple Mail (2.2098)
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - heron.directrouter.co.uk
X-AntiAbuse: Original Domain - lists.sourceforge.net
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hashingit.com
X-Get-Message-Sender-Via: heron.directrouter.co.uk: authenticated_id:
	dave@hashingit.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1YsCwG-0002u0-WA
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Long-term mining incentives
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 16:21:51 -0000


--Apple-Mail=_8BC3E943-08E7-4C35-9E50-5C3F5143F7E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think proof-of-idle had a potentially serious problem when I last =
looked at it. The risk is that a largish miner can use everyone else's =
idle time to construct a very long chain; it's also easy enough for them =
to make it appear to be the work of a large number of distinct miners. =
Given that this would allow them to arbitrarily re-mine any block =
rewards and potentially censor any transactions then that just seems =
like a huge security hole?


Cheers,
Dave


> On 12 May 2015, at 17:10, Gavin Andresen <gavinandresen@gmail.com> =
wrote:
>=20
> Added back the list, I didn't mean to reply privately:
>=20
> Fair enough, I'll try to find time in the next month or three to write =
up four plausible future scenarios for how mining incentives might work:
>=20
> 1) Fee-supported with very large blocks containing lots of tiny-fee =
transactions
> 2) Proof-of-idle supported (I wish Tadge Dryja would publish his =
proof-of-idle idea....)
> 3) Fees purely as transaction-spam-prevention measure, chain security =
via alternative consensus algorithm (in this scenario there is very =
little mining).
> 4) Fee supported with small blocks containing high-fee transactions =
moving coins to/from sidechains.
>=20
> Would that be helpful, or do you have some reason for thinking that we =
should pick just one and focus all of our efforts on making that one =
scenario happen?
>=20
> I always think it is better, when possible, not to "bet on one horse."
>=20
>=20
> On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin =
<thomasv@electrum.org <mailto:thomasv@electrum.org>> wrote:
> Le 12/05/2015 15:44, Gavin Andresen a =C3=A9crit :
> > Ok, here's my scenario:
> >
> > https://blog.bitcoinfoundation.org/a-scalability-roadmap/ =
<https://blog.bitcoinfoundation.org/a-scalability-roadmap/>
> >
> > It might be wrong. I welcome other people to present their road =
maps.
> >
>=20
> [answering to you only because you answered to me and not to the list;
> feel free to repost this to the list though]
>=20
> Yes, that's exactly the kind of roadmap I am asking for. But your blog
> post does not say anything about long term mining incentives, it only
> talks about scalability. My point is that we need the same kind of =
thing
> for miners incentives.
>=20
>=20
>=20
> --=20
> --
> Gavin Andresen
> =
--------------------------------------------------------------------------=
----
> One dashboard for servers and applications across =
Physical-Virtual-Cloud=20
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable =
Insights
> Deep dive visibility with transaction tracing using APM Insight.
> =
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___________________=
____________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_8BC3E943-08E7-4C35-9E50-5C3F5143F7E8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><div class=3D"">I think proof-of-idle had a potentially =
serious problem when I last looked at it. The risk is that a largish =
miner can use everyone else's idle time to construct a very long chain; =
it's also easy enough for them to make it appear to be the work of a =
large number of distinct miners. Given that this would allow them to =
arbitrarily re-mine any block rewards and potentially censor any =
transactions then that just seems like a huge security hole?</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">Cheers,</div><div class=3D"">Dave</div><div class=3D""><br =
class=3D""></div><br class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">On 12 May 2015, at 17:10, Gavin Andresen =
&lt;<a href=3D"mailto:gavinandresen@gmail.com" =
class=3D"">gavinandresen@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"">Added back the list, I didn't mean to reply =
privately:</div><div class=3D""><br class=3D""></div>Fair enough, I'll =
try to find time in the next month or three to write up four plausible =
future scenarios for how mining incentives might work:<div class=3D""><br =
class=3D""></div><div class=3D"">1) Fee-supported with very large blocks =
containing lots of tiny-fee transactions</div><div class=3D"">2) =
Proof-of-idle supported (I wish Tadge Dryja would publish his =
proof-of-idle idea....)</div><div class=3D"">3) Fees purely as =
transaction-spam-prevention measure, chain security via alternative =
consensus algorithm (in this scenario there is very little =
mining).</div><div class=3D"">4) Fee supported with small blocks =
containing high-fee transactions moving coins to/from =
sidechains.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Would that be helpful, or do you have some reason for =
thinking that we should pick just one and focus all of our efforts on =
making that one scenario happen?</div><div class=3D""><br =
class=3D""></div><div class=3D"">I always think it is better, when =
possible, not to "bet on one horse."</div><div class=3D""><br =
class=3D""></div><div class=3D"gmail_extra"><br class=3D""><div =
class=3D"gmail_quote">On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin =
<span dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:thomasv@electrum.org" =
target=3D"_blank" class=3D"">thomasv@electrum.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">Le =
12/05/2015 15:44, Gavin Andresen a =C3=A9crit :<br class=3D"">
&gt; Ok, here's my scenario:<br class=3D"">
&gt;<br class=3D"">
&gt; <a href=3D"https://blog.bitcoinfoundation.org/a-scalability-roadmap/"=
 target=3D"_blank" =
class=3D"">https://blog.bitcoinfoundation.org/a-scalability-roadmap/</a><b=
r class=3D"">
&gt;<br class=3D"">
&gt; It might be wrong. I welcome other people to present their road =
maps.<br class=3D"">
&gt;<br class=3D"">
<br class=3D"">
</span>[answering to you only because you answered to me and not to the =
list;<br class=3D"">
feel free to repost this to the list though]<br class=3D"">
<br class=3D"">
Yes, that's exactly the kind of roadmap I am asking for. But your =
blog<br class=3D"">
post does not say anything about long term mining incentives, it only<br =
class=3D"">
talks about scalability. My point is that we need the same kind of =
thing<br class=3D"">
for miners incentives.<br class=3D"">
</blockquote></div><br class=3D""><br clear=3D"all" class=3D""><div =
class=3D""><br class=3D""></div>-- <br class=3D""><div =
class=3D"gmail_signature">--<br class=3D"">Gavin Andresen<br =
class=3D""></div>
</div></div>
=
--------------------------------------------------------------------------=
----<br class=3D"">One dashboard for servers and applications across =
Physical-Virtual-Cloud <br class=3D"">Widest out-of-the-box monitoring =
support with 50+ applications<br class=3D"">Performance metrics, stats =
and reports that give you Actionable Insights<br class=3D"">Deep dive =
visibility with transaction tracing using APM Insight.<br class=3D""><a =
href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___________=
____________________________________" =
class=3D"">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y________=
_______________________________________</a><br =
class=3D"">Bitcoin-development mailing list<br =
class=3D"">Bitcoin-development@lists.sourceforge.net<br =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t<br class=3D""></div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_8BC3E943-08E7-4C35-9E50-5C3F5143F7E8--