Re: Proposal: remove "getwork" RPC from bitcoind

Re: Proposal: remove "getwork" RPC from bitcoind
2013-08-19 20:09 ` Frank F
  2013-08-19 20:15 ` Matt Corallo
  
From: Jeff Garzik @ 2013-08-19 16:27 UTC (permalink / raw)
  To: Bitcoin Dev

Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to
remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork

On mainnet, almost everybody uses a pool (and therefore, not "getwork"
directly to bitcoind).  Those few who solo mine use a pool server to
talk to bitcoind via "getblocktemplate" or other means.  Tests show
that attempts to solo mine on mainnet via "getwork" lead to delays and
problems.

On testnet, getwork has a better chance of continuing to work.
Nevertheless, the same tools (open source pool servers or p2pool) are
available for testnet, obviating the continued need to support
getwork.

However, at one time, getwork to bitcoind was widely used.  I wanted
to poke the audience, to gauge response to removing "getwork."  If a
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/



 permalink raw reply	[|nested]
2013-08-19 16:27 Jeff Garzik

  2013-08-19 20:13   ` Luke-Jr
                     ` (2 more replies)
  2013-08-19 20:15 ` Matt Corallo
  
From: Frank F @ 2013-08-19 20:09 UTC (permalink / raw)
  Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 2616 bytes --]

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
tragic outcome for something that holds a great promise. Nobody knows what
mining will look like in the future, and denying the individual novice the
ability to mine at a small scale, even if we may think it is inefficient
now, is not a good path to start down.

If there are technical problems with getwork, maybe they should be
addressed and fixed instead of outright abandoned.


On Mon, Aug 19, 2013 at 11:27 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:

> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to
> remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork
>
> On mainnet, almost everybody uses a pool (and therefore, not "getwork"
> directly to bitcoind).  Those few who solo mine use a pool server to
> talk to bitcoind via "getblocktemplate" or other means.  Tests show
> that attempts to solo mine on mainnet via "getwork" lead to delays and
> problems.
>
> On testnet, getwork has a better chance of continuing to work.
> Nevertheless, the same tools (open source pool servers or p2pool) are
> available for testnet, obviating the continued need to support
> getwork.
>
> However, at one time, getwork to bitcoind was widely used.  I wanted
> to poke the audience, to gauge response to removing "getwork."  If a
> 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/
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
*MONEY IS OVER!*
                                IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian

[-- Attachment #2: Type: text/html, Size: 3797 bytes --]

 permalink raw reply	[|nested]
2013-08-19 20:09 ` Frank F

  2013-08-19 20:14   ` Pieter Wuille
  2013-08-19 20:16   ` Gregory Maxwell
  
From: Luke-Jr @ 2013-08-19 20:13 UTC (permalink / raw)
  To: bitcoin-development

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 headed towards a monopoly/cartel model, and that would be a
> tragic outcome for something that holds a great promise. Nobody knows what
> mining will look like in the future, and denying the individual novice the
> ability to mine at a small scale, even if we may think it is inefficient
> now, is not a good path to start down.
> 
> If there are technical problems with getwork, maybe they should be
> addressed and fixed instead of outright abandoned.

You missed getblocktemplate. It does everything getwork did and more.

Individual solo miners aren't being locked out at all. This is just removal of 
a protocol that has been obsolete for well over a year now.

Luke



 permalink raw reply	[|nested]
2013-08-19 20:09 ` Frank F
  2013-08-19 20:13   ` Luke-Jr

  2013-08-19 20:16     ` Frank F
  2013-08-19 20:16   ` Gregory Maxwell
  
From: Pieter Wuille @ 2013-08-19 20:14 UTC (permalink / raw)
  To: Frank F;  Bitcoin Dev

On Mon, Aug 19, 2013 at 10:09 PM, Frank F <frankf44@gmail•com> 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 towards a monopoly/cartel model, and that would be a
> tragic outcome for something that holds a great promise. Nobody knows what
> mining will look like in the future, and denying the individual novice the
> ability to mine at a small scale, even if we may think it is inefficient
> now, is not a good path to start down.
>
> If there are technical problems with getwork, maybe they should be addressed
> and fixed instead of outright abandoned.

They were addressed and fixed in a successor API, getblocktemplate.
It's even more decentralization-friendly, as it allows the caller to
see what transactions the daemon is trying to put into a block, and
even modify it.

The suggestion here is not to remove functionality - only to remove an
obsolete API for doing so.

-- 
Pieter



 permalink raw reply	[|nested]
2013-08-19 16:27 Jeff Garzik
  2013-08-19 20:09 ` Frank F

  
From: Matt Corallo @ 2013-08-19 20:15 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

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://en.bitcoin.it/wiki/Getwork
> 
> On mainnet, almost everybody uses a pool (and therefore, not "getwork"
> directly to bitcoind).  Those few who solo mine use a pool server to
> talk to bitcoind via "getblocktemplate" or other means.  Tests show
> that attempts to solo mine on mainnet via "getwork" lead to delays and
> problems.
> 
> On testnet, getwork has a better chance of continuing to work.
> Nevertheless, the same tools (open source pool servers or p2pool) are
> available for testnet, obviating the continued need to support
> getwork.
> 
> However, at one time, getwork to bitcoind was widely used.  I wanted
> to poke the audience, to gauge response to removing "getwork."  If a
> driving use case remains of which we're unaware, speak up, please.  We
> don't want to break anybody needlessly.
> 





 permalink raw reply	[|nested]
2013-08-19 20:14   ` Pieter Wuille

  
From: Frank F @ 2013-08-19 20:16 UTC (permalink / raw)
  Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1537 bytes --]

Thank you for setting me straight. Please forgive my ignorance.


On Mon, Aug 19, 2013 at 3:14 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:

> On Mon, Aug 19, 2013 at 10:09 PM, Frank F <frankf44@gmail•com> 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 towards a monopoly/cartel model, and that would be a
> > tragic outcome for something that holds a great promise. Nobody knows
> what
> > mining will look like in the future, and denying the individual novice
> the
> > ability to mine at a small scale, even if we may think it is inefficient
> > now, is not a good path to start down.
> >
> > If there are technical problems with getwork, maybe they should be
> addressed
> > and fixed instead of outright abandoned.
>
> They were addressed and fixed in a successor API, getblocktemplate.
> It's even more decentralization-friendly, as it allows the caller to
> see what transactions the daemon is trying to put into a block, and
> even modify it.
>
> The suggestion here is not to remove functionality - only to remove an
> obsolete API for doing so.
>
> --
> Pieter
>



-- 
*MONEY IS OVER!*
                                IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian

[-- Attachment #2: Type: text/html, Size: 2297 bytes --]

 permalink raw reply	[|nested]
2013-08-19 20:09 ` Frank F
  2013-08-19 20:13   ` Luke-Jr
  2013-08-19 20:14   ` Pieter Wuille

  2013-08-19 20:18     ` Frank F
  2013-08-19 20:23     ` Gregory Maxwell
  
From: Gregory Maxwell @ 2013-08-19 20:16 UTC (permalink / raw)
  To: Frank F;  Bitcoin Dev

On Mon, Aug 19, 2013 at 1:09 PM, Frank F <frankf44@gmail•com> 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|-qt) has been
using for a long time.

I think removing the ability to mine in the stock package would be
regrettable, but to be honest we already don't have it for the
mainnet. I think we should do as Jeff suggests and remove getwork. But
I think we should also package along a proper getblocktemplate miner
to remove any doubt that we're providing a full network node here.  (I
note that the choice of miner is also easy:  Regardless of people's
preferences which way or another, AFAIK only luke's bfgminer stuff can
mine directly against bitcoin getblocktemplate with no pool in the
middle.  It also supports a huge variety of hardware, and a superset
of our target platforms)



 permalink raw reply	[|nested]
2013-08-19 20:16   ` Gregory Maxwell

  2013-08-19 20:23     ` Gregory Maxwell
  
From: Frank F @ 2013-08-19 20:18 UTC (permalink / raw)
  Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

This sounds like an ideal compromise.


On Mon, Aug 19, 2013 at 3:16 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

> On Mon, Aug 19, 2013 at 1:09 PM, Frank F <frankf44@gmail•com> 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|-qt) has been
> using for a long time.
>
> I think removing the ability to mine in the stock package would be
> regrettable, but to be honest we already don't have it for the
> mainnet. I think we should do as Jeff suggests and remove getwork. But
> I think we should also package along a proper getblocktemplate miner
> to remove any doubt that we're providing a full network node here.  (I
> note that the choice of miner is also easy:  Regardless of people's
> preferences which way or another, AFAIK only luke's bfgminer stuff can
> mine directly against bitcoin getblocktemplate with no pool in the
> middle.  It also supports a huge variety of hardware, and a superset
> of our target platforms)
>



-- 
*MONEY IS OVER!*
                                IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian

[-- Attachment #2: Type: text/html, Size: 2073 bytes --]

 permalink raw reply	[|nested]
2013-08-19 21:07 ` Gregory Maxwell
  
From: Goss, Brian C., M.D. @ 2013-08-19 20:22 UTC (permalink / raw)
  To: 'bitcoin-development@lists•sourceforge.net'

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 ground in case of the equivalent of a great depression in network hash rate (or some jerk spending $100M just to drive the difficulty up and then turning his hardware off?).

-----Original Message-----
From: bitcoin-development-bounces@lists•sourceforge.net [mailto:bitcoin-development-bounces@lists•sourceforge.net] On Behalf Of bitcoin-development-request@lists•sourceforge.net
Sent: Monday, August 19, 2013 3:16 PM
To: bitcoin-development@lists•sourceforge.net
Subject: Bitcoin-development Digest, Vol 27, Issue 28

Send Bitcoin-development mailing list submissions to
	bitcoin-development@lists•sourceforge.net

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
	bitcoin-development-request@lists•sourceforge.net

You can reach the person managing the list at
	bitcoin-development-owner@lists•sourceforge.net

When replying, please edit your Subject line so it is more specific than "Re: Contents of Bitcoin-development digest..."


Today's Topics:

   1. Proposal: remove "getwork" RPC from bitcoind (Jeff Garzik)
   2. Re: Proposal: remove "getwork" RPC from	bitcoind (Frank F)
   3. Re: Proposal: remove "getwork" RPC from	bitcoind (Luke-Jr)
   4. Re: Proposal: remove "getwork" RPC from	bitcoind (Pieter Wuille)
   5. Re: Proposal: remove "getwork" RPC from bitcoind (Matt Corallo)
   6. Re: Proposal: remove "getwork" RPC from	bitcoind (Frank F)


----------------------------------------------------------------------

Message: 1
Date: Mon, 19 Aug 2013 12:27:01 -0400
From: Jeff Garzik <jgarzik@bitpay•com>
Subject: [Bitcoin-development] Proposal: remove "getwork" RPC from
	bitcoind
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID:
	<CAJHLa0MnnWw=qiYC0nJcY=BdTDcAjGtraJ+kazoG7_bHW-HBtw@mail•gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork

On mainnet, almost everybody uses a pool (and therefore, not "getwork"
directly to bitcoind).  Those few who solo mine use a pool server to talk to bitcoind via "getblocktemplate" or other means.  Tests show that attempts to solo mine on mainnet via "getwork" lead to delays and problems.

On testnet, getwork has a better chance of continuing to work.
Nevertheless, the same tools (open source pool servers or p2pool) are available for testnet, obviating the continued need to support getwork.

However, at one time, getwork to bitcoind was widely used.  I wanted to poke the audience, to gauge response to removing "getwork."  If a 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 Aug 2013 15:09:41 -0500
From: Frank F <frankf44@gmail•com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
	bitcoind
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID:
	<CALxyHsXoCqL8dNXeayibfbR7-JU6Ke19gJJ1fToboULdUa155Q@mail•gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

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
tragic outcome for something that holds a great promise. Nobody knows what
mining will look like in the future, and denying the individual novice the
ability to mine at a small scale, even if we may think it is inefficient
now, is not a good path to start down.

If there are technical problems with getwork, maybe they should be
addressed and fixed instead of outright abandoned.


On Mon, Aug 19, 2013 at 11:27 AM, Jeff Garzik <jgarzik@bitpay•com> wrote:

> Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to
> remove "getwork" RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork
>
> On mainnet, almost everybody uses a pool (and therefore, not "getwork"
> directly to bitcoind).  Those few who solo mine use a pool server to
> talk to bitcoind via "getblocktemplate" or other means.  Tests show
> that attempts to solo mine on mainnet via "getwork" lead to delays and
> problems.
>
> On testnet, getwork has a better chance of continuing to work.
> Nevertheless, the same tools (open source pool servers or p2pool) are
> available for testnet, obviating the continued need to support
> getwork.
>
> However, at one time, getwork to bitcoind was widely used.  I wanted
> to poke the audience, to gauge response to removing "getwork."  If a
> 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/
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
*MONEY IS OVER!*
                                IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Mon, 19 Aug 2013 20:13:00 +0000
From: "Luke-Jr" <luke@dashjr•org>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
	bitcoind
To: bitcoin-development@lists•sourceforge.net
Message-ID: <201308192013.02806.luke@dashjr•org>
Content-Type: Text/Plain;  charset="iso-8859-15"

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 headed towards a monopoly/cartel model, and that would be a
> tragic outcome for something that holds a great promise. Nobody knows what
> mining will look like in the future, and denying the individual novice the
> ability to mine at a small scale, even if we may think it is inefficient
> now, is not a good path to start down.
> 
> If there are technical problems with getwork, maybe they should be
> addressed and fixed instead of outright abandoned.

You missed getblocktemplate. It does everything getwork did and more.

Individual solo miners aren't being locked out at all. This is just removal of 
a protocol that has been obsolete for well over a year now.

Luke



------------------------------

Message: 4
Date: Mon, 19 Aug 2013 22:14:36 +0200
From: Pieter Wuille <pieter.wuille@gmail•com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
	bitcoind
To: Frank F <frankf44@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID:
	<CAPg+sBjMdZfHpZrvHwMx6oQsS0yJaXVjTnyRwf6VCdnWTHQZaw@mail•gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 19, 2013 at 10:09 PM, Frank F <frankf44@gmail•com> 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 towards a monopoly/cartel model, and that would be a
> tragic outcome for something that holds a great promise. Nobody knows what
> mining will look like in the future, and denying the individual novice the
> ability to mine at a small scale, even if we may think it is inefficient
> now, is not a good path to start down.
>
> If there are technical problems with getwork, maybe they should be addressed
> and fixed instead of outright abandoned.

They were addressed and fixed in a successor API, getblocktemplate.
It's even more decentralization-friendly, as it allows the caller to
see what transactions the daemon is trying to put into a block, and
even modify it.

The suggestion here is not to remove functionality - only to remove an
obsolete API for doing so.

-- 
Pieter



------------------------------

Message: 5
Date: Mon, 19 Aug 2013 16:15:08 -0400
From: Matt Corallo <bitcoin-list@bluematt•me>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
	bitcoind
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID: <1376943308.27037.7.camel@localhost•localdomain>
Content-Type: text/plain; charset="UTF-8"

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://en.bitcoin.it/wiki/Getwork
> 
> On mainnet, almost everybody uses a pool (and therefore, not "getwork"
> directly to bitcoind).  Those few who solo mine use a pool server to
> talk to bitcoind via "getblocktemplate" or other means.  Tests show
> that attempts to solo mine on mainnet via "getwork" lead to delays and
> problems.
> 
> On testnet, getwork has a better chance of continuing to work.
> Nevertheless, the same tools (open source pool servers or p2pool) are
> available for testnet, obviating the continued need to support
> getwork.
> 
> However, at one time, getwork to bitcoind was widely used.  I wanted
> to poke the audience, to gauge response to removing "getwork."  If a
> driving use case remains of which we're unaware, speak up, please.  We
> don't want to break anybody needlessly.
> 





------------------------------

Message: 6
Date: Mon, 19 Aug 2013 15:16:17 -0500
From: Frank F <frankf44@gmail•com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
	bitcoind
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Message-ID:
	<CALxyHsV=LWY+TzZG-XBQ6HNhxFEezjFhW++aJ7oVbVGEJWW0nw@mail•gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Thank you for setting me straight. Please forgive my ignorance.


On Mon, Aug 19, 2013 at 3:14 PM, Pieter Wuille <pieter.wuille@gmail•com>wrote:

> On Mon, Aug 19, 2013 at 10:09 PM, Frank F <frankf44@gmail•com> 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 towards a monopoly/cartel model, and that would be a
> > tragic outcome for something that holds a great promise. Nobody knows
> what
> > mining will look like in the future, and denying the individual novice
> the
> > ability to mine at a small scale, even if we may think it is inefficient
> > now, is not a good path to start down.
> >
> > If there are technical problems with getwork, maybe they should be
> addressed
> > and fixed instead of outright abandoned.
>
> They were addressed and fixed in a successor API, getblocktemplate.
> It's even more decentralization-friendly, as it allows the caller to
> see what transactions the daemon is trying to put into a block, and
> even modify it.
>
> The suggestion here is not to remove functionality - only to remove an
> obsolete API for doing so.
>
> --
> Pieter
>



-- 
*MONEY IS OVER!*
                                IF YOU WANT IT<http://www.zeitgeistmovie.com/>
=====================================================
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk

------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


End of Bitcoin-development Digest, Vol 27, Issue 28
***************************************************



 permalink raw reply	[|nested]
2013-08-19 20:16   ` Gregory Maxwell
  2013-08-19 20:18     ` Frank F

  2013-08-19 20:33       ` Warren Togami Jr.
  
From: Gregory Maxwell @ 2013-08-19 20:23 UTC (permalink / raw)
  To: Frank F;  Bitcoin Dev

On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell <gmaxwell@gmail•com> 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 rid of most of the getwork code. It doesn't actually.

Though this doesn't change the fact that the internal miner is mostly
a pretext for integrated mining.  Since it only really works on
testnet it also means our testnet testing using it is not a good test
of the actual production software.  I'd rather remove the internal
miner too, getting rid of the extra code and complexity, and package
up a GBT miner which would actually be usable on the mainnet.



 permalink raw reply	[|nested]
2013-08-19 20:23     ` Gregory Maxwell

  2013-08-19 20:34         ` Jeff Garzik
  
From: Warren Togami Jr. @ 2013-08-19 20:33 UTC (permalink / raw)
  To: Gregory Maxwell, pooler;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1845 bytes --]

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 this goal of completely removing the internal miner and getwork.

Warren


On Mon, Aug 19, 2013 at 10:23 AM, Gregory Maxwell <gmaxwell@gmail•com>wrote:

> On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell <gmaxwell@gmail•com>
> 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 rid of most of the getwork code. It doesn't actually.
>
> Though this doesn't change the fact that the internal miner is mostly
> a pretext for integrated mining.  Since it only really works on
> testnet it also means our testnet testing using it is not a good test
> of the actual production software.  I'd rather remove the internal
> miner too, getting rid of the extra code and complexity, and package
> up a GBT miner which would actually be usable on the mainnet.
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2685 bytes --]

 permalink raw reply	[|nested]
2013-08-19 20:33       ` Warren Togami Jr.

  2013-08-19 23:02           ` Andreas Schildbach
  
From: Jeff Garzik @ 2013-08-19 20:34 UTC (permalink / raw)
  To: Warren Togami Jr.;  Bitcoin Dev, pooler

On Mon, Aug 19, 2013 at 4:33 PM, Warren Togami Jr. <wtogami@gmail•com> 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 be convinced to add GBT support too, which would help this
> goal of completely removing the internal miner and getwork.

The internal miner is still actively used for testnet, here.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2013-08-19 20:22 Goss, Brian C., M.D.

  2013-08-19 22:49   ` Jorge Timón
  
From: Gregory Maxwell @ 2013-08-19 21:07 UTC (permalink / raw)
  To: Goss, Brian C., M.D.;  bitcoin-development

On Mon, Aug 19, 2013 at 1:22 PM, Goss, Brian C., M.D.
<Goss.Brian@mayo•edu> 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 ground in case of the equivalent of a great depression in network hash rate (or some jerk spending $100M just to drive the difficulty up and then turning his hardware off?).

[Aside: When replying to the digest, please try to trim it]

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, which is much slower
than external optimized cpu miners.

But this is why I suggest packaging up a modern mining tool that
supports CPU/GPU/FPGA/ASIC mining against a current bitcoind. Doing so
would reduce the difference between testnet and mainnet, and provide
an actually useful tool for contributing directly.

Though again, I note, that Jeff's patch doesn't actually remove the
integrated miner (I think it should…).  Just the getwork support for
external miners which don't use getblocktemplate... and if you're
going to download one of those you could go download bfgminer instead.



 permalink raw reply	[|nested]
2013-08-19 21:07 ` Gregory Maxwell

  
From: Jorge Timón @ 2013-08-19 22:49 UTC (permalink / raw)
  To: Gregory Maxwell;  Goss, Brian C., M.D., bitcoin-development

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 shouldn't use it and should
code their own accounting system instead. One that keeps a full log
of the accounting, etc.
Unfortunately the first exchange to support freicoin (cryptonit) used
this feature for accounting user balances on the exchange.

So the question is, is there any good reason to maintain this?
Is any serious business really using this or anyone at all?

I'm talking about removing the following rpc calls:

getaccount
getaddressesbyaccount
getbalance
getreceivedbyaccount
listaccounts
listreceivedbyaccount
move
sendfrom
setaccount

...and modifying these:

getnewaddress
listreceivedbyaddress
listtransactions
sendmany

I think this would also leave a cleaner API, but I'm just interested
on what the objections would be to this removal.

How crazy does this sound?
Should we reconsider their removal for freicoin, proceed or create a
pull request for bitcoin?

-- 
Jorge Timón

http://freico.in/



 permalink raw reply	[|nested]
2013-08-19 20:34         ` Jeff Garzik

  2013-08-19 23:30             ` Warren Togami Jr.
  
From: Andreas Schildbach @ 2013-08-19 23:02 UTC (permalink / raw)
  To: bitcoin-development

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 be convinced to add GBT support too, which would help this
>> goal of completely removing the internal miner and getwork.
> 
> The internal miner is still actively used for testnet, here.

Here, too. If I'm too impatient to wait for the next block that is.

I think it'd be a pity if the easy way to mine blocks would be removed.





 permalink raw reply	[|nested]
2013-08-19 23:02           ` Andreas Schildbach

  
From: Warren Togami Jr. @ 2013-08-19 23:30 UTC (permalink / raw)
  To: Andreas Schildbach;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

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
<andreas@schildbach•de>wrote:

> 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 be convinced to add GBT support too, which would help
> this
> >> goal of completely removing the internal miner and getwork.
> >
> > The internal miner is still actively used for testnet, here.
>
> Here, too. If I'm too impatient to wait for the next block that is.
>
> I think it'd be a pity if the easy way to mine blocks would be removed.
>
>
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2359 bytes --]

 permalink raw reply	[|nested]


  2013-08-21 21:39   ` rob.golding
  
From: Ron @ 2013-08-21 21:24 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 6186 bytes --]

Message: 1

Date: Mon, 19 Aug 2013 14:07:46 -0700
From: Gregory Maxwell <gmaxwell@gmail•com>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
    bitcoind
To: "Goss, Brian C., M.D." <Goss.Brian@mayo•edu>
Cc: "bitcoin-development@lists•sourceforge.net"
    <bitcoin-development@lists•sourceforge.net>
Message-ID:
    <CAAS2fgQtGg+SxRc7Byw0_L3NpEudPTtBpmnKYt-+7VEVSnKZaQ@mail•gmail.com>
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 19, 2013 at 1:22 PM, Goss, Brian C., M.D.
<Goss.Brian@mayo•edu> 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 ground in case of the equivalent of a great depression in network hash rate (or some jerk spending $100M just to drive the difficulty up and then turning his hardware off?).

[Aside: When replying to the digest, please try to trim it]

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, which is much slower
than external optimized cpu miners.

But this is why I suggest packaging up a modern mining tool that
supports CPU/GPU/FPGA/ASIC mining against a current bitcoind. Doing so
would reduce the difference between testnet and mainnet, and provide
an actually useful tool for contributing directly.

Though again, I note, that Jeff's patch doesn't actually remove the
integrated miner (I think it should?).  Just the getwork support for
external miners which don't use getblocktemplate... and if you're
going to download one of those you could go download bfgminer instead.

Message: 5
Date: Tue, 20 Aug 2013 01:02:41 +0200
From: Andreas Schildbach <andreas@schildbach•de>
Subject: Re: [Bitcoin-development] Proposal: remove "getwork" RPC from
    bitcoind
To: bitcoin-development@lists•sourceforge.net
Message-ID: <kuu86a$ii5$1@ger•gmane.org>
Content-Type: text/plain; charset=ISO-8859-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 be convinced to add GBT support too, which would help this
>> goal of completely removing the internal miner and getwork.
> 
> The internal miner is still actively used for testnet, here.

Here, too. If I'm too impatient to wait for the next block that is.

I think it'd be a pity if the easy way to mine blocks would be removed.
__________________________________________________________________
My comments start here.

I agree with Andreas. The mining code in bitcoind & qt is not so hard to improve 
and even use, such as it is. I am sorry to say that using bfgminer is one big, complicated install, 
on Windows at least, AFAICT from looking at the github code bfgminer-2.10.11.zip. 
Seems much more work than I had bringing up bitcoind/qt from the "ground up" on my 
Windows machine. And the mining code is only a small part of the end of main.cpp .
I don't see it harming the rest of the code when I run it in the daemon or Qt.

Can't one mine "from a distance" using the RPC interface now anyway, even with the 
code still there?

I assume that you all would like to have a "seething horde" of new Windows users 
running and using bitcoin? I know that I sure am trying to make that happen. I think 
an integrated, wallet, miner, full node on the net (which I presume bitcoind/bitcoin-qt 
are) is the first step, and maybe should always exist? Though other variations could 
exist too. Could even be a compile Define, like USE_PNP for example, to strip off 
this or that?

So for me, if I want to mine, just because my solar powered laptop has some free cpu 
cycles, I don't mind having a "snow ball's chance in hell" of solving the "next" block. At 
~0.5 MHPS on my CPU it takes me ~2.5 hours to go through all (2^32)-1 nonces for a 
tentative new block, with a particular set of transactions. I only can get "deep" into 
the nonces when one of those +30 minute blocks comes by! And they do from time to time.

I think forcing users to have two computers to mine, or run two programs,  is "pushing it" 
so to speak? And do I also see some wallet removal code being conjured up on git hub?

I think the beauty that is Satoshi's original bitcoin idea should be kept, together in one 
package. If the code was properly commented, formatted, organized , etc.etc., which I 
understand is "postponed" when one is "in the zone" writing code, then I think 
separating the wallet code or mining code, ought to be much easier. 

I feel that the dirty task of at least "calling things by their right names" (as said in the 
Chinese proverb) should be done first. As an example calling the main Berkeley 
database environment class instance of the wallet an abbreviated 5 lower case 
letter cryptic "bitdb" reminds me of the time when ram and disc storage were 
"dear" and compilers couldn't handle "long" names! I would call it something 
much grander! Only 46 places to change ! Also the member DbEnv dbenv 
is equally underplayed as it is the main actor in the play! Let's not even mention pdb 
being used both for a BerkeleyDB  CDB.Db* and as an albeit private leveldb DB*.!

Pointers that aren't called pSomething, un-commented/un-documented magic numbers 
where commented constants should be, and on and on it goes.

So I just sit back doing the clean up on 0.8.1, then .0.8.2, now 0.8.3 while you 
architects march ahead oblivious to the cryptic minefield of code that exists underneath :) 
My aim is to first clean up the code enough so that I can understand it. Then eventually, 
take it over to a real Windows project/solution where it can be made into an executable 
that is palatable for the masses.

Getting off soapbox now and retreating to the back...(bitcointalk.org that is)

Ron

[-- Attachment #2: Type: text/html, Size: 7807 bytes --]

 permalink raw reply	[|nested]
2013-08-21 21:24 ` [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind Ron

  2013-08-22  9:36     ` Maciej Trebacz
  
From: rob.golding @ 2013-08-21 21:39 UTC (permalink / raw)
  To: bitcoin-development

> 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 bitcoin-qt

Now you can buy a USB stick for $20 which can be pushed to around 
500MH/s, and  there's no reason the manufacturers couldn't ship those 
with a miner-program onboard !

Rob



 permalink raw reply	[|nested]
2013-08-21 21:39   ` rob.golding

  2013-08-22 13:18       ` Jeff Garzik
  
From: Maciej Trebacz @ 2013-08-22  9:36 UTC (permalink / raw)
  To: bitcoin-development

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

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 :).


On Wed, Aug 21, 2013 at 11:39 PM, <rob.golding@astutium•com> wrote:

> > 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 bitcoin-qt
>
> Now you can buy a USB stick for $20 which can be pushed to around
> 500MH/s, and  there's no reason the manufacturers couldn't ship those
> with a miner-program onboard !
>
> Rob
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2298 bytes --]

 permalink raw reply	[|nested]
2013-08-22  9:36     ` Maciej Trebacz

  2013-08-22 13:33         ` Mike Hearn
  
From: Jeff Garzik @ 2013-08-22 13:18 UTC (permalink / raw)
  To: Maciej Trebacz;  bitcoin-development

On Thu, Aug 22, 2013 at 5:36 AM, Maciej Trebacz <maciej@bitalo•com> 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 testing and easy to setup, it would be great if it stays that way

Yes, that is currently being discussed in a separate pull request.  My
pull request does not impact setgenerate, but an added proposal does
remove the internal miner completely.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/



 permalink raw reply	[|nested]
2013-08-22 13:18       ` Jeff Garzik

  2013-08-22 15:30           ` Wladimir
  
From: Mike Hearn @ 2013-08-22 13:33 UTC (permalink / raw)
  To: Jeff Garzik;  Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

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, 2013 at 3:18 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:

> On Thu, Aug 22, 2013 at 5:36 AM, Maciej Trebacz <maciej@bitalo•com> 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 testing and easy to setup, it would be great if it stays that
> way
>
> Yes, that is currently being discussed in a separate pull request.  My
> pull request does not impact setgenerate, but an added proposal does
> remove the internal miner completely.
>
> --
> Jeff Garzik
> Senior Software Engineer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 2534 bytes --]

 permalink raw reply	[|nested]
2013-08-22 13:33         ` Mike Hearn

  
From: Wladimir @ 2013-08-22 15:30 UTC ( / )
  To: Mike Hearn;  Bitcoin Dev



On Thu, Aug 22, 2013 at 3:33 PM, Mike Hearn <mike@plan99•net> 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 regtest mode that'd be a step backwards, IMO.
>

There is some consensus that when the internal miner is to be removed, a
simple miner should be packaged with the main repository as separate
program (the "reference miner"?). The only change is that it does no longer
need to burden the core code
(see also the discussion here: https://github.com/bitcoin/bitcoin/pull/2917).


Wladimir