LearnBitcoin

Bitcoin Dev Archive 2014

Finite monetary supply for Bitcoin

27 messages, 1 to 5 Apr 2014. Started by Pieter Wuille.

Pieter Wuille (4), Greg Maxwell (3), Jorge Timón (3), Matt Whitlock (2), Matt Corallo (2), Luke Dashjr (2), Jeff Garzik (2), Wladimir J. van der Laan (2), +7 more

Permalink Original thread on gnusha.org

Pieter Wuille permalink original

Hi all,

I understand this is a controversial proposal, but bear with me please.

I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I consider this a worthwhile idea to be explored.

The text can be found here: https://gist.github.com/sipa/9920696

Please comment!

Thanks,

Matt Whitlock in reply to Pieter Wuille permalink original

The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1.

:-)

On Tuesday, 1 April 2014, at 9:00 pm, Pieter Wuille wrote:

Quoted text (23 lines)
> Hi all,
>
> I understand this is a controversial proposal, but bear with me please.
>
> I believe we cannot accept the current subsidy schedule anymore, so I
> wrote a small draft BIP with a proposal to turn Bitcoin into a
> limited-supply currency. Dogecoin has already shown how easy such
> changes are, so I consider this a worthwhile idea to be explored.
>
> The text can be found here: https://gist.github.com/sipa/9920696
>
> Please comment!
>
> Thanks,
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Greg Maxwell in reply to Pieter Wuille permalink original

On Tue, Apr 1, 2014 at 12:00 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

Quoted text (8 lines)
> Hi all,
> I understand this is a controversial proposal, but bear with me please.
> I believe we cannot accept the current subsidy schedule anymore, so I
> wrote a small draft BIP with a proposal to turn Bitcoin into a
> limited-supply currency. Dogecoin has already shown how easy such
> changes are, so I consider this a worthwhile idea to be explored.
>
> The text can be found here: https://gist.github.com/sipa/9920696

A minor nitpick: It is well known that the Bitcoin core developers are some of the most active TypeScript coders around, E.g. http://osrc.dfm.io/sipa and http://osrc.dfm.io/gavinandresen

But I think this is an important step forward: Seminal alternative crypto-currencies such as SolidCoin showed us that economic parameters can be freely changed at any time, for any (or no) reason at all; and so we should take this opportunity to demonstrate our commitment to adopting innovative features like non-inflation regardless of their origins in other crypto-currencies.

Tamas Blummer in reply to Pieter Wuille permalink original

While at that let's allow coin bases to be merged from orphan blocks, so miner are fairly rewarded even if unlucky.

On 01.04.2014, at 21:00, Pieter Wuille <pieter.wuille@gmail•com> wrote:

Quoted text (24 lines)
> Hi all,
>
> I understand this is a controversial proposal, but bear with me please.
>
> I believe we cannot accept the current subsidy schedule anymore, so I
> wrote a small draft BIP with a proposal to turn Bitcoin into a
> limited-supply currency. Dogecoin has already shown how easy such
> changes are, so I consider this a worthwhile idea to be explored.
>
> The text can be found here: https://gist.github.com/sipa/9920696
>
> Please comment!
>
> Thanks,
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Mike Hearn in reply to Pieter Wuille permalink original

This proposal will destroy Bitcoin. I would expect nothing less coming from a Google employee.

Matt Corallo in reply to Pieter Wuille permalink original

I disagree with this proposal both in spirit and in practice.

We all know satoshi was the best programmer like no one ever was. Clearly he intended this monetary supply from the beginning, who are we but mere mortals to go against satoshi's will?

Also, should we really do this with a soft fork when we can take this opportunity to redesign the whole system with a hard fork? This is out chance to switch to a whole new script engine!

Matt

On April 1, 2014 3:00:07 PM EDT, Pieter Wuille <pieter.wuille@gmail•com> wrote:

Quoted text (23 lines)
>Hi all,
>
>I understand this is a controversial proposal, but bear with me please.
>
>I believe we cannot accept the current subsidy schedule anymore, so I
>wrote a small draft BIP with a proposal to turn Bitcoin into a
>limited-supply currency. Dogecoin has already shown how easy such
>changes are, so I consider this a worthwhile idea to be explored.
>
>The text can be found here: https://gist.github.com/sipa/9920696
>
>Please comment!
>
>Thanks,
>
>--
>Pieter
>
>------------------------------------------------------------------------------
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge•net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Luke Dashjr in reply to Pieter Wuille permalink original

On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote:

Quoted text (12 lines)
> Hi all,
>
> I understand this is a controversial proposal, but bear with me please.
>
> I believe we cannot accept the current subsidy schedule anymore, so I
> wrote a small draft BIP with a proposal to turn Bitcoin into a
> limited-supply currency. Dogecoin has already shown how easy such
> changes are, so I consider this a worthwhile idea to be explored.
>
> The text can be found here: https://gist.github.com/sipa/9920696
>
> Please comment!

I cleaned it up a bit. By 2214, we should be using tonal numbers after all:

https://gist.github.com/luke-jr/9920788

Benjamin Cordes in reply to Luke Dashjr permalink original

luke, you might enjoy the book Topos of Music. It's a complete mathematical music theory by a student of Grothendieck. He advanced Euler's theories of harmony based on advanced category theory. I'm sure there are many applications to Bitcoin.

On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr <luke@dashjr•org> wrote:

Quoted text (23 lines)
> On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote:
>> Hi all,
>>
>> I understand this is a controversial proposal, but bear with me please.
>>
>> I believe we cannot accept the current subsidy schedule anymore, so I
>> wrote a small draft BIP with a proposal to turn Bitcoin into a
>> limited-supply currency. Dogecoin has already shown how easy such
>> changes are, so I consider this a worthwhile idea to be explored.
>>
>> The text can be found here: https://gist.github.com/sipa/9920696
>>
>> Please comment!
>
> I cleaned it up a bit. By 2214, we should be using tonal numbers after all:
>
> https://gist.github.com/luke-jr/9920788
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Luke Dashjr in reply to Benjamin Cordes permalink original

Please, *music* is obsolete, but inline replies *are not*!

On Tuesday, April 01, 2014 7:16:42 PM Benjamin Cordes wrote:

Quoted text (30 lines)
> luke, you might enjoy the book Topos of Music. It's a complete
> mathematical music theory by a student of Grothendieck. He advanced
> Euler's theories of harmony based on advanced category theory. I'm
> sure there are many applications to Bitcoin.
>
> On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr <luke@dashjr•org> wrote:
> > On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote:
> >> Hi all,
> >>
> >> I understand this is a controversial proposal, but bear with me please.
> >>
> >> I believe we cannot accept the current subsidy schedule anymore, so I
> >> wrote a small draft BIP with a proposal to turn Bitcoin into a
> >> limited-supply currency. Dogecoin has already shown how easy such
> >> changes are, so I consider this a worthwhile idea to be explored.
> >>
> >> The text can be found here: https://gist.github.com/sipa/9920696
> >>
> >> Please comment!
> >
> > I cleaned it up a bit. By 2214, we should be using tonal numbers after
> > all:
> >
> > https://gist.github.com/luke-jr/9920788
> >
> > -------------------------------------------------------------------------
> > ----- _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge•net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Peter Todd in reply to Pieter Wuille permalink original

On Tue, Apr 01, 2014 at 09:00:07PM +0200, Pieter Wuille wrote:

Quoted text (10 lines)
> Hi all,
>
> I understand this is a controversial proposal, but bear with me please.
>
> I believe we cannot accept the current subsidy schedule anymore, so I
> wrote a small draft BIP with a proposal to turn Bitcoin into a
> limited-supply currency. Dogecoin has already shown how easy such
> changes are, so I consider this a worthwhile idea to be explored.
>
> The text can be found here: https://gist.github.com/sipa/9920696

What's interesting about this bug is we could also fix the problem - the economic shock - by first implementing the OP_CHECKLOCKTIMEVERIFY opcode in a soft-fork, followed by a second soft-fork requiring miners to "pay-forward" a percentage of their coinbase outputs to the future. (remember that whomever mines a block controls what recently-made-available anyone-can-spend txouts are included in their block) We could then pick the distribution rate fairly arbitrarily; I propose the following linear distribution:

Each gold mine produces 21,000,000 coins over 210,000*64 blocks, or 1.5625 BTC/block evenly distributed. Measured as an absolute against the monetary the inflation rate will converge towards zero; measured against the actual economic monetary supply the value will converge towards some low value of inflation. In the short run we get an immediate reduction in inflation, which can help our currently sluggish price. Either outcome should be acceptable to any reasonable goldbug - fortunately our community is almost entirely made up of such calm and reasonable people. Meanwhile maintaining a miner reward has significant advantages in terms of the long-term sustainability of the system - everyone needs PoW security regardless of whether or not you do transactions, thus we should all pay into it.

As for your example of Python, I'm sure they'll accept a pull-req changing the behavior in the language.

Pieter Wuille in reply to Peter Todd permalink original

On Tue, Apr 1, 2014 at 10:00 PM, Peter Todd <pete@petertodd•org> wrote:

Quoted text (11 lines)
> On Tue, Apr 01, 2014 at 09:00:07PM +0200, Pieter Wuille wrote:
>> The text can be found here: https://gist.github.com/sipa/9920696
>
> What's interesting about this bug is we could also fix the problem - the
> economic shock - by first implementing the OP_CHECKLOCKTIMEVERIFY opcode
> in a soft-fork, followed by a second soft-fork requiring miners to
> "pay-forward" a percentage of their coinbase outputs to the future.
> (remember that whomever mines a block controls what
> recently-made-available anyone-can-spend txouts are included in their
> block) We could then pick the distribution rate fairly arbitrarily; I
> propose the following linear distribution:

Interesting idea, but perhaps we can keep that change for a future hard fork, as Matt suggested? That means it could be implemented much more concisely too.

Mike, I'm sad to hear you feel that way. I'll move your name in the document from ACKnowledgements to NAKnowledgements.

As this is a relatively urgent matter - we risk forks within 250 years otherwise, I'd like to move this forward quickly.

In case there are no further objections (excluding from people who disagree with me), I'd like to request a BIP number for this. Any number is fine, I guess, as long as it's finite.

Pieter Wuille in reply to Matt Whitlock permalink original

On Tue, Apr 1, 2014 at 9:04 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:

Quoted text (1 line)
> The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1.

Thanks - fixed!

Jorge Timón in reply to Matt Corallo permalink original

On 4/1/14, Matt Corallo <bitcoin-list@bluematt•me> wrote:

Quoted text (3 lines)
> Also, should we really do this with a soft fork when we can take this
> opportunity to redesign the whole system with a hard fork? This is out
> chance to switch to a whole new script engine!

+1 The hard fork also forces the whole community and not a few miners to decide. Well, if it is possible for the community to reach an agreement with such a short time frame...

Quoted text (28 lines)
> Matt
>
> On April 1, 2014 3:00:07 PM EDT, Pieter Wuille <pieter.wuille@gmail•com>
> wrote:
>>Hi all,
>>
>>I understand this is a controversial proposal, but bear with me please.
>>
>>I believe we cannot accept the current subsidy schedule anymore, so I
>>wrote a small draft BIP with a proposal to turn Bitcoin into a
>>limited-supply currency. Dogecoin has already shown how easy such
>>changes are, so I consider this a worthwhile idea to be explored.
>>
>>The text can be found here: https://gist.github.com/sipa/9920696
>>
>>Please comment!
>>
>>Thanks,
>>
>>--
>>Pieter
>>
>>------------------------------------------------------------------------------
>>_______________________________________________
>>Bitcoin-development mailing list
>>Bitcoin-development@lists•sourceforge•net
>>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Greg Maxwell in reply to Pieter Wuille permalink original

On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:

Quoted text (3 lines)
> In case there are no further objections (excluding from people who
> disagree with me), I'd like to request a BIP number for this. Any
> number is fine, I guess, as long as it's finite.

With ten people commenting on this proposal there are quite a few ways in which you could partition their views. Only one possible integer partitioning has everyone in the same partition, so consensus seems unlikely.

But owing to a rather large bribe (or at least not less large than any other offered by competing parties) I hereby assign BIP 42 for this proposal.

Daryl Banttari in reply to Greg Maxwell permalink original

On Tue, Apr 1, 2014 at 4:47 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

Quoted text (4 lines)
> But owing to a rather large bribe (or at least not less large than any
> other offered by competing parties) I hereby assign BIP 42 for this
> proposal.
>

What about BIP 420? Everyone knows if you add zero it's still the same number.

Matt Corallo in reply to Greg Maxwell permalink original

I move to reclaim bip 42 as reserved for a bip containing either a reference to musical dolphins or towels in the name.

Matt

On April 1, 2014 5:47:34 PM EDT, Gregory Maxwell <gmaxwell@gmail•com> wrote:

Quoted text (20 lines)
>On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille <pieter.wuille@gmail•com>
>wrote:
>> In case there are no further objections (excluding from people who
>> disagree with me), I'd like to request a BIP number for this. Any
>> number is fine, I guess, as long as it's finite.
>
>With ten people commenting on this proposal there are quite a few ways
>in which you could partition their views. Only one possible integer
>partitioning has everyone in the same partition, so consensus seems
>unlikely.
>
>But owing to a rather large bribe (or at least not less large than any
>other offered by competing parties) I hereby assign BIP 42 for this
>proposal.
>
>------------------------------------------------------------------------------
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge•net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Jeff Garzik in reply to Daryl Banttari permalink original

On Tue, Apr 1, 2014 at 5:51 PM, Daryl Banttari <dbanttari@gmail•com> wrote:

Quoted text (2 lines)
> What about BIP 420?  Everyone knows if you add zero it's still the same
> number.

Similarly, everyone knows if you multiply both sides by zero, the result is always a true statement.

Pieter Wuille in reply to Greg Maxwell permalink original

On Tue, Apr 1, 2014 at 11:47 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

Quoted text (4 lines)
> On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> But owing to a rather large bribe (or at least not less large than any
> other offered by competing parties) I hereby assign BIP 42 for this
> proposal.

Submitted as BIP 42 (https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki) through PR #42 (https://github.com/bitcoin/bips/pull/42).

Thanks!

Kyle Jerviss in reply to Matt Whitlock permalink original

Matt Whitlock wrote:

Quoted text (2 lines)
> The creation date in your BIP header has the wrong format. It should be 01-04-2014, per BIP 1.
>

At first, I thought this was a second April Fool's joke, but then I looked and saw that all of the BIPs really do use this format. As far as I can tell, we are using this insane format because RFC 822 predates ISO 8601 by half a decade.

Since we don't have half a gajillion mail servers to patch, we could, if we desired, adopt a sensible date format here. The cost to the community would be minimal, with probably not more than a half dozen people needing to update scripts. It could even be as simple as one guy running sed s/parseabomination/parsedate/g

Wladimir J. van der Laan in reply to Kyle Jerviss permalink original

On Fri, Apr 4, 2014 at 5:41 AM, kjj <bitcoin-devel@jerviss•org> wrote:

Quoted text (15 lines)
> Matt Whitlock wrote:
> > The creation date in your BIP header has the wrong format. It should be
> 01-04-2014, per BIP 1.
> >
> At first, I thought this was a second April Fool's joke, but then I
> looked and saw that all of the BIPs really do use this format.  As far
> as I can tell, we are using this insane format because RFC 822 predates
> ISO 8601 by half a decade.
>
> Since we don't have half a gajillion mail servers to patch, we could, if
> we desired, adopt a sensible date format here.  The cost to the
> community would be minimal, with probably not more than a half dozen
> people needing to update scripts.  It could even be as simple as one guy
> running sed s/parseabomination/parsedate/g
>

BIPs were based on Python PIPs, PIPs use this same ordering but spell out the month like '1-Oct-2000'. This is slightly more readable than our format.

http://legacy.python.org/dev/peps/pep-0453/

But to make it more confusing they have two different date conventions within the header (one for the modified date, and one for the created date).

Personally I'd prefer to standardize on ISO 8601 (YYYY-MM-DD) dates as well.

Feel free to submit a pull against bips/bips that changes around the dates.

Wladimir

Jeff Garzik in reply to Wladimir J. van der Laan permalink original

On Fri, Apr 4, 2014 at 3:01 AM, Wladimir <laanwj@gmail•com> wrote:

Quoted text (1 line)
> Personally I'd prefer to standardize on ISO 8601 (YYYY-MM-DD) dates as well.

+1 for all-numeric, easily computer parse-able without a lookup table, and naturally sorts correctly in a lexicographic sort.

English (or any language) should never be in a date format, on a computer.

Jorge Timón in reply to Jeff Garzik permalink original

I like both DD-MM-YYYY and YYYY-MM-DD. I just dislike MM-DD-YYYY and YYYY-DD-MM.

On 4/4/14, Jeff Garzik <jgarzik@bitpay•com> wrote:

Quoted text (20 lines)
> On Fri, Apr 4, 2014 at 3:01 AM, Wladimir <laanwj@gmail•com> wrote:
>> Personally I'd prefer to standardize on ISO 8601 (YYYY-MM-DD) dates as
>> well.
>
> +1 for all-numeric, easily computer parse-able without a lookup table,
> and naturally sorts correctly in a lexicographic sort.
>
> English (or any language) should never be in a date format, on a computer.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Matt Whitlock in reply to Jorge Timón permalink original

On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote:

Quoted text (1 line)
> I like both DD-MM-YYYY and YYYY-MM-DD. I just dislike MM-DD-YYYY and YYYY-DD-MM.

Your preferences reflect a cultural bias. The only entirely numeric date format that is unambiguous across all cultures is YYYY-MM-DD. (No culture uses YYYY-DD-MM, or at least the ISO seems to think so.)

Jorge Timón in reply to Matt Whitlock permalink original

On 4/5/14, Matt Whitlock <bip@mattwhitlock•name> wrote:

Quoted text (7 lines)
> On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote:
>> I like both DD-MM-YYYY and YYYY-MM-DD. I just dislike MM-DD-YYYY and
>> YYYY-DD-MM.
>
> Your preferences reflect a cultural bias. The only entirely numeric date
> format that is unambiguous across all cultures is YYYY-MM-DD. (No culture
> uses YYYY-DD-MM, or at least the ISO seems to think so.)

Probably my acceptance of DD-MM-YYYY is caused by cultural bias. The ISO YYYY-MM-DD seems what you normally do with indo-arabic numerals: put the more weighted numbers on the left, so I guess it's the most universal (in addition to being standard).

Wladimir J. van der Laan in reply to Matt Whitlock permalink original

On Sat, Apr 5, 2014 at 12:40 PM, Matt Whitlock <bip@mattwhitlock•name>wrote:

Quoted text (8 lines)
> On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote:
> > I like both DD-MM-YYYY and YYYY-MM-DD. I just dislike MM-DD-YYYY and
> YYYY-DD-MM.
>
> Your preferences reflect a cultural bias. The only entirely numeric date
> format that is unambiguous across all cultures is YYYY-MM-DD. (No culture
> uses YYYY-DD-MM, or at least the ISO seems to think so.)
>

Let's not waste any time shed-painting this. I'd like to finish this discussion at once:

https://xkcd.com/1179/

Wladimir

Daryl Tucker in reply to Wladimir J. van der Laan permalink original

YYYY-MM-DD sorts more naturally.

On 04/05/2014 06:28 AM, Wladimir wrote:

Quoted text (31 lines)
>
> On Sat, Apr 5, 2014 at 12:40 PM, Matt Whitlock <bip@mattwhitlock•name
> <mailto:bip@mattwhitlock.name>> wrote:
>
>     On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote:
>     > I like both DD-MM-YYYY and YYYY-MM-DD. I just dislike MM-DD-YYYY
>     and YYYY-DD-MM.
>
>     Your preferences reflect a cultural bias. The only entirely
>     numeric date format that is unambiguous across all cultures is
>     YYYY-MM-DD. (No culture uses YYYY-DD-MM, or at least the ISO seems
>     to think so.)
>
>
> Let's not waste any time shed-painting this. I'd like to finish this
> discussion at once:
>
> https://xkcd.com/1179/
>
> Wladimir
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Greg Maxwell in reply to Kyle Jerviss permalink original

On Thu, Apr 3, 2014 at 8:41 PM, kjj <bitcoin-devel@jerviss•org> wrote:

Quoted text (4 lines)
> At first, I thought this was a second April Fool's joke, but then I
> looked and saw that all of the BIPs really do use this format.  As far
> as I can tell, we are using this insane format because RFC 822 predates
> ISO 8601 by half a decade.

In my opinion you can have whatever style you want on the BIPs, so long as you pledge to slay all who come and complain about the new style.