From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsClq-0000qo-MX for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 16:11:02 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.43 as permitted sender) client-ip=209.85.215.43; envelope-from=gavinandresen@gmail.com; helo=mail-la0-f43.google.com; Received: from mail-la0-f43.google.com ([209.85.215.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsClo-0002C7-Dm for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 16:11:02 +0000 Received: by lagv1 with SMTP id v1so9660477lag.3 for ; Tue, 12 May 2015 09:10:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.97.202 with SMTP id ec10mr2567898lbb.4.1431447054031; Tue, 12 May 2015 09:10:54 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Tue, 12 May 2015 09:10:53 -0700 (PDT) In-Reply-To: <555210AF.3090705@electrum.org> References: <5550D8BE.6070207@electrum.org> <5551F376.4050008@electrum.org> <555210AF.3090705@electrum.org> Date: Tue, 12 May 2015 12:10:53 -0400 Message-ID: From: Gavin Andresen To: Thomas Voegtlin , Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1133b1c42ba2790515e4bd2d X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YsClo-0002C7-Dm 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:11:02 -0000 --001a1133b1c42ba2790515e4bd2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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. > --=20 -- Gavin Andresen --001a1133b1c42ba2790515e4bd2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Added back the list, I didn't mean to reply priva= tely:

Fair enough, I'll try to find time in the nex= t 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 securi= ty via alternative consensus algorithm (in this scenario there is very litt= le mining).
4) Fee supported with small blocks containing high-fe= e transactions moving coins to/from sidechains.

Wo= uld 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 hap= pen?

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


On Tue, May 12, 2015 at 10:39 AM, Th= omas 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.<= br> >

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

Yes, that's exactly the kind of roadmap I am asking for. But your blog<= br> 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
--001a1133b1c42ba2790515e4bd2d--