Protocol rules - Revision history

Furunodo: /* Block creation fee */

2020-06-23T10:29:26Z

Block creation fee

← Older revision		Revision as of 10:29, 23 June 2020
Line 60:		Line 60:
	(in satoshis) as:		(in satoshis) as:

	(50 * 100000000) >> (height / 210000)		:(50 * 100000000) >> (height / 210000)

	The block creation fee started with 50 BTC, has fallen to 25 BTC at block 210000, ~~will fall~~ to 12.5 BTC at block 420000, and finally down to 0 satoshi with block 6930000.		The block creation fee started with 50 BTC, has fallen to 25 BTC at block 210000, fell to 12.5 BTC at block 420000, to 6.25 at block 630000, will halve every 210000 blocks (roughly 4 years) and finally go down to 0 satoshi with block 6930000 around the year 2140.
	The block creation fee of all coinbase transactions will sum up to 2099999997690000 satoshis, practically 21million BTC.		The block creation fee of all coinbase transactions will sum up to 2099999997690000 satoshis, practically 21million BTC.

Ivanzar at 19:11, 25 August 2017

2017-08-25T19:11:55Z

← Older revision		Revision as of 19:11, 25 August 2017
Line 1:		Line 1:
	~~<translate>~~
	'''Rules''' for [[:Category:Clients\|clients]].		'''Rules''' for [[:Category:Clients\|clients]].

Line 165:		Line 164:

	[[Category:Technical]][[Category:Developer]]		[[Category:Technical]][[Category:Developer]]
	~~</translate>~~

Ivanzar at 19:10, 25 August 2017

2017-08-25T19:10:08Z

← Older revision		Revision as of 19:10, 25 August 2017
Line 1:		Line 1:
			<translate>
	'''Rules''' for [[:Category:Clients\|clients]].		'''Rules''' for [[:Category:Clients\|clients]].

Line 164:		Line 165:

	[[Category:Technical]][[Category:Developer]]		[[Category:Technical]][[Category:Developer]]
			</translate>

Tomasvdw: Minor typo to align tx rule 3 with actual code

2016-10-04T08:41:29Z

Minor typo to align tx rule 3 with actual code

← Older revision		Revision as of 08:41, 4 October 2016
Line 71:		Line 71:
	# Check syntactic correctness		# Check syntactic correctness
	# Make sure neither in or out lists are empty		# Make sure neither in or out lists are empty
	# Size in bytes < MAX_BLOCK_SIZE		# Size in bytes <= MAX_BLOCK_SIZE
	# Each output value, as well as the total, must be in legal money range		# Each output value, as well as the total, must be in legal money range
	# Make sure none of the inputs have hash=0, n=-1 (''coinbase'' transactions)		# Make sure none of the inputs have hash=0, n=-1 (''coinbase'' transactions)

Nayuki: Added and improved links to internal pages

2016-03-04T19:27:37Z

Added and improved links to internal pages

← Older revision		Revision as of 19:27, 4 March 2016
Line 9:		Line 9:
	== Data structures ==		== Data structures ==

	The main data structures are [[~~transactions~~]] and [[~~blocks~~]]. Blocks are composed of the ''block header'' followed by transactions in the block. Transactions are identified by their hash; blocks by the hash of their header. Blocks have prev pointers that link them into a graph.		The main data structures are [[transaction]]s and [[block]]s. Blocks are composed of the ''block header'' followed by transactions in the block. Transactions are identified by their hash; blocks by the hash of their header. Blocks have prev pointers that link them into a graph.

	Conceptually, the client has the following data structures:		Conceptually, the client has the following data structures:
Line 67:		Line 67:
	== [[Protocol_specification#tx\|"tx"]] messages ==		== [[Protocol_specification#tx\|"tx"]] messages ==

	These messages hold a single transaction.		These messages hold a single [[transaction]].

	# Check syntactic correctness		# Check syntactic correctness
Line 95:		Line 95:
	== [[Protocol_specification#block\|"block"]] messages ==		== [[Protocol_specification#block\|"block"]] messages ==

	These messages hold a single block.		These messages hold a single [[block]].

	# Check syntactic correctness		# Check syntactic correctness

Orphanblock: /* "tx" messages */

2014-05-31T14:52:36Z

"tx" messages

← Older revision		Revision as of 14:52, 31 May 2014
Line 77:		Line 77:
	# Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey not matching the two usual forms<ref>Note that this is not a hard requirement on clients.</ref>		# Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey not matching the two usual forms<ref>Note that this is not a hard requirement on clients.</ref>
	# Reject if we already have matching tx in the pool, or in a block in the main branch		# Reject if we already have matching tx in the pool, or in a block in the main branch
	# ~~Reject~~ if any other tx in the pool ~~uses the same~~ transaction ~~output as one used by this tx~~.<ref>Note that this is not a hard requirement on clients. The network-enforced rule is that only <i>one</i> transaction spending a particular output can be in the blockchain, thus preventing double-spending. Technically miners can choose which one they want to put into the block they're working on as long as no other transaction has spent that output either previously in the blockchain, or in the same block. The in-memory transaction pool can technically be managed in whatever way the miner is willing to implement.</ref>		# For each input, if the referenced output exists in any other tx in the pool, reject this transaction.<ref>Note that this is not a hard requirement on clients. The network-enforced rule is that only <i>one</i> transaction spending a particular output can be in the blockchain, thus preventing double-spending. Technically miners can choose which one they want to put into the block they're working on as long as no other transaction has spent that output either previously in the blockchain, or in the same block. The in-memory transaction pool can technically be managed in whatever way the miner is willing to implement.</ref>
	# For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.		# For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.
	# For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction		# For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction

Gmaxwell: /* "tx" messages */ avoid 0/1 indexing confusion, reorder some to better reflect reality (expensive tests come later), and that never existing is pretty much the same as already spent.

2014-03-15T08:20:33Z

"tx" messages: avoid 0/1 indexing confusion, reorder some to better reflect reality (expensive tests come later), and that never existing is pretty much the same as already spent.

← Older revision		Revision as of 08:20, 15 March 2014
Line 79:		Line 79:
	# Reject if any other tx in the pool uses the same transaction output as one used by this tx.<ref>Note that this is not a hard requirement on clients. The network-enforced rule is that only <i>one</i> transaction spending a particular output can be in the blockchain, thus preventing double-spending. Technically miners can choose which one they want to put into the block they're working on as long as no other transaction has spent that output either previously in the blockchain, or in the same block. The in-memory transaction pool can technically be managed in whatever way the miner is willing to implement.</ref>		# Reject if any other tx in the pool uses the same transaction output as one used by this tx.<ref>Note that this is not a hard requirement on clients. The network-enforced rule is that only <i>one</i> transaction spending a particular output can be in the blockchain, thus preventing double-spending. Technically miners can choose which one they want to put into the block they're working on as long as no other transaction has spent that output either previously in the blockchain, or in the same block. The in-memory transaction pool can technically be managed in whatever way the miner is willing to implement.</ref>
	# For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.		# For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.
	~~# For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject this transaction~~
	# For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction		# For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction
	~~# Verify crypto signatures for each input; reject if any are bad~~		# For each input, if the referenced output does not exist (e.g. never existed or has already been spent), reject this transaction<ref>This is the protection against double-spending</ref>
	# For each input, if the referenced output has already been spent ~~by a transaction in the main branch~~, reject this transaction<ref>This is the protection against double-spending</ref>
	# Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range		# Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
	# Reject if the sum of input values < sum of output values		# Reject if the sum of input values < sum of output values
	# Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block		# Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block
			# Verify the [[Script\|scriptPubKey]] accepts for each input; reject if any are bad
	# Add to transaction pool<ref>Note that when the transaction is accepted into the memory pool, an additional check is made to ensure that the coinbase value does not exceed the transaction fees plus the expected BTC value (25BTC as of this writing).</ref>		# Add to transaction pool<ref>Note that when the transaction is accepted into the memory pool, an additional check is made to ensure that the coinbase value does not exceed the transaction fees plus the expected BTC value (25BTC as of this writing).</ref>
	# "Add to wallet if mine"		# "Add to wallet if mine"

Makerofthings7: /* "tx" messages */

2012-12-21T18:34:19Z

"tx" messages

← Older revision		Revision as of 18:34, 21 December 2012
Line 86:		Line 86:
	# Reject if the sum of input values < sum of output values		# Reject if the sum of input values < sum of output values
	# Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block		# Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block
	# Add to transaction pool<ref>Note that when the transaction is accepted into the memory pool, an additional check is made to ensure that the coinbase value does not exceed the transaction fees plus the expected BTC value (~~50BTC~~ as of this writing).</ref>		# Add to transaction pool<ref>Note that when the transaction is accepted into the memory pool, an additional check is made to ensure that the coinbase value does not exceed the transaction fees plus the expected BTC value (25BTC as of this writing).</ref>
	# "Add to wallet if mine"		# "Add to wallet if mine"
	# Relay transaction to peers		# Relay transaction to peers

Dree12: update

2012-12-10T02:36:21Z

update

← Older revision		Revision as of 02:36, 10 December 2012
Line 62:		Line 62:
	(50 * 100000000) >> (height / 210000)		(50 * 100000000) >> (height / 210000)

	The block creation fee started with 50 BTC, ~~will fall~~ to 25 BTC at block 210000, 12.5 BTC at block 420000, finally down to 0 satoshi with block 6930000.		The block creation fee started with 50 BTC, has fallen to 25 BTC at block 210000, will fall to 12.5 BTC at block 420000, and finally down to 0 satoshi with block 6930000.
	The block creation fee of all coinbase transactions will sum up to 2099999997690000 satoshis, practically 21million BTC.		The block creation fee of all coinbase transactions will sum up to 2099999997690000 satoshis, practically 21million BTC.

Gmaxwell: /* "block" messages */ <= is the test, not < Please don't revert this without discussing with me.

2012-10-30T18:34:52Z

"block" messages: <= is the test, not < Please don't revert this without discussing with me.

← Older revision		Revision as of 18:34, 30 October 2012
Line 110:		Line 110:
	# Check if prev block (matching ''prev'' hash) is in main branch or side branches. If not, add this to orphan blocks, then query peer we got this from for 1st missing orphan block in ''prev'' chain; done with block		# Check if prev block (matching ''prev'' hash) is in main branch or side branches. If not, add this to orphan blocks, then query peer we got this from for 1st missing orphan block in ''prev'' chain; done with block
	# Check that ''nBits'' value matches the difficulty rules		# Check that ''nBits'' value matches the difficulty rules
	# Reject if timestamp is ~~before~~ the median time of the last 11 blocks		# Reject if timestamp is the median time of the last 11 blocks or before
	# For certain old blocks (i.e. on initial block download) check that hash matches known values		# For certain old blocks (i.e. on initial block download) check that hash matches known values
	# Add block into the tree. There are three cases: 1. block further extends the main branch; 2. block extends a side branch but does not add enough difficulty to make it become the new main branch; 3. block extends a side branch and makes it the new main branch.		# Add block into the tree. There are three cases: 1. block further extends the main branch; 2. block extends a side branch but does not add enough difficulty to make it become the new main branch; 3. block extends a side branch and makes it the new main branch.