Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1YhIq3-0001xC-2k
	for bitcoin-development@lists.sourceforge.net;
	Sun, 12 Apr 2015 14:26:19 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.177 as permitted sender)
	client-ip=209.85.220.177; envelope-from=pieter.wuille@gmail.com;
	helo=mail-qk0-f177.google.com; 
Received: from mail-qk0-f177.google.com ([209.85.220.177])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YhIq1-00079j-Sd
	for bitcoin-development@lists.sourceforge.net;
	Sun, 12 Apr 2015 14:26:19 +0000
Received: by qkgx75 with SMTP id x75so128428454qkg.1
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 12 Apr 2015 07:26:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.224.198 with SMTP id re6mr9125028obc.49.1428848772242;
	Sun, 12 Apr 2015 07:26:12 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Sun, 12 Apr 2015 07:26:12 -0700 (PDT)
Date: Sun, 12 Apr 2015 07:26:12 -0700
Message-ID: <CAPg+sBjNkzqTUupx5QYZ_uzMwAdY4qRc+PGR5R9qCKUxxcHx7g@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0139ff7c81e4dd051387c79f
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
	(pieter.wuille[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: 1YhIq1-00079j-Sd
Subject: [Bitcoin-development] Deprecating Bitcoin Core's regtest-specific
	`setgenerate` behaviour
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 12 Apr 2015 14:26:19 -0000

--089e0139ff7c81e4dd051387c79f
Content-Type: text/plain; charset=ISO-8859-1

Hello everyone,

Bitcoin Core's `setgenerate` RPC call has had a special meaning for
-regtest (namely instantaneously mining a number of blocks, instead of
starting a background CPU miner).

We're planning to deprecate that overloaded behaviour, and replace it with
a separate RPC call `generate`. Is there any software or user who would
need compatibility with the old behaviour? We're generally very
conservative in changing RPC behaviour, but as this is not related to any
production functionality, we may as well just switch it.

Note that the bitcoin.org developer documentation will need to be updated.

-- 
Pieter

--089e0139ff7c81e4dd051387c79f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hello everyone,<br><br></div>Bitcoin Core&#=
39;s `setgenerate` RPC call has had a special meaning for -regtest (namely =
instantaneously mining a number of blocks, instead of starting a background=
 CPU miner).<br><br>We&#39;re planning to deprecate that overloaded behavio=
ur, and replace it with a separate RPC call `generate`. Is there any softwa=
re or user who would need compatibility with the old behaviour? We&#39;re g=
enerally very conservative in changing RPC behaviour, but as this is not re=
lated to any production functionality, we may as well just switch it.<br><b=
r></div>Note that the <a href=3D"http://bitcoin.org">bitcoin.org</a> develo=
per documentation will need to be updated.<br><br>-- <br></div>Pieter<br><b=
r></div>

--089e0139ff7c81e4dd051387c79f--