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 ) 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 ) 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 In-Reply-To: Date: Tue, 12 May 2015 17:21:40 +0100 Message-Id: <6D03480C-C9B9-4CCC-938B-151AC0DD57F0@hashingit.com> References: <5550D8BE.6070207@electrum.org> <5551F376.4050008@electrum.org> <555210AF.3090705@electrum.org> To: Gavin Andresen 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 = > wrote: > Le 12/05/2015 15:44, Gavin Andresen a =C3=A9crit : > > Ok, here's my scenario: > > > > 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
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:

Added back the list, I didn't mean to reply = privately:

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:

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.

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?

I always think it is better, when = possible, not to "bet on one horse."


On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin = <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/ >
> It might be wrong. I welcome other people to present their road = maps.
>

[answering to you only because you answered to me and not to the = list;
feel free to repost this to the list though]

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.



--
--
Gavin Andresen
= --------------------------------------------------------------------------= ----
One dashboard for servers and applications across = Physical-Virtual-Cloud
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-developmen= t

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