Talk:Alternative chain - Revision history

Sgornick: moved Talk:Alternative Chains to Talk:Alternative chain: The article-naming convention used in this wiki generally is that a topic is singular, and the category/directory uses the plural. Changing to singular use.

2012-05-15T21:55:42Z

moved Talk:Alternative Chains to Talk:Alternative chain: The article-naming convention used in this wiki generally is that a topic is singular, and the category/directory uses the plural. Changing to singular use.

← Older revision		Revision as of 21:55, 15 May 2012
(No difference)

JohnTobey253 at 15:48, 16 June 2011

2011-06-16T15:48:28Z

← Older revision		Revision as of 15:48, 16 June 2011
Line 1:		Line 1:
	Excellent article! Two suggestions:		Excellent article! Two suggestions:

	The fields coinbase_tx, coinbase_merkle_branch, altblock_merkle_branch, and the yet-to-be-specified Merkle branch format are a lot of complexity. They could be generalized, with perhaps added flexibility, by supplying a new kind of script to link the alt chain header hash to the Bitcoin header hash. The script would start with the alt chain header hash on the stack and have access to a "concatenate" instruction (already implemented as OP_CAT) that pops the top stack item and appends it to the next one. Merkle branch navigation from the leaf hash to the root would be expressed as constants (stubs), concatenations, and sometimes swaps (when the branch goes left vs. right).		The fields coinbase_tx, coinbase_merkle_branch, altblock_merkle_branch, and the yet-to-be-specified Merkle branch format are a lot of complexity. They could be generalized, with perhaps added flexibility, by supplying a new kind of script to link the alt chain header hash to the Bitcoin header hash. The script would start with the alt chain header hash on the stack and have access to a "concatenate" instruction (already implemented as OP_CAT) that pops the top stack item and appends it to the next one. Merkle branch navigation from the leaf hash to the root would be expressed as constants (stubs), concatenations, and sometimes swaps (when the branch goes left vs. right). The embedding of a hash in a transaction or a block header could also be expressed as appending and prepending data.

	All the extra bytes (the script as just described) impose some burdens on the alternative chain. They must be stored even in SPV mode for proof of work. They must be transmitted along with block headers. They require additional verification steps. We would like to encourage miners to mine our block "first" or at least in such a way as to minimize this overhead. Alternative chains' block acceptance rules could impose a lower target (higher difficulty) on blocks with longer scripts. For example, if the normal block header size is 80 and the current target is T, a block of size S+80 (S bytes in the script) could require a hash below T * 80 / (S+80).		All the extra bytes (the script as just described) impose some burdens on the alternative chain. They must be stored even in SPV mode for proof of work. They must be transmitted along with block headers. They require additional verification steps. We would like to encourage miners to mine our block "first" or at least in such a way as to minimize this overhead. Alternative chains' block acceptance rules could impose a lower target (higher difficulty) on blocks with longer scripts. For example, if the normal block header size is 80 and the current target is T, a block of size S+80 (S bytes in the script) could require a hash below T * 80 / (S+80).

	[[User:JohnTobey253\|JohnTobey253]] 03:07, 16 June 2011 (GMT)		[[User:JohnTobey253\|JohnTobey253]] 03:07, 16 June 2011 (GMT)

JohnTobey253: Created page with "Excellent article! Two suggestions: The fields coinbase_tx, coinbase_merkle_branch, altblock_merkle_branch, and the yet-to-be-specified Merkle branch format are a lot of comple..."

2011-06-16T03:07:20Z

Created page with "Excellent article! Two suggestions: The fields coinbase_tx, coinbase_merkle_branch, altblock_merkle_branch, and the yet-to-be-specified Merkle branch format are a lot of comple..."

New page

Excellent article! Two suggestions:

The fields coinbase_tx, coinbase_merkle_branch, altblock_merkle_branch, and the yet-to-be-specified Merkle branch format are a lot of complexity. They could be generalized, with perhaps added flexibility, by supplying a new kind of script to link the alt chain header hash to the Bitcoin header hash. The script would start with the alt chain header hash on the stack and have access to a "concatenate" instruction (already implemented as OP_CAT) that pops the top stack item and appends it to the next one. Merkle branch navigation from the leaf hash to the root would be expressed as constants (stubs), concatenations, and sometimes swaps (when the branch goes left vs. right).

All the extra bytes (the script as just described) impose some burdens on the alternative chain. They must be stored even in SPV mode for proof of work. They must be transmitted along with block headers. They require additional verification steps. We would like to encourage miners to mine our block "first" or at least in such a way as to minimize this overhead. Alternative chains' block acceptance rules could impose a lower target (higher difficulty) on blocks with longer scripts. For example, if the normal block header size is 80 and the current target is T, a block of size S+80 (S bytes in the script) could require a hash below T * 80 / (S+80).

[[User:JohnTobey253|JohnTobey253]] 03:07, 16 June 2011 (GMT)