From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsI6p-0007uB-Vk for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 21:53:04 +0000 X-ACL-Warn: Received: from mail-lb0-f171.google.com ([209.85.217.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsI6o-0000AY-B7 for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 21:53:03 +0000 Received: by lbbuc2 with SMTP id uc2so16157743lbb.2 for ; Tue, 12 May 2015 14:52:55 -0700 (PDT) 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:from:date :message-id:subject:to:cc:content-type; bh=2IXRZjElp7FaP37O2L5RA+KNLgxpwtNbqQCr4iO/dAA=; b=m2uWRZo5DGtoQSHHUlv+yg+zKDDmIZF5Vt2KVIPc3SEBqZIyxyxG7isZS/VxP185Au TZewIVQWfX7jUno4Lcu0QwGFx/abCl3n8a/muOFpIsTP0KAFpty67SxIUX1xtKPtPz6F Y15ikF9ZlaGCWanQATB1mG7WeKptStUukaQah441S/kiSlHR2brtVsWrffMO2bSBkdj8 AY7bilKxke5SkQvX+BkdOwpnDYb2/POKb+xjUHt0AYlBNT6AK/FsQHINxbJx1d9HsXf+ 4XA1gahn1P6QduSgZztRWDtXj+M9n1m+UGMa6PvicJUmJRE85AQnM6Rdx7/9ZTkw51dS 4Q8Q== X-Gm-Message-State: ALoCoQllHl24umvis7omDsNj9AQpsWZ/nzPudqobWTKZULTv2feIZmehPrIhZBtwwmd9XCgfwfQD X-Received: by 10.152.88.80 with SMTP id be16mr13366557lab.39.1431465922516; Tue, 12 May 2015 14:25:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.125.161 with HTTP; Tue, 12 May 2015 14:24:41 -0700 (PDT) In-Reply-To: References: <5550D8BE.6070207@electrum.org> <5551F376.4050008@electrum.org> <555210AF.3090705@electrum.org> From: Pedro Worcel Date: Wed, 13 May 2015 09:24:41 +1200 Message-ID: To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a11c3564ed1ed4d0515e92172 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YsI6o-0000AY-B7 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 21:53:04 -0000 --001a11c3564ed1ed4d0515e92172 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Disclaimer: I don't know anything about Bitcoin. > =E2=80=8B2) 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). I don't understand why you would casually mention moving away from Proof of Work, I thought that was the big breakthrough that made Bitcoin possible at all? Thanks, Pedro 2015-05-13 4:10 GMT+12:00 Gavin Andresen : > 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 > =E2=80=8B=E2=80=8B > 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 movin= g > 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. >> > > > > -- > -- > 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-development > > --001a11c3564ed1ed4d0515e92172 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Disclaimer: I don't know anything about Bitcoin.

>= ; =E2=80=8B2) 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=20 alternative consensus algorithm (in this scenario there is very little=20 mining).

I don't understand why you would casually mention mo= ving away from Proof of Work, I thought that was the big breakthrough that = made Bitcoin possible at all?

Thanks,
Pedro

2015-05-13 4:10 GMT+12:00 G= avin Andresen <gavinandresen@gmail.com>:
Added back th= e list, I didn't mean to reply privately:

Fair enou= gh, I'll try to find time in the next month or three to write up four p= lausible future scenarios for how mining incentives might work:

1) Fee-supported with very large blocks containing lots of tiny-fee= transactions
=E2=80=8B=E2=80=8B
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 securit= y via alternative consensus algorithm (in this scenario there is very littl= e mining).
4) Fee supported with small blocks containing high-fee= transactions moving coins to/from sidechains.

Wou= ld 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 happ= en?

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


On Tue, May 12, 2015 at 10:39 AM, Tho= mas Voegtlin <thomasv@electrum.org> wrote:
Le 12/05/2015 15:44, Gavin And= resen 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

-----------------------------------------------------------------------= -------
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-de= velopment


--001a11c3564ed1ed4d0515e92172--