Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of dashjr.org
	designates 85.234.147.28 as permitted sender)
	client-ip=85.234.147.28; envelope-from=luke@dashjr.org;
	helo=zinan.dashjr.org; 
From: Luke Dashjr <luke@dashjr.org>
To: Sergio Lerner <sergiolerner@certimix.com>
Date: Mon, 29 Dec 2014 22:35:04 +0000
User-Agent: KMail/1.13.7 (Linux/3.14.27-gentoo; KDE/4.12.5; x86_64; ; )
References: <54A1A99E.1020604@certimix.com>
In-Reply-To: <54A1A99E.1020604@certimix.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201412292235.05695.luke@dashjr.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP: Voluntary deposit bonds
Precedence: list

On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input  to be added (only a
> pseudo-input).

This is something I've wanted since 2011, but hasn't been a priority.

> Because sometime in the future (maybe 5-10 years) we may have to deal
> with problems of securing the blockchain, as the subsidy is lowered. We
> don't want the number of confirmation blocks to be increased in
> compensation because Bitcoin won't be able to compete with other payment
> networks.
> Then by having this hardfork now, we will be able to soft-fork later to
> any rule we may came come up with involving deposit bonds,
> proof-of-stake, and the penalization of double-mining (mining two blocks
> at the same height) to prevent short-range attacks.

I'm not sure this increases the priority of it.

If someone feels it's worth the time, I'd suggest coding up a branch that 
hardforks it in at some far-off block height. Even if it doesn't get merged 
right away, at least the code will be available for testing and ready to go 
when/if that time comes.

Luke