BIP 0023 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0023.mediawiki

2019-09-24T18:00:57Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0023.mediawiki

Show changes

934: Undo revision 44927 by Luke-jr (talk)

2016-03-29T17:12:00Z

Undo revision 44927 by Luke-jr (talk)

Show changes

Luke-jr: Undo revision 42914 by Witchspace (talk)

2014-03-11T23:58:10Z

Undo revision 42914 by Witchspace (talk)

Show changes

Wumpus: Move to github

2013-12-06T07:48:07Z

Move to github

Show changes

Luke-jr: /* Rationale */ Fix higher/lower

2013-05-09T10:14:47Z

Rationale: Fix higher/lower

← Older revision		Revision as of 10:14, 9 May 2013
Line 281:		Line 281:

	Is "target" really needed?		Is "target" really needed?
	* Some pools work with ~~higher~~ targets, and should not be expected to waste bandwidth ignoring shares that don't meet it.		* Some pools work with lower targets, and should not be expected to waste bandwidth ignoring shares that don't meet it.
	* Required to be a proper superset of getwork.		* Required to be a proper superset of getwork.
	* As mining hashrates grow, some miners may need the ability to request a ~~higher~~ target from their pools to be able to manage their bandwidth use.		* As mining hashrates grow, some miners may need the ability to request a lower target from their pools to be able to manage their bandwidth use.

	What is the purpose of the "hash" transaction list format?		What is the purpose of the "hash" transaction list format?

Luke-jr at 23:58, 20 February 2013

2013-02-20T23:58:12Z

← Older revision		Revision as of 23:58, 20 February 2013
Line 5:		Line 5:
	Title: getblocktemplate - Pooled Mining		Title: getblocktemplate - Pooled Mining
	Author: Luke Dashjr <luke+bip22@dashjr.org>		Author: Luke Dashjr <luke+bip22@dashjr.org>
	Status: ~~Draft~~		Status: Accepted
	Type: Standards Track		Type: Standards Track
	Created: 28-02-2012		Created: 28-02-2012

Luke-jr: /* Summary Support Levels */ These seem good

2013-02-20T23:56:51Z

Summary Support Levels: These seem good

← Older revision		Revision as of 23:56, 20 February 2013
Line 19:		Line 19:

	===Summary Support Levels===		===Summary Support Levels===
	~~''NOTE: This section is still in early draft''~~

	Something can be said to have BIP 23 Level 1 support if it implements at least:		Something can be said to have BIP 23 Level 1 support if it implements at least:

Luke-jr: /* Full Node Optimization */ Remove entire section, as it is incomplete and there seems to be no interest; a future BIP can reintroduce it if desired

2013-02-20T23:51:13Z

Full Node Optimization: Remove entire section, as it is incomplete and there seems to be no interest; a future BIP can reintroduce it if desired

← Older revision		Revision as of 23:51, 20 February 2013
Line 201:		Line 201:

	The format used for submitting shares with the "share/merkle" mutation shall be the 80-byte block header, the total number of transactions encoded in Bitcoin variable length number format, the coinbase transaction, and then finally the little-endian SHA256 hashes of each link in the merkle chain connecting it to the merkle root.		The format used for submitting shares with the "share/merkle" mutation shall be the 80-byte block header, the total number of transactions encoded in Bitcoin variable length number format, the coinbase transaction, and then finally the little-endian SHA256 hashes of each link in the merkle chain connecting it to the merkle root.

	~~===Full Node Optimization===~~

	~~{\| class="wikitable"~~
	~~! colspan="3" \| template request~~
	\|-
	~~! Key !! Type !! Description~~
	\|-
	~~\| tx \|\| String \|\| format of response "transactions" key elements ("obj" per default; "hash" per full node optimization)~~
	\|}

	~~If the miner is running a full node, they may request to receive the "transactions" key in their template populated with transaction ids instead of the full data.~~
	~~This is done by specifying a "tx" key in the request set to "hash".~~
	~~Note that the "coinbasetxn" key in the template will remain in "obj" format.~~

	~~''FIXME'': Describe gettransaction RPC method?~~

	TODO: Some way to signify that the client has its own memory pool, so the server should only send ones it is particularly interested in - but ignored if the server does not allow transactions/add mutation!

	===Logical Services===		===Logical Services===

Luke-jr: /* Basic Pool Extensions */

2013-02-20T23:46:20Z

Basic Pool Extensions

← Older revision		Revision as of 23:46, 20 February 2013
Line 42:		Line 42:
	! Key !! Type !! Description		! Key !! Type !! Description
	\|-		\|-
	\| target \|\| String \|\| desired target for block template		\| target \|\| String \|\| desired target for block template (may be ignored)
	\|}		\|}

Line 54:		Line 54:
	\| target \|\| String \|\| the number which valid results must be less than, in big-endian hexadecimal		\| target \|\| String \|\| the number which valid results must be less than, in big-endian hexadecimal
	\|}		\|}


	===Block Proposal===		===Block Proposal===

Luke-jr: /* Submission Abbreviation */ Clarify

2012-11-04T03:30:54Z

Submission Abbreviation: Clarify

← Older revision		Revision as of 03:30, 4 November 2012
Line 184:		Line 184:
	\|-		\|-
	\| submit/coinbase		\| submit/coinbase
	\| if the "transactions" provided by the server are used as-is with no changes, submissions may omit transactions after the coinbase		\| if the "transactions" provided by the server are used as-is with no changes, submissions may omit transactions after the coinbase (transaction count varint remains included with the full number of transactions)
	\|-		\|-
	\| submit/truncate		\| submit/truncate