From mboxrd@z Thu Jan 1 00:00:00 1970 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 = <<a href=3D"mailto:gavinandresen@gmail.com" = class=3D"">gavinandresen@gmail.com</a>> 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""><<a href=3D"mailto:thomasv@electrum.org" = target=3D"_blank" class=3D"">thomasv@electrum.org</a>></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""> > Ok, here's my scenario:<br class=3D""> ><br class=3D""> > <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""> ><br class=3D""> > It might be wrong. I welcome other people to present their road = maps.<br class=3D""> ><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--