On Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn wrote:
> That would be annoying for testing. Regtest mode allows you to create a
> new block by just running "setgenerate true" (it switches itself off after
> creating a block). If you had to set up a complicated set of separate
> programs just to do r
That would be annoying for testing. Regtest mode allows you to create a new
block by just running "setgenerate true" (it switches itself off after
creating a block). If you had to set up a complicated set of separate
programs just to do regtest mode that'd be a step backwards, IMO.
On Thu, Aug 22
On Thu, Aug 22, 2013 at 5:36 AM, Maciej Trebacz wrote:
> Will removing "getwork" from the client impact the "setgenerate" RPC call?
> I.e. would you still be able to generate coins on testnet-in-a-box this way,
> or would you need a dedicated miner for that? testnet-in-a-box is very
> useful for t
Will removing "getwork" from the client impact the "setgenerate" RPC call?
I.e. would you still be able to generate coins on testnet-in-a-box this
way, or would you need a dedicated miner for that? testnet-in-a-box is very
useful for testing and easy to setup, it would be great if it stays that
way
> It appears that we will soon be at a hashrate where all the desktop
> CPUs in the world couldn't really make a dent in it... certainly not
> desktop cpus using the slow integrated cpu miner,
I thought the integrated miner was retired a version or so ago - I
dontrecall seeing it for some time in
Message: 1
Date: Mon, 19 Aug 2013 14:07:46 -0700
From: Gregory Maxwell
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
bitcoind
To: "Goss, Brian C., M.D."
Cc: "bitcoin-development@lists.sourceforge.net"
Message-ID:
Content-Type:
Hence ship a miner that automatically reads the bitcoin.conf to find the
RPC authentication info. It would be faster and more efficient than the
unoptimized miner while simplifying the bitcoind code. Win for everyone.
Warren
On Mon, Aug 19, 2013 at 1:02 PM, Andreas Schildbach
wrote:
> On 08/1
On 08/19/2013 10:34 PM, Jeff Garzik wrote:
>> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned
>> people that getwork will be removed in the next major version. Pooler's CPU
>> minerd which supports both sha256d and scrypt recently grew stratum support.
>> Perhaps he could b
Removing getwork and the old miner and packaging a better miner seems
the best solution for the reasons already mentioned.
Not directly related, but this remembered me that we planned to
remove the accounting features on freicoin. We don't want to adapt
them for demurrage and we think business sho
On Mon, Aug 19, 2013 at 1:22 PM, Goss, Brian C., M.D.
wrote:
> What if we have a massive (like many orders of magnitude) drop in network
> harsh rate? Might such a function be useful to salvage the (non-functioning)
> network? Same for IRC bootstrapping. How do we pick ourselves up off the
>
driving use case
remains of which we're unaware, speak up, please. We don't want to break
anybody needlessly.
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/
----------
Message: 2
Date: Mon, 19
On Mon, Aug 19, 2013 at 4:33 PM, Warren Togami Jr. wrote:
> FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned
> people that getwork will be removed in the next major version. Pooler's CPU
> minerd which supports both sha256d and scrypt recently grew stratum support.
> Perhaps
FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned
people that getwork will be removed in the next major version. Pooler's
CPU minerd which supports both sha256d and scrypt recently grew stratum
support. Perhaps he could be convinced to add GBT support too, which would
help th
On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell wrote:
> I think removing the ability to mine in the stock package would be
> regrettable,
I am naughty and should clarify. I had ass.u.me.d that Jeff's patch
also removed the internal CPU miner, because doing so is necessary for
actually getting
This sounds like an ideal compromise.
On Mon, Aug 19, 2013 at 3:16 PM, Gregory Maxwell wrote:
> On Mon, Aug 19, 2013 at 1:09 PM, Frank F wrote:
> > If there are technical problems with getwork, maybe they should be
> addressed
> > and fixed instead of outright abandoned.
>
> They have been, re
Thank you for setting me straight. Please forgive my ignorance.
On Mon, Aug 19, 2013 at 3:14 PM, Pieter Wuille wrote:
> On Mon, Aug 19, 2013 at 10:09 PM, Frank F wrote:
> > I strongly object to removing the only mechanism that allows anyone to
> say
> > that bitcoin is p2p, in the truest sense
On Mon, Aug 19, 2013 at 1:09 PM, Frank F wrote:
> If there are technical problems with getwork, maybe they should be addressed
> and fixed instead of outright abandoned.
They have been, resulting in a replacement called "getblocktemplate"
which (presumably) almost everyone talking to bitcoin(d|-q
ACK, I see no reason to leave broken things in that a) arent necessary
and b) no one has the developer resources to fix.
Matt
On Mon, 2013-08-19 at 12:27 -0400, Jeff Garzik wrote:
> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to
> remove "getwork" RPC from bitcoind: https:/
On Mon, Aug 19, 2013 at 10:09 PM, Frank F wrote:
> I strongly object to removing the only mechanism that allows anyone to say
> that bitcoin is p2p, in the truest sense of the word. Moves like this that
> favor only the pool operators and private mining interests are signs that
> bitcoin is headed
On Monday, August 19, 2013 8:09:41 PM Frank F wrote:
> I strongly object to removing the only mechanism that allows anyone to say
> that bitcoin is p2p, in the truest sense of the word. Moves like this that
> favor only the pool operators and private mining interests are signs that
> bitcoin is hea
I strongly object to removing the only mechanism that allows anyone to say
that bitcoin is p2p, in the truest sense of the word. Moves like this that
favor only the pool operators and private mining interests are signs that
bitcoin is headed towards a monopoly/cartel model, and that would be a
trag
21 matches
Mail list logo
